随着业务规模的扩大，各类相关的数据量增大、数据指标也越来越多，如果缺乏指标体系就会造成难以衡量产品/活动效果、难以判断整体业务发展状况等问题。而本文就通过拆解阿里制定指标的规范，来为我们建立数据指标体系做一些参考。

在建立OneData之前，阿里数据有30000多个指标，其中，即使是同样的命名，但定义口径却不一致。即使是中等规模的公司，也是如此，随着数据量的增大，数据指标也会越来越多，缺乏指标体系的管理会存在各种各样的问题。

一、指标不规范带来的问题

1. 在数据指标概念=0时，业务方按“我觉得”来办事，难以衡量效果

产品设计、运营同学通常是：我觉得用户会喜欢我们新推出的这个功能，我觉得新推的活动，活动效果会很好…..

那领导就要问了，这个“觉得”有什么依据么？怎样衡量用户喜欢这个新增的功能？怎样判断活动效果好，多少人参与或是多少转化？

这样一提问，其实设计者们也云里雾里的，一脸懵逼，别问设计原因，问就是回答其它竞品也有这个功能，所以我们也做……

是不是觉得自己也中招了？

不过已经有大批产品人员已经意识到传统的盲目设计、抄袭式设计时代已经过去，数字化产品时代已到来的现状，开始尝试用数据指标来辅助业务决策。于是开始进入下一阶段…

2. 此时数据指标概念=0.5，有单点数据指标，但难以看出整体业务问题

这种情况下通常是想到什么业务指标，就用什么业务指标。

比方说看到神策、友盟数据分析类厂商通常会用GMV、日活用户、月活用户、PV、UV、页面停留时长等数据，于是产品设计人员先将其照搬进来，再结合具体使用的时候，会想到一些指标，然后逐个往上加。

以网约车为例，今天的GMV降低50%，是什么原因导致呢？

分析人员回复说：受疫情影响，乘客下单量降低20%。

这是平台当前已有指标，那还有30%呢？是什么问题导致的？

于是分析人员一查数，发现在线司机数、接单司机数降低30%，于是匆匆的又把临时想到的这两个指标，简单的描述了一下业务含义，经过一系列的沟通协调，让研发临时添加。

这种方式会存在什么问题呢？

1. 指标修改成本大。研发团队需要重新进行数据采集、清洗、存储工作。
2. 取值定义不清晰，数据不准确。
3. 指标缺乏定义规范，各部门理解难度大。会产生一些重复指标，如指标名称相同，含义不同，例如都叫注册司机，一种定义的是注册手机号成功即为注册司机；一种定义的是加盟成功了的是注册司机。
4. 存储、计算、研发成本高：没有统一的规范管理，造成了重复计算的资源浪费；数据的层次和粒度不清晰，使得重复存储严重。

二、理解OneData指标规范

既然不提前设计指标体系会出现诸多问题，那指标体设计流程是什么？如何保证指标体系的规范设计呢？

下面我们先来看看阿里是如何制定指标规范的：

以维度建模作为理论基础，构建总线矩阵，定义业务域、数据域、业务过程、度量/原子指标、维度、维度属性、修饰词、修饰类型、时间周期、派生指标等。

1. 业务域

比数据域更高维度的业务划分方法，适用于特别庞大的业务系统，且业务板块之间的指标或业务重叠性较小。例如用车业务板块包含乘客端、司机端，电商业务板块包含商城、返利模块。

2. 业务过程

业务过程可以概括为一个个不可拆分的行为事件，如下单、支付、评价等业务过程/事件。

看到这一系列的名词，很多人可能就开始懵逼了，业务域倒还能理解，简单来说就是对不同业务的分类；业务过程也容易理解，相当于画业务流程图呗。

那数据域又是何方神圣？

3. 数据域

是联系较为紧密的数据主题的集合，是对业务对象高度概括的概念层归类，目的是便于数据管理与应用。

简而言之，数据域就类似于我们电脑桌面要建立不同的文件夹来存储数据，这些个文件夹名就是数据域。

维度、维度属性、修饰这些怎么理解？有什么用途？

4. 维度

是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，可以从who-where-when-what层面来看。

5. 维度属性

维度属性隶属于维度，相当于维度的具体说明，如用户维度中性别为男、女。

6. 修饰词

指除了统计维度以外指标的业务场景。

7. 修饰类型

对修饰词的抽象划分。

简而言之，维度和修饰都可以理解为原子指标的一些限定条件，懂sql的会更好理解一些，一般是写sql时，放在where语句后边的。

8. 度量/原子指标

原子指标和度量含义相同，某一业务行为事件下的度量，是业务定义中不可拆分的指标，如注册数。

9. 时间周期

用来明确数据统计的时间范围或是时间点，如最近30天、自然周、截至当日等。

10. 指标类型

包含原子指标、派生指标。

• 原子指标 = 行为事件+度量
• 派生指标 = 一个原子指标+多个修饰词+时间周期

例如：原子指标=完单量，派生指标=近一周iOS乘客完单量，包含时间周期=近一周，修饰词=iOS，维度=乘客，原子指标=完单量。

三、制定自己的指标体系规范

接下来参考阿里的onedata数据标准，搭建网约车体系中的数据指标。

• 业务背景：用车业务是网约车整体业务中的一个核心，处于多次循环迭代中，存在指标定义不规范，业务方频繁提出新增指标，技术修改难度大等问题，所以目前需要从业务整体角度重新构建指标体系。
• 业务目标：标准化指标体系，提升指标提取工作效率。
• 行动：在构建指标体系的过程中，首要动作要明确指标分类和约束指标命名方式，使各个指标能够做到见名知意、减少沟通成本，这里我们参照阿里对指标的划分，来规范建设指标体系。

1. 调研业务需求与分析业务流程

1）调研业务需求

充分的业务调研是指标体系构建的基础，在数据指标体系搭建项目启动前，需要与各业务方详细了解具体业务、梳理清楚关键业务流程。

需求采集可分为定量、定性采集两种类型，定量地发放调研问卷形式，广泛采集业务需求；定性地进行用户访谈，深度挖掘业务应用场景和核心需求。详细的需求采集与分析方式之前《需求采集与需求分析》这篇文章有写过，此处不再展开，可做参考。

2）分析业务流程

根据阿里巴巴onedata的最佳实践，业务过程可以概括为一个个不可拆解的行为事件。为梳理数据之间的逻辑关系和流向，首先要理解用户的业务过程，了解业务过程中涉及的数据系统。

下面以网约车体系为例，梳理司机端、乘客端的业务流程以及数据指标。

乘客端流程可划分为：注册/登陆、下单、服务、支付、评价/客服投诉。

核心流程中所产生的业务指标：

1. 注册/登陆阶段：新用户数、用户数、不同渠道用户数
2. 下单阶段：下单量、新用户下单量、老用户下单量、不同城市下单量数据、不同车型下单量数据、下单成功用户数
3. 决策阶段：议价订单数、非议价订单数、决策阶段用户主动取消订单数、决策阶段超时取消数、数加价完成订单数、减价完成订单数
4. 服务阶段：下单成功用户数、订单时长、下单成功率、完单量、完单率、完单用户数
5. 支付阶段：订单金额、订单平均金额、订单优惠金额、计费差额
6. 评价阶段：好评率、差评率

司机端业务流程可划分为：

业务流程中产生的核心业务指标：

1. 注册/登陆阶段：注册用户数、新增用户数
2. 加盟阶段：提交审核用户数、审核通过用户数、新注册司机、累计注册量、老司机量、新司机量
3. 接单阶段：在线司机数、听单司机数、有效听单司机数、中标司机数、中标率、日均中标司机数
4. 决策阶段：决策阶段司机取消订单数
5. 服务：服务平均距离、平均时长、空驶平均距离、空驶平均时长
6. 评价：司机好评率、司机差评率、平均星级
7. 提现：司机余额、提现次数、提现金额

在明确用户的业务过程后，需要根据分析决策的业务，划分数据域，并在相应的数据域下拆解具体的业务过程。

2. 划分数据域

数据域：是联系较为紧密的数据主题的集合，是对业务对象高度概括的概念层归类，目的是便于数据管理与应用。

这里相当于对数据进行分类，类似于我们电脑桌面要建立不同的文件夹来存储数据。我们的数据是面向不同业务人员，比方说市场、运营、客服、风控等人员，而其关注的业务模块大不相同。

而我们技术人员还要给他们提供各种不同的数据指标，找起来工作效率低，服务器计算成本高（你想想在电脑搜索框查某一文件名时，是不是很慢），业务人员也难以及时得到数据。没办法，那我就做个数据的分类吧，方便我们快速找数据，以及未来横向扩展数据。

所以在划分数据域时，我们也要注意：

• 能涵盖当前所有的业务需求
• 能拓展新业务进入已有数据域，或者拓展新的数据域

这里就相当于电脑上的文件夹命名，要包含当前所有的文件（数据），产生新文件时，能够放到已有文件或者是方便新建一个文件。

可以根据对业务需求、各个模块的业务流程进行分析，进行数据域的划分。通常数据域划分可以根据企业部门划分，如客服、运营、市场等；也可以按照业务过程或者业务板块的功能模块划分。

例如网约车体系中用车业务域可划分为如下表所示的数据域，依据实际业务过程进行归纳、抽象得出数据域。

3. 定义指标规范——总线矩阵构建

我们梳理了业务域、数据域、业务过程的整体框架，接下来针对指标规范进行设计。

简单点理解，相当于我们设计了文件夹的一级、二级、三级目录结构规范，现在要对该文件命名结构规范进行设计。

常用的指标基本是按照个人理解给予的命名，并没有特别的规范，比如说日活/月活用户量、近一个月下单量、完单金额等。但随着数据指标的增多，出现了很多限定条件下的指标，比如近7天北京快车下单量这样的指标，这个指标是如何设计得到的，有没有一套指标规范设计呢？

如上图所示，设计指标时需清晰定义业务域=用车业务、数据域=服务域、业务过程=下单、维度=城市、属性=北京、时间周期=近7天、修饰词=快车、度量/原子指标=下单量。通过增加对原子指标的约束条件，规范产生派生指标=近7天北京快车下单量，提供一套通用的指标定义标准，方便不同业务部门的人理解指标含义。

以网约车体系中的服务域为例，制定如下总线矩阵，划分业务过程为下单、派单、决策、开始行程、完单。

总线矩阵是数仓架构师会用的比较多，对于产品人员会比较难理解，其实就类似于数学中矩阵和排列组合，一个原子指标的维度限制条件组合不同，可得到成千上万个派生指标。

总结

本文主要从数据产品角度介绍，如何基于阿里OneData进行网约车指标体系建设。通过对业务分析、数据域划分及总线矩阵构建，来建立一套指标设计规范。通过建立指标规范，可以提升研发和业务方的指标获取效率，为后续自助式分析打下基础。

在设计指标规范过程中发现会产生成千上万个指标，那这些指标哪些是真正给业务方提供指导意义的呢？