第4章 估算Reach的常用方法：历史数据、市场报告、AB测试基线

用户场景与业务问题

产品经理小张正在为新版“智能推荐”功能编写PRD。在填写RICE评分中的Reach字段时，他陷入了困境：产品还未上线、没有直接数据可用，老板又要求在周五前完成优先级排序。如果估算过高，团队会投入过多资源到一个小众功能；估算过低，高价值需求可能被推迟到下一季度。

Reach估算的本质是在信息不完全的条件下做最合理的推测。本章将围绕三种主流估算方法——历史数据法、市场报告法和AB测试基线法，帮助你在不同数据成熟度阶段选择对应的估算路径。

需求拆解：三种估算方法的决策框架

在实际PRD撰写中，选择哪种方法取决于三个维度：数据可得性、产品成熟度和时间成本。以下对比表帮助你快速定位当前场景适用的方法。

方案表达：三种方法的详细操作步骤

1. 历史数据法

核心逻辑： Reach = 当前活跃用户基数 × 类似功能的渗透率 × 目标用户占比修正系数。

操作步骤：

1. 从数据平台提取近30天DAU（日活跃用户）或MAU（月活跃用户）。
2. 查找已有类似功能的渗透率（功能使用人数 / 总活跃用户）。
3. 根据新功能的用户门槛（如需要特定权限、设备或会员等级），乘以修正系数（0.1~1.0）。
4. 计算 Reach = DAU × 渗透率 × 修正系数，并给出上下浮动20%的置信区间。

数据查询示例（内部数据平台 SQL）：

-- 查询最近30天DAU，并按会员等级计算渗透率基线
WITH dau_base AS (
    SELECT COUNT(DISTINCT user_id) AS dau
    FROM user_events
    WHERE event_date BETWEEN CURRENT_DATE - INTERVAL 30 AND CURRENT_DATE - INTERVAL 1
),
feature_penetration AS (
    SELECT 
        COUNT(DISTINCT ue.user_id) * 1.0 / (SELECT dau FROM dau_base) AS penetration_rate
    FROM user_events ue
    WHERE ue.event_date BETWEEN CURRENT_DATE - INTERVAL 30 AND CURRENT_DATE - INTERVAL 1
        AND ue.feature_name = 'recommendation_v1'
)
SELECT 
    (SELECT dau FROM dau_base) AS dau,
    (SELECT penetration_rate FROM feature_penetration) AS penetration_rate,
    (SELECT dau FROM dau_base) * 
    (SELECT penetration_rate FROM feature_penetration) * 0.8 AS estimated_reach
FROM dual;

2. 市场报告法

核心逻辑： Reach = 目标市场总规模 × 同类产品渗透率 × 可触达比例。

操作步骤：

1. 从权威报告（如QuestMobile、艾瑞咨询、IDC）获取目标市场的用户总量。
2. 查找竞品或同类功能的渗透率数据（通常报告中有“功能使用率”指标）。
3. 评估你的产品可触达比例（渠道覆盖、定价门槛等约束）。
4. 计算 Reach = 市场总量 × 渗透率 × 可触达比例，并标注数据来源与报告日期。

适用条件： 适用于0→1创新功能、新市场进入、缺乏内部数据的战略项目。准确度依赖报告样本与目标用户的匹配度。

3. AB测试基线法

核心逻辑： 通过小流量实验获取真实的用户响应率，再外推到全量用户。Reach = 实验组转化率 × 全量目标用户数。

操作步骤：

1. 在实验平台上创建小流量实验（建议样本量 > 1000用户/组）。
2. 运行实验至少1~2个完整业务周期（如7天），收集点击率/转化率/使用率。
3. 计算实验组与对照组的显著差异（p < 0.05），取实验组转化率作为基线。
4. Reach = 实验组转化率 × 全量目标用户数，并标注90%置信区间。

样本量估算示例（Python）：

import math

def min_sample_size(baseline_rate, mde, alpha=0.05, beta=0.2):
    z_alpha = 1.96   # alpha/2 = 0.025
    z_beta  = 0.84   # beta = 0.2
    p1 = baseline_rate
    p2 = baseline_rate * (1 + mde)
    p_avg = (p1 + p2) / 2
    n = (z_alpha * math.sqrt(2 * p_avg * (1 - p_avg)) +
         z_beta * math.sqrt(p1 * (1 - p1) + p2 * (1 - p2))) ** 2 / (p2 - p1) ** 2
    return math.ceil(n)

# 假设基线点击率8%，最小可检测效果20%
print(min_sample_size(0.08, 0.2))
# 输出：约 2200 用户/组

指标验证：如何衡量Reach估算的准确性

无论采用哪种方法，Reach估算本质上是一个预测值，需要在上线后进行回测验证。建议在PRD中提前定义验证指标和采集周期。

• 回测偏差率： |实际Reach − 估算Reach| / 估算Reach × 100%。偏差率 ≤ 30% 为可接受区间。
• 置信区间覆盖率： 实际值是否落在估算时给出的置信区间内（如±20%）。
• 方法对比差异： 当使用多种方法估算时，各方法结果的最大值与最小值之比不应超过3倍，否则说明某些方法的假设条件需要重新审视。
• 验证时机： 功能上线后第7天、第30天分别采集一次Reach数据，与PRD中的估算值对比，并记录偏差原因（如渠道投放超出预期、功能入口曝光不足等）。

验收标准

在PRD评审中，Reach估算必须满足以下标准才能被认定为“可通过评审”：

1. 数据源可追溯： 明确标注了数据来源（内部SQL查询ID、报告名称与页码、实验ID），评审方可快速复现。
2. 计算逻辑可审计： 给出了完整的计算公式和中间变量取值，不包含无法解释的“经验系数”。
3. 假设条件已文档化： 列出了所有假设（如“渗透率按v1版本取值”“不考虑节假日影响”），并评估了假设不成立时的风险。
4. 置信区间已标注： 估算值不是一个孤立的数字，而是带有上下边界（如“5.2万~7.8万用户”）。
5. 方法选择理由充分： 在PRD中说明了为什么选择该方法而非其他方法（如“因功能为0→1创新，内部无历史数据，故采用市场报告法”）。

交付物模板：PRD中的Reach估算章节

以下模板可直接复制到PRD文档的“RICE评分 → Reach”部分，确保估算过程完整透明。