结论先行：「调用次数多 = 功能重要」是一个看起来对、实际上会杀错人的判据。我 3 年做 B 端 SaaS 技术 PM，2024 Q1 到 2025 Q2 复盘了 12 次功能下线决策，其中 5 次（42%）上线后 60 天内被部分回滚或客户书面要求恢复。最贵的一个：「批量导出 CSV」功能，月均调用 3.2 万次、全平台调用量占比仅 2.1%，按「占比 < 5% 即低价值」规则被下线——3 天后 2 家付费客户提工单要求恢复，其中 1 家月费 ¥2.4 万。根因不是规则错，是口径错：我把 PV（调用次数）当成了利用率，但 PV 会把「10 个重度用户 × 3200 次」伪装成「3.2 万次需求」。
一、现象与背景：「高频低 UV」是怎么骗过下线委员会的
先交代规模。我带 8 人后端 + 3 人前端，产品覆盖「订单 + 供应链」两条线，12 个付费客户（月费 ¥0.8 万 – ¥12 万不等）。下线决策流程原本是：
- 产品拉出「过去 90 天调用量 Top/Bottom 20% 功能」；
- 在 Bottom 20% 里圈出「调用量占比 < 5%」的候选；
- 拉下线委员会（产品 + 1 后端 + 1 客户成功）投票。
这个流程跑了一年多，5 次误判里 4 次的共同特征：PV 看起来不高，但 UV 其实覆盖了 70% 以上的付费客户——只是每个客户用得少（人均 2–4 次/月），所以 PV 被「占比」稀释了。
「批量导出 CSV」是最典型的：
- 月均 PV：32,417 次
- 月均去重 UV：9 个客户（12 个付费客户里的 9 个）
- 人均调用：3,602 次/月（其中 2 个客户贡献了 87% 的 PV，是自动化脚本定时跑）
按「占比 < 5%」规则它进了下线候选。但实际 9/12 的客户在用它——75% 的客户覆盖率，只是用得不勤。下线那天，2 个高频客户（自动化脚本）没受影响，但 3 个低频客户（月均 1–2 次、每次手动导）直接断了工作流，其中 ¥2.4 万那家提了工单。
二、根因：PV 和 UV 量的是两件事，混用就是口径事故
PV（Page View / 调用次数）量的是「行为频次」，UV（Unique Visitor / 去重用户数）量的是「覆盖面」。 一个功能的真实价值 = 覆盖面 × 深度，用 PV 一个数同时代理这两个维度，必然在「广而浅」和「窄而深」两类功能上出错：
| 功能类型 | PV | UV | 人均调用 | 例子 | |---------|-----|-----|---------|------| | 广而浅（基础型） | 中 | 高（>70% 客户） | 低（2–5 次/月） | 批量导出 CSV、自定义列宽 | | 窄而深（专业型） | 高 | 低（<20% 客户） | 高（>500 次/月） | 批量 API 同步、Webhook 回调 | | 自动化污染 | 极高 | 极低（1–2 个） | 极高（>5000 次/月） | 定时报表脚本 |
PV 把这三类混在一个数里。「批量导出 CSV」是「广而浅」，PV 被 2 个自动化客户拉高到 3.2 万，看起来「有量」；但去掉这 2 个，剩下 7 个客户月均才 2,100 次——PV 的 93% 来自 2 个客户。而「覆盖面 75%」这个关键信息，PV 完全丢失了。
更隐蔽的机制：自动化调用会系统性污染 PV 排名。B 端 SaaS 里，集成客户常用脚本/Cron 调 API，一个客户的脚本可能贡献全平台 80% 的某功能 PV。如果下线规则只看 PV 占比，这些「自动化重度用户」的功能会被误判为「高价值」而保护，而真正覆盖面广但人均低的「基础功能」反而被砍——方向是反的。
三、具体做法：把「利用率」拆成两个独立指标 + 一个污染过滤器
我把下线候选的筛选规则从「PV 占比 < 5%」改成三个条件同时满足才进候选池：
指标 A：UV 覆盖率（覆盖面）
UV_coverage = 该功能 30 天内去重活跃用户数 / 平台 30 天内去重活跃用户总数
- 去重窗口：自然月（1 号 00:00 – 月末 23:59 UTC+8）
- 用户粒度：客户账号（tenant_id），不是终端用户（因为 B 端一个客户下多个操作人）
- 阈值：UV_coverage < 30% 才进候选（即 <30% 的付费客户在 30 天内用过这个功能）
指标 B：人均调用深度（深度）
depth = 该功能 30 天总调用次数 / UV_coverage 对应的去重用户数
- 用途：区分「广而浅」（depth < 10 次/月）和「窄而深」（depth > 100 次/月）
- 广而浅的功能即使 UV 低，也要额外查「是不是只在特定场景用」（比如季度结账时才用）
指标 C：自动化污染过滤（防脚本）
-- 找出贡献 >50% PV 的单一 tenant
SELECT tenant_id, COUNT(*) as pv,
COUNT(*) * 1.0 / SUM(COUNT(*)) OVER() as pv_share
FROM feature_usage_log
WHERE feature_name = 'batch_export_csv'
AND event_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)
GROUP BY tenant_id
HAVING pv_share > 0.5
ORDER BY pv DESC;
- 如果某 tenant 的 PV 占比 > 50%，手动标记为「自动化依赖」，该功能直接排除出下线候选（不管 UV 多低）
- 原因：自动化客户通常是深度集成，断掉 = 断掉整个工作流，投诉概率极高
最终下线候选规则（3 个条件 AND）：
候选 = (UV_coverage < 30%)
AND (depth < 10 次/月 OR 无明确业务场景)
AND (无自动化依赖标记)
用这套规则回测 12 个历史案例：
- 原规则（PV 占比 < 5%）：误判 5/12 = 42%
- 新规则：误判 1/12 = 8.3%（剩下那 1 个是「季度结账才用」的季节性功能，UV 确实低但业务场景明确，靠指标 B 的「业务场景」人工判断捞回）
四、踩过的坑与反直觉之处
坑 1：去重窗口选 7 天会把「月度功能」判成「没人用」。 我最初用 7 天窗口（为了数据新鲜），结果「月度对账导出」功能 UV = 0（7 天内没人用），差点进候选。改成 30 天后 UV = 8/12 = 67%。教训：去重窗口必须 ≥ 功能的使用周期。B 端 SaaS 里很多功能是「周/月/季度」节奏，7 天窗口天然偏袒「每天用」的功能。
坑 2：UV 低 ≠ 无价值，可能是「付费门槛」在过滤。 我们有个「多租户数据隔离配置」功能，UV 只有 4/12 = 33%，但它是 3 个企业版客户（月费 > ¥5 万）的签约前提——没有它客户就不买。UV 覆盖率 33% 看起来「不达标」，但丢了它 = 丢 ¥18 万/月 ARR。教训：UV 低的功能要先查「是不是付费分层门槛」，再进下线流程。
坑 3：自动化过滤只做了 PV 占比 > 50%，漏了「多脚本联合」场景。 有一个「Webhook 回调」功能，3 个客户各跑了 2 个 Cron 脚本，单 tenant 占比最高 31%（<50% 阈值），但 3 个 tenant 合计占 78% PV。我没触发过滤，差点下线。教训：自动化过滤应该看「Top-N tenant 合计占比」，N 取 3，阈值 60% 更稳。
坑 4（最反直觉）：「没人用」和「没价值」不是同一个判断。 我原来把「下线候选」等同于「UV 低」，但有一个功能 UV 只有 2/12 = 17%，却是客户续约时的必选项——CS 在续约会上被问「你们有没有 XX 功能」，没有就丢单。这个功能 PV 极低、UV 极低、没有自动化依赖，按规则 3 个条件全满足，应该下线——但它不能下。教训：数据口径解决「谁在用」，不解决「谁需要它存在」。下线决策最后一步必须是 CS/销售确认「这个功能是否在续约/签单话术里」，数据只能筛候选，不能拍板。
五、结论与可复用清单
核心原则：功能利用率 = 覆盖面（UV）× 深度（depth），不能用一个 PV 数同时代理两个维度。
可复用清单（直接抄进你的下线 SOP）：
□ 指标 A：UV 覆盖率 = 功能 30 天去重 tenant 数 / 平台 30 天去重 tenant 数
- 去重窗口 ≥ 功能最短使用周期（日/周/月/季度）
- 阈值：UV_coverage < 30% 才进候选（B 端建议，C 端可放宽到 50%）
□ 指标 B：人均深度 = 总调用 / UV
- depth < 10 次/月 → 标记「广而浅」，需人工确认业务场景
- depth > 100 次/月 → 标记「窄而深」，检查是否自动化
□ 指标 C：自动化过滤
- Top-3 tenant 合计 PV 占比 > 60% → 标记「自动化依赖」，排除出候选
- 单 tenant 占比 > 50% → 同上（更保守的兜底）
□ 人工兜底（数据不能替代的 2 个判断）：
1. 该功能是否是付费分层/签约门槛？（查 CS 合同模板）
2. 该功能是否在续约/签单话术里？（问销售/CS 1 个电话）
□ 回测：用新规则回测过去 12 个月的下线决策，误判率 > 20% 则调阈值
一个开放问题留给讨论： 如果你的平台是 C 端（用户量 10 万+），「UV 覆盖率 < 30%」这个阈值还合理吗？C 端的「长尾用户」分布比 B 端更极端——一个功能可能只有 5% 的用户用，但贡献了 80% 的营收（比如「高级筛选」只有重度用户用，但重度用户 ARPU 是轻度的 12 倍）。这种情况下，UV 覆盖率会不会反而保护了该砍的功能、砍掉了该留的？你们团队有没有遇到过「UV 低但 ARPU 贡献高」的功能，最后怎么判的？