数据指标中心的建设

做好业务分析的重点在于数据分析师要有良好的专业素养：一方面要有过硬的专业技能、了解业务；另一方面要能够通过合作和协调，让分析策略可以落地并正向影响业务。这篇文章将从数据认知开始，给大家讲讲数据分析和指标体系建设。

— 01—业务和数据的闭环

业务和数据，可以理解为映射关系，数据是业务在数字世界里的另一个它。举个例子来说：你衣服鞋子的尺码、喜欢吃什么口味的菜、爱看什么内容的文章、什么时候起床和睡觉等等，所有这些个人的数据都在云端被记录着，它就是你在数字世界里的映射。网上之前流行的一句话很有意思：手机可能比你自己还要了解你。就是因为它里面存储了一个数据的你。
我相信大家都清楚，手机用的越频繁，越多个人的数据被记录，它就会越好用，然后你就会用的更频繁。业务和数据就是这样的闭环促进关系：业务越全面、越深入的被线上化，反过来数据对业务的赋能就会越大。

• 业务数据化：
  业务线上化，存储业务所产生的数据，记录业务；
• 数据业务化：
  分析收集的业务数据，评估业务状态，指导业务发展，提升效率；

图1 业务和数据闭环
— 02—认知：数据、信息和知识

接下来我们会就其中的数据分析环节展开来讲，在这之前，先宏观的了解一下从数据到决策会经历怎样的一个过程。
我们时刻都在被数据所记录着：年龄、身高、体重、消费金额、运动步数等等，如果只是单纯的去看这些数字是没有意义的，要用心去思考数字背后鲜活的业（灵）务（魂）。说到这里，阿北笑着又重复补充到：业务是有灵魂的！当我们从这些数字中发现业务背后的信息，再将这些数据和信息转化成一组规则来辅助我们决策（知识）的时候，数据就会变得很有价值。这个过程就是：从数据到信息，再到决策（知识）。
跟大家举个生活中的例子：体温39度是单纯的数字，背后的信息是发烧了，做出的决策（知识）就是需要去医院看病。

图2 数据-信息-知识
对于上面总结的从数据到决策的过程，我们往往会说成根据数据分析的结果去做决策，虽然这样的说法没问题，但不够直接，实际上我们是基于业务理解去做决策的，而数据是帮助我们加深业务理解的工具。数据赋能业务一般会经历四个环节：数据表现、业务原因、业务策略和作用方式。最开始我们通过数据去评估业务状态，发现业务表现异常，再全面的分析数据并结合一线的调研反馈，反复的进行猜想和数据验证，弄清楚数据表现背后的业务原因，然后思考解决问题的策略，再落地执行，监控后续效果并不断的迭代，直到问题被解决，业务发展进入正轨。

图3 数据赋能业务
再就刚才提到的生病发烧的例子详细解释一下数据赋能业务的过程：体温39度是数据表现，背后的身体原因是发烧了（业务原因），医生说需要打点滴退烧（业务策略），之后你就躺在病床上，护士过来给你输液（作用方式），这些流程走完之后，后续还会要求你持续的测量体温（监控落地效果），如果还一直不退烧的话，可能还需要继续去输液吃药（不断的迭代业务策略），直到最后体温恢复正常（问题被解决），身体进入健康状态（业务发展进入正轨）。
— 03—业务策略的闭环

分析数据定位业务问题，基于业务理解，确定解决策略，到最终正向的影响业务，整个过程中，业务策略存在两个闭环：逻辑闭环和业务闭环。

• 逻辑闭环：
  数据分析的过程，逻辑上要闭环，论据要能够支持结论的成立；
• 业务闭环：
  策略在业务上的落地执行要闭环，不断的调整迭代；

图4 业务策略的闭环
这两个闭环是互相影响的，首先要做到的就是论证逻辑闭环，保证结论可以站得住脚。等真正落地执行的时候，业务上可能行不通，就需要基于新的业务理解去迭代论证逻辑，形成新的逻辑闭环，再去落地执行，直到在业务上可以跑通。所以在数据分析过程中会常出现两类问题：

1. 逻辑闭环相关：
   不接地气，指的是策略的逻辑论证没问题，但离业务上跑通还很远；
2. 业务闭环相关：
   策略没有落地或者落地反馈周期太长，导致业务理解只停留在当时分析数据的节点，没有得到验证反馈；

那我们在工作中怎么判断业务策略是否接地气呢？主要分成两步：

1. 深入思考策略成立的业务假设是什么？
2. 调研判断业务假设是否成立？

举个例子：你设计了一套完整的针对B端商家的权益方案，希望牵引商家按平台的方向去做生意，假设权益方案在逻辑上没问题，但要真正落地有效的话，就会涉及到一些业务假设需要成立：

1. 平台可以很好的触达商家，商家也能够理解权益方案；
2. 权益方案细节，商家真的很在意；
3. ……

接着就需要去调研这些业务假设是否真的成立？如果成立的话，那么该策略落地有效的概率就会很大；如果商家理解不了复杂的权益方案，或者商家对权益根本不在意，那说明该业务策略是不接地气的，就需要及时做出调整。当然，策略是否有效的前置调研验证是很有必要的，但有时候调研结果并不能直接推导出策略有效或者无效，那就需要设计好的落地方案，快速验证迭代。
最后也类比过来，判断某个人是否懂业务：如果这个人通篇都在讲数学逻辑，没有业务判断，或者有些业务判断明显是不成立的，那大概率这个人就不太懂业务。要做出正确的决策首先逻辑上要成立，另外在业务上也要行得通。

— 04—数据分析与指标体系

如今不论是企业还是个人发展，整体都在往数据方向转型，数据变得越来越重要。企业需要数据资产保持行业竞争力、产品需要根据数据分析的结果来迭代、运营需要通过数据来评估活动效果等等，越往后，数据思维、分析能力会逐渐变成横向能力被大家所掌握，人人都会数据分析肯定是未来的趋势。所以我觉得大家在这个窗口期选择数据领域是非常明智的。
建立指标体系是数据分析的第一步。

数据指标中心是规范化开发指标并对其进行管理维护的系统，将指标的组成部分解耦拆分开来，并在逻辑表中进行规范性的定义，在此基础上，后续可以按照一定规则进行自由拼装，实现自定义指标的功能。

在我们日常的数据工作中，指标的重要性毋庸置疑，指标来源于业务的场景化呈现，业务也通过指标来透视出问题，但也正因为如此重要，使用如此频繁，所以导致指标也出现各种混乱、难用、难找等等问题。所以我们必须有一套合理合规的指标治理方法，并将这套方法转化成工具，通过固定流程去约束原本不可控的行为。接下来我们就看看，指标治理的有那些方法论？以及这些方法是如何设计成系统，也就是我们说的——数据指标中心。

— 05—如何建立指标体系

1、首先定义指标并归集到对应的主题域指标的本质是量化了的目标，比如常见的例子：①我们要把用户的盘子做大，那对应的量化指标就是已注册用户数；②我们要统计今天的销售额，那对应的量化指标就是总支付金额；③我们要衡量一次活动的效果，那对应的量化指标就是下单率。
从上面的例子我们可以看到，我们比较常用的几个类型的指标就是，存量型指标（已注册用户数）、事务型指标（支付金额）、转化型指标（下单率），其它还有比例型、统计型、排名型等，这些比较不常用，就不在此赘述了。
这些不同类型的指标，分散在我们产品中的不同功能模块中，所以为了更好地规范与管理，我们需要将这些指标也按照主题域的方式归集起来。主题域在“仓库模型中心”进行创建与定义，在这里只需要将对应的指标划归到对应的主题域就行了。

2、然后是拆分原子指标与派生指标先来看看原子指标跟派生指标这两个概念具体是什么？①原子指标：是事实表中，某一个字段的统计值（sum、count、max、min、avg），如下单用户数，下单金额等；②派生指标：是基于原子指标，进行维度组合后产生的指标，如近1天商城下单用户数，本周商城黄金会员下单金额等。

原子指标无业务意义，它只是预定义的代码片段而已。业务中用到的指标基本都是派生指标。

3、接着定义原子指标与派生指标的生产逻辑

在本章的开头有提到这样一句话：“将指标的组成部分解耦拆分开来，并在逻辑表中进行规范性的定义”，这个解耦跟定义的过程，就是把一个派生指标拆解成原子指标、时间周期、限定维度、聚合粒度，然后再重新拼装，生成新的派生指标的过程：

在上面这个例子中可以这样来理解：①统计周期是这个原子指标进行统计运算的时间范围，在这里是本周；②聚合粒度是指标的主体，即按照哪个维度来来进行聚合，这里是黄金会员；③限定维度是限制原子指标的计算范围，这里限定在商城，即只计算商城相关的数据；④原子指标则是预定义的某个字段计算规则。在这里是下单金额的累加。

4、最后通过指标管理平台对指标进行规范生产（1）规范化指标命名命名规范对于后期大量的指标管理来说非常重要，因为当指标多起来的时候，你要找一个指标经常需要用到检索功能，而检索的前提是你对指标有一些前置的认知。这就需要我们对指标的命名进行规范化。
指标命名规范有三个重点：①简洁明了，易懂：最好是只要看到指标名，不需要看注释就可以知道它的意思，归属等；②格式统一：每个指标的格式都是一样的，通过组合不同模块的命名拼凑起来；③生成统一：原子指标与继承自它的派生指标的规范是一致的。
以商城相关的指标为例：①所有业务下单跟支付指标，默认以主单为统计口径，不用带“主单”相关字眼，如商城下单次数；当统计口径为“子单”时则需要在命名中标出，如：商城子单下单次数；
②所有与人相关指标默认以“注册用户”为统计实体，不需要带“用户”相关字眼，如访问次数；当统计主体为“游客”时则需要在命名中标出，如：游客访问次数；
③无指定业务范围的指标默认为平台指标，不需要带“平台”相关字眼，如近30天支付人数。如果有限定业务范围，则需要加上业务名称，如：商城-近30天支付人数；
④无指定时间周期的指标默认为“近1天”（但需要保存小时粒度，便于后续下钻），不需要带“时间”相关字眼，如注册人数。如果有限定时间范围，则需要加上时间周期：如：近7天注册人数。
完整的命名的规范为：商城（业务板块）+用户（实体）+近7天（统计周期）+新增（业务动作）+子单（类型）+单日（间隔周期）+平均（统计运算规则）+支付金额（原子指标），如：商城-用户近7天新增子单单日平均支付金额（没有的部位可留空，如：商城-汇总支付金额）。
⑵规范化统计口径当指标主体为实体（名词）：游客、用户、商品等，则只需定义单位为“人/个” 即可。如：游客人数、用户人数、商品个数。
当指标为业务动作（动词）：如点击、支付、下单等，单位除定义为“次数” 外，还需考虑跟这个动作关联的实体的单位，如“商品”时需要定义多一个单位“笔数”；为“用户”时则需要定义多一个“人数”等；所以一个下单动作的指标，会有多个不同的统计口径：下单次数，下单人数，下单笔数，下单金额……
在定义指标名时需要详细列出，避免出现“下单数”这样模糊的指标。
⑶规范化指标等级我们都知道，随着公司的发展，产品在不断地进行迭代，功能的增删与业务的变化势必也影响着指标的发展，一些旧的指标被不断更新或废弃，而新的指标也不断增加。这时对指标的管理也成了一个问题，哪些指标由谁开发？后续谁来维护……
一个比较好的解决方案就是对指标进行等级划分，可以划分为两个等级：①一级指标：即原子指标与小部分全平台的核心指标，从各业务部门收集需求后，统一由数据中台来产出，有一套完整规范的开发流程：需求-评审-排期-开发-测试-验收-上线。所有维护管理工作都由中台负责；
②二级指标：即派生指标，由各业务部门自定通过指标中心生成，没有严格的开发流程，各业务部门根据需要自行创建，但需要遵守命名规范。所有维护管理工作由部门内部负责。

— 06—业务合作与职责边界

指标中心建成后，还需要将在整个数据分析过程中各个角色的职责边界理清楚。公司在追求业务商业价值最大化的过程中，会涉及到多个部门间的合作。

• 业务产品经理：
  负责协调研发、测试、设计等部门，从实际业务需求出发，上线产品；
• 数据开发工程师：
  根据数据产品经理的需求，按模型、按主题等去加工业务数据；
• 数据分析师：
  建立体系的分析框架评估业务状态，定位业务问题，指导业务的发展；
• 数据产品经理：
  负责协调数据开发同学将业务数据模块化和体系化，同时将业务分析框架产品化，提升数据赋能的效率；
• 运营：
  根据业务方向，通过短期的激励活动，引导用户认识到产品的长期价值；

在实际的工作中，涉及的部门会更多，比如还会有算法部门、研发部门、用户研究部门等等，这里就不一一展开跟大家讲了。

具体的合作过程：首先是业务产研团队基于实际需求，上线产品，当业务数据被收集上来以后，会同步到数据仓库，数据开发工程师根据数据产品经理的需求对数据进行加工处理，数据分析师会全面有逻辑的去拆解和分析业务，并同数据产品经理一起合作把分析框架沉淀在数据产品上。数据分析师、数据产品经理和数据开发工程师一起搭建了整个业务的数据体系，然后对外输出：评估业务状态、数据支持运营活动、分析产品迭代效果等等。