第2章 Reach维度定义：覆盖用户群、触达频率、量化口径、数据来源
Reach（覆盖）是 RICE 评分公式中的第一权重项，用于量化一个功能特性在给定周期内能够影响多少独立用户。与粗放的曝光量不同，Reach 强调有效触达与去重后的唯一身份覆盖。本章提供拆解 Reach 的四维标准化操作程序，确保定量过程可追溯、可复现。
核心原则： Reach 评分不是拍脑袋的估算，而是基于“用户群 → 频率 → 口径 → 来源”四个维度逐层推导出的可验证数值。任何维度的缺失或模糊都会导致评分偏差。
适用场景
- 对多个待开发功能进行优先级排序时，需要横向比较各自的覆盖用户量级。
- 评估面向不同客群的功能（如内部工具 vs. 外部用户、免费版 vs. 付费版）。
- 在季度/OKR规划周期中，需要量化功能上线后的预期影响范围。
- 对已上线功能进行复盘验真，对比预期 Reach 与实际 Reach。
前置条件
- 已定义产品用户细分： 明确产品的核心用户画像（如 MAU、DAU、周活、新注册用户、企业租户管理员等）。
- 可用的分析工具： 已经接入埋点平台（如 Firebase、Amplitude、神策、自建数仓），能查询到事件级或会话级用户行为数据。
- 功能范围说明书： 清晰描述功能的影响边界——是影响所有用户，还是仅影响特定角色（如仅作者、仅管理员）。
- 基线数据： 如果功能尚未上线，需准备类似功能的历史采用率作为估算参照。
操作步骤
| 步骤 | 动作 | 关键考量 | 产出物 |
|---|---|---|---|
| 1 | 定义覆盖用户群 | 是月活用户（MAU）、周活（WAU）、日活（DAU），还是累计注册用户？不同基线将影响 Reach 量级。 | 目标用户基数（N） |
| 2 | 确定触达频率 | 用户在一个版本周期内会主动/被动触发该功能多少次？单次（如设置页）、低频（每周1次）、高频（每日多次）。 | 频率系数（F） |
| 3 | 建立量化口径 | 以什么实体去重？用户 ID（推荐）、设备 ID、浏览器 cookie、还是公司账户？口径不对会导致计算偏差。 | 去重字段与粒度定义 |
| 4 | 提取数据来源 | 数据来自埋点事件表、业务数据库、第三方面板还是抽样问卷？需注明时间窗口与过滤条件。 | 源数据查询脚本或链接 |
输入输出物
| 类别 | 具体内容 | 格式规范 |
|---|---|---|
| 输入物 | 用户角色清单、基础活跃数据（MAU/DAU）、历史功能采用率、事件定义规范 | CSV / SQL 查询 / 产品文档 |
| 输出物 | 周期内独立覆盖用户数（Reach Score）、覆盖百分比、置信区间（如为估算值） | RICE 评分看板 / Spreadsheet |
责任边界
- 产品经理（PM）： 定义功能影响范围，选定作为基线的用户群，对最终 Reach 评分负直接责任。
- 数据分析师（DA）： 编写并验证数据提取脚本，处理归一化与去重逻辑，标注数据来源与时间窗口。
- 算法/后端工程师： 提供功能标记位（Feature Flag）埋点，确保事件正确上报，协助排查数据异常。
记录材料
在提取数据阶段，建议使用标准模板记录查询逻辑，以便后续审计与复现。以下为从事件表中提取月活跃覆盖基数的 SQL 示例：
SELECT
COUNT(DISTINCT user_id) AS monthly_reach_users
FROM
product_events
WHERE
event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
AND event_name IN ('feature_page_view', 'feature_click')
AND feature_id = 'your_feature_id';
模板化建议： 将以上 SQL 封装为参数化模板，每次评估新功能时只需替换
feature_id 和时间窗口，减少重复劳动。
异常处理
- 数据稀疏（新功能/新市场）： 无历史埋点时，可使用相似功能采用率作为代理指标，或采用最小可行估算（例如乐观覆盖 = 目标基数的 20%）。
- 覆盖数为 0： 事件表为空时，优先检查埋点管道是否阻塞，而非直接判定“无用户”。若确认功能未上线，则 Reach 评分为 0 并标注说明。
- 高估覆盖风险： 跨设备用户（如手机+PC）易被重复计算。必须与口径制定时的去重逻辑（User-ID）保持一致，严禁直接使用 Event-Count 作为 Reach。
- 维度不一致： 当功能影响买家和卖家两侧时，应分别计算后再加总，并在备注中标注重叠部分。加总需减去交集（使用并集逻辑）。
验收标准
- 合理性校验： Reach 评分应在预估目标基数的 ±15% 范围内波动。超出此范围需输出异常说明。
- 可溯源性： 所有 Reach 评分必须附带数据来源链接或查询脚本，评分看板中应支持一键跳转。
- 覆盖率守恒： 当拆解子维度（如平台、用户类型）时，各子 Reach 之和应等于总量（或标记出排重的交集量）。
- 口径一致性： 同一产品套件内的 Reach 评分必须使用相同的去重实体定义，不得出现 A 功能用 User-ID、B 功能用 Device-ID 的混用情况。