第2章 · RICE要素拆解——Reach:确定影响范围、用户群体覆盖度、量化指标与数据来源

概念通识 · 什么是 Reach?

Reach(触达) 是 RICE 优先级框架中的第一个要素,衡量的是在指定时间窗口内,某个产品改动、功能特性或优化措施将影响到多少独立用户。Reach 不统计重复曝光,只关心“有多少人至少一次受到影响”。

🔍 类比 · 广播 vs 一对一通话
Reach 就像广播电台的覆盖人口——它告诉你信号能传多远、能覆盖多少听众,而不是每个听众听了多少遍。如果只做一对一通话,Reach 很小,即使通话质量再高,影响力也有限。RICE 中 Reach 越大,改动带来的潜在规模效应就越明显。
💡 核心公式思维
Reach 通常表示为:在 X 天 / 周 / 月内,受到影响的独立用户数。数值越大,表示改动的影响面越广,在 RICE 评分中的权重也越高。

误区辨析

常见误区 正确理解
Reach = 页面总访问量(PV) Reach 是 独立用户数,PV 包含重复访问。Reach ≤ PV。
Reach 越大,效果一定越好 Reach 只衡量覆盖范围,不衡量影响深度。高 Reach + 低 Impact 可能不如中等 Reach + 高 Impact。
所有用户群体都用同一 Reach 值 不同群体(新用户 / 活跃用户 / 沉默用户)的 Reach 计算方式不同,需分层量化。
Reach 只看上线后数据 估算阶段应基于历史 + 预估,上线后复盘修正。

适用场景

本章 Reach 拆解方法适用于以下场景——

  • 功能优先级排序:在 RICE 评分中需要对多个需求进行 Reach 量化时。
  • 产品改版评估:判断一个新功能或界面调整会影响多少现有用户。
  • 运营活动规划:估算活动触达的目标用户规模,辅助资源投入决策。
  • 技术架构升级:评估迁移、重构或 API 变更对用户群体的影响范围。

前置条件

在开始 Reach 量化之前,必须确认以下条件已满足:

  1. 明确改动的目标用户群:定义“谁会被影响”(如日活用户、付费用户、特定功能用户)。
  2. 可用的用户数据源:至少有一种数据源能支撑覆盖估算(如数据库、埋点、运营后台)。
  3. 时间窗口已定义:统一使用 X 天 / X 周 / X 月为计算周期。
  4. 渠道/触达路径已梳理:清楚用户通过哪些方式接触到该改动(如首页、推送、分享)。
⚠️ 常见卡点
如果缺少用户去重 ID(如设备 ID、账号 ID),将无法准确计算独立用户数,此时 Reach 只能用范围区间(下限~上限)来估算,并在记录材料中注明“数据置信度:低”。

操作步骤 · 4 步量化 Reach

以下步骤为 Reach 估算的标准流程,每一步都包含输入、执行动作和输出。

  1. 步骤 1:定义受影响的用户群体
    • 动作:列出该改动直接作用的用户分层(如:所有登录用户 / 周活跃≥3 天的用户 / 某实验组用户)。
    • 输出:用户群体定义表(群体名称 + 判断规则 + 预估基数)。
    • 示例:群体A = “近7天有至少1次购买行为的用户”,基数约 120 万。
  2. 步骤 2:确定触达渠道与覆盖系数
    • 动作:识别用户通过哪些渠道接触到该改动(如:App 首页 Banner、站内信、Push、分享裂变)。
    • 动作:为每个渠道估算覆盖系数(该渠道能触达目标群体的百分比)。
    • 输出:渠道覆盖矩阵(渠道名 + 目标群体 + 覆盖系数 + 数据来源)。
    • 示例:Push 渠道覆盖系数 = 日均 Push 送达独立用户数 ÷ 目标群体基数 = 40%。
  3. 步骤 3:收集并交叉验证数据
    • 动作:从至少 2 个独立数据源获取用户数(如埋点系统 + 业务数据库)。
    • 动作:检查数据一致性,若偏差 > 15% 需说明原因并采用保守值。
    • 输出:数据源对比表(来源 + 数值 + 置信度 + 偏差说明)。
  4. 步骤 4:计算 Reach 值并去重
    • 动作:对多渠道的覆盖用户进行去重合并,得到总独立触达用户数。
    • 公式:Reach = 所有渠道触达的独立用户去重总数。
    • 输出:Reach 估算结果(数值 + 时间窗口 + 置信区间)。
# Reach 估算伪代码示例(Python)
target_users = 1_200_000          # 目标群体基数
push_coverage = 0.40              # Push 渠道覆盖系数
banner_coverage = 0.25            # Banner 渠道覆盖系数
overlap_rate = 0.15               # 渠道间重叠率(预估)

# 去重后 Reach
reach = (target_users * push_coverage) + (target_users * banner_coverage) - (target_users * overlap_rate)
print(f"Estimated Reach: {reach:,.0f} users in 7 days")
# 输出: Estimated Reach: 600,000 users in 7 days

输入输出物

类别 名称 说明 示例
输入物 用户分层定义 明确受影响的用户群体及判断规则 “近7天活跃用户”
输入物 渠道触达数据 各渠道的独立用户覆盖数 Push 送达 48 万用户
输入物 时间窗口定义 统一的计算周期(天/周/月) 7 天
输出物 Reach 估算报告 含数值、置信区间、数据来源 Reach = 60 万 ± 5 万
输出物 渠道覆盖矩阵 渠道与覆盖系数对照表 Push 40%, Banner 25%

责任边界

角色 职责 不负责
产品经理 定义用户群体、选择数据源、输出 Reach 估算值 不负责埋点数据的技术实现
数据分析师 提供用户基数、渠道覆盖数据、去重算法支持 不负责业务决策
开发工程师 确保数据采集埋点正确、提供接口获取用户数 不负责 Reach 估算的数值解读
运营/增长团队 提供渠道触达率和用户分层经验数据 不负责最终评分计算

记录材料

每次 Reach 估算必须填写《Reach 量化工作记录表》,并归档至项目 Wiki。模板如下:

字段 填写内容 必填
需求/特性名称 如“首页搜索推荐优化” 是
目标用户群体 “周活跃≥3天用户” + 基数 是
时间窗口 7 天 / 14 天 / 30 天 是
渠道列表及覆盖系数 渠道A: 40%, 渠道B: 25% 是
数据来源 埋点系统 / 业务库 / 运营后台 是
去重前总触达 78 万 是
去重后 Reach 60 万 是
置信度 高 / 中 / 低(说明原因) 是
估算人 姓名 + 日期 是

异常处理

异常场景 处理方式
数据源冲突,偏差 > 15% 取较低值作为 Reach 上限,并在记录中注明“数据源偏差大,采用保守值”。
无法获取独立用户 ID 改用设备 ID 或 Cookie ID 近似,并标注“近似值,置信度低”。
渠道间重叠率无法估算 默认重叠率 = 0(即不重叠),并在结论中注明“未去重,Reach 可能偏高”。
目标群体基数未知 用产品 MAU/DAU 的 20%~80% 做区间估算,给出上下限。
改动涉及多个用户群体 分层计算每个群体的 Reach,最后加权汇总,避免直接加总。

验收标准

完成本章 Reach 量化后,需满足以下标准才可通过评审:

  • 完整性:Reach 估算报告中包含目标群体、时间窗口、渠道覆盖矩阵、数据来源、去重逻辑、最终数值。
  • 可复现:其他人按照记录材料中的步骤和数据源,能得出相同或相近的 Reach 值(误差 < 10%)。
  • 透明度:所有异常场景和近似处理都在记录中明确标注,不隐瞒数据缺陷。
  • 关联性:Reach 值直接与 RICE 评分中的其他要素(Impact、Confidence、Effort)在同一上下文下使用。
✅ 验收自检清单
□ 目标群体定义清晰且可量化
□ 至少使用 2 个独立数据源交叉验证
□ 渠道覆盖系数总和不超过 100%(合理去重)
□ 记录材料已归档至项目 Wiki
□ 置信度标注明确(高/中/低及原因)

Reach 量化框架图

下图展示了从“定义用户群体”到“输出 Reach 值”的完整流程,包含渠道分支、去重合并和置信度标注。

Reach 量化决策与流程框架图 Reach 量化决策与流程框架 定义目标用户群体 确定触达渠道 & 覆盖系数 数据源交叉验证 渠道A 覆盖系数 独立用户数 渠道B 覆盖系数 独立用户数 渠道C 覆盖系数 独立用户数 去重合并 → 输出 Reach 值 ⚠ 去重时需扣除渠道间重叠用户,重叠率可根据历史数据或抽样估算
📌 本章要点回顾
• Reach 衡量的是独立用户覆盖数,不是 PV 或 UV 的简单加总。
• 估算时必须 定义用户群体 + 时间窗口 + 渠道覆盖系数。
• 数据源交叉验证 & 渠道去重是保证 Reach 准确性的关键。
• 所有异常处理和近似假设必须记录在《Reach 量化工作记录表》中。