第2章 Reach（触达）拆解：触达指标定义、数据来源、量化方法、案例分析
Reach（触达）是RICE优先级模型中“客观量化”的起点，它回答一个核心问题：在当前用户场景下，有多少目标用户会受到你的功能或改进的影响？ 本章将从用户访谈与需求拆解出发，系统拆解触达指标的定义、数据来源、量化方法，并通过案例演示如何将指标验证与验收标准对齐。
2.1 触达指标的定义
触达指标并非简单的“用户总数”，而是与具体业务问题强关联的度量。通常用以下维度定义：
| 维度 | 定义示例 | 典型场景 |
|---|---|---|
| DAU / MAU | 日活跃用户 / 月活跃用户 | 全局功能影响评估 |
| 事件触达用户 | 完成特定行为的独立用户数 | 新功能试用、转化漏斗 |
| 目标用户群 | 根据用户画像筛选的细分群体 | AB实验、分层运营 |
| 会话触达 | 进入某个页面/模块的会话次数 | 着陆页、引导流程 |
需求拆解要点： 在用户访谈阶段，不要直接问“有多少人用”，而要问“你现在是怎么完成这个任务的？如果改善了，你觉得每周能用几次？”——由此推导出真实触达场景。
2.2 数据来源
触达指标的数据来源分为三类，每类对应不同的验收标准与交付物模板：
- 用户访谈与调研：样本量小但能揭示行为动机，用于定义“触达用户”的边界。
- 埋点与日志：客户端/服务端埋点，通过事件ID统计独立用户，数据准确但需定义去重逻辑。
- 业务系统存量数据：CRM、订单系统、持仓记录等，适合历史触达趋势分析。
常见的数据取数脚本示例（以DAU查询为例）：
SELECT
DATE(event_time) AS day,
COUNT(DISTINCT user_id) AS dau
FROM user_events
WHERE event_name = 'app_open'
AND event_time >= '2025-01-01'
GROUP BY day
交付物模板提示： 在需求文档的“数据来源”部分，需明确列出数据表名、字段、去重键、采样周期。示例表格如下：
| 数据表名 | 字段 | 去重键 | 更新频率 |
|--------------------|--------------------------|-------------|----------|
| user_events | event_name, user_id, ts | user_id+ts | 实时 |
| dim_user_segment | user_id, segment_name | user_id | 日增 |2.3 量化方法
量化方法决定了指标的可验证性。常用方法包括：
- 直接计数法：对满足条件的独立用户数进行每日/每周累计。
- 预估加权法：当无法直接统计时，通过用户访谈样本比例×总用户池估算。
- 分层外推法：按用户活跃分层（核心、高活、低活），分别统计后相加。
数量级对照表（供方案表达时参考）：
| 触达规模 | 月活量级 | 典型产品阶段 |
|---|---|---|
| 极小 | < 1万 | MVP验证 |
| 小 | 1万～10万 | 早期增长 |
| 中 | 10万～100万 | 规模化 |
| 大 | 100万～1000万 | 成熟产品 |
| 超大 | 1000万+ | 平台级 |
常见误区： 不要将“潜在用户”直接等同于触达指标。例如，功能上线后预计覆盖100万用户，但实际只有10万用户会主动触发该场景。必须通过用户访谈验证真实发生路径。
2.4 案例分析：从用户场景到指标验证
以“在线文档评论功能优化”为例，完整展示Reach拆解流程：
- 用户场景：团队协作时，成员通过评论@提及快速同步进展。
- 业务问题：当前评论提醒延迟高，导致回复率低。
- 用户访谈：发现50%的周活跃用户会发起评论，但仅20%收到即时提醒。
- 需求拆解：将触达指标定义为“每日触发评论提醒的独立用户数”。
- 量化计算：DAU=50万，评论发起率=30%，提醒触发率=80% → 触达用户=50万×30%×80%=12万/日。
- 验收标准：上线后监控埋点，确保日均触达数≥10万，且单用户提醒延迟＜3秒。
- 交付物模板：在PRD中附上触达指标定义表、数据来源SQL、量化计算说明。
下图总结了触达指标从定义到验证的完整链路：
通过以上拆解，触达指标不再是模糊的“用户数”，而是可派生、可验证、可对齐验收标准的核心量化依据。下一环节将进入“Impact（影响）拆解”——继续用同样严谨的结构处理效果度量。