运营数据分析
2020-04-07 14:12:20 10 举报AI智能生成
登录查看完整内容
干货：如何对运营数据进行分析？
作者其他创作
大纲/内容
指标建模
数据指标定义
对当前业务有参考价值的统计数据（一定要与业务相关有参考价值、数据可统计）
常用的数据指标
谁 干了什么 结果怎么样？
用户数据
存量（DAU/MAU）
理解daily/monthly
理解Active
数据统计系统的定义
基于事件上报：有事件上报→该用户活跃
业务上的定义
基于关键事件上报：用户执行某个关键事件→该用户活跃
理解user
认人
给每位注册用户一个唯一的专属ID只适合强注册/登陆环境，未登陆的用户被漏掉
认设备
每台设备一串唯一标识符（在网页cookie仲埋下一段长随机字符串，作为设备唯一标识符用户数=访问过服务的设备数 ）
认人还是认设备？
1.是否有账号体系（no-认设备）
2.业务场景是否强依赖登陆（yes-认人+认设备）
3.不登录的用户对业务是否有价值（no-认人+认设备 yes-认设备）
增量（新增用户）
新增的定义
点击渠道页面（量级不大/免费渠道/不需要做精细结算）
下载（渠道依赖应用商店且没有更好渠道）
安装/启动（自己较强势，可给渠道指定统计规则）
激活（对用户质量要求很高且产品ARPU高）
判别新
基于设备（ios、android、web）
基于账号关联（与后台已有账号比对匹配）
健康程度（留存率）
留存意义
了解某一个渠道的质量
日留存：以日为单位，衡量这个渠道来的用户当下&接下来的表现
算法一：第七天 /第一天*100% （7日日留存）
只关心到特定日的留存情况，避免了其他日数据的干扰
算法二：（第二天-第七天去重后）/第一天100% （7日内留存）
引入了其他日数据，适用于有固定使用周期，且周期较长的业务
算法三：第七天/第0天*100% （7日日留存，新增当天为0天）
使第7日语新增当日对齐，试图抵消某些星期级别的周期性差异
观察整个大盘
以周/月为单位，衡量产品的健康情况，观察用户在平台上的粘性务必去重
算法：第二个月的登陆用户数/上个月的登陆用户数*100%
从哪儿来（渠道来源）
行为数据
次数/频率（PV/UV/访问深度）
PV
page views页面浏览量（次数）
PV转化率
表示页面引发某行为的能力
UV
unique visitors 独立访客数（人数）
UV转化率
表示用户某行为的倾向
访问深度
用户对产品的了解程度
算法一：用户对某些关键行为的访问次数
算法二：将网站内容/功能分成几个层级，以用户本次访问过最深的一级计算
访问时长
通过统计特殊事件，支持业务需求（统计视频被消费程度，评价内容质量）
路径走通次数（转化率）
质量（弹出率）
所有用户在完整的网站中，只访问一个页面的占比/单个用户弹出率
业务数据
总量（GMV/访问时长）
直接付费
使用场景
总量
解决什么问题
交易的金额总规模
非直接付费
目标完成数（报名、点击、分享）
人均（ARPU/ARPPU 人均访问时长）
人均
单个用户的贡献程度/单个付费用户的贡献程度
人均访问时长
人数（付费人数/播放人数）
人数
描述愿意为服务付费的人数总规模
完成人数
健康程度（付费率、付费频次 观看率）
健康程度
描述总体上用户付费意愿评判一个服务的健康程度
完成率
被消费对象（SKU视角 被消费内容视角）
被消费对象
需要分析消费品本身的运营情况
被消费内容视角
如何选好数据指标？
1.从业务的最终目的触发梳理业务模块（目的-手段-支撑手段的工具/支撑手段的手段）
2.判断业务模块所属类型（工具类模块、交易类模块、内容浏览类模块、社区类模块）
工具类模块关心的指标
交易类模块关心的指标
内容浏览类模块关心的指标
社区社交类模块关心的指标
3.根据业务模块所属类型选择数据指标（还原业务全貌，是否能用指标来描述公司业务进展）
数据工具
核心逻辑
根据业务问题中的核心需求，匹配适当的分析套路，选用适当的数据工具
如何选择合适的数据工具？
业务核心划分
公司缺了啥，最要命？
计数导向工具
原理
通过脚本与代码统计日志
通过BI工具进行基本分析（解决计数问题，快捷，简单）metabase
流量导向工具
研究问题
谁来了？
从哪来的？
来了干什么？
有没有达成目标？
解决的问题
流量依赖性业务，如电商，或者一锤子买卖
优势
能将流量入口分析得较为细致
内容导向工具
哪些资源被消费了
被消费的情况如何
内容表现质量如何
以内容为核心资源的，如媒体、视频网站
用户导向工具
研究问题
用户来了干什么？
用户还会不会再来？
用户在哪流失了？
用户都是啥样的？
需要关注隐藏在报表、总量下面的，用户具体的行为
从用户视角描述单个用户的行为轨迹
业务导向工具
流程是否顺畅？
规模/频次如何？
异常原因何在？
业务逻辑复杂，需要跟踪周期长
从商业逻辑上去还原整个业务流程，可接入线上-线下
不同类型数据工具特点
根据公司阶段划分
数据处理
excel工具
VLOOKUP函数
vlookup（查找项值，查找列序号，查找列数量，精确匹配）
Rawgraphs可视化展示数据
Circle packing
beeswarm plot
横轴时间变化，竖轴订单，面积订单类别
高德地图API
地理位置可视化
google analyse
GA邮件日报
指标预警（设置-自定义提醒）
数据注释
自定义指标（注册转化率）
访客属性
数据分析基础
9种数据分析方法
对比分析
事出反常必有妖没有对比就没有好坏
比什么？
绝对值
本身具备价值的数字
销售金额或阅读数（不易得知问题的严重程度）
比例值
在具体环境中看比例才具备对比价值
活跃占比或注册转化率（易收到极端值影响）
怎么比？
环比
与当前时间范围相邻的上一个时间范围对比（日环比：今天vs昨天 月环比：本月vs上月）对短期内具备连续性的数据进行分析，需要根据相邻时间范围的数字对当前时间范围的指标进行设定
同比
与当前时间范围上层时间范围的前一范围中同样位置数据对比（年同比：今天vs去年今天 周同比：今天vs上周同日）观察更为长期的数据集，观察的时间周期里有较多干扰，希望某程度上消除这些干扰
和谁比？
和自己比
从时间维度
不同业务线
从过往经验估计
和行业比
是自身因素，还是行业趋势
都跌，能否比同行跌得少
都涨，是否比同行涨得多
多维度拆解
运作原理
指标/业务流程需要按照多维度拆分，来观察变动
拆解分析方法
分析单一指标的构成
eg分栏目的播放量
eg新老用户比例
针对流程进行拆解分析
eg不同渠道的浏览、购买转化率
eg不同省份参与漏斗
还原行为发生时的场景
eg打赏主播的等级、性别、频道
eg是否在wifi或者4g环境下
适用场景
需要分析单一指标的构成、比例时
需要针对流程进行拆解分析
需要还原行为发生时的场景
案例：数据涨跌异动处理
处理步骤
发现异常--确定问题--确定原因--针对性解决问题--执行
原则
数据只是验证支撑工具首先需要你有一个假设
活动影响
查对应活动页面及对应动作的数据波动，关注活动是否有地域属性
版本发布
将版本号作为维度，区分查看
渠道投放
查看渠道来源变化
策略调整
策略上线时间节点，区分前后关键指标波动
服务故障
明确故障时间，按时间为维度进行小时或分钟级别的拆分
漏斗观察
漏斗定义
一连串向后影响的用户行为
新用户充值数的转化漏斗
安装-注册-阅读产品说明-选择产品-支付
建立漏斗时容易掉的坑
【坑1】漏斗一定是有时间窗口的
根据业务实际情况，选择对应的时间窗口
按天
对用户心智的影响只有在短期内有效（如短期活动）
按周
业务本身复杂/决策成本高/多日才能完成（如理财/美股开户）
按月
决策周期更长（如装修买房）
【坑2】漏斗一定是有严格的顺序的
【坑3】漏斗的计数单位可以试基于用户，也可以基于事件
往往基于用户
关心整个业务流程的流动
基于事件
关心某一步具体的转化率无法获知事件流转的真实情况
【坑4】结果指标的数据不符合预期
自查：是否只有一个漏斗能够到达最终目标
通过一连串向后影响用户行为来观察目标
适用：有明确的业务流程和业务目标
不适用：没有明确的流程，跳转关系纷繁复杂的业务
案例：如何评估渠道质量，确定投放优先级
渠道划分方式
来源（source）
具体的流量实体，百度、头条、线下…
媒介（medium）
实体中承载推广的实体，SEM、自然搜索结果、Banner…
其他参数
营销活动名称、广告关键词…
渠道质量跟踪
1.选择关键事件
选取反映你产品目标人群会做的行为的数据
eg（电商）购买、（社区）发帖（可衡量各渠道来的用户是否为目标用户）
完成为期三个月的课程（门槛太高/流程太深，转化率极低，无区分度）
打开APP/访问首页（门槛太低，同样缺乏区分度）
2.查看产生关键事件的用户来源是哪
分布情况
定义
一个事件不仅只有累计数量这么一个指标可以观察的指标还可以从该事件在不同维度中的分布来观察
常见的群体划分
事件频率
一天内的时间分布
消费金额的区间
从事件在不同维度中的分布来观察以便理解该事件除了累计数量和频次外，更多维度的信息
已知道一群用户完成了指定事件，但需要对用户群体进行细分，按不同的维度和价值将他们划分为不同群体，分别进行后续的维护或分析。
已知道单个事件的完成次数，希望知道这些次数拆分到不同维度上后的分布情况，以便更清晰地了解该事件的完成情况
用户留存分析方法
一般的计算方式
将某一时间段的用户ID与另一时间段的用户ID做交叉去重
产品、运营、技术、市场每个环节都会对留存造成影响
大盘留存
将某时间段与另一时间段的用户ID交叉去重
精准留存
过滤进行过指定行为的用户ID，再计算
将用户分为不同的群体后，观察其之间留存的区别
评估产品粘性
验证产品长期价值
案例：功能/内容上线后，如何评估其短期效果/长期价值/未来潜力
上线后的目标与价值清晰明确
借助漏斗分析对比（转化关系明确时）
借助用户分群对比（转化关系较复杂时）
上线后关注其对产品价值的提升
借助精准留存对比
上线以探索更长期的产品潜力
借助分布情况分析后，对比其是否优化了…
产品核心功能使用频次的分布
使用场景（如时间段）的分布
数据分析进阶
用户画像
Profile用户档案
来自用户产生的真实的数据、行为特征、主动填写资料（偏数据统计调查系统）用在产品推广运营、产品设计等
Persona用户画像
来自用户访谈、研究（偏抽象），感性认识用户是什么样的人
用途
通过对用户各类特征进行标识，给用户贴上各类标签，通过这些标签将用户分为不同的群体，以便对不同的群体分别进行产品/运营动作
市场营销/个性化运营/业务研究/用户研究
标签都有哪些？
基础属性
年龄、性别、生日、星座、教育、身高、收入、职业…
社会关系
婚姻、有无小孩、女孩、老人、性取向
行为特征
基本行为
注册时间、来源渠道、是否购买行为、购买次数、金额
业务行为
买过特惠商品、曾获优秀学员
业务相关
胖瘦高矮、体脂率、在练胸、日均8000步、收藏n份健身计划
标签从哪里来？
直接填写
间接填写
收货地址/计算工具
通过用户自己的已有特征推导
做活动 简单的个性化运营 业务分析 用户研究
通过用户身边的人推断
距离相近
某些属性，周围的人都具备，用户大概率也具备
行为相似
通过协同过滤，找到行为相似的目标用户
案例：如何高质量拉新
步骤
从现有用户中找到我们真正的用户--找到真正的用户的特征--按此特征找到类似的用户
定义真正的用户
高留存/核心行为频次/高完成率
找到真正的用户的特征
从哪儿来
从哪儿来eg通过电话访谈等方式，发现很多来自朋友推荐
eg通过他们买卖的书籍，倒推他们的年龄/受教育成都/地域/消费能力
找类似用户
高校/科研院所/知识密集型工作区域/消费倾向社科类书籍
渠道来源
用人拉人而非广撒网地投放
归因查找
找出事情发生的主要原因
对业务中明确的业务目标（购买/留资料/充值等）归因
将目标的达成拆分到各个模块，方便统计各模块的贡献
获悉当前指标达成的主要因素，获得如何提升业务指标的洞见
方法
末次归因
转化路径短，且事件间关联性强的场景
s1--s2--s3--...--s（n-2）--s（n-1）-sN
递减归因
转化路径长，非目标事件差异不大，没有完全主导的
s1--s2--s3--...--s（N-2）--s（N-1）-sn
首次归因
强流量依赖的业务场景，拉人比后续所有事都重要
S1--s2--s3--...--s（n-2）--s（n-1）-sn
将事件拆解，并根据业务性质，确定影响事件的关键部分（首次归因/递减归因/末次归因）
将目标的达成拆分到各个模块，方便统计各个模块的贡献
案例：如何进行精准运营推送
运营资源盘活
不同人在同一个运营资源上得到不同的信息需要在千人一面和千人千面之间找到roi的平衡
常规做法
出台一套运营资源适用规则
eg一天最多只能推3条，同一个类型的营销在一周/月内不得重复推送
推荐做法
精细化的用户分群运营
既能提升整个公司的可用资源也能提升收到推送的用户自己的体验
千人n面
理想
每个标签都去左不同的推送内容
现实
在roi上找到一个平衡点，先选择容易出成绩的
容易出成绩的标签：如电商的性别标签
容易出成绩的运营位：如 首页/每日推送
千人十面往往就已经解决80%问题，7-8个标签足够
人口统计学上的标签
如性别/年龄或地域 eg电商中 性别影响商品偏好eg k12教育影响教育水平/教材选择/考察的侧重点
业务相关的标签
eg k12教育 年级影响所学内容/关注的信息 eg健身 bmi影响用户对功能和内容上的诉求
推送内容与用户有关
基于用户真实的动作，调整推送内容使其感到推送是因我而来（而非自己是被批量推送的分母）
向我说话
利用用户之前留下的信息，在推送文案中使用对应名称
由我触发
通过挖掘用户的行为序列，将推送与你的某个行为挂钩
和我有关
次推送的活动，真正和我的需求有关
路径挖掘
逐级展开某一事件的前一级（后一级）事件，观察其流向
有明确的起始场景，希望观察整个场景它之后发生了什么
有明确的结果目标，希望观察来的用户是如何到达的
行为序列
将单一用户的所有行为以时间线的形式进行排列
观察掩盖在统计信息下更细致的信息，还原用户具体的使用场景通过观察具体的行为特征，找到提升产品价值的机会点
作用
辅助产品设计
谁
在什么情况下
行为序列的属性
干什么&遇到什么问题
行为序列or屏幕录像
案例：如何判断羊毛党
抓作弊的方法
找到1-找到模式-找到N-一网打尽
找到1
发现数据异常（异常高且无理由的流量、工作人员观察、人工举报）
找到模式
明确其目的（刷量、薅羊毛、spam垃圾广告）
观察其特征（机刷、人肉刷）
多：显著与普通用户相异的动作，如通过商家变现，发布特定内容等少：留存低、非核心业务（如帮助界面）几乎不访问
找到N
RD爬取并人工审核
一网打尽
封：封禁/封禁权限/屏蔽/定向屏蔽/…
提高关键成本
前：注册7日后方可发帖中：减少存在bug的商品库存后：提高提现的审核力度/周期
数据采集
数据需求文档（DRD）
埋点需求
埋点实施过程中的细节
埋点的困境
困境一：自己理不清
要啥数据
有啥属性
困境二：RD听不懂
前端采集or后端采集
跨越前-后端取值？
选择适当的埋点属性
依据经验，预先按分析维度设计属性
较为依赖分析经验
频繁添加埋点，则需要RD密切配合
根据套路，预先设计埋点属性（WWWHW）
某个用户在某个时间点、某个地方以某种方式完成了某个具体事情活用属性（公共属性和事件聚类）
Who
Web：cookieios：uuid、idfv、idfa
Android：uuid、android id
线上：UID、微信等第三方union ID/open id、手机号、身份证
线下：手机号、身份证
When
问题一：哪个节点的时间
事件发生-事件上报-事件接受-事件入库
问题二：哪个时区的时间
上报时间时，带时区
使用unix时间戳
Where
GPS（往往还需要通过API取得详细地址信息）
IP（统一分配给运营商，相对比较粗略，可通过三方反查所属地）
自主填写（相比用户真实位置，更关心用户希望在哪儿）
How
用什么设备
装的哪个版本
操作系统是什么
用的哪个浏览器
现在用4G还是wifi
从哪个页面跳过来的
What
购买：商品名称、商品类型、购买数量、购买金额、付款方式
搜索：搜索关键词、搜索类型
用户注册：注册渠道、注册邀请码
用户投诉：投诉内容、投诉对象、投诉渠道、投诉方式
申请退货：退货金额、退货原因、退货方式
读取公共属性（统一取值、维护）
事件聚类（添加属性position）
形成需求文档
埋点选择
除非某个行为只在前端发生，否则，建议永远在后端采集
前端埋点的弊端
某些属性前端没有（where/what/how）的许多信息，往往只存在于后端
改动依赖产品发版Appstore需审核、web发版也有排期，响应速度不如后端
事件上报时机略尴尬需要在省流量/电和及时性之间取舍
埋点属性来源
前端
调用API取页面上的值行为统计（eg前台timer、自行触发&记录页面时长）
后端
业务数据查关联表前端送来的数据技术数据（eg单次事件响应时间）
埋点有效性的检验
手段
抓包、看数据平台是否显示对应事件
与DRD逐个对比，核验是否符合预期
意义
数据不具备回溯性，信息损失了，后续再也补不回来
其他类型的数据采集方法
全埋点/无埋点
分析需求简单（只需要统计PV和点击）
业务流程简单（不涉及更多消息，只需要点击、跳转）
技巧
可通过将本来能一页完成的流程拆为多页，实现采集
限制
费流量和点击事件无法采集，无法采集到what/how类的信息
跨越物理界限
线下（/第三方系统）数据收集
电商：物流信息、客服跟进情况
教育：到课率、线下招生收集到的客户/用户信息
金融：地推、短信发送的用户（与新注册用户对比，验证推广效果）
竞品数据采集
运营数据分析
0 条评论
回复 删除
下一页
