作者介绍 @小风 数据中台产品负责人; UBDC全域大数据峰会“灯塔人物”; 擅长埋点模型、指标治理,数仓架构等; 《大数据实践之路:数据中台+数据分析+产品应用》作者; “数据人创作者联盟”成员。 在我们日常的数据工作中,指标的重要性毋庸置疑,指标来源于业务的场景化呈现,业务也通过指标来透视出问题,但也正因为如此重要,使用如此频繁,所以导致指标也出现各种混乱、难用、难找等等问题。所以我们必须有一套合理合规的指标治理方法,并将这套方法转化成工具,通过固定流程去约束原本不可控的行为。接下来我们就看看,指标治理的有那些方法论?以及这些方法是如何设计成系统,也就是我们说的——数据指标中心 01 数据指标中心的定位是什么 数据指标中心是规范化开发指标并对其进行管理维护的系统,将指标的组成部分解耦拆分开来,并在逻辑表中进行规范性的定义,在此基础上,后续可以按照一定规则进行自由拼装,实现自定义指标的功能。 02 数据指标中心应该如何设计 1、首先定义指标并归集到对应的主题域 指标的本质是量化了的目标,比如常见的例子: ①我们要把用户的盘子做大,那对应的量化指标就是已注册用户数; ②我们要统计今天的销售额,那对应的量化指标就是总支付金额; ③我们要衡量一次活动的效果,那对应的量化指标就是下单率。 从上面的例子我们可以看到,我们比较常用的几个类型的指标就是,存量型指标(已注册用户数)、事务型指标(支付金额)、转化型指标(下单率),其它还有比例型、统计型、排名型等,这些比较不常用,就不在此赘述了。 这些不同类型的指标,分散在我们产品中的不同功能模块中,所以为了更好地规范与管理,我们需要将这些指标也按照主题域的方式归集起来。主题域在“仓库模型中心”进行创建与定义,在这里只需要将对应的指标划归到对应的主题域就行了。 2、然后是拆分原子指标与派生指标 先来看看原子指标跟派生指标这两个概念具体是什么? ①原子指标:是事实表中,某一个字段的统计值(sum、count、max、min、avg),如下单用户数,下单金额等; ②派生指标:是基于原子指标,进行维度组合后产生的指标,如近1天商城下单用户数,本周商城黄金会员下单金额等。 原子指标无业务意义,它只是预定义的代码片段而已。业务中用到的指标基本都是派生指标。 3、接着定义原子指标与派生指标的生产逻辑 在本章的开头有提到这样一句话:“将指标的组成部分解耦拆分开来,并在逻辑表中进行规范性的定义”,这个解耦跟定义的过程,就是把一个派生指标拆解成原子指标、时间周期、限定维度、聚合粒度,然后再重新拼装,生成新的派生指标的过程: 在上面这个例子中可以这样来理解: ①统计周期是这个原子指标进行统计运算的时间范围,在这里是本周; ②聚合粒度是指标的主体,即按照哪个维度来来进行聚合,这里是黄金会员; ③限定维度是限制原子指标的计算范围,这里限定在商城,即只计算商城相关的数据; ④原子指标则是预定义的某个字段计算规则。在这里是下单金额的累加。 4、最后通过指标管理平台对指标进行规范生产 ⑴规范化指标命名 命名规范对于后期大量的指标管理来说非常重要,因为当指标多起来的时候,你要找一个指标经常需要用到检索功能,而检索的前提是你对指标有一些前置的认知。这就需要我们对指标的命名进行规范化。 指标命名规范有三个重点: ①简洁明了,易懂:最好是只要看到指标名,不需要看注释就可以知道它的意思,归属等; ②格式统一:每个指标的格式都是一样的,通过组合不同模块的命名拼凑起来; ③生成统一:原子指标与继承自它的派生指标的规范是一致的。 以商城相关的指标为例: ①所有业务下单跟支付指标,默认以主单为统计口径,不用带“主单”相关字眼,如商城下单次数;当统计口径为“子单”时则需要在命名中标出,如:商城子单下单次数; ②所有与人相关指标默认以“注册用户”为统计实体,不需要带“用户”相关字眼,如访问次数;当统计主体为“游客”时则需要在命名中标出,如:游客访问次数; ③无指定业务范围的指标默认为平台指标,不需要带“平台”相关字眼,如近30天支付人数。如果有限定业务范围,则需要加上业务名称,如:商城-近30天支付人数; ④无指定时间周期的指标默认为“近1天”(但需要保存小时粒度,便于后续下钻),不需要带“时间”相关字眼,如注册人数。如果有限定时间范围,则需要加上时间周期:如:近7天注册人数。 完整的命名的规范为:商城(业务板块)+用户(实体)+近7天(统计周期)+新增(业务动作)+子单(类型)+单日(间隔周期)+平均(统计运算规则)+支付金额(原子指标),如:商城-用户近7天新增子单单日平均支付金额(没有的部位可留空,如:商城-汇总支付金额)。 ⑵规范化统计口径 当指标主体为实体(名词):游客、用户、商品等,则只需定义单位为“人/个” 即可。如:游客人数、用户人数、商品个数。 当指标为业务动作(动词):如点击、支付、下单等,单位除定义为“次数” 外,还需考虑跟这个动作关联的实体的单位,如“商品”时需要定义多一个单位“笔数”;为“用户”时则需要定义多一个“人数”等;所以一个下单动作的指标,会有多个不同的统计口径:下单次数,下单人数,下单笔数,下单金额…… 在定义指标名时需要详细列出,避免出现“下单数”这样模糊的指标。 ⑶规范化指标等级 我们都知道,随着公司的发展,产品在不断地进行迭代,功能的增删与业务的变化势必也影响着指标的发展,一些旧的指标被不断更新或废弃,而新的指标也不断增加。这时对指标的管理也成了一个问题,哪些指标由谁开发?后续谁来维护…… 一个比较好的解决方案就是对指标进行等级划分,可以划分为两个等级: ①一级指标:即原子指标与小部分全平台的核心指标,从各业务部门收集需求后,统一由数据中台来产出,有一套完整规范的开发流程:需求-评审-排期-开发-测试-验收-上线。所有维护管理工作都由中台负责; ②二级指标:即派生指标,由各业务部门自定通过指标中心生成,没有严格的开发流程,各业务部门根据需要自行创建,但需要遵守命名规范。所有维护管理工作由部门内部负责。 03 数据指标中心最终呈现是怎么样 将我们上述讲的所有方法论,内化到对应的功能,然后把功能集合到一个产品里,就是我们常说的指标管理平台,后续所有的指标申请、新建、更新、下架归档、字典等,都在这个系统里去实现,也就实现了我们指标的收口与规范化开发。
发表评论 取消回复