第2章 Reach维度详解：如何定义“受影响用户数”、数据来源、不同规模产品的计算口径
Reach（覆盖范围）是RICE评分中首个需要量化的维度，它回答一个核心问题：“当前需求如果上线，在指定时间窗口内会影响到多少目标用户？” 本章将系统拆解“受影响用户数”的定义边界、数据获取链路，以及因产品规模不同而适用的计算口径。
💡 核心认知： 不要将“所有注册用户”或“MAU”直接当做Reach值。Reach强调需求的实际触发人群，而非平台整体用户池。
2.1 定义“受影响用户数”
“受影响用户数”是指在需求上线后30天内（或其他约定周期），因该功能变化而主动或被动产生交互、感知或行为变更的用户数量。按交互深度可分为三个层级：
| 层级 | 定义 | 示例 |
|---|---|---|
| 直接操作层 | 必须主动使用新功能/界面的用户 | 提交订单的新按钮、新增筛选条件 |
| 感知影响层 | 虽不主动操作，但结果或体验受到改变的用户 | 搜索结果排序调整、通知频率变化 |
| 数据波及层 | 后台系统/API调用触发的间接用户 | 积分重算影响历史订单的查看者 |
在RICE评分中，我们优先统计直接操作层 + 感知影响层的并集，数据波及层仅在业务流程强绑定时才计入。
2.2 数据来源：从哪里获取Reach数字？
准确计算Reach需要依赖多源数据交叉验证。以下按可靠度从高到低排列常见来源：
- 产品埋点/事件分析平台（如Mixpanel、Amplitude、自建数仓）—— 最精确，但要求已有同类功能的使用数据或A/B测试样本量。
- 业务数据库/用户标签系统—— 通过SQL统计满足特定属性（如“过去7天有添加购物车行为”）的用户量。
- 问卷/用户访谈样本放大—— 小样本结合置信区间推算总体，适用于全新方向需求。
- 竞品/行业基准报告—— 仅用作交叉验证，不单独作为计算依据。
⚠️ 常见陷阱： 不要直接复用“DAU/MAU”作为Reach。例如“增加英文版支付方式”，受影响用户仅为英文版活跃且发起支付的那部分用户（可能DAU的15%），而非全部DAU。
2.3 不同规模产品的计算口径
产品所处的生命周期阶段决定了Reach的粗糙度与数据可得性。以下给出三种常见场景的口径标准：
| 产品规模 / 阶段 | 典型用户量级 | 推荐计算口径 | 数据容忍度 |
|---|---|---|---|
| 初创期 / 0→1 产品 | < 1万注册用户 | 基于灰度发布的最小可用数 + 功能触发比例的估测值（±50%误差可接受） | 高（优先验证需求） |
| 成长期产品 | 1万～100万MAU | 通过用户分群（行为+属性）统计过去30天类似功能的渗透率，乘以目标人群基数（±20%误差） | 中（需估算但不宜偏差过大） |
| 成熟期 / 大规模产品 | 100万+ MAU | 使用准实验设计或基于历史A/B实验样本的转化漏斗数据，计算精确到千分位（±5%误差） | 低（要求高准确度） |
📊 示例：成长期产品口径计算
需求：“为已下单但未支付用户增加一键催付短信按钮”。
步骤：① 访问数仓查询“过去30天内有下单但支付状态为‘待支付’的用户数”→ 12,480；② 查询“历史催付相关功能的短信点击率”→ 32%；③ Reach = 12,480 × 32% ≈ 3,994。最终取整为 4,000。
需求：“为已下单但未支付用户增加一键催付短信按钮”。
步骤：① 访问数仓查询“过去30天内有下单但支付状态为‘待支付’的用户数”→ 12,480；② 查询“历史催付相关功能的短信点击率”→ 32%；③ Reach = 12,480 × 32% ≈ 3,994。最终取整为 4,000。
2.4 Reach维度计算的完整决策流程
下图的SVG框架总结了从需求输入到Reach数值输出的关键步骤与判断节点：
2.5 常见误区与避坑指南
- ❌ 误区一：把PV/UV当成用户数 —— 同一用户可能产生多次操作，应使用“去重用户ID”统计。
- ❌ 误区二：忽略需求的影响深度 —— 仅计算“看到”的用户，未考虑功能是否真正产生价值互动。
- ❌ 误区三：不同团队使用不同时间窗口 —— 建议统一为需求上线后30天，跨季度需求可改用90天并标注。
- ❌ 误区四：为追求数字好看故意扩大口径 —— 将“搜索引擎收录”用户也算作Reach，导致后续Impact和Confidence估算失准。
🔍 实操建议： 每次计算Reach时，在需求描述旁边额外写下“计算假设”，包括：选择的人群、数据源、时间窗口、是否包含估算。这有助于团队评审时快速对齐。