3. 如何量化Reach（覆盖面）指标
Reach 这个东西，我见过很多团队把它想得太简单。要么拍脑袋给个数字，要么把「可能看到」当成「实际用到」。说到底，Reach 量化的核心就一句话：你的改动，到底能触达多少真实用户。
今天咱们就把这个指标拆开揉碎了讲。你会看到三种不同的量化口径、不同场景下的算法差异，还有我这些年踩过的坑。
核心观点：Reach 不是「有多少人能看到」，而是「有多少人会被你的改动真正影响」。
3.1 先理清楚：Reach 到底算什么
Reach 的全称是「Reach of Impact」，说白了就是你的功能上线后，在给定的时间窗口里，会影响到多少用户。注意这里说的是「影响」，不是「看到」。用户看到了但没用，那不算 Reach。
我个人习惯把 Reach 拆成两个维度：广度和深度。
- 广度：覆盖了多少独立用户
- 深度：每个用户被影响的频率或强度
但在 RICE 评分里，我们主要看广度。深度通常留给 Impact（影响力）去衡量。这样分工更清晰。
一个小经验：我在早期做评分时，总想把 Reach 和 Impact 合并成一个数，结果两个维度都算不准。后来我想明白了——Reach 只管「多少人」，Impact 只管「多深」，分开算反而更准。
3.2 三种量化口径，你选哪一种？
量化 Reach 有 3 种常见口径。选哪个，取决于你的数据基础和场景。
| 口径类型 | 数据来源 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| 用户数口径 | MAU / DAU | 新功能、全量发布 | 直观，易沟通 | 忽略使用频率和目标匹配度 |
| 事件数口径 | 埋点 / 日志 | 功能优化、A/B 实验 | 精准，可量化频次 | 用户去重复杂，需清洗 |
| 覆盖比例口径 | 用户画像 / 分群 | 基础设施、底层能力 | 可跨功能对比 | 分母定义不同，结果差异大 |
你想想看，如果做一个全量上架的新功能，用用户数口径最直接。但如果你优化的是一个只有 20% 用户用过的深层功能，还用 MAU 算，那结果就虚高了。这时候得用事件数口径，或者干脆用覆盖比例。
3.3 不同场景，算法不一样
我建议你按场景来选公式。下面这 3 种是我在项目里用得最多的。
场景 A：新功能上线
公式：Reach = 目标用户群 × 预期渗透率
目标用户群是你希望触达的用户基数。预期渗透率参考同类功能的历史数据。如果没数据，保守点取 10%–20%。
场景 B：功能优化 / 体验改进
公式：Reach = 当前月活中受影响的用户数
直接查埋点，看过去 30 天里用过这个功能的独立用户数。注意要去重，同一个用户用 100 次也只算 1 个。
场景 C：基础设施 / 底层能力
公式：Reach = 全量用户 × 受影响比例
这种场景最容易被高估。比如升级数据库，表面上所有用户都会受益，但实际上只有那些触发慢查询的用户才「真正受影响」。我建议用「实际触发率」来打折。
⚠️ 注意：不要把「全量用户」直接当 Reach。基础设施类的改动，一定要乘以「实际影响比例」，否则你的 Reach 分数会虚高得离谱。
3.4 避坑指南：我踩过的三个坑
做 Reach 量化这几年，我栽过不少跟头。分享三个最典型的，你遇到了直接绕开。
坑一：把「可能触达」当成「实际触达」
我曾经做过一个弹窗功能，PM 说「每天有 10 万用户会看到这个弹窗」。结果上线后发现，真正点击的用户只有 2000。为什么？因为弹窗要满足 5 个条件才会触发，而大部分用户只满足 3 个。后来我学乖了——用「实际触发条件×历史触发率」来算，而不是用「理论上限」。
坑二：忽略用户去重
这是最常见的坑。多个功能、多个渠道会带来大量重叠用户。如果你简单相加，Reach 能算出总用户数的 3 倍。我现在的做法是：所有 Reach 计算，优先用独立用户 ID 去重。没有用户 ID 的，至少用设备 ID 或 Cookie 做近似去重。
坑三：时间窗口选得不对
做新功能一般看「上线后 30 天」，做运营活动可能只看「活动期内 7 天」。时间窗口不统一，Reach 分数就没法横向对比。我建议团队内部约定一个标准窗口——我个人习惯用 28 天（4 周）作为默认值，这样既覆盖了用户使用周期，又避免了月尾效应。
3.5 动手算一个：完整的 Reach 评分案例
假设我们要上一个「智能标签」功能，目标用户是所有内容创作者。以下是我实际做过的一个简化版计算流程。
- 确定目标用户群：内容创作者 50,000 人（来自用户画像）
- 预期渗透率：参考同类「AI 辅助」功能的 30%
- 计算原始 Reach：50,000 × 30% = 15,000 人
- 去重修正：其中 20% 已经在 Beta 中用过了，去掉这批人，实际新增 Reach = 15,000 × 80% = 12,000 人
- 时间窗口：28 天
- 分数映射：12,000 人 → Reach 分数 = 6 分
分数映射这块，我通常用一个简单的分段函数。你可以根据自己的产品量级调整阈值。
def reach_score(reach_users):
"""将 Reach 用户数映射到 1-10 分"""
if reach_users >= 100_000:
return 10
elif reach_users >= 50_000:
return 8
elif reach_users >= 10_000:
return 6
elif reach_users >= 5_000:
return 4
elif reach_users >= 1_000:
return 2
else:
return 1我的建议：分数映射不要搞太复杂的公式。你团队能达成共识、能快速算出结果，比「精确但没人懂」重要得多。我见过有团队用对数函数算 Reach 分数，结果每次评审都要花 10 分钟解释公式，得不偿失。
3.6 小结：Reach 量化的三个关键动作
- 选对口径：用户数、事件数、覆盖比例——根据场景选，别混用。
- 算对数字：目标用户 × 渗透率 × 去重系数，每一步都要有数据支撑。
- 定好阈值：分数映射要透明，团队内部达成一致，避免每次评分都争论「6 分还是 7 分」。
Reach 量化的本质，是用一个可复用的方法，把「覆盖面」这个模糊概念变成团队成员都能理解的数字。你不需要做到 100% 精确，但要做到 100% 可复现——这才是 RICE 评分能落地的前提。