数据指标治理的痛点和目标

米苏_momo

于 2023-03-09 16:40:41 发布

阅读量200

点赞数 1

分类专栏：数据治理文章标签：数据仓库

本文链接：https://blog.csdn.net/qq_41537880/article/details/129425808

版权

数据治理专栏收录该内容

1 篇文章 0 订阅

订阅专栏

一、指标提质的工作主要分为两个阶段

A、面对已存在的、混乱的旧指标现状，进行全业务的指标梳理与重建；

B、约束新指标需求，规范化指标开发流程

二、指标提质需要达到的目标

A阶段：

1、输出全局指标字典：用于相关使用人员检索、查询、确认；

2、调整指标的呈现：从数仓字段到报表、数据产品的功能上，对梳理后的指标进行优化、重整；

3、指导数仓的重构：重新规划数仓分层与数据加工流程。

B阶段：

1、制定指标需求审核流程；

2、输出指标作业手册，从指标的变更、动议到方案、执行，制定严格的流程；

3、研发指标系统，规范化指标开发流程，并最终将指标落地到指标字典。

三、针对当前业务痛点调研,指标混乱的原因主要有以下 7 个方面（4 个不一致，3 个不清晰）

1、相同指标名称，口径不一致

如对于 “新用户” 的定义：运营部的口径是：首次下单并完成支付的用户。产品部的口径是：当日新增注册的用户。两者描述的是不同的目标用户群，但由于命名上相同，所以在使用上容易让人混淆。

2、相同口径，不同指标名称

如 “优惠券” 的相关指标：衡量企业日常经营活动的健康度：优惠券抵扣金额。衡量市场活动效果：优惠券消耗金额。两者都是衡量优惠券抵扣的金额，但由于不同名，所以导致认知上出现了偏差。

3、限定词不同，但业务事实相同的两个指标，描述事实部分的口径不一致

如涉及到 “购买” 这个业务事实的相关指标：白金会员的支付用户数中，“支付用户数” 的口径定义是：统计周期内下单并且成功支付的去重用户数。黄金会员的支付用户数中，“支付用户数” 的口径定义是：统计周期内下单并且支付成功，并排除退单的去重用户数。两者描述的都是 “用户支付商品订单” 的这个业务过程，记录都是 “支付” 这个事实，区别在于，一个限定词是白金会员，另外一个是黄金会员。但根据一致性原则，虽然这两个指标不同，但是“支付”这个事实是相同的，所以“支付用户数”这个指标的业务口径、计算逻辑应该是一致的。

4、指标口径与计算逻辑不一致

这个问题的根本是指标的需求方或开发人员对于指标的认识不清晰，导致指标在开发逻辑上产生了错误导致。如 “近 7 日 UV” 这个指标：正确的定义是：最近 7 天内，有登录过的去重用户数。但是在实际应用场景中，有的会定义成：“7 日日均 UV” 也就是近 7 日，每日的 UV 相加除以 7 取平均值。这个问题在梳理的过程中是比较难发现的，因为它涉及到计算逻辑跟口径之间的校准，所以需要更仔细地梳理指标开发逻辑。

5、指标口径不清晰

部分指标口径的描述比较笼统，或者部分名词具有多义性。如描述笼统的 “关单金额” 的口径描述是 “关闭订单的金额”，但关闭订单会有两种理解，1 是支付后退款，2 是支付前取消；名词多义性的：“地址” 这个维度，有多种涵义，如户籍地址、常住地地址、IP地址、GPS 地址等；指标描述不清晰，就会让使用者产生误解，所以在记录的时候，必须对这些容易产生误解的地方进行标注。

6、指标命名不清晰

在实际的业务操作过程中，因为各业务部门只着眼于自己的业务，没有进行全局的设计，所以有很多指标在自己的部门内部使用是没有问题，但是跟其他部门沟通时就会产生歧义，如 ROI、销售额、支付人数等。这些词都是普通名词（也即原子指标），是没有一个具体的指称的，所以必须将这些普通名词都加上具体指称的业务对象（也即指标的聚合粒度），变成专有名词，如： xx渠道 ROI，或是xx活动 ROI； xx专题销售额，或是全平台销售额； xx课程支付人数，或是xx专题支付人数。除此之外，所有的指标都包含了一定的统计周期，只要涉及到具体的数值，就必然要加上统计周期，所有的指标，也都是在最小粒度上去累加出来的，如近一个月xx专题支付人数，是 sum 了 30 个近一天xx专题支付人数，而近一天xx专题支付人数，是 sum 了 24 个近一小时xx专题支付人数，然后到分、到秒。具体需要聚合到什么粒度，根据具体的需求来设计，所以上述的指标需要调整成：近一周xx渠道 ROI；近一月xx专题销售额；近一年xx课程支付人数。

7、指标来源和计算逻辑不清晰

这个问题主要出现在一个指标可以通过多个数据源，不同的计算逻辑分别统计得出。比如：某个课程的销售额，既可以从课程的角度，对单个课程的销售金额进行累加；也可以从用户的角度，对购买过该课程的用户的子单的支付金额进行计算。如果指标有多个来源，就需要进行来源统一，否则，如果来源不清楚，一旦指标发生问题，很难去溯源定位。另外，有些指标的计算逻辑比较复杂，仅仅凭借业务口径一段描述，使用指标的人还是无法理解这个指标的计算逻辑，这个时候就需要有一些伪码或者 SQL 描述。