构建数据指标体系中踩过的坑

编辑导语：作为数据产品经理，与数据打交道是必不可少的事项。搭建数据指标体系，一方面有助于数据产品经理根据数据缕清产品设计思路，另一方面也有助于推动团队理解与后期产品落地。本篇文章里，作者总结了构建数据指标体系中的注意事项，一起来看一下。

构建指标体系可以说是数据产品经理的「基本功」，在工作当中总要和各种各样的指标打交道，这篇文章聊聊在做指标设计的时候遇到的麻烦、解决的方法，对容易忽视的问题进行了重点标注。

文章的整体构架如图：

一、数据指标体系概述

1. 「自下而上」理解「单个指标」的定义

在介绍如何构建数据指标体系之前，咱们先看看「单个指标」通常都是怎么定义的，以交易环节中常用的指标“当日通过微信支付的用户数量”为例，对指标结构进行拆解：

• 时间周期：用于明确时间范围，如当日、近3日、近7日、近30日、营销窗口期……
• 修饰词：用于明确场景类型，如浏览、阅读、点**、收藏、设为最爱……
• 原子指标：不可再拆分的核心表述，如总时长、文章数量、支付金额、下单笔数……

「自下而上」的应用方式：

几乎所有的指标都可以依据上述的方法进行拆分，工作中我**使用它做两件事情：

1. 在指标设计的初期，快速地头脑风暴几个指标demo，便于后续和业务人员更具象地沟通讨论，提升效率；
2. 在指标设计交稿之前，复审指标有没有拆分不到位、遗漏的情况，尽可能地减少二次开发。

2. 「自上而下」构建「数据指标体系」

1）第一层：业务板块

数据平台往往面向的是公司/事业群的业务，**有多个业务板块（新闻、视频、电商、广告等等），每个业务板块服务的人群是不一样的，关注的维度也就不一样。类比于公司的组织架构一样，在设计指标体系的时候，第一层可以按照业务板块进行划分。

2）第二层：业务子模块

面向业务的进一步模块划分；以电商为例，可以有用户模块、商户模块、供应链模块、支付模块等等，它们有些侧重于属性特征（如商户模块）、有些侧重于行为特征（如支付模块），进行拆分后便于管理和维护，同时也方便后期与其他系统进行基础信息共享。

3）第三层：业务环节

对用户行为等进行拆解，以支付模块为例，通过对全链路进行拆解，可以划分为“提交订单→支付→退款”等环节。

4）第四层：时间周期、修饰词、原子指标

时间周期很好理解，重点说一下修饰词，这个地方需要去深入理解业务，才能设计出合理的、对业务真正有帮助的指标。

比如支付环节，**有“正常支付的、**时未支付的、多次支付失败的、因余额不足导致支付失败的、自动退款的”等等。这部分内容要和需求方（运营、业务产品经理等）进行深入沟通和确认，后面的建设步骤中也**有介绍。

「自上而下」的应用方式：

在和需求方大致沟通业务需求之后，在整体框架设计中可以采用这种方式对指标体系进行梳理：

• 便于缕清思路，避免遗漏大的模块和环节（如果架构上有遗漏，很有可能大大增加后期的维护和重构成本）；
• 便于后期数仓开发的人员理解需求，减少沟通成本。

二、如何说服各方配合搭建数据指标体系

之所以把这个环节单独作为一节，是因为数据平台具有中台属性，最终是要服务于业务，争取各方支持对于数据指标体系的建设质量和价值体现非常重要，有了好的开头后面的事情才**顺利。

当然这件事有时并不容易，但做到了的话，好处是显而意见的：

• 有利于争取资源。毕竟公司的研发资源是有限的，争取到更多领导的支持自然有助于获取资源，不然可能就是“这个需求，排期明年吧”，有再好的想法没有资源能落地也很难受。
• 指标更系统化、更有业务导向，不**闭门造车。术业有专攻，数据产品经理不可能洞悉所有的业务环节和细节，而产品经理和运营人员更了解产品的模块、关心点和常见问题等，有大家的深度参与最终的效果才**好。
• 有助于体现数据平台的价值，获得各方的认可。从心理学上讲，大家亲自参与的项目，**更有认同感和使用的欲望，毕竟只有大家真正的把数据用起来，才能更好地体现数据价值。

那究竟怎么做呢，有一些小tips仅供参考。

1）需求侧，抓住一切可能的机**输出「数据指标体系能够提升大家工作效率」的理念。

比如多个部门在一个活动上汇报的数据不一致，大老板询问数据平台的时候，你可以抓住机**，“如果作为指标统一起来，可以避免大家对指标定义不一致的问题，可以更高效地定位问题，更准确地反映业务发展情况……”

再比如搞一个营销活动，运营人员找到你，想要一个用户增长数据的时候，你可以向他介绍，“临时增加这个指标需要多长时间，他可能需要比较滞后才能看到这个数据，但是如果在早期就已经做好了指标的设计，那这个时候就只需要场景迁移，时间**缩短XXX”。

老板认可了，执行层的员工也理解了这个事情对工作的帮助，合作起来自然比较愉快。

2）研发侧，除了输出理念，还有一点非常重要，做一个「靠谱的中间人」。

• 指标框架和需求要清晰明了，最好能有demo示例，便于高效达成一致理解，减少反复；
• 要对业务环节有一定程度的了解，提升效率，不能只做“传话人”，对研发提的业务问题不能一问三不知；
• 有同理心，在汇报中尽量体现各方的贡献和产出。

三、搭建数据指标体系的步骤

以电商场景为例，搭建数据指标体系。

1. 需求调研

在数据指标体系的搭建初期，一定要与各业务方深入了解业务场景、业务流程和核心关注点。

需求调研的方式有很多，从定性与定量、主观和客观两个维度来划分，大致有四种方法：用户访谈、问卷调查、可用性测试和数据分析。

简单说就是苏杰老师的“定性地说，定量地说，定性地做，定量地做”（具体的方式建议大家读一下《人人都是产品经理》，很经典的一本书，上面很多例子让人印象深刻）。

• 用户访谈：可用于产品前期问题收集以及日常发现问题的原因探寻；
• 问卷调查：可用于确定具体问题的重要程度；
• 可用性测试：招募用户真实使用产品，收集用户反馈；
• 数据分析：通过分析大量用户的真实使用情况发现问题。

注意这里需求方提出的有可能是「伪需求」，数据产品经理要有「打破砂锅问到底」的精神。

举个例子：

• 运营喵今天说“用户投诉今天支付失败率好高，能给我一个界面看到失败率吗，有情况我好及时发现？”
• 产品汪完全按照需求方的要求，这个功能很快上线了。
• 后续需求马上又来了“能给我一个区分支付渠道的失败率吗？”、“失败原因的数据有没有呀？”
• 于是产品汪和程序猿又忙碌了起来，好不容易两天后功能上线了。
• 运营喵感慨“平台效率好低哦，这个需求提了好久了呀，怎么这次又要等好几天”。
• 最终的结果就是大家都很疲惫……

其实可以一次性解决的问题，工作中可能要折腾很多次，究其原因，有部分原因是在需求沟通的时候没有聊透。

如果在第一次，产品汪能够了解到，发现失败率高之后运营喵要定位是哪个渠道出了问题，再进一步需要知道是收单机构的问题还是账户机构的问题，更进一步定位失败原因，他就可以给运营喵提出建议，”你的问题可以通过系统错误码和业务错误码进行定位”，从而设计一个由错误码为底层数据的数据采集和处理流程，指标体系的可扩展性就强了很多。

下次运营喵发现问题的时候，就可以通过数据平台的下**功能一层一层地定位问题了，效率提高了不少，同时也可以提升用户体验。

这种情况相信大家多多少少都遇见过，其实大家都没错，只是看不到”认知范围以外的事情”。

• 从运营喵的角度：定位问题原因是很常规的操作呀，需要费这么口舌吗；
• 从产品汪的角度：收到的需求就是”展示失败率”，满足需求了呀；
• 从程序猿的角度：早说是这个功能呀，浪费了好多时间，后面还有好多需求排着呢。

收到需求后不要马不停蹄地就开干，尽可能地去挖掘用户的真正需求，极致的数据产品经理甚至能根据需求背后的问题场景，筹备更具有建设性的解决方案，“比用户更了解用户”。

2. 分析业务流程，明确业务口径，划分优先级

电商是零售交易模式的一种，一般围绕“人”、“货”、“场”进行指标设计。在场中的平台运营环节，大致可以分为“浏览→加入购物车→提交订单→支付→评价”（实际中还有注册/登陆、加入收藏夹、退货退款、复购等众多可能环节，此处不做展开）。

每个流程都需要很多业务指标支撑后续的分析，这里举几个例子，后面如果有时间再详细写：

• 浏览阶段：用户浏览量、页面停留时长、页面有效浏览时长、直接跳出APP的用户比例等；
• 加入购物车阶段：今日加购的商品数、近3日加购的商品数，加购**过30天的商品数，加购商品中女装占比，加购商品平均价格等；
• 提交订单：提交订单的笔数、提交订单的金额、提交订单的用户数量、提交订单的地区分布等；
• 支付：支付成功/失败笔数、支付成功/失败金额、支付成功/失败用户数、支付成功/失败商品数、支付失败率、多次支付失败的用户数量、主动取消支付的用户数量等；
• 评价：商品好评率/中评率/差评率，有效评价率等。

明确业务口径的时候，对于有阈值设置的指标（例如近7天每天都登陆APP的用户数量），要确认阈值的合理性，因为这个阈值有可能是需求方拍脑袋定的，而后续修改其实可能非常麻烦。

常用的方法是对指标分布进行测算，和需求方一起通过分布情况选择一个合理的指标。从实际情况出发，如果类似的指标比较多，测算时间来不及的话，可以选定其中几个重要的指标进行测算，至少保证核心指标的可用性。

数据产品经理还有一项很重要的工作就是「划分优先级」，因为工作中每个业务都有非常非常多的指标需要建立，而这些都是有成本的，所以需要综合考虑性价比，圈定核心指标优先开发。

3. 明确技术口径，判断可行性

数据产品经理需要将指标框架和指标业务逻辑给到数仓建模工程师，由他完成指标的计算。可以在业务指标的初稿出来之后（而不是定稿之后），就与技术人员进行沟通。

• 需要确认指标是否可计算，有些数据没有进行埋点上报，底层数据层面就是不支持的；
• 可以大致沟通一下开发时间和排期安排。

适当提前介入技术口径阶段，避免“理想很丰满，现实很骨干”的状况发生。

进阶一步，告知需求方那些目前无法实现的指标，在上线了哪些功能/埋点后可以获取，如果大家判断说这个指标确实很重要，那么下一步组**业务方产品经理看看要不要做这个功能。

4. 原型设计

指标计算后，一般在数据平台上进行可视化展现（仪表**和报表等），这很考验数据产品经理对数据的理解，需要根据指标的含义选择其合理的展现形式：

• 表格：一般用于展示明细数据；
• 柱状图：一般用来展示2-4主体的指标对比情况；
• 饼状图：一般用来展现占比情况；
• 折线图：一般用来展现趋势变化，查看一定时间段的数据波动情况；
• 地图：一般用来展现热点地区分布情况；
• 漏斗图：一般用于展现环节比较多的流程分析，如“浏览→加购→提交订单→支付 ”每一个环节的流失率；
• 桑葚图：一般用于展现用户行为路径，如新增用户在一段时间后变为**、活跃用户、僵尸用户等。

互联网公司一般都有专业的「BI方向」的数据产品经理，还有UI设计师，既然这章主要讲指标设计，那这部分内容后续再单独写。

5. 项目流程跟进（评审、数据开发、前后端开发、测试、上线）

数据产品经理需要推进产品的开发状态，一般的环节如下：

• 评审：组**向重要环节成员介绍产品的价值、功能和交互形式，演示demo，目的一是拉齐大家对产品的理解，提高效率；二是倾听不同领域的专家意见，查缺补漏，及时发现问题，避免返工。
• 数据开发：对接大数据开发工程师、数仓建模工程师。
• 前后端开发：对接UI设计师、前端开发工程师、后端开发工程师。
• 测试：对接测试工程师。
• 上线：对接运维工程师。

测试环节最好拿部分「现有的数据」和「待上线产品的数据」进行校验，增加准确性，因为有些指标计算比较复杂，测试环节可能**有遗漏，毕竟是上线前的「守门员」，建议多一层防守。

6. 跟进用户反馈

产品上线「是服务的开始，而不是服务的结束」，接下来要长期跟进指标的变化，优化指标的展现形式。当有新产品上线、业务模块更新或新营销活动上线时，数据指标也需要进行更新。

数据产品也是产品，虽然现在大多数企业还是内部使用，没有对外赋能，但是也需要有合理的”运营“和“推广”。公司内部可以通过编写使用手册、开展跨部门培训等方式让大家更好地把数据平台“用起来”，也可以小规模锻炼自己在用户增长方面的能力。

在收集用户反馈方面，不要被动被吐槽，要主动出击：

• 通过后台数据可以分析最近用户的使用频率、常用的操作、高频访问的指标、失败的操作记录等；
• 主动找运营、业务产品的同事面对面聊聊，问问他们的使用体验和建议。

近期**集中更新一些之前的笔记，期待交流和批评指正。

本文由 @Amy 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。