写给产品和运营人看的数据系列(1):维度和指标——事实的视角
请不要用“字段”,掩盖自己对维度和指标的一知半解。
刚刚工作那会,我在鹅厂从事广告变现相关工作。在向数据分析师提需求的时候,我只会用“字段”这个词,来指代所有的维度和指标。很多时候,数据分析师同学会向我耐心解释,为什么这个“字段”不能被计算,那个字段没有办法取出来。
直到我后来系统学习了数据分析、数据仓库相关的知识,了解了维度、指标、OLAP、上卷和下钻这些基本概念之后,才发现我当初的需求文档问题有多大,而这也是我写下这篇文章的原因——避坑。
01 为什么要搞清楚维度和指标?
最直接的,理解了维度和指标之后,再跟BI和RD提需求,能避免被当做一个数据白痴,体现自己的专业性(至少看起来)。
其次,理解维度和指标的前提,是了解业务逻辑和数据生产逻辑。
以往我们是从用户流程、组织层级等视角理解我们的业务,但是不妨从数据逻辑视角试试:数据是在哪个主体上,在什么场景下,以什么样的方式被生产和记录的?数据是怎么被加工和呈现的?为什么需要这么呈现?这个指标如果跌了,对业务有指向意义吗?
当你问这些问题的时候,你会发现你不仅要知道产品的设计逻辑、各个模块的功能点,还要知道它们的耦合和组织方式。这些都会驱动你去问同事、查wiki、自己上手体验。相信我,这样全套流程走下来,你对业务和产品一定会有更深入的理解。
再次,理清楚维度和指标,能帮我们确定分析的思路。
业务指标下降了,我们要做定位和分析;要写PRD了,我们要做功能点的收益预估——相信你一定为数据抓耳挠腮过。
那么我们究竟应该从庞大的数据库中,选取哪些“字段”来辅助分析呢?高效的方式之一——在对业务理解基础上提出假设,然后把假设翻译成维度和指标,否则我们只会陷入在庞大的数据细节中而无从下手。
所以,当你理清楚正确的维度和指标的时候,你的问题已经解决了一大半。
02 从事件的视角,认识维度和指标
网上介绍维度、指标及其差异的文章很多,可以作为基础概念辅助初识维度和指标。
我希望从“事件”的视角,带你重新认识这两个名词。
做过App/网页前端埋点的同学,相信对“事件”(event)这个词一定不会陌生,它指的是某个特定行为的发生,如某个按钮的曝光、点击,这些都可以称作事件。
这里,我们将事件的含义泛化一下,不局限在某个具体行为上,也不要拘泥在行为埋点范畴中,而是将其扩展到所有的结构化数据表上。
每一张数据表,都是围绕一个特定事件进行创建的。而事件的发生,必然有其主体,即出发事件发生的人/物/事。
维度,是对事件发生主体属性的补充描述,或者伴随主体而存在的,除了事件发生的时间,它一般是静态存在的,不依赖于事件的发生。
指标,则是对事件发展程度的量化描述;一个指标,通常描述主体的其中一种状态。它依赖于事件的发生,是一个动态变化的数值。
如果觉得抽象,我们来看个例子。
作为产品经理,我们需要关注的一个重要指标是“次留”,即今天打开App的用户,有多少比例会在第2天,继续打开我们的App:回访在这里就构成了一个事件,而事件发生的主体是用户。
如果要细拆留存,可以分拆的维度有:性别、年龄、机型、新/老用户、地域、来源渠道、是否在App内支付过,等等。这些维度,本身是依附于用户这个主体而存在的,它并不依赖于回访的发生。所以,它是一个静态的属性描述,并不会因为事件是否发生,而发生变化。
但是指标不是。次留随着会随着你观察的时间、观察的群体而发生变化。
03 维度的4个作用
1)筛选:我们一般通过维度来筛选所观察的数据范围。
如果是定性的分类维度,那么通过枚举可以筛选,典型的定性维度如年份、省份等;如果是定量的维度,那么可以像指标一样,按照数值大小取一个范围即可,如身高。
2)聚合:通俗地来说,即我们希望在多大粒度上分析数据。
比如你要统计广告消耗,那么是在创意粒度上看,还是将创意粒度消耗数据加总,并上卷到计划粒度分析消耗呢?如果你之前写过SQL,那么肯定知道在对指标进行sum(求和)、avg(求平均)之后,要在脚本最后加入group by XX,也就是你希望聚合到的维度。
但是需要注意的是,你在进行聚合的时候,一定要确认计算的指标,是可以在该维度上可分和可计算的,否则你算出来的数据肯定是错误的,这个会在后面会详述。
3)对比:数据只有在对比的时候才有意义。
我们发现数据上涨、下跌、波动,是因为我们知道正常的数据应该是多少,超过这个范围的数据都是异常的,才会需要进一步比较和分析。我们在对比数据的时候,通常会选择某一个维度,然后在该维度下进行对比。不在同一个维度上,对比2个同样指标,在业务中没有任何意义。
假设我们要对比每一个机型的留存,必须是在同一个维度(机型)的下钻和比较,这通常称为横向对比。
另一种对比,则是以时间为维度的纵向对比。我们看DAU、留存这些指标,究竟是涨了还是跌了,通常都是观察一段时间的指标变化;环比、同比这些,则是基于不同时间窗口维度,对指标的二次加工和计算。
4)归因:这里的归因,指的是对数据波动的解释,而不是数字广告领域的归因模型(attribution model)。
当我们通过同维度的对比,发现数据异常波动时,通常我们需要对波动的原因进行定位和解释。而最终的排查结果,必然会定位到某个维度上,或者维度的某个值(枚举)上。
我们发现昨日的订单数,日环比(相对于前天)跌了30%,如果排除掉运营活动结束带来的正常下跌,而是一个异常的下降,我们必须找到可能的原因。
我们通常会逐个维度分析。比如看品类:是衣服跌的多,还是鞋子跌的多,还是整体都在跌;看时间,订单数量是否在某个时间段跌的多(是否某个时间段服务器崩了);看交易方式(是否某个支付方式出了问题)、看App版本(是否某个版本有bug)……
关于数据波动的归因,后续会再单独用一章的篇幅,来重点讲。
04 指标在维度上是否可分和可聚合
我们拿到一份数据,先不要急着上手分析,而是要弄清楚维度与指标的关系。这里的“关系”我们仍然分两层来理解。
第一层:指标所反映的事实,可以在所选维度上发生、被统计;换句话说,指标所反映的被统计的事实,在业务场景中是真实存在的。
比如我们在数字广告场景中,衡量一条创意好坏的指标是CTR(点击率,Click Through Rate)= 同时期点击次数/该广告曝光次数。我们可以比较不同创意、不同计划之间的CTR,但是不会比较不同广告落地页之间的CTR。
因为广告落地页是用户点击完广告之后打开的页面,外显广告点击行为并不在落地页这个主体上发生。尽管对比之下,不同落地页的CTR之间肯定略有差异,但是落地页并不是造成CTR差异的原因,这种横向对比并无实际意义。
另一个案例中,指标确实在这个维度上发生,但通常情况下并不能被计算。
我们经常看的一个指标是UV(独立访客数),如果在device_id(设备ID)维度上看UV,一般没太大实际意义,因为通常情况下,一个设备ID上只有1个UV,即UV和设备ID等价(除非某些业务如反作弊场景下,需要分析1个设备登录了几个账号)。
第二层:计算时,指标在所有参与计算维度上可分割、可加总。
如果我们把维度,想象成一把梳子,把指标想象成一缕头发。当梳子经过头发的时候,头发能被梳齿,分成N块更细的发束(分割),且头发的数量并没有发生改变;当拿掉这把梳子的时候,这些发束又聚合在一起(加总),恢复成原来的样子。
还是以UV举例。我们通常需要看DAU日活和WAU周活2个指标。DAU统计比较简单,看每天有多少用户数打开了App。WAU是对过去一周的访客数的去重计数,若1个用户在周一和周三都打开了App,在WAU的计算中,这个用户只会被计算一次,但是在日活的口径中,周一和周三会被分别统计一次。
如果我们拿到的是以周为维度、周活为指标的一张表,假设我们想要分析过去一周每天的UV,那么显然不能直接用周活进行计算,即WAU在日期维度上不可分割。反之,周一到周日每天的DAU,加总起来也不是周活,也就是说DAU在周维度上不可加总。
特别要注意的是,一些复合指标在整体上有意义,也能在一些维度层级上被分割和被计算,但是不能被无限分割。
我们通常会看创意、(上卷一层到)计划、(再上卷一层到)账户维度的CTR,但是我们通常不会去计算单个用户粒度的CTR。因为假设每个用户只会看见1次广告,对这条广告点击行为只有“是”或者“否”两种情况,CTR要么是0,要么是1,这种极端值,并不能反映一条广告质量的好坏。
05 维度和指标可互换
我们对于维度和指标的理解,一定要在具体业务场景下深入分析。并不是某些字段一定是维度,某些字段一定是指标;维度和指标的界定,一定要根据具体业务场景,以及在该业务场景下的数据生产逻辑。
正如上文所说的那样,就像“薛定谔的猫”一样,它取决于你对这次事件的主体、性质等的观察。
如果单看“体重”这个字段,你觉得它应该是维度,还是指标呢?
我认为要看“体重”所在的场景。
如果你是一个体育老师,现在要通过体重、升高、BMI、肺活量等这些字段的数值,给每一个学生的健康状况打分,体重在这里就是一个要被计算的指标。
反之,假设我们要看体重跟薪资收入、寿命的关系,则体重作为维度更加适合。
此外,通过二次计算,维度和指标也可以互换,即原来是维度的字段,可以变成指标;反之,指标通过设置区间可以变成维度。
还是以上文提到的广告消耗为例。我们拿到的数据是计划ID(维度)、消耗(指标);但是如果我们想看,消耗在5万及以上、3-5万(不含5万)、1-3万(不含3万)和不到1万的计划数有多少,那么就需要把指标变成一个分类维度,然后对计划ID去重计数——计划数成了指标。
总之,对维度和指标介绍文章看的再多,也不如自己亲手实践。你可以找公司的数仓或者BI同学,要1张数据底表的字段明细,尝试自己分析,比如看指标是否可以在维度上可分割、可加总,哪些维度可以筛选、聚合。
本文作者 @简写2019
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!