作者在《推荐系统评估》和《推荐系统的商业价值》这两篇文章中提到了AB测试的重要性，新的推荐算法在上线到现网时需要做AB测试，对比新算法和老算法在关键指标上的差异，只有当新算法明显优于老算法时才会完全取代老算法。其实，AB测试的价值不止体现在推荐系统中，它在整个互联网产品迭代周期中得到了广泛深入的应用。
本文试图对AB测试做一个比较全面的介绍，会从什么是AB测试、AB测试的价值、什么时候需要AB测试、AB测试的应用场景、AB测试平台核心模块、业界AB测试的架构实现方案、推荐系统业务AB测试实现方案、构建AB测试需要的资源及支持、构建AB测试需要关注的问题等9个方面来讲解AB测试技术。
希望本文能够帮助读者更好地理解AB测试的价值和应用场景，并结合本文提供的实现方案，可以在具体业务中快速落地AB测试技术，应用到真实业务场景中，真正用AB测试工具驱动公司业务增长。
一，什么是AB测试
AB测试的本质是分离式组间试验，也叫对照试验，在科研领域中已被广泛应用（它是药物测试的最高标准）。自2000年谷歌工程师将这一方法应用在互联网产品以来，AB测试越来越普及，已逐渐成为衡量互联网产品运营精细度的重要体现。
简单来说，AB测试在产品优化中的应用方法是：在产品正式迭代发版之前，为同一个目标制定两个（或以上）可行方案，将用户流量分成几组，在保证每组流量在控制特征不同而其他特征相同的前提下，让用户分别看到不同的方案设计，根据几组用户的真实数据反馈，科学地帮助产品进行决策(比如你想优化某个位置的文案颜色，觉得蓝色比红色好，就可以保持这个位置一组流量的文案红色，一组蓝色，其他都相同，进行AB测试)。AB测试原理如下面图1。
图1：AB测试原理
AB测试是一种科学的评估手段，具备概率统计学理论的支撑。这里我简单解释一下原因。 概率论中有一个中心极限定理，意思是独立同分布的随机变量的和服从正态分布。对于AB测试，我们比较的是两组样本的平均表现，AB测试保证AB两组某个因素不一样(这个就是我们要验证的优化点)，AB两组其他很多未知影响因素一样(这些因素是独立同分布的随机变量)，当AB两组样本足够多时，这些其他因素产生的效果是满足同一正态分布的，因此可以认为对要验证的变量的作用是相互抵消的，这样待验证因素(即我们的控制变量)的影响就可以比较了，因此我们就可以通过实验来验证优化是否有效。
像Google，Facebook，百度，阿里，微博，大众点评等互联网公司很早就采用AB测试框架来驱动业务发展，为公司创造价值。
业内也有很多提供AB测试SAAS服务的创业公司，通过定制化的AB测试方案来为其他公司提供AB测试能力，如吆喝科技(http://www.appadhoc.com/)，ABTester(http://www.abtester.cn/), 云眼(https://www.eyeofcloud.com/), Testin云测(http://ab.testin.cn/)等等。
讲完了什么是AB测试，我们知道AB测试可以驱动业务发展，那么AB测试的价值到底体现在哪些方面呢？这就是下节主要讲的内容。
二，AB测试的价值
最近几年增长黑客的理念在国内互联网盛行，有很多这方面的专业书出版，很多公司甚至设立了CGO(首席增长官)的高管职位。增长黑客思维希望通过从产品中找到创造性的优化点，利用数据来驱动产品优化，提升用户体验及收益增长，最终达到四两拨千斤的效果。随着公司业务规模及用户的增长，利用数据来驱动业务发展越来越重要。增长黑客本质上就是一种数据驱动的思维，并且有一套完善的技术管理体系来科学地驱动业务发展，而这套体系中最重要的一种技术手段就是AB测试。
AB测试可以很好的指导产品迭代，为产品迭代提供科学的数据支撑。 具体来说，AB测试的价值主要体现在如下四个方面。
1.为评估产品优化效果提供科学的证据
前面说过，AB测试是基于概率论与统计学原理之上构建的科学的测试技术，有很强的理论依据。
AB测试也经历过多年实践的检验，被证明是有效的方法。前面提到过AB测试是药物测试的最高标准，在药品制造业得到了很好的使用和验证。同时，各大互联网公司都大量使用AB测试技术，为整个互联网的发展提供了很好的榜样和示范作用。
2.借助AB测试可以提升决策的说服力
因为AB测试是有统计学作为理论基础，并且又有工业上的实践经验作为支撑，利用AB测试得到的结论具备极大的说服力。因此，在用数据说话上，大家在意识形态上更容易达成一致，这样就可以让产品迭代更好更快的推行下去。
3.AB测试可以帮助提升用户体验和用户增长
任何涉及到用户体验、用户增长相关的优化想法都可以通过AB测试来验证，通过验证得出有说服力的结论，从而推动产品朝着用户体验越来越优的方向发展。
4.AB测试可以帮助提升公司变现能力
搜索、推荐、广告、会员等涉及到收益相关的产品及算法都可以通过AB测试来验证新的优化思路是否可以提升盈利性指标。其中盈利性指标可以根据公司业务和发展阶段来定义。
总之，一切涉及到用户体验、用户增长、商业变现的产品优化都可以借助AB测试技术，驱动业务做得更好，AB测试是一种科学的决策方式。那我们在什么时候需要AB测试呢？
三，什么时候需要AB测试
如果你像乔布斯这么牛逼，可以深刻洞察用户的需求，甚至是创造用户需求，我觉得你可以不用AB测试，但是世界上只有一个乔布斯。所以，对于我们普通人来说，AB测试在产品迭代过程中还是必要的。那么是不是所有产品迭代或者优化都需要做AB测试呢？我觉得不一定，需要具体情况具体分析，我认为下面4点是需要利用AB测试来做决策的前置条件。
1.必须是有大量用户的产品或者功能点
如果你的产品只有很少的用户使用，比如一些政府部门的官网。由于用户少，分组后用户更少。根据上面AB测试的统计学解释(大量随机样本产生的影响的均值是正态分布，样本量小就不是，这时其他因素的影响就可能无法抵消，导致控制变量的比较就无意义)，根据很少的用户得出的结论是不具备统计学意义的。所以即使做了AB测试，得出的结论的有效性是无法用统计学原理支撑的，因此是不可信的。
同样的，某个产品虽然用户多，但是如果某个功能点只有很少用户用，这跟上面道理是一样的，是无法做出可信服的结论的。
同样的，某个优化太细(用户意识到这种改变的概率很小)，比如就看某个推荐位的颜色深浅是否对用户点击是否有影响，这时也需要大量的用户对这个位置的访问才可以得出比较有指导意义的结论。
2.进行AB测试的代价(金钱&时间)可以接受
如果做AB测试的代价太大，比如需要消耗大量的人力财力，这时做AB测试的产出可能小于付出, 这时做AB测试就是费力不讨好的事情了。
3.有服务质量提升诉求
如果某个业务或者功能点用户极少使用，并且也不是核心功能点，比如视频软件的调整亮度，这个是一个很小众的需求，只要功能具备就可以了，好用和不好用对用户体验影响不大，这时花大力气对它进行优化就是没必要的。
4.变量可以做比较好的精细控制
如果某个功能影响的变量太多，并且我们也无法知道哪个变量是主导变量，甚至都不知道有哪些变量对它有影响，这时就很难利用AB测试了。因为，AB测试需要调整一个变量同时控制其他变量不变。
如果上面4个条件都满足的话，我觉得这个功能点是可以做AB测试的。对于toC的互联网产品来说，其实上面几个条件是很容易满足的，所以在互联网公司有很多地方都可以通过AB测试来优化产品功能，那AB测试在互联网公司到底有哪些应用场景呢？
四，AB测试的应用场景
在互联网公司AB测试可以落地的场景是很多的，具体包括如下3大类：
1.算法类
各类算法是AB测试应用场景最多的地方，算法开发人员通过AB测试来验证一个新的算法或者小的算法优化是否可以提升算法的业务指标。包括推荐、搜索、精准广告、精细化运营等涉及到算法的产品和业务都是可以利用AB测试技术的。
2.运营类
任何一个互联网产品少不了运营，在互联网红利消失的当下，某个产品是否可以“占领”用户的心智，运营将起到越来越重要的作用，甚至有人说互联网时代将进入一个运营驱动的时代。各类运营手段，如用户运营(用户拉新、会员运营等)、内容运营(视频行业的节目编排等)、活动运营(抽奖等)等都可以借用AB测试技术来验证哪种运营策略是更加有效的。
3.UI展示及交互类
UI是任何一个互联网产品可直接被用户感知的部分，用户通过UI与互联网产品交互，用户对一个产品的感知也是首先通过UI建立的。简洁美观的UI界面，流畅的UI交互往往能够给用户留下好的第一印象。对于UI视觉及交互部分的优化，往往凭设计师的经验是不够的，需要利用技术手段来验证哪种UI展示风格、哪种交互方式是用户更喜欢的、能够带来最大收益的。
像颜色、字体、按钮形状、页面布局、操控方式的调整及优化都是可以通过AB测试来验证的。
现在我们知道了互联网产品哪些模块和功能是可以利用AB测试驱动做得越来越好的，那么大家一定想知道我们怎么构建一个高效易用的AB测试平台，并怎样通过该平台更好地支撑各类AB测试任务。在下面两节我们就来讲讲一个完备可用的AB测试平台有哪些模块，怎么构建一个完整的AB测试平台。
五，AB测试平台核心模块
根据作者构建AB测试平台的经验，我认为一个完备的AB测试平台至少需要分组模块、实验管理平台、业务接入模块、行为记录分析模块、效果评估模块这5大部分(见下面图2)，这其中分组模块、实验管理平台、业务接入模块是构建完整AB测试体系必须具备的模块，行为收集分析模块和效果评估模块是配合AB测试能够更好的得出可信结论必须具备的支撑模块。下面我们分别对这5个模块的功能和价值做简单说明，让大家更好的理解为什么需要这几个模块。
图2：AB测试平台核心模块及支撑模块
分组模块
分组模块的目的是根据各种业务规则，将流量(用户)分为AB两组(或者多组)。可以说分组模块是AB测试最核心的模块，好的AB分组方案可以让流量分配的更均匀随机。同时需要具备根据用户、地域、时间、版本、系统、渠道、事件等各种维度来对请求进行分组的能力，并且保证分组的均匀性和一致性。
对于推荐系统，“完全个性化范式”和“标的物关联标的物范式”两种推荐范式是主要的推荐范式(不熟悉的读者可以参考《推荐系统的工程实现》第五节推荐系统范式)，第一种范式是个性化推荐，为每个用户生成推荐，这时我们可以对用户做随机分组。对于第二种范式，如果我们对标的物做随机分组，是存在问题的，因为不同的标的物是不一样的，有些是热门的，有些是冷门的，可能存在分配不均的现象。我们可以采用基于时间的分配策略，某段时间标的物X分配到A组，另一段时间X分配到B组，只要保证分到AB两组的时间是公平的就行(比如第一天分到A组第二天分到B组)。
我们团队基于分组模块设计了两个算法，在推荐算法AB测试中得到大量使用及验证，可以保证分组的均匀性和公平性，并申请了相关专利。
实验管理模块
实验管理模块的目的是让产品经理、运营人员或者开发人员方便快速的创建AB测试案例，增加新的AB测试分组，调整AB测试方案各个组的比例，让AB测试跑起来。同时也用于管理AB测试平台用户创建、权限管理，让用户具备编辑、拷贝、使用AB测试实验的能力，做到高效易用。
业务接入模块
接入模块的主要目的是方便在产品迭代优化的各个阶段整合AB测试能力，对优化点做各种AB测试。一般通过提供一个AB测试SDK或者AB测试Restful接口的形式供业务方使用。接入模块需要做到高效易用，最好能够适用于产品上所有类型的AB测试优化。
我们会在第七节结合我们团队的真实业务情况详细介绍推荐系统AB测试的接入实现方案，为读者提供业务接入AB测试的参考。
行为记录分析模块
行为记录分析模块包含AB测试行为数据打点、数据收集、数据分析和数据可视化展示等子模块。
行为记录分析模块主要的目的是当某个产品功能的AB测试在线上运行时，记录用户的在AB测试模块的行为，将用户的行为收集到数据中心，借助大数据分析平台来做各种效果评估指标的统计分析与评估，最终确定新的优化点是否是有效的。
在业务实现上, 需要前端在用户访问做AB测试页面的过程中记录做AB测试的业务标识及对应的方法(策略)标识。因为在一段时间或者在同一时间整个产品中会有各类AB测试在运行，只有记录了对应的业务和策略, 我们在数据分析时才能更好的区分一条日志到底是哪个业务上的哪个策略产生的。最终方便我们将整个AB测试的效果评估、指标分析及可视化做到全自动化，提升整个AB测试迭代的速度。
效果评估模块
AB测试效果评估组件是用于跟踪AB测试的效果，根据AB测试效果来做出业务、运营、算法调整的决策。
AB测试要评估出A方案和B方案的好坏，这时就需要一个较好的衡量指标了，一般可以采用人均播放量，人均点击量，人均浏览次数，转化率，CTR等指标来评估。
具体效果评估指标的定义需要读者根据自己公司行业特点、产品形态、功能点等来定义，指标能够方便量化，并能够直接或者间接跟产品体验、用户增长、商业变现联系起来，毕竟这才是公司整体目标。
定义好各类效果评估指标后，最好可以将指标计算通用化、模块化，方便实验人员快速上线AB实验，根据不同产品及AB测试案例选择合适的指标。
有些AB测试(如猜你喜欢推荐系统)只要T+1尺度的指标计算就够了，有些(如广告投放算法的AB测试)需要具备分钟级输出AB测试结果的能力。尽早知道AB测试结果可以快速做有利决策，避免对用户体验产生不好的影响，同时快速决策也可以减少损失或者增加收益。
我们初略介绍完了AB测试平台的各个模块，知道了每个模块的作用和价值，那么在实际构建AB测试系统时，这些模块是怎么组织起来提供服务的呢？这就涉及到AB测试架构实现问题了，这是我们下节主要讲解的。
六，业界流行的AB测试架构实现方案
本节我们来讲解有哪些可行的AB测试架构实现方案，这些方案是作者结合自己的经验、思考及参考了业界一些公司AB测试实现方案后的总结。读者可以根据自己公司的产品特性、现有的基础架构、人力资源及未来需要做的AB测试类别来选择适合自己的AB测试架构。
根据作者自己这几年在推荐系统中做AB测试的经验及调研和自己的思考整理，我认为目前有3种主要的AB测试框架实现方案，具体见下面图3。
图3：AB测试可行的三种实现架构
根据上面图3，我们将AB测试架构分为3大方案，其中方案1在客户端整合AB测试能力，方案2在接口层整合AB测试能力，方案2又分为采用统一Router的形式和在web接口层整合AB测试两大类，方案3在后端业务层实现AB测试能力。我们在下面分别对这些方式做更细致的讲解说明。其中我们公司算法团队采用的AB测试方案就是方案3，在下一节我们会详细讲解。
下面我们对图3各种AB测试方案进行拆解，更加细致的说明各个方案的架构实现。
方案1：通过定制的AB Test SDK来处理AB测试业务
该方案需要开发AB Test SDK，并将SDK整合到前端，通过AB Test SDK与AB测试服务(核心分组模块)交互来处理AB测试相关功能，采用该方案的公司有微博等。具体架构见下面图4。
具体AB测试服务与业务接口的交互实现方式可以是如下两种之一：
a AB测试服务下发两个不同的接口给AB测试SDK，当用户请求时，根据用户的分组，分别调用不同的接口。
b AB测试服务下发同一个接口给AB测试SDK，但是不同的分组对应的参数不同，当用户请求时，根据用户所在的分组，选择不同的参数来访问该接口(该接口会根据不同的参数获取不同的数据)。
图4：通过提供AB测试SDK来进行AB测试的实现方案
该方案的好处是通过统一的SDK来对接AB分组服务，前端业务代码简单调用SDK的方法就可以，开发效率高。不好的点是，如果AB测试业务有调整，需要升级SDK，较麻烦(现在很多APP具备通过插件的方式做升级，这时对SDK的修改就不要发版本了，相对会更加灵活)。同时，如果公司有iOS、Android、PC等多个业务的话，需要开发多套SDK，维护成本较大。
方案2：在后端业务层增加相关组件来做AB测试
该方案通过在后端接口层增加相关组件来处理AB测试需求， 该组件通过与AB测试交互来做AB测试， 采用该方式的公司有Google，百度，大众点评等。其中又可以分为两类：
第一类：像Google，百度，AB两组对比测试业务分别部署在不同的服务器，通过构建一层统一的router来分发流量。具体架构见下面图5。通过后端统一Router模块来处理AB测试相关请求。
具体AB测试服务与业务接口的交互实现方式跟方案1类似，这里不再说明。
图5：通过后端统一Router来进行AB测试的实现方案
该方案的优点是模块化，router解决所有与AB测试相关问题，对AB测试业务做调整不需要前端版本升级，只需要升级后端服务即可。但是Router层是整个AB测试的核心，需要具备高并发高可用的能力，否则出现问题会影响AB测试能力的发挥。
第二类：像大众点评，将AB两组对比测试业务实现逻辑写在同一个业务接口，全部业务逻辑在业务服务器完成。具体架构见下面图6。通过构建AB lib(比如构建一个处理所有AB测试业务逻辑的jar包)模块来处理AB测试相关业务。
当用户使用产品触发做AB测试的功能时，前端调用统一的接口，接口层通过AB lib跟AB测试服务交互获取该请求对应的分组，并从对应的数据存储中获取数据，组装成合适的格式返回给用户。
图6：通过业务端整合AB测试lib来进行AB测试的实现方案
该方案当AB测试调整时也不需要前端做升级, 只需要修改AB lib包就可以了。该方案最大的缺点是如果公司采用多种开发语言做业务接口服务，需要每种开发语言维护一套AB lib库，维护成本较高。另外AB测试逻辑调整需要升级AB lib包时，需要对所有线上接口做升级，明显增加了风险。同时，在接口服务中整合AB lib与AB测试服务交互，增加了接口服务的复杂度，如果AB测试服务有问题，可能会影响接口功能或者性能。
方案3：通过在算法业务层跟AB测试服务交互来实现AB测试能力，不需要前端和接口层做任何处理
该方案通过在具体业务中整合AB测试能力来做AB测试，我们团队采用该方案。该方案比较适合算法类(推荐算法、搜索算法、精准投放、精准运营等)相关业务做AB测试。具体架构见下面图7。
图7：通过算法业务层来进行AB测试的实现方案
需要做AB测试的业务模块通过调用AB测试服务来实现AB测试能力，具体AB测试的实现放在业务中实现(如在推荐推断时，推荐程序在为用户计算推荐结果过程中访问AB测试服务，确定用户对应的分组)。当然，可以将这些处理AB测试的操作或者模块封装成Jar包，方便各个业务方共用，提升AB测试落地效率。
该方案的好处是(拿推荐来说)前端和接口层不做任何处理，只需在业务中实现AB测试能力，并且不需要根据AB两组分别对全量用户计算推荐结果，也不需要为全量用户分别存储AB两个算法的推荐结果，大大减少计算时间和存储开销。
到此，我们讲完了所有AB测试架构实现方案。本节我们只是给出了架构实现的架构图，并对各个方案的优缺点做了简要说明，并未具体说明怎么真正实现。在下面一节，作者以我们团队的AB测试实现方案为例来详细说明该怎么实现AB测试平台。
七，推荐系统业务AB测试实现方案
前面提到我们公司大数据与人工智能团队的AB测试就是基于方案3来实现的，目前在推荐搜索等算法业务中大量采用，效果还不错，在本节我详细说明一下具体的实现逻辑，方便大家作为落地的参考。
我们用个性化推荐(如兴趣推荐，见下面图8，对于相似推荐也适用)来说明怎么利用方案3来做AB测试。个性化的兴趣推荐是为每个用户推荐一组视频。
图8：个性化的兴趣推荐，为每个用户生成推荐结果
下面图9是推荐算法接入AB测试框架的业务流，下面我们对下图中标注数字的4处交互逻辑做简单说明，方便大家全局理解整个AB测试交互逻辑。
图9：推荐算法接入AB测试框架(方案3)业务流
对于图9中标注数字1的部分，我们的AB测试配置人员先在AB测试管理平台配置AB两类算法(可以是多个算法同时进行AB测试)的占比, 见下面图10(homePagePersonal是首页的个性化推荐，有三个算法，其中streaming-als比例为0，streaming-long-videos-v1比例为0.1，streaming-long-videos比例为0.9)，这时AB测试服务检测到了AB测试配置文件有改动，会将对应的新的AB测试配置(或者老的配置的调整)更新到AB测试服务，更新后，算法业务调用AB测试服务时就会获得最新的用户分组。
图10：通过XML格式来配置各个算法的比例
这时具体的业务逻辑调用AB测试接口(我们的接口的url为http://ab.tvmore.com.cn/config/abTest?userId=82073570&version=moretv，算法业务调用该接口后返回的json类似图11)时就会基于新的分组比例计算某个用户或者视频对应的是哪个分组(算法)，不同的分组采用不同的算法来计算推荐列表，参见下面图11中红色虚线框中部分，某个用户的guessulike业务(猜你喜欢业务)对应的是seq2seq算法(基于keras+rnn算法)，可能另外一个用户得到的是另外一个算法。我们的AB测试框架中的分组算法保证按照配置的各个算法的比例来分配，将所有用户大致按照该比例分配到对应的算法。
图11：调用AB测试接口获取某个用户对应的推荐业务的算法
对于图9中标注数字2的部分，算法业务根据某个用户所属的算法分组，对该用户利用该算法计算推荐结果，并将结果存于最终的推荐库中。参考下面图12中的流程。该步骤做完后，每个用户的推荐结果就会存储在数据库中，同时我们会在推荐结果数据库中为该用户的推荐结果增加两个字段，一个biz，一个alg，biz是对应的推荐业务(如相似影片、猜你喜欢等)，alg是对应的算法(如seq2seq等)。
图12：推荐算法根据用户所属的分组分别计算推荐
对于图9中标注数字3的部分，当用户使用产品触发对应的推荐系统时，会调用对应的接口，从相关数据库中获取对应的推荐结果，并将结果展示给用户。其中返回给用户的接口中是包含biz和alg字段的(见下面图13中红色虚线框中部分，该图就是用户触发推荐后后端返回的推荐结果json), 包含这两个字段的目的主要是将用户的行为打点记录下来，方便对用户行为进行统计分析，最终评估出算法的效果。这两个字段及字段的值就是从存入数据库的用户的推荐结果中获得的。
图13：返回给用户的推荐结果中包含biz和alg两个字段
对于图9中标注数字4的部分，我们会基于用户对AB测试模块的点击行为，计算出各个算法的核心评估指标，见下面图14。其中直接转化率(从节目曝光给用户到用户进入详情页的转化率)，有效转化率(从节目曝光给用户到用户产生播放行为的转化率)，付费入口转化率(从用户进入付费节目详情页到用户点击付费按钮的转化率)是核心指标。
图14：根据用户对AB测试模块的访问记录计算出评估指标，并可视化出来
对于非个性化推荐(如相似影片)的AB测试，基本跟个性化推荐一样，这里不再赘述。需要注意的是节目有热门和冷门之分，在分组中需要加入时间的扰动因子，让X节目在不同时间段分别用AB两种策略来计算关联节目，这在前面也提到了。
针对我们公司推荐系统的AB测试实现，我这里就介绍完了，其他算法类的AB测试也类似。希望读者从本节中学到怎么落地AB测试方案。从中我们也可以看出要实现完整的AB测试能力还是需要做很多开发工作的，涉及到前后端、大数据等多个业务部门，因此需要得到很多部门的支持。
八，开发AB测试平台需要的资源及支持
前面提到任何涉及到数据驱动运营策略、产品优化都需要依赖AB测试能力。因此，要想更好的利用数据来驱动业务发展，让产品快速增长， 互联网公司具备AB测试能力是必须的，可以说AB测试平台作为一个基础服务平台，在互联网公司的地位举足轻重。目前市面上也有很多AB测试的SAAS服务，通过购买这些SAAS服务可以方便的让自己的产品具备AB测试能力。当然也可以通过自己来开发实现AB测试能力。那到底是自己开发还是选择第三方的呢？
作者建议初创公司、规模不大的小公司或者非技术驱动但是需要AB测试能力的公司采购SAAS方案，这样可以快速的让自己的产品具备AB测试能力，将主要精力放到优化产品体验上，而不是将精力放到实现一个AB测试框架上。
如果外面的AB测试SAAS方案满足不了本公司的业务需求，而公司领导非常认可数据驱动方法，并且希望将数据驱动作为自己团队的核心能力，期待努力践行，这时就可以自研AB测试平台了。下面我讲讲自研构建AB测试平台需要哪些团队的配合和支持。
AB测试属于基础架构能力，同时又跟业务紧密结合，需要公司的基础架构后端团队、大数据算法团队、产品团队、前端团队、业务部门一起沟通，明确AB测试应用的范围，短期目标，未来的发展方向，确定AB测试的价值体现形式。最终大家一起协力开发一个适合本公司当前阶段和产品形态的AB测试平台。
其中，业务部门和产品确定需要在产品上进行AB测试的种类，需要具备什么样AB测试的能力，大数据算法团队实现分组的算法方案和进行日志的收集分析、可视化展示，基础架构后端团队设计适合公司业务的AB测试框架并开发后端的各模块及与前端交互的接口等，前端团队负责AB测试管理平台的开发，让业务部门可以更加方面的使用AB测试工具，同时实现日志打点及与AB测试平台的交互能力。
AB测试平台构建完善后，需要产品提供完善的AB测试接入文档，让大家都能够轻松使用该平台，需要大家一起努力打造利用AB测试来驱动产品迭代的团队文化，让更多的业务接入AB测试平台，通过数据分析得出有价值的结论，让数据说话，最终让AB测试平台为业务带来价值。
公司管理层一定需要有数据驱动的意识，否则即使有了AB测试能力也不太会在产品迭代中推进利用AB测试来驱动业务。如果老板有了数据驱动的意识，需要自上而下推动数据驱动和AB测试在企业的落地。
自己构建一套完备好用的AB测试平台不是一件容易的事情，还有很多细节方面需要注意，才能让AB测试真正发挥价值。
九，构建AB测试平台需要关注的重要问题
我们讲完了AB测试平台的具体实现方案，在设计AB测试平台中，我们需要关注如下几点，才能让AB测试能力得到正确的运用，更好的发挥应有的价值。
1.灵活的分组/分桶
AB测试一般需要根据各种维度对用户来分组，因此需要设计灵活(方便快速迭代)、有效(效果评估置信度高)的分组方案。
具体可能会根据随机、用户版本、用户地域、时间、渠道、年龄、性别、收入、行为等各种维度来对用户分组。AB测试平台要具备多维度分组的能力。
2.AB测试一定要具备统计学意义上“显著”的置信度
AB测试是有成本的，AB测试的目的是得出正确的结论来优化产品体验、提升收益转化，所以AB测试指标的提升一定要是统计学上“显著”的，是真实有效的。
关于置信度有很多统计学方法来验证，这里我不细讲，有兴趣的读者可以自行搜索相关材料。
3.用户体验一致性
根据上节讲的AB测试的实现方案，有些方案(如方案3)用户在一定周期内体验是一致的(同一天多次重复进入该页面或者使用该功能看到的结果是一样的)，而有的方案(如方案2第一类)用户每次进入页面或者使用该功能看到的结果可能是不一样的。显然前一种用户体验是一致的，后一种不一致。
个人建议涉及到UI展示及交互的、用户会多次进入/使用的功能点，利用体验一致的AB测试方案比较好。但是像广告投放这类业务，是在不同场景不一样的，没必要采用用户体验一致的做法。
4.测试周期要足够长
要让AB测试得出可信服的结论，AB测试需要经历一定的周期，才能得出比较有价值的结论。这里举一些例子来说明。
像UI及用户交互的优化，新的UI及交互方式可能开始用户有新鲜感，但是等用户新鲜感过去后可能就对该功能没有那么热衷了(这就像你刚找了个女朋友，恨不得每时每刻待在一起，但是过了2年3年，甚至几个月后，你可能就不是这种想法了)。如果只测试较短时间，发现新功能使用更频繁，这时如果我们就得出新的优化是比老的好，可能就被数据欺骗了。这时最好的做法是让AB测试运营一个足够长的时间段，让结果稳定下来，再来比较核心指标。具体选用多长的时间需要根据行业及经验来定，并且在在计算核心指标时，可以剔除掉初期的数据，避免初期的新鲜感影响最终评估结果。
另外，像有些特殊行业的产品，用户在不同时间行为是不一样的，比如视频行业(特别是智能电视上的视频应用，由于是多人使用一个产品，每个人的时间是不一样的，父母可能平时要上班，小孩只有在晚上有时间看电视，老人整天都有机会看电视)，用户在周末跟工作日的行为是不一样的。这是AB测试周期不能是一天的某段时间，也不能是某几天，最好是一周的整数倍，得出的结论才比较可靠。
5.损失最小性原则
我们做AB测试的目的是优化用户体验，但是有可能我们认为有效的优化在真实上线时反而是不好的，为了避免这种情况发生对用户体验和收益的负面影响。我们在做AB测试时尽量用小的流量来测试新的算法或者优化点，当数据证明优化点是有效的，才逐步推广到所有用户。实验过程中如果数据不好，最多只影响到测试的这批少量用户，不至于产生大的负面影响。
6.处理好AB测试与缓存的关系
互联网公司通过大量采用缓存技术来加速查询，同时提升整个系统的高性能、高可用能力。当为某个功能模块做AB测试时，特别要考虑缓存情况，这时可能会存在问题。
这里举个例子说明，如果某个用户开始是老算法策略，如果在做AB测试时，给用户分配到了新算法策略，如果有缓存的话，那么用户会从缓存获取到老算法策略，这时跟实际上用户分配到的新算法策略不一致。
解决方案是当用户的缓存跟用户的实际分配的策略不一致时，清空缓存，让请求回源。当然，具体实现方式可以有很多种且跟具体业务和AB测试实现方案有关