第四章:Reach 估算操作步骤

Reach(触达用户数)是 RICE 评分中决定实验影响范围的核心维度。本章将按照 SOP 流程拆解 Reach 的完整估算链路:从目标用户圈定、活跃数据口径选取、周活与月活换算、时段修正到最终分数输出。每一环节均附带输入输出物与异常处理规则,确保估算结果可复现、可审计。

适用场景

  • 新产品功能上线前,需要量化实验可触达的用户规模。
  • 面向不同分层用户(新用户、活跃用户、付费用户)的 A/B 实验,需要差异化估算 Reach。
  • 历史实验回顾或 RICE 评分复审,需统一 Reach 计算口径。
  • 跨产品线或跨平台实验对比时,需要标准化的 Reach 产出流程。

前置条件

  • 已获取产品全局 DAU / MAU 基础数据(建议使用最近 30 天均值)。
  • 已定义实验目标人群的用户属性规则(地域、版本、注册时长、行为标签等)。
  • 具备用户分群工具(如 SQL、用户画像平台、CDP)的查询权限。
  • 团队内已统一“活跃用户”的业务定义(如:打开 App 并完成一次核心事件)。

操作步骤

  1. 圈定目标用户池:根据实验需求定义过滤条件,从全量用户中圈定可能触达的用户集合。
  2. 确定 DAU / MAU 取值口径:选择“设备去重”或“账号去重”口径,并固定统计窗口。
  3. 周活 / 月活换算:当实验周期按周计而基础数据按月计,使用周活占比系数换算。
  4. 时段影响修正:识别节假日、大促、版本升级窗口等异常时段,按修正系数调整。
  5. 输出 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 估算流程总图

Reach 估算操作步骤流程 Reach 估算五步流程 ① 圈定目标用户池 过滤条件 + 用户属性 ② DAU / MAU 取值口径 设备去重 / 账号去重 ③ 周活 / 月活换算 周活占比系数 ④ 时段影响修正 节假日 / 大促修正系数 ⑤ 输出 Reach 分数 1-5 分档位映射 说明: 步骤②中若使用“设备去重”口径,需在日志中标注 DAU/MAU 来源;步骤④的修正系数建议取最近 3 年同期均值的波动比。

步骤一:圈定目标用户池

根据实验设计文档中的用户属性条件(版本号 ≥ 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% 时回到步骤一重新排查条件逻辑。