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