同一个指标，产品说 100 万、数据团队说 95 万、后端日志说 103 万——「口径」到底该谁说了算？

【背景】 做了 3 年指标体系搭建，最头疼的不是「指标怎么算」，而是「指标谁来定」。

一个真实场景：上周产品拉了个「核心留存率」复盘会，PPT 里写 42.3%。我拉了同一时间窗的数据，算出来 38.7%。差的那 3.6 个点是去重逻辑——产品按「设备 ID」去重，我们按「用户 ID」去重，而前端埋点里有 11% 的设备 ID 是空的（iOS 隐私限制导致）。

三方都没算「错」，但开会时数字对不上，讨论直接跑偏，最后变成「你们数据是不是有问题」的拉锯。

【常见分歧——我见过三种典型做法】

1. 数据团队说了算：所有指标由数据团队统一定义、统一出数，业务方只看报表。优点是口径一致，缺点是响应慢，业务方觉得「被数据绑架」，紧急需求排不上。
2. 业务方自己算：每个团队自己定义、自己拉数，数据团队只提供底层表。优点是灵活，缺点是同一个词在不同团队含义不同——「活跃」到底是登录、打开 App、还是产生一次有效行为？
3. 联合评审：指标定义走评审流程，产品、数据、后端三方签字确认。听起来最合理，但实际执行中评审文档写完就过时了，业务迭代速度永远快于文档更新速度。

【我的倾向与理由】 我倾向于「数据团队定骨架，业务方定血肉，变更走 changelog」：

• 骨架（去重逻辑、时间窗、过滤条件、数据源优先级）由数据团队统一规范，写进指标字典（metric dictionary），变更必须走 changelog 并通知所有订阅方；
• 血肉（业务含义、汇报口径、目标值、告警阈值）由业务方定义，但必须引用骨架里的字段名，不能自己发明新口径；
• 兜底：每个指标卡片强制标注「口径版本 + 生效日期 + 最近变更人」，开会前把口径卡片甩到群里，5 秒对齐。

理由：口径之争的本质不是技术问题，是「谁有最终解释权」的权责问题。纯靠人治（联合评审）成本太高、衰减太快；纯靠业务方自治又会回到「各说各话」；骨架-血肉分离至少把「怎么算」和「为什么算」拆开了，减少 80% 的扯皮。

【想听大家聊什么】

1. 你们团队里「口径」到底谁说了算？是数据团队、业务方、还是某个明确的「指标 owner」角色？
2. 有没有踩过「同一个指标、两个团队、两个数字」的坑？最后怎么收的场？
3. 指标字典你们有吗？载体是 Notion / Confluence / 代码仓里的 YAML / JSON？维护频率多高？谁来 review？
4. 如果让你给「指标口径变更」设计一个最小流程（别搞太重，两页纸以内），你会怎么设计？
5. 有没有「口径统一了但业务方还是不信」的案例？你们怎么破的？

欢迎拍砖，更欢迎贴你们团队的真实案例——脱敏就行。