第3章 Reach（触达）评估标准定义

Reach（触达）是RICE评分模型中衡量功能或改动实际影响用户广度的核心维度。本章定义触达用户数量的计算方式、时间窗口选择规则、数据采集来源以及最终转换为评分的刻度表，确保团队在MVP迭代中统一口径、避免重复计数或遗漏。

适用场景

• 需要对功能上线后实际触达用户进行量化评分的MVP迭代。
• 跨渠道（App、Web、小程序、邮件、Push）用户触达统计口径不一致时。
• 进行RICE优先级排序前，需为每个候选功能项打上触达分数。
• 评估AB实验或灰度发布中的用户覆盖效果。

前置条件

• 已建立统一用户标识体系（User ID / Device ID / Cookie ID 映射表）。
• 各触达渠道（前端埋点、后端日志、第三方归因）数据可按时汇总至数仓或分析工具。
• 定义好“有效触达”的判定标准：如页面加载完成、按钮点击、消息已读、支付成功等，必须在各渠道间保持一致。
• 确定最小统计粒度：全量用户 vs. 特定用户群（如新用户、付费用户）。

操作步骤

1. 确定时间窗口：根据功能迭代节奏选择评估周期（日、周、月或灰度期）。
2. 采集触达事件：从各数据源获取用户与该功能交互的原始事件日志。
3. 去重与合并：按唯一用户标识对同一用户在一个时间窗口内的多次触达进行去重，避免重复计数。
4. 计算触达用户数：统计去重后的用户量，记为 reach_users。
5. 映射评分刻度：将 reach_users 对照下表转换为 1~4 分的 Reach 分数。

输入输出物

[
  { "event": "btn_click", "user_id": "u1001", "ts": "2025-03-10 14:23:01" },
  { "event": "push_open", "user_id": "u1002", "ts": "2025-03-10 15:01:22" }
]

{
  "feature_id": "F23",
  "reach_users": 45600,
  "reach_score": 3,
  "window": "weekly"
}

责任边界

• 数据分析师：负责按定义提取数据、去重计算、输出评分建议。
• 产品经理：确认时间窗口、判定有效性、最终拍板评分，并记录在RICE评分矩阵中。
• 开发团队：确保埋点事件正确上报、用户标识不丢失。
• QA团队：在灰度发布时校验触达统计与埋点日志的一致性。

记录材料

异常处理

• 数据缺失：某渠道当天日志未上报 → 使用前一天同时间段数据替换，并在记录中备注；若连续2天缺失则取周均值。
• 用户标识冲突：同一用户在不同渠道标识不同 → 运行映射表做id打平，无法打平则按低阈值统计（即只计可识别部分）。
• 时间窗口跨灰度期：灰度用户与全量用户窗口不同 → 取灰度期作为主要窗口，全量用户仅作参考，评分时降低一档（说明风险）。
• 异常峰值：因活动流量爆发导致触达数突增 → 取窗口内剔除活动期的自然触达均值，并在评分备注中说明。

验收标准

• 每个功能项输出明确的 Reach 评分（1~4），且与《RICE 评分矩阵》记录一致。
• 同一功能在同一时间窗口、同一用户群下，两次计算差异 <5%（随机抽样10%用户验证）。
• 数据来源可追溯至原始事件日志，且查询时间在5分钟内完成。
• 异常处理记录作为附录纳入迭代复盘文档。

触达评估流程与评分映射