Reach 维度定义与度量方法：触达用户数定义、统计口径、不同产品形态的估算方法
适用场景
- 需要量化某功能或需求在特定周期内可能覆盖的用户规模
- RICE 模型中 Impact 和 Confidence 已经初步判断，需用 Reach 补充市场规模权重
- 对比不同产品形态（C 端 App、B 端 SaaS、线下服务）的潜在影响力
- 资源有限，优先选择覆盖面更广的需求进入 MVP
前置条件
- 明确当前产品形态与核心用户触点（网页、移动端、API、线下设备）
- 确认可获取的用户行为数据源（埋点、业务系统、第三方行业报告）
- 团队对齐“触达”的判定标准：主动使用 vs 被动曝光 vs 注册登录
- 历史或行业基准数据（如 DAU、MAU、活跃账号数）可作为估算锚点
操作步骤
| 步骤 | 动作 | 关键要点 |
|---|---|---|
| 1 | 定义触达用户数 | 指在评估周期内至少一次通过功能触点产生有效交互的独立用户数 |
| 2 | 选择统计口径 | 日活 (DAU) / 周活 (WAU) / 月活 (MAU) 按功能迭代周期匹配 |
| 3 | 确认数据来源 | 优先使用埋点系统（如神策、GA）、若缺失则采用平台公开数据 + 调研估算 |
| 4 | 按产品形态估算 | C 端：DAU * 功能渗透率；B 端：付费账号数 * 预估使用率；线下：客流量 * 转化率 |
| 5 | 验证与标记置信度 | 数据来自实际埋点记为 High，行业基准记为 Medium，纯估算记为 Low |
| 6 | 输出 Reach 数值 | 保留整数，并附带口径说明和置信度等级 |
输入输出物
- 输入：产品形态定义文档、历史用户数据表（或行业基准）、功能预期渗透率假设
- 输出：Reach 估算记录（包含数值、口径、数据来源、置信度）、触达用户数分布图（按平台/用户群）
责任边界
- 产品经理：定义触达判定标准和统计口径，协调数据团队获取数据
- 数据分析师：执行数据提取、清洗、计算，提供置信度评估
- 业务负责人：审核估算结果是否合理，确认竞品对标数据
记录材料
| 字段 | 说明 | 示例 |
|---|---|---|
| 产品形态 | B2C App / B2B SaaS / 线下终端 | B2C 移动 App |
| 统计口径 | DAU / WAU / MAU | MAU |
| 触达用户数 | 整数，单位：人/账号 | 125,000 |
| 数据来源 | 埋点 / 平台后台 / 行业报告 / 估算 | 埋点 + 行业报告交叉验证 |
| 置信度 | High / Medium / Low | High |
| 估算公式 | 说明计算过程 | MAU × 功能渗透率 40% |
异常处理
- 数据缺失：使用替代指标（如注册用户数 × 留存率），并在置信度中标记 Low
- 新功能无历史数据：参考同类功能上线初期的渗透率曲线，取保守值
- 多平台合并：按平台分别估算后去重（如 web 与 App 重叠用户需扣减）
- 口径争议：由产品委员会裁决，并以会议纪要作为记录材料
验收标准
- Reach 数值有明确的统计口径定义，团队内可复现
- 不同产品形态使用对应的估算方法，并在记录材料中注明公式
- 置信度低于 Medium 时，需在最终 RICE 评分中附加风险说明
- 所有估算过程经过至少一次同级评审才能进入下一阶段
Reach 估算流程（内联 SVG）
实践技巧： 触达用户数应保守估计。优先使用实际埋点数据，对渗透率假设按历史数据的低百分位取值。若同时进行多个功能的 Reach 评估，建议统一基表数据月份，避免因活跃周期差异造成对比失真。
最佳实践案例： 某 B2C 音乐 App 评估“歌单分享”功能 Reach：MAU=5.2M，同类分享功能渗透率约35%，去重后触达用户=1.82M，置信度 High。该数据直接作为 RICE 评分中 Reach=180 万代入计算。
常见错误： 把曝光量（Impression）直接当作触达用户数，忽略去重。例如广告曝光1000万次，实际独立用户仅200万，差距5倍。务必按独立用户（Unique Users）定义 Reach。