指标字典膨胀到 200+ 个后，怎么定「指标下线」标准才不伤业务

【背景】 我做了 10 年算法，近两年主做数据分析与指标体系搭建。接手一个 B 端 SaaS 的指标字典，半年前约 80 个指标，现在滚到 200+，背后埋点事件 400+。字典本身维护得还算规整（指标名/口径/口径 owner/上线日期都有），但「只进不出」的趋势已经很明显。

【现象】

1. 新需求几乎都从「加个新指标」开始，很少有人回头看旧指标还有人用没有；
2. 有一批上线两年、埋点事件还在跑、但看板里半年没人点的指标，我拉了埋点日志统计下游调用量，约 30% 的指标近 90 天调用为 0，可它们占着口径 owner 的维护心智、也占着数仓计算资源；
3. 更麻烦的是：业务方对「删指标」极度敏感——上次我提议下线 5 个，被一个 PM 在群里质疑「你是不是要砍我们业务」，最后不了了之。

【已尝试的排查与结果】

• 拉了 90 天 BI 看板访问日志 + 数仓下游任务血缘，按「访问次数=0 且无下游任务」圈出约 60 个疑似可下线指标；
• 按「owner 离职/转岗」圈出约 20 个无主指标；
• 试过一次「先冻结（只读、标记 deprecated，保留 30 天观察）再下线」，但冻结后没有配套通知机制，没人感知，等于没做。

【期望得到的答案形态】 不是「要不要治理」这种大方向（大家都说要），而是可落地的判断标准与流程：

1. 你们团队用什么量化阈值判定一个指标可以进入下线候选（调用量、下游血缘、owner 状态如何组合打分）？
2. 「冻结观察期」多长合适？观察期内用什么信号判定"真的没人用"vs"只是这个月没看"（比如大促/月度复盘这种周期性访问）？
3. 怎么把「下线」从"砍业务"的对抗，变成低阻力的动作？有没有把通知/异议窗口/回滚做成标准 SOP 的实践？
4. 对"无主指标"有没有比"找 owner"更省力的兜底处理？

欢迎贴你们的指标字典规模、下线比例和踩过的坑，越具体越好。