同一个「转化率」三个团队三个数：指标口径到底怎么统一才不会被当成甩锅工具？

【背景】 我做了 3 年技术文档，最近转做指标体系搭建。团队约 12 人：2 个数据、4 个后端、4 个产品、2 个运营。核心业务指标有 40 多个，散落在 3 张 BI 看板 + 1 个数据仓库 + 若干 SQL 脚本里。

【现象（具体可复现）】 同一个「次日留存率」，上周三方对数结果分别是：

• 产品看板：23.4%（口径：注册后 24h 内有任意 API 调用即算留存，含测试号）
• 数据仓库跑数：21.1%（口径：注册后第 2 自然日有登录行为才算，剔除 is_test=1）
• 运营周报：25.8%（口径：注册后 48h 内有任意事件，含未激活账号）

三个数差异 4.7 个点，每次周会都要花 20 分钟解释「为什么对不上」，最后谁也不服谁。本质问题是：「留存」这个词在我们团队里根本没有唯一定义，而且每加一个业务场景，口径就裂一次。

【已尝试与结果】

1. 拉了一张「指标字典」Excel（指标名 / 口径 / 负责人 / 更新日），发了 2 个版本——第 3 周开始没人维护，口径又漂移了；
2. 找数据同学把 40 个指标统一成 1 张宽表 + 1 张 BI 看板，上线 1 个月，产品还是自己用 SQL 跑，理由是「看板刷新慢」；
3. 在周报里强制写口径说明，坚持了 3 周，第 4 周大家又开始省略。

【期望得到的答案形态】 希望回答能给出可落地的具体做法，而不是「加强治理」「建数据中台」这类方向性建议。具体希望覆盖：

• 指标字典该长什么样：每个指标需要哪些字段（计算 SQL？时间窗口？分母定义？剔除条件？owner？失效条件？）才不会被当成「文档存档」；
• 单一事实源（single source of truth）在工程上怎么强制：是上 dbt metrics / Cube 这类语义层，还是用数据库视图 + 权限收口，两种路线各自的前置成本；
• 当两个业务方对同一指标有不同口径时（比如「活跃」对产品是登录、对运营是下单），怎么在命名和结构上区分，避免「一个词两个数」；
• 有没有轻量的对账机制（比如每天跑一次口径一致性 SQL，差异超阈值告警），工具或 SQL 模板都可以。

如果能附上你团队的真实指标字典结构（脱敏后）或对账 SQL 片段，会非常有帮助。