A/B测试背后的工程问题: 只懂统计是不够的
在科技行业工作两年后，我被同行发的一条Tweet触动：“想象一下，如果在生活中你不能在量化行动的结果前采取任何行动，这会是种什么样的体验？这简直是目前科技行业中的一种病态氛围。” 这条推特相当准确地总结了我至少一半的A/B测试经验，也促使我写下今天这篇文章。
A/B测试的理念
A/B测试也称多变量测试， 是一种比较同一功能或同一页面的不同版本，并比较这些版本的统计指标，看哪个版本表现更好的机制。理想情况下，A/B测试能够推动数据驱动的决策，并使快速反馈和持续改进成为可能。科技圈最经典的案例是：谷歌测试过40种蓝色色调，为了了解哪种蓝色使用户转化最多。
从比较宏观的角度来说，A/B测试机制是这样运行的（或者说，应该是这样运行的）：
首先，我们有一个关于用户行为的假设（通常是基于心理学理论，比如害怕错过的心理）。为了验证这个假设，我们会设计一个实验，在这个实验中，我们会测试当前的版本和一个或多个想要测试的版本。在测试开始之前，我们需要决定评估实验的指标。
用户访问网站或应用程序，特别是正在测试的功能。
然后，用户们被分配到正在测试的实验的某一个变体中（控制组或实验组）。用户被分配到哪一组就决定了他们将看到和使用的是实验的哪个版本。每一个人在实验过程中只会看到一个版本。
我们记录用户的行为，并将其存储以进行统计分析。通常情况实验至少持续一周或更长时间。完成测试后，我们将对结果进行分析，并且在大多数情况下，将向所有用户推广该实验效果最好的版本。
A/B测试的设置
假设你现在要实施A / B测试，你需要些什么？
A/A测试在实际工作中有什么用？
以下是你在任何测试方案中都可能用到的一些关键特征：
分组（Bucketing）：用户需要被分配到不同的组中。它的核心内容是Math.random（）> 0.5。通常情况下，分配比重为50/50（也就是在变体之间平均分配）。但是如果你进行的实验风险更高，则可能需要执行例如80/10/10的分配。你还可以使用受众群体定位或环境定位来确定用户是否有资格参加实验。
远程配置（Remote configuration）:它有助于使用与代码无关的配置来开始和结束实验。在大多数情况下，部署应用程序的新版本是一个繁琐的过程，而且管理实验的人员往往不是工程师本身。理想的情况是，产品经理或营销人员可以通过一个对他们来说比推出一个新版本更友好的方法来管理配置。至少，你需要管理你们启用了哪些实验以及实验开始和结束的日期或目标。
追踪（Tracking）：在测试中，你还需要获取有关用户行为的数据，以便评估哪种版本效果更好。用户在页面上花费了多少时间？他们会转化到销售漏斗的下一步吗？他们将多少商品添加到购物车中？你需要追踪、记录并保存这些用户行为数据。
分析（Analysis）：实验结束后，有了这些数据就需要分析结果。比如一些基本数据：版本B或C中有多少用户？他们是如何根据你选择的指标来执行的？检验的统计意义是什么？可能你也想按设备类型或受众群体数据进行细分，那你可以从数据库中导入统计信息并使用基本的Excel工作表，也可以使用例如Google Analytics之类的工具来查询序列，这对于分析用户行为非常有用。
可视化编辑器（Visual editors）：像Optimizely这样的工具提供了可视化编辑器，能让你按自己的方式来设计一个新的实验。如果你不能直接接触到一个engineer团队，可视化编辑器将会非常有用；但如果你能接触到的话，很可能还有更好的选择。
A/B测试的实施方法
在我有限的认知里，至少有五种实现A/B测试的方法:
金丝雀发布(Canary Releases)：如果你想要测试网站的变化，则可以为每个要测试的变化部署一个新版本，然后将部分用户分流到新版本。要这么做的话，你必须拥有一个管理良好的基础架构和发布工作流，尤其是当你要并行运行多个测试、需要许多不同的部署以及复杂的用户分流时。此外，你可能还需要大量的流量。不过好处似乎是很明显的， 一是任何失败的实验都不会带来技术上的负担（代码永远不会落在主数据库上，部署只会被删除）；二是这强制用户一次只能进行一个实验，因为多次实验会同时带来技术挑战和实验相互影响的不确定性。
分割网址（Split URLs）: 这是Google历来推荐使用，以防止SEO问题的方法。你可以使用URL将用户分流到不同的实验。例如：/amazing-feature/test-123/b。这种方法的好处是，在尝试不同的设计时，不会对域中给定URL所具有的任何SEO值产生负面影响。
服务器端（Server-side）:当页面被请求时，用户在服务器上受到限制。然后你可以设置一个Cookie来确保用户被“卡在”某个分组中，并使用它来呈现用户正在进行的任何实验的界面。你可以做任何你想做的事情：A/B测试、多元测试、特性切换和并行实验等等。对于用户来说，这也是最好的选择之一，因为它带来的性能影响可以被忽略不计。然而，由于你使用了Cookie， CDN的好处就会被限制。当Cookie引入了请求的变化(特别是当用户可以进入多个实验时)，它将导致缓存丢失，使你没有CDN的保护。
客户端（Client-side）：如果你不能访问服务器，或者你想拥有最大的灵活性，那么对你来说客户端A/B测试也是一个不错的选项。在这种情况下，要么不呈现任何界面，要么呈现原始界面。一旦测试被激活，界面会立即根据用户所处的版本变化。当你没有engineer团队，并且正在使用外部工具运行测试时，这种选择通常是行之有效的。然而就性能而言，这却常常是最糟糕的选择。这里举个例子，让我们看看如何优化地实现客户端A/B测试：首先你要嵌入一个阻塞脚本，它将迫使浏览器在屏幕上不能显示任何内容，直到该脚本被下载、编译和执行。此外，浏览器将降低所有其他资源的优先级(可能你需要先逐步增强您的网站)，从而尽快加载阻塞脚本。最重要的是，如果你不自行托管脚本的话，浏览器都必须预连接到另一个源，并且只能缓存几分钟（如果你想尽快关掉conversion-destroying测试的话)。在对移动连接的综合测试中，我看到过最优的延迟关键事件时间在1-2秒之间。建议小心使用！
缓存（On the edge）:如果你的网站配备了CDN（内容交付网络），你可以使用edge workers来运行测试。它的要点是你的服务器显示了界面的所有版本、你的CDN缓存了这个响应，然后当用户加载网站时，当edge workers删除不适用的HTML的用户请求后，缓存会被响应。如果你很在乎性能的话，这是一种非常有潜力的方法，因为它使你既可以获得CDN的好处，又不让浏览器的性能受到任何影响。
现实中的A/B测试
然而事实证明，A/B测试很难。它也许非常有价值，但我认为你应该根据你的底线来衡量它。A/B测试并没有那么万能，你一定要根据你现在的公司类型来调整测试的方法。
以下是我在一家每天拥有大约5 - 10万用户的中型公司学到的:
1. 尽可能的独立实验
在我目前的公司里，我们正在同时进行多个实验，新版本总是在经过验证后立即投入生产。这主要是由于我们的技术选择。除此之外，由于流量不足，我们无法负担让每个平台上每个用户只进行一次实验。因此会导致实验产生副作用，出现如下两个问题：
首先，同时执行的实验使得端到端测试范围的任何合理预期都不可能实现：即使是10个A/B测试这样的少量测试也会创建100个应用变体。为了测试所有这些不同的变体，我们的测试将花费250小时而不是15分钟。因此，我们在测试期间禁用了所有的实验。这意味着，任何实验都可以——而且最终将——破坏关键(和非关键)的用户功能。此外，除了我前面提到的缓存问题之外，它还使debug的过程变得异常艰辛。
其次，在用户的整个体验过程中运行多个实验将导致测试结果的不确定性。假设你在产品页面和搜索页面上各进行了一项实验， 如果搜索实验对发送到产品页面的访问量类型有很大影响，那么该产品实验的结果将出现偏差。
我能想到的最好的独立实验策略是Canary Releases和特性分支。在我认为的理想状态下它是这样工作的：当你开始一个实验，你创建一个将包含变体的分支。你提交了一个拉取请求，并部署了带有该变化的测试环境。一旦通过审核，便将其部署进行应用，并更新路由器配置以将一定量的流量发送到要测试的变体。你必须查看预期的使用率、一般流量和预期的测试持续时间，来确定哪种流量划分是合理的。假设你估计一周有20％的流量就足够了，那么通常会排除80％的流量进行测试，然后将其余20％的流量平均分配给运行网站当前版本， 以及正在运行的该实验变体的版本。
我可以想象要协调这些需要大量的编程工作，尤其是当你想要自动开始和结束实验或者想要使用更高级的定位时。你必须拥有足够的流量，这样你才能看到将网站拆分为较小的可部署单元的好处。如果你无法正确实施独立实验，不妨尝试接受这样的事实：并非生活中的所有问题都可以或应该被解决。
但如果你更像是控制狂（就像我一样），则可能需要考虑互斥的实验——这意味着处于实验X的用户不能同时处于实验Y。互斥实验有利于消除行为方面的副作用。如果你需要更多的测试可信度，则可以选择接受较低级别的测试，例如单元或组件测试。
2. 坚持高标准
关于A/B测试有一个经常被重复的咒语：“它只是一个测试，我们稍后会修复它”。人们说这句话时的想法是，先构建一个MVP并衡量兴趣，有兴趣的话就构建一个设计更好、实现更好的版本作为最终版本。但在实践中，我还没有看到过这种情况出现，原因大概有两点：第一，在产品发布后，修复问题的动力就消失了。这适用于所有方面：工程、设计和产品。当更新已经被证明是一种提升后，花费时间重新设计或重构会让人觉得没有必要。第二，重新实施一个实验，甚至重新设计它，可能会对之前假设的提升产生影响。当你需要运行另一个实验时，你需要使用现有的、新发布的产品来实现。这就是问题所在：因为现有的环境不太可能分配时间来重构或重新运行成功的实验。
那么接下来会发生什么呢？答案是你积累了技术债务。这些债务通常没有明确的范围和定量的描述，而且很难用数字来衡量，也很难提出解决的理由。技术债务会逐渐增加，直到最后，每个人都选择放弃。
不同的标准不仅不明智，反而令人困惑。让工程师们遵循一个标准就够难的了，还要遵循两个？这是不可能的。做好准备，你也许也会经历在代码审查中无休止地来回折腾的过程。
回到那条推特
它包含了一个有力的事实：数据，或者对数据的要求，往往会导致惰性。数据并不能解决所有问题。它不能取代一种愿景，它也不是一种战略。
我们最好是定义一个愿景，然后使用A/B测试来验证实现该愿景的进展，而不是反过来。
由于“A / B测试”非常有价值却很难实施，因此花时间进行适当规划以最大化它的影响显得尤为重要。如果你想要正确地花费时间在设计、实施和评估实验上，想要做到能够根据公司类型因地制宜地调整A/B测试的方法，更重要的是，帮助自己在职业生涯中实现真正的飞跃式成长，那么一定不要错过MarTechApe的《A/B测试企业级实战训练营》！让学员在两个月的时间里，使用百万量级原始数据，搭建完整的A/B测试流程。
在过去开办的两期《训练营》中，我们为顶尖科技公司输送数据能力强、实验经验丰富、统计基础扎实的数据人才。不论你本来是什么背景，都能通过这门课程，打开盛行“测试文化”的互联网高科技公司的大门！
点击下方图片了解项目详情
你将获得：
真枪实弹的A/B测试项目实操，百万量级真实数据+五大应用案例，从零学会A/B测试的里里外外！
为你建立一个完整的、专业的、深度还原大公司的的A/B测试项目，让你在面试时可以自信展示自己亲自做的案例，成功拿下offer！
从0到100真实操作A/B测试项目的全套流程：数据清洗、数据自动化处理、实验设计、实验执行、结果分析、报告展示。
经历真实工作场景中的、各大互联网科技公司里使用的A/B测试流程，以及适应不同商业场景的各类实验/准实验方法。学会工作中最重要的分析方法！
深度学习A/B测试实战中常见的测试陷阱及避免方法。
牢固掌握公司里A/B测试项目中的实际SQL与Python应用，为A/B测试搭建数据库、清理数据、创建数据集。
学会用Python自动化实现A/B测试，为你的老板提高100%的工作效率！
接受系统的统计训练，打下坚实牢固的统计基础，彻底明白A/B测试的统计原理、分析方法、实验设计方法、抽样准则。
各大互联网、科技公司A/B testing面试题解题步骤示范与详细解析。对互联网科技公司的深度剖析和指标介绍，让你自如面对各类面试考验！
专业的Bootcamp经历简历模版与认证证书，可以晒到LinkedIn等求职网站，大大提高面试邀请率！
福利升级：训练营以往只内推成功从训练营中毕业的学生。但在疫情期间，所有A/B测试实战训练营学员，均可获得全职或实习岗位的内推机会！
以下为往期学员的战绩榜：
《A/B Testing Bootcamp》往期学员拿到的面试机会以及全职工作OFFER包括Facebook、Amazon、TikTok、Viagogo、GSK、Walmart、Pinterest、Chegg、Wish、Twitch、Plymouth Rock、Nintendo等互联网科技公司。
现在，MarTechApe《A/B测试企业级实战训练营》第3期正在火热报名中！
每一期训练营，我们只招收20名学生。先到先得，遵循阶梯价位，优惠逐额递减，越早报名越优惠！
长按下方二维码，添加小助手为好友，回复“AB”，即可报名《A/B测试实战训练营》：
小助手（微信ID：yvonne91_wsn）
