互联网数据分析实战
2020-04-27 18:06:57 3 举报AI智能生成
登录查看完整内容
互联网数据分析实战课程笔记，涉及多种数据分析方法及多项实际业务分析
作者其他创作
大纲/内容
互联网数据分析实战
数据指标建模
常见数据指标定义
数据指标：对当前业务有参考价值的统计数据
对业务有价值
可统计
常见数据指标
用户数据（谁）
存量
DAU：日活跃用户
自然日
跨时区（如全球服务）则关心最近24h
MAU：月活跃用户
MAU≠当月各日DAU之和
务必去重，才有观察意义
Active活跃：基于事件上报，有事件上报=用户活跃，但部分上报事件不一定来自用户主动操作
增量
新增用户
选择合适的节点，定义【增】
1.点击渠道页面链接
统计简单，离激活环节最远，转化率太差
适用于量级不大/免费渠道，不需要做精细结算
2.进入应用商店下载
反应用户的实际意愿
数据源可信度存疑，无法避免刷量
适用于渠道依赖应用商店且没有更好的渠道
3.安装/启动app进入应用首页
离「激活」最近，便于统计
渠道不一定配合，仍然无法避免刷量
适用于自己较强势，可给渠道制定统计规则
4.激活（完成注册）
最真实的数据
渠道费用激增，统计复杂
适用对用户质量要求很高且产品ARPU高\b
如何定义【新】
基于设备
基于账号关联，和后台已有账号比对匹配
健康程度
留存
7日日留存率
计算方法
算法一：第七天活跃用户/第一天新增用户*100%
算法二：第七天活跃用户/第0天活跃用户*100%
新增当天为第0天
分子分母星期相同，某种程度能抵消星期级别的波动
了解某渠道质量，以天为单位，衡量渠道用户当下&接下来的表现
以【X日日留存】作为比较标准时，可以避免其他日数据干扰
了解某个渠道质量
7日内留存率
计算方法：第二天—第七天去重后活跃用户/第一天新增用户*100%
用户访问特别集中，只看Day7不能反应真实情况（如用户集中在周六周天使用），此时需关注7日内留存
周/月留存率
以周/月为单位，衡量产品第健康情况，观察用户在平台上的粘性
算法：指定周（月）活跃用户数/第1周（月）活跃用户数*100%
计算时务必去重！
观察大盘数据
从哪儿来
渠道来源
直接访问
引荐流量
搜索引擎自然流量
搜索引擎付费流量
社交媒体等
行为数据（干了什么）
次数/频率
PV
Page Views 页面访问量（次数，不去重）
UV
Unique Visitors 独立访问数（人数，去重）
访问深度
算法一：用户对某些关键行为的访问次数
算法二：将网站内容/功能分成几个层级，以用户本次访问过最深的一级计算
路径走通程度
转化率
关注功能：PV/PV
关注业务：UV/UV
PV/UV不是转化率，是（关键功能/动作的）人均触发次数
做了多久
访问时长
通过统计特殊事件，支持业务需求
e.g统计视频被消费程度，评价内容质量，可以记录暂停/关闭页面后，播放器中视频进度条当前的位置
具体的访问时长统计难度高，且不具有真实意义（不确定用户是否真实访问）
质量
弹出率
用户来了只访问一个页面，没有任何行为立马就走了
业务数据（结果怎样）
总量
GMV：描述交易的金额总规模
人均
ARPU/ARPPU
ARPU：人均付费，平台总收入/总用户数
ARPPU：付费用户人均付费，平台总收入/平台付费用户数
人均访问时长
人数
付费人数
观看人数
付费率/付费频次
观看率等
被消费对象
SKU/被消费内容视角
需要分析消费品本身的运营情况
数据指标选择原则
1. 指标的选取必须和商业发展的核心目标契合，且不同时期关注的指标不一样
2. 关注的指标必须反应用户的核心价值
3. 数据必须能够汇总
数据指标选取步骤
1.拆解业务模块
通过最终目的反推梳理业务模块
确定最终目的
如何搞大/搞频繁（手段）
有什么困难，通过什么特色方式解决（工具）
2.判断模块类型
工具模块
省时间
产品对用户的价值来自产品本身
内容浏览模块
杀时间
交易模块
产品对用户的价值来自「连接」其他资源
社区模块
3.根据模块类型，选取数据指标
数据指标需回归业务具体落实
使用量
目标达成率
频次
浏览数
浏览广度
浏览时长
内容互动
详情页转化率
金额/GMV
客单价
复购率
发布量
互动量
关系密度
数据分析工具
如何选择合适的数据分析工具
数据工具解决问题
计数
流量
内容
用户
业务
如何选择合适的数据工具
1.根据业务核心划分
核心问题：公司缺了什么，最要命？
根据核心业务选择合适的数据分析工具
如规模化电商，更倾向流量快速变现，选择流量导向工具
奢侈品电商，更倾向用户维系，选择用户导向数据工具
2.根据公司阶段划分
探索期
业务问题：刚起步不完善，流程未定型，常变动
待解决需求：验证业务是否可行，需求是否存在
数据工具：计数导向
成长期
业务问题：追求增长
待解决问题：寻找用户量和业务量规模化增长的方法
数据工具：流量导向、内容导向、用户导向、业务导向
成熟期
业务问题：稳定，没有新的突破点
待解决问题：业务流程理的更顺、用户群体拆的更细
数据工具：用户导向、业务导向
衰退期
业务问题：用户对产品渐渐失去兴趣，开始流失
待解决问题：延长产品生命周期，尽力挖掘用户剩余价值及可能的新需求
数据工具：用户导向
常见数据分析“套路”
计数统计：快速验证
通过脚本与代码统计日志
通过BI工具进行基本的分析
流量导向：渠道依赖
解决问题
谁来了
从哪里来
来了干什么
有没有达成目标
流量导向工具
解决问题：流量依赖性业务，如电商，或一锤子买卖
优势：能将流量入口分析的较为细致
内容导向：质量第一
哪些资源被消费
被消费的情况如何
内容表现质量如何
内容导向工具
解决问题：以内容为核心资源的，如媒体、视频网站
优势：能从内容的角度描述其表现
用户导向：用户为王
来了干什么：用户行为路径
还会不会再来：留存分析
在哪流失：漏斗分析
用户都是什么样的：用户画像
用户导向工具
解决问题：需关注隐藏在报表、总量下面的用户具体的行为
优势：从用户视角描述单个用户的行为轨迹
业务导向：商业本质
业务流程是否顺畅
规模/频次如何？
异常原因在哪
业务导向工具
解决问题：业务逻辑复杂，需要跟踪周期长
优势：从商业逻辑上去还原整个业务流程，可接入线上-线下
数据处理
数据分列
插入空白列—选中—数据下的「分列」—分隔符号
分列脏数据处理：因空格导致的分列使用「查找」—「替换」，将空格替换
数据清洗
筛选
去重
排序
数据二次处理
数据查询：「VLOOKUP」函数（计算用户留存）
函数语法结构：VLOOKUP（查找的值，查找范围，找查找范围中的第几列，精准匹配还是模糊匹配）
条件判断：IF函数
条件求和：SUMIF（单条件）、SUMIFS（多条件）函数
SUMIF语法结构：SUMIF（条件范围，条件，求和范围）
条件计数：COUNTIF（单条件）、COUNTIFS（多条件）函数
COUNTIF语法结构：COUNTIF(条件范围，条件)
COUNTIFS语法结构：COUNTIFS（条件范围1，条件1，条件范围2，条件2……条件范围N，条件N）
逆向查询：LOOKUP函数
函数语法结构：LOOKUP（查找的值，查找的条件，返回值的范围）
提取出生年月（身份证）：TEXT+MID函数
函数语法结构：TEXT（MID（数据范围，第几位数开始，符号长度，字符格式））
计算年龄（身份证）：DATEDIF函数
数据透视表
数据可视化
Excel
折线图：适合连续性时间纬度对比
柱状图：单类别对比
柱状堆积图（比例）：有两种纬度对比，其中一种纬度还需按照不同比例进行观察
饼图：不关心绝对数量，关心单类别在总量中的占比
二维面积图：连续时间段内，各类别产品对销售总量的贡献占比和趋势
RAWGraphs
Circle Packing：分类分析
Beeswarm Plot（蜂群图）：http://rawgraphs.io/learning/how-to-make-a-beeswarm-plot/
产品链接：https://rawgraphs.io
其他图表使用介绍：https://rawgraphs.io/learning/
高德地图开放平台
产品介绍—「Map Lab（数据可视化）」
点类型
热力图
产品链接：https://lbs.amap.com
提升：1.多体验和分析相似甚至不同类型的产品，接触不同类型的用户，尤其是小众奇葩用户
解决地理位置可视化问题
数据分析方法
对比分析
比什么
绝对值：本身具备【价值】的数字
#不易得知问题的严重程度
销售额
阅读数
比例值：在具体环境中看比利才具备对比价值
%易受到极端值影响
活跃占比
注册转化率
怎么比
环比：与当前时间范围相邻的上一个时间范围对比
对短期内具备连续性的数据进行分析
需要根据相邻时间范围的数字对当前时间范围的指标进行设定
同比：与当前时间范围上层时间范围的前一范围中同样位置数据对比
观察更为长期的数据集
观察的时间周期里有较多干扰，希望某种程度上消除这些干扰
和谁比
和自己比
从时间纬度
从不同业务线
从过往经验估计
和行业比
是自身因素还是行业趋势
都跌，能否比同行跌的少
同涨，是否比同行涨的慢
多维度拆解
运作原理：指标/业务流程需要按照多维度拆分，来观察变动
适用场景
分析单一指标的构成
分栏目播放量
新老用户比例
针对流程进行拆解分析
不同渠道的浏览、购买转化率
不同省份的活动参与漏斗
还原行为发生时的场景
打赏主播的等级、性别、频道
是否在Wi-Fi或4g环境下
漏斗分析
漏斗：一连串向后影响的用户行为
漏斗建立容易掉的坑
1.漏斗一定是有时间窗口的
根据业务实际情况，选择时间窗口
按天：对用户心智对影响只在短期内有效（如短期活动）
按周：业务本身复杂/决策成本高/多日才能完成（如理财/美股开户）
按月：决策周期更长（如装修买房）
2.漏斗一定是有严格顺序的
不能用「ABCDE」的漏斗，看「ACE」的数据
3.漏斗的计数单位可以基于【用户】、也可以基于【事件】
基于【用户】：关心整个业务流程的推动
基于【事件】：关心某一步具体的转化率
4.结果指标的数据不符合预期
自查：是否只有这一个漏斗能够到达最终目标？
运作原理：通过一连串向后影响的用户行为来观察目标
适用：有明确的业务流程和业务目标
不适用：没有明确的流程、跳转关系纷繁复杂的业务
分布分析
运作原理：从事件在不同纬度中的分布来观察，以便理解该事件除了累计数量和频次外，更多纬度的信息
常见划分
事件频率
一天内的时间分布
消费金额的区间
已经知道一群用户完成了指定事件，但需要对用户群体进行细分，按不同纬度和价值将他们划分不同群体，分别进行后续的维护或分析
已经知道单个事件的完成次数，希望知道这些次数拆分到不同纬度上后的分布情况，以便清晰的了解该事件的完成情况
用户留存
评估产品功能粘性
精准留存
过滤进行过指定行为的用户ID，再计算
将用户分为不同的群体后，观察其之间留存的区别
验证产品长期价值（月留存）
大盘留存
将某时间段与另一时间段的用户ID交叉去重计算
用户画像
运作原理：通过对用户各类特征进行标识，给用户贴上各类标签，通过这些标签将用户分为不同的群体，以便对不同群体分别进行产品/运营动作
常见特征
基础属性：年龄、性别、生日、星座、教育、收入、职业等
社会关系：婚姻、有无孩子、有无老人、性取向等
行为特征：注册行为、来源渠道、买过特惠商品、曾获优秀学员等
业务相关：胖瘦高矮、体脂率、在练胸、收藏100份健身计划等
标签来源
直接填写
通过用户自己的已有特征推得
通过用户身边的人推断
市场营销
高质量拉新
1.找到现有用户中表现最好的一批用户
2.提炼这批用户特征
3.照此特征，找到类似用户
个性化运营
业务分析
用户研究
精准运营推送
辅助产品设计
归因查找
运作原理：将事件拆解，并根据业务性质，确定影响事件完成的关键部分
首次归因：强流量依赖的业务场景，拉人比后续所有事情都重要
递减归因：转化路径长，非目标事件差异不大，没有完全主导的事件
末次归因：转化路径短，且事件间关联性强的场景
将目标的达成拆分到各个模块，方便统计各模块的贡献
获悉当前指标达成的主要因素，获得如何提升业务指标的洞见
路径分析
运作原理：逐级展开某一事件的前一级（后一级）事件，观察其流向
有明确的起始场景，希望观察这个场景它之后发生了什么
有明确的结果目标，希望观察来的用户是如何到达的
行为序列分析
运作原理：将单一用户的所有行为以时间线的形式进行排列
观察掩盖在统计信息下更细致的信息，还原用户具体的使用场景
通过观察具体的行为特征，找到提升产品价值的机会点
常见业务处理
数据涨跌异常处理
发现异常
确定问题
同比、环比确定是否存在问题
确定原因
常见假设
活动影响：查对应活动页面及对应动作的数据波动，关注活动是否有地域属性
版本发布：将版本号作为纬度，区分查看
渠道投放：查看渠道来源变化
策略调整：策略上线时间节点，区分前后关键指标波动
服务故障：明确故障时间，按时间为纬度进行小时或者分钟级别的拆分
数据是验证假设的支撑工具
针对性解决问题
执行
功能/内容上线后，如何评估短期/长期价值
上线后的目标与价值清晰明确
借助漏斗分析对比（转化关系明确时）
借助用户分群对比（转化关系较为复杂时）
上线后关注其对产品价值的提升
借助精准留存对比
上线以探索更长期的产品潜力
借助分布情况分析，对比其是否优化了使用频次/场景的分布
查出羊毛党
找到【1】
发现数据异常
异常高且无理由的流量
工作人员观察
人工举报
找到模式
明确其目的
刷量
薅羊毛
apam垃圾广告
观察其特征
机刷
人肉刷
找到【N】
RD爬取并人工审核
一网打尽
封禁/封禁权限
提高关键成本
前：注册7日后方可发帖
中：减少存在bug的商品的库存
后：提高提现的审核力度/周期
不做处理
根据roi决定是否需要进行处理
数据采集
明确数据埋点
Who
认设备
认人：UID、微信等第三方Union ID等
公共属性
When
哪个节点的时间
哪个时区的时间
上报时间时，带时区
使用Unix时间戳
Where
GPS
需要通过API取得详细地址信息（国家/省/市/街道）
IP
统一分配给运营商，相对较粗略，可通过三方反查所属地
自主填写
相比用户真实位置，更关心用户希望在哪儿，如装修买房
How
用的什么设备
装的哪个版本
操作系统是什么
用的哪个浏览器
用4G还是WI-FI
从哪个页面跳过来
……
What
购买
商品名称、类型、购买数量、购买金额、付款方式等
搜索
搜索关键词、搜索类型等
用户注册
注册渠道、注册邀请码等
用户投诉
投诉内容、投诉对象、投诉渠道、投诉方式等
申请退款
退货金额、退货原因、退货方式等
形成数据需求文档（DRD）
埋点位置
前端
属性来源
调用API
取页面上的值
行为统计（如前台timer，自行触发&记录页面时长）
弊端
某些属性前端没有：where/what/how 的许多信息，往往只存在后端
改动依赖产品发版
App Store需审核、web发版也需排期，响应速度不如后期
事件上报时机略尴尬
需要在省流量/省电和及时性之间取舍
后端
业务数据
查关联表
前端送来的数据
技术数据（如单次事件响应时间）
0 条评论
回复 删除
下一页
