|
|
# 34 | A/B测试与灰度发布必知必会
|
|
|
|
|
|
在网站和App的产品设计中，经常会遇到关于哪种产品设计方案更优的思考和讨论：按钮大一点好还是小一点好；页面复杂一点好还是简单一点好；这种蓝色好还是另一种蓝色好；新的推荐算法是不是真的效果好…这种讨论会出现在运营人员和产品经理之间，也会出现在产品经理和工程师之间，有时候甚至会出现在公司最高层，成为公司生死存亡的战略决策。
|
|
|
|
|
|
在Facebook的发展历史上，曾经多次试图对首页进行重大改版，甚至有时候是扎克伯格亲自发起的改版方案，但是最终所有的重大改版方案都被放弃了，多年来Facebook基本保持了一贯的首页布局和风格。
|
|
|
|
|
|
相对应的是，一直被认为抄袭Facebook的人人网在Facebook多次改版举棋不定的时候，毅然进行了重大的首页改版，摆脱了长期被诟病的抄袭指责。但是讽刺的是，事后回头再看，伴随着人人网改版的是用户的快速流失，并最后导致了人人网的没落，而Facebook的守旧却保证了Facebook的持续发展。
|
|
|
|
|
|
让Facebook放弃改版决定的，正是Facebook的A/B测试。Facebook开发出新的首页布局版本后，并没有立即向所有用户发布，而是随机选择了向大约1%的用户发布，即这1%的用户看到的首页是新版首页，而其他用户看到的还是原来的首页。过一段时间后观察两部分用户的数据指标，看新版本的数据指标是否好于旧版本。
|
|
|
|
|
|
事实上Facebook观察到的结果可不乐观，新版本的用户数据指标呈下跌状态。扎克伯格不甘心，要求继续放大新版测试用户的比例，运营团队一度将新版测试用户的比例放大到16%，但是数据显示新版并不受用户欢迎，数据指标很糟糕。最后扎克伯格决定放弃新版，首页维持原来布局。
|
|
|
|
|
|
A/B测试是大型互联网应用的常用手段。如果说设计是主观的，那么数据是客观的，与其争执哪种设计更好、哪种方案更受用户欢迎，不如通过A/B测试让数据说话。如果人人网当初认真做A/B测试，也许不会贸然改版；据说今日头条为了论证两条新闻之间的分割究竟应该用多宽的距离，同样是做了数百组A/B测试。
|
|
|
|
|
|
所以A/B测试是更精细化的数据运营手段，通过A/B测试实现数据驱动运营，驱动产品设计，是大数据从幕后走到台前的重要一步。
|
|
|
|
|
|
## A/B测试的过程
|
|
|
|
|
|
A/B测试将每一次测试当作一个实验。通过A/B测试系统的配置，将用户随机分成两组（或者多组），每组用户访问不同版本的页面或者执行不同的处理逻辑，即运行实验。通常将原来产品特性当作一组，即原始组；新开发的产品特性当作另一组，即测试组。
|
|
|
|
|
|
经过一段时间（几天甚至几周）以后，对A/B测试实验进行分析，观察两组用户的数据指标，使用新特性的测试组是否好于作为对比的原始组，如果效果比较好，那么这个新开发的特性就会在下次产品发布的时候正式发布出去，供所有用户使用；如果效果不好，这个特性就会被放弃，实验结束。
|
|
|
|
|
|
|
|
|
|
|
|
对于一个大型网站，通常都会开发很多新产品特性，其中很多特性需要进行A/B测试，所以在进行流量分配的时候，每个特性只会分配到比较小的一个流量进行测试，比如1%。但是由于大型网站总用户量比较大，即使是1%的用户，实验得到的数据也具有代表性了。Facebook拥有几十亿用户，如果A/B测试的新特性对用户不友好，那么即使只测试1%的用户，也有几千万用户受到影响。所以，在进行A/B测试时对实验流量和特性的选择也要谨慎对待。
|
|
|
|
|
|
## A/B测试的系统架构
|
|
|
|
|
|
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测试系统有一定难度。但是一个良好运行的A/B测试系统对企业的价值也是极大的，甚至可以支撑起整个公司的运营管理，我们下期会详细讨论。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
A/B测试需要在前端App根据实验分组展示不同界面、运行不同业务逻辑，你有没有比较好的设计方案或者技术架构，可以更灵活、对应用更少侵入地实现这一功能？
|
|
|
|
|
|
欢迎你点击“请朋友读”，把今天的文章分享给好友。也欢迎你写下自己的思考或疑问，与我和其他同学一起讨论。
|
|
|
|