一个熟悉的场景
月度经营分析会上，市场部说本月新增客户 8600，运营部说 7200，财务说 6900。三个部门都用了公司的数据平台，都能拿出取数逻辑，谁也说服不了谁。
会议的后半程变成了口径辩论，真正该讨论的经营问题反而没有时间了。
这不是数据质量问题，是指标定义没有唯一来源。
两层建模：原子指标与派生指标
我们推荐的方法是把指标拆成两层。
原子指标是不可再分的业务度量，只包含"度量 + 聚合方式"，不带任何限定条件。比如：
- 订单金额（SUM）
- 客户数（COUNT DISTINCT）
- 订单数（COUNT）
原子指标数量应该很少，一个中型企业通常 30–50 个就够了。
派生指标 = 原子指标 + 时间周期 + 业务限定。比如：
- 本月 + 新增 + 客户数 → 本月新增客户数
- 近 7 日 + 已支付 + 订单金额 → 近 7 日 GMV
派生指标可以有成百上千个，但它们全部由原子指标推导而来，口径天然一致。
关键是把限定条件显性化
回到开头的例子。三个部门的差异其实源于三个未言明的限定：
- 市场部算的是注册用户数；
- 运营部算的是完成实名认证的用户数；
- 财务算的是发生过付费的用户数。
三个数字都对，只是回答了三个不同的问题。
两层建模的价值就在于强迫限定条件显性化——你不能只说"新增客户数"，必须说清楚"新增"的判定标准是注册、认证还是首单。定义一旦写进指标字典，歧义就消失了。
指标责任人机制
技术方案之外，还需要组织机制配套。我们建议每个指标明确三个角色：
- 业务负责人：定义指标含义与口径，有最终解释权；
- 数据负责人：实现计算逻辑，保证数据产出；
- 消费方清单：谁在用这个指标，口径变更时通知谁。
第三项经常被忽略，但它是变更管理的基础。没有消费方清单，任何一次口径调整都会变成一次事故。
指标字典应该长什么样
一个可用的指标字典条目至少包含：
| 字段 | 说明 |
|---|---|
| 指标名称 | 中英文，全公司唯一 |
| 业务定义 | 用业务语言描述，不含 SQL |
| 计算逻辑 | 原子指标 + 限定条件 |
| 统计周期 | 自然日/自然月/账期月 |
| 数据来源 | 上游表与字段 |
| 业务负责人 | 姓名与部门 |
| 更新频率 | T+1 / 实时 |
| 变更记录 | 历史口径与生效时间 |
变更记录这一行尤其重要。当有人问"为什么去年的数字和现在对不上"，它就是答案。
从 BI 到 AI 的前提
近两年很多企业希望在数据平台上叠加 AI 能力——智能问数、自动归因、预测预警。这些能力的效果高度依赖底层的指标质量。
道理很简单：如果"新增客户数"这个指标本身就有三个版本，那么让模型基于它做归因分析，输出的结论只会更加混乱，而且因为披着 AI 的外衣，错误还更难被发现。
指标治理是 AI 能力的地基，不是可以跳过的前置工作。
落地建议
不要试图一次性梳理全公司指标。我们的经验是：
- 选一个业务域（比如销售），梳理其 15–20 个核心指标；
- 走通定义、责任人、字典、消费方通知的完整流程；
- 用一次真实的口径变更验证机制是否有效；
- 再复制到下一个域。
先把机制跑通，再谈规模。