为什么要构建数据指标体系？我们所需要的并不是数据，而是数据背后映射的洞察。在业务发展过程中，会产生大量的数据，单看数据是没有价值的，只有和业务相结合转化为信息，再经过处理才能体现其价值。
对于业务数据而言，通常分为两项：其一是维度，其二是度量，或者说是指标，这两项构成了我们数据分析的基础。
对于结构化数据，我们可以理解为一个多维立方体（cube），里面存在着维度和度量。
当然，不仅仅是三维，可以有多个维度。
这里拿三维立方体模型进行举例：
想象你操作数据透视表的模式，可以通过钻取、切片、切块等多种方式来对这个cube进行多维度观察，记录对比多个度量值，从而获取到数据所描绘的业务现状，继而通过对比产生对业务发展的洞察，从而制定出相应的决策。
然而在实际的业务运营中，单纯从几个维度并不能完整的了解业务发展的状态，我们需要从更深的层次去观察业务，更需要在业务指标出现问题时快速定位原因，这就需要通过构建合适的指标体系来实现。
笔者主要做社区板块的数据支持，社区业务是整体业务的一个较为重要的子版块，目前处于多批次循环迭代中，由于业务方向及产品形态的变化，需要多次更新调整数据计算逻辑。
并且由于埋点及业务数据的不完善，经常需要校验异常数据，且部分指标至今无法确保准确性，为了应对频繁的产品迭代产生的数据需求以及更好的发现问题、定位问题，故需要从整体业务的角度构造指标体系。
为什么要搭建指标体系？
通过指标体系监测业务发展的状况，最大的价值就是高效利用时间，把时间花在解决问题上，而不是寻找问题上，从而提高整体的人效。
指标体系的输出结果应当是一份指标字典和对应的Dashboard展示，需要至少满足以下要求：
这其实也是商业数据分析能力的前两层，即发生了什么和为什么会发生。
在构建指标体系的过程中，首要动作就是明确指标的分类以及约束指标命名方式，使各个指标能够做到见名知意、减少沟通成本，这里我们按照阿里对指标的划分规范指标命名：
指标分为原子指标和派生指标。
原子指标是基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，是具有明确业务含义的名词 ，体现明确的业务统计口径和计算逻辑，例如支付金额。
下图是各个基本概念之间的关系：
参照阿里对以上基础概念的定义：
业务板块：比数据域更高维度的业务划分方法，适用于特别庞大的业务系统。
业务过程：指企业的业务活动事件，如下单、支付、退款都是业务过程，请注意，业务过程是一个不可拆分的行为事件，通俗的讲，业务过程就是企业活动中的事件。
修饰类型：是对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖无线端、PC端等修饰词。
修饰词：指出了统计维度以外指标的业务场景限定抽象，修饰词隶属于一种修饰类型，如果在日志域的访问终端类型下，有修饰词PC端、无线端等。
时间周期：用来明确数据统计的时间范围或者时间点，如最近30天、自然周、截至当日等。
度量/原子指标：原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，通常是业务过程+度量组合而成，如支付金额。
维度：维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以成为实体对象。维度属于一个数据域，如地理纬度、时间维度。例如， 在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。
派生指标：派生指标=一个原子指标+多个修饰词（可选）+时间周期。可以理解为对原子指标业务统计范围的圈定。如原子指标：支付金额，最近一天海外买家支付金额则为派生指标（最近1天为时间周期，海外为修饰词，买家作为维度，而不作为修饰词）
依据以上基本概念，下面是电商业务中一个具体的指标实例：
结果性指标和过程性指标
结果性指标，比如电商场景下的 GMV 或订单量，它通常是业务漏斗的底部，是一个不可更改的、后验性的指标。
过程性指标，可以简单理解为我到达这个结果之前经过的路径，以及通过这个路径去衡量转化好坏的过程，它是可干预的，而且通常是“用户行为”。
在实际的业务运营过程中，不仅要关注结果性指标，更要关注过程性指标，通过优化过程性指标便能够更加有效的达成结果性指标。
在了解了指标的类型之后我们就可以着手开始搭建我们的指标体系了，首先需要找到什么是我们关注的核心指标？
核心指标应当是结果性指标，然后在核心指标的基础上拆解过程性指标并纵向划分层级，在此基础上再划分层级之间的关系，通过层次划分，最终实现我们需要的效果。
搭建指标体系的时候，横向使用OSM模型，纵向进行三级指标分级。
（一）横向选择数据指标
选取数据指标是需要有方向性的，需要针对业务现状选取最能代表业务发展状态的指标，在这方面有成熟的模型可以参考，这里我们使用OSM模型来选取指标。
OSM模型（Obejective，Strategy，Measurement）分别代表业务目标、业务策略、业务度量。
O：用户使用产品的目标是什么？产品满足了用户的什么需求？业务的核心目标是什么？
S：为了达成上述目标采取的策略是什么？
M：这些策略随之带来的数据指标变化有哪些？
我们依据核心业务目标，最终选取的关键指标如下：
（二）纵向划分数据指标层级
基于以上选择的数据指标，再对数据指标进行层级划分，划分指标层级能够帮助公司搭建一套完整的数据监控指标体系，从而及时发现业绩的升高或降低，以及产生的原因，节省花在寻找问题上的时间。
指标分级可以帮助我们更高效的去定位问题，去验证你的方法论，无需每次都要思考要去看哪些指标。
一级指标：公司战略层面指标，必须是全公司都认可的、衡量业绩的核心指标。它可以直接指引公司的战略目标，衡量公司的业务达成情况，本质上需要管理层和下级员工的双向理解、认同，且要易于沟通传达。比如公司的销售额，或者社交产品的活跃度。
二级指标：业务策略层面指标，二级指标是一级指标的路径指标，一级指标发生变化的时候，我们通过查看二级指标，能够快速定位问题的原因所在。比如uv、转化率、客单价，通过这三个指标可以快速定位销售额降低的原因。
三级指标：业务执行层面指标，三级指标是对二级指标的路径的拆解，即是二级指标的过程性指标。通过三级指标，可以高效定位二级指标波动的原因，并可以快速做出相应的动作。这一步会基于历史经验进行拆解，拆解时可以试着不断询问自己为了实现二级指标我需要做哪些事情？这些事对应的指标是什么？
根据以上原则拆分指标如下(指标都为日度汇总指标)：
以上是依据目前业务现状搭建的基本指标体系，在当前指标体系的基础上，仍然可以针对产品中的各个业务子板块继续依照以上方法搭建业务子板块的数据体系。
比如针对社区板块中的鉴定板块，按照鉴定业务组的业务目标搭建鉴定频道的业务指标体系，这里先不深入。。。
搭建好了指标体系，已经梳理出了需要的指标，但是如何更合理有效的计算出我们需要的指标呢？
这就需要构建数仓，通过ETL过程对数据进行多维度计算汇总，再经由Bi产品可视化展现，最终产出我们需要的指标体系。
并且这个数仓需要满足幂等性，即多次复核计算的结果都应该是相同的。
在构建的过程中，目前只考虑T+1模式的离线数仓构建，暂不考虑其他情况。
（一）划分数据域
数据仓库是面向主题（数据综合、归类并进行分析利用的抽象）的应用。数据仓库模型设计除横向的分层外，通常也需要根据业务情况进行纵向划分数据域。数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念层次归类，目的是便于数据的管理和应用。
数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。
数据域可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块进行划分。
由于社区板块只是整体业务的一个子版块，这里只划分社区涉及到的业务过程与数据域：
以上划分的数据域严格来说并不全，因为我仅仅只将社区板块中的业务过程进行划分，仅仅是整体业务板块中的一部分，在更高层面上的数据域划分应当是规范划分每个数据域下有哪些业务过程。
（二）构建总线矩阵
明确每个数据域下有哪些业务过程后，即可构建总线矩阵。
同时需要明确业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。
构建总线矩阵的重点在于：
基于以上两点，宏观上构建业务主题与数据域之间的关系，微观上构建业务主题中的业务过程与维度之间的关系。
1.宏观业务矩阵
宏观矩阵是业务主题和数据主题的关系，由于社区数仓仅涉及社区业务主题，故这里仅放置社区涉及到的业务过程。
2.微观业务矩阵
微观矩阵是数据主题和维度的关系。
在构建微观业务矩阵的时候，需要结合对业务过程的分析定义维度，根据业务的不同形态需要从不同的维度进行分析，这个维度的定义需要结合业务场景与分析指标，最终定义如下：
基于以上得到的总线矩阵，我们可以进行如下模型的设计：
1）明细模型设计：设计一致性维表DIM和一致性事实表DWD
2）汇总模型设计：设计公用汇总层DWS和应用汇总层ADS
（三） 确定统计指标
这一步需要依据之前使用OSM模型和指标分层构建的指标体系，对数据进行计算，标准化命名，然后将涉及到的指标计算出来。
例如，通过访问事实表计算社区的用户数、社区各子板块的用户数，并拆分平台、版本和用户类型。
（四）数仓分层
数仓分层的目的在于我们希望数据的流转能够更加有序可控，减少重复开发，统一数据口径，且能够及时有效的响应多样的数据需求，参照如下结构，将数据进行组织：
DWD层：明细事实层
DWS层：主题汇总层，这一步可以拆分两层：
DWM层基于明细事实表的维度进行日度汇总
DWS层基于常用分析维度进行的数据汇总
按照以下层级调用标准进行分层计算：
禁止逆向调用
避免同层调用
优先使用公共层
避免跨层引用
数据在经过ETL之后就计算出了我们需要的指标，但是在数据的计算过程中，我们会遇到很多计算口径的问题，需要我们和运营、技术、产品一起多次明确口径。
比如用户互动中已删除的点赞算不算点赞、已删除的评论算不算互动等类似问题。。。
故，在最后阶段，我们要将计算过程中每一个指标的计算口径，异常值的处理等等输出一份指标字典，以便我们和运营之间进行沟通。
当然，这一步也可以在构建完纵向指标层级之后就进行输出，但是由于我们无法提前预知计算过程中的问题，所以还是建议在指标体系搭建的最后阶段输出准确的指标字典。
指标字典的输出必须明确的三个要素是：指标名称、指标描述、计算方式，结构可以参照如下指标字典：
BI层展示存在多种方式，目前通用的比较快速的就是通过BI工具进行展示。
主流的BI工具有国外的tableau、powerbi；国内代表的BI产品有网易有数、阿里的QuickBI、smartBI。不过以上的BI平台是收费，并且可定制化并没有那么强。
开源的BI工具国外的有superset、redash、metabase，国内的主要有CBoard和Davinci，这些产品的简单介绍可以查看这篇文章可视化BI工具，这里最终用superset进行BI层的展示。
考虑到我们希望输出的是一个指标体系，而不是单纯的数据展示，故在展示时，需要能够进行基础的级联刷新、筛选操作，以便运营能够通过该展示层，寻找到问题的原因。
展示层需要满足以下功能：
能够多角度的描述业务当前的运营状态
能够从时间、平台、人群多维度分析业务
能够快速获取历史数据通过excel灵活分析
能够了解对应指标的含义
能够关注到核心链路
此外，将所有数据展示在同一张DashBoard上肯定会是不现实的，所以需要按照分析主题将DashBoard规划为以下层级：
1、整体业务层级：该层级关注当前业务状态的核心主题，即指标体系中的第一第二层级数据
2、业务执行层级：该层级关注具体业务专题的结果指标及路径指标，即指标体系中的第二和第三层级数据
本文作者:芒果 来源:玩物得志技术
CIO之家 www.ciozj.com 微信公众号:imciow