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

前言

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

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

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

产品设计、运营同学通常是:我觉得用户会喜欢我们新推出的这个功能,我觉得新推的活动,活动效果会很好…..那领导就要问了,这个“觉得”有什么依据么?怎样衡量用户喜欢这个新增的功能?怎样判断活动效果好,多少人参与或是多少转化?

这样一提问,其实设计者们也云里雾里的,一脸懵逼,别问设计原因,问就是回答其它竞品也有这个功能,所以我们也做…...是不是觉得自己也中招了?

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

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

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

以网约车为例,今天的GMV降低50%,是什么原因导致呢?分析人员回复说:受疫情影响,乘客下单量降低20%。

这是平台当前已有指标,那还有30%呢?是什么问题导致的?于是分析人员一查数,发现在线司机数、接单司机数降低30%,于是匆匆的又把临时想到的这两个指标,简单的描述了一下业务含义,经过一系列的沟通协调,让研发临时添加。

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

二、理解OneData指标规范

既然不提前设计指标体系会出现诸多问题,那指标体设计流程是什么?如何保证指标体系的规范设计呢?下面我们先来看看阿里是如何制定指标规范的。

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

业务域

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

业务过程

:业务过程可以概括为一个个不可拆分的行为事件,如下单、支付、评价等业务过程/事件。这里的事件跟埋点的事件类似,详情可查看

《埋点事件设计》

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

那数据域又是何方神圣?

数据域

:是联系较为紧密的数据主题的集合,是对业务对象高度概括的概念层归类,目的是便于数据管理与应用。简而言之,数据域就类似于我们电脑桌面要建立不同的文件夹来存储数据,这些个文件夹名就是数据域。

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

维度

:是度量的环境,用来反映业务的一类属性,这类属性的集合构成一个维度,可以从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进行网约车指标体系建设。通过对业务分析、数据域划分及总线矩阵构建,来建立一套指标设计规范。通过建立指标规范,可以提升研发和业务方的指标获取效率,为后续自助式分析打下基础。

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

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,716评论 4 364
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,558评论 1 294
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 109,431评论 0 244
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,127评论 0 209
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,511评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,692评论 1 222
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,915评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,664评论 0 202
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,412评论 1 246
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,616评论 2 245
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,105评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,424评论 2 254
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,098评论 3 238
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,096评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,869评论 0 197
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,748评论 2 276
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,641评论 2 271

推荐阅读更多精彩内容