0)指标体系背景知识
什么是指标体系。
指标体系就是指衡量企业业务状态的指标集合。
好的指标体系特征
业务复杂性:流程越复杂,我们越需要搭建指标体系。
行业毛利低:行业毛利越低,企业越需要搭建指标体系。
- 需要指标体系来控制各个生产销售环节的指标。达到利益、利润最大化。
公司规模大:公司规模越大,越有必要建立指标体系。
0.2)指标体系的作用
看清业务-找到痛点-指导业务-
- 看清业务现状
当企业没有一个统一的指标体系的时候,各部门对于同一件事务的反馈很可能刚出现不同的结论,引发冲突。而指标体系可以让不同部门企业管理者看到一个相对客观的数据,能够统一公司不同部门对业务现状的理解。指标体系大部门由“第三方机构”数据中台部门,来做出相对中立客观的统一指标口径。
找出业务痛点,确立分析主体
- 梳理关键指标
对比关键指标的值和行业标准的差距
AARRR模型
智能指导业务
- 指标预测
- 结果指标预测
- 通过预测结果指标来指导我们生产、销售资源
- 指标预警
- 负面指标优化
- (退货率、用户流失率)这是需要稳住的指标,就需要指标保持在一定的波动范围。通过预测负面指标的波动范围来监测指标数据是出现异常,从而做到指标预警。
- 异常归因
- 异常数据归因
- 经验、数据方法
- 指标预测
优化产品\业务逻辑
可以通过漏斗分析来观察我们各个环节的业务状况,从而找到漏斗过程中折损较大的过程。
1)指标体系搭建
在线教育企业数据问题与指标体系解决方案
- 企业遇到的问题
- 数据缺乏系统性,代表性
- 解决:数据架构梳理+业务架构梳理
- 缺乏统一的指标口径
- 解决:指标口径梳理+统一指标口径
- 数据孤岛
- 解决:数据打通
- 数据缺乏系统性,代表性
梳理公司架构
梳理公司架构的主要任务:
- 了解公司各业务部门承担的主要工作,扮演的主要角色
- 了解各部门关心的主要指标
为什么要做公司架构梳理,在做了公司架构梳理的基础上来做指标梳理,了解各个业务部门之间的影响,单一的目的分析指标会忽略掉很多问题和细节。
MECE原则:相互独立,完全穷尽。
部门业务流程
通过自己梳理各个业务部门的分工和占比,让自己能够了解到该如何获取想要的指标,什么指标该找哪个团队获取。
梳理部门业务的必要性:
- 能让指标体系更具有系统性
- 能让指标体系更有代表性
- 为了让平面的指标体系具象化。
指标体系立项
- 需要些立项报告
- 项目背景
- 项目解决问题
- 项目方案
- 项目设计
- 人员安排
- 对接团队
- 项目排期
梳理完运作图能够让我们知道我们需要做什么工作,才能让整个项目运行起来
使用泳道图梳理运作流程
- 数据提取
- 数据存储
- 数据计算
- 数据可视化
- 数据应用
确定指标
- 拟定核心指标(北极星指标)
- 指标对比与确认
北极星指标的作用
北极星指标也叫作第一关键指标,是指在产品的当前阶段与业务/战略相关的核心指标,一旦确立就像北极星一样闪耀在空中,指引团队向同一方向迈进
- 北极星指标的作用
- 聚焦企业现阶段的核心问题
- 同一个团队工作方向
- 明确任务优先级
- 量化团队工作效果
如何确定北极星指标
两个步骤
- 确定企业的商业目标
- 确定用户价值
列出符合这两个目的的指标,并按照6个标准与他们作对比,最后回到商业目标和用户价值环节,探究我们确定的北极星指标能不能在实现商业目标的时候还能让用户持续获得价值
明确商业目标和用户价值 -> 列出备选指标 -> 确认北极星指标
1)明确商业目标和用户价值
- 商业目标
- 商业目标相当于是企业的最终愿景。
- 北极星指标是实现这个最终愿景中的一个中期战略目标,一般1-3年才会变动一次,需要企业依据公司状况和商业环境不断调整。
- 用户价值
- 用户对于产品的主要需求。
- 如果用户在使用产品的时候没法获得他所需要的反馈,那么这个产品就是没有价值的产品,产品就很难有存在的意义。
本案例中的商业目标:持续的课程营收
本案例中的用户价值:学习知识
2)列出备选指标
用户路线梳理与设计指标模型
- 业务梳理
- 梳理用户路线
- 设计指标模型
- 确定指标口径
梳理用户路线
设计指标模型
AARRR模型
获取 -> 激活 -> 留存 -> 付费 -> 推荐
阿里使用AIPL :从兴趣到认知到付费
使用业务和模型相匹配的模型
完善指标监控模型
需要将北极星指标与指标模型结合,主要是利用指标模型来拆解北极星指标
方案:
- 链路型
根据与北极星指标有关的链路逐步拆解
- 比较适合跨部门拆解,容易给不同部门分配不同的表
- 拆分粒度比较粗,结构比较平面,不如分解型拆解容易让使用者看到重点
- 分解型
- 比较整体统一化,适合单个部门或事业群
- 有明显的逻辑架构,,容易让使用者关注到数据重点
- 如果某个地方遇到跨部门环节,比较难分部门拆分
指标模型的作用:
- 揭示影响目标指标增长的所有输入变量,就能使用量化方法指导工作;能够让策略多样且全面而不是集中在某一环节;能够站在更高维度的视角来审视项目。
- 指标模型能够让我们确定工作优先级;
- 拆解到比较细的指标之后有助于我们做更精确的指标预测,预测目标能够帮助我们做以后的工作计划。
- 指标模型容易让使用者看到工作重点
做指标体系架构图
埋点定义
埋点:事件追踪,是一种对特定用户行为的捕获、处理、发送技术。
- 网站收集数据的基础:
- 监测代码:SDK(software development kit)
- 不能靠基础代码获取的用户行为:最典型的就是(事件)Event
- 网页:JavsScript\Flsh\Ajax,各种页面的插件交互
- APP:用户点击在内的所有交互
每一个需要我们监测的Event互动都被称为一个“监测点”,每一个监测点都必须部署上“事件监测代码”Event Tracking Code
埋点的类型
前端代码埋点:
定义:
APP工程师手动添加代码
不同监测点的命名和属性都需要一一对应
优点:
可以根据自身业务需求,定制化地设置自定义属性,自定义事件,传递比较丰富的数据到业务端。
缺点:
1.每次上线新的埋点或者更新埋点时,需要发布新的版本,难免存在部分用户不更新新版本的情况,会影响数据质量。
2.性能影响,统计代码的引入对性能有一定的影响。
3.工作量大,每一个事件埋点都需要添加代码。
可视化埋点:
定义:在APP模拟器上交互式添加埋点
事件在编辑基础代码的时候位置就确定了
优点:
1.人力成本低;产品和运营可以直接在APP上操作埋点,埋点之后可以自行验证埋点数据。
2.更新代价小,埋点部署到所有客户端几乎实时生效,不需要新发版。
缺点:
1.只能覆盖基本的点击、展示等用户行为,不支持自定义属性的采集。
2.可视化埋点覆盖基本功能有限,如内容瀑布流加载交互、下拉菜单内容的点击等无法采集。(已有部分公司改进这部分功能)
全埋点:
定义:直接将页面的所有基本事件埋点
在前端埋点的基础上对页面上所有的基础事件埋点。
1.记录所有events和Dom Path 直接追踪所有Events
2.在有用户行为事件发生的时候,将用户事件+Cookie(用户信息或Device ID)全部追踪下来
优点:
1.历史数据可回溯
2.自发获得启发性信息
3.僵尸按钮容易暴露出来
4.只需要部署SDK数据便开始采集,技术成本低,门槛低。
缺点:
1.只能覆盖基本的点击、展示等用户行为,不支持自定义属性的采集。
2.由于全面采集用户行为数据,数据量非常大,对服务器压力很大。
3.兼容性不佳。
4.记录的交互行为的属性有限
- 依据服务器资源选择是否使用全埋点