一、常用指标
1.1 用户数据(谁)
(1)存量
DAU/MAU – 日/月活跃用户,一日或一月内至少活跃一次的用户数。注意MAU != 当月内各日DAU总和。AU表示Active User。
- 对于Active:数据统计系统的定义,即基于事件上报,有事件上报表明该用户活跃;业务上的定义,基于关键事件的上报,条件更加严格。
- 对于User:认人,即每位注册用户有一个ID,但是未登录用户会漏掉;认设备,即每台设备一个标识符,但是无法对应设备背后的用户。
(2)增量:新增用户
1)如何选择合适的节点定义“新增”?
节点 | 优势 | 劣势 | 适用场景 |
---|---|---|---|
点击渠道链接 | 统计简单 | 离激活最远,转化率低 | 量级不大、免费渠道、不需要精细结算 |
下载 | 真实反映用户意愿 | 可信度低,存在刷量可能 | 渠道依赖应用商店,且没有更好渠道 |
安装、启动 | 离激活最近,容易统计 | 渠道不一定配合,存在刷量 | 自己较强势,可给渠道制定统计规则 |
激活 | 最真实的数据 | 渠道费用激增,统计复杂 | 对用户质量要求高,且产品ARPU高 |
2)如何判别“新增”?
- 基于设备:iOS、Android、web各有门道
- 基于账户关联:与后台已有账户对比匹配
(3)健康程度:留存率
- 三种留存算法:
- 七日日留存:只关心到特定日的留存情况,避免了其他日数据的干扰;第七天/第一天 * 100%
- 七日内留存:适用于有固定使用周期,周期较长的业务;第二天~第七天(去重)/第一天 * 100%
- 修正的七日日留存:使第七日与新增当日对齐,消除某些星期级别的周期性;第七天/第O天 * 100%
- 注意事项 以日留存作为比较标准,可以避免其他日数据的干扰,了解一个渠道的质量;以周或月做标准,可以观察整个大盘,衡量产品的健康情况,观察用户在平台上的黏性;注意周或月内流存量统计时务必去重。
(4)用户来源:渠道(参考留存率)
1.2 行为数据(干了什么)
(1)次数or频率:PV、UV、访问深度
1)定义:
- PV:Page Views,页面浏览量(次数)
- UV:Unique Visitors,独立访问数(人数)
- 访问深度:两种算法:用户对某些关键行为的访问次数;将网站内容或功能分成几个层级,以用户该次访问最深的一层计算。
2)用法示例:
- 详情页的评论转化率:评论发表页PV / 详情页PV;表示详情页引发评论的能力
- 用户的评论转化率:评论发表UV / 详情页PV;表示用户的评论倾向
- 人均行为次数:PV / UV;某个页面的人均浏览次数
(2)其他
- 行径走通程度:转化率
- 做了多久:访问时长
- 质量:弹出率
1.3 业务数据(结果怎样)
- 总量:GMV – 成交总额,指流水。GMV = 实际销售额 + 取消订单金额 + 拒收订单金额 + 退货订单金额 ……
- 人均:ARPU/ARPPU(Average Revenue Per Paying User,每用户平均收入)、人均访问时长
- 人数:付费人数、播放人数
- 健康程度:付费率、付费频次、观看率
- 被消费对象:SKU视角、被消费内容视角
二、选好数据指标的通用方法论
2.1 拆解业务模块
(1)拆解思路
目的 –> 手段 –> 支撑手段的手段
(2)拆解示例
- 资讯平台通过大量自媒体高效创作资讯换取广告收入
- 用户为了获取便捷的学习系统和良好的社群服务提供的教学效果支付学费
- 用户为了获得良好社交观影体验,以1V1弹幕聊天形式观看影片,贡献产品价值
2.2 判断模块类型
模块类型 | 产品对用户的价值来自 | 省时间 or 耗时间 |
---|---|---|
工具模块 | 产品本身 | 省时间 |
内容浏览模块 | 产品本身 | 耗时间 |
交易模块 | 其他资源 | 省时间 |
社区模块 | 其他资源 | 耗时间 |
三、选择合适的数据分析工具
3.1 计数统计
- 关键:快速验证
- 特点:简单、快
- 常见应用场景:单纯计数和固定报表
- 工具:埋点、BI报表工具
- 解决问题:统计PV、UV、在线人数等
3.2 流量导向
- 关键:渠道依赖
- 特点:能将流量入口分析的比较细致
- 常见应用场景:流量依赖性业务,如电商,或者一锤子买卖
- 工具:Google Analytics、Growing IO等
- 解决问题:谁来了?从什么渠道来的?来干了什么?有没有达到目的?
3.3 用户导向
- 关键:用户为王
- 特点:从用户视角描述单个用户的行为轨迹
- 常见应用场景:在乎用户长期价值,企业核心资产是用户
- 工具:Miaxpanel、appsee、inspectlet
- 解决问题:用户来干什么?用户还会不会再来?用户在哪流失了?用户画像?
3.4 内容导向
- 关键:内容质量
- 特点:能从内容的视角描述其表现
- 常见应用场景:以内容为核心资源,如媒体、视频网站
- 工具:百度统计
- 解决问题:哪些资源被消费?被消费的情况如何?内容表现质量如何?
3.5 业务导向
- 关键:商业本质
- 特点:从商业逻辑上还原整个业务流程,可接入线上线下的数据
- 常见应用场景:业务逻辑复杂,需跟踪周期长
- 工具:神策数据
- 解决问题:流程是否顺畅?规模、频次如何?异常原因?
四、数据分析方法
4.1 对比分析
(1)比什么?
- 绝对值:如销售金额、阅读数
- 比例值:活跃占比、注册转化率
(2)怎么比?
- 环比:与当前时间范围的相邻上一个时间范围对比
- 同比:与当前时间范围上层时间范围的前一范围中的同位置数据对比
(3)和谁比?
- 和自己比:从时间维度、从不同业务线、从过往经验估计
- 和行业比:是自身因素还是行业趋势
4.2 多维度拆解
(1)数据分析的本质就是:从不同角度去分析、观察同一个数据指标
(2)多维度拆解适用场景:
- 分析单一指标的构成:分栏目播放量;新老用户比例
- 针对流程进行拆解分析:不同渠道的浏览、购买转化率;打赏主播的等级、性别、频道;不同省份的活动参与漏斗;是否在WiFi或4G环境;等。
4.3 漏斗观察
(1)漏斗:
指的是一系列向后影响的用户行为。示例:影响新用户充值数的转化漏斗:安装–>注册–>阅读产品说明–>选择产品–>支付
(2)适用场景:
适用于有明确的业务流程和业务目标的场景了,不适用于没有明确流程、跳转关系复杂的业务。
4.4 分布情况
(1)运作原理:
从事件在不同维度中的分布来观察,以便了解事件除了累计数量和频次外,更多维度的信息。
(2)适用场景:
- 已知一群用户完成了特定事件,但需要对用户群体进行细分,按不同维度和价值将他们划分为不同群体,分别进行后续的维护或分析。
- 已知单个事件的完成次数,希望知道这些次数拆分到不同维度上后的分布情况,以便更清晰地了解该事件的完成情况。
- 常见的群体划分:事件频率/一天内的时间分布/消费金额的区间
4.5 用户留存
(1)运作原理:
- 大盘留存:将某时间段与另一时间段的用户ID交叉去重;
- 精准留存:过滤进行过指定行为的用户ID,或将用户分为不同群体后,再计算;
(2)适用场景:
评估产品功能黏性、验证产品长期价值
4.6 用户画像
(1)运作原理:
通过对用户各类特征进行标识,给用户贴上各类标签,然后可以通过标签将用户分为不同群体,以便对不同群体分别进行产品、运营动作。
(2)常见特征 – 示例标签
- 基础属性:年龄、性别、生日、星座、教育、身高、职业、收入
- 社会关系:婚姻状况、有无小孩、家有老人、性取向
- 行为特征:注册时间、来源渠道、买过特惠商品、曾获优秀学员
- 业务相关:高矮胖瘦、体脂率、健身习惯、日均步数、收藏100+份健身计划
(3)标签来源
- 通过用户的特征推理得出
- 通过用户身边的人推断,协同过滤寻找行为相似的用户
(4)适用场景:
市场营销、个性化运营、业务分析、用户研究,等。
4.7 归因查找
(1)运作原理:
将事件拆解,并根据业务性质,确定影响事件完成的关键因素。
(2)适用场景:
- 将目标的达到拆分到各个模块,方便统计个模块的贡献
- 获悉当前指标达成的主要因素,获得如何提升业务指标的洞见
(3)不同场景的归因查找:
- 末次归因:转化路径短,且事件间关联性强的场景
- 递减归因:转化路径长,非目标事件差异不大,没有完全主导的
- 首次归因:强流量依赖的业务场景,拉人比后续所有事都重要
4.8 路径挖掘
(1)运作原理:
逐级展开某一事件的前一级或后一级事件,观察其流向
(2)适用场景:
有明确的结果目标或起始场景,希望观察这个场景前后会发生什么
4.9 行为序列
(1)运作原理:
将单一用户所有行为以时间线的形式进行排列
(2)适用场景:
- 观察掩盖在统计信息下更细致的信息,还原用户具体的使用场景
- 通过观察具体的行为特征,找到提升产品价值的机会点
五、数据分析案例
- 9个数据分析方法:对比分析、多维度拆解、漏斗观察、分布情况、用户留存、用户画像、归因查找、路径挖掘、行为序列
- 常见业务场景:数据涨跌异动如何处理?如何评估渠道质量,确定投放优先级?功能/内容上线后,如何评估其短期效果、长期价值、未来潜力?了解数据背后的用户,从而 高质量拉新、精准运营推送、辅助产品设计;如何揪出羊毛党?
5.1 数据异常涨跌如何处理?(对比分析 + 多维度拆解)
(1)问题出现
昨天的收入下跌10%
(2)多维度拆解
问题严重吗?是不是服务器挂了?是不是渠道问题?是不是哪里缺货?
(3)对比分析:
- 维度:问题严重程度?
- 假设:如果是个例,往期应该没有这么大的跌幅
- 证明:周同比、月同比确实没有这么大的跌幅
- 结论:问题严重
5.2 评估渠道质量以确定投放优先级
(1)常见渠道划分方式
- 来源(具体的流量实体):百度、头条、线下……
- 媒介(实体中承载推广的实体):SEM、自然搜索结果、Banner……
- 其他参数:营销活动名称、广告关键词……
(2)渠道质量跟踪
1)选择关键事件:选取反映你的产品的目标人群的行为的数据
- (√)电商购买、社区发帖(衡量各渠道来的用户是否为目标用户)
- (×)完成为期三个月的课程(门槛太高、流程太深,转化率极低,区分度低)
- (×)打开App/访问首页(门槛太低,同样区分度低)
2)查看产生关键事件的用户来源
- 对比各个渠道的指标:激活用户数、新用户人均使用次数/时长、新用户留存率……
5.3 功能/内容上线后,如何评估其价值
(1)评估思路
- 上线后的目标与价值清晰明确:借助漏斗分析和用户分群
- 上线后关注其对产品价值的提升:借助精准留存对比
- 上线以探索更长期的产品潜力 – 借助分布情况分析,是否优化了频次或场景的分布:某社交App,本来每天只用1次,发布新功能后变为3次;某博客产品,本来只在通勤时间使用,上线情感内容后深夜段用户增加。
(2)新上线漫画(内容)对付费会员(支付)转化的效果评估
- 单纯的数字相关不足以说明问题,不能说付费涨了就是这批漫画的贡献,要将具体数字代入业务流程中进行检验。
- 可以借助用户分群对比:分为看过该漫画的用户和未看过该漫画的用户。
- 借助漏斗对比:控制流量入口,对比该漫画与其他漫画的会员付费转化效果。
(3)某一主播对产品价值(用户留存)的影响
留存是一个特别复杂的构成,受很多因素影响,需要分析精准留存。
5.4 高质量拉新
(1)从现有用户中找到我们真正的高质量用户
- 留存率高
- 核心行为完成率高,频次高
(2)分析高质量用户的特征
- 是谁;用户画像,例如通过他们买的书籍,分析年龄、学历、地域、消费能力等信息
- 从哪里来;渠道来源,例如通过问卷调查,发现很多来自朋友推荐
(3)按照特征寻找类似用户
- 用户画像:高校、知识密集型工作区域,倾向消费社科类书籍
- 渠道来源:采用人拉人方式
5.5 精准运营推送
(1)通过用户分群精准推送
由于运营能力有限,分群太多太精确,也不可能编写那么多不同的推文;应该在ROI上找一个平衡点,先选择容易出成绩的,包括容易出成绩的标签,例如电商的性别标签;以及容易出成绩的运营位,例如首页、每日推送。
(2)如何选择最重要的几个标签
- 人口统计学意义上的标签,如性别、年龄、地域;例如K12教育的地域标签;
- 业务相关度高的标签:例如健身,BMI影响用户对内容的诉求;
(3)推送内容要与用户有关
- 向我说话:利用用户之前留下的信息,在推文中使用相应名称;
- 有我触发:通过挖掘用户的行为序列,将推送与用户的高频行为挂钩;
- 和我有关:真正和用户的需求有关;
5.6 辅助产品设计
- 谁:用户画像
- 在什么情况下:行为序列的属性
- 做了什么/遇到什么问题:行为路径、App内屏幕录像
5.7 查出羊毛党
- 定位:流量监控、员工审核、人工举报
- 找到模式:机刷、人刷、其他行为特征
- 找到:按规则爬取并人工审核
- 解决:封、提高关键步骤成本
六、数据采集
6.1 明确埋点需求
- who/when/where/how/what:某个用户在某个时间点、某个地方,以某种方式完成了某个具体的事情。
(1)Who
1)认设备:
- web – cookies
- iOS – UUID、IDFV、IDFA
- Android – UUID、AndroidID
2)认人:
- 线上 – UID、微信号等第三方UnionID/OpenID、手机号、身份证号
- 线下 – 手机号、身份证号
(2)When
- 哪个时间节点:事件发生、事件上报、事件接受、事件入库
- 哪个时区时间:上报时间时区、Unix时间戳
(3)Where
- GPS – 可结合地图API获取详细地址信息
- IP – 统一分配给运营商,相对GPS较粗略,可通过三方反查归属地
- 自主填写 – 相比用户真实位置,更关心用户希望在哪儿,如装修买房
(4)How
- 用的什么设备?
- 装的什么版本?
- 操作系统是什么?
- 用的什么浏览器?
- 使用4G还是WIFI?
- 从那个页面跳转过来的?
(5)What
- 购买事件:商品名称、商品类型、购买数量、购买金额、付款方式……
- 搜索:搜索关键词、搜索类型……
- 用户注册:注册渠道、注册邀请码……
- 用户投诉:投诉内容、投诉对象、投诉渠道、投诉方式……
- 退货申请:退款金额、退货原因、退货方式……
(6)示例数据
1)公共属性
id | event_name | device_id | user_id | time_stamp | location | how | what |
---|---|---|---|---|---|---|---|
1 | pay | ||||||
2 | pay | 666 | 888 | 2019 | sz | ? | ? |
3 | pay |
2)事件聚类
id | event_name | …… | position |
---|---|---|---|
1 | detail_pay | – | detail |
2 | home_pay | – | home |
3 | H5_pay | – | H5 |
4 | offline_pay | – | detail |
5 | detail_pay | – | home |
6 | H5_pay | – | H5 |
7 | Campaign_pay | – | campaign |
6.2 形成需求文档
(1)数据需求文档(Data Requirements Document,DRD)
- 作为与研发沟通的凭借,沟通每个事件触发的时机和定义、属性取值的来源、背后隐藏的逻辑;
- 管理数据埋点的当前状态和迭代历程中留下来的判断逻辑和附加信息
(2)埋点属性的来源
- 除非某个行为只在前端发生,否则建议永远在后端收集
- 前端:调用API、取页面上的值、行为统,(例如前台timer,自动触发记录时长)
- 后端:业务数据、查关联表、前端送来的数据、技术数据,(如单次事件响应时间)
(3)埋点有效性的检验
- 手段:抓包,或者后台查看
- 方法:与DRD逐项对比,核对是否符合预期结果
- 意义:由于数据不具备回溯性,丢失了无法恢复,需要事先检验埋点有效性
(4)DRD维护:
是否在线、上线时间、下线时间、修改备注
6.3 数据采集实战
(1)业务背景
- 一家专注于互联网行业学习交流的社区媒体,产品之前的首页feed主要来自于用户关注的好友产生的数据。但是存在问题:关注的好友不够多,刷不出新的内容;关注的好友缺少动态,也刷不出新的内容。
- 提问题:如何才能让用户的阅读范围跳出他关注的圈子的限制?
- 提方案:上个性化推荐
(2)埋点事件确定
1)需求:
- 产品自身的指标建模
- 内容推荐模块:
- content impression by user;
- 各个内容的CTR;
- 各个内容类型的曝光和点击需要能够分开查看;
- 评论数和点赞数是否对阅读产生影响;
- 内容推荐模块:
- 业务部门的分析需求
- 技术部门的需求:
- 每个卡片匹配
不感兴趣
按钮; - 用户主动刷新或加载内容;
- 区分不同推荐理由;
- 每个卡片匹配
- 广告部门的需求:
- 每天广告曝光量以及CTR效果;
- 广告曝光时长(focus duration);
- 技术部门的需求:
2)指标 – 埋点
- 内容卡片曝光量(可按内容类型和话题拆分)– cardShow
- 内容卡片点击量(可按内容类型和话题拆分)– cardClick
- 广告曝光量、点击量以及曝光时长 – adShow、adClick、adDuration
- 主动刷新推荐feed的次数 – pullRefresh
- 主动滚动到底部加载新内容的次数 – loadMore
- 点击不感兴趣的次数和原因 – notInterested
(3)属性拆解
- App公共属性:用户ID、触发时间、应用版本、网络类型、设备ID、操作系统,等;
- 事件属性(以cardClick字段为例):内容ID、内容类型、列表位置、推荐理由、内容频道、有无图片、评论数、点赞数,等;
(4)触发时机
1)事件定义
- cardShow:卡片在用户可见的屏幕范围内出现就算一次展示;
- cardClick:用户点击卡片可跳转的区域就算一次点击;
- adShow:广告卡片在用户可见的屏幕范围内出现;
- adClick:用户点击广告卡片可跳转的区域;
- pullRefresh:用户在顶部下拉,触发接口刷新后,新内容渲染出来算一次刷新;
- loadMore:滚动到底部,触发接口加载新内容,渲染出来,算一次加载;
- notInterested:用户点击了
×
,并选择了理由算一次不感兴趣事件;
2)事件详细定义以及属性
- cardShow
- 卡片在可见范围内出现;“出现”的定义–卡片的2/3高度露出;快速滑动时不计算展示,停止滑动一秒后开始计算;单次访问中不重复上报。
- 事件属性定义:
- contentId:从API中返回数据中提取的contentId字段
- contentType:type字段
- position:按照客户端实际加载的列表顺序进行赋值
- recommendReason:API返回数据中的reason字段
- channel:c字段
- withPictures:从API返回数据中判断是否有图片
- adShow
- 相当于cardShow的子类,定义类似
- 事件属性定义:类似cardShow
- duration:触发adShow开始计时,滚动后面积少于2/3结束计时;用户有任何离开推荐tab的行为(切换tab、退出App、锁屏)结束计时。
- pullRefresh
- 事件属性定义:
- times:单日刷新次数
- interval:刷新间隔时长;用当前时间戳减去上一次API返回的时间戳
- 事件属性定义:
- loadMore
- 事件属性定义:
- depth:加载深度,即当前列表position最大值
- interval:同pullRefresh
- 数据检验发现的问题:
- 卡片展示、卡片点击的position值经常为0;
- loadmore的interval字段可能出现极大的值(几万秒);
- 事件属性定义:
(5)数据检验
- 检验埋点上新后对业务目标的影响,并据此推出新功能
- 参考网页表格
(6)新需求(参考网页表格)
6.4 其他数据采集方法
(1)全埋点/无埋点
- 全埋点/无埋点 –> 把所有浏览和点击行为记下来
- 适用场景:
- 分析需求简单(只需要统计PV和点击量)
- 开发限制因素多(临时活动,没有资源部署埋点)
- 业务流程简单(不涉及更多信息,只有点击、跳转)
- 技巧:可将本来一页完成的流程拆分为多页,实现采集更多信息
- 限制:非浏览和点击事件无法记录,无法采集what、how类的信息
(2)案例:AB站UP主留存率对比
- 数据获取:将所需数据指标拆解,爬取公开数据并代入。
- 对于UP主留存率这一指标,需要计算UP主每天上传视频数量;可以爬取所有视频数据,分析上传视频和用户ID,计算每周/月/年的留存率。
END