第 2 章 · 适用场景判断：何时使用A/B测试排序、何时不适合、资源门槛、时间窗口

不是所有需求候选集都适合用 A/B 测试来排序。误用 A/B 测试不仅浪费流量，还会得出误导性结论，甚至拖慢发布节奏。本章建立一套快速判断框架，帮助你在立项前用 5 分钟确认“能不能测”。

1. 适用场景 · 可以测

• 高流量 + 低单位成本：日均 UV ≥ 10 000，且每次展示/点击的边际成本可忽略。
• 可隔离的变量：待排序的需求能拆分为互斥的版本（如按钮颜色、文案措辞、推荐算法），版本间互不干扰。
• 短期可观测指标：核心指标（CTR、转化率、时长）在 3～7 天内能收敛到统计显著。
• 低风险变更：不会触发法律风险、品牌底线或用户安全，即“最差版本”也能接受。

2. 不适合场景 · 不要测

• 低频使用页面：月 PV < 1 000，长期无法收集样本。
• 无法拆分流量：技术架构不支持同层分流（如仅一套后端、无实验平台）。
• 指标滞后严重：核心收益在 30 天之后才显现（如用户留存、LTV），等不起实验周期。
• 不可逆改动：版本间无法回滚，或改造成本高于收益（如 API 重构、数据库模式变更）。
• 政策/合规约束：用户分组可能导致差异化服务违法（如 GDPR、隐私保护）。

3. 资源门槛 · 最少需要什么

• 工程资源：1 名开发 × 2 天（前端或服务端埋点 + 分流逻辑）。
• 数据资源：已有事件采集管道，能产出核心指标报表。
• 分析能力：至少 1 人会用 t 检验或贝叶斯方法判断显著性。

4. 时间窗口 · 多久能出结果

从需求提出到排序结论，总时间 = 开发 2 d + 实验运行 3～7 d + 分析 1 d = 6～10 d。若上线窗口 < 5 天，跳过 A/B 测试，改用专家打分或 ICE 法。

5. 前置条件

• 已输出需求候选列表（≥ 5 项），每项有预期收益方向。
• 已确认基础流量监控系统在运行。
• 产品经理与开发负责人已对齐本决策的权责。

6. 操作步骤

1. 流量核查：在后台导出近 7 日 UV，确认是否 ≥ 10 000。
2. 变量隔离性评估：列出每个需求的改动范围，判断是否可以独立上线/回滚。
3. 指标收敛预估：根据历史同类实验，估算核心指标达到显著所需天数。
4. 风险清单检查：对照法律、安全、品牌维度，排除风险不可控项。
5. 资源盘点：当前 sprint 能否出土 2 个开发人天 + 实验平台接入。
6. 时间窗口对齐：业务方要求的上线截止日是否 ≥ 当前日期 + 10 d。

7. 输入输出物

8. 责任边界

• 产品经理：提供需求清单、预期指标、上线 deadline。
• 数据分析师：提供流量报表、历史实验收敛时长。
• 开发负责人：评估分流实现成本、版本回滚方案。
• 法务/合规：若涉及用户分组差异化，需签署确认无合规风险。

9. 记录材料

• 《适用性判定表》（模板见课程附件）
• 流量佐证截图
• 资源成本估算（工时 + 基础设施）
• 会议纪要 / 决策拉齐记录

10. 异常处理

• 流量达标但无法隔离：拆分为多期单变量实验，或改为准实验（非随机分组）。
• 资源不足：借调 QA 或数据团队，或砍掉 1～2 个低优先级需求换取人天。
• 时间窗口不够：压缩实验范围（仅测最关键变量），或用贝叶斯方法提前 20% 停止。
• 合规风险突现：立即标记为“不可测”，转由法务升级处理。

11. 验收标准

• 每一候选需求都落到“可测 / 不可测”两个桶中。
• 不可测项附有明确原因（如流量不足、不可逆、合规风险）。
• 可测项已确认满足：日均 UV ≥ 10K + 可隔离 + 收敛 ≤ 7 d + 低风险 + 资源可交付。
• 判定结果已由 PM、数分、开发三方签字确认。