第2章 Reach（触达）维度定义

适用场景

• 新增功能或改版：需要预估功能上线后有多少用户会看到或使用（如首页改版、新入口）。
• 活动/推广策略：评估活动曝光量、活跃用户参与率（如限时促销、推送弹窗）。
• 跨功能优先级排序：在多个候选需求中，单纯用影响人数比较（如 100 万 vs 1 万用户），决定是否优先做高触达需求。
• 产品增长实验：通过 A/B 测试对比两组触达率，验证优化效果。

前置条件

1. 用户定义清晰：明确“活跃用户”标准（如过去30天登录≥3次、有下单行为等），并确认是否包含新用户、匿名访客。
2. 数据源可用：能够从埋点日志、数据库、BI 系统获取用户行为数据。
3. 时间窗口固定：确定计算周期（日/周/月），避免因统计口径不同导致数值不可比。
4. 工具/ETL 就绪：具备对用户去重、过滤异常流量（爬虫、测试账号）的能力。

操作步骤

1. 界定触达范围：明确“谁”被触达。例如：
   • 全体注册用户（活跃+非活跃）
   • 月活跃用户（MAU）
   • 日活跃用户（DAU）
   • 特定行为用户（如“点击过商品详情页”）
2. 选择量化方式：
   • 独立用户数（Unique Users）：更适合衡量功能影响的人群广度。
   • 曝光量（Impressions）：次数累计，适合衡量内容或广告的可见性（如推送文案展示次数）。
   • 组合使用：例如“每用户日均曝光次数”用于评估疲劳度。
3. 确认数据来源：
   • 数据库：用户表、订单表、日志表。
   • 埋点系统：前端/客户端事件日志（如点击、页面浏览）。
   • 第三方工具：广告平台（Google Ads）、推送服务（Firebase）。
4. 计算 Reach 值：

   例：月活跃触达用户 = COUNT(DISTINCT user_id) 
   WHERE event_time BETWEEN '2025-03-01' AND '2025-03-31' 
   AND (login_status = 1 OR purchase_count > 0)

5. 记录并检验：将结果写入《需求评估表》，并与上一周期数据对比，确认无异常波动。

输入输出物

责任边界

• 产品经理：负责定义“触达用户”业务含义（如“已完成身份认证的用户”），确定量化粒度（独立用户或曝光），并在需求文档中输出 Reach 预期值。
• 数据分析师：保障数据源准确、SQL 正确、异常值处理（如剔除真实爬虫），并交付校验后的 Reach 数。
• 开发工程师：确保埋点正确上报（事件名称、参数、采样率），并提供数据拉取接口。
• QA/测试：验证埋点覆盖所有触达场景，确认数据统计口径与文档一致。

记录材料

• 《RICE 评估表》：固定列包括“需求名称”“Reach 定义（独立用户/曝光）”“统计周期”“数值”“数据来源”“责任方”。
• SQL 脚本归档：每个需求对应的查询语句（带注释）保存至代码仓库，用于回溯复现。
• 数据校验日志：记录异常值过滤规则（如排除 user_id<100000 的测试账号）及最终校验人签名。

异常处理

• 数据源缺失或延迟：若埋点漏报，改用备用数据（如支付流水表推算最低活跃用户数），并在记录中标注“保守估算”。
• 用户定义模糊：与业务方、数据团队开会统一口径，会议结论写入文档。
• 活跃标准变化（如改版后登录入口变化）：新旧标准下同时计算 Reach，并对比差异，给出推荐值。
• 重大异常波动（突然翻倍或减半）：优先排查是否新增了用户群、外部流量导入、系统故障，必要时回退到上一个稳定周期。

验收标准

1. 可复现性：同一 SQL 针对同一时间段运行，结果偏差＜1%（因浮动采样率除外）。
2. 定义明确性：任何第三方阅读《RICE 评估表》中的 Reach 列，都能理解其计算逻辑。
3. 数据一致性：与公司官方周报/月报中的“活跃用户数”或“PV/UV”趋势吻合，无逻辑矛盾。
4. 异常透明：所有排除规则（如过滤机器人 IP）均被记录在数据校验日志中。