4. Reach 因子详解：定义、度量单位、数据来源、常见口径
4.1 概念定义
Reach（覆盖/触及） 是 RICE 打分模型中第一个乘数因子，用于衡量在特定时间窗口内，因该功能/项目将要触达的独立用户数量。它回答一个核心问题：“这个功能的受益面有多宽？”
严格意义上，Reach 是指 新行为/新价值被独立用户首次感知或使用的机会，而非简单统计 PV（页面浏览量）或 DAU（日活用户）。在 RICE 体系中，Reach 是一个绝对数值（如 1000 人/季），不包含相对比例或百分比。
4.2 度量单位与常见口径
Reach 的度量单位必须是 “独立用户 / 时间窗口”。时间窗口通常与团队的规划周期一致（月、季、半年）。下表列出了最常用的 5 种口径及其适用场景：
| 口径名称 | 度量公式 | 数据来源 | 典型场景 |
|---|---|---|---|
| 活跃用户触达 | MAU × 功能渗透率预估 | 产品分析后台、A/B 测试基线 | 存量功能优化、UI 改版 |
| 事件触发触达 | 日均事件量 × 窗口天数 × 去重系数 | 埋点日志、实时计算管道 | 自动化流程、推送通知类 |
| 目标人群触达 | 画像筛选后的独立用户数 | CRM、数据仓库用户标签表 | 新市场拓展、特定群体功能 |
| 业务规则触达 | 满足条件且去重的订单/账户数 | 交易流水、订单系统 | 风控规则、计费变更 |
| 峰值负载触达 | 监控系统记录的并发峰值用户数 | APM、SLI 指标 | 扩容、限流、性能优化 |
关键校准点： 团队在开始使用 RICE 前，必须用文档固定当前项目所采用的 Reach 口径。同一个项目在不同迭代阶段允许切换口径，但必须在评分表备注中写明切换原因。
4.3 数据来源
- 用户行为分析平台（如 Amplitude、Mixpanel、自建事件中心）：获取日/月活用户数和功能使用率。
- 业务数据库：通过 SQL 按画像条件 COUNT(DISTINCT user_id) 直接计算。
- 运营投放系统：广告触达用户数、push 发送打开数。
- 估算模型：当功能尚未上线时，使用类似功能的历史数据或行业基准估算。
-- 示例：从订单表计算特定人群的 Reach（季）
SELECT COUNT(DISTINCT user_id) AS reach_quarter
FROM orders
WHERE order_type = 'subscription_renew'
AND created_at BETWEEN '2025-01-01' AND '2025-03-31';4.4 流程与结构图解
下图展示了从原始日志到最终 Reach 数值的标准化计算流程，以及五种口径之间的衍生关系：
4.5 类比：超市货架与客流
把功能比作一件新品上架：
- Reach 是 进入该货道区域的独立顾客数（不是进店总人数，也不是拿起商品的次数）。
- 如果货架在角落（功能入口深），Reach 会急剧下降。
- 如果超市在门口放指示牌（引导性文案/弹窗），Reach 会上升。
这个类比帮助团队区分“看到机会”和“实际交互”——前者对应 Reach，后者对应 Engagement 或 Conversion。
4.6 常见误区
误区一：把 PV 当 Reach。 一人刷新 10 次页面 ≠ 10 个 Reach。必须去重到独立用户粒度。RICE 中的 Reach 永远是人，不是次数。
误区二：使用口径前未统一时间窗口。 一个模块用“日 Reach”，另一个用“季度 Reach”，相乘后的 RICE 分数无任何比较意义。建议团队以季度为默认窗口，短期决策可改用月度但必须注明。
误区三：将“所有注册用户”直接当作 Reach。 除非功能确实是全量强制触达（如登录页改版），否则必须根据实际触达漏斗折算。使用“注册用户数”往往会高估 2~5 倍。
4.7 练习题
下面是一个真实场景计算。请先独立思考，再参考解析。
场景： 你负责用户端 App 的“个性化首页推荐”改版。改版后预计能让首页推荐点击率提升 12%。当前 App MAU = 50 万，首页日 PV = 120 万，推荐模块日曝光用户数 = 30 万。请估算本次改版的 Reach（按季度口径）。并说明你选择了哪种口径，为什么。
解析：
- 口径选择：目标人群触达。因为推荐模块不是全量用户都可见（存在冷启动未激活用户），用曝光用户数更接近真实触达。
- 季度天数按 90 天计，但独立用户存在回访，不能直接 30 万 × 90。典型移动 App 月度去重比率约为 1.2~1.5。这里取季去重系数 1.3：
Reach_quarter ≈ 30万 × 90天 ÷ 1.3 ≈ 2077 万（独立用户/季）
团队注意： 如果使用“活跃用户触达”口径 = 50 万 × 3 月 = 150 万，会严重低估，因为推荐模块每天曝光不同人群，实际覆盖远大于 MAU。必须理解不同口径对数值的放大/缩小效应。
4.8 应用边界
- 何时 Reach 是核心因子： 用户规模增长阶段、平台型功能、基础体验类项目（如加载速度优化、登录流程简化）。
- 何时 Reach 应降权： 高净值用户专属功能（如企业版、白名单测试）、交付周期极短的小版本修复。此时可用 Impact 或 Confidence 取代 Reach 的主导地位。
- 边界警告： Reach 不能为 0。如果某个功能的 Reach 估算为 0，说明它可能是一个纯技术债务或仅影响内部工具，此时不应使用 RICE，而应换成成本-收益或风险评估框架。