02 | 数据中台笔记-数据指标的管理

一、指标口径问题

在电商业务中，新用户销售额是考核市场活动拉新效果的重要指标。马漂亮（化名）是市场部门的数据分析师，某一天，她要给 CEO 提供一份数据报告，报告中有一项指标是“新用户销售额”。孙美丽（化名）是会员中心的运营，她每天都会给 CEO 提供每日的新用户销售额数据。
结果有一天，CEO 看了这两份报告后发现，同一日的新用户销售额数值相差很大，他判断数据出了问题，责令两个部门的负责人进行排查。排查后发现，市场部门对新用户口径的定义和会员中心不一样：

市场部门认定新用户是首次下单并完成支付的用户；
会员中心认定新用户是当日新注册用户。

二、指标常见问题

同名不同径，同径不同名。
口径不清晰，口径有错误。
命名难理解，计算不易懂。
来源不清晰，同部不同径。

1.相同指标名称，口径定义不同

见上述的例子，各管各的到最后出来的结果不一样。

2.相同口径，指标名称不一样

这种情况与上面相反，比如发放优惠券是电商常见的促销手段，现在你有两个数据产品：

一个是经营大脑，主要展示的是企业日常经营活动健康度的核心指标，它有一个指标叫“优惠券抵扣金额”；
一个是市场 360，主要是展示市场活动效果衡量的指标，它也有一个指标叫“优惠券消耗金额”。
其实，两者的口径定义并没有区别，但是指标名称不同，这会让使用指标的人疑惑，是不是同一个指标，计算逻辑是否一致？数据是否可以横向对比？

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

这个问题该如何理解呢？来看一个例子。
黑卡会员购买用户和非会员购买用户数，它们描述的都是用户下单购买商品的相同业务过程，记录的都是购买商品的事实，只是一个限定词是黑卡会员，一个限定词是非会员。
按照一致性原则，虽然是两个指标，但是对于购买用户数这个相同的事实部分，业务口径、计算逻辑应该是一致的，但是现实情况却可能不是这样：

“黑卡会员购买用户数”的口径定义是计算周期内去重的（重复购买的用户只算一个），下单并且支付成功的用户数量；
“ 非会员的购买用户数”的口径定义是计算周期内去重的，下单并且支付成功，排除关单（“关单”是指在用户在下单购买成功后，取消订单）的用户数量。
你能看到，对于购买用户数，这两个指标的口径是不一致的，一个包含关单，一个不包含关单。

4.指标口径描述不清晰

比如“关单金额”，口径描述“关闭订单的金额”。不同人的理解可能不一样，有的人会认为是支付成功后关闭订单；也有可能是支付完成前，取消订单。描述不清晰，就会让人们对数据的理解产生歧义。

5.指标口径描述错误

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

6.指标命名难于理解

不难理解ads_jkdjjkljks_ksafkl 诸如此类

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

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

三、如和规范化定义指标

1.面向主题域

指标中的主题域与数仓中的概念是一致的，划分标准最好是跟数仓保持一致

eg:销售分析”就是一个分析领域，这个“销售分析”所涉及到的分析对象有商品、供应商、顾客、仓库等，那么数仓主题就确定为商品主题、供应商主题、顾客主题、仓库主题，“销售分析”就可以作为一个主题域；

2.拆分原子指标和派生指标

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

引用前面的例子：

购买用户数是原子指标，原子指标的口径定义是“计算周期内去重的，下单并且支付成功的用户数量，包括关单”；
黑卡会员和非会员都可以认定为业务限定词；
统计粒度是商品粒度的；
统计周期是 30 天。
这样 30 天内，商品维度的黑卡会员购买用户数和 30 天内商品维度的非会员购买用户数就作为两个派生指标存在，但是他们继承自同一个原子指标。

3.命名规范

根据所在公司定义的术语表，或者分层规范见表或者任务这个没必要细说，反正记住命名要规范就行。

4.分等级管理

一级指标，要确保指标按时、保证质量产出，指标创建由中台负责；
二级指标，允许业务方自己创建，中台不承诺指标的产出时间和质量。

5.指标系统

在了解如何管理指标之后，我们还需要一款好用的工具，帮助我们落实管理方法。我观察到，很多公司喜欢用 Excel 管理指标（本博主所工作过的公司就是用的excel，也是大多数公司所用的），觉得 Excel 上手容易，编辑比较方便。在我看来，Excel 并不是一个适合指标管理的工具，有这样几个原因：
难于共享；
缺少权限控制；
无法动态更新；

大公司有自己的指标管理系统如下图：

6.构建全局指标字典

构建全局的指标字典分为两个场景：

一个是面对一个新的指标需求，如何基于指标系统完成指标开发流程；
另外一个是面对已经存在的，混乱的指标现状，如何进行全局梳理。
先来看第一个场景。

指标需求评审，需要需求方、数据开发、应用开发都参加。评审首先要确认这是不是一个新的指标，并明确它是原子指标还是派生指标。评审的目的就是要大家达成一致。
评审的结果一种是不需要开发，是一个已经存在的指标，直接可以通过设计逻辑模型（具体我会在数据服务章节讲），发布接口，获取数据。第二种就是需要开发。前者交付时间短，后者需要排期，交付时间长。
上面我提到指标有一级和二级之分，这个流程适用于一级指标，对于二级指标，可以不需要评审，当然开发也是由业务方开发和发布上线。

接下来，我们来看第二个场景。
除了新建指标的流程，对于很多公司，已经有一定的大数据业务，但是还不能算是一个中台，那这部分公司该如何进行一次全局的指标梳理呢？我认为应该有以下几个步骤：
成立以数据产品或者分析师为核心的 1～3 人的工作小组，专门负责指标的全局梳理；
制定指标梳理计划，明确指标梳理目标，覆盖多少个业务线，与业务方共同制定时间计划；
对于每一个业务线，需要对还在使用的数据报表、数据产品进行盘点，这里顺便可以把没用的报表和数据产品应该下线；