第2章 Reach（触达）定义：用户度量、时间范围、数据来源
适用场景
- 需要基于用户实际触达量化来划定 MVP 功能范围时。
- 产品或运营团队尚未统一“触达”统计口径，需建立标准定义。
- 使用 RICE 优先级排序前，必须先确定 Reach 的度量单位、观察窗口和可靠数据源。
前置条件
- 已明确目标用户群体（如注册用户、活跃设备、匿名访客）。
- 产品已部署基础埋点或分析工具（如 GA、自建日志、Firebase）。
- 团队就“一次触达”的判定标准达成初步共识（例如：完成一次关键事件算一次触达）。
操作步骤
- 定义用户度量单位：选择唯一标识（User ID、Device ID、Cookie）并确定去重规则。
- 设定时间范围：根据 MVP 验证周期选择窗口（通常为 7 天/30 天）。
- 确定数据来源：明确从哪个系统提取原始数据（后端事件表、前端埋点、第三方平台 API）。
- 编写度量查询：使用 SQL 或分析工具按度量单位和时间窗口聚合触达次数。
- 验证结果合理性：抽样比对原始日志，确保去重逻辑和事件定义无误。
输入输出物
| 输入物 | 输出物 |
|---|---|
| 用户行为事件定义文档 | Reach 度量标准（含度量单位、时间范围） |
| 持有多天的原始日志或分析平台数据 | Reach 数值（去重用户数或会话数） |
| 数据源权限及连接配置 | 数据溯源清单（含字段映射、提取脚本） |
责任边界
- 产品经理：定义度量单位、时间窗口，提出数据需求并验收结果。
- 数据分析师 / 后端工程师：从指定数据源提取数据、编写查询脚本、确保去重准确。
- QA 测试：通过手动埋点验证数据一致性，发现异常时反馈修订。
记录材料
- Reach 度量规则卡片（度量单位 / 窗口 / 数据源字段）
- SQL 或配置脚本快照（如有多轮迭代需保留版本）
- 数据抽样验证报告（记录对比结果与误差）
异常处理
常见异常及处理
- 数据源缺失或延迟：切换到备用数据源（如从实时流切到离线数仓），并在 Reach 注释中标记时间戳。
- 去重后触达数异常波动：检查是否有重复事件（如页面刷新多次），需增加事件去重键（event_id）。
- 度量单位变更：若从 User ID 改为 Device ID，需重新回算历史数据，避免口径不一致。
验收标准
- Reach 数值在连续两天内误差不超过 5%（排除真实波动）。
- 任意抽样 100 条原始日志人工标注触达状态，与自动化结果一致率 ≥ 98%。
- 时间范围、度量单位、数据源名称已在项目文档中明确记录并达成交叉评审。
实践提示：在首次定义 Reach 时，建议先使用 7 天窗口和 User ID 作为度量单位，待数据稳定后再扩展至其他维度（如跨设备去重）。务必保存一份数据源的字段映射快照，方便后续回溯。