同一个核心指标（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 报告强制标注口径版本号（如 conv_rate@v3.2, window=T+7, user=account），让「哪个口径」从口头对齐变成显式声明。

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

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

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