实战案例解析:如何参照阿里OneData构建数据指标体系?

在建立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进行网约车指标体系建设。通过对业务分析、数据域划分及总线矩阵构建,来建立一套指标设计规范。通过建立指标规范,可以提升研发和业务方的指标获取效率,为后续自助式分析打下基础。

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

下一篇将会讲解如何根据GSM模型和AARRR模型确定核心业务指标,以及如何设计指标字典。

#作者#

大鹏,公众号:一个数据人的自留地。《数据产品经理修炼手册》作者。

本文

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部