以下内容意在阐述构建数据指标体系的总体思路，也是向各方学习及个人经验汇总而来。主要讨论为什么需要构建指标体系，如何构建指标体系，以及具体怎么做。希望数据、开发、产品等同学能够参与讨论，多多补充完善。查看业务看板核心指标建设的同学可以直接跳到第四部分。
一、什么是指标体系？
1.1 指标体系的概念
首先，我们先援引百度百科的定义，如下：
评价指标体系是指由表征评价对象各方面特性及其相互联系的多个指标，所构成的具有内在结构的有机整体。简单来说，就是将统计指标系统性的组织起来。
由上面的简单定义可以看出，指标体系是由指标与体系两个部分有机组合而来。
1.2 什么是指标？
对于指标，我们通常所说的指标是指，将业务单元精细化区分之后，用来量化业务的度量值。大到用于监控和评估业务进程的状态，小到衡量某个功能模块组件的情况，或者是自己发起的运营活动效果。例如我们日常运营业务中用到的：日活数、订单数、成交金额、人均浏览时长、留存率、活动参与人数等等，都属于典型的指标值。
1.3 什么是体系？
对于体系，它是由不同维度组构而成。维度指的是我们观察、思考与表述某个事物的“思维视角”。放在我们业务里来说，例子有：区分不同时间周期来看用户数，区分不同机型来看用户数，这个时间区间、机型就是维度。维度是指标体系的核心，可以看出没有维度，单纯说指标是没有任何意义的。
二、为什么要构建指标体系
2.1 从运营业务的视角来看
我们现在经常碰到的一种现象是业务上线了之后发现数据不够用，缺指标或缺维度。随之而来的便是运营临时提出许多数据需求更改、添加指标、增加维度、增加各种五花八门的数据报表等需求。这一系列的需求变更和反复迭代造成的苦果，会使得报表越发臃肿，数据口径参差不齐。业务同学分析具体问题时找数据变得越来越难，每天会消耗大量时间在不断的寻找数据、核对指标的泥潭中。
同时，业务当前所具备的能力需要对外展示、输出，便于外部业务、运营/PM进行了解，缩短接入成本和赋能更多业务线。
2.2 从技术视角来看
基于需求的变更，技术的同学将需要重新去更改设计和开发埋点，数据分析和开发团队的技术同学则需要重新采集、清洗、存储数据。
更为致命的是，若在原有的监控BI报表上增加指标或维度还会需要：
- 在原有的数据存储结果表上动刀，增加存储列等；
- 数据计算SQL逻辑更改；
- 数据回算；
- 结果展现逻辑更改。
这一系列下来不仅耗费人力物力，同时实现本身周期也会更长，反馈效率低下，这也是目前临时需求或者报表开发需求处理慢的根本原因。
2.3 指标体系化后能不能解决？
答：一个好的指标体系设计，不能说可以规避掉百分百的问题，但至少让问题出现时各方临危不乱。
首先，运营同学需要对自己的业务有一个大概的预判，譬如：在整体的业务里程碑上什么时间点会有哪些策略动作，对应的体量会是多大。与此同时也提前去预知大概会监控哪些指标，从哪些维度拆解等。
其次，在有了初步预判之后，运营与开发同学沟通，与数据团队沟通，尽量让各方信息对称。这样的好处是我们能尽量提前将指标体系设计得不重不漏、条理清晰。同时数据团队也会有所准备，在做数据底层设计时多去考虑其稳定性、扩展性等。
2.4 指标体系化的本质和好处
体系化本质是将数据指标系统性的组织起来，具体会按照业务模型，按标准对指标不同的属性分类及分层。当然，不同的业务阶段、不同业务类型，会有不同阶段的划分标准。
指标体系化将零散的数据串联起来，使得我们有能力通过单点看到全局，通过全局解决单点的问题。用一个词来形容，就是“引一发而动全身”，通过相关的指标变化看到整体业务场景下的变化，从而快速发现问题或者是监控相应运营策略的效果情况。
简而言之：
体系化的指标和零散的指标，最大的区别是——是否能更加快速地发现一些问题。
拿购物业务举个简单的例子（单纯为了说明问题）：某一天，自营购物的同事发现，用户进入商品详情页后到下单的过程中的下单转化率偏低。如果根据零散的数据指标，我们很快就会想到：1、商品详情页的设计可能存在问题，可能不够吸引用户；2、下单的按钮，或者下单的操作门槛成本过高，导致用户在详情页流失的比例较高。
但是如果有了基于业务流程的指标体系，我们可能会在分析下单转化率偏低这个问题的时候，从整个业务的指标维度中，选取分析视角，我们可能会发现：3、下单转化率不高的同时，真正有兴趣购买的用户进入商品详情页可能需要在购物版面或者商品列表页下翻三屏才能找到商品。4、我们的用户的平均客单价可能是100元上下，而流量最大的位置可能放的是3000~4000元的商品，点击进来的用户自然有较大比例不会对详情页商品感兴趣，从而导致下单转化低。而上述两条很有可能才是根本原因。
可以看出体系化的指标往往是结合用户的场景来进行分析，并且多个不同的指标和维度是可以串联起来进行综合分析。就像排序因素里面的某个维度（如价格），可以分析页面转化率，也可以分析商品的售出率等。通过相同维度的分析可以更快地找到问题的原因
网上也有文章指出了指标体系的一些别的好处：
| 序号 | 没有指标体系 | 有指标体系 |
|---|---|---|
| 1 | 上线没数据-》产品上线后发现没有报表可以查数据 | 产品上线前已有报表，确保上线后有数据量化 |
| 2 | 业务同学不懂设计报表-》没有经验的业务同学不知如何提报表需求，对维度指标没概念 | 指标体系帮产品规划好所有的报表内容，无需产品敲定 |
| 3 | 指标多样化-》评估指标不统一导致产品之间难以横向比较，如7日留存率的定义是第7日留存，有的定义是累计7日留存 | 指标体系提供了标准的评估指标，不会出现非常规且不便于比较的指标 |
| 4 | 做不完的报表需求-》随着产品的发展，不断出现各种报表需求，不同的报表可能是为了评估同一内容 | 指标体系一次性解决所有报表需求，体现做数据的专业性 |
三、行业内现有指标体系构建模型
在这里简单地介绍常用的几个模型或选取思路，以供参考：
1、指标分级模型
1、一级指标：公司战略层面指标。
用于衡量公司整体目标达成情况，通常设定在5-8个指标。这类指标是与业务紧密结合，按照行业标准进行制定，有可参考的行业标准指标，且这类指标针对全公司所有员工均具有核心的指导意义。
比如某公司的一级指标：新增账号、留存率、DAU/MAU、付费人数（率）、收入金额等。
2、二级指标：业务策略层面指标。
为了实现一级指标，公司会做出一些策略，二级指标通常与这些策略有所关联。可以简单理解为一级指标的实现路径，用于更快定位一级指标的问题。
例如：某公司一级指标是总体广告收入，那么二级指标可以设定为不同版面广告内容的收入。一级指标是DAU，那么二级指标设定为分类型的DAU等。这样当一级指标出现问题的时候，我们可以快速查询到问题的所在点。
3、三级指标：业务执行层面指标。
三级指标是对二级指标的路径拆解，用于定位二级指标的问题。三级指标的使用通常是可以指导一线人员开展工作的指标内容。三级指标的要求是：一线人员看到指标后，可以快速做出相应的动作。
如游戏公司的二级指标是XX频道的DAU，那么三级指标则可以设定为打游戏时长、玩游戏频次、用户等级分布、导致用户流失情况等。通过观察这些数据，可以去针对性地做调整，如某个功能或者界面导致流失的用户特别高，那么尝试将其隐藏或尽量置后。
2、OSM模型（这也是目前已经在使用的方案）
OSM模型（Obejective，Strategy，Measurement）分别代表业务目标、业务策略、业务度量。
O：用户使用产品的目标是什么？产品满足了用户的什么需求？
S：为了达成上述目标我采取的策略是什么？
M：这些策略随之带来的数据指标变化有哪些？我们搭建指标体系是为了更好地发现用户的问题，并且去解决。所以我们需要站在用户的场景去考虑整体的内容。
以知乎为例，按照OSM模型，它的指标是什么样的？
— O：用户来使用知乎这个产品，目标是什么？
这里涉及两个不同的用户——内容分享者和内容消费者，这里简单介绍内容生产者的分析思路，大家可以自己试着分析下内容消费者。
用户需求：分享知识观点（发布观点），建立行业影响力（内容受到反馈）。
那么，如何让用户感受到自己的需求被满足了呢？
— S：知乎做的策略是：内容点赞评论、内容打赏、盐值增加、XX话题优秀回答者。
— M：接下来，我们需要针对这些用户动作去做指标，在这里面我们的指标会有两个，分别是结果指标和过程指标。
结果指标：用于衡量用户发生某个动作后所产生的结果，通常是延后知道的，很难进行干预。
过程指标：用户在做某个动作时候所产生的指标，可以通过某些运营策略来影响这个过程指标，从而影响最终的结果。
还是以内容生产者为例：
结果性指标：发布文章数、发布文章的人数、文章点赞/评论数、被打赏人数、被打赏金额、优秀回答者人数、新增优秀回答者人数等。
过程性指标：使用内容导入人数、内容发布转化率、文章互动率、评论折叠率等。
通常我们会在指定指标的过程中使用OSM的模型，去针对用户在不同场景下产生的动作，以及这个动作可能带来的结果，用户在这个动作中会出现什么样的数据变化。之后再结合数据，针对性地去调整我们的运营策略或者产品功能。
简单理解：
结果性指标更多的是监控数据异常，或者是监控某个场景下用户需求是否被满足；
而过程性指标则是更加关注用户的需求为什么被满足或没被满足。
3、业模型图x海盗指标法AARRR
该方法构建数据指标体系需要理清楚以下三个关键点：
1、业务拆解：业务流程图
2、角色分析：用户关键触达路径
3、漏斗分析：各环节核心指标
依据我们之前对业务的梳理，先对自身业务模式进行拆解，画出了业务模型流程图。通过观察其在业务主流程上，不同阶段实现用户需求时，用户会做什么、产生哪些数据、我们需要监控哪些数据。
以下为一个典型电商业务的拆解过程（借鉴《精益数据分析》内容）:
通过上一步的业务拆解，我们基本可以摸清楚，用户在实现需要的路径上会产生哪些数据，这些数据将会为我们还原业务真相：
- 认知阶段：市场渠道相关数据，品牌广告数据。如：渠道新增、渠道DAU、渠道留存、渠道转化、渠道ROI等；
- 激活注册：应用激活量、激活注册转化率、版本分布、机型覆盖率等；
- 关键行为：用户行为数据，如：发布商品、搜索、浏览商品、收藏、添加购物车等；
- 沟通：留言、私信、电话沟通；
- 交易：下单、支付等；
- 售后：交易仲裁、申诉投诉、催单等。
接下来考虑为了解决用户的问题，需要有哪些角色的人参与业务流程：
基于海盗指标法，他们的第一指标是什么？
如下：
四 、如何构建通用核心指标体系
核心指标建设思路采用 OSM模型 进行构建
背景
业务以及中台各方向产品在建设过程中努力建设一套该产品方向关注的核心指标体系，通过对指标数据的建设、分析和运营，可以反馈产品功能现状、分析对业务的影响、评估工作成果
核心指标体系框架
指标体系的框架(即终极指标、过程指标、观察指标、必看指标四个模块)是不变的，但每个模块的具体指标可以根据该方向工作所处阶段实际情况调整
每个指标建议要有理解逻辑或使用逻辑的描述，例如描述指标与业务关系，指标大小有什么影响等
终极指标（北极星指标）
- 描述：也称北极星指标，各方向工作最终关注的核心指标，使用这些指标评估该方向工作成果与价值。各方向PM为终极指标负责
- 前提：终极指标就是业务指标，或者终极指标与业务关心的指标有强相关性，则提升终极指标的同时能辅助提升业务关心的指标
过程指标
- 描述：终极指标的过程拆分指标，终极指标有波动时，通常也由过程指标来分析解释。分析师对过程指标的波动归因负责
- 举例：漏斗转化，描述该功能设计的漏斗转化率情况，通常是终极指标的中间转化环节，转化率越高说明该能力越有效稳定
观察指标
- 描述：各方向工作进行的过程中需要关注的观察指标，没有对观察指标要明确上升或下降的优化目标要求，但观察指标出现较大波动时需要有归因分析
- 举例：渗透率，描述某功能环节涉及的用户在 dau/mau 上的渗透；用户反馈，用户使用该功能过程中的反馈量和反馈率等
必看指标
- 描述：用于周报、双月报等汇报场景的必看指标，一般是从终极指标、过程指标、观察指标中取部分必看指标
指标深度分析
对部分核心指标进行深度剖析，有助于更好地理解和使用核心指标
- 指标相关性分析：终极指标与业务指标的相关性分析
- 指标拆解分析：终极指标可能是受多个 阶段/维度 的指标影响，拆分不同 阶段/维度 指标对其影响
- 指标组合分析：综合多个指标一起分析经常能呈现更多的信息，例如二维象限图等
归因分析
日常的核心指标出现异常波动时，分析影响波动的指标数据表现
- 核心指标波动异常监控
- 核心指标波动异常归因分析，归因分析工作文档：
- 主动输出归因分析结果报告，周知BP和业务方
看板建设
日常核心指标展示
- 周报双月报指标体系梳理
- 周报双月报自动化建设
五、实践示例
** 以账号业务为例
帐号业务核心指标体系
1、终极指标
| 指标 | 计算逻辑 | 说明 |
|---|---|---|
| 登录转化率 | 登录成功量级 / 登录面板曝光量级 | 综合衡量整个流程的流畅程度。提升漏斗的任何环节都会提升整个转化率。 |
| 登录耗时 | 点击提交登录到登录成功的耗时 | 综合衡量整个流程的流畅程度。在登录中遇到问题会阻碍操作，造成登录耗时变长。 |
2、过程指标
| 指标 | 计算逻辑 | 说明 |
|---|---|---|
| 登录流程 | ||
| 登录提交率 | 登录流程中：登录点击提交用户数量 / 登录展现用户数量 | 衡量在触发了登录面板之后的用户的登录意愿强度。 |
| 各个登录方式提交率 | 某登录方式的提交量级uv/某登录方式的面板量级uv | |
| 登录成功率 | 登录流程中：登录成功用户数量 / 登录提交用户数量 | 登录提交到成功是跟用户操作无关的过程，除去用户的手机和网络的影响，登录成功率越高说明登录提交后的功能做得越好。 |
| 各个登录方式成功率 | 某登录方式的成功量级uv/某登录方式的提交量级uv | |
| 登录请求成功率 | 登录成功请求pv / 所有登录请求pv | 衡量每次请求的成功和失败情况 |
| 新增注册量 | 注册的新帐号的量级 | 新增注册是首次体验登录注册流程的用户量级 |
| 用户注册方式分布 | 短信验证码、帐密、第三方等方式的注册方式占比分布 | |
| 用户登录方式分布 | 短信验证码、帐密、第三方等方式的登录方式占比分布 |
3、观察指标
| 指标 | 计算逻辑 | 描述 |
|---|---|---|
| 登录渗透 | ||
| 登录率 | 日活登录率 = 日活跃中登录态设备数 / 日活跃设备数 | 登录率与留存率有密切关系，登录率高的业务其留存率也相对高（因果关系未证明） |
| 注册率 | 新增用户中注册的数量 / 新增用户数量 | 衡量一个业务的新用户愿意登录注册的程度，注册率越高，可能是业务形态本身更需要注册使用，或当前通过活动等运营手段影响的结果；当用户有意愿注册时，用户中心应以100%满足其登录成功为目的，即在登录成功率上体现。 |
| 登录展现渗透率 | 登录流程中：登录面板展现用户数量 / 启动时未登录的用户数量 | 衡量有多少未登录用户触发了登录面板，反映了产品的登录引导强度。 |
| 绑定 | ||
| 大盘绑定率 | 绑定了手机号（三方、邮箱）的账号数量/所有账号数量 | 衡量大盘中有绑定某种登录方式的用户占比情况，在调整功能时能有效评估影响面。 |
| 日活绑定率 | 日活中绑定了手机号（三方、邮箱）的账号数量/日活账号数量 | 活跃用户中绑定了某方式的用户占比情况，在调整功能时能有效评估影响面。 |
| 新增绑定量 | 新增绑定的账号量级 | 当天操作成功使用该绑定功能的用户量级 |
| 换绑请求量 | 换绑手机号（邮箱、三方）的账号量级 | |
| 绑定转化率 | 绑定流程中：绑定成功用户数量/绑定面板展现用户数量 | 需要区分绑定入口来观测，有些产品强制需要在登录环节绑定手机号 |
| 绑定成功率 | 绑定流程中：绑定成功用户数量/绑定提交用户数量 | |
| 反馈 | ||
| 反馈量 | 反馈设备数去重统计 | 帐号反馈量是用户当前对业务的帐号服务的反馈量 |
| 反馈率 | 反馈量 / 未登录成功量 | |
| 业务覆盖 | ||
| 业务覆盖 | 已覆盖的业务量级 | |
| 注销 | ||
| 注销量 | 完成注销的帐号量级 |
4、必看指标/周报指标
| 指标 | 计算逻辑 | 描述 |
|---|---|---|
| 登录率 | 日活登录率 = 日活跃中登录态设备数 / 日活跃设备数 | 登录率与留存率有密切关系，登录率高的业务其留存率也相对高（因果关系未证明） |
| 注册率 | 新增用户中注册的数量 / 新增用户数量 | 衡量一个业务的新用户愿意登录注册的程度，注册率越高，可能是业务形态本身更需要注册使用，或当前通过活动等运营手段影响的结果；当用户有意愿注册时，用户中心应以100%满足其登录成功为目的，即在登录成功率上体现。 |
| 登录转化率 | 登录成功量级 / 登录面板曝光量级 | 综合衡量整个流程的流畅程度。提升漏斗的任何环节都会提升整个转化率。 |
| 登录耗时 | 点击提交登录到登录成功的耗时 | 综合衡量整个流程的流畅程度。在登录中遇到问题会阻碍操作，造成登录耗时变长。 |
| 帐号反馈量 | 按照各个反馈标签按设备数去重统计 | 帐号反馈量是用户当前对业务的帐号服务的反馈量。 |
