简介
AB 测试是为 Web 或 App 界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。
灰度发布
又名金丝雀发布。是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。
分析
利弊
:::: tabs top-start
::: tab-pane 优势
有序列表消除客户体验（UX）设计中不同意见的纷争，根据实际效果确定最佳方案。
通过对比试验，找到问题的真正原因，提高产品设计和运营水平。
建立数据驱动、持续不断优化的闭环过程。
通过 A/B 测试，降低新产品或新特性的发布风险，为产品创新提供保障。
:::
::: tab-pane 劣势
A/B 测试可能需要很长时间。
大多数时候，选择什么方法都是基于你自己的考虑。
不能为了测试而测试，这一点至关重要。
不合理的 A/B 测试还会成为做好产品的绊脚石。
:::
::::
流程
:::: tabs top-start
::: tab-pane 流程
现状分析
分析业务数据，确定当前最关键的改进点。
假设建立
根据现状分析作出优化改进的假设，提出优化建议。
设定目标
设置主要目标，用来衡量各优化版本的优劣；设置辅助目标，用来评估优化版本对其他方面的影响。
界面设计
制作两（或多）个优化版本的设计原型。
技术实现：通过技术进行落地实施。
采集数据
通过各大平台自身的数据收集系统自动采集数据。
分析A/B测试结果
统计显著性达到 95% 或以上并且维持一段时间，实验可以结束；如果在 95% 以下，则可能需要延长测试时间；如果很长时间统计显著性不能达到 95% 甚至 90%，则需要决定是否中止试验。
:::
::: tab-pane 注意事项
从简单开始
可以先在 Web 前端上开始实施。Web 前端可以比较容易的通过可视化编辑器制作多个版本和设置目标（指标），因此实施A/B测试的工作量比较小，难度比较低。在 Web 前端获得经验后，再推广到 App 和服务器端。
隔离变量
为了让测试结果有用，应该每个试验只测一个变量（变化）。如果一个试验测试多个变量（比如价格和颜色），就不知道是哪个变量对改进起了作用。
尽可能频繁、快速进行 A/B 测试
要降低 A/B 测试的代价，避免为了 A/B 测试做很多代码修改，尽量将 A/B 测试与产品的工程发布解耦，尽量不占用太多工程部门（程序员、QA 等）的工作量。
要有一个“停止开关”
不是每个 A/B 测试都会得到正向的结果，有些试验可能失败，要确保有一个“开关”能够停止失败的试验，而不是让工程部门发布一个新版本。
检查纵向影响
夸大虚假的 CTA(Call To Action) 可以使某个 A/B 测试的结果正向，但长期来看，客户留存和销售额将会下降。因此，时刻要清楚我们追求的是什么，事先就要注意到可能会受到负面影响的指标。
先“特区”再推广
先在一两个产品上尝试，获得经验后，推广到其他产品中。
:::
::::
工具
AB Tester：AB 测试站工具。
云眼：AB 实验 + 灰度发布。
Optimizely：AB 测试站工具。
VWO：AB 测试站工具。