编辑导语：几乎所有的数据分析工作都会提到一个词——“建立数据指标体系”，虽然这个词对于大家来说并不陌生，但是如何具体的搭建，很多人还是一头雾水的。今天，本文作者就和我们好好聊一聊数据指标体系如何从构思到落地。

一、数据指标与体系

1. 什么是数据指标？

指标是一个可以量化目标事物多少的数值，有时候也称为度量，如：DNU、留存率等都是指标。

一个指标通常需要从多维度来分析指标构成，这就要求指标与多维度关联支持多维度分析，如DNU就可以按照不同渠道查看各渠道流量大小，也可以按操作系统查看不同操作系统的人数，这里的渠道、操作系统就是维度。

2. 好的指标体系该是什么样的？

指标体系就是将各个指标按照特定的框架组织起来，从不同维度梳理指标，梳理的过程也是对业务本质进行思考的过程。

一个好的指标体系应该有以下两点性质：

1. 上能指引高层领导把控业务整体方向，下能指导业务人员落地执行业务目标；
2. 指标之间要形成闭环相互作用相互影响产生反馈，才能称之为体系，以数据定位问题，再反向作用运营和产品，最终形成数据驱动产品设计及用户运营的闭环。

二、如何搭建指标体系

指标体系的搭建分为两大步骤：设计指标体系和落地指标体系，这两大部分又可以拆成一些小步骤，我们先来看一张指标体系从设计到落地的整体步骤图，下面再根据这张图细分拆解其中的每个步骤是怎样落地的。

1. 如何设计指标体系

1）需求来源

主要需求来源随着产品生命周期而改变。搭建数据指标根据数据现状分为初中后三个阶段。首先要明确的是先有目标方案后再有数据指标，而不是凭空捏造出一些指标体系然后往产品上套。

• 在数据指标搭建初期以产品战略目标为主，优先搭建北极星指标的全方位指标监控；
• 中期以业务驱动为主，搭建指标衡量现有业务，业务驱动直接获取到的指标一般是二级指标，需要整合到指标模型里面去；
• 到了后期，此时各数据指标已经搭建的差不多了，是时候根据模型查缺补漏，搭建针对产品的指标闭环，通过数据来反向推动产品的迭代优化。

2）确定一级指标

一级指标其实就是反映产品在各个重要方面的运营情况怎么样，把对用户的运营当成一个流水线，围绕着用户生命周期即可挖掘到一些重要的一级指标并自然而然的形成闭环。

在众多指标模型中我觉得AARRR模型能很好的概括用户的生命周期，美中不足的是遗漏了用户流失这一环节，个人觉得AARRRR比较能完整概括用户生命周期，即Acquisition（获取）、Activation（激活）、Retention（留存）、Revenue（收入）、Referral（自传播）、Recall（召回）。

围绕这六大方面，可以拓展以下一级指标（只是举例一些通用指标，具体的一级指标可根据具体业务进行定义）：

3）得到二级指标

二级指标由一级指标衍生而来，为了实现一级指标，企业会采取一些策略，二级指标通常与这些策略有所关联。可以简单理解为一级指标的实现方式，用于替换定位一级指标的问题。

二级指标的作用就是将一级指标的涨跌落实到具体的业务部门或者是责任人，通过成分拆解我们可以从一级指标得到对应的二级指标。例如收入这个一级指标，通过成分拆解可以分为广告收入和内购收入等。

4）得到三级指标

通过二级指标的分析可以找到相应问题的责任方，而三级指标的作用正是指导该责任方去定位具体问题，进而修复问题。

通过对二级指标的路径拆解即可得到三级指标，一线人员可通过三级指标的具体表现快速做出相应的动作，所以三级指标的要求是尽可能覆盖每一个关键路径上的关键动作。

这里继续拿内购收入这个指标举例，通过路径拆解，最终促成内购的关键行为路径是：浏览商品、加入购物车、提交订单、支付成功。

按照以上流程不断查缺补漏确定各一级指标并对其进行逐步拆解，即可搭建出一套行之有效的数据指标体系。为了加深印象，下面看看各级指标的应用实战案例：

责任方找到了，那就该赶紧定位解决问题啦。

问题就这样自上而下的逐步拆解直到解决，当然了，现实工作中各级人员都要时刻关注自己负责的那部分指标将问题扼杀在萌芽阶段，不要等着领导发现问题找过来再亡羊补牢。总结起来整个指标体系的应用流程如下：

2. 如何落地指标体系

终于到了开干时候，有了目标之后接下来就是将规划的指标进行埋点落地了。

落地指标就不像设计指标那样首先着眼于一级指标，而是应该首先着眼于二级指标，因为一级指标是由二级指标组成的，二级指标埋点好了之后一级指标自然而然地可以计算出来。

埋点不是一个人的事情，需要各部门通力合作，下图就是埋点的整个设计到落地的流程：

不知看完这张图有没有一个疑惑，责任方为什么还要去理解熟悉需求，需求方不是给出指标了吗，照着去埋点就好了啊。如果你这么想的话，那你注定只能做一个工具人。

首先各指标跟具体的业务逻辑设计紧密相关的，如果你不去熟悉业务，是无法针对指标进行多维度细化埋点设计的，最终设计出来的埋点方案必定是丢三落四漏洞百出。

再者需求方给出的指标不一定是全面的，需求方往往数据意识不强，无法洞察到当前业务的很多细节是数据可分析的。

所以这就需要数据产品经理熟悉业务懂产品懂用户，才能一针见血设计出一套有指导性意义的埋点方案，而不是照本画葫芦搞出一些冷冰冰的数据看看就好，要记住，每一个埋点都是有深意的，数据也是有灵魂的。

明确了埋点的工作流程，接下来要确定的是选择自研数据门户还是使用第三方工具，如：神策、Growing IO、诸葛IO等。这两者主要有以下区别：

• 自研工作量大，搭建周期长，第三方提供现成的模型，搭建周期短；
• 自研更灵活，相对埋点实施方上报数据更友好，无需过多无谓的逻辑记录，在后期的指标计算方式上可以随心所欲，如某些耗时只要打好点，自研就可以通过两个事件的时间差计算出耗时，而有些第三方则不支持。

总之，自研前期痛苦后期爽，第三方前期爽后期痛苦。从实现难度上来说自研需要的人力物力远远大于第三方服务，绝大部分中小公司会选择第三方服务，下面的埋点介绍就基于第三方服务的方式进行讲解。

老规矩，在讲解之前先上一张整体的流程图：

1）埋点规范文档

正如前面所说，指标体系的搭建需要各部门通力合作，一份埋点规范文档既能规范工作流程提高效率，又能明确需求规范减少沟通成本避免理解出现偏差。埋点规范文档包括了工作流程规范、命名规范、需求文档规范等，这些应该在指标体系落地之初就规定好。

当然由于一开始经验不足并且有的问题在后续的工作中才会暴露出来，初版的规范文档可能并没有那么详细，但是大体框架还是要有的，后续再补充一些细枝末节的东西。

2）拿到需求原型

就是产品功能原型或者活动原型。

3）定义页面、元素名称

拿到需求原型后，首先将原型里面的页面及页面中的元素名称提前定义好，以便后续进行统一使用避免不同指标出现页面命名不一致的情况。

如果是页面的话建议全部命名，页面里面的元素可能会有点多，可以挑一些关键路径上的重要元素进行命名，其它元素视后续工作需求再进行埋点（当然了有精力的话全部命名进行监控是更好的，毕竟数据是多多益善，避免后续需要用数据发现没有埋点的情况发生）。

4）定义事件名称

为什么要规范事件名称？我直接举个例子吧，某天你想查看用户的使用路径，当你使用用户路径分析之后发现有大量的展示事件穿插在用户行为事件中，这时候你是不是很恼火。

如果之前埋点的时候对事件进行规范命名，这时候你只需要在筛选条件中过滤掉事件名前缀为展示的事件，就可以轻松过滤掉所有跟用户行为无关的事件。

事件规范命名除了以上好处，还有个好处就是方便需求方使用，使用者可以通过事件名轻松知道这个事件具体的含义，提高了使用效率，事件命名可由以下几部分组成：行为、对象、结果、类型。

各部分解释：

• 行为：事件的具体行为，主要有 4 类：

1. 点击 – 点击某个按钮或元素的一类事件；
2. 进入 – 进入某个页面或功能的一类事件；
3. 展示 – 展示某个页面或元素的一类事件；
4. 退出 – 退出某个页面或功能的一类事件。

事件行为必须填写，后续可按实际情况增加其他行为。

• 对象：事件行为对应的具体对象可以是页面，或者是功能，事件对象必须填写。
• 结果：对该对象进行的行为最终的结果，主要有3类：

1. 成功 – 针对该对象进行的行为结果为成功；
2. 失败 – 针对该对象进行的行为结果为失败；
3. 结果 – 针对该对象进行的行为结果为成功或者失败，此时具体结果存储在该事件的维度中，事件结果必须填写。

• 类型：此参数为拓展参数，如展示事件可能展示的是页面，也可能展示的是弹窗，这时候在事件后面加个页面后缀或者弹窗后缀，后续使用起来就能很方便的区分事件的具体类型。事件类型为可选参数，视情况而定。

以上就是事件的命名标准，可以从该标准进行如下一些命名：注册_指标_成功、进入_充值页面_成功等。

5）梳理指标维度

这时候就要隆重介绍一下前面《指标体系搭建流程图》中提到的新4W1H分析法了。为什么叫新4W1H，因为针对传统的4W1H进行了新的的解释，在新的释义上可以更加合理的加上本人在实际工作中总结的经验。

根据平时的埋点总结，事件维度主要由主题和事件因果几个大维度组成。主体即用户、设备和应用，因果即这个事件的来源和结果。通过增加因果维度可以方便的看到一个事件的来源和去向。

我们先用一张图来了解下新4W1H分析法是如何定义维度的：

• Who：触发该事件的主体，是唯一区分用户的标志，如果用户登录了则使用用户ID（设备ID也需要记录），未登录则使用设备ID；
• When：事件发生的时间，使用UNIX时间戳就好；
• What：描述触发这个事件的参与主体具体信息，一般有三个主体，用户本身、应用、还有设备。使用第三方服务的话除了用户信息需要我们埋点设置，其他的第三方SDK都会自动采集，所以这部分参数不是我们工作的重点；
• Where：事件发生的物理地点，可以用过GPS、LBS、IP来判断，具体视用户的授权而定。位置信息第三方SDK也会自动采集；
• How：事件的具体描述，这一块才是我们工作的重点，缺乏经验的话往往会遗漏一些重要的维度，导致后续的分析支持不上。根据个人总结的因果分析法可以将事件的描述分为来源和结果描述，事件的来源去向无非有两类：多个行为造成同一个结果、一个行为造成不同结果。

例如：进入充值页面，可能从不同入口进来的；点击充值按钮，可能会充值成功或者充值失败。

事件的结果即为对该事件的具体信息描述。通过因果分析法进入充值页面到充值成功这一系列行为我们可以做以下事件埋点（以下事件维度只列举因果分析法相关维度，其它参数视具体业务自由增加）：

通过这样的埋点，我们就可以很清晰的知道进入充值页面各个入口的分布情况，也能知道点击充值按钮后充值成功和失败的分布。

6）明确上报时机

事件的上报时机由事件的定义来具体决定。主要有以下三大类：

1. 展示：展示时候上报，需要明确重复展示是否重复上报，像那种自动轮播的banner就不需要重复展示重复上报，因为这样的重复上报是没什么意义的，而用户反复滑动导致的重复展示可以重复上报；
2. 点击：点击时上报，这个是最简单的上报时机，一般没什么争议；
3. 接口：这个涉及到与后端的接口交互，如前面举例的购买_金币_结果事件，上报时机则为充值成功或者失败时上报，即客户端拿到后端返回的具体结果时上报。

7）输出数据需求文档

当上面工作已经做完时，就可以输出需求文档了，需求文档主要包含以下信息：

8）录入指标字典

埋点指标上线后，为了方便业务方使用，可以将各指标按照业务分为不同的主题，方便使用者快速找到需要的指标，具体包含以下信息：

三、数据应用

数据的作用用一句话来概括就是总结过去，预测未来，常见的使用方式如下：

鉴于篇幅问题这里就不再细说数据的分析应用了，后续有时间再另写一篇有关数据分析的经验。不知不觉写了这么多，终于把指标设计到落地总结完了，希望大家看完能有所收获。

本文由 @不语 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议