第2章：Reach维度定义

适用场景

Reach（触达）维度用于评估一项功能、活动或内容在目标用户中的覆盖广度。在以下典型场景中必须明确定义 Reach：

• 功能上线效果评估：衡量新功能或改版页面在目标用户中的曝光比例。
• 渠道投放效率对比：比较不同推广渠道（推送、短信、广告位）的实际触达用户数。
• 影响范围估算：在 RICE 优先级排序中，用 Reach 量化“该方案可能影响的用户规模”，为后续 Impact 和 Effort 提供基数。
• 日常健康度监控：持续追踪核心路径的触达率，发现用户流失断层。

前置条件

在定义 Reach 维度之前，团队必须已完成以下准备工作：

• 目标用户群已明确：定义清晰的目标受众画像（如“注册 7 天内未付费的用户”），避免模糊泛化。
• 数据采集能力就绪：客户端埋点、服务端日志或第三方 SDK 至少有一条可用数据通路。
• 口径标准已对齐：产品、数据、开发三方对“用户数”“会话数”“曝光量”的基础定义达成一致，避免后续争议。
• 标识体系可打通：设备 ID、登录账号、Cookie 等标识符能关联到同一真实用户，支持跨端去重。

操作步骤

定义 Reach 维度需按以下 4 个步骤依次执行：

1. 确定衡量单位：根据业务目标选择“用户数（UV）”“会话数（PV）”或“曝光量（Impression）”。评估受众规模用 UV，评估互动频率用 PV，评估展示效率用 Impression。
2. 选择数据来源：从客户端埋点、服务端日志或第三方平台中选择与衡量单位匹配的数据源。同一场景下优先使用唯一权威来源，避免多源混用导致口径漂移。
3. 设定去重规则：明确“同一个用户跨设备/跨时段/跨页面是否重复计数”。例如：UV 按设备 ID+登录账号联合去重，PV 按会话 Session 划分，Impression 按展示事件逐条累计。
4. 计算并输出 Reach：根据口径规则聚合数据，输出“触达用户数”或“触达次数”，并计算目标群体中的触达覆盖率（Reach ÷ 总目标用户数）。

输入输出物

责任边界

记录材料

每次 Reach 口径定义完成后，必须归档以下材料：

• 口径说明文档：写明本章适用的衡量单位、数据来源、去重规则、计算时间窗口。
• 数据字典：列出所用事件名、字段名、枚举值及其业务含义。
• 去重逻辑伪代码或规则描述：用自然语言写清楚“在什么条件下两条记录算同一个用户”。

Reach 维度定义检查清单：

• ☐ 衡量单位已明确（UV / PV / Impression）并写入文档
• ☐ 数据来源唯一且可回溯
• ☐ 去重规则已定义并经过数据验证
• ☐ 目标用户群规模已知
• ☐ 口径文档已归档至共享知识库

异常处理

• 数据缺失：部分渠道（如低版本客户端）未上报数据，需在报告中标注“仅统计 v3.2 以上版本”，并评估未覆盖占比。
• 重复计数：同一用户跨设备访问导致 UV 虚高。处理方式：建立设备图谱或优先使用登录账号去重；若无法打通，需在口径中注明“按设备 ID 去重”。
• 口径不一致：不同团队对“用户数”定义不同（如“启动用户”vs“注册用户”）。处理方式：统一使用口径文档中的定义，冲突时以产品经理签字确认为准。
• 数据延迟：第三方平台数据 T+1 到达。处理方式：离线计算时标明数据截止时间，实时场景需切换至自研埋点。

验收标准

Reach 维度定义是否合格，需同时满足以下 4 条：

• 数据可回溯：支持按天、周、月粒度回算 Reach 值，且与原始事件表可逐条对应。
• 口径一致性：不同团队（产品、运营、数据）使用同一口径文档查到的 Reach 值偏差 < 1%。
• 误差可控：自研埋点数据与第三方校验平台（如友盟、GrowingIO）的 Reach 差异 ≤ 5%，且差异原因可解释。
• 文档完备性：口径说明、数据字典、去重规则三份材料齐全，且经过至少一次跨团队评审。