数据产品经理，除了应该具备的如：沟通/原型/文档/项目管理等基本技能外，还应该具有精于“数据”的核心专业技能如【数据认知/数据技术/数据平台/数据分析/搭建指标体系】等，而搭建数据指标体系是其中最为重要的，将直接影响数据【产生--处理--存储--计算--应用】的全流程，也将影响数据平台产品的系统性、稳定性和扩展性。
一、为什么需要指标体系？
1.1 什么是指标？
通常我们讲的指标是指讲业务单元精分量化的度量值，譬如「DAU」「订单数」「金额」等。当然，原子指标还会基于维度、修饰词、统计口径而构建出派生指标。指标的核心意义是它使得业务目标可描述、可度量、可拆解
1.2 指标不成体系会怎么样？
从业务视角看：
经常碰到一种现象是业务上线了之后发现数据不够用，缺指标或缺维度。随之而来的便是数据需求更改：添加指标、添加维度、增加各种五花八门的数据报表等。这一系列的需求变更，和反复迭代造成的苦果，会使得报表越发臃肿，数据参差不齐。业务同学分析具体问题时找数据会越来越难，每天会消耗大量时间在不断的寻找数据、核对指标的泥潭中。
从技术视角看：
基于需求的变更，业务团队技术同学将需要重新去更改设计和开发埋点。数据团队技术同学则需要重新采集、清洗、存储数据；更为致命的是，若在原有的监控报表上增加指标或维度还会需要：
1）在原有的数据存储结果表上动刀，增加存储列等
2）数据计算SQL逻辑更改
3）数据回算
4）结果展现逻辑更改；
这一系列下来，不仅耗费人力物力，同时实现本身周期也会更长，反馈效率低下
1.3 指标体系化后能不能解决？
一个好的指标体系设计，不能说可以规避掉百分百的问题，但至少让问题出现时各方临危不乱。
首先，业务同学需要对自己的业务有一个大概的预判，譬如：在整体的业务里程碑上，什么时间点会有哪些策略动作，对应的业务体量会有多大。与此同时，也提前去预知大概会监控哪些指标，从哪些维度拆解等。
其次，在有了初步预判之后与团队技术沟通，与数据团队沟通，尽量让各方信息对称。这样的好处是，我们能尽量提前将指标体系设计得不重不漏、条理清晰。同时技术团队也会有所准备，在做数据底层设计时多去考虑其稳定性、扩展性等。
1.4 指标体系化的本质
体系化本质是将数据指标系统性的组织起来。具体会按照不同的业务模型，按标准对指标不同的属性分类及分层；当然，不同的业务阶段、不同业务类型会有不同阶段的划分标准。那么，我们该如何依据现有业务去搭建指标体系呢
二、如何搭建指标体系？
2.1 明确业务是什么
在搭建指标体系之前，需要明确自己的业务是什么？公司的整体目标是什么？在产品实现上，如何帮助用户解决问题。譬如像电商C2C企业，业务本质上要解决的是需求「匹配」和「匹配效率」的问题，是一个不断丰富供给和满足需要的过程。目标上会去追求实现更多的用户双边关系需要，对应到数据去看会衍生出「DAU」「订单」「GMV」等战略指标。下面将会以“电商C2C”为例，从「业务整体大盘」和「业务子单元」拆分讲解数据指标体系的构建方法。
2.2 按业务大盘拆解
根据企业战略目标，按照业务大盘的方式拆解数据指标体系，在业内有个有名的方法论AARRR（也叫海盗指标法），整体的拆分逻辑是「获取--活跃--留存--营收--传播」。这个方法论的特点是比较系统和笼统的拆解了精益创业中的增长模型，不过在对应到现实业务上应用时，仍会有些让人不知所以。尽管如此，我们依旧可以在基础上进行改良，进行基于自身业务本地化之后的扩展延伸。
2.2.1 用户实现需要的路径
我们先对自身业务模式进行拆解，画出业务模型流程图。观察其在业务主流程上，不同阶段实现用户侧买家和卖家需求时，用户会做什么、产生哪些数据、我们需要监控哪些数据。如下图，我们得出两点：
1）无论买家还是卖家，在整个业务主流程上的动作比较相似
2）主流程中认知、激活注册、行为、沟通、交易、售后六个阶段，克依据阶段的差异性进行数据分类
2.2.2 数据还原业务真相
通过上一步的拆解，我们基本可以摸清楚，用户在实现需要的路径上会产生哪些数据，这些数据将会为我们还原业务真相：
1）认知阶段：市场渠道相关数据，品牌广告数据。如：渠道新增、渠道DAU、渠道留存、渠道转化、渠道POI等
2）激活注册：应用激活量、激活注册转化率、版本分布、机型覆盖率等。
3）关键行为：用户行为数据，如：发布商品、搜索、浏览商品、收藏、添加购物车等。
4）沟通：留言、私信、电话沟通
5）交易：下单、支付等
6）售后：交易仲裁、申诉投诉、催单等
2.2.3 建立大盘指标体系
基于不同阶段需要观察指标的不同，结合海盗指标法勾勒出业务数据的关键漏斗。再加上整体概况数据、「用户/商品/订单」核心指标实时数据，我们就能够对「业务大盘」有粗粒度的，相对完善的监控
2.3 按业务单元精分
有了业务大盘之后，我们对「这个业务做了什么？我们拿到了什么数据？」有了大致的了解。但对于企业来讲更为重要的是，需要去考虑两个问题：
1）为了解决用户在不同业务环节中的问题，企业应该配备什么样的团队去解决；
2）该如何通过不同的“第一关键指标”考核不同的团队？
2.3.1 企业如何介入？
相对应的，我们通过对用户实现需要的路径拆解，也拆解了企业在不同阶段需要配备哪些不同的团队，不同团队间既独立，又相互需要，但整体上都是为了实现业务闭环而组成。具体如下：
1）认知阶段：需要配备的团队是渠道市场部、品牌市场部。
2）激活注册：基础体验部、其他垂直业务部
3）关键行为：搜索推荐团队、基础体验 、风控、垂直业务部
4）沟通：与通信及推送相关的架构部、运营部、风控部、公关部
5）交易：交易中台、运营部、财务部
6）售后：客服部、风控部、公关部
2.3.2 第一关键指标
第一关键指标是指：当前阶段无比重要的第一指标，同时也指出了在创业阶段的任何意义点上应该且只关注第一项重要指标。公司的第一关键指标，拆解到不同的部门，就成了各部门的“第一关键指标”，也是团队的考核度量（OKR或KPI），通过调研不同部门或业务单元，他们基于自身的业务、基于考核关键指标应该去关注哪些数据呢。
下图：举例，在认知阶段最相关的部门是渠道部和品牌公关部。如果他们的目标是“如何通过更少的钱获取更多的新用户”，那么关键指标可以认为是「新增用户数」「ROI」，再按照*指标*、*维度矩阵*的方式对关键指标进行拆解。其他部门的关键指标也可以照此方式抽象拆解，方法类似，不再逐一举例。
三、具体怎么做？
3.1 明确关键指标
通过上文的描述，无论是企业整体概况，还是某个业务单元的考核目标。我们都可以找到其在当下业务阶段的关键指标，诸如：DAU、新用户数、支付订单数、新买家数、新卖家数等。下面以「支付订单数」为例：
3.2 指标体系设计
需要将「支付订单数」进行拆解，按不同的维度（观察指标的视角）进行下钻，具体需要哪些维度也会因为企业产品、业务模式的不同而不同。支付订单数大致可以从六个维度进行拆解：
1）终端：按订单实际支付订单的场景终端进行拆分，分端内/端外、pc端、小程序端等。一旦某个终端的支付抖动的厉害，可以立即发现定位问题
2）渠道：按用户认知企业产品，下载应用的渠道拆分。也可以依据需要拆解的更细，进一步提升监控敏感度
3）订单来源：电商行业里，订单来源常常需要重点关注。不同的运营活动、客户端版本策略都将直接影响搜索、推荐、列表页等来源的订单量波动
4）订单类型：按照订单类型拆分，主要是尽可能的去感知促销或红包等运营手段对用户支付的影响，这块通常也会因为直接涉及到促销红包成本等方面而拆解的足够细致。
5）商品品类：这是商品自身的属性，不同商品品类的订单波动往往受到垂直运营活动、季节、外部环境、竞品等因素的影响
6）应用版本：按客户端应用版本拆分，以便于迅速找到产品在升级更新时有可能会对支付订单带来的问题。
3.3 设计埋点收集
指标体系设计完成后，我们确定了数据收集的边界。根据不同维度场景下需要的数据，通过埋点事件模型设计数据采集方案，也可以直接从关系型数据库中拉取非日志类数据，最终同步到数据仓库中。这其实是一个业务驱动指标设计，再驱动数据收集的过程。
3.4 统计与应用
有了基本数据之后，依据业务指标定义确定数据的统计逻辑，最终计算结算可视化到报表系统中，供日常离线/实时监控使用;也可以依据数据仓库中存储的用户、商品、订单等信息进行数据分析、挖掘。
3.5 验证指标体系设计的合理性
指标体系设计是否合理，往往也是一个不断被挑战，然后不断被优化改进的过程，下面列举几个验证指标设计合理的关键点：
1）可执行可描述：所有设计出来的指标应该可被执行，也应当可被业务语言和技术语言描述
2）完整性：可依据金字塔原理，枚举指标和维度，不重不漏以保证完整性
3）优先级：按优先级确定哪些维度下的哪些指标需要优先解决，以保证执行效率
数据指标体系设计流程：
四、需要注意的问题
4.1 是否刚开始，就需要设计一套大而全的方案
不需要。业务还在摸索阶段，量级还没起来的时候设计大而全的方案不仅耗费人力，同时对计算、存储资源也是较大的消耗。但整体设计要有预见性，业务团队与数据团队时刻都要保持信息对称。
4.2 如何进行需求管理
业务需要推动需求管理：
1）确定优先级；
2）保证输出效率；
3）迭代反馈和修正；
4.3 指标的生命周期
数据指标服务于业务，也会受到业务变动的直接影响。在一个业务变革飞速的时代，通常半年一年业务本体便发生质变，随之原有的指标设计便不再合适，也不再需要。数据产品经理要时刻保持敏锐的业务嗅觉，周期性调研数据指标的使用反馈，再去做好指标自动化下线计算任务暂定等工作。不断释放优化计算存储资源，从而保证资源投入产出比最优
4.4 兵无常形，量体裁衣
以上说的，不一定适用于你
原文作者：Andy685
