A/B 测试

ab-testing
分类编程
作者Agentic Awesome Skills 社区
许可MIT
评分4.60/5
使用12.9K

A/B 测试设置

何时使用

当用户想要规划、设计或实施 A/B 测试或实验，或者构建增长实验计划时使用此技能。此外，当用户提到“A/B 测试”、“拆分测试”、“实验”、“测试此更改”、“变体文案”、“多变量测试”、“假设”、“我应该测试这个吗”等词汇时也请使用。

你是一位实验和 A/B 测试专家。你的目标是帮助设计能够产生统计学有效且具有可操作性结果的测试。

初始评估

首先检查产品营销上下文：
如果存在 .agents/product-marketing.md（或 .claude/product-marketing.md，以及在旧设置中的 product-marketing-context.md 文件），请在提问前阅读。利用该上下文，仅询问尚未涵盖或针对此任务的特定信息。

在设计测试之前，请了解：

1. 测试背景 - 你试图改进什么？你正在考虑什么样的更改？
2. 当前状态 - 基准转化率是多少？当前的流量规模如何？
3. 约束条件 - 技术复杂度如何？时间线如何？可用工具有哪些？

---

核心原则

1. 从假设开始

  • 不要只是“看看会发生什么”
  • 对结果做出具体预测
  • 基于推理或数据

2. 每次只测试一项

  • 每个测试仅包含单一变量
  • 否则你无法确定是什么起到了作用

3. 统计严谨性

  • 预先确定样本量
  • 不要中途窥视并提前停止
  • 坚持执行既定方法论

4. 衡量关键指标

  • 主指标必须与业务价值挂钩
  • 次要指标用于提供上下文
  • 护栏指标（Guardrail metrics）用于防止负面影响

---

假设框架

结构

code
基于 [观察/数据]，
我们认为 [更改]
将导致 [预期结果]
针对 [受众]。
当 [指标] 达成时，我们将验证此假设成立。

示例

弱假设：“更改按钮颜色可能会增加点击量。”

强假设：“由于用户反馈难以找到 CTA（根据热力图和反馈），我们认为将按钮调大并使用对比色将使新访客的 CTA 点击率提高 15% 以上。我们将衡量从页面浏览到开始注册的点击率。”

---

测试类型

| 类型 | 描述 | 所需流量 |
|------|-------------|----------------|
| A/B | 两个版本，单一更改 | 中等 |
| A/B/n | 多个变体 | 较高 |
| MVT | 多个更改的组合 | 极高 |
| Split URL | 不同变体使用不同 URL | 中等 |

---

样本量

快速参考

| 基准 | 10% 提升 | 20% 提升 | 50% 提升 |
|----------|----------|----------|----------|
| 1% | 150k/变体 | 39k/变体 | 6k/变体 |
| 3% | 47k/变体 | 12k/变体 | 2k/变体 |
| 5% | 27k/变体 | 7k/变体 | 1.2k/变体 |
| 10% | 12k/变体 | 3k/变体 | 550/变体 |

计算器：



imizely.com/sample-size-calculator/)

详细的样本量表格和时长计算：请参阅 references/sample-size-guide.md

---

指标选择

核心指标 (Primary Metric)

  • 最关键的单一指标
  • 与假设直接相关
  • 用于判定测试结果的依据

次要指标 (Secondary Metrics)

  • 辅助核心指标的解读
  • 解释变更生效的原因或方式

护栏指标 (Guardrail Metrics)

  • 不应恶化的指标
  • 若出现显著负面影响，则停止测试

示例：定价页测试

  • 核心指标：方案选择率
  • 次要指标：页面停留时间、方案分布
  • 护栏指标：客服工单量、退款率

---

变体设计

变量维度

| 类别 | 示例 |
|----------|----------|
| 标题/文案 | 消息角度、价值主张、具体程度、语气 |
| 视觉设计 | 布局、颜色、图片、层级 |
| CTA (行动号召) | 按钮文案、尺寸、位置、数量 |
| 内容 | 包含的信息、顺序、数量、社交证明 |

最佳实践

  • 每次仅进行一项有意义的变更
  • 变更幅度足够大，以产生可察觉的差异
  • 忠实于初始假设

---

流量分配

| 方案 | 分配比例 | 使用场景 |
|----------|-------|-------------|
| 标准 | 50/50 | A/B 测试默认方案 |
| 保守 | 90/10, 80/20 | 降低劣质变体带来的风险 |
| 渐进 | 从小比例开始，逐步增加 | 缓解技术风险 |

注意事项：

  • 一致性：用户再次访问时应看到相同的变体

  • 均衡性：确保在不同时间段/周内地均匀曝光

---

实施方案

客户端 (Client-Side)

  • JavaScript 在页面加载后进行修改
  • 实施快速，但可能导致页面闪烁 (flicker)
  • 工具：PostHog, Optimizely, VWO

服务端 (Server-Side)

  • 在页面渲染前确定变体
  • 无闪烁，但需要开发工作
  • 工具：PostHog, LaunchDarkly, Split

---

执行测试

上线前检查清单

  • [ ] 假设已记录
  • [ ] 核心指标已定义
  • [ ] 样本量已计算
  • [ ] 变体已正确实施
  • [ ] 埋点已验证
  • [ ] 所有变体已完成 QA 测试

测试期间

建议执行 (DO)：

  • 监控技术问题

  • 检查分群质量

  • 记录外部影响因素

应避免 (Avoid)：

  • 频繁查看结果并提前停止测试

  • 修改已上线的变体

  • 引入新的流量来源

“偷看”问题 (The Peeking Problem)

在达到预设样本量之前查看结果并提前停止，会导致假阳性 (false positives) 和错误决策。请预先承诺样本量并信任测试过程。

---

结果分析

统计显著性

  • 95% 置信度 = p-value < 0.05
  • 意味着结果由随机因素导致的概率 < 5%
  • 这不是绝对保证，而是一个阈值

分析检查清单

1. 是否达到样本量？ 若未达到，结果仅为初步结论
2. 是否具有统计显著性？ 检查置信区间
3. 效应量 (Effect size) 是否有意义？ 与 MDE 比较，预估影响
4. 次要指标是否一致？ 是否支持核心指标？
5. 护栏指标是否有问题？ 是否有指标恶化？
6. 分群是否存在差异？ 移动端 vs 桌面端？新用户 vs 回访用户？

结果解读

| 结果 | 结论 |
|--------|------------|
| 显著胜出 | 部署该变体 |
| 显著落败 | 保留对照组，分析原因 |
| 无显著差异 | 需要更多流量或更大胆的测试 |
| 信号矛盾 | 深入挖掘，尝试分群分析 |

---

文档记录

每项测试均需记录：

  • 假设

  • 变体（附截图）

  • 结果（样本量、指标、显著性）

  • 决策及心得

模板参考：请参阅 references/test-templates.md

---

增长实验计划

Indivi
持续的实验计划是一项具有复利效应的资产。本节将介绍如何将实验作为持续的增长引擎来运行，而不仅仅是零散的单次测试。

实验循环

code
1. 生成假设（基于数据、研究、竞品、客户反馈）
2. 使用 ICE 评分进行优先级排序
3. 设计并运行测试
4. 使用统计学严谨性分析结果
5. 将获胜方案记录至 Playbook（实验手册）
6. 从学习结果中生成新假设
→ 重复

假设生成

通过多种渠道填充你的实验待办列表（Backlog）：

| 来源 | 关注点 |
|--------|-----------------|
| 数据分析 | 流失点、低转化页面、表现不佳的用户分群 |
| 客户研究 | 痛点、困惑、未满足的预期 |
| 竞品分析 | 对方拥有而你没有的功能、话术或 UX 模式 |
| 客服工单 | 关于转化流程的重复性问题或投诉 |
| 热力图/录屏 | 用户犹豫、愤怒点击或放弃的位置 |
| 过往实验 | “显著失败”的测试通常能揭示新的尝试方向 |

ICE 优先级排序

从三个维度为每个假设打分（1-10 分）：

| 维度 | 核心问题 |
|-----------|----------|
| 影响力 (Impact) | 如果奏效，对核心指标的提升幅度有多大？ |
| 信心值 (Confidence) | 我们有多大把握它会奏效？（基于数据，而非直觉） |
| 易行度 (Ease) | 上线和衡量该实验的速度有多快，成本有多低？ |

ICE 分数 = (影响力 + 信心值 + 易行度) / 3

优先运行得分最高的实验。随着环境变化，每月重新评分。

实验速度

将实验速率作为增长的领先指标进行追踪：

| 指标 | 目标 |
|--------|--------|
| 每月启动实验数 | 大多数团队为 4-8 个 |
| 胜率 | 成熟计划通常在 20-30%（持续过高可能意味着假设过于保守） |
| 平均测试时长 | 2-4 周 |
| 待办列表深度 | 积压 20 个以上的假设 |
| 累计提升 | 所有获胜实验带来的复利增长 |

实验 Playbook (手册)

当测试获胜时，不要只是简单地实施，而要记录其模式：

code
## [实验名称]
日期: [日期]
假设: [假设内容]
样本量: [每个变体的样本数 n]
结果: [获胜/失败/无结论] — [核心指标] 变化 [X%] (95% 置信区间: [范围], p=[值])
护栏指标: [任何护栏指标及其结果]
分群差异: [设备、分群或队列之间的显著差异]
成功/失败原因: [分析]
模式: [可复用的洞察 —— 例如，“在定价 CTA 附近添加社交证明可提高方案选择率”]
适用场景: [该模式可能奏效的其他页面/流程]
状态: [已实施 / 暂缓 / 需要后续测试]

随着时间的推移，你的 Playbook 将成为一个针对你的产品和受众的、经过验证的增长模式库。

实验节奏

每周 (30 分钟)：检查运行中的实验是否存在技术问题或护栏指标异常。不要过早判定获胜，但如果护栏指标出现显著负面影响，应立即停止测试。

每两周：总结已完成的实验。分析结果，更新 Playbook，从待办列表中启动下一个实验。

每月 (1 小时)：回顾实验速度、胜率和累计提升。补充假设待办列表，使用 ICE 重新排序。

每季度：审计 Playbook。哪些模式已被广泛应用？哪些获胜模式尚未规模化？漏斗的哪些环节测试不足？

---

常见错误

测试设计

  • 测试的改动幅度太小（不...
  • 可检测性不足
  • 测试变量过多（无法隔离）
  • 缺乏明确的假设

执行阶段

  • 过早停止测试
  • 测试中途修改变量
  • 未检查具体实现

分析阶段

  • 忽略置信区间
  • 刻意挑选数据片段（Cherry-picking）
  • 对不确定的结果过度解读

---

任务相关问题

1. 当前的转化率是多少？
2. 该页面的流量规模如何？
3. 你考虑做出什么更改？原因是什么？
4. 值得检测的最小提升幅度是多少？
5. 你拥有哪些测试工具？
6. 之前是否对该区域进行过测试？

---

相关技能

  • cro：基于 CRO 原则生成测试想法
  • analytics：设置测试衡量指标
  • copywriting：创作变体文案

局限性

  • 仅在任务与上游来源及本地项目上下文明确匹配时使用此技能。
  • 在应用更改前，请验证命令、生成的代码、依赖项、凭据以及外部服务的行为。
  • 不要将示例视为环境特定测试、安全审查或破坏性/高成本操作用户确认的替代方案。