核心概念解析：原子指标、派生指标、复合指标、维度与度量
聊指标口径统一，绕不开几个基础概念。很多团队吵来吵去，说白了就是没把这些词的定义对齐。我见过最夸张的一次，业务方说「我要看用户活跃度」，数据团队给了三个不同数字——因为有人用了原子指标，有人用了派生指标，还有人直接拼了个复合指标出来。
嗯，咱们先把这五个概念掰扯清楚。
原子指标：不可再拆的业务度量
原子指标是什么？就是业务上最基础、不可再拆的度量。比如「订单金额」「用户数」「访问次数」。它不附带任何业务限定条件，就是一个纯粹的数值定义。
原子指标三要素
- 业务含义：比如「支付金额」就是用户实际付的钱
- 数据来源：来自哪张表、哪个字段
- 计算逻辑：sum、count、distinct count 等
我在项目中遇到过最典型的坑：有人把「支付成功订单数」当原子指标。你想想看，这其实已经带了「支付成功」这个过滤条件。真正的原子指标应该是「订单数」，支付成功是后面派生时加上的维度约束。
注意：原子指标不要带任何业务限定条件。一旦加了 where 条件，它就变成了派生指标。
派生指标：原子指标 + 维度限定
派生指标就是在原子指标基础上，加上一个或多个维度限定。比如「昨日支付金额」「北京地区用户数」「移动端访问次数」。
我习惯把派生指标拆成三部分看：
- 原子指标：底层的数值定义
- 维度：限定条件，比如时间、地域、渠道
- 统计周期：比如近7天、近30天、累计
举个例子，「近7天北京地区移动端支付金额」——
| 组成部分 | 内容 |
|---|---|
| 原子指标 | 支付金额 |
| 维度限定 | 北京地区 + 移动端 |
| 统计周期 | 近7天 |
我曾经见过一个团队，派生指标命名完全靠脑补。什么「pay_amt_7d_bj」「amt_mob_30d」，三个月后没人看得懂。后来我强制要求命名规范：{统计周期}_{维度限定}_{原子指标}，这才消停。
复合指标：多个指标的运算结果
复合指标是由两个或多个原子/派生指标通过加减乘除算出来的。最常见的比如「客单价 = 支付金额 / 支付用户数」「转化率 = 下单人数 / 访问人数」。
这里有个容易踩的坑——
我的建议：复合指标不要存物理表，尽量用视图或者指标平台动态计算。为什么？因为一旦存了物理表，口径变更时你要同时改ETL和下游依赖，成本翻倍。
我记得有一次，业务方要求把「毛利率」从复合指标改成原子指标直接存储。我问为什么，他们说「计算太慢」。结果查了一圈，发现是底层数据模型没优化，跟复合指标没关系。嗯，很多时候问题不在指标本身，而在数据架构。
维度：看问题的角度
维度就是你看数据的角度。时间、地区、渠道、用户类型、商品品类……这些都是维度。
维度有两个关键属性：
- 维度属性：比如「地区」维度下可以有省份、城市、区县
- 维度层级：比如「年→季度→月→日」
我习惯在维度设计时做一件事：把常用维度属性拍平到事实表里。比如订单表里直接冗余「用户等级」「商品一级类目」。为什么？因为星型模型虽然规范，但查询时多一次 join，性能就掉一截。你想想看，大促期间跑报表，每多一个 join 就是几秒钟的差距。
避坑指南：维度表的主键一定要稳定。我曾经接手过一个项目，用户维度表的主键跟着业务系统走，结果业务系统重构，主键全变了。那一个月我都在修历史数据……
度量：指标的具体数值
度量就是指标在某个维度组合下的具体数值。比如「2024年1月北京地区移动端支付金额 1,234,567 元」，这个 1,234,567 就是度量。
度量和指标的区别，我打个比方：
- 指标是「体温计」——定义了测量什么、怎么测
- 度量是「38.5℃」——具体的测量结果
在数据仓库里，度量通常存在事实表中。我建议把度量字段统一命名为 measure_xxx，这样下游一看就知道哪些是数值、哪些是维度。
五者关系：一张图说清楚
下面这张图展示了原子指标、派生指标、复合指标、维度和度量之间的关系：
统一口径的核心：把概念对齐
为什么很多团队口径统一搞不下去？说白了就是这五个概念没对齐。业务方说「我要看用户数」，数据团队给了 DAU、MAU、累计注册用户数——三个都是用户数，但口径完全不同。
我建议团队做一件事：建一个指标字典，把每个指标按「原子/派生/复合」分类，标注清楚它的维度、统计周期、计算逻辑。嗯，这件事看起来简单，但能坚持做下去的团队不多。
一个小技巧：指标字典不要用 Excel 维护，版本控制太痛苦。我习惯用 Git 管理，每次变更都走 PR 评审。这样谁改了什么、为什么改，一清二楚。
最后说一句：概念对齐是基础，但不是终点。下一层我们要聊的是——这些概念怎么落地到数据模型里。不过那是后面的事了，先把这五个概念吃透再说。