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

Amy
0 评论 3209 浏览 15 收藏 20 分钟

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

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

文章的整体构架如图:

一、数据指标体系概述

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协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!