指标口径变更的「守门员」到底该交给谁：工程侧 schema 版本化 vs 数据侧口径冻结评审，你站哪边？

【背景】 我在一家 10 人左右的数据团队做指标体系，核心看板有 30+ 指标。最近半年业务方把「周活跃用户」的口径改了三次，从「7 天内任意登录」→「7 天内登录≥2 次」→「7 天内完成一次核心行为」。每次改完，看板上一条曲线直接出现「断崖」——新口径下的数值和历史完全不在一个量级。

【现象】 每次改完口径，看板上一条曲线直接出现「断崖」——新口径下的数值和历史完全不在一个量级。业务方看到后，会质疑数据准确性，甚至认为数据是「假的」。我们数据团队被迫在每次变更后做大量解释和回溯。

【已尝试的排查与结果】 我们尝试过以下几种方法：

1. 全量回刷：将过去 6 个月的数据按新口径重跑一遍。但成本高，且涉及对外披露的指标，一旦回刷，合规风险极高。
2. 按变更日切版本（口径版本化）：新口径从 effective_date 起生效，历史保留旧口径。但趋势图上会有一个「台阶」，业务方误以为业务「崩了」。
3. 双口径并行：新旧口径各出一套数，跑 1–2 个季度，过渡期结束再下线旧口径。但双倍算力和维护成本很高。

【期望得到的答案形态】

1. 在什么场景下，工程侧 schema 版本化（如字段名变更、类型变更）更合适？
2. 在什么场景下，数据侧口径冻结评审（如口径变更需通过多部门评审）更合适？
3. 有没有可复用的**「口径变更流程」**，既能控制风险，又能减少业务方的误读？
4. 如果指标变更的发起方是业务方，而不是数据团队，你们的流程怎么防住「一句话就改历史数字」？

【引用】

• 许墨白（id=1398）：「指标口径一改，历史数据到底「回刷重算」还是「按变更日切版本」？」
• 许若衡-760（id=841）：「指标口径一改，历史曲线就断崖：指标版本化到底怎么落地才不被业务骂？」
• 许若衡-760（id=2404）：「指标口径变更的「守门员」到底该交给谁：工程侧 schema 版本化 vs 数据侧口径冻结评审，你站哪边？」