统计指标、业务数据、预制模型、自定义分析
数据采集-指标建模-观测数据-数据分析-业务洞察
数据使用的能力模型
能力项 | 本课程 | 未来 |
建模 | 目标明确、流程单一的功能/模块 | 复杂产品的指标体系 |
工具 | 利用现有工具自身的特性 | 跨工具组合使用 |
方法 | 掌握9个常见分析方法 | 需求驱动的分析方法 |
应用 | 完成对业务现状的描述 | 用数据为业务直接产生价值/预测趋势及未来 |
1、数据指标
什么是数据指标?-对当前业务有参考价值的统计数据
常用的数据指标有哪些?它们是怎么定义的?
日常工作中查看这些指标会碰到哪些坑?
①用户数据:
存量-DAU/MAU
增量-新增用户
健康程度-留存率
从哪儿来-渠道来源
②行为数据:
次数/频率-PV、UV、访问深度
路径走通程度-转化率
做了多久-时长
质量-弹出率
③业务数据:
总量 | GMV | 访问时长 |
人均 | ARPU/ARPPU | 人均访问时长 |
人数 | 付费人数 | 播放人数 |
健康程度 | 付费率、付费频次 | 观看率 |
被消费对象 | SKU视角 | 被消费内容视角 |
1)用户相关指标:
Daily/Monthly Active User
日/月 活跃 用户
Daily 自然日 若跨时区则关心最近24H
Monthly 当月至少活跃一次的用户总数
MAU不等于当月各日DAU之和
单纯将日活累加而不去重,是没有任何参考价值的
Active
方法一:数据统计系统的定义
预制报表的统计系统(友盟、百度统计、GA等等)
基于事件上报:有事件上报=该用户活跃
上报一事可能有“坑”(假定了事件上报一定来自用户主动操作)
谨防Surprise!(活跃暴增,其他数值并无显著增加)
方法二:业务上的定义
基于关键事件上报:用户执行了关键事件=该用户活跃
存在维护成本:需不断维护日活时间列表
存在沟通成本:团队内外对(活跃)的认识需统一
User
认人
给每位注册用户一个唯一的专属ID
只适合强注册/登陆环境,未登录的用户会被漏掉
用户数=访问过服务的ID数
认设备
在网页cookie中埋下一段长随机字符串,作为设备唯一标识符
无法对应设备背后的用户
用户数=访问过服务的设备数
认人OR认设备
是否有账号体系?no=认设备
业务场景是否强依赖登陆?yes=认人+认设备
不登录的用户对业务是否有价值?no=认人+认设备 yes=认设备
新增用户
问题一:选择合适的节点,定义(增)
渠道商往往强势,哪个节点算钱应该先谈清楚
渠道ABC-渠道页面-应用商店-应用首页-完成注册
点击渠道连接 | 下载 | 安装/启动 | 激活 | |
优势 | 统计简单 | 真正反映了用户的实际意愿 | 离(激活)最近,便于统计 | 最(真实)的数据 |
劣势 | 离激活环节最远,转化率太差 | 数据源可信度存疑,无法避免刷量 | 渠道不一定配合,仍然无法避免刷量 | 渠道费用激增,统计复杂 |
适用场景 | 量级不大/免费渠道,不需要做精细结算 | 渠道依赖应用商店且没有更好的渠道 | 自己较强势,可给渠道制定统计规则 | 对用户质量要求很高且产品ARPU高 |
问题二:用适当的方法,判别(新)
基于设备
基于账号关联
用户留存
为什么要看留存?
了解某一个渠道的质量-日留存(7日日留存/30日日留存)
以天为单位,衡量这个渠道来的用户当下&接下来的表现
以(x日日留存)作为比较标准时,可以避免其他日数据的干扰
特殊:用户访问特别集中,只看Day7来评价,往往不能反映真实情况,此时,关注7日内活跃情况,更能描述渠道质量
观察整个大盘-周留存/月留存(次周周留存/次月月留存)
以周/月为单位,衡量产品的健康情况,观察用户在平台上的粘性
务必去重!
2)行为相关数据指标:
Page Views 页面浏览量(次数)
Unique Visitors 独立访问数(人数)
PV/UV 人均行为次数
访问深度:用户对产品的了解程度
算法一:用户对某些关键行为的访问次数
算法二:将网站内容/功能分成几个层级,以用户本次访问过最深的一级计算
访问时长
web时代:页面打开时长(如果我一直没关)
app时代:前台驻留时长(如果我手机放桌子没有动)
通过瞳孔与注意识别:摄像头观察瞳孔是否注视屏幕(需要外设和隐私授权)
要想明白统计时长用来干嘛
通过统计特殊事件,支持业务需求
统计视频被消费程度,评价内容质量
记录暂停/关闭页面后、播放器中视频进度条当前的位置
弹出率
客户来了立马就走了,没有进行其他操作
一个客户当天来了很多次,每次都算一次会话,每次会话都算一次弹出率
3)业务相关的数据指标:
常用的业务数据指标
直接付费 | 适用场景 | 解决什么问题 | 非直接付费 |
GMV | 总量 | 描述交易的金额总规模 | 目标完成数 |
ARPU/ARPPU | 人均 | 单个用户的贡献程度 | 人均访问时长 |
付费人数 | 人数 | 描述愿意为服务付费的人数总规模 | 完成人数 |
付费率、付费频次 | 健康程度 | 描述总体上的用户付费意愿评判一个服务的健康程度 | 完成率 |
SKU视角 | 被消费对象 | 需要分析消费品本身的运营情况时 | 被消费内容视角 |
2、选好数据指标的通用方法论
①从业务的最终目的出发梳理业务模块
常见的拆解角度:
目的、手段、支撑手段的工具、支撑手段的手段
如何搞大/稿频繁(手段)
往往有什么困难,我们通过什么特色方式解决的(工具)
②判断业务模块所属类型
四大业务模块
工具模块(效率)、内容浏览模块(质量)、交易模块(转化率)、社区模块(活跃)
产品对用户的价值来自产品自身
产品对用户的价值来自(连接)其他资源
③根据业务模块所属类型选择数据指标
工具类模块关心的指标
描述了什么 | 举个例子 | 做好了就能怎样 | |
使用量 | 累计量,投入程度 | 拍照、笔记 | 用户粘性强 |
目标达成率 | 是否正常运转 | 支付、搜索 | 满意度高 |
频次 | 能不能让用户养成习惯 | 闹钟 | 养成固定习惯 |
交易类模块关心的指标
描述了什么 | 举个例子 | 做好了就能怎样 | |
详情页转化率 | 核心场景转化效率 | 电商 | 更容易卖 |
金额 | 总的交易规模 | 电商、知识付费 | 卖更多 |
客单价 | 单个用户价值 | 奢侈品海涛 | 卖更高价 |
复购率 | 收入的持久度 | 订阅式购物 | 卖更多次 |
内容浏览类模块关心的指标
描述了什么 | 举个例子 | 做好了就能怎样 | |
浏览数 | 累计量 | 头条类 | 有多少人阅读 |
浏览广度 | 覆盖内容库存情况 | 视频网站多个频道 | 库存利用效率更高 |
客单价 | 占据用户多少时间 | 快手、抖音 | 减少竞品使用时间 |
内容互动 | 用户对内容的情感 | AB站 | 用户粘性 |
社区/社交类模块类模块关心的指标
描述了什么 | 举个例子 | 做好了就能怎样 | |
发布量 | 用户创作内容的数量 | 贴吧、FB | 更多的话题源头 |
互动量 | 用户与用户间互动的次数 | 微博 | 社区更具活力 |
关系密度 | 用户与用户间的关系 | 微信 | 更有可能长期留存 |
选择数据工具的核心逻辑:业务问题
1、根据公司业务/发展阶段选用数据工具的方法
2、从(解决特定问题)的视角,快速上手/掌握数据工具
根据业务中的核心需求,匹配适当的分析套路,选用适当的数据工具
数据工具能解决什么问题?
计数、流量、内容、用户、业务
如何选择适当的数据工具
根据业务核心划分
根据公司阶段划分
公司不同阶段关注的业务重点不同,需不同的数据工具
探索期 | 成长期 | 成熟期 | 衰退期 | |
业务问题 | 刚起步不完善,流程未定型,常变动 | 追求增长,同时补前期债务 | 稳定,没有新的突破点 | 用户对产品渐渐失去兴趣,开始流失 |
待解决需求 | 验证:业务是否可行/需求是否存在 | 寻找用户量和业务量规模化增长的方法 | 业务流程理得更顺,用户群体拆得更细 | 延长产品生命周期,尽力挖掘用户剩余价值及可能的新需求 |
所需的数据工具 | 计数 | 流量、内容、用户、业务导向 | 用户、业务导向 | 用户导向 |
流量向导的工具(GA)
解决的问题:
谁来了
从哪来
来了干什么
有没有达成目标
内容导向的工具(百度统计)
解决问题:
哪些资源被消费
被消费的情况如何
内容表现质量如何
用户导向的工具(Mixpanel)
解决的问题
用户来了干什么
用户还会不会再来
用户在哪流失了
用户都是啥样的
业务导向的工具(神策)
解决的问题
流程是否顺畅
规模/频次如何
异常原因何在
计数 | 流量 | 内容 | 用户 | 业务 | |
关键 | 快速验证 | 渠道依赖 | 内容质量 | 用户为王 | 商业本质 |
特点 | 简单、快 | 能将流量入口分析得较为细致 | 能从内容的视角描述其表现 | 从用户视角描述单个用户的行为轨迹 | 从商业逻辑上还原整个业务流程,可介入线上线下数据 |
常见应用场景 | 单纯计数和固定报表 | 流量依赖性业务,如电商,或者一锤子买卖 | 以内容为核心资源的,如媒体、视频网站 | 在乎用户长期价值,企业核心资产是用户 | 业务逻辑复杂,需要跟踪周期长 |
数据分析的价值
9种数据分析方法
1、对比分析
事出反常必有妖,没有对比就没有好坏
比什么:
绝对值:本身具备(价值)的数字
销售金额、阅读数
不易得知问题的严重程度
比例值:在具体环境中看比例才具备对比价值
活跃占比、注册转化率
易受到极端值影响
怎么比:
环比:last period
与当前时间范围相邻的上一个时间范围对比
如:今天昨天、这周上周
对短期内具备连续性的数据进行分析
需要根据相邻时间范围的数字对当前时间范围的指标进行设定
同比:same period/last year month day..
与当前时间范围上层时间范围的前一范围中同样位置数据对比
如:八月7号和九月7号
观察更为长期的数据集
观察的时间周期里有较多干扰,希望某种程度上消除这些干扰
和谁比:
和自己比
从时间维度
从不同业务线
从过往经验估计
和行业比
是自身因素,还是行业趋势
都跌,能否比同行跌得少?
都涨,是否比同行涨得慢?
2、多维度拆解
运作原理:
指标/业务流程需要按照多维度拆分,来观察变动
数据分析的本质就是用不同的视角去拆分、观察同一个数据指标
对业务流程,拆解维度
适用场景:
分析单一指标的构成、比例
分栏目的播放量
新老用户比列
针对流程进行拆解分析
不同渠道的浏览、购买转化率
不同省份的活动参与漏斗
还原行为发生时的场景
打赏主播的等级、性别、频道
是否在WIFI或4G环境下
案例:数据涨跌异动如何处理
1)搞明白每一次涨跌
跌:采取动作,减缓趋势
涨:弄清原因,并放大
发现异常-确定问题-确定原因-针对性解决问题-执行
2)数据只是验证支撑工具,首先需要你有一个假设
常见的假设
活动影响:
查对应活动页面及对应动作的数据波动,关注活动是否有地域属性
版本发布:
将版本号作为维度,区分查看
渠道投放:
查看渠道来源变化
策略调整:
策略上线时间节点,区分前后关键指标波动
服务故障:
明确时间,按时间为维度进行小时或者分钟级别的拆分
维度拆解分析是可以叠加的
3、漏斗观察
漏斗=一连串向后影响的用户行为
建立漏斗时容易掉的坑:
坑1:漏斗一定是有时间窗口的
根据业务实际情况,选择对应的时间窗口
按天:对用户心智的影响只在短期内有效(如短期活动)
按周:业务本身复杂/决策成本高/多日才能完成(如理财/美股开户)
按月:决策周期更长(如装修买房)
太长,包进了太多无关的信息;太短,扔掉了很多有用的信息。
坑2:漏斗一定是有严格顺序的
坑3:漏斗的计数单位可以基于(用户)、也可以基于(事件)
往往基于用户
关心整个业务流程的推动
也可以基于事件
关心某一步的转化率
无法获知事件流转的真实情况
坑4:结果指标的数据不符合预期
自查:是否只有这一个漏斗能够到达最终目标?
适用场景:
适用:有明确的业务流程和业务目标
不适用:没有明确的流程、跳转关系纷繁复杂业务
案例:如何评估渠道质量去顶投放优先级
1)常见的渠道划分方式
来源:具体流量实体
百度、头条、线下
媒介:实体中承载推广的实体
SEM、自然搜索结果、Bannner
其他参数:
营销活动名称
广告关键词
2)渠道质量跟踪
选择关键事件
选取反映你产品目标人群会做的行为的数据
电商购买、社区发帖(可衡量各渠道的用户是否为目标用户)
完成为其三个月的课程(门槛太高/流程太深,转化率极低,无区分度)
打开APP/访问首页(门槛太低,同样缺乏区分地)
查看产生关键事件的用户来源是哪
4、分布情况
一个时间不仅只有累计数量这么一个可以观察的指标。
还可以从该事件在不同维度中的分布来观察。
常见的群体划分:
事件频率
一天内的时间分布
消费金额的区间
适用场景:
已经知道一群用户完成了指定事件,但需要对用户群体进行细分,按不同的维度和价值将他们划为不同群体,分别进行后续的维护或分析。
已经知道单个事件的完成次数,希望知道这些次数拆分到不同维度上后的分布情况,以便更清晰地了解该事件的完成情况。
5、用户留存
为什么要看留存?
了解某一个渠道的质量-日留存
观察整个大盘-周留存/月留存
适用场景:
验证产品长期价值
留存:
一般的计算方式
将某一时间段的用户ID与另一时间段的用户ID做交叉去重
产品、运营、技术、市场每个环节都会对留存造成影响
精准留存
过滤进行过指定行为的用户ID,再计算
将用户分为不同的群体后,观察其之间留存的区别
案例:功能/内容上线后,如何评估其短期效果/长期价值/未来潜力
一个功能/内容上线后,如何评估其价值?
上线后的目标与价值清晰明确:
借助漏斗分析对比(转化关系明确时)
借助用户分群对比(转化关系较复杂时)
上线后关注其对产品价值的提升:
借助精准留存对比
上线以探索更长期的产品潜力:
借助分布情况分析,对比其是否优化了
产品核心功能使用频次的分布
使用场景(如时间段)的分布
一个功能/内容上线后,如何评估其对产品长期潜力的价值?
从对使用情况的促进作用来观察
从占据用户一日时间段的角度来看观察
6、用户画像
通过对用户各类特征进行标识,给用户贴上各类标签,通过这些标签将用户分为不同的群体,以便对不同的群体分别进行产品/运营动作
标签都有啥?
基础属性:年龄、性别、生日、星座、教育、身高、收入、职业...
社会关系:婚姻、有无小孩、有无女孩、家有老人、性取向...
行为特征:
基本行为-注册时间、来源渠道...
业务行为-买过特惠商品、曾获优秀学员...
业务相关:胖瘦高矮、体脂率、在练胸、日均8000步、收藏100+份健身计划...
标签从哪儿来?
直接填写:
通过用户自己的已有特征推得:
做活动
简单的个性化运营
业务分析
用户研究(准备)
通过用户身边的人推断:
距离相近-某些属性,周边的人都具备,用户大概率也具备
行为相识-通过协同过来,找到行为相识的目标用户
适用场景:
市场营销、个性化运营、业务分析、用户研究...
案例:如何了解数字背后的用户
高质量拉新
从现有用户中找到我们真正的用户
真正的用户:高留存、核心行为频次、完成率高
找到特征:是谁、从哪儿来
按此特征,找到类似的用户:用户画像、渠道来源(用人拉人而非广撒网地投放)
精准运营推送
辅助产品设计
7、归因查找
找出事件发生的主要原因
归因查找的适用场景:
对业务中明确的业务目标(购买、留资料、充值等)归因,便可...
将目标的达成拆分到各个模块,方便统计各模块的贡献
获悉当前指标达成的主要因素,获得如何提升业务指标的洞见
运作原理:
将事件拆解,并根据业务性质,确定影响时间完成的关键部分
末次归因-转化路径短,且事件间关联性强的场景
递减归因-转化路径长,非目标事件差异不大,没有完全主导的
首次归因-强流量依赖的业务场景,拉人比后续所有事都重要
案例:精准运营推送
精准运营
1、运营资源盘活:
不同人在同一个运营资源位上得到不同的信息
需要在千人一面和千人千面之间找到ROI的平衡
常规做法-出台一套运营资源适用规则
如:一天最多只能推3条;同一个类型的营销在一周/月内不得重复推送;...
问题:整个公司的内部营销资源存在上线
推荐做法-精细化的用户分群运营
既能提升整个公司的可用资源,也能提升收到推送的用户自己的体验
千人?面
理想:每个标签都去做不同的推送内容
现实:在ROI上找到一个平衡点,先选择容易出成绩的
如:
容易出成绩的标签-电商的性别标签
容易出成绩的运营位-首页/每日推送
千人十面往往就已经解决了80%的问题,7~8个标签往往足矣
如何选择最初的七八个标签?
人口统计学意义上的标签,如性别(电商)、年龄或者地域(健身)
业务相关的标签,年纪(教育)、BMI(健身)
2、推送内容与用户有关:
基于用户真实的动作,调整推送内容
使其感到推送是因我而来(而非自己是被批量推送的分母之一)
向我说话-利用用户之前留下的信息,在推送文案中适用对应名称
由我触发-通过挖掘用户的行为序列,将推送与你的某个行为挂钩
和我有关-这次推送的活动,真正和我的需求有关
8、路径挖掘
行为事件
流入、流出
运作原理:
逐级展开某一事件的前一级(后一级)事件,观察其流向
适用场景:
有明确的起始场景,希望观察这个场景它之后发生了什么
有明确的结果目标,希望观察来的用户是如何到达的
9、行为序列
路径挖掘的局限
运作原理:
将单一用户的所有行为以时间线的形式进行排列
适用场景:
观察掩盖在统计信息下更细致的信息,还原用户具体的使用场景
通过观察具体的行为特征,找到提升产品价值的机会点
案例:评估用户对产品的兴趣和依赖程度
案例:辅助产品设计
辅助产品设计决策
谁:用户画像
在什么情况下:行为序列的属性
干什么&遇到什么问题:行为序列or屏幕录像
不要套数据!如有更直接的方式get用户场景,大胆去用
案例:羊毛党盛行,如何查出谁在薅
抓作弊的方法:
找到1-找到模式-找到N-一网打尽
找到成规模的spamer
找到1:
发现数据异常-异常高且无理由的流量、工作人员观察、人工举报
找到模式:
明确其目的-刷量、薅羊毛、spam(垃圾广告)
观察其特征-机刷、人肉刷
多:显著与普通用户相异的动作,如通过商家变现、发布特定内容等
少:留存低、非核心业务(如帮助界面)几乎不访问
找到N:
RD爬取并人工审核
一网打尽:
封-封禁/封禁权限/屏蔽/定向屏蔽/...
提高关键成本
前:注册7日后方可发帖
中:减少存在BUG的商品的库存
后:提高提现的审核力度/周期
不做处理
真正懂数据的人,一定会走到自己做数据采集这一步
1、数据埋点
埋点的困境
困境一:自己理不清
要杀数据
有啥属性
困境二:RD听不懂
前端采集or后端采集?
跨越前-后端取值?
Data Requirements Document
数据需求文档(DRD)
埋点需求
埋点实施过程中的细节
2、明确埋点需求
归纳需求
产品自身的指标建模
业务部门的分析需求
需求-指标-埋点
选择适当的埋点属性
依据经验,预先按分析维度设计属性:
较为依赖分析经验
平凡添加埋点,则需要RD密切配合
根据套路,预先设计埋点属性:
who when where how what
某个用户在某个时间点、某个地方以某种方式完成了某个具体的事情
活用属性(公共属性和事件聚类)
who
认设备
web:cookie
ios:uuid、idfv、idfa
androdi:uuid、android id
认人
线上:uid、微信等第三方union id/open id、手机号、身份证
线下:手机号、身份证
when
问题一:哪个节点的时间
事件发生、事件上报、事件接收、事件入库
问题二:哪个时区的时间
上报时间带时区
使用Unix时间戳
where
GPS-往往还需通过API取得详细地址信息(国家/省/市/街道)
IP-统一分配给运营商,相对比较粗略,可通过三方反查所属地
自主填写-相比用户真实位置,更关心用户希望在哪儿(如:装修买房)
how
用的什么设备
装的哪个版本
操作系统是什么
用的哪个浏览器
现在是4G还是wifi
从哪个页面跳过来
what
购买-商品名称、商品类型、购买数量、都买金额、付款方式
搜索-搜索关键词、搜索类型
用户注册-注册渠道、注册邀请码
用户投诉-投诉内容、投诉对象、投诉渠道、投诉方式
申请退货-退货金额、退货原因、退货方式
公共属性(统一取值、维护)
3、形成需求文档
埋点位置的选择:
除非某个行为只在前端发生(如:美颜自拍,拍照时选了哪些滤镜),否则,建议永远在后端采集
前端埋点的弊端:
某些属性前端没有
where/what/how的许多信息,往往只存在于后端
改动依赖产品发版
appstore需审核、web发版也有排期,响应速度不如后端
时间上报时机略尴尬
需要在省流量/省电和及时性之间取舍
埋点属性来源:
前端-调用API、取页面上的值、行为统计
后端-业务数据、查关联表、前端送来的数据、技术数据
埋点有效性的校验:
手段-抓包、看数据平台是否显示对应时间
方法-与DRD“逐个”对比,校验是否符合预期
意义-数据不具备回溯性,信息损失了,后续再也补不回来
埋点文档的维护:
是否在线、上线时间、下线时间、修改备注
4、其他类型的数据采集方法
全埋点/无埋点:
把所有的浏览和点击行为都记录下来
适用场景:
分析需求简单(只需要统计PV和点击)
开发限制因素多(临时活动,没有时间/资源部署埋点)
业务流程简单(不涉及更多信息,只需要点击、跳转)
技巧-可通过将本来能在一页完成的流程拆为多页,实现采集
限制:
非浏览和点击时间无法采集,无法采集到what/how类的信息
跨越物理界限,实现数据采集:
线下(/第三方系统)数据收集:
电商-物流信息/客服跟进情况
教育-到课率/线下招生收集到的客户/用户信息
金融-地推、短信发送的用户(与新注册用户对比,验证推广效果)
竞品数据采集:
明确采集目的