> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# A/B测试

> A/B测试是一种比较网页或应用两个版本以确定哪个表现更好的方法。学习如何运行统计有效的A/B测试。

<Info>
  **类别**: 方法<br />
  **类型**: 实验框架<br />
  **起源**: 随机对照试验，18世纪医学 / 网络优化，1990年代-2000年代<br />
  **别名**: 分割测试、分桶测试、对照实验
</Info>

<Note>
  **快速回答** — A/B测试是一种比较产品两个版本的方法——通常是网页、应用屏幕或功能——以确定哪个在特定目标上表现更好。通过随机向不同用户展示每个版本并测量结果，团队可以做出关于哪些更改实际上改善了用户体验和业务指标的数据驱动决策。关键洞察是直觉是不可靠的；只有受控实验才能可靠地区分产品决策中的因果关系。
</Note>

## 什么是A/B测试？

A/B测试是一种受控实验，其中比较产品元素的两个版本，以确定哪个版本在特定指标上取得更好的结果。一个版本（A，对照组）与修改版本（B，处理组）进行比较，用户被随机分配到每组。通过测量组间结果的差异，团队可以将行为的变化归因于所做的特定修改。

这一实践源于几个世纪前的医学研究，但其网络和产品开发中的应用始于1990年代末和2000年代初，当时亚马逊、谷歌和Netflix等公司开始尝试数据驱动的产品决策。如今，A/B测试是数字产品开发的基本实践，几乎每家大型科技公司都使用它来优化从按钮颜色到整个用户体验的一切。

> "受控实验是任何想要做出数据驱动决策的人工具包中最强大的工具。" — 罗恩·科哈维，前Netflix高管和A/B测试先驱

A/B测试的力量在于其隔离特定更改效果的能力。没有受控实验，就不可能知道观察到的改善是由于更改、外部因素还是随机机会。正确设计的A/B测试提供了统计置信度，证明观察到的差异是真实的。

### A/B测试的三层理解

* **入门**: 从定义你想要改进的单一主要指标开始（如点击率或转化率）。创建一个简单的更改来测试，确保你的样本量足够大，并在分析结果之前运行固定持续时间的测试。

* **Practitioner**: 使用多变量测试同时测试多个变量。实施适当的统计显著性阈值（通常为95%）。细分结果以了解不同用户组的效果，同时避免过度解释小样本细分。

* **Advanced**: 应用顺序测试方法，允许在结果明确时提前停止。使用保留组测试长期效果与新奇效果。实施贝叶斯分析以更快地进行不确定量化的决策。

## 起源

A/B测试的起源可追溯到随机对照试验（RCT）的概念，该概念在20世纪初统计学家如罗纳德·费舍尔的工作后成为医学研究的标准。基本原则——随机分配受试者到处理组和对照组以隔离干预的效果——直接转化为产品测试。

受控实验适应网络优化始于1990年代末。2000年，谷歌运行了最早的A/B测试之一，测试每页显示的搜索结果数量。亚马逊、Netflix和其他互联网公司迅速采用这一做法，认识到当应用于数百万用户时，用户界面的微小变化可能产生巨大的财务影响。

罗恩·科哈维（曾在亚马逊和后来的Netflix负责实验）被广泛认为是将现代A/B测试实践数字产品化的先驱。他的工作确立了许多至今仍在使用的统计和运营最佳实践，包括实验项目中信任、速度和迭代的重要性。

## 核心要点

<Steps>
  <Step title="定义清晰的假设">
    在测试之前，阐述你期望发生什么以及为什么。好的假设指定了更改、预期结果和将衡量成功的指标。
  </Step>

  <Step title="选择和优先排序指标">
    选择直接衡量你的目标的主要指标（转化率、每用户收入）。包括次要指标以观察意外后果。避免优化虚荣指标。
  </Step>

  <Step title="确保统计有效性">
    在开始前计算所需样本量。运行足够长时间的测试以达到统计显著性。理解统计显著性与实际重要性之间的区别。
  </Step>

  <Step title="正确随机化">
    随机分配用户到测试组以确保可比性。在会话间保持一致的分配（同一用户看到相同版本）。考虑用户级与会话级随机化。
  </Step>

  <Step title="分析并根据结果采取行动">
    在得出结论之前等待足够的样本量。仔细考虑细分分析——查看太多细分会增加误报风险。实施获胜者并迭代失败者。
  </Step>
</Steps>

## 应用场景

<CardGroup cols={2}>
  <Card title="网站转化优化">
    电子商务网站测试结账流程、定价页面、产品描述和行动号召。单个获胜测试可以将收入增加10-30%。
  </Card>

  <Card title="移动应用优化">
    应用开发者测试入职流程、功能配置、付费墙和通知时机。移动测试通常关注参与度和留存指标。
  </Card>

  <Card title="邮件营销">
    营销人员测试主题行、发送时间、内容布局和行动号召。邮件A/B测试通常关注打开率和点击率。
  </Card>

  <Card title="广告创意">
    广告团队测试不同的广告文案、图片、标题和着陆页。广告级A/B测试优化客户获取成本。
  </Card>
</CardGroup>

## 经典案例

微软的必应搜索引擎提供了大规模A/B测试的典范例子。2009年至2015年间，必应团队在任何时候都运行200多个并发A/B测试，测试从结果页面布局到算法调整的一切。一个特别值得注意的测试涉及更改默认搜索设置以包含更多样化的结果。测试显示，虽然用户满意度提高了，但这最初并没有转化为收入增加。然而，团队发现这一更改有助于训练他们的算法，带来长期改善，最终将年收入提高超过12%——这表明即使初始结果看起来是负面的，运行实验也有价值。

## 边界与失效场景

A/B测试有重要的局限性，从业者必须理解。首先，A/B测试只能比较小的、渐进的变化；测试激进的设计重新思考很困难，因为用户经常对新界面反应消极，即使新设计客观上更好。其次，测试需要大量流量——测试微妙的变化或小改进通常需要数百万用户才能达到统计显著性。

另一个关键的失败模式是"窥视"——在测试达到适当样本量之前反复检查结果，并在结果看起来有希望时提前停止。这显著增加了误报率。此外，短期结果通常无法捕捉长期效果，如品牌建设或客户终身价值。最后，A/B测试无法解决基本的产品-市场匹配问题；再多的按钮颜色优化也无法挽救没人想要的产品。

## 常见误区

<AccordionGroup>
  <Accordion title="统计显著性保证获胜结果">
    统计显著性只告诉你差异可能是真实的，而不是它在实践中是否重要。统计显著性的0.1%改善可能不足以证明实施成本是合理的。
  </Accordion>

  <Accordion title="更多测试总是更好">
    运行太多并发测试会造成干扰效应，一个测试中的用户会受到另一个测试的影响。质量和学习比数量更重要。
  </Accordion>

  <Accordion title="A/B测试消除了产品直觉的需要">
    A/B测试告诉你什么有效，但不是为什么。需要良好的产品判断来生成值得测试的假设并正确解释结果。
  </Accordion>
</AccordionGroup>

## 相关概念

<CardGroup cols={3}>
  <Card title="假设驱动思考">
    将假设结构化为可测试的预测。A/B测试是测试产品假设的执行方法。
  </Card>

  <Card title="科学方法">
    测试假设的系统方法。A/B测试将科学方法应用于产品决策。
  </Card>

  <Card title="PDCA循环">
    计划-执行-检查-行动为迭代测试和学习提供了框架。A/B测试体现了"检查"阶段。
  </Card>

  <Card title="精益方法论">
    构建增量测试以最小化浪费。A/B测试通过在全面实施之前验证假设来支持精益产品开发。
  </Card>

  <Card title="OKR">
    目标和关键结果通常包括可以通过A/B实验测试的指标。OKR提供目标；A/B测试提供衡量。
  </Card>

  <Card title="KPI">
    关键绩效指标是A/B测试衡量的指标。好的KPI对于有意义的测试至关重要。
  </Card>
</CardGroup>

## 一句话总结

<Tip>
  相信数据而不是直觉——A/B测试为哪些更改实际上改善了用户结果和业务指标提供了统计有效的证据。
</Tip>