第2章：Reach（触达）定义与量化：用户数量、使用频次、覆盖范围的估算方法
2.1 适用场景
- 需求池待办事项排序： 当产品需求池积压超过20条待评估需求，需要快速筛选高影响力需求投入开发时。
- 季度/月度版本规划： 在制定具体迭代计划前，通过Reach评估各需求对核心用户指标（DAU/MAU）的拉动潜力。
- 跨团队资源争夺： 当多个部门提出后台工具或数据类需求，需判断哪个需求能覆盖更多的一线业务人员。
- MVP（最小可行性产品）范围界定： 从曝光量最大的功能切片入手，确保第一个版本能触达足够多的种子用户。
2.2 前置条件
- 已明确产品的核心目标用户画像（Persona）及细分标签。
- 产品数据看板可提供至少近3个月的DAU、MAU及核心功能渗透率数据。
- 已完成《RICE框架概览》(第1章) 的团队对齐，成员对“触达”与“用户总数”的区别有基本认知。
- 业务侧已提供非在线用户数（如：线下门店店员、外部合作方系统对接方）。
2.3 核心概念与计算公式
Reach ≠ 用户总量
Reach 定义：在指定时间周期内，通过该功能实际被影响的独立用户预期次数。
标准公式：
Reach（有效触达）= 目标用户基数 × 使用频次系数 × 覆盖有效率
| 因子 | 解释 | 单位 |
|---|---|---|
| 目标用户基数 | 功能直接服务的最大人群，需排除无关用户。 | 人数/账号数 |
| 使用频次系数 | 每位目标用户在周期内（通常按月）触发该功能的期望次数。 | 次/周期 |
| 覆盖有效率 | 受版本更新率、权限开通率、网络环境等限制，实际可用比例。 | 百分比 |
2.4 详细操作步骤（SOP）
- 步骤一：圈定目标用户基数
从后台导出用户分群数据，去除非目标受众。
案例：某AI绘图功能，基数 = 高级订阅用户数（排除免费用户）。 - 步骤二：评估功能使用频次
通过A/B测试历史数据、原型点击率预估或竞品对标，设定月频次。
案例：批量导出功能 vs 实时预览功能，频次差异可达5~10倍。 - 步骤三：折算覆盖有效率
检查该功能是否需要强制升级App版本、是否需要特定硬件（如高端GPU），若无限制则为100%。
案例：新需求基于Flutter 3.0，当前版本覆盖率70%，有效率 = 0.7。 - 步骤四：计算最终Reach值并归一化
将上述三个因子相乘，得到月度有效触达次数，并转化为RICE评分中的1~10分。
// 示例：在RICE评估表中记录Reach计算逻辑
{
"需求ID": "REQ-AI-042",
"功能标题": "AI智能抠图一键优化",
"目标用户基数": 50000, // MAU中设计师用户
"月使用频次": 8, // 预估每周2次
"覆盖有效率": 0.85, // 需升级至V3.2
"Reach月均触达": 340000, // 50000 * 8 * 0.85
"归一化评分": 7 // 参考Reach区间表：30万~50万为7分
}
提示：统一时间单位
所有因子的时间周期必须对齐。若用户基数使用MAU，频次必须对应“每月次数”，避免使用日活基数乘以月频次导致逻辑混乱。
所有因子的时间周期必须对齐。若用户基数使用MAU，频次必须对应“每月次数”，避免使用日活基数乘以月频次导致逻辑混乱。
2.5 输入与输出物
| 类型 | 内容 | 提供方/生成方 |
|---|---|---|
| 输入 | 用户画像标签表、产品后台按群组维度的MAU/DAU数据、版本升级率报表、功能使用热力图 | 数据分析师、用户研究团队 |
| 输出 | Reach量化数值（带单位：次/月）、归一化1~10评分、推导过程说明文档 | 产品经理（记录于RICE评估卡） |
2.6 责任边界（RACI）
- 产品经理 (R / A): 负责执行量化估算，对最终Reach评分负责，并组织评审会。
- 数据分析师 (C / I): 提供准确的数据基数和频次参考，确认数据口径。
- 业务方/运营 (C): 提供非线上用户（如BD团队人数、地推人员）的规模及使用习惯。
- 技术负责人 (I): 确认版本覆盖率及技术限制对有效率的影响。
2.7 记录材料
使用标准RICE评估卡（Confluence/Jira/Excel模板）记录以下字段：
| 需求ID | 功能标题 | 用户基数 | 月频次 | 有效率 | Reach值 | 评分 | 备注 |
|--------|----------|----------|--------|--------|---------|------|------|
| REQ-01 | AI助手快捷指令 | 50K | 10 | 0.8 | 400K | 8 | 需v3.1以上 |
| REQ-02 | 后台批量导入 | 2K | 4 | 1.0 | 8K | 3 | 管理员专属 |2.8 异常处理
常见异常场景与对策
- 场景一：全新功能，无历史频次数据
处理方案：采用类比法（参考竞品类似功能）或MVP灰度测试，取最小可行值（保守估算）。 - 场景二：B2B产品，涉及多层级账号
处理方案：区分“企业数”和“坐席数”，根据功能触达层级选择基数，并标注单位（如：Reach=100企业×50坐席/企业）。 - 场景三：长期战略功能，短期内基数小
处理方案：按年度目标用户基数计算，但需单独注明“战略型”，并将时间周期调整为年。 - 场景四：Reach评分争议
处理方案：推行“三点估算”（乐观值、悲观值、最可能值），取加权平均作为最终Reach值。
2.9 验收标准
- ✅ 每次Reach评估都包含了完整的用户基数 * 频次 * 有效率三项因子，无缺项。
- ✅ 所有参与评估的需求，其Reach值均附带明确的时间单位（如：次/月）。
- ✅ 推导过程中的假设条件（如：频次参考哪款竞品、有效率基于哪个版本号）已记录至备注栏。
- ✅ 团队经过至少一次模拟演练，对Reach量化标准达成共识，评分误差控制在±1分内。