A/B测试与灰度发布

产品设计中，经常会遇到哪种产品设计方案更优：按钮大点还是小点好；页面复杂点好还是简单点好；这种蓝色还是另一种蓝好；新推荐算法是不是效果真好…这种讨论会出现在运营人员和产品经理之间，也会出现在产品经理和工程师之间，有时候甚至会出现在公司最高层，成为公司生死存亡的战略决策。

A/B测试是大型互联网应用的常用手段。如说设计主观，那数据是客观的，与其争执哪种设计更好、哪种方案更受用户欢迎，不如通过A/B测试让数据说话。所以A/B测试是更精细化的数据运营手段，通过A/B测试实现数据驱动运营，驱动产品设计，是大数据从幕后走到台前的重要一步。

A/B测试过程

A/B测试将每一次测试当作一个实验。通过A/B测试系统的配置，将用户随机分成两组（或者多组），每组用户访问不同版本的页面或者执行不同的处理逻辑，即运行实验。通常将原来产品特性当作一组，即原始组；新开发的产品特性当作另一组，即测试组。

经过一段时间（几天甚至几周）以后，对A/B测试实验进行分析，观察两组用户的数据指标，使用新特性的测试组是否好于作为对比的原始组：

• 效果好，那这个新开发特性就会在下次产品发布的时候正式发布出去，供所有用户使用
• 效果不好，这个特性就会被放弃，实验结束

大型网站通常都会开发很多新产品特性，很多特性需A/B测试，所以在进行流量分配的时候，每个特性只会分配到比较小的一个流量进行测试，如1%。但大型网站总用户量大，即使1%用户，实验数据也具代表性。

A/B测试系统架构

最重要的是能根据用户ID（或者设备ID）将实验配置参数分发给应用程序，应用程序根据配置参数决定给用户展示的界面和执行的业务逻辑：

在实验管理模块里进行用户分组，比如测试组、原始组，并指定每个分组用户占总用户的百分比；流量分配模块根据某种Hash算法将用户（设备）分配到某个实验组中；一个实验可以有多个参数，每个组有不同的参数值。

移动App在启动后，定时和A/B测试系统通信，根据自身用户ID或者设备ID获取自己参与的A/B测试实验的配置项，根据配置项执行不同的代码，体验不同的应用特性。应用服务器和A/B测试系统在同一个数据中心，获取实验配置的方式可以更灵活。

移动App和应用服务器上报实验数据其实就是传统的数据采集，但是在有A/B测试的情况下，数据采集上报的时候需要将A/B测试实验ID和分组ID也上报，然后在数据分析时，才能够将同一个实验的不同分组数据分别统计，得到A/B测试的实验数据报告。

灰度发布

经过A/B测试验证过的功能特性，就可以发布到正式的产品版本中，向所有用户开放。但是有时候在A/B测试中表现不错的特性，正式版本发布后效果却不好。此外，A/B测试的时候，每个功能都应该是独立（正交）的，正式发布的时候，所有的特性都会在同一个版本中一起发布，这些特性之间可能会有某种冲突，导致发布后的数据不理想。

解决这些问题的手段就是灰度发布：不一次性将新版本发布给全部用户，而是一批批逐渐发布给用户。过程中，监控产品的各项数据指标，看是否符合预期，若数据表现不理想，就停止灰度发布，甚至灰度回滚，让所有用户都恢复到以前版本。

灰度发布系统可用A/B测试系统来承担，创建一个名叫灰度发布的实验即可，这个实验包含这次要发布的所有特性的参数，然后逐步增加测试组的用户数量，直到占比达到总用户量的100%，即为灰度发布完成。

灰度发布的过程也叫灰度放量，灰度放量是一种谨慎的产品运营手段。对于Android移动App产品而言，因为国内存在很多个应用下载市场，所以即使没有A/B测试系统，也可以利用应用市场实现灰度发布。即在发布产品新版本的时候，不是一次在所有应用市场同时发布，而是有选择地逐个市场发布。每发布一批市场，观察几天数据指标，如果没有问题，继续发布下一批市场。

总结

A/B测试的目的依然是为了数据分析，因此通常被当作大数据平台的一个部分，由大数据平台团队主导，联合业务开发团队和大数据分析团队合作开发A/B测试系统。A/B测试系统囊括了前端业务埋点、后端数据采集与存储、大数据计算与分析、后台运营管理、运维发布管理等一个互联网企业几乎全部的技术业务体系，因此开发A/B测试系统有一定难度。

大数据生态体系包括Hadoop这样的大数据产品，还包括大数据平台、大数据分析、大数据机器学习，这才是一个大数据技术体系的完整知识框架。

如果AB测试，涉及到调整了数据结构或业务逻辑较大改动，是否还有用？比如统计中需要全量数据，AB测试分成两个不同表来存。暂时考虑的是冗余存储比调整报表逻辑好，但是不知道是否会影响到AB测试的结果，毕竟有一部分是多做了近一倍的事，性能、用户感受这些指标结果可能又不准确。

A/B测试可理解成在原来的打点基础上增加了实验ID、分组ID，数据存储和结构跟原来一样，SQL统计的时候根据ID分别统计，就得到各个实验分组的PV转化率这些指标。

AB测试的逻辑偏复杂、需求也是花样百出，对于SDK，每做一个功能，逻辑设计就要将近一周，代码开发两天。像flurry友盟等单纯数据收集的SDK，很长时间都不会发版。

怎么把AB测试的SDK内部逻辑做的比较灵活，目的是适用业务需求变化，还不用频繁发版。

AB test总体分为：实验方法，指标计算，效果评估，整体流程还要结合公司的业务，例如流量划分，指标体系建设等。APP端一般都是通过sdk进行埋点数据。然后进行etl。

AB测试用户喜不喜欢是如何获得的？pv uv 留存各种数据指标下降了，就是不喜欢。

abtest流量划分需要尽量随机，保证实验结果客观，不应该有太多的划分方式。

用户请求AB实验成功后，AB后台会下发一组配置给该用户，用户的App会将这组配置作为参数加载进来，并在下一次请求前，不会改变APP的界面和效果，直到下一次这些AB实验的参数发生改变。