在数据指标概念=0时，业务方按“我觉得”来办事，难以衡量效果。
产品设计、运营同学通常是：我觉得用户会喜欢我们新推出的这个功能，我觉得新推的活动，活动效果会很好…..那领导就要问了，这个“觉得”有什么依据么？怎样衡量用户喜欢这个新增的功能？怎样判断活动效果好，多少人参与或是多少转化？
这样一提问，其实设计者们也云里雾里的，一脸懵逼，别问设计原因，问就是回答其它竞品也有这个功能，所以我们也做…...
是不是觉得自己也中招了？
不过已经有大批产品人员已经意识到传统的盲目设计、抄袭式设计时代已经过去，数字化产品时代已到来的现状，开始尝试用数据指标来辅助业务决策。于是开始进入下一阶段…
此时数据指标概念=0.5，有单点数据指标，但难以看出整体业务问题。
这种情况下通常是想到什么业务指标，就用什么业务指标。比方说看到神策、友盟数据分析类厂商通常会用GMV、日活用户、月活用户、PV、UV、页面停留时长等数据，于是产品设计人员先将其照搬进来，再结合具体使用的时候，会想到一些指标，然后逐个往上加。
以网约车为例，今天的GMV降低50%，是什么原因导致呢？
分析人员回复说：受疫情影响，乘客下单量降低20%。
这是平台当前已有指标，那还有30%呢？是什么问题导致的？于是分析人员一查数，发现在线司机数、接单司机数降低30%，于是匆匆的又把临时想到的这两个指标，简单的描述了一下业务含义，经过一系列的沟通协调，让研发临时添加。
这种方式会存在什么问题呢？
1）指标修改成本大。研发团队需要重新进行数据采集、清洗、存储工作。
2）取值定义不清晰，数据不准确。
3）指标缺乏定义规范，各部门理解难度大。会产生一些重复指标，如指标名称相同，含义不同，例如都叫注册司机，一种定义的是注册手机号成功即为注册司机；一种定义的是加盟成功了的是注册司机。
4）存储、计算、研发成本高：没有统一的规范管理，造成了重复计算的资源浪费；数据的层次和粒度不清晰，使得重复存储严重。
既然不提前设计指标体系会出现诸多问题，那指标体设计流程是什么？如何保证指标体系的规范设计呢？下面我们先来看看阿里是如何制定指标规范的。
以维度建模作为理论基础，构建总线矩阵，定义业务域、数据域、业务过程、度量/原子指标、维度、维度属性、修饰词、修饰类型、时间周期、派生指标等。
业务域：比数据域更高维度的业务划分方法，适用于特别庞大的业务系统，且业务板块之间的指标或业务重叠性较小。例如用车业务板块包含乘客端、司机端，电商业务板块包含商城、返利模块。
业务过程：业务过程可以概括为一个个不可拆分的行为事件，如下单、支付、评价等业务过程/事件。这里的事件跟埋点的事件类似，详情可查看《埋点事件设计》
看到这一系列的名词，很多人可能就开始懵逼了，业务域倒还能理解，简单来说就是对不同业务的分类；业务过程也容易理解，相当于画业务流程图呗。
那数据域又是何方神圣？
数据域：是联系较为紧密的数据主题的集合，是对业务对象高度概括的概念层归类，目的是便于数据管理与应用。
简而言之，数据域就类似于我们电脑桌面要建立不同的文件夹来存储数据，这些个文件夹名就是数据域。
维度、维度属性、修饰这些怎么理解？有什么用途？
维度：是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，可以从who-where-when-what层面来看。
维度属性：维度属性隶属于维度，相当于维度的具体说明，如用户维度中性别为男、女。
修饰词：指除了统计维度以外指标的业务场景。
修饰类型：对修饰词的抽象划分。
简而言之，维度和修饰都可以理解为原子指标的一些限定条件，懂sql的会更好理解一些，一般是写sql时，放在where语句后边的。
度量/原子指标：原子指标和度量含义相同，某一业务行为事件下的度量，是业务定义中不可拆分的指标，如注册数。
时间周期：用来明确数据统计的时间范围或是时间点，如最近30天、自然周、截至当日等。
指标类型：包含原子指标、派生指标。
原子指标 = 行为事件+度量
派生指标 = 一个原子指标+多个修饰词+时间周期
例如：原子指标=完单量，派生指标=近一周iOS乘客完单量，包含时间周期=近一周，修饰词=iOS，维度=乘客，原子指标=完单量。
接下来参考阿里的onedata数据标准，搭建网约车体系中的数据指标。
业务背景：用车业务是网约车整体业务中的一个核心，处于多次循环迭代中，存在指标定义不规范，业务方频繁提出新增指标，技术修改难度大等问题，所以目前需要从业务整体角度重新构建指标体系。
业务目标：标准化指标体系，提升指标提取工作效率。
行动：在构建指标体系的过程中，首要动作要明确指标分类和约束指标命名方式，使各个指标能够做到见名知意、减少沟通成本，这里我们参照阿里对指标的划分，来规范建设指标体系。
第一步：调研业务需求与分析业务流程
1.调研业务需求
充分的业务调研是指标体系构建的基础，在数据指标体系搭建项目启动前，需要与各业务方详细了解具体业务、梳理清楚关键业务流程。
需求采集可分为定量、定性采集两种类型，定量地发放调研问卷形式，广泛采集业务需求；定性地进行用户访谈，深度挖掘业务应用场景和核心需求。
2.分析业务流程
根据阿里巴巴onedata的最佳实践，业务过程可以概括为一个个不可拆解的行为事件。为梳理数据之间的逻辑关系和流向，首先要理解用户的业务过程，了解业务过程中涉及的数据系统。
下面以网约车体系为例，梳理司机端、乘客端的业务流程以及数据指标。
乘客端流程可划分为：注册/登陆、下单、服务、支付、评价/客服投诉。
核心流程中所产生的业务指标：
1） 注册/登陆阶段：新用户数、用户数、不同渠道用户数
2） 下单阶段：下单量、新用户下单量、老用户下单量、不同城市下单量数据、不同车型下单量数据、下单成功用户数
3） 决策阶段：议价订单数、非议价订单数、决策阶段用户主动取消订单数、决策阶段超时取消数、数加价完成订单数、减价完成订单数
4） 服务阶段：下单成功用户数、订单时长、下单成功率、完单量、完单率、完单用户数
5） 支付阶段：订单金额、订单平均金额、订单优惠金额、计费差额
6） 评价阶段：好评率、差评率
司机端业务流程可划分为：
业务流程中产生的核心业务指标：
1） 注册/登陆阶段：注册用户数、新增用户数
2） 加盟阶段：提交审核用户数、审核通过用户数、新注册司机、累计注册量、老司机量、新司机量
3） 接单阶段：在线司机数、听单司机数、有效听单司机数、中标司机数、中标率、日均中标司机数
4） 决策阶段：决策阶段司机取消订单数
5） 服务：服务平均距离、平均时长、空驶平均距离、空驶平均时长
6） 评价：司机好评率、司机差评率、平均星级
7） 提现：司机余额、提现次数、提现金额
在明确用户的业务过程后，需要根据分析决策的业务，划分数据域，并在相应的数据域下拆解具体的业务过程。
第二步：划分数据域
数据域：是联系较为紧密的数据主题的集合，是对业务对象高度概括的概念层归类，目的是便于数据管理与应用。
这里相当于对数据进行分类，类似于我们电脑桌面要建立不同的文件夹来存储数据。我们的数据是面向不同业务人员，比方说市场、运营、客服、风控等人员，而其关注的业务模块大不相同。
而我们技术人员还要给他们提供各种不同的数据指标，找起来工作效率低，服务器计算成本高（你想想在电脑搜索框查某一文件名时，是不是很慢），业务人员也难以及时得到数据。没办法，那我就做个数据的分类吧，方便我们快速找数据，以及未来横向扩展数据。
所以在划分数据域时，我们也要注意：
1） 能涵盖当前所有的业务需求
2） 能拓展新业务进入已有数据域，或者拓展新的数据域
这里就相当于电脑上的文件夹命名，要包含当前所有的文件（数据），产生新文件时，能够放到已有文件或者是方便新建一个文件。
可以根据对业务需求、各个模块的业务流程进行分析，进行数据域的划分。通常数据域划分可以根据企业部门划分，如客服、运营、市场等；也可以按照业务过程或者业务板块的功能模块划分。
例如网约车体系中用车业务域可划分为如下表所示的数据域，依据实际业务过程进行归纳、抽象得出数据域。
第三步：定义指标规范——总线矩阵构建
我们梳理了业务域、数据域、业务过程的整体框架，接下来针对指标规范进行设计。
简单点理解，相当于我们设计了文件夹的一级、二级、三级目录结构规范，现在要对该文件命名结构规范进行设计。
常用的指标基本是按照个人理解给予的命名，并没有特别的规范，比如说日活/月活用户量、近一个月下单量、完单金额等。但随着数据指标的增多，出现了很多限定条件下的指标，比如近7天北京快车下单量这样的指标，这个指标是如何设计得到的，有没有一套指标规范设计呢？
如上图所示，设计指标时需清晰定义业务域=用车业务、数据域=服务域、业务过程=下单、维度=城市、属性=北京、时间周期=近7天、修饰词=快车、度量/原子指标=下单量。通过增加对原子指标的约束条件，规范产生派生指标=近7天北京快车下单量，提供一套通用的指标定义标准，方便不同业务部门的人理解指标含义。
以网约车体系中的服务域为例，制定如下总线矩阵，划分业务过程为下单、派单、决策、开始行程、完单。
总线矩阵是数仓架构师会用的比较多，对于产品人员会比较难理解，其实就类似于数学中矩阵和排列组合，一个原子指标的维度限制条件组合不同，可得到成千上万个派生指标。
本文主要从数据产品角度介绍，如何基于阿里OneData进行网约车指标体系建设。通过对业务分析、数据域划分及总线矩阵构建，来建立一套指标设计规范。通过建立指标规范，可以提升研发和业务方的指标获取效率，为后续自助式分析打下基础。
CIO之家 www.ciozj.com 公众号:imciow