第四章:Reach 估算操作步骤
Reach(触达用户数)是 RICE 评分中决定实验影响范围的核心维度。本章将按照 SOP 流程拆解 Reach 的完整估算链路:从目标用户圈定、活跃数据口径选取、周活与月活换算、时段修正到最终分数输出。每一环节均附带输入输出物与异常处理规则,确保估算结果可复现、可审计。
适用场景
- 新产品功能上线前,需要量化实验可触达的用户规模。
- 面向不同分层用户(新用户、活跃用户、付费用户)的 A/B 实验,需要差异化估算 Reach。
- 历史实验回顾或 RICE 评分复审,需统一 Reach 计算口径。
- 跨产品线或跨平台实验对比时,需要标准化的 Reach 产出流程。
前置条件
- 已获取产品全局 DAU / MAU 基础数据(建议使用最近 30 天均值)。
- 已定义实验目标人群的用户属性规则(地域、版本、注册时长、行为标签等)。
- 具备用户分群工具(如 SQL、用户画像平台、CDP)的查询权限。
- 团队内已统一“活跃用户”的业务定义(如:打开 App 并完成一次核心事件)。
操作步骤
- 圈定目标用户池:根据实验需求定义过滤条件,从全量用户中圈定可能触达的用户集合。
- 确定 DAU / MAU 取值口径:选择“设备去重”或“账号去重”口径,并固定统计窗口。
- 周活 / 月活换算:当实验周期按周计而基础数据按月计,使用周活占比系数换算。
- 时段影响修正:识别节假日、大促、版本升级窗口等异常时段,按修正系数调整。
- 输出 Reach 分数:将修正后的预估用户数按 RICE 标准映射为 1-5 分档位。
关键原则:整个过程需记录每一步的筛选条件与系数取值,任何主观判断均需双人复核。
输入输出物
| 类别 | 物项 | 说明 |
|---|---|---|
| 输入 | 全量用户画像表 | 包含用户 ID、注册时间、最后活跃时间、版本、地域等属性 |
| 输入 | 近 30 天 DAU / MAU 均值 | 按设备去重后的日/月活跃数据 |
| 输入 | 实验设计文档 | 明确目标人群规则与实验周期 |
| 输出 | Reach 估算日志 | 含每一步筛选条件、系数、中间值与最终分数 |
| 输出 | Reach 分数 | 1-5 分的整数值,附保留小数位的原始预估量 |
责任边界
- 数据工程师:提供准确的 DAU / MAU 基础数据,确保统计口径一致。
- 产品经理 / 实验负责人:定义人数圈定规则与时段修正系数,对分数的业务合理性负责。
- 数据分析师:执行 SQL 圈选并记录中间值,输出 Reach 估算日志。
- 复审人(团队 TL):抽查系数取值与分档映射,确认无逻辑错误或口径漂移。
记录材料
| 材料名称 | 格式 | 保存位置 | 保留周期 |
|---|---|---|---|
| Reach 估算日志 | Google Sheets / Airtable | 项目共享盘 / 实验目录 | 实验结束 + 6 个月 |
| SQL 查询脚本 | .sql 文件 | 代码仓库 / 实验记录子目录 | 实验结束 + 12 个月 |
| 系数决策记录 | Wiki 页面 / 文档 | 团队知识库 | 长期 |
异常处理
| 异常场景 | 处理方式 |
|---|---|
| 目标人群过小(< 1000 用户) | 扩大人群圈定条件或延长实验周期,否则标记为“低触达”并直接给 Reach 分数 1 |
| MAU 数据缺失 | 使用近 7 天 DAU 均值 × 30 作为 MAU 估算,并在日志中注明“估算模式” |
| 时段修正系数无法判断 | 默认取 1.0(不修正),由复审人确认并签字 |
| 用户属性标签与业务定义冲突 | 以实验设计文档中的定义为最终标准,记录冲突原因 |
注意:异常处理路径必须在 Reach 估算日志中显式标注,不可静默替换。任何“估算模式”下的输出均需人工二次确认。
验收标准
- Reach 估算日志完整记录 5 个步骤的中间值,且每一步均有操作人签名或系统时间戳。
- 输出分数与原始预估量对应关系符合 RICE 分档表(见下方表格)。
- 同一实验由不同分析师独立估算,Reach 分数差异 ≤ 1 分(若超过需复勘)。
- 所有异常场景的处理路径均有文档记录且经过复审人确认。
| 预估触达用户数 | Reach 分数 | 说明 |
|---|---|---|
| 0 – 1,000 | 1 | 极低触达 |
| 1,001 – 10,000 | 2 | 低触达 |
| 10,001 – 100,000 | 3 | 中等触达 |
| 100,001 – 1,000,000 | 4 | 高触达 |
| > 1,000,000 | 5 | 极高触达 |
Reach 估算流程总图
步骤一:圈定目标用户池
根据实验设计文档中的用户属性条件(版本号 ≥ V6.2、注册时间 ≥ 30 天、地域为国内),使用 SQL 或分群工具筛选出基础人群。若条件超过 3 个,建议创建临时用户标签表以提高复用性。
-- 示例:圈定目标用户池
SELECT DISTINCT user_id
FROM user_profile
WHERE app_version >= '6.2'
AND datediff(day, reg_date, getdate()) >= 30
AND region IN ('CN', 'HK', 'TW');
步骤二:确定 DAU / MAU 取值口径
决策是否需要跨设备去重。如果实验以“账号”为单元,使用账号去重口径;若以“设备”为单元,使用设备去重口径。统一从数据仓库获取最近 30 个自然日的 DAU 均值与当月 MAU。
| 口径类型 | 适用场景 | 统计复杂度 |
|---|---|---|
| 设备去重 | 安装量、曝光量实验 | 低 |
| 账号去重 | 登录态功能、付费实验 | 中 |
| 用户主体去重 | 跨设备同一用户识别 | 高(需 ID-Mapping) |
步骤三:周活 / 月活换算
当实验周期 ≤ 7 天但基础数据为 MAU 时,使用周活占比系数 α = WAU / MAU(取最近 4 周均值)。预估实验触达数 = MAU × α ×(实验天数 / 7)。
-- 计算周活占比系数 α
WITH weekly_active AS (
SELECT COUNT(DISTINCT user_id) AS wau
FROM event_log
WHERE event_date >= dateadd(day, -7, getdate())
),
monthly_active AS (
SELECT COUNT(DISTINCT user_id) AS mau
FROM event_log
WHERE event_date >= dateadd(day, -30, getdate())
)
SELECT ROUND(1.0 * wau / mau, 4) AS alpha
FROM weekly_active, monthly_active;
步骤四:时段影响修正
识别估算周期内是否包含以下异常时段:春节、双十一、暑期高峰、版本强制升级周。按历史同期活跃度波动比给出修正系数 β(0.8 – 1.5),并在日志中注明依据。
经验参考:若无明确历史数据,β 取 1.0 且不修正;若遇大型版本升级,建议 β = 1.2 – 1.3。
步骤五:输出 Reach 分数
最终预估触达数 = 目标用户基数 ×(实验天数占比)× β。对照 RICE 分档表映射为 1-5 分,同时保留原始数值(保留两位小数)存入 Reach 估算日志。
-- 输出 Reach 分数示例(Python 伪代码)
reach_estimate = target_users * day_ratio * beta
if reach_estimate <= 1000:
score = 1
elif reach_estimate <= 10000:
score = 2
elif reach_estimate <= 100000:
score = 3
elif reach_estimate <= 1000000:
score = 4
else:
score = 5
# 记录日志:log_reach(target_users, day_ratio, beta, reach_estimate, score)
复核机制:每一步的中间值与系数需由另一名团队成员独立验算,差异超过 5% 时回到步骤一重新排查条件逻辑。