发布机制-A/B 测试：百科

ylbtech-发布机制-A/B 测试：百科

AB测试是为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。

1.返回顶部

1、

中文名：A/B测试
外文名：A/B Testing

别名：分组测试，分桶测试
英文名：Split Testing, Bucketing Tests

实施作用

A/B测试的作用

消除客户体验（UX） 设计中不同意见的纷争，根据实际效果确定最佳方案；
通过对比试验，找到问题的真正原因，提高 产品设计和运营水平；
建立数据驱动、持续不断优化的 闭环过程；
通过A/B测试，降低新产品或新特性的发布风险， 为产品创新提供保障。

A/B测试与一般工程测试的区别

A/B测试，用于 验证用户体验、市场推广等 是否正确，而一般的工程测试主要用于 验证软硬件是否符合设计预期，因此AB测试与 一般的工程测试分属于不同的领域。

应用场景

1、体验优化

用户体验 永远是卖家最关心的事情之一，但 随意改动已经完善的落地页是一件 很冒险的事情，因此很多卖家会通过AB测试进行决策。常见的是在保证其他条件一致的情况下，针对某一单一的元素进行AB两个版本的设计，并进行测试和数据收集，最终选定数据结果更好的版本。

2、转化率优化

通常影响电商销售转化率的因素有 产品标题、描述、图片、表单、定价等，通过测试这些相关因素的影响，不仅可以 直接提高销售转化率，长期进行也能 提高用户体验。

3、广告优化

广告优化可能是AB测试最常见的应用场景了，同时结果也是最直接的，营销人员可以通过AB测试的方法了 解哪个版本的广告更受用户的青睐， 哪些步骤怎么做才能更吸引用户。

实施步骤

1.现状分析：分析业务数据，确定当前最关键的改进点。

2.假设建立：根据现状分析作出优化改进的假设，提出优化建议。

3.设定目标：设置主要目标，用来衡量各优化版本的优劣；设置辅助目标，用来评估优化版本对其他方面的影响。

4.界面设计：制作2（或多）个优化版本的设计原型。

5.技术实现：

网站、App(Android/iOS) 、微信小程序和服务器端需要添加各类A/B测试平台提供的SDK代码，然后制作各个优化版本。
Web平台、Android和iOS APP需要添加各类A/B测试平台提供的SDK代码，然后通过编辑器制作各个优化版本。
通过编辑器设置目标，如果编辑器不能实现，则需要手工编写代码。
使用各类A/B测试平台分配流量。初始阶段，优化方案的流量设置可以较小，根据情况逐渐增加流量。

6.采集数据：通过各大平台自身的数据收集系统自动采集数据。

7.分析A/B测试结果：统计显著性达到95%或以上并且维持一段时间，实验可以结束；如果在95%以下，则可能需要延长测试时间；如果很长时间统计显著性不能达到95%甚至90%，则需要决定是否中止试验。

实施关键

A/B测试实施的关键问题

在App和Web开发阶段，程序中添加用于制作A/B版本和采集数据的代码由此引起的开发和QA的工作量很大，ROI（return on investment）很低。AB测试的场景受到限制，App和Web发布后，无法再增加和更改AB测试场景。额外的A/B测试代码，增加了App和Web后期维护成本。因此，提高效率是A/B测试领域的一个关键问题。

如何高效实施A/B测试？

在App和Web上线后，通过可视化编辑器制作A/B测试版本、设置采集指标，即时发布AB测试版本。

AB测试的场景数量是无限的；
在App和Web发布上线后，根据实际情况，设计AB测试场景，更有针对性，更有效；
无需增加额外的AB测试代码，对App和Web的开发、QA和维护的影响最小。

实用经验

1.从简单开始：可以先在Web前端上开始实施。Web前端可以比较容易的通过可视化编辑器制作多个版本和设置目标（指标），因此实施A/B测试的 工作量比较小，难度比较低。在Web前端获得经验后，再推广到App和服务器端。

2.隔离变量：为了让测试结果有用，应该每个试验只测一个变量（变化）。如果一个试验测试多个变量（比如价格和颜色），就不知道是哪个变量对改进起了作用。

3. 尽可能频繁、快速进行A/B测试：要降低A/B测试的代价，避免为了A/B测试做很多代码修改，尽量将A/B测试与产品的工程发布解耦，尽量不占用太多工程部门（程序员、QA等）的工作量。

4. 要有一个“停止开关”：不是每个A/B测试都会得到正向的结果，有些试验可能失败，要确保有一个“开关”能够停止失败的试验，而不是让工程部门发布一个新版本。

5.检查纵向影响： 夸大虚假的CTA(Call To Action)可以使某个A/B测试的结果正向，但长期来看，客户留存和销售额将会下降。因此，时刻要清楚我们追求的是什么，事先就要注意到可能会受到负面影响的指标。

6. 先“特区”再推广：先在一两个产品上尝试，获得经验后，推广到其他产品中。

2、

3.返回顶部

1、

3.2 A/B 测试

A/B 测试附录 7.10原来主要用于产品功能的比对测试，收集用户反馈和对比数据做产品功能设计的决策。实际上，A/B 测试也可以作为一种新功能发布技术。下图展示基于 LB 实现的一种 A/B 测试发布。

600

实践要点

上图中，原来 PC 端和手机端都访问老版本 V1 服务（也称 A 组或控制组），当 V2 新版本（也称 B 组或实验组）发布以后，为了验证 V2 的功能正确性，同时也为了避免 V2 有问题时影响所有用户，先通过 LB 将手机端的流量切换到 V2 版本，经过一段时间的 A/B 比对测试和观察（主要通过用户和监控反馈），确保 V2 正常，则通过 LB 将全部流量切换到 V2。
基于 LB 方式实现 A/B 测试，LB 需要能够通过某种条件做流量路由，例如通过 client ip，设备类型，浏览器类型，甚至是定制的 HTTP Header 或查询字符串。
高级的 A/B 测试需要专门的平台支撑，wasabi附录 6.6就是 intuit 开源的一个支持高级 A/B 测试的平台，这类平台可以细粒度到针对某类用户做 A/B 测试，例如针对某个地区的用户，某个年龄段的用户，公司内部用户等等。举了例子，假设一个关键业务的新功能上线，为了降低风险采用 A/B 测试，可以做到先只让公司内部员工能访问到新功能，待新功能验证过，再全量放开给外部用户使用。
功能开关和 A/B 测试有点相似，但功能开关一般是无状态和全量的，无法做到针对某类特定用户进行测试，而 A/B 测试一般是有状态的，能够跟踪事务和用户级别的状态，可以实现针对某类特定用户进行测试。