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根据实验分组展示不同界面、运行不同业务逻辑，你有没有比较好的设计方案或者技术架构，可以更灵活、对应用更少侵入地实现这一功能？
欢迎你点击“请朋友读”，把今天的文章分享给好友。也欢迎你写下自己的思考或疑问，与我和其他同学一起讨论。
- Linton 👍（49） 💬（2）
为什么讲大数据的课程，会说到A/B测试去
2019-01-16 - yang 👍（14） 💬（2）
除了AB实验，还可以提出AA实验，ABC实验的概念 AA实验可以理解成：实验的配置相同，但划分到不同的用户群体 ABC实验可以理解成: 一个实验的多组不同配置而非两组不同配置分别下发到不同群体
2019-01-15 - null 👍（4） 💬（1）
请问老师，如果AB测试，涉及到调整了数据结构，或者业务逻辑较大改动，是否还有用呢？比如统计中需要全量数据，AB测试分成两个不同表来存。暂时考虑的是冗余存储比调整报表逻辑好，但是不知道是否会影响到AB测试的结果，毕竟有一部分是多做了近一倍的事，性能、用户感受这些指标结果可能又不准确。
2019-01-16 - hxppk 👍（2） 💬（1）
abtest 流量分配环节，如何做到百分比流量分桶，同时也做到用某些event条件等划分流量，让流量高效利用？两种划分逻辑如何共存？
2019-01-18 - 小老鼠 👍（0） 💬（1）
AB测试用户喜不喜欢是如何获得的？
2019-01-22 - yang 👍（2） 💬（0）
看带着过了一遍，我现在觉得AB实验还是很有意思的。 用户请求AB实验成功后，AB后台会下发一组配置给该用户，用户的App会将这组配置作为参数加载进来， 并在下一次请求前，不会改变APP的界面和效果，直到下一次这些AB实验的参数发生改变。
2019-01-15 - 毛毛 👍（2） 💬（0）
AB测试的逻辑偏复杂、需求也是花样百出，对于SDK，每做一个功能，逻辑设计就要将近一周，代码开发两天。像flurry友盟等单纯数据收集的SDK，很长时间都不会发版。 请问老师，怎么把AB测试的SDK内部逻辑做的比较灵活，目的是适用业务需求变化，还不用频繁发版。
2019-01-15 - Sic Pavis 👍（1） 💬（0）
我的经历一般在后端做ab测试的区分逻辑，前端如果有不同页面之类的展示方式通过后端下发不同的配置文件实现。 好处是后端比前端容易控制版本，前端如果是app的话，你发新版本需要用户更新才行，即使强更，要等待全量用户更新也需要长尾的时间。
2021-12-30 - 乃鱼同学 👍（1） 💬（0）
大规模随机对照实验，技术名词眼花缭乱，如果你真的了解技术出现的过程和原因。顺藤摸瓜。你会来到计算机科学的基石：数学。
2020-07-22 - hallo128 👍（1） 💬（0）
AB测试的核心原理是很简单的，就是统计学中2个总体的比较问题。 难度在于整个系统的自动化搭建，从如何抽样，如何安排试验，但最后数据的传递返回处理。最后才对已有数据进行统计检验。 不过从这个系统涉及到的统计知识会有：试验设计（是否为正交在此阶段考虑），调查抽样，假设检验。 现在的数据分析，既需要有扎实的理论基础，也需要有较强的编程实现能力。
2019-01-29 - 强哥 👍（1） 💬（0）
AB test总体分为三大部分，实验方法，指标计算，效果评估，整体流程还要结合公司的业务，例如流量的划分，指标体系的建设等。APP端一般都是通过sdk进行埋点数据。然后进行etl。
2019-01-15 - (Kelen) 👍（0） 💬（0）
推送系统定点推送一批配置到设备，sdk读取配置进行对应的测试，然后上报打点情况。如果有问题，可以随时再发配置，回滚。
2020-02-22 - 不渡 👍（0） 💬（0）
受益匪浅
2020-02-20 - 钱 👍（0） 💬（0）
阅过留痕 A/B测试公司内肯定搞过，不过我们组貌似没有，我们比较喜欢用以下两种方式： 1：黑白名单，比如用户黑白名单，仓库黑白名单，四级地址黑白名单 2：线上流量倒流到验证系统，然后做对比分析
2020-02-11 - 魂斗罗丶 👍（0） 💬（0）
这不就是中学学的控制变量法的一个应用吗，哈哈哈
2019-09-21