暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

如何统⼀管理纷繁杂乱的数据指标?

大数据真有意思 2020-08-14
860

点击关注上方“知了小巷”,

设为“置顶或星标”,第一时间送达干货。

前文回顾:

元数据中⼼的关键⽬标和技术实现⽅案

数据中台到底怎么建设呢?

到底什么样的企业应该建设数据中台?

数据中台到底是不是大数据的下一站?


前文已经了解到各种类型的元数据,这些元数据有什么⽤?跟数据中台⼜有什么关系呢? 实,元数据在指标管理模型设计数据质量成本治理四个领域都发挥着作⽤,⽽这些领域构成了数据中台OneData数据体系。

 

</> 指标管理



指标是⼀种特定类型的元数据,公司的运营会围绕它进⾏⼯作,可以说,它是业务和数据的交汇点。指标数据能不能⽤,会影响他们的⽇常⼯作。


 

在电商业务中,新⽤⼾销售额是考核市场活动拉新效果的重要指标。⻢漂亮(化名)是市场部⻔的数据分析师,某⼀天,她要给CEO提供⼀份数据报告,报告中有⼀项指标是“新⽤⼾销售额”。孙美丽(化名)是会员中⼼的运营,她每天都会给CEO提供每⽇的新⽤⼾销售额数据。

 

结果有⼀天,CEO看了这两份报告后发现,同⼀⽇的新⽤⼾销售额数值相差很⼤,他判断数据出了问题,责令两个部⻔的负责⼈进⾏排查。排查后发现,市场部⻔对新⽤⼾⼝径的定义和会员中⼼不⼀样:

1. 市场部⻔认定新⽤⼾是⾸次下单并完成⽀付的⽤⼾;

2. 会员中⼼认定新⽤⼾是当⽇新注册⽤⼾。

 

也就是说,市场部⻔认定的新⽤⼾中,可能有之前注册但是没有下过单的客⼾;⽽会员中⼼只包括当⽇注册并完成下单⽀付的⽤⼾。其实,在⽇常⼯作中还有很多类似的问题。

 

造成上述问题的根源是因为指标⼝径不⼀致,⽽我们要构建全局⼀致的指标⼝径,输出企业的指标字典。

 

</> 指标混乱现状


2018年年末开始,⽹易电商数据中台团队对电商业务的核⼼指标进⾏了全⾯的盘点和梳理,为的就是解决指标⼝径不⼀致的问题。原先800个指标,最终梳理完成427个指标,在梳理过程中,总结了7个常⻅的指标问题,对照一下看看自己公司否也存在类似的情况。

指标常见问题:

1. 相同指标名称,口径不一致

2. 相同口径,指标名称不一致

3. 不同限定词,描述相同事实过程的两个指标,相同事实部分口径不一致

4. 指标口径描述不清楚

5. 指标口径描述错误

6. 指标命名难于理解

7. 指标数据来源和计算逻辑不清晰

⼝诀记忆⼀下,⽐如:

同名不同径,同径不同名。

⼝径不清晰,⼝径有错误。

命名难理解,计算不易懂。

来源不清晰,同部不同径。

 

第⼀,相同指标名称,⼝径定义不同。

 

不同的部⻔对相同的“新⽤⼾销售额”,因为⼝径定义的差别,导致指标数值的不⼀致。⽽这种情况是指标管理中最容易出现的情况。⼝径不⼀致,数据也就没办法横向对⽐,失去了数据辅助商业决策的意义。


第⼆,相同⼝径,指标名称不⼀样。

 

这种情况与上⾯相反,⽐如发放优惠券是电商常⻅的促销⼿段,现在你有两个数据产品:⼀个是经营⼤脑,主要展⽰的是企业⽇常经营活动健康度的核⼼指标,它有⼀个指标叫“优惠券抵扣⾦额”;⼀个是市场360,主要是展⽰市场活动效果衡量的指标,它也有⼀个指标叫“优惠券消耗⾦额”。



其实,两者的⼝径定义并没有区别,但是指标名称不同,这会让使⽤指标的⼈疑惑,是不是同⼀个指标,计算逻辑是否⼀致?数据是否可以横向对⽐?

 

第三,不同限定词,描述相同事实过程的两个指标,相同事实部分⼝径不⼀致。

 

这个问题该如何理解呢? 来看⼀个例⼦。

 

⿊卡会员购买⽤⼾和⾮会员购买⽤⼾数,它们描述的都是⽤⼾下单购买商品的相同业务过程,记录的都是购买商品的事实,只是⼀个限定词是⿊卡会员⼀个限定词是⾮会员

 

按照⼀致性原则,虽然是两个指标,但是对于购买⽤⼾数这个相同的事实部分,业务⼝径、计算逻辑应该是⼀致的,但是现实情况却可能不是这样:

1. “⿊卡会员购买⽤⼾数”的⼝径定义是计算周期内去重的(重复购买的⽤⼾只算⼀个),下单并且⽀付成 功的⽤⼾数量;

2. “⾮会员的购买⽤⼾数”的⼝径定义是计算周期内去重的,下单并且⽀付成功,排除关单(“关单”是指在⽤⼾在下单购买成功后,取消订单)的⽤⼾数量。

 

可以看到,对于购买⽤⼾数,这两个指标的⼝径是不⼀致的,⼀个包含关单,⼀个不包含关单。

 

第四,指标⼝径描述不清晰。

 

有些报表上的指标⼝径描述的⽐较笼统。⽐如“关单⾦额”,⼝径描述“关闭订单的⾦额”。不同⼈的理解可能不⼀样,有的⼈会认为是⽀付成功后关闭订单;也有可能是⽀付完成前,取消订单。描述不清晰,就会让⼈们对数据的理解产⽣歧义。

 

第五,指标⼝径描述错误。

 

流量分析数据产品中,有7⽇uv”这个指标,⼝径的定义是7⽇内⽇均uv。根据⼝径描述的计算逻辑,   应该是最近7⽇,每⽇uv相加除以7取平均值。显然,这个定义在业务场景中是有问题的,正确的7⽇uv的⼝径定义应该是7⽇内有登录过,去重的⽤⼾数。

 

第六,指标命名难于理解。

 

有⼀个数据产品的指标名称是ROI”,⼝径定义优惠券销售额/优惠券成本ROI其实是投资回报率的简称,在电商业务场景中,除了优惠劵,商品降价促销都可以计算ROI,所以⽐较好的命名应该是(商品|类⽬|通⽤)优惠劵ROI。所以,指标命名不规范的话,从指标名称中很难看出指标描述的业务过程。

 

最后,指标数据来源和计算逻辑不清晰。

 

如果指标数据来源不清楚,⼀旦这个指标数据异常,就很难去做溯源。另外,有些指标的计算逻辑⽐较复杂,仅仅凭借业务⼝径⼀段描述,使⽤指标的⼈还是⽆法理解这个指标的计算逻辑,这个时候就需要有⼀些伪码或者SQL描述。

 

</> 如何规范化定义指标


那么如果⾯临上面这些指标问题,该如何规范化定义指标呢?如何⾼效、规范化的管理指标...

业务线【电商(游戏、教育、音乐)】

主题域【交易(流量、用户、产品)】:业务过程、维度

业务过程【下单、加入购物车、支付】:原子指标、派生指标

维度【商品、类目、地理、时间】

 

⾸先,⾯向主题域管理。

 

为了提⾼指标管理的效率,需要按照业务线、主题域和业务过程三级⽬录⽅式管理指标(业务线是顶级⽬录)。

 

在⽹易,电商、游戏、⾳乐、传媒、教育都是不同的业务线。在业务线之下,是主题域,指标中的主题域与数仓中的概念是⼀致的,划分标准最好是跟数仓保持⼀致(数仓主题域的划分)。在主题域下⾯还有细分的业务过程,⽐如对于交易域,细分的业务过程有加⼊购物⻋、下单、⽀付。

 

其次,拆分原⼦指标和派⽣指标。

 

为了解决前⾯提到的,“⿊卡购买⽤⼾数”和“⾮会员购买⽤⼾数”,这两个指标对购买⽤⼾数⼝径定义不

⼀致的问题,我们需要引⼊原⼦指标和派⽣指标的管理⽅式。那么什么是原⼦指标,什么是派⽣指标呢?

 

统计周期、统计粒度、业务限定、原⼦指标,组成派⽣指标,所以原⼦指标可以定义为不能够按照上述规则进⼀步拆分的指标

统计周期(近30天)=>统计粒度(商品)=>业务限定(黑卡会员;非会员)=>原子指标(购买用户数)=>派生指标

 

在上述例⼦中,可以这样理解:

1. 购买⽤⼾数是原⼦指标,原⼦指标的⼝径定义是“计算周期内去重的,下单并且⽀付成功的⽤⼾数量,包括关单”;

2. ⿊卡会员和⾮会员都可以认定为业务限定词;

3. 统计粒度是商品粒度的;

4. 统计周期是30天。


这样30天内,商品维度的⿊卡会员购买⽤⼾数和30天内商品维度的⾮会员购买⽤⼾数就作为两个派⽣指标存在,但是他们继承⾃同⼀个原⼦指标。

 

除此之外,还需要指标命名规范。

 

指标命名规范要遵循两个基本的原则:

1. 易懂,就是看到指标的名称,就可以基本判断这个指标归属于哪个业务过程;

2. 统⼀,就是要确保派⽣指标和它继承的原⼦指标命名是⼀致的。

除此之外,指标应该有指标名称和指标标识(或者叫英⽂名)。

 

对于原⼦指标,指标名称适合⽤“动作+度量”的命名⽅式(⽐如注册⽤⼾数、购买⽤⼾数),标识的命名

⽤英⽂简写或者汉语拼⾳缩写⽐较好。

 

对于派⽣指标,指标名称应该严格遵循“时间周期+统计粒度+修饰词+原⼦指标”的命名⽅式,标识命名要

“修饰词_原⼦指标_时间周期”的⽅式。


第四,关联的应⽤和可分析维度。

 

对于使⽤指标的⼈(运营、分析师)了解了这个指标的⼝径定义之后,下⼀步就是要看指标的数值。所以,在全局的指标字典中,还应该有指标被哪些应⽤使⽤,这样⽅便去对应的数据产品或者报表上查看指标的数值。除此之外,还应该有指标的可分析维度,⽅便分析师从不同的维度分析指标的变化趋势。

 

最后⼀个是分等级管理。

 

那这么多指标,数据中台管的过来么?是的,确实管不过来,因为不仅仅是数据中台会产出⼀些公共核⼼指标,业务部⻔也会创建⼀些专属业务部⻔内的指标。那⾯对这么多指标,如何管理呢?可以按照以下原则区分等级,来管理指标。

1. ⼀级指标:数据中台直接产出,核⼼指标(提供给公司⾼层看的)、原⼦指标以及跨部⻔的派⽣指标。

2. ⼆级指标:基于中台提供的原⼦指标,业务部⻔创建的派⽣指标。

不同等级的指标意味着管理⽅式不同:

1. ⼀级指标,要确保指标按时、保证质量产出,指标创建由中台负责;

2. ⼆级指标,允许业务⽅⾃⼰创建,中台不承诺指标的产出时间和质量。

 

</> 指标系统


在了解如何管理指标之后,我们还需要⼀款好⽤的⼯具,帮助我们落实管理⽅法。很多公司喜欢⽤Excel管理指标,觉得Excel上⼿容易,编辑⽐较⽅便。当然Excel并不是⼀个适合指标管理的⼯具,有这样⼏个原因:

1. 难于共享;

2. 缺少权限控制;

3. ⽆法动态更新;

4. 指标⽆法跟数仓的模型动态关联。

 

所以,我们需要⼀个⾯向指标的管理系统

指标系统是基于元数据中⼼构建的⼀个指标管理⼯具,它从元数据中⼼⾃动同步数仓的主题域和业务过程,按照规范化定义创建指标

 

新创建的指标同时会以特定类型的标签,下沉到元数据中⼼对应的表和字段上,这样在数据地图上就可以搜索到表关联的指标。

指标系统还提供了按照指标名称、标识、业务⼝径的检索功能。

既然指标系统能够实现指标的规范化定义,还解决了如何系统化、规范化定义指标的问题,那接下来我们的重点就是如何基于指标系统构建全局的指标字典,因为这是指标治理的最终结果


</> 基于指标系统构建全局的指标字典


指标治理的最终结果,就是要形成⼀个全局业务⼝径⼀致的指标字典。让使⽤指标的⼈,可以通过指标字典,快速了解指标的业务含义和计算过程,不会对指标⼝径产⽣歧义。

数据中台团队必须要有⼀个专⻔负责指标管理的⼈或者⼩组(⼀般不超过3个⼈),最好是数据产品经理来负责,如果没有这个职位,也可以让分析师承担(前提是分析师必须属于中台团队)。构建全局的指标字典分为两个场景:

1. ⼀个是⾯对⼀个新的指标需求,如何基于指标系统完成指标开发流程;

2. 另外⼀个是⾯对已经存在的,混乱的指标现状,如何进⾏全局梳理。

 

先来看第⼀个场景。

这个图详细地描述了新建指标的流程流程中参与的各个⻆⾊

下面是重点强调⼏点:

1. 指标需求评审,需要需求⽅、数据开发、应⽤开发都参加。评审⾸先要确认这是不是⼀个新的指标,并明确它是原⼦指标还是派⽣指标。评审的⽬的就是要⼤家达成⼀致。

2. 评审的结果⼀种是不需要开发,是⼀个已经存在的指标,直接可以通过设计逻辑模型,发布接⼝,获取数据。第⼆种就是需要开发。前者交付时间短,后者需要排期,交付时间⻓。

3. 上⾯提到指标有⼀级和⼆级之分,这个流程适⽤于⼀级指标,对于⼆级指标,可以不需要评审,当然开 发也是由业务⽅开发和发布上线。

 

接下来,是第⼆个场景。

 

除了新建指标的流程,对于很多公司,已经有⼀定的⼤数据业务,但是还不能算是⼀个中台,那这部分公司该如何进⾏⼀次全局的指标梳理呢?

应该有以下⼏个步骤:

1. 成⽴以数据产品或者分析师为核⼼的13⼈的⼯作⼩组,专⻔负责指标的全局梳理;

2. 制定指标梳理计划,明确指标梳理⽬标,覆盖多少个业务线,与业务⽅共同制定时间计划;

3. 对于每⼀个业务线,需要对还在使⽤的数据报表、数据产品进⾏盘点,这⾥顺便可以把没⽤的报表和数据产品应该下线;

4. 对于每⼀个报表和数据产品中涉及的指标,按照以下格式进⾏收集;


5. 对于收集的指标,明确业务⼝径,对于⼝径相同的,应该去除重复,关联的应⽤应该合并,一般可以过滤掉相当⼀部分;

6. 根据指标业务⼝径,明确指标所属的主题域、业务过程;

7. 区分指标类型,对于派⽣指标,要明确指标的统计粒度、修饰词、时间周期以及关联的原⼦指标;

8. 按照指标系统对指标的规范化定义,把整理好的指标录⼊指标系统。

 

通过全局的梳理和新建指标流程的管控,就可以构建⼀个全局⼀致的指标字典了。

 

总结


主要了解了如何构建全局⼀致的指标字典,通过系统+规范的⽅法,解决了数据中台指标⼀致性管理的难题:

1. 数据中台直接产出的核⼼指标必须实施强管理,由数据中台团队的专⼈或者⼩组负责,最好是数据产品经理的⻆⾊。

2. 指标的管理必须结合系统+规范的治理⽅法,明确每个⻆⾊的职责,通过系统化的⽅法实现。

3. 不同的两个指标描述的相同业务过程中的相同事实部分⼝径不⼀致,是指标梳理过程中最常⻅的问题,需要通过拆分原⼦指标和派⽣指标的⽅式解决。


往期推荐:


元数据中⼼的关键⽬标和技术实现⽅案

Hive程序相关规范-有助于调优

HBase内部探险-数据模型

HBase内部探险-HBase是怎么存储数据的

HBase内部探险-一个KeyValue的历险

数据中台到底怎么建设呢?

到底什么样的企业应该建设数据中台?

数据中台到底是不是大数据的下一站?



文章转载自大数据真有意思,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论