一文帮你更好地理解指标

lee
0 评论 3758 浏览 18 收藏 14 分钟

编辑导读:产品每天在使用,数据在不断增长,我们需要对产品的表现进行量化,建立一个精良的指标体系,以帮助我们做出科学的决策。如何搭建指标体系呢?本文作者从自身工作经验出发,对此展开了五个维度的分析,一起来看一下吧。

随着市场竞争进入白热化,越来越多的公司由原来的增长黑客转变为精细化运营,不管是增长还是留存,我们都需要对产品的表现进行量化。

数据指标,就是量化信息的别名,科学的决策离不开构建精良的指标体系。

本文重点从技术视角,给大家介绍指标的定义和实现。文中会有部分简单的 SQL 示例,文末会给到一些实用的参考资料。

01 一个例子讲清楚指标的定义

小明看到自己喜欢喝的一款高端酸奶标价 8 元,他连忙拿了一瓶去买单。结果店员告诉他,本次活动第一瓶是原价,第二瓶才是 8 块的半价 。

上面的例子中,单纯一个数字,是没有意义的,必须要相应的解释,人们才能理解。“买满两瓶,第二瓶酸奶的单价是 8 块”,这才是真正完整的指标。

用一个简单的公式给出指标的定义:

指标 = 数字 + 解释

其中解释包含两方面:业务上的解释;技术上的解释。

业务解释通常是图文,意在给指标使用者解释指标从何处来,怎么算。

技术解释通常是用程序语言定义的计算逻辑,比如用 SQL 语句定义人数为 count(user_id),均价为 avg(price) 。

其实理解了元数据,就能理解指标,大家可以参考文末的元数据文章。

02  如何设定合理的指标

互联网发展到现在,很多行业或公司都有了成熟的指标体系,而最初构建指标体系,都要围绕关键指标(北极星指标)展开。

社交类产品,关键指标是 DAU ,因为社交产品的核心是希望更多人能更频繁地用它沟通交流。

电商类产品,关键指标是 GMV ,因为电商平台希望能承载更多的线上交易。

视频类产品,关键指标是用户观看时长,因为这类产品的目的就是为了帮助用户杀时间。

不同行业,业务不同,核心关键指标也不同。

而不同之中有相同之处:关键指标都能反映产品表现,且能衡量产品的直接或间接商业价值。

指标体系的构建,要基于业务展开,尤其是核心业务。基于核心业务流程,进行层层拆解,逐渐构建起企业的业务指标体系。

拿电商行业的 AARRR 漏斗模型举例,每个业务阶段,都会有相应的北极星指标。

想要构建科学的指标体系,必须花时间深入了解公司、部门的关键业务。通常来说,经营性业务指标是业务型产品经理重点关注对象。

不过,公司对人才的综合能力要求越来越高, T 型人才的说法广为流传,产品经理也被越来越多地要求具备数据分析能力,所以了解下指标的管理与实现,对我们会有很大的增益。

03 指标该怎么管,要解决哪些问题

公司业务多,则指标多,如此多的指标,怎么管才好呢?

起初,很多公司会用 Excel 管理,构建一本“指标字典”,如果不明白某个指标什么意思,就去翻翻字典。毕竟,先上车后补票,让业务跑起来最重要。

公司业务发展好,人更多了,离线 Excel 文档不便于多人协同的问题就暴露了,在线文档出现后,离线文档逐渐被替代。

也有的公司也会用脑图来管理指标,不过这一类的工具,都算作是在线文档。但文档内容还是差不多,大体如下:

因为数据通常都是存在关系型数据库中的,所以定义指标时,也需要技术人员基于业务的数据模型给出技术口径,即指标的计算方式。

统一的指标共享文档,解决了指标业务口径一致性的问题,但还有 2 个问题没有解决:

  1. 业务口径和技术口径的关联
  2. 技术口径的复用性

先说第一个问题。假设系统中有一张用于记录用户登录的记录表,其结构如下:

起初,每日活跃用户定义为每天登录的用户数,日活用户数的取数SQL表达式为:

业务发展一段时间,日活指标的定义修改为“每日停留时长达到 1 个小时的用户”。业务定义变了,技术定义也要随之变动也会变动。假定有另一张用户行为记录表,结构如下:

那么日活用户数的取数的SQL表达式为:

而作为产品的运营者,我们监测用户活跃度,往往还会得到更细的数据,比如近 1 天活跃用户数、近 7 天活跃用户数、近 14 天活跃用户数。

每一个业务口径都对应着特定的分析条件,业务口径可有修改其中的分析条件组合方式,所以会对应很多种具体的技术逻辑(比如 SQL 语句)。

而且,当指标的业务口径变化时,技术定义为了保证数据的准确性,也要随之变更。如果每一种组合都写定一个逻辑,那么工作量是浩大的。

为了降低技术对业务支撑的难度,聪明的工程师们就想出了办法:对指标进行分层管理。

04 指标,具体如何分层

如果你看过指标管理的文章或书籍,或者体验过指标管理系统,那你肯定这个结论:指标要分层,通常分 2-3 层。

按照阿里的分法,指标有两层:原子指标(有一个小中间层:衍生原子指标)、派生指标。按照华为的分法有三层,分别是:原子指标、衍生指标、复合指标。

当我们接触一个新东西, 我们通常最先会看到演进的最终结果。如果我们忽视演进过程不去探究,会有一个问题,我们回答不清楚为什么是这样。

上文其实已经给出了指标分层管理的背景,那指标到底为什么要分层?

答案就是为了方便复用和重新组合。

事实表中有三种字段:事实属性字段、度量字段、维度字段。

原子指标的来源有三种:

  1. 对事实表中的属性字段进行计数,比如count、count(distinct)
  2. 对事实表中的维度字段进行计数,比如count、count(distinct)
  3. 对度量字段进行聚合操作,比如求和、求平均值等

原子指标 +  时间限定 + 业务限定(修饰词) = 衍生指标

第一节中,我们知道指标是由数值和解释组成。假设我们知道了一个数值的业务含义,接下来,我们就会关心这个数值从何而来,以及数值是怎么计算得出的。

而原子指标,就承担了这样的角色。原子指标定义了数值从哪里取得,如何计算。比如活跃人数,是从用户登录表根据对 user_id 进行计数而得来。也就是上面表格里面的 count (user_id)。

为了识别和区分,我们会对事物进行归类。比如性别:男/女,时代:当代/近现代/古代,地区:国内/国外。

这些区分事物的“东西”,我们称其为维度。维度还可以拆得更细,且不同维度之间是可以组合的。

阿里对派生指标的定义为:

衍生/派生指标 = 原子指标 + 时间周期 + 修饰词

其中的时间周期,我们也可以理解为时间维度,因为大多数时候,我们业务分析上都是用的离散的时间值,比如近 1 天、近 3 天、截止当前等。

修饰词,可以理解为不同的维度,或者是维度中特定某个值。比如地区维度,且维度值为北京。

抽象的东西,通过例子来理解:

近 1 个月北京市的活跃用户数 = 活跃用户数(原子指标) + 近 1 个月(时间周期) + 北京市(修饰词)

将原子指标、时间周期、修饰词、维度等分别定义出来,就好像乐高积木,工程师将最细粒度的标准化零件构建出来,并且设定好零件之间的组合规则,用户可以根绝自身业务需求进行组合,组合完成后,系统自动生成对应的 SQL 语句。

一方面减少了重复劳动,另一方面,对某个原子指标进行改动的时候,其他依赖该原子指标的衍生指标对应的逻辑系统也会自动更新。

05 建设指标管理系统的认知层次

如果你同为数据平台的产品经理,也要为公司建设指标管理系统,可以从如下三个层次进行认知突破。

第 1 层次:

掌握一些常识概念,了解基础流程。

通过查阅各个竞品,知道原子指标、派生指标、复合指标、业务限定等基础概念,大概知道指标的需要哪些属性(要是要做系统,可以先照猫画虎)。

第 2 层次:

明白数仓分层,以及指标体系。

对数据仓库(维度建模、分层)、业务数据库(范式建模尤其是 3NF)、数据库基础(聚合函数和group by)、元数据等有一定的理解。

第 3 层次:

深入业务,服务业务,优化业务。

深入了解业务,知道业务方关心哪些核心指标,核心指标建设的优先级、怎么管、怎么运营,指标如何帮助业务部门解决问题。毕竟,数据价值最终要在业务上体现~

06 写在最后

本人作为数据平台产品经理,现在重点参与部分是数据中台的指标系统建设,对于业务方的指标需求认知还有许多不足之处。

从我的视角出发,给有不同需求的小伙伴一些建议。

如果你是业务型产品(前台),平时要负责产品的规则和玩法设计,需要观测产品的各项用户指标,那你应该侧重掌握业务逻辑,定义运营指标,并拆解出业务指标体系。

如果你是平台型产品(中后台),要更多考虑是为业务赋能,降本增效。建议你熟悉掌握相关技术知识和底层概念,构建全面的技术认知,再深入了解业务需求。

学以致用,祝各位都能用好指标,管好指标,共同创建美好的数据时代。

 

作者:lee;公众号:乐说乐言

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

题图来自 Unsplash,基于 CC0 协议

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