第2章：Reach维度详解——触及用户数的定义、统计口径与数据来源
核心定义，贯穿全章：
Reach = 在特定时间范围内（通常是一个月），功能上线后会体验到的独立用户数量。
基础公式：
Reach = 在特定时间范围内（通常是一个月），功能上线后会体验到的独立用户数量。
基础公式：
Reach = 目标用户基数 × 功能渗透率
1. 用户场景：
作为B2B SaaS的产品经理，你被夹在客户成功（CS）团队要求的小众高级功能和增长团队要求的广泛激活功能之间。CS团队说：“这个合约导出功能对续约至关重要！”增长团队说：“这个仪表盘分享功能能拉来5万新用户！”没有统一且正确的Reach度量标准，你根本无法做出客观决策，只能凭感觉赌博。
2. 业务问题：统计口径的“千人千面”
你的MAU是50,000。但执行“数据导出”功能的DAU只有50。当评估“批量导出增强”这个需求时，Reach应该填50,000还是50？
都不是。这完全取决于你如何定义统计口径以及数据来源是否可靠。口径不一致是RICE模型中最大的噪音来源。
3. 用户访谈与需求拆解：统一“触及”的语言
访谈发现：
- 销售/高管：通常喜欢用“总潜在客户数”或“公司总MAU”夸大Reach，以获得资源倾斜。
- 工程/数据：倾向于使用“严格的技术调用次数”或“DAU”，导致Reach被严重低估。
- 设计/用户研究：关注“人物角色”，但难以量化。
需求拆解结论：我们不能只用一个数字，而需要一套公式和决策树来裁决Reach。
4. 方案表达：明确统计双口径与数据来源
为了解决争议，我们必须在需求文档中明确区分两种口径，并锁定数据来源。
| 统计口径 | 定义 | 典型数据来源 | 适用场景 |
|---|---|---|---|
| 严格口径（保守） | 直接点击/使用该功能的独立用户 | 产品埋点（如Mixpanel、Amplitude） | ToC功能、工具型功能、底层架构改造 |
| 宽松口径（激进） | 间接受益或依赖该输出的独立用户 | CRM系统、工单系统、用户调研估算 | B2B协作功能、审批流、数据分发功能 |
5. 指标验证：如何校准你的Reach模型
功能上线后第30天，必须进行回测校准：
// 验证标准
实际第1个月独立用户数 = 从埋点数据库拉取的实际数据
// 校准逻辑
if (|预测Reach - 实际Reach| / 实际Reach > 0.3) {
// 差异超过30%，说明Reach模型或数据源有系统偏差
// 需要复盘是口径选错还是数据源不可靠
}6. 交付物模板：Reach规划记录表
在需求文档中，必须使用以下模板记录Reach数据，不允许只填一个数字。
| 功能需求 | 采用口径 | 数据来源 | 预计月Reach | 置信度 | 数据尾注 |
|---|---|---|---|---|---|
| 批量导出增强 | 严格（导出者） | 行为埋点（过去90天活跃导出用户） | 1,200 | 高 | 基于当前导出点击率的月活用户推算 |
| 仪表盘分享 | 宽松（分享者+查看者） | CRM + 埋点 | 5,000 | 中 | 假设每个分享者平均触达5个查看者 |
7. 决策流程可视化
以下是Reach指标从定义到输出的标准化统计流程，帮助你快速确定数值。
8. 常见误区与避坑指南
误区一：混淆 Reach 与 Impression（曝光量）
Reach 是独立用户数，Impression 是展示次数。一个用户刷新10次页面产生10次 Impression，但 Reach 仅为 1。
在 RICE 中，我们只使用独立用户数。
Reach 是独立用户数，Impression 是展示次数。一个用户刷新10次页面产生10次 Impression，但 Reach 仅为 1。
在 RICE 中，我们只使用独立用户数。
误区二：忽略时间范围的一致性
永远不要说“这个功能将覆盖1000用户”。你必须说“预计每月覆盖1000用户”。时间范围不统一会导致 RICE 分数完全不可比。建议企业级产品统一采用“月活用户”作为 Reach 时间基准。
永远不要说“这个功能将覆盖1000用户”。你必须说“预计每月覆盖1000用户”。时间范围不统一会导致 RICE 分数完全不可比。建议企业级产品统一采用“月活用户”作为 Reach 时间基准。
企业级最佳实践：建立 Reach 字典
在交付物模板中，为每个功能预留 “数据尾注” 字段。记录当前 MAU、渗透率计算公式、以及数据置信度（高/中/低）。这不仅能避免扯皮，还能在功能上线后快速复盘校准。
在交付物模板中，为每个功能预留 “数据尾注” 字段。记录当前 MAU、渗透率计算公式、以及数据置信度（高/中/低）。这不仅能避免扯皮，还能在功能上线后快速复盘校准。