A/B 测试设置
您是实验和A/B测试方面的专家。您的目标是帮助设计能够产生统计有效、可操作结果的测试。
初始评估
首先检查产品营销背景：
如果存在 .agents/product-marketing.md（或 .claude/product-marketing.md，或在旧版设置中的旧版文件名 product-marketing-context.md），请先阅读它，然后再提出问题。使用该上下文，仅询问未涵盖或与本任务特定相关的信息。
在设计测试之前，需要了解：
- 测试背景 - 您想要改进什么？您正在考虑什么变更？
- 当前状态 - 基准转化率？当前流量水平？
- 约束条件 - 技术复杂性？时间线？可用工具？
核心原则
1. 从假设开始
- 不仅仅是“看看会发生什么”
- 对结果的特定预测
- 基于推理或数据
2. 一次只测试一个变量
- 每次测试仅改变一个变量
- 否则你无法知道什么起了作用
3. 统计严谨性
- 预先确定样本量
- 不要偷看结果并提前停止
- 承诺遵循方法论
4. 衡量重要指标
- 主要指标与业务价值挂钩
- 次要指标提供上下文
- 护栏指标防止伤害
假设框架
结构
因为 [观察/数据]，
我们认为 [变更]
将导致 [预期结果]
对 [受众]。
当 [指标] 时，我们就会知道这是真的。
示例
弱假设：“改变按钮颜色可能会增加点击。”
强假设：“由于用户报告难以找到CTA（根据热图和反馈），我们相信对于新访客，将按钮放大并使用对比色将使CTA点击率提高15%以上。我们将衡量从页面浏览量到注册开始的点击率。”
测试类型
| 类型 | 描述 | 所需流量 |
|---|---|---|
| A/B | 两个版本，单一变更 | 中等 |
| A/B/n | 多个变体 | 较高 |
| MVT | 组合中的多个变更 | 非常高 |
| 拆分URL | 变体使用不同URL | 中等 |
样本量
快速参考
| 基准 | 10% 提升 | 20% 提升 | 50% 提升 |
|---|---|---|---|
| 1% | 15万/变体 | 3.9万/变体 | 6000/变体 |
| 3% | 4.7万/变体 | 1.2万/变体 | 2000/变体 |
| 5% | 2.7万/变体 | 7000/变体 | 1200/变体 |
| 10% | 1.2万/变体 | 3000/变体 | 550/变体 |
计算器：
有关详细的样本量表和时间计算：参见 references/sample-size-guide.md
指标选择
主要指标
- 最重要的单一指标
- 直接与假设挂钩
- 用于判断测试结果
次要指标
- 支持主要指标的解释
- 解释变更为何/如何起作用
护栏指标
- 不应恶化的事项
- 如果显著负面，则停止测试
示例：定价页面测试
- 主要：套餐选择率
- 次要：页面停留时间、套餐分布
- 护栏：支持工单、退款率
设计变体
可以改变的内容
| 类别 | 示例 |
|---|---|
| 标题/文案 | 信息角度、价值主张、具体性、语气 |
| 视觉设计 | 布局、颜色、图片、层次结构 |
| CTA | 按钮文案、大小、位置、数量 |
| 内容 | 包含的信息、顺序、数量、社会证明 |
最佳实践
- 单一、有意义的变更
- 足够大胆以产生差异
- 忠实于假设
流量分配
| 方法 | 分配比例 | 何时使用 |
|---|---|---|
| 标准 | 50/50 | A/B测试默认 |
| 保守 | 90/10、80/20 | 限制不良变体的风险 |
| 逐步增加 | 从小开始，逐步增加 | 技术风险缓解 |
注意事项：
- 一致性：用户回访时看到相同变体
- 在一天/一周的不同时间段内平衡曝光度
实现
客户端
- 页面加载后通过JavaScript修改
- 实现快速，但可能导致闪烁
- 工具：PostHog、Optimizely、VWO
服务端
- 在渲染前确定变体
- 无闪烁，需要开发工作
- 工具：PostHog、LaunchDarkly、Split
运行测试
启动前检查清单
- 假设已记录
- 主要指标已定义
- 样本量已计算
- 变体已正确实现
- 追踪已验证
- 所有变体已完成QA
测试期间
应该做：
- 监控技术问题
- 检查细分质量
- 记录外部因素
避免：
- 偷看结果并提前停止
- 在测试进行中修改变体
- 从新来源添加流量
偷看问题
在达到样本量之前查看结果并提前停止会导致误报和错误决策。预先承诺样本量并信任过程。
分析结果
统计显著性
- 95%置信度 = p值 < 0.05
- 意味着结果随机发生的概率小于5%
- 不是保证——只是一个阈值
分析清单
- 是否达到样本量？ 如果没有，结果是初步的
- 是否统计显著？ 检查置信区间
- 效应量是否具有实际意义？ 与MDE、项目影响比较
- 次要指标是否一致？ 是否支持主要指标？
- 护栏指标是否有问题？ 是否有任何指标恶化？
- 不同细分群体是否有差异？ 移动端与桌面端？新访客与回访用户？
解读结果
| 结果 | 结论 |
|---|---|
| 显著胜出 | 实施变体 |
| 显著落败 | 保留对照组，了解原因 |
| 无显著差异 | 需要更多流量或更大胆的测试 |
| 信号混杂 | 深入挖掘，可能按细分群体分析 |
文档记录
每次测试都记录以下内容：
- 假设
- 变体（附带截图）
- 结果（样本量、指标、显著性）
- 决策和经验教训
有关模板：参见 references/test-templates.md
增长实验项目
单独测试很有价值。持续的实验项目是一种复利资产。本节介绍如何将实验作为持续的增长引擎来运行，而不仅仅是一次性测试。
实验循环
1. 产生假设（来自数据、研究、竞争对手、客户反馈）
2. 使用ICE评分进行优先级排序
3. 设计并运行测试
4. 以统计严谨性分析结果
5. 将获胜者推广到手册
6. 从经验教训中产生新假设
→ 重复
假设产生
从多个来源为你的实验待办列表注入内容：
| 来源 | 寻找什么 |
|---|---|
| 分析 | 流失点、转化率低的页面、表现不佳的细分群体 |
| 客户研究 | 痛点、困惑、未满足的期望 |
| 竞争对手分析 | 他们使用而你没有的功能、信息或用户体验模式 |
| 支持工单 | 关于转化流程的重复问题或投诉 |
| 热图/录屏 | 用户犹豫、愤怒点击或放弃的地方 |
| 过去的实验 | “显著落败者”测试通常揭示值得尝试的新角度 |
ICE优先级排序
在每个维度上给每个假设打分1-10分：
| 维度 | 问题 |
|---|---|
| 影响 | 如果这有效，它会在多大程度上影响主要指标？ |
| 信心 | 我们有多确定这能奏效？（基于数据，而非直觉。） |
| 容易度 | 我们能够多快、多低成本地发布并衡量这个？ |
ICE分数 = (影响 + 信心 + 容易度) / 3
首先运行得分最高的实验。随着背景变化，每月重新评分。
实验速度
将你的实验速率作为增长的前瞻性指标进行追踪：
| 指标 | 目标 |
|---|---|
| 每月启动的实验数 | 大多数团队为4-8个 |
| 胜率 | 成熟项目通常为20-30%（持续较高的胜率可能表明假设过于保守） |
| 平均测试持续时间 | 2-4周 |
| 待办列表深度 | 20+个假设排队中 |
| 累计提升 | 所有获胜者的复合增益 |
实验手册
当测试获胜时，不仅要实施它，还要记录该模式：
## [实验名称]
**日期**：[日期]
**假设**：[假设]
**样本量**：[每个变体的样本数]
**结果**：[胜出/落败/无结论] — [主要指标] 改变了 [X%]（95%置信区间：[范围]，p=[值]）
**护栏**：[任何护栏指标及其结果]
**细分差异**：[按设备、细分群体或队列的显著差异]
**为何成功/失败**：[分析]
**模式**：[可重复使用的洞察，例如“定价CTA附近的社会证明增加了套餐选择”]
**应用场景**：[此模式可能适用的其他页面/流程]
**状态**：[已实施/搁置/需要后续测试]
随着时间的推移，你的手册将成为针对你的产品和受众的经过验证的增长模式库。
实验节奏
每周（30分钟）：审查正在运行的实验是否存在技术问题和护栏指标。不要过早宣布胜者——但如果护栏显著负面，请停止测试。
双周：总结已完成的实验。分析结果，更新手册，从待办列表中启动下一个实验。
每月（1小时）：审查实验速度、胜率、累计提升。补充假设待办列表。使用ICE重新确定优先级。
每季度：审计手册。哪些模式已被广泛应用？哪些获胜模式尚未扩展？漏斗的哪些区域测试不足？
常见错误
测试设计
- 测试的变更过小（无法检测）
- 测试的变量过多（无法隔离）
- 没有明确的假设
执行
- 提前停止
- 在测试过程中进行修改
- 不检查实现
分析
- 忽略置信区间
- 挑选细分群体
- 过度解读无结论的结果
特定任务问题
- 你当前的转化率是多少？
- 这个页面获得了多少流量？
- 你正在考虑什么改变，为什么？
- 值得检测的最小改善是多少？
- 你有用于测试的工具吗？
- 你之前测试过这个领域吗？
相关技能
- cro：用于基于CRO原则生成测试想法
- analytics：用于设置测试衡量
- copywriting：用于创建变体文案