3. 指标命名规范
指标命名这件事，说实话，看着简单，坑特别多。我见过太多团队，指标建了一堆，最后没人分得清哪个是哪个。你想想看，一个叫 revenue_1，另一个叫 revenue_2，谁能记得住哪个是含税哪个是不含税？
所以这一章，咱们就把命名这件事彻底聊透。我会从英文命名规则、中文别名定义、指标编码体系三个维度展开。嗯，这些都是我踩过坑之后总结出来的经验。
3.1 英文命名规则：让机器和人都能看懂
指标英文名，说白了就是给数据模型看的身份证。它要满足两个要求：机器能解析，人能理解。
我个人习惯用 小写蛇形命名法（snake_case）。为什么？因为大多数数据仓库工具对大小写敏感，全小写能避免很多莫名其妙的报错。
核心命名结构：
[业务域]_[实体]_[度量]_[聚合方式]
举个例子：
order_amount_sum— 订单金额汇总user_cnt_distinct— 用户数去重payment_success_rate— 支付成功率
每个部分我都建议控制在 3-5 个字符以内，太长了写 SQL 的时候手都酸。
我的小习惯：聚合方式统一用缩写。sum、avg、cnt、max、min、rate。别混用 total 和 sum，也别用 count 和 cnt 混着来。团队统一比什么都重要。
我曾经在一个项目里见过 total_sales_amount 和 sales_sum 同时存在，结果两个值一模一样，愣是没人敢删。你说尴尬不尴尬？
3.2 中文别名定义：给业务同学看的说明书
英文名是给系统用的，中文别名才是给人用的。我建议每个指标都要有 唯一的中文别名，而且命名风格要贴近业务语言。
中文别名的核心原则就三条：
- 业务术语优先 — 别自己造词。业务叫「成交额」，你就别叫「交易总金额」。
- 避免歧义 — 「当日新增用户」和「新增当日用户」是两个意思，写清楚。
- 统一前缀/后缀 — 比如所有比率指标都以「率」结尾，所有金额指标都以「额」结尾。
| 英文名 | 中文别名 | 说明 |
|---|---|---|
| order_amount_sum | 订单总金额 | 所有订单金额加总 |
| user_cnt_distinct | 独立用户数 | 去重后的用户数量 |
| payment_success_rate | 支付成功率 | 支付成功订单占比 |
| avg_order_value | 客单价 | 平均每单金额 |
注意：中文别名不要包含英文单词。比如「订单 amount」这种写法，业务同学看不懂，技术同学也觉得别扭。要么全中文，要么全英文，别混搭。
3.3 指标编码体系：给指标一个永久的 ID
指标编码，说白了就是给每个指标发一个唯一的「身份证号」。为什么需要这个？因为指标会改名、会迁移、会合并。如果没有编码，你根本不知道历史上那个 revenue_v1 到底对应现在的哪个指标。
我建议的编码结构是这样的：
[业务域代码]-[实体代码]-[度量代码]-[版本号]
举个例子：
ORD-AMT-SUM-001— 订单金额汇总 v1USR-CNT-DST-001— 独立用户数 v1PAY-RAT-SUC-001— 支付成功率 v1
每个部分用两位或三位大写字母表示，版本号用三位数字。这样编码可读性强，而且方便扩展。
编码体系的好处：
- 指标改名时，编码不变，历史数据可追溯
- 指标合并时，旧编码保留，新编码建立映射关系
- 跨系统同步时，编码是唯一的关联键
我曾经接手过一个项目，指标没有编码体系。结果数据迁移的时候，光是对应新旧指标就花了整整两周。嗯，从那以后我再也不敢省这一步了。
3.4 整体知识结构
下面这张图，把指标命名的三个核心维度串起来了。你可以把它当作团队规范制定的参考框架。
3.5 避坑指南
最后，我把自己踩过的坑整理成几条原则，你直接拿去用：
- 不要用序号命名 —
指标1、指标2这种，三个月后没人记得住。 - 不要用拼音 —
dingdan_jine这种，看着就头疼。 - 不要用特殊字符 — 空格、连字符、括号，都会在 SQL 里报错。
- 不要用太长的名字 — 超过 50 个字符的指标名，写 JOIN 的时候你会崩溃。
我曾经踩过的坑：有一次我图省事，把「当日活跃用户数」直接命名为 dau。结果半年后业务调整，DAU 的定义变了，但所有历史报表都用的旧逻辑。因为没有编码体系，根本追溯不到哪些报表受影响。后来我花了整整一周，一张表一张表地排查。嗯，从那以后，编码体系就成了我的铁律。
好了，指标命名的三个维度就聊到这里。记住：命名不是小事，它是数据治理的基石。你前期花 10 分钟想清楚命名，后期能省 10 个小时的排查时间。这笔账，怎么算都划算。