指标口径不统一的三种典型冲突，以及一份对齐清单
只要公司里有两个以上的人在算同一个指标，口径冲突就一定会出现。我遇到过最典型的三类：
一、时间窗口不一致
运营说「昨天日活 12.4 万」，财务说「昨天日活 9.8 万」。查下来两边都没算错：
- 运营用的是自然日 00:00–23:59，按下单时间
- 财务用的是 T+1 结算日，按支付完成时间
数据源不同、字段不同、时区处理也不同。数字对不上是必然的，不是谁弄错了。
二、去重粒度不一致
「活跃用户数」这四个字里藏着最关键的一个词：用户。
-- 按设备去重
SELECT COUNT(DISTINCT device_id) FROM events WHERE dt = '2026-10-25';
-- 按账号去重
SELECT COUNT(DISTINCT uid) FROM events WHERE dt = '2026-10-25';一人多设备、一设备多账号，两种算法的结果能差出 20% 以上。写报表时如果只写「活跃用户数」， 半年后没人说得清这条曲线到底是哪个口径。
三、过滤条件不一致
最常见的是这几条：要不要排除内部测试账号、要不要排除退款订单、要不要含海外流量。 这些条件往往散落在各个人的 SQL 里，谁也没写进文档。
一份能落地的对齐清单
| 项目 | 必须写清的内容 |
|---|---|
| 指标全名 | 中文名 + 英文名 + 唯一 code，三者一一对应 |
| 业务含义 | 一句话说人话的定义，非技术人员能看懂 |
| 计算逻辑 | 完整可执行的 SQL 或伪代码，不能只写「去重统计」 |
| 时间口径 | 自然日 / 滚动 24 小时 / 结算日，以及时区 |
| 去重口径 | 按什么维度去重，为什么选这个维度 |
| 过滤条件 | 排除哪些数据，逐条列明 |
| 数据源 | 哪张表、哪个字段、更新频率、延迟多久 |
| 责任人 | 口径变更找谁确认 |
判断一份指标文档合不合格，标准很简单：换一个人，只看这份文档，能不能算出一样的数。
最后一句实话：文档写完之后，最容易失效的是「责任人」那一栏。人一离职，口径就没人维护了。 建议挂到团队公共位置，改口径必须走评审，别让它躺在某个人的本地文件夹里。
← 返回首页