第4章 · Reach量化定义:区分日活、周活、月活用户触达口径,以及事件触发次数的统计方式

用户场景

角色:资深产品经理 小陈 · 负责一款 B 端协同工具的内容模版模块

场景:小陈需要评估“一键插入图表模版”功能对用户增长的贡献。她打开 RICE 评分表,在 Reach 列填入“预估覆盖 2 万用户”——但数据团队提供的周报显示该功能日均触发仅 4300 次,而运营同学说“上周有 1.8 万人用过”。矛盾的口径让小陈无法确定真实的触达规模。

痛点:日活、周活、月活各团队随口引用,事件触发次数按“点击”还是“成功插入”统计也未对齐,导致 Reach 评分成了“拍脑袋”数字。

业务问题

Reach 在 RICE 模型中代表“单位时间内有多少用户被功能触达”,但团队中普遍存在三种口径混淆:

口径常见误用对 RICE 的影响
日活 (DAU)把“日活用户数”直接当作 Reach严重高估短期功能覆盖,忽略低频用户
周活 (WAU)用“周活跃用户”替代事件触发人数口径过粗,无法区分功能级 vs 产品级活跃
月活 (MAU)拿“月活跃用户”做功能决策周期过长,掩盖功能冷启动阶段的真实触达
事件触发次数把“PV/点击”等同于“触达用户数”同一用户多次触发被重复计算,Reach 虚高

核心矛盾:Reach 要求的是“独立用户数”而非“操作次数”。若口径不统一,同一功能在不同团队的 RICE 评分中可能差 3~5 倍,优先级排序完全失效。

用户访谈 · 三组对话摘录

  1. 数据工程师 · 老李:“埋点事件表里 event_name=‘chart_insert_click’ 每天有 6000 行,但 user_id 去重后只有 2100。你们要说清是要‘去重用户’还是‘总次数’,不然我两个都算。”
    → 启示:事件触发次数必须明确 count(distinct user_id) 还是 count(*)。
  2. 运营经理 · 小蔡:“上周活动页有 1.2 万人访问,但其中 8000 人是老用户回访,真正新触达只有 4000 人。我觉得 Reach 应该只算‘首次触达’。”
    → 启示:触达口径需要定义 “首次触达” vs “周期内活跃” 两种模式。
  3. 产品总监 · 大刘:“我只看 MAU,因为业务汇报要用月活。你们功能 Reach 也按 MAU 折算吧。”
    → 启示:管理者偏好 ≠ 量化准确,需要建立 口径转换桥接表。

需求拆解 · 三个量化层次

基于访谈,我们将 Reach 拆解为三个独立维度,每个维度对应不同的 RICE 决策场景:

维度定义适用场景
DAU-based Reach过去 24h 内触发过目标功能的去重用户数快速验证、A/B 测试、功能上线初期
WAU-based Reach过去 7d 内触发过目标功能的去重用户数功能迭代期、周报复盘、中频功能评估
MAU-based Reach过去 30d 内触发过目标功能的去重用户数季度规划、成熟功能、战略级特性评估
事件触发次数 (EVT)单位时间内功能被触发的总次数(含重复)负载评估、埋点校验、成本估算

决策原则:RICE 的 Reach 评分 必须 使用 WAU-based Reach 作为默认口径,除非功能有明确的时间窗要求(如 24h 限时活动用 DAU,季度战略用 MAU)。

方案表达 · 口径框架与事件统计规则

制定 Reach 量化四步法,确保产品、数据、运营三方对齐:

  1. 确定时间窗口:根据功能节奏选择 D/W/M 基线。
  2. 确定事件标识:指定唯一的埋点事件名(如 feature_x_complete)。
  3. 去重规则:按 user_id 去重,同一个用户多次触发只计 1 次。
  4. 事件触发次数统计:去重用户数 = Reach,总触发次数 = 负载指标,两者同时记录。

埋点执行规范:每个功能埋点必须同时输出 user_id、event_name、event_time、session_id,便于后续做 DAU/WAU/MAU 任意口径回算。

Reach 口径选择与事件统计流程 原始事件埋点数据流 日活口径 (DAU) 24h 窗口 · 去重 user_id 周活口径 (WAU) 7d 窗口 · 去重 user_id 月活口径 (MAU) 30d 窗口 · 去重 user_id 事件触发次数统计 (EVT) count(*) 总次数 · 同一用户可多次计入 Reach 量化评分 (RICE) 默认使用 WAU 口径 · 辅以 EVT 做负载参考 💡 同一埋点数据可同时回算 DAU/WAU/MAU,无需重复埋点 Reach 评分取值 = WAU 口径去重用户数 / 产品总 MAU × 100%

指标验证 · 埋点校验三步骤

通过以下验证确保口径落地无误:

  1. 一致性校验:同时执行 DAU/WAU/MAU 三种 SQL 查询,确认 WAU ≤ MAU 且 DAU ≤ WAU 的层级关系成立。
  2. 重复率检查:计算 EVT / WAU 比值,若该值 > 5 说明单用户触发过于频繁,需确认是否计入正确事件。
  3. 抽样回测:抽取 200 个用户 ID,人工核查其时间窗口内的埋点记录是否与口径计算结果一致。
-- 示例:WAU 口径 SQL(BigQuery 方言)
SELECT
  COUNT(DISTINCT user_id) AS wau_reach
FROM
  `project.dataset.events`
WHERE
  event_name = 'chart_insert_success'
  AND event_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)

验收标准 · 交付 Checklist

#验收项验收方式通过条件
1功能埋点同时输出 user_id、event_name、event_time、session_id查数据表 schema4 字段均存在且非空
2DAU/WAU/MAU 三口径可基于同一事件回算且层级成立SQL 断言测试DAU ≤ WAU ≤ MAU
3事件触发次数 (EVT) 与去重用户数分开存储查看指标看板两个指标独立展示
4RICE 评分卡中 Reach 默认使用 WAU 口径评审评分卡模板字段注释写明“WAU-based”
5埋点重复率 (EVT/WAU) 有监控告警阈值配置检查阈值 > 10 时触发告警

交付物模板 · Reach 口径定义文档

每次进行 RICE 评分前,必须填写以下模板并归档:

## Reach 口径定义卡

功能名称:__________________    版本:____    日期:________

1. 选定口径:□ DAU  □ WAU (默认)  □ MAU
   选择理由:_____________________________________________

2. 关联埋点事件名:________________________________________

3. 去重键:□ user_id  □ device_id  □ 其他(______)

4. 时间窗口:____ 天(若选 DAU 为 1,WAU 为 7,MAU 为 30)

5. 事件触发次数 (EVT) 同期值:______ 次

6. WAU 口径 Reach 值:______ 独立用户
   产品总 MAU:______  →  Reach 占比:______ %

7. 口径确认人(产品/数据/运营):____ / ____ / ____

最佳实践:将此模板嵌入 RICE 评分工具的“Reach 填写步骤”中,强制用户先定义口径再填数字,从流程上杜绝口径混乱。