数据指标体系建设和数据仓库搭建与可视化

　　一、数据指标体系建设方法
　　01
　　数据
　　数据是指未经过处理的原始记录。
　　数据的本质是利用数学观察、记录、理解世界；数据分析的过程就是人类从定性到定量、模糊到精准过程。
　　大家都喜欢看数据，而不是通过一堆的文字、现象进行决策判断。
　　02
　　指标
　　指标=数据+业务场景，能够指导业务制定下一步行动方案。
　　例如：【体重】是一个数据，120KG不代表胖，60KG也不代表瘦，这个数字的或大或小并不能从说明什么问题，因为还有身高的因素。而【体脂率】是一个衡量人体内脂肪含量的多少的指标，对男性而言3-4%左右的体脂是必须脂肪，对女性而言10-12%的脂肪是必须脂肪，低于这个标准就会影响健康。另外，男性体脂高于25%、女性高于35%则属于肥胖，不但难看还会影响健康。因此【体脂率】是一个可以指导人们下一步行动的＂指标＂，而【体重】只是一个数据。
　　一个好的指标的应该能够解决以下5W的问题：  1、使用场景（who、when、where）
　　解决指标的维度问题，通过定义维度可以明确指标所能支持的分析场景，例如【体脂率】可以支持性别、年龄段、地区等维度，那对应的可以支持对不同性别、年龄段、地区人群的分析。
　　2、指标定义（what）
　　解决指标的计算口径问题，大多数情况下需要解决的是同名不同义、同义不同名的问题，如下图的销售额、上架数量两个指标所示。
　　3、指标用途（why）
　　解决指标的逻辑问题，明确指标与指标之间的逻辑关系，如：销售利润=销售额-采购成本-头程税费-退税差额，毛利润=销售利润-呆滞计提-资金占用利息。
　　03
　　指标体系
　　明确了指标应该解决的问题，接下来就是如何把指标构建成为一套指标体系。这里给出两套比较常用的指标体系建设方法论，一个是海盗指标法，另一个是第一关键指标法（现在也叫北极星指标，名称不同但是理念是一致的）。
　　海盗指标法（AARRR）：
　　2007 年，500 Startups 创业孵化器的创始合伙人 Dave McClure 针对创业公司应该关注哪些指标，提出了一套模型—— PirateMetrics，即海盗指标法，思想如下。
　　它将创业公司应该关注的指标切分成了获取、激活、留存、收入、推荐等5个环环相扣的模块，在每个模块中需要关注的指标都看过《增长黑客》的朋友对这个模型应该不陌生。AARRR模型的每个层级所衡量的关键指标是不同的。
　　这个模型对于流量 收入转化的指标建设有相当的指导意义，适用于大部分的互联网公司。但对于传统电商这类关注供应链、管理成本的企业来说，这套指标体系并不能覆盖所有的场景，因此我们主要采用的是第一关键指标法作为指标体系建设的理论基础。  第一关键指标法：
　　第一关键指标法的核心思想，不是说一个公司只为一个指标负责，而是说在任意一个时间点，肯定只有一个最关键的指标，但随着业务的发展关注重点会有变化。所处商业模式一般有电子商务、SaaS、移动APP、双边市场、媒体、UCG等，所处阶段从大的阶段可以分为MVP、增长、营收三个阶段，往细了分又可以再拆分为5个阶段，每个阶段的指标体系需要解决的问题都有差异。
　　指标体系建设过程（以某公司为例）：
　　1、确定第一关键指标
　　在项目建设期间，公司已经成为国内跨境电商领域的巨头之一，相比起用户规模，在这个阶段公司是上下更关注的是营收（以更低的成本获取更多的用户和营业额），各事业部的OKR也是以销售额作为第一考核点。因此，虽然销售额是一个所谓的＂虚荣指标＂（销售额的高低并不能直接说明公司的经营状况），但是我们仍然将该指标作为第一关键指标，在此基础上进行指标体系的梳理。
　　2、划分模块
　　在销售额这个第一关键指标的指导下，需要关注的不只是用户转化、留存率的情况，还需要关注采购、仓储、物流等各个环节的成本、时效等，因此将指标模块划分如下。
　　3、梳理指标逻辑关系
　　确定各个模块的核心关注指标之后，我们从第一关键指标开始，从上往下梳理指标之间的逻辑关系。
　　04总结
　　不同行业在不同发展阶段，最终绘制出来的＂指标树＂可能有很大的差异。不同的指标体系方法论适用场景不同，建议结合不同的方法论进行指标梳理，但不管是第一关键指标法还是海盗指标法，重点都在于如何让指标为公司经营提供决策依据。
　　二、数据仓库的搭建和数据可视化。
　　历史导读：
　　小进阶：数据指标体系和数据治理的管理
　　小诀窍：不妨尝试从交付质量上打败对手
　　以下，Enjoy：01 为什么基于指标体系搭建数据仓库
　　前面文章中我们提到过为什么要搭建指标体系，如果还无法体会指标体系的作用和意义，可以通过历史导读重温前面的2篇文章，或者加入我们的微信群，同大家一起交流。这里简单的在换2句话描述一下做指标体系的重要性。搭建指标体系实际上是同需求方达成一种协议，可以有效地遏止不靠谱的需求，让需求变得体系且有条理；数据指标体系是指导数据仓库搭建的基石，稳定且体系的数据需求，有利于数据仓库方案优化，效率提升。
　　没有数据指标体系的团队内数据需求经常表现为＂膨胀＂现象。每个人都有看数据的视角和诉求，然后以非专业的方式创造维度/指标的数据口径。数据从业人员被海量的数据需求缠住，很难抽离出业务规则设计好的解决方案，最终滚雪球似的搭建难以维护的＂烟囱式＂数据仓库。
　　提供数据可视化方案的过程，依然存在像搭建数据仓库一样的问题。数据可视化报表数量膨胀但使用率低，好似再多的数据报表都远远不够满足数据需求一样。长久下来维护成本居高不小，效益率不够高。这让数据从业者很苦恼，如果大家还有其他苦恼的问题，希望继续深入的沟通了解，欢迎评论留言或者加入我们的微信群聊共同交流。02 基于指标体系搭建数据仓库思考
　　我们简单回忆下的数据仓库分层问题，做＂又宽又薄＂的数据仓库分层，让数据能够有序的流转。数据全链路的整个生命周期只有通过层次才能清洗明确的被使用者感知和消费。任何跨层依赖，循环依赖，多重依赖都会导致数据问题的多发且不可维护。数据仓库常见分层方式
　　数据仓库分层和跨层依赖、循环依赖、多重依赖的不同表现形式
　　因此，我们需要有效的组织和管理数据，让它更有秩序。每层都有作用域和职责，清晰每层数据的目标定位和理解。规范工作方式，做标准数据分层，开发通用性强（健壮）的数据中间层，避免耦合重复计算问题。提供统一的数据服务，输出统一认知的数据口径将复杂的数据任务拆解，标准步骤每层解决场景问题。
　　从数据仓库的分层来看，ODS层是贴业务，形态主要依赖业务数据形式；APP层是贴使用场景，取决于数据怎么呈现和消费，DW层是中间层，负责发挥重要的扩展作用，肩负大量的数据加工计算责任。
　　鉴于以上数据仓库的分层逻辑，我们不难得出结论。ODS层的搭建不需要过多思考，依赖业务库的表现形式；APP层的更多依赖数据最终的场景搭建，考虑场景因素居多，比如多维、速度、口径。
　　只有DW层让数据生产者有极大的发挥空间，如何设计出好的（扩展性强）DW层是数据仓库的重点标准，相信很多同学在DW层搭建的过程都出现过类似问题＂理想很丰满，现实很残酷＂，搭建的数据＂不接地气，不实用＂，还是不能解决数据需求问题，总是跟不上业务的发展变幻。
　　那么，从现在开始不妨首先建立指标体系，基于指标体系搭建数据仓库。我们常见的指标体系大致包含以下内容：产品框架
　　数据矩阵
　　说明：
　　根据产品框架梳理出可靠的数据矩阵效果最佳，单现实的情况是在产品框架下的不同报表的指标口径或是计算逻辑可能存在差异，因此数据矩阵可以是根据某个报表单独针对性小矩阵。数据口径
　　说明：同数据矩阵一样不同的数据报表中，相同的指标名称可能存在不同的数据口径或者计算逻辑 ，因此指标的口径定义方面也可以做一些调整，例如口径和计算逻辑不同，必须区分出不同的指标名称，或者是相同的指标名称，做好指标口径定义的说明，告知受众群体差异点在哪里。03 基于指标体系搭建数据仓库
　　常见的数据仓库搭建，实现数据分层大致分为两种模式：A模式：基于业务实体或者数据的应用场景，从应用层向底层推导过程。B模式：基于已有的数据，从底层分类整理数据，向应用层逐步搭建。
　　以底层向应用层搭建数据仓库，侧重在于需求尚且不清晰的情形下开展数据开发工作，首先实现数据预处理，做好数据的采集对接和数据主题分类。以备数据消费场景落地的时候，快速实现功能的开发。这种模式通用型强，使用广泛，同时也会造成很多冗余和设计不合理，实际响应需求的时候出现扩展性差，重构几率高的现象。
　　另一种模式则是在需求明确的前提下，以需求向底层推导数据仓库建模。通过需求让参与项目的各方快速理解业务诉求，统一目标的认知。高质量的梳理出业务需求和数据仓库之间的关系，针对性强的搭建数据仓库。但是这依然有诟病，就是数据建设容易出现＂烟囱式＂搭建，满足场景有限，复用性差。
　　基于指标体系搭建数据仓库，主要解决的是＂A模式＂中的数据场景考虑不全面的问题。如果数据的使用场景考虑不全面就会造成＂烟囱式＂数据搭建，复用性差。数据需求如果以＂点状＂碎片的形式提出，没有全局的认知和规划，数据仓库的搭建只能针对性的以＂点状的烟囱式＂搭建。如果需求能体系化的产出，梳理出业务场景中所需要的维度、指标。那么就可以最大限度的解决数据建模过程中的＂烟囱式＂，从而让数据的搭建＂又宽又薄＂。
　　例如，我们有如下数据矩阵
　　-w505
　　那么，我们可以选择的数据仓库分层建模方式如下
　　-w713
　　说明库.表1：通过APP层的数据表服务数据可视化，数据应用服务，多维查询；库.表2：实时明细表，通过与其他的实时表（库.表3）或者维度表（库.表4、5）关联生成APP层的数据表；库.表6：埋点数据产生的日志表，或者是从业务库对接过来的业务数据（比如订单数据）0x04 数据可视化报表