2. 四要素详解——Reach（触达）：含义、量化方法、常见误区

适用场景

Reach 用于衡量一个候选任务或特性在单位时间内能够影响的独立用户数量。在 RICE 框架中，Reach 适用于以下场景：

• 需要对比不同用户触达范围的多个待办项
• 评估功能上线后对核心用户群的影响强度
• 在资源受限时优先落地覆盖更广的需求

前置条件

• 用户行为日志（事件名称、用户标识、时间戳）
• 用户去重 ID（如 UUID、设备 ID、登录账号）
• 业务定义的“触达事件”规范（例如：浏览页面、点击按钮、收到推送）
• 统计时间窗口（默认取最近 28 天，可调整）

操作步骤

Reach 的计算可分为四个子步骤，每个步骤都直接影响最终数值的准确性。

1. 定义触达事件：从业务需求中提取明确的用户动作，例如page_view、push_received。
2. 确定时间窗口：一般为最近 28 个自然日，对于季节性功能可缩短为 7 天。
3. 去重计数：按用户 ID 对触发事件的所有用户做唯一计数。
4. 应用阶段权重：若触达发生在灰度阶段，按用户比例折算。

以下伪代码展示了核心逻辑：

function computeReach(eventName, windowDays):
    events = loadEvents(eventName, now - windowDays, now)
    distinctUsers = set()
    for event in events:
        distinctUsers.add(event.userId)
    rawReach = len(distinctUsers)
    if isGreyScale:
        rawReach *= greyScaleRatio
    return rawReach

输入与输出物

责任边界

• 产品经理：定义触达事件、时间窗口、灰度比例
• 数据分析师：编写并执行计算脚本，提供 Reach 数值
• 技术负责人：审核数据源正确性、处理异常数据
• 决策者：依据 Reach 数值参与 RICE 排序

记录材料

每次计算完成后需在项目管理工具中记录以下内容：

• Reach 计算公式（含时间窗口、去重键）
• 数据源名称与查询时间范围
• 灰度比例及调整原因
• 参与复核的人员签名

# Reach 计算记录示例
revision: v2.3
feature: 首页新用户引导弹窗
event: guide_popup_show
window: 28 days (2025-03-01 ~ 2025-03-28)
grey_scale: 1.0
rawReach: 123450
finalReach: 123450
checked_by: zhangsan

异常处理

验收标准

• 双人复核：至少 2 人独立使用相同数据计算，Reach 数值差异 < 1%
• 抽样验证：从原始日志中抽取 1000 条，人工标记用户 ID，验证去重计数与实际一致
• 合理性检查：Reach 不应超过 DAU 的 5 倍，若超出需说明特殊场景（如跨多端累计）
• 变更可追溯：所有计算参数、数据源版本、异常处理都记录在案

Reach 计算流程与常见陷阱