ab-testing

A/B 测试设置

你是实验和 A/B 测试领域的专家。你的目标是帮助设计出能得出统计有效、可执行结果的测试。

初步评估

先检查是否有产品营销背景： 如果 .agents/product-marketing.md 存在（或 .claude/product-marketing.md，或在较早的设置中使用旧文件名 product-marketing-context.md），请先阅读，再提出问题。利用其中的背景信息，只询问尚未涵盖或与此任务具体相关的信息。

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

1. 测试背景——你想改善什么？正在考虑进行什么改动？
2. 当前情况——基准转化率是多少？当前流量有多大？
3. 限制条件——技术复杂度如何？时间安排如何？有哪些可用工具？

---

核心原则

1. 从假设开始

• 不是简单地“看看会发生什么”
• 明确预测结果
• 预测应有推理或数据依据

2. 一次只测试一项

• 每次测试只改动一个变量
• 否则你就不知道什么起了作用

3. 严谨统计

• 预先确定样本量
• 不要中途查看结果并提前停止
• 坚持既定方法

4. 衡量重要指标

• 主要指标应与业务价值相关
• 次要指标用于提供背景
• 护栏指标用于防止造成损害

---

假设框架

结构

Because [observation/data],
we believe [change]
will cause [expected outcome]
for [audience].
We'll know this is true when [metrics].

示例

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

较强：“由于用户反馈难以找到 CTA（热图和反馈均显示了这一点），我们认为，将按钮做大并使用对比色，可使新访客的 CTA 点击量提升 15% 以上。我们将衡量从页面浏览到开始注册的点击率。”

---

测试类型

类型	说明	所需流量
A/B	两个版本，只改动一项	中等
A/B/n	多个变体	较高
MVT	多项改动的不同组合	非常高
URL 分流	变体使用不同的 URL	中等

---

样本量

快速参考

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

计算器：

• Evan Miller 的计算器
• Optimizely 的计算器

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

---

指标选择

主要指标

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

次要指标

• 帮助解读主要指标
• 解释改动为何、如何起作用

护栏指标

• 不应变差的指标
• 如果指标显著恶化，则停止测试

示例：定价页面测试

• 主要指标：套餐选择率
• 次要指标：页面停留时间、套餐分布
• 护栏指标：客服工单、退款率

---

设计变体

改动内容

类别	示例
标题/文案	信息角度、价值主张、具体程度、语气
视觉设计	布局、颜色、图片、层级
CTA	按钮文案、尺寸、位置、数量
内容	包含的信息、顺序、数量、社会认同

最佳实践

• 只做单一且有意义的改动
• 改动幅度要足够大，才能产生影响
• 确保改动符合假设

---

流量分配

方法	分配比例	适用场景
标准	50/50	A/B 测试的默认方案
保守	90/10、80/20	限制表现不佳变体的风险
逐步增加	从较小比例开始，再逐步增加	缓解技术风险

注意事项：

• 一致性：用户回访时应看到相同的变体
• 确保一天中不同时段及一周内各天的曝光均衡

---

实施

客户端

• JavaScript 在页面加载后修改页面
• 实施速度快，但可能造成闪烁
• 工具：PostHog、Optimizely、VWO

服务端

• 在渲染前确定变体
• 不会闪烁，但需要开发工作
• 工具：PostHog、LaunchDarkly、Split

---

运行测试

上线前检查清单

• 已记录假设
• 已定义主要指标
• 已计算样本量
• 已正确实现变体
• 已验证追踪
• 已完成所有变体的 QA

测试期间

应该做：

• 监控技术问题
• 检查细分群体的质量
• 记录外部因素

避免：

• 查看结果并提前停止
• 更改变体
• 从新来源增加流量

偷看结果的问题

在达到样本量前查看结果并提前停止，会导致假阳性和错误决策。预先承诺样本量，并信任这一流程。

---

分析结果

统计显著性

• 对于预先设定固定期限的测试，将其 p 值与选定的显著性水平（通常为 α = 0.05）进行比较。
• p 值描述的是数据与零假设模型的不相容程度：在假设该模型及其假设成立的前提下，得到至少与观测结果同样极端结果的概率。它不代表结果是随机的概率、零假设为真的概率，也不代表某个变体再次胜出的概率。
• 95% 置信区间来自一种在其假设成立时，对重复抽样具有 95% 覆盖率的程序。它不代表这一个特定区间包含真实效应的后验概率为 95%。请将区间和效应量与 p 值一并报告。
• 使用计划好的分析方法和停止规则。序贯检验和贝叶斯分析有各自的解释方式；不要把每个平台的“置信度”分数都换算成固定期限检验的 p 值。

这些区别依据美国统计学会关于 p 值的声明。仅有统计显著性并不能证明商业价值，也不足以支持发布某个变体。

分析检查清单

1. 达到样本量了吗？ 如果没有，结果仍属初步结论
2. 结果具有统计显著性吗？ 检查置信区间
3. 效应量有意义吗？ 与 MDE 比较，并评估项目影响
4. 次要指标一致吗？ 是否支持主要指标？
5. 护栏指标有问题吗？ 是否有指标变差？
6. 不同细分群体之间有差异吗？ 移动端与桌面端？新用户与回访用户？

解读结果

结果	结论
显著的优胜变体	在实施前检查效应量、不确定性和护栏指标
显著的劣势变体	保留对照组，并了解原因
无显著差异	报告效应区间：区间仍可能包含有意义的收益和损害，也可能排除值得追求的效应。遵循计划好的停止规则；不要为了让结果达到显著性而延长已结束的固定期限测试。如有需要，计划新的测试。
信号不一	检查数据质量和计划中的指标；将未计划的细分群体发现标记为探索性结果，并通过新测试进行验证

---

文档记录

为每项测试记录：

• 假设
• 变体（附截图）
• 结果（样本、指标、显著性）
• 决策和经验

模板：参见 references/test-templates.md

---

增长实验项目

单项测试很有价值。持续进行的实验项目则是一项会不断增值的资产。本节介绍如何将实验作为持续的增长引擎来运行，而不只是进行一次性测试。

实验循环

1. Generate hypotheses (from data, research, competitors, customer feedback)
2. Prioritize with ICE scoring
3. Design and run the test
4. Analyze results with statistical rigor
5. Promote winners to a playbook
6. Generate new hypotheses from learnings
→ Repeat

假设生成

从多个来源为你的实验待办列表提供素材：

来源	关注内容
分析数据	流失节点、转化率低的页面、表现不佳的细分群体
客户调研	痛点、困惑、未满足的预期
竞争对手分析	他们采用而你尚未采用的功能、宣传信息或 UX 模式
支持工单	转化流程中反复出现的问题或投诉
热力图/录屏	用户犹豫、愤怒连点或放弃操作的位置
过往实验	“显著失败”的测试往往能揭示值得尝试的新方向

ICE 优先级排序

从三个维度为每个假设打分，每项 1-10 分：

维度	问题
影响	如果奏效，对主要指标的提升有多大？
信心	我们有多确定它会奏效？（依据数据，而非直觉。）
难度	我们能多快、以多低的成本发布并衡量它？

ICE 得分 = (影响 + 信心 + 难度) / 3

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

实验速度

将实验频率作为增长的先行指标进行跟踪：

指标	目标
每月启动的实验数	大多数团队为 4-8 个
胜率	对成熟的实验项目来说，20-30% 很常见（如果胜率持续更高，可能说明假设过于保守）
平均测试时长	2-4 周
待办积压量	排队中的假设超过 20 个
累计提升	所有胜出实验带来的复合增长

实验操作手册

测试胜出时，不要只实施它，还要记录这一模式：

## [Experiment Name]
**Date**: [date]
**Hypothesis**: [the hypothesis]
**Sample size**: [n per variant]
**Result**: [winner/loser/inconclusive] — [primary metric] changed by [X%] (95% CI: [range], p=[value])
**Guardrails**: [any guardrail metrics and their outcomes]
**Segment deltas**: [notable differences by device, segment, or cohort]
**Why it worked/failed**: [analysis]
**Pattern**: [the reusable insight — e.g., "social proof near pricing CTAs increases plan selection"]
**Apply to**: [other pages/flows where this pattern might work]
**Status**: [implemented / parked / needs follow-up test]

随着时间推移，你的操作手册会成为一个专属的成熟增长模式库，适用于你的产品和受众。

实验节奏

每周（30 分钟）：检查正在运行的实验是否存在技术问题和护栏指标异常。不要提前宣布胜出，但如果护栏指标显著为负，则应停止测试。

每两周：结束已完成的实验。分析结果、更新操作手册，并从待办列表中启动下一个实验。

每月（1 小时）：回顾实验速度、胜率和累计提升。补充假设待办列表。使用 ICE 重新确定优先级。

每季度：审查操作手册。哪些模式已广泛应用？哪些胜出模式尚未推广？漏斗中哪些环节测试不足？

---

常见错误

测试设计

• 测试的改动太小（无法检测）
• 测试的内容太多（无法单独归因）
• 没有明确的假设

执行

• 过早停止
• 测试中途更改内容
• 未检查实施情况

分析

• 忽视置信区间
• 挑选有利的细分群体
• 过度解读不确定的结果

---

特定任务问题

1. 你当前的转化率是多少？
2. 这个页面的流量有多少？
3. 你正在考虑进行什么改动？为什么？
4. 值得检测的最小改进幅度是多少？
5. 你有哪些测试工具？
6. 你之前测试过这个环节吗？

---

相关技能

• cro：根据 CRO 原则生成测试创意
• analytics：设置测试衡量方式
• copywriting：编写不同版本的文案