第3章：Reach（触达）计算方法
3.1 适用场景
本章适用于需要定量评估功能触达能力的产品决策场景，包括但不限于：
- 评估新功能上线后的实际曝光人数
- 比较不同渠道/模块的触达效率
- 为RICE评分中的Reach维度提供数据基础
- 识别触达覆盖率不足的信号，指导推广策略调整
3.2 前置条件
| 项目 | 要求 | 检查点 |
|---|---|---|
| 数据源 | 已接入埋点系统或业务日志，可统计独立用户标识 | UV（Unique Visitor）统计口径已对齐 |
| 时间窗口 | 明确评估周期（如7天、30天、单次活动期） | 起止时间戳已定义 |
| 用户去重规则 | 按设备ID/用户ID/手机号等唯一标识去重 | 去重字段无空值、无异常重复 |
| 触达定义 | 明确“触达”的行为阈值（如进入页面、看到关键元素、点击等） | 产品文档中已描述触发条件 |
常见陷阱：误将“曝光次数”（PV）当作触达人数（UV），导致数值虚高。必须使用去重后的独立用户数。
3.3 操作步骤
- 确定触达事件 – 选择能代表“用户已看到/体验到”的关键行为，例如：
page_view、feature_impression、modal_open。 - 提取原始日志 – 从埋点数据仓库中获取指定时间范围内触达事件的所有记录。
- 去重统计 – 按用户唯一标识对记录进行去重，得到独立触达用户列表。
- 计算触达人数 – 去重后的用户计数即为Reach值。
- 记录上下文 – 保存事件定义、时间窗口、去重口径，便于后续核验或复用。
3.4 输入输出物
| 类型 | 名称 | 格式说明 |
|---|---|---|
| 输入1 | 触达事件日志 | CSV/JSON/Parquet，包含字段：user_id, event_name, timestamp |
| 输入2 | 触达事件定义文档 | 描述触发条件、归属产品模块、版本号 |
| 输出1 | Reach数值 | 整数，表示独立触达用户数（示例：153,420） |
| 输出2 | 去重用户清单（可选） | 仅留存脱敏ID，用于异常复核 |
3.5 责任边界
- 产品经理：定义触达事件、确认去重口径、校准业务含义。
- 数据分析师/数据开发：执行SQL/Python查询、保证数据准确性、处理异常数据。
- QA/验收人：核对Reach值与埋点验证结果的一致性。
建议：产品经理应提供至少一个“可人工验证的小样本”，例如指定10个测试用户，确认这10人是否全部出现在去重结果中，以验证数据链路无误。
3.6 记录材料
| 材料名称 | 内容要求 | 保存位置 |
|---|---|---|
| Reach计算文档 | 事件定义、SQL脚本、时间窗口、去重字段、结果数值 | 部门知识库 / 产品需求文档附表 |
| 异常处理日志 | 时间、问题描述、根因、处理方案、最终Reach值 | 项目共享文件夹 |
| 验收签收单 | QA签名、数据比对结果、是否通过 | 项目管理工具 |
3.7 异常处理
| 异常场景 | 原因 | 处理动作 |
|---|---|---|
| 触达人数为0 | 事件未正确触发、埋点延迟、查询条件有误 | 检查埋点是否上线；确认时间窗口内是否有正常流量；在日志中搜索测试用户行为 |
| 触达人数远超预期 | 去重失败（如user_id出现空值被当作不同用户） | 过滤无效ID；核对去重逻辑；重新统计 |
| 多次统计结果不一致 | 时间窗口不固定、事件定义变更 | 固化查询语句和时间参数，使用版本号标记定义 |
| 数据缺失 | 部分渠道未接入埋点、日志丢失 | 补充埋点；记录缺失部分占比，并在报告中注明 |
3.8 验收标准
- Reach 数值与埋点平台离线统计偏差 ≤ 1% 视为通过。
- 去重用户清单中随机抽检至少 20 个用户，确认其在触达事件日志中真实存在。
- 计算脚本及参数已在文档中完整记录，且可复现相同结果。
计算公式示例（SQL）：
SELECT COUNT(DISTINCT user_id) AS reach
FROM fact_event_log
WHERE event_name = 'feature_impression'
AND dt BETWEEN '2025-01-01' AND '2025-01-07';df = pd.read_parquet('events.parquet')
reach = df[df['event_name'] == 'feature_impression']['user_id'].nunique()