2. Reach（覆盖范围）定义与量化

Reach 反映一个项目、功能或需求在单位时间内能够影响的唯一用户数量。有效的 Reach 量化需要统一定义 覆盖人数口径、触达频次 和 时间周期 三要素，否则估算数据不可横向对比。

2.1 适用场景

• 需要评估功能上线后能触达多少独立用户。
• 对比多个需求的市场影响力权重。
• 制定 A/B 实验或灰度发布的用户池规模。
• 对客户进行分层运营、分渠道推广前的预算分配。

2.2 前置条件

1. 已明确目标用户群体（如“所有注册用户”“近 30 天活跃用户”“付费会员”）。
2. 已有可获取的用户行为数据源（埋点系统、DAU/MAU 报表、CRM 系统）。
3. 团队已就“一次触达”的最小定义达成一致（例如：1 次页面加载 ＝ 1 次触达）。
4. 已选定用于计算的时间窗口（如 7 天、30 天、一个自然月）。

2.3 操作步骤

1. 确定覆盖人数口径：选择统计基础，例如：
   • MAU（月活跃用户）—— 用于常规功能评估。
   • DAU（日活跃用户）—— 用于高频工具、首页改版。
   • WAU（周活跃用户）—— 用于每周活动、推送类项目。
   • 累积用户（全部注册用户）—— 用于合规、迁移、全量发布场景。
2. 设定触达频次：定义在时间周期内单个用户预计被触发的次数。
   • 一次触达：用户登录/打开页面一次即为 1 次触达。
   • 多次触达：按功能入口层级估算（例如首页 banner → 用户每日访问 1 次 → 7 天内触达 7 次）。
   • 注意：Reach 统计的是唯一用户，不是总触达次数。
3. 明确时间周期：固定计算窗口，如“未来 7 天”“下一个版本周期（2 周）”“季度”。
4. 计算最终 Reach 值：

   Reach = min( 口径用户数 × 触达比例 , 口径用户数 )
   其中：
   - 口径用户数 = 从数据源获取的基数
   - 触达比例 = 实际能触达该功能的用户比例（例如仅 60% 用户会进入二级页面）
   - 若功能入口对所有用户开放，则触达比例取 1.0

2.4 输入输出物

2.5 责任边界

• 产品经理：提供功能入口信息、目标用户群体定义、时间周期选择。
• 数据分析师：从数据平台提取准确的口径用户基数，并审核触达比例假设。
• 项目经理：检查输入数据是否符合当前版本范围，确认 Reach 估算值用于 Effort 和 Confidence 打分。
• 技术负责人：评估实现该 Reach 所需要的后端/前端改动是否影响用户量。

2.6 记录材料

| 项目名称 | 目标用户口径 | 口径用户数 | 触达比例 | 时间周期 | Reach 值 (人) | 备注 |
|----------|--------------|------------|----------|----------|---------------|------|
| 首页改版 | MAU          | 500,000    | 0.85     | 30 天    | 425,000       | 预计覆盖 85% MAU |
| 支付优化 | DAU          | 120,000    | 1.0      | 7 天     | 120,000       | 所有日活用户均需支付 |
| 会员通知 | WAU          | 280,000    | 0.6      | 7 天     | 168,000       | 仅 60% 用户在周内打开通知 |

2.7 异常处理

• 数据口径不一致：不同分析师使用不同口径（如 DAU vs 活跃设备）。
  应对：统一使用“唯一用户 ID”作为基准，并在输入输出表中注明数据来源。
• 触达比例无法准确估算：新功能无历史数据。
  应对：采用保守估计（0.5~0.7），并在备注中标记“待 A/B 验证后修正”。
• 时间周期跨版本：功能分阶段上线。
  应对：按阶段分别计算 Reach，取加权平均或阶段最大 Reach。
• 用户基数波动大：如节假日导致 DAU 飙升。
  应对：取最近 30 天均值，避免单日极值。

2.8 验收标准

1. Reach 值有明确的口径说明（MAU/DAU/其他）和数据来源链接。
2. 触达频次假设必须有文字解释（例如：“用户每日打开 App 一次，视为一次触达”）。
3. 时间周期与项目排期中的观测窗口一致。
4. 所有参与方（产品、数据、技术）已确认过最终 Reach 值并签字（或会议记录）。
5. Reach 值存储在共享文档中，且版本号标记清晰。