构建数据指标体系
为什么要构建数据指标体系?因为我们希望时间能花在解决问题而不是寻找问题上。
指标体系衡量效果:当战略指标出现问题之后能否一眼找到问题点。
修补添加:一直以为构建数据指标体系的难点在于指标的选取,但是当真的走完这一遍流程之后,才发现数据指标的选取其实很简单,难的是数据的流向,数据从哪里来,怎么多维度计算,怎么展示。
本次修补内容:
1.参照GrowingIO直播,更新指标体系搭建方式:osm+ujm+场景化
2.明确指标定义及命名规则
3.调整数仓方案
4.增加数据展示层的内容
前言
我们所需要的并不是数据,而是数据背后映射的洞察。在业务发展过程中,会产生大量的数据,单看数据是没有价值的,只有和业务相结合转化为信息,再经过处理才能体现其价值。
对于业务数据而言,通常分为两项,其一是维度,其二是度量,或者说是指标,这两项构成了我们数据分析的基础。对于结构化数据,我们可以理解为一个多维立方体(cube),里面存在着维度和度量。当然,不仅仅是三维,可以有多个维度,这里拿三维立方体模型进行举例,想象你操作数据透视表的模式,可以通过钻取、切片、切块等多种方式来对这个cube进行多维度观察,记录对比多个度量值,从而获取到数据所描绘的业务现状,继而通过对比产生对业务发展的洞察,从而制定出相应的决策。
数据如何驱动业务发展,按数据驱动书中所说,四个步骤,从埋点到指标,通过指标进行数据驱动决策。
然而在实际的业务运营中,单纯从几个维度并不能完整的了解业务发展的状态,我们需要从更深的层次去观察业务,更需要在业务指标出现问题时快速定位原因,这就需要通过构建合适的指标体系来实现。
一、业务背景
笔者主要做社区板块的数据支持,社区业务是整体业务的一个较为重要的子版块,目前处于多批次循环迭代中,由于业务方向及产品形态的变化,需要多次更新调整数据计算逻辑。并且由于埋点及业务数据的不完善,经常需要校验异常数据,且部分指标至今无法确保准确性,为了应对频繁的产品迭代产生的数据需求以及更好的发现问题、定位问题,故需要从整体业务的角度构造指标体系。
为什么要搭建指标体系?通过指标体系监测业务发展的状况,最大的价值就是高效利用时间,把时间花在解决问题上,而不是寻找问题上,从而提高整体的人效。
指标体系的输出结果应当是一份指标字典和对应的Dashboard展示,需要至少满足以下要求:
- 成体系化的指标监控系统,能够从多维度了解业务发展的现状
- 在业务发展出现问题时能够快速定位问题所在
- 高效地为团队提供数据支持
这其实也是商业数据分析能力的前两层,即发生了什么和为什么会发生,关于商业数据分析的四个层级可以参考这篇文章。
二、指标
指标是为了从不确定性到确定性,
指标体系是指:针对一种具体业务场景,为了完成该场景的主目标,所搭建的一套指标,用于分析问题和解决问题。
指标体系=维度+指标,二组的组合而成的cube。
二、指标类型及命名
在构建指标体系的过程中,首要动作就是明确指标的分类以及约束指标命名方式,使各个指标能够做到见名知意,减少沟通成本,这里我们按照阿里对指标的划分规范指标命名:
指标分为原子指标和派生指标。原子指标是基于某一业务事件行为下的度量,是业务定义中不可再拆分的指标,是具有明确业务含义的名词 ,体现明确的业务统计口径和计算逻辑,例如支付金额。
- 原子指标=业务过程+度量,例如访问用户,下单用户,支付金额等
- 派生指标=时间周期+修饰词+原子指标,派生指标可以理解为对原子指标业务统计范围的圈定。
下图是各个基本概念之间的关系:
参照阿里对以上基础概念的定义:
业务板块:比数据域更高维度的业务划分方法,适用于特别庞大的业务系统。
业务过程:指企业的业务活动事件,如下单、支付、退款都是业务过程,请注意,业务过程是一个不可拆分的行为事件,通俗的讲,业务过程就是企业活动中的事件。
修饰类型:是对修饰词的一种抽象划分。修饰类型从属于某个业务域,如日志域的访问终端类型涵盖无线端、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模型和指标分层构建的指标体系,对数据进行计算,标准化命名,然后将涉及到的指标计算出来,例如,通过访问事实表计算社区的用户数、社区各子板块的用户数,并拆分平台、版本和用户类型。
(四)数仓分层
数仓分层的目的在于我们希望数据的流转能够更加有序可控,减少重复开发,统一数据口径,且能够及时有效的响应多样的数据需求,参照如下结构,将数据进行组织,可以参照以下数据组织形式:
(一)ODS层:原始事实层
将原始数据按照快照表等方式同步过来
(二)DWD层:明细事实层
该层对ODS层级的数据进行清洗
(三)DWM层:轻度汇总层
DWM层会在DWD层的数据基础上,对数据做轻度的聚合操作,生成一系列的中间表,提升公共指标的复用性,减少重复加工。在DWM层,我们会从DWD层中选取业务关注的核心维度来做聚合操作,比如只保留人、商品、设备和页面区域维度。类似的,我们这样做了很多个DWM的中间表
该层级的核心在于提高公共指标的复用性,且是非跨主题域的数据聚合,基于当前业务形态,该层级考虑构建userid和videoid之间的关联关系表,保留人、视频两个核心维度。
例如,人和视频之间的互动关系,人和视频之间的浏览访问关系,人和视频之间的曝光关系,人和视频之间的下单、出价关系等等,然后在dws层再构建一份人和视频之间的所有的关系表。
(四)DWS层:跨主题汇总层
DWS层:主题汇总层,这一步可以拆分两层,分别是DWM层基于明细事实表的维度进行日度汇总,以及DWS层基于常用分析维度进行的数据汇总,跨数据主题计算。
DWS层又称数据集市或宽表。按照业务划分,如流量、订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等。
一般来讲,该层的数据表会相对比较少,一张表会涵盖比较多的业务内容,由于其字段较多,因此一般也会称该层的表为宽表
所以dws层应该是视频、话题、类目等维度的数据聚合,dwm层uv、曝光、点赞、评论、分享等做轻度汇总。
在实际计算中,如果直接从DWD或者ODS计算出宽表的统计指标,会存在计算量太大并且维度太少的问题,因此一般的做法是,在DWM层先计算出多个小的中间表,然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定,也可以去掉DWM这一层,只留DWS层,将所有的数据在放在DWS亦可。
(五)DIM层:维度数据层
存放一致性维度表
(六)层级调用标准
按照以下层级调用标准进行分层计算:
禁止逆向调用
避免同层调用
优先使用公共层
避免跨层表用
五、输出指标字典
数据在经过ETL之后就计算出了我们需要的指标了,但是在数据的计算过程中,我们会遇到很多计算口径的问题,需要我们和运营、技术、产品一起多次明确口径,比如用户互动中已删除的点赞算不算点赞、已删除的评论算不算互动等等类似问题,故,在最后的阶段,我们要将计算过程中每一个指标的计算口径,异常值的处理等等输出一份指标字典,以便我们和运营之间进行沟通。
当然,这一步也可以在构建完纵向指标层级之后就进行输出,但是由于我们无法提前预知计算过程中的问题,所以还是建议在指标体系搭建的最后阶段输出准确的指标字典。
指标字典的输出必须明确的三个要素是:指标名称、指标描述、计算方式,结构可以参照如下指标字典。
六、BI层展示
BI层展示存在多种方式,目前通用的比较快速的就是通过BI工具进行展示,主流的BI工具有国外的tableau、powerbi,国内代表的BI产品有网易有数、阿里的QuickBI、smartBI,不过以上的BI平台是收费,并且可定制化并没有那么强。开源的BI工具国外的有superset、redash、metabase,国内的主要有CBoard和Davinci,这些产品的简单介绍可以查看这篇文章可视化BI工具,这里最终用superset进行BI层的展示。
考虑到我们希望输出的是一个指标体系,而不是单纯的数据展示,故在展示时,需要能够进行基础的级联刷新、筛选操作,以便运营能够通过该展示层,寻找到问题的原因,所以该展示层要按照产品的形式来做。
展示层需要满足以下功能:
- 能够全方位的描述业务当前的运营状态
- 能够从时间、平台、人群多维度分析业务
- 能够快速获取历史数据通过excel分析
- 能够了解对应指标的含义
- 能够关注到核心链路
此外,将所有数据展示在同一张DashBoard上肯定会是不现实的,所以需要按照分析主题将DashBoard规划为以下层级:
- 整体业务层级:该层级关注当前业务状态的核心主题,即指标体系中的第一第二层级数据
- 业务执行层级:该层级关注具体业务专题的结果指标及路径指标,即指标体系中的第二和第三层级数据
(一)展示层级及内容划分
接入数据平台,划分数据层级和展示主题
数据、指标字典
(二)
分析模式:漏斗、分布、留存、用户分群等等,除此之外,这里还需要针对留存构建每天访问的用户组成结构,
漏斗:appuv –> 社区列表页uv –> 话题页、视频页、banner位二级页面uv
漏斗:视频页uv –> 互动人数
留存:1-7日内留存,1、7、15、30留存
分布:每日留存用户分布,观看视频时长分布,互动次数分布,观看视频次数分布
用户分群:访问用户类型,男女类型、用户等级类型,其实是基础的用户画像
使用OSM模型来进行BI层的规划:
正确的可视化故事与视图选择
首先需要策划一个令人信服的可视化故事,这里引用发现问题→分析问题→解决问题的思路构建可视化故事。
- 首先是发现问题,用数据可视化的形式展示相关数据,通过数据发现存在的问题;
- 接下来分析问题,通过多维度分析数据最终找到问题
- 最后是解决问题,
合理的信息密度筛选
一个好的可视化应当展示合适的信息,而不是越多越好。合理的信息展示,有利于向用户清晰地叙述可视化故事。合理的信息展示需要:
- 筛选信息密度,使信息展示量恰到好处;
- 区分信息主次,使信息显示主次分明。
数据可视化设计的3个原则
数据可视化设计原则一:选择可以讲故事的图表
你首先需要思考清楚你想达到什么目的、传达什么信息、以及你的用户是谁等。
数据可视化设计原则二:删减与故事无关的元素
这并不意味着要减半数据量,而是要多留意图表垃圾、多余的信息、不必要的说明、阴影、装饰等。可视化的绝妙之处在于它可以四两拨千斤般强化并传达你想表达的故事。(但可别用3D图表——它会让视觉化感知效果出现偏差)。
数据可视化设计原则三:为了更好的理解去设计
创建好可视化原型后,退一步考虑如何才能让读者更容易地理解数据。还可以增加、微调或者移除哪些简单的元素?或许要在线性图表里增加一条趋势线,你也可能会发现饼图切片太多了(最多只能用6片)。这些微妙的调整将会带来极大的改变。
最后输出的文档:
七、关于数据驱动业务的思考
作为一名BI分析师,每天有几个重点任务:
- 观察业务发展状态
- 定位问题原因
- 提出解决方案
最后,如果想要一个数仓支撑所有的分析需求,这个真的是不现实的,我花费了很长的时间来优化数仓,希望能够支撑所有的数据需求,后来发现是徒劳的。olap的维度是无尽的,数仓和数据指标体系只能够支撑其中的一部分,其余的部分还是要写sql,自己去分析。所以,实施自助的ad-hoc式分析才是未来。
八、指标体系如何产品化?
产品化、平台化才是未来,才是最有效的数据能力输出!!
参照滴滴的实践:滴滴数据仓库指标体系建设实践
参考资料:
阿里巴巴大数据实践
http://www.woshipm.com/data-analysis/2317120.html
建立商业指标:https://mp.weixin.qq.com/s/210SqfNaUiEcCkOKNvCybg
梳理数据指标体系:https://mp.weixin.qq.com/s/xshTfnSval_dODAZM3Lnfw
KPI 看板:https://mp.weixin.qq.com/s/uy_FZF0d9IJKfGL2GJ8OZA
如何选择数据指标,建立数据监控体系?:https://mp.weixin.qq.com/s/g98oPQSw2zvPo7YzKhpJhQ
以「抖音」为例,分析互联网数据指标体系的搭建:http://www.woshipm.com/pd/3086815.html