结论：指标下线的核心不是"删不删"，而是把判定标准从主观判断变成可量化的打分模型 + 低阻力流程。我们团队从 350+ 指标裁到 180 个，用了下面这套组合，误杀率 < 3%。
一、量化打分模型（直接可抄）
给每个指标算一个 Retention Score（保留分），满分 100，低于阈值进候选池：
| 维度 | 权重 | 打分规则 | |------|------|----------| | 近 90 天直接调用量 | 30 | 0 次=0 分；1-10 次=10 分；>10 次=30 分 | | 下游血缘（被多少任务/看板引用） | 25 | 0 个=0 分；1-2 个=10 分；≥3 个=25 分 | | Owner 状态 | 20 | 在职且近期有 commit=20；在职但 90 天无 commit=10；离职/转岗=0 | | 周期性访问（见下文） | 15 | 最近 4 个完整业务周期每周期 ≥1 次=15；有 1-2 个周期有访问=8；全 0=0 | | 上线时间衰减 | 10 | <6 个月=10；6-18 月=5；>2 年=0 |
下线候选阈值：Retention Score ≤ 20 分。 我们 350 个指标里，约 78 个命中，最终实际下线 52 个（其余 26 个在异议窗口被拉回）。
用 SQL 伪代码（假设你的元数据表叫 metric_registry，调用日志表叫 metric_access_log）：
SELECT m.metric_id, m.metric_name,
-- 调用量分
CASE WHEN COUNT(al.access_id) = 0 THEN 0
WHEN COUNT(al.access_id) <= 10 THEN 10
ELSE 30 END AS access_score,
-- 血缘分
CASE WHEN (SELECT COUNT(*) FROM lineage WHERE metric_id = m.metric_id) = 0 THEN 0
WHEN (SELECT COUNT(*) FROM lineage WHERE metric_id = m.metric_id) <= 2 THEN 10
ELSE 25 END AS lineage_score,
-- owner 分
CASE WHEN o.status = 'active' AND o.last_commit > NOW() - INTERVAL 90 DAY THEN 20
WHEN o.status = 'active' THEN 10
ELSE 0 END AS owner_score
FROM metric_registry m
LEFT JOIN metric_access_log al ON al.metric_id = m.metric_id AND al.ts > NOW() - INTERVAL 90 DAY
LEFT JOIN owner o ON o.metric_id = m.metric_id
GROUP BY m.metric_id
HAVING (access_score + lineage_score + owner_score) <= 20;
二、周期性访问的判定（你问的第 2 点）
关键判据：观察期必须覆盖完整业务周期，且用"周期覆盖率"而非"总量=0"。
具体做法：
- 确定该指标所属业务的最小周期（日/周/月/季/年）。B 端 SaaS 常见的是月度和季度。
- 观察期 = max(30 天, 1 个完整业务周期 + 7 天缓冲)。月度业务 → 37 天；季度业务 → 97 天。
- 判据：最近 N 个完整周期中，每个周期内是否有 ≥1 次有效访问（有效 = 非爬虫、非自动化巡检、停留 > 3s 或触发了导出/订阅）。
- 覆盖率 < 50% 的周期 → 该项打 0 分（上面模型里的"周期性访问"维度）。
我踩过的坑：一个"季度对账指标"在 90 天窗口内恰好只有 1 次访问（季度末），被模型判为"低价值"。后来加了"周期覆盖率"维度后这类误杀归零。
三、低阻力 SOP（把"砍业务"变成"归档"）
核心原则：把举证责任从"提下线的人"翻转到"想保留的人"。
具体流程（我们跑了 3 轮，稳定）：
Step 1 [自动] 打分模型跑出候选池 → 生成「归档通知」
Step 2 [T+0] 通知发至指标 owner + 关联 PM + 数据团队（邮件 + IM 双通道）
通知里必须包含：指标名、口径定义、近 90 天调用量(=0)、下游引用(=0)、
冻结起始日（T+7）、异议截止日（T+14）
Step 3 [T+7] 指标进入「冻结态」：
- 看板仍可见但标灰 + 顶部横幅"该指标即将归档，T+14 后停止计算"
- 数仓任务暂停调度（保留表结构，不删数据）
- 埋点事件保留但停止聚合
Step 4 [T+7~T+14] 异议窗口：
- owner / 任一 PM 在工单里回复"保留" + 一句话理由 → 自动撤销归档
- 无人响应 → 进入 Step 5
Step 5 [T+14] 正式归档：
- 指标字典标记 status=archived（不物理删除，保留 12 个月可恢复）
- 数仓任务下线（释放计算资源）
- 看板移除（或归档到"历史指标"折叠区）
- 埋点事件标记 deprecated，30 天后停止采集
量化收益（我们团队 350→180 的实际数据）：
- 每轮归档 50-80 个指标，异议率约 15-20%（即 80 个候选里 12-16 个被拉回）
- 误杀率（归档后 30 天内被要求恢复）< 3%
- 数仓计算资源节省约 22%（下线了 52 个指标的聚合任务）
- PM 投诉率从"上次群里质疑"降到 0（因为举证责任翻转 + 窗口透明）
四、无主指标的兜底（你问的第 4 点）
别逐个追离职/转岗的人，用公共冻结池：
- 在指标字典里建一个公共 owner 账号
@data-platform（数据平台团队）。 - 无主指标（owner 离职 > 30 天 且 无交接记录）自动转入该账号名下，状态标记
orphaned。 - 所有
orphaned指标统一进下一轮归档候选池，不单独发起沟通。 - 归档通知里 owner 栏写"原 owner 已离职，当前由数据平台托管"——PM 看到"数据平台在管"比看到"无主"心理接受度高得多。
我们 200+ 指标里约 25% 是无主状态，用这个方式一轮就处理完了，省了逐个 IM 追人的 3 天工作量。
五、一句话总结
打分模型定标准（≤20 分进池）、周期覆盖率防误杀、举证责任翻转降阻力、公共冻结池兜无主。 四件事做齐，指标字典就能从"只进不出"变成"有进有出"，而且业务方不会觉得你在"砍他们"。