第2章 覆盖度（Reach）：定义、度量单位、数据来源
适用场景
- 评估新功能或产品改动对用户触达范围的影响时。
- 营销活动（推送、广告、邮件）投放效果的受众规模预测。
- 跨渠道获客策略的“基础量级”比较，判断哪些渠道能带来更多曝光。
- 优先级排序中需要量化“影响用户数”以计算 RICE 总分时。
前置条件
- 已经明确本次评估的 目标用户群体（例如：全部注册用户、过去30天活跃用户、新注册14天内用户等）。
- 具备可追溯的用户标识体系（user_id / device_id / cookie 等）。
- 拥有至少一项能判定“触达”的数据源（如登录日志、页面浏览埋点、推送送达记录等）。
- 选定统一的 时间窗口（日、周、月、季度），不同候选项目间必须保持一致。
操作步骤
- 定义触达行为——明确什么算“被覆盖”：例如“访问过该页面”、“收到推送并打开”、“参与过活动”等。
- 划定时间窗口——按业务节奏选择窗口长度，通常优先使用“日活跃用户（DAU）”或“月活跃用户（MAU）”。
- 获取唯一用户数——对所选时间窗口内的触达用户进行去重，输出
unique_users数值。 - 转换度量单位——将原始用户数转换为覆盖度（Reach）指标：
Reach = unique_users / 目标用户池总基数 × 100%（可选百分比）。 - 记录数据来源与版本——标注所用数据库表、埋点事件名、提取时间，确保可复现。
输入输出物
| 类型 | 内容 | 示例 |
|---|---|---|
| 输入 | 用户行为日志 / 推送送达日志 / 广告曝光日志 | dwd_web_pageview (事件=‘product_page’, dt=‘2025-03-01’) |
| 输出 | 覆盖度数值 + 度量单位 | Reach = 48,000 (DAU) 或 18.5% (占MAU) |
| 附带物料 | 数据血缘说明、SQL脚本、去重逻辑描述 | “使用 distinct user_id 计算，过滤内部测试账号” |
责任边界
- 产品经理：定义目标用户群体、触达行为标准、时间窗口。
- 数据分析师：提取原始数据、执行去重计算、输出覆盖度数值。
- 技术/数据工程师：确保数据管道稳定，提供可用的事件表。
- 复核人（Lead/Stakeholder）：验证定义的正确性，确认计算口径与业务目标一致。
记录材料
每次评估必须记录：
- 目标用户池定义与基数来源（如“注册用户表 t_user，状态=active”）
- 时间窗口起止日期与长度
- 触达行为判定规则（事件名、条件）
- 原始 SQL 或脚本路径 / Git 提交号
- 覆盖度计算结果（数值+百分比）
- 任何异常或假设（如“排除爬虫用户”）
异常处理
| 异常类型 | 可能原因 | 处理方式 |
|---|---|---|
| 数据缺失 | 埋点丢失、日志延迟 | 扩大时间窗口或使用备份表；标注缺失比例 |
| 用户去重冲突 | 多设备同一用户被计为多人 | 采用 user_id 优先；若无则使用 device_id+登录状态融合 |
| 定义歧义 | “触达”在不同团队标准不同 | 在记录材料中明确事件定义，并由负责人签字确认 |
| 基数变动 | 目标用户池在计算期内变化 | 取时间窗口首日或均值作为分母，并备注选择依据 |
验收标准
- 覆盖度数值可被另一位分析师独立复现（误差不超过 2%）。
- 度量单位（DAU/MAU/WAU）与项目评估周期匹配，且所有候选项目使用同一单位。
- 数据来源、去重逻辑、时间窗口均有书面记录，且通过至少一人复核。
- 当 Reach 应用于 RICE 总分计算时，对应的数值与原始日志 sample 验证结果一致。