同一个核心指标（GMV/留存/转化率），BI、算法、产品三个口径经常差 5%–15%：该由谁拍板？该不该强制 SoT？

【背景】 做了 10 年算法，带过增长、推荐、风控三条线的模型团队，几乎每个团队都经历过同一个尴尬场景：

• 产品周报里写「本周转化率 6.8%」
• 算法 A/B 报告里写「实验组转化率 7.2%」
• BI 月报里写「本月转化率 6.1%」

三个数都对，三个数都不对——因为口径根本不一样：

1. 转化定义：点击即转化 vs 支付成功 vs 结算完成
2. 时间窗：T+0 实时 vs T+1 离线 vs T+7 退款窗口关闭后
3. 用户口径：设备 ID vs 账号 ID vs 归一化后的自然人
4. 地域/时区：本地时区 vs UTC vs 业务方所在时区
5. 退款/异常：毛 GMV vs 净 GMV vs 剔除风控黑名单后的 GMV

我粗略统计过自己经手的 12 个「核心指标」，平均每个指标在 3 个团队里有 2.4 种口径，差异区间 3%–18%。最离谱的一次：一次大促复盘，产品说「ROI 1:4.2」，算法说「1:3.6」，BI 说「1:3.1」，三个数都进了 PPT。

【常见分歧 / 几种做法】 我见过三种典型模式，各有利弊：

做法 A：各算各的，汇报时口头对齐

• 优点：快，业务方想怎么算怎么算
• 缺点：跨团队对齐成本极高，决策时「听谁的」靠职级而非数据
• 典型场景：小团队、早期业务、指标少（<5 个）

做法 B：数据中台建「指标字典」，落地靠自觉

• 优点：有统一文档，新人能查
• 缺点：没有系统级强制，各团队照样自建口径；字典经常 3 个月不更新
• 典型场景：中大型团队，有数据中台但还没到「指标平台」阶段

做法 C：强制 SoT（Single Source of Truth），所有报表只能从统一指标表取数

• 优点：口径唯一，审计可追溯
• 缺点：核心指标之外的长尾需求全被堵死，业务方怨声载道；指标平台本身成为瓶颈
• 典型场景：成熟大厂，指标治理有专职团队

【我的倾向与理由】 我倾向 分层 SoT，核心思路是「抓大放小，分级管控」：

• L0（~5 个）：公司级核心指标（如 GMV、DAU、留存），强制 SoT，口径由指标委员会（产品+算法+BI+财务）共同定义，变更走审批
• L1（~20 个）：业务线核心指标（如某 BU 的转化率、某场景的推荐 CTR），推荐 SoT，允许业务方在 L0 基础上派生，但必须标注「基于 L0-xxx 派生」
• L2（长尾）：探索性指标、实验性指标，自由定义，但生命周期不超过 90 天，到期必须升级或下线

理由是：

1. 过度统一拖慢业务（做法 C 的代价）
2. 过度分散让决策失真（做法 A 的代价）
3. 分层后，90% 的口径冲突在 L0/L1 就被消化，L2 的混乱不影响核心决策

配套机制上，我认为比「谁拍板」更重要的是让口径差异可见：每张报表/每次 A/B 报告强制标注口径版本号（如 [已脱敏], window=T+7, user=account），让「哪个口径」从口头对齐变成显式声明。

【补充：口径变更回填策略（基于社区反馈修订）】 发布后收到几位同学的反馈，补三个落地细节：

1. 原子口径必须版本化（version + effective_date）：社区有同学指出，如果「活跃用户」这类原子口径只改定义不改版本号，派生指标的 SQL 各自硬编码过滤条件，回填时就会悄悄混口径。正确做法是把原子口径定义成一个「带 version 的 entity」，回填脚本读 WHERE metric_version = 'v3' AND effective_date <= '2024-06-01'，而不是各 SQL 里散落 WHERE duration > 30。

2. ML 特征是血缘图的「隐藏下游节点」：一个增长模型把「活跃用户 7 日留存」当特征用了 2 周，口径漂移导致 AUC 从 0.71 掉到 0.68，重训花了 5 天。建议血缘图的下游节点类型从「报表 / 看板」扩展到「ML 特征工程 / 模型训练 pipeline」，否则口径漂移对模型侧是完全静默的——没有告警、没有看板变红，只有模型 AUC 悄悄掉。

3. 口径变更的「影响面自动枚举」应作为 L0/L1 的 CI 门禁：改一个 L0 原子口径时，CI 自动跑一遍依赖图，列出所有受影响的 L1 派生指标 + ML 特征，强制标注「本次变更影响以下 N 个下游」，审批人看到影响面才能判断要不要加灰度期。这一步把「口径变更」从「改完上线再说」变成「改之前就知道影响面」，和我们做代码变更的 code review 是同构的。

【想听大家在什么场景下怎么选】 特别想收集几个具体场景的经验：

1. 团队规模 < 20 人时，你会直接上 SoT 还是先各算各的？临界点大概在哪？
2. ToC 增长 vs ToB 中台，指标口径的打架频率和烈度差别大吗？
3. 你们有没有遇到过「口径之争」直接导致上线延期或决策回滚的案例？最后怎么收场的？
4. 指标字典 / 指标平台，你们是怎么做的？纯文档、半自动（指标注册+审批）、还是全自动（统一指标服务）？落地成本大概多少？

期待各位拍砖，尤其是 BI 和产品同学——我这边偏算法视角，想听听「被口径约束」那一侧的真实痛点。