第4章 · Reach量化定义:区分日活、周活、月活用户触达口径,以及事件触发次数的统计方式
用户场景
角色:资深产品经理 小陈 · 负责一款 B 端协同工具的内容模版模块
场景:小陈需要评估“一键插入图表模版”功能对用户增长的贡献。她打开 RICE 评分表,在 Reach 列填入“预估覆盖 2 万用户”——但数据团队提供的周报显示该功能日均触发仅 4300 次,而运营同学说“上周有 1.8 万人用过”。矛盾的口径让小陈无法确定真实的触达规模。
痛点:日活、周活、月活各团队随口引用,事件触发次数按“点击”还是“成功插入”统计也未对齐,导致 Reach 评分成了“拍脑袋”数字。
业务问题
Reach 在 RICE 模型中代表“单位时间内有多少用户被功能触达”,但团队中普遍存在三种口径混淆:
| 口径 | 常见误用 | 对 RICE 的影响 |
|---|---|---|
| 日活 (DAU) | 把“日活用户数”直接当作 Reach | 严重高估短期功能覆盖,忽略低频用户 |
| 周活 (WAU) | 用“周活跃用户”替代事件触发人数 | 口径过粗,无法区分功能级 vs 产品级活跃 |
| 月活 (MAU) | 拿“月活跃用户”做功能决策 | 周期过长,掩盖功能冷启动阶段的真实触达 |
| 事件触发次数 | 把“PV/点击”等同于“触达用户数” | 同一用户多次触发被重复计算,Reach 虚高 |
核心矛盾:Reach 要求的是“独立用户数”而非“操作次数”。若口径不统一,同一功能在不同团队的 RICE 评分中可能差 3~5 倍,优先级排序完全失效。
用户访谈 · 三组对话摘录
- 数据工程师 · 老李:“埋点事件表里 event_name=‘chart_insert_click’ 每天有 6000 行,但 user_id 去重后只有 2100。你们要说清是要‘去重用户’还是‘总次数’,不然我两个都算。”
→ 启示:事件触发次数必须明确 count(distinct user_id) 还是 count(*)。 - 运营经理 · 小蔡:“上周活动页有 1.2 万人访问,但其中 8000 人是老用户回访,真正新触达只有 4000 人。我觉得 Reach 应该只算‘首次触达’。”
→ 启示:触达口径需要定义 “首次触达” vs “周期内活跃” 两种模式。 - 产品总监 · 大刘:“我只看 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 量化四步法,确保产品、数据、运营三方对齐:
- 确定时间窗口:根据功能节奏选择 D/W/M 基线。
- 确定事件标识:指定唯一的埋点事件名(如
feature_x_complete)。 - 去重规则:按
user_id去重,同一个用户多次触发只计 1 次。 - 事件触发次数统计:去重用户数 = Reach,总触发次数 = 负载指标,两者同时记录。
埋点执行规范:每个功能埋点必须同时输出 user_id、event_name、event_time、session_id,便于后续做 DAU/WAU/MAU 任意口径回算。
指标验证 · 埋点校验三步骤
通过以下验证确保口径落地无误:
- 一致性校验:同时执行 DAU/WAU/MAU 三种 SQL 查询,确认
WAU ≤ MAU且DAU ≤ WAU的层级关系成立。 - 重复率检查:计算
EVT / WAU比值,若该值 > 5 说明单用户触发过于频繁,需确认是否计入正确事件。 - 抽样回测:抽取 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 | 查数据表 schema | 4 字段均存在且非空 |
| 2 | DAU/WAU/MAU 三口径可基于同一事件回算且层级成立 | SQL 断言测试 | DAU ≤ WAU ≤ MAU |
| 3 | 事件触发次数 (EVT) 与去重用户数分开存储 | 查看指标看板 | 两个指标独立展示 |
| 4 | RICE 评分卡中 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 填写步骤”中,强制用户先定义口径再填数字,从流程上杜绝口径混乱。