运营常用数据指标分析方法分享
2022-10-13 14:52:33 1 举报
AI智能生成
登录查看完整内容
运营常用数据指标分析方法分享
作者其他创作
大纲/内容
不是所有的数据都叫指标
与当前业务无关的,也意义不大
当前业务
有价值
数据不是凭空产生的,不能脱离现实
可统计
key word
对 <b>当前业务 </b>有参考 <b>价值 </b>的 <b>统计数据</b>
什么是数据指标?
一自然日
注意:跨时区(如全球服务),则关心最近24小时
DAU(日活)
当月至少活跃一次的用户总数
注意:MAU不等于当月各日DAU之和,务必去重,才有观察的意义
MAU(月活)
基于事件上报:有事件上报 → 该用户活跃
预制报表的统计系统(友盟、百度统计、GA等)都是基于<b>事件上报</b>进行统计
注意:上报一事中假定了事件上报一定来自用户主动操作,实际情况可能会有偏差(统计了不需要用户主动操作在后台就能自动发生的事件(例如推送等))
用户访问的是一个网页 → 页面加载成功 → 上报Page View事件
在APP页面里有个确认按钮 → 点击按钮 → 上报onclick事件
例子
方法一:数据统计系统的定义
用户执行了关键事件 → 这个用户是活跃的
一开始采用的是访问首页 → 上报 → 统计日活
从业务分析上来看这样统计的日活和想象中的日活有差距
后来发现产品上有个路径是这样的:用户收到推送 → 点击推送 → 直接到达了详情页
用户在此路径上没有访问首页,自然也没有上报访问首页的行为,也就是说该用户并没有被统计进日活里面
后来解决方法,建立了日活事件列表,把关键业务路径加入到列表中
统计日活出现偏差
需不断维护日活事件列表
维护成本
团队内外对活跃的认识需统一
沟通成本
存在额外成本
关键事件
方法二:业务上的定义
理解Active
原来认知中,用户是直接访问你的服务
实际情况下,用户是通过设备去访问你的服务的(会存在着一个人有多台设备或者多个人使用同一台设备的情况)
认知
给每位注册用户分配一个唯一的专属ID
用户数 = 访问过服务的ID数
注意:只适合强注册/强登录环境,未登录的用户会被漏掉
认人
在网页cookie中埋下一段长随机字符串,作为设备唯一标识符
用户数 = 访问过服务的设备数
注意:此方法无法对应设备背后的用户
认设备
两种操作方式
NO → 认设备
是否有账号体系
Yes → 认人 + 认设备(为什么来了不登录?与日活分开统计)
业务场景是否<b>强依赖登录</b>(不登录没法用)
Yes → 认设备(例如:小说APP,不登录也能看小说,看小说的行为毫无疑问对小说来说是有价值的)
NO → 认人 + 认设备(仅作为描述没有登录的设备数)
不登录的用户对业务是否有价值
认人 or 认设备
理解User
存量
每个人都在提新增,每个人嘴里讲的新增其实都不一样
常见渠道新增流程
统计简单
优势
离激活环节最远,转化率太差
劣势
量级不大/免费渠道
不需要做精细结算
适用场景
点击渠道链接
真正反映了用户的实际意愿
数据源可信度存疑,无法避免刷量
渠道依赖应用商店且没有更好的渠道
下载
离激活最近,便于统计
渠道不一定配合,仍然无法避免刷量
自己较强势,可给渠道制定统计规则
安装/启动
最真实的数据
渠道费用激增,统计复杂
对用户质量要求很高且产品ARPU高
激活
问题一:选择合适的节点,定义增(渠道商往往强势,哪个节点算钱应该先谈清楚)
IOS、Andriod、Web各有门道,不具体展开
基于设备
与后台已有账号比对匹配
基于账号关联
问题二:用适当的方法,判别新
新增用户
增量
七日日留存:只关心到特定日的留存情况,避免其他日数据的干扰
七日内留存:引入了其他日数据,适合于有固定使用周期,且周期较长的业务
七日日留存:新增当日为第0日,下一日为第1日,使第7日与新增当日对齐,试图抵消某些星期级别的周期性差异
三种算法
以天为单位,衡量这个渠道来的用户当下&接下来的表现
以【X日日留存】作为比较标准时,可以避免其他日数据的干扰
了解某个渠道的质量——日留存
以周/月为单位,衡量产品的健康情况,观察用户在平台上的黏性
务必去重!!
观察整个大盘——周留存/月留存
为什么要看留存?
日留存算法
7日日留存
30日日留存
日留存 — 了解某个渠道的质量
周/月 留存算法
次周周留存
次月月留存
周留存/月留存 — 观察整个大盘
正确认识留存
留存率
健康程度
指的是用户直接访问网站,而不是从其它网站或搜索引擎进入
包括但不限于:用户在地址栏输入网址访问网站、从浏览器收藏夹访问、用户点击聊天工具里的链接如QQ聊天记录里的链接
直接访问
从用户非搜索引擎与社交网站点击链接进入网站
比如友链互惠网站、百度贴吧等站外社区论坛
引荐流量
从搜索引擎自然搜索结果链接进入网站的流量
自然流量
搜索引擎竞价,很多没有搜索引擎优化资源的网站,短平快的流量获取方式
付费流量
社交媒体
Email
展示广告
其他广告
其他
渠道来源
从哪儿来
谁(用户数据)
PV(浏览量)
UV(访问数)
用户对某些关键行为的访问次数
算法一
将网站内容/功能分成几个层级,以用户本次访问过最深的一级计算
算法二
访问深度
次数/频率
转化率
路径走通程度
页面打开时长(但如果我一直没关,或是上了个洗手间)
web时代
前台驻留时长(如果我收集放桌上没动)
APP时代
摄像头观察瞳孔是否注视屏幕(需要外设和隐私授权)
通过瞳孔与注意识别
如何统计访问时长
例子:统计视频被消费程度,评价内容质量,记录暂停/关闭页面后、播放器中视频进度条当前的位置
通过统计特殊时间,支持业务需求
需先想明白:为何统计访问时长
时长
做了多久
有一个网站,该网站只有一个页面—页面A,用户来了只能访问页面A而不可能发生别的事情,该页面的弹出率只可能是百分之百,用户并不可能产生别的行为,那么该网站的弹出率为百分之百
弹出率是定义用户来了立马就走了的行为
若该网站有两个页面,有的用户先访问页面A,有的用户先访问页面B,有的用户两个页面都访问了,只访问了一个页面就被弹走的用户分别为用户1、用户4、用户5,这个场景下弹出率为3/5*100% = 60%
基于用户来了就走,没有访问别的页面的行为,被弹出的用户有1、4、6,弹出率为50%
弹出率不是基于单个页面的,基于单个用户完整的访问里面包含了几次页面的访问
某个用户在一天之内访问了该网站五次,这五次中有四次都是来了就走的,我们就认为他这四次都是被弹走的,他今天的弹出率就是80%
弹出率的计算是基于单次访问(会话)的
弹出率
质量
干了什么(行为数据)
描述业务的总量
描述交易的金额总规模
解决什么问题
GMV(成交总额)
访问时长
总量
人均相关的
单个用户的贡献程度
人均付费(ARPU)/付费用户人均付费(ARPPU)
人均访问时长
人均
人数
描述愿意为服务付费的人数总规模
付费人数
完成人数
描述总体上的用户付费意愿评判一个服务的健康程度
付费率、付费频次
完成率
被消费对象
需要分析消费品本身的运营情况时
SKU视角
被消费内容视角
结果怎样(业务数据)
常用的数据指标有哪些?它们是怎么定义的?
1、数据指标——数据使用过程中的通用语言
目的
手段
来源
难点
支撑手段的工具
支撑手段的手段
解决
常见的拆解角度
就是把货卖给用户
通过文章来买货
社区创作
文章从哪来
用户使用手机创作文章很困难
为社区提供方便的创作工具,让用户在手机创作精美的图文来卖货
业务流程
卖货
获取广告收入
通过大量的资讯新闻获取广告收入
引入大量自媒体
资讯从哪来
自媒体不知道用户喜欢什么样的内容
通过大量自媒体资讯换取广告收入
帮助自媒体可以很方便的测试标题、图片怎样很好的吸引用户
提供高效的创作工具
获取学费收入
用户为了教学效果支付学费
若只给你一个教材,用户很难去学习
提供课程
提供便捷的学习系统
提供氛围良好的社群服务
希望用户付学费
案例
(1)、拆解业务模块
工具模块
内容浏览模块
交易模块
社区模块
四种模块
四个模块同时存在
便捷的学习系统(工具模块)、课程(内容浏览模块)、氛围良好的社群服务(社群社交模块)
1V1弹幕聊天(社交模块)、观看影片(内容浏览模块)
微光
(2)、判断模块类型
分支主题
四类业务模块
工具类模块关心的指标
MAC上的App Store
QQ音乐的歌词海报功能
内容浏览类模块关心的指标
微信的看一看模块
交易类模块关心的指标
知乎的Live(直播课程)详情页
社区/社交类模块关心的指标
脉脉的职言板块
各业务模块的关心指标
如何还原业务全貌,是否能用指标描述公司业务发展
核心
(3)、根据模块类型,选取数据指标
组合案例
三个步骤
梳理业务模块(从业务的最终目的出发) → 判断业务模块所属类型 → 选择数据指标(根据业务模块所属类型)
总体流程
我想获得用户
目标
搭建了产品矩阵,通过各种效率工具类产品来累积用户群,并寻求利益
行动
Clover 集团
想通过一个好用的汇率工具来获得用户
iMoney
工具
向别的产品导流
使用量
使用频次
好用
用户能长期留存,产品能向其他产品导流
获得用户
拆解
想承载C2C交易流量
分类
内容浏览
按“地理位置”或“兴趣”,方便交流交易
鱼塘
社区
买家
易用的快速发布工具
“鱼塘”用来分发
卖家
商品的浏览量
内容浏览模块:分类
内容(商品)日发布量/率
内容(商品)被查看量/率
内容(商品)被询问量/率
社区模块:鱼塘
商品发布成功率
工具模块:发布工具
闲鱼
售卖个人信息
图文攻略
估价工具
Leads 收集量
目的:卖人
浏览人数
各文章转化率
传播量
手段:图文攻略
使用率
工具:估价
土巴兔(早期)
2、选好数据指标的通用方法论
运营常用数据指标分析方法分享
0 条评论
回复 删除
下一页