打造工业级推荐系统（八）：AB测试平台的工程实现_大数据_数据与智能

都2023了！我不允许你还不了解AIGC！立即报名了解详情 



 写点什么

在前面的文章中我们提到了 AB 测试的重要性，新的推荐算法在上线到现网时需要做 AB 测试，对比新算法和老算法在关键指标上的差异，只有当新算法明显优于老算法时才会完全取代老算法。其实，AB 测试的价值不止体现在推荐系统中，它在整个互联网产品迭代周期中得到了广泛深入的应用。

本文试图对 AB 测试做一个比较全面的介绍，会从什么是 AB 测试、AB 测试的价值、什么时候需要 AB 测试、AB 测试的应用场景、AB 测试平台核心模块、业界 AB 测试的架构实现方案、推荐系统业务 AB 测试实现方案、构建 AB 测试需要的资源及支持、构建 AB 测试需要关注的问题等 9 个方面来讲解 AB 测试技术。

希望本文能够帮助读者更好地理解 AB 测试的价值和应用场景，并结合本文提供的实现方案，可以在具体业务中快速落地 AB 测试技术，应用到真实业务场景中，真正用 AB 测试工具驱动公司业务增长。

1.什么是 AB 测试

AB 测试的本质是分离式组间试验，也叫对照试验，在科研领域中已被广泛应用（它是药物测试的最高标准）。自 2000 年谷歌工程师将这一方法应用在互联网产品以来，AB 测试越来越普及，已逐渐成为衡量互联网产品运营精细度的重要体现。

简单来说，AB 测试在产品优化中的应用方法是：在产品正式迭代发版之前，为同一个目标制定两个（或以上）可行方案，将用户流量分成几组，在保证每组流量在控制特征不同而其他特征相同的前提下，让用户分别看到不同的方案设计，根据几组用户的真实数据反馈，科学地帮助产品进行决策(比如你想优化某个位置的文案颜色，觉得蓝色比红色好，就可以保持这个位置一组流量的文案红色，一组蓝色，其他都相同，进行 AB 测试)。AB 测试原理如下面图 1。

图 1：AB 测试原理

AB 测试是一种科学的评估手段，具备概率统计学理论的支撑。这里我简单解释一下原因。概率论中有一个中心极限定理，意思是独立同分布的随机变量的和服从正态分布。对于 AB 测试，我们比较的是两组样本的平均表现，AB 测试保证 AB 两组某个因素不一样(这个就是我们要验证的优化点)，AB 两组其他很多未知影响因素一样(这些因素是独立同分布的随机变量)，当 AB 两组样本足够多时，这些其他因素产生的效果是满足同一正态分布的，因此可以认为对要验证的变量的作用是相互抵消的，这样待验证因素(即我们的控制变量)的影响就可以比较了，因此我们就可以通过实验来验证优化是否有效。

像 Google，Facebook，百度，阿里，微博，大众点评等互联网公司很早就采用 AB 测试框架来驱动业务发展，为公司创造价值。

业内也有很多提供 AB 测试 SAAS 服务的创业公司，通过定制化的 AB 测试方案来为其他公司提供 AB 测试能力，如吆喝科技，ABTester, 云眼, Testin 云测等等。

讲完了什么是 AB 测试，我们知道 AB 测试可以驱动业务发展，那么 AB 测试的价值到底体现在哪些方面呢？这就是下节主要讲的内容。

2. AB 测试的价值

最近几年增长黑客的理念在国内互联网盛行，有很多这方面的专业书出版，很多公司甚至设立了 CGO(首席增长官)的高管职位。增长黑客思维希望通过从产品中找到创造性的优化点，利用数据来驱动产品优化，提升用户体验及收益增长，最终达到四两拨千斤的效果。随着公司业务规模及用户的增长，利用数据来驱动业务发展越来越重要。增长黑客本质上就是一种数据驱动的思维，并且有一套完善的技术管理体系来科学地驱动业务发展，而这套体系中最重要的一种技术手段就是 AB 测试。

AB 测试可以很好的指导产品迭代，为产品迭代提供科学的数据支撑。具体来说，AB 测试的价值主要体现在如下四个方面。

1.为评估产品优化效果提供科学的证据

前面说过，AB 测试是基于概率论与统计学原理之上构建的科学的测试技术，有很强的理论依据。

AB 测试也经历过多年实践的检验，被证明是有效的方法。前面提到过 AB 测试是药物测试的最高标准，在药品制造业得到了很好的使用和验证。同时，各大互联网公司都大量使用 AB 测试技术，为整个互联网的发展提供了很好的榜样和示范作用。

2.借助 AB 测试可以提升决策的说服力

因为 AB 测试是有统计学作为理论基础，并且又有工业上的实践经验作为支撑，利用 AB 测试得到的结论具备极大的说服力。因此，在用数据说话上，大家在意识形态上更容易达成一致，这样就可以让产品迭代更好更快的推行下去。

3.AB 测试可以帮助提升用户体验和用户增长

任何涉及到用户体验、用户增长相关的优化想法都可以通过 AB 测试来验证，通过验证得出有说服力的结论，从而推动产品朝着用户体验越来越优的方向发展。

4.AB 测试可以帮助提升公司变现能力

搜索、推荐、广告、会员等涉及到收益相关的产品及算法都可以通过 AB 测试来验证新的优化思路是否可以提升盈利性指标。其中盈利性指标可以根据公司业务和发展阶段来定义。

总之，一切涉及到用户体验、用户增长、商业变现的产品优化都可以借助 AB 测试技术，驱动业务做得更好，AB 测试是一种科学的决策方式。那我们在什么时候需要 AB 测试呢？

3.什么时候需要 AB 测试

如果你像乔布斯这么牛逼，可以深刻洞察用户的需求，甚至是创造用户需求，我觉得你可以不用 AB 测试，但是世界上只有一个乔布斯。所以，对于我们普通人来说，AB 测试在产品迭代过程中还是必要的。那么是不是所有产品迭代或者优化都需要做 AB 测试呢？我觉得不一定，需要具体情况具体分析，我认为下面 4 点是需要利用 AB 测试来做决策的前置条件。

1.必须是有大量用户的产品或者功能点

如果你的产品只有很少的用户使用，比如一些政府部门的官网。由于用户少，分组后用户更少。根据上面 AB 测试的统计学解释(大量随机样本产生的影响的均值是正态分布，样本量小就不是，这时其他因素的影响就可能无法抵消，导致控制变量的比较就无意义)，根据很少的用户得出的结论是不具备统计学意义的。所以即使做了 AB 测试，得出的结论的有效性是无法用统计学原理支撑的，因此是不可信的。

同样的，某个产品虽然用户多，但是如果某个功能点只有很少用户用，这跟上面道理是一样的，是无法做出可信服的结论的。

同样的，某个优化太细(用户意识到这种改变的概率很小)，比如就看某个推荐位的颜色深浅是否对用户点击是否有影响，这时也需要大量的用户对这个位置的访问才可以得出比较有指导意义的结论。

2.进行 AB 测试的代价(金钱 &时间)可以接受

如果做 AB 测试的代价太大，比如需要消耗大量的人力财力，这时做 AB 测试的产出可能小于付出, 这时做 AB 测试就是费力不讨好的事情了。

3.有服务质量提升诉求

如果某个业务或者功能点用户极少使用，并且也不是核心功能点，比如视频软件的调整亮度，这个是一个很小众的需求，只要功能具备就可以了，好用和不好用对用户体验影响不大，这时花大力气对它进行优化就是没必要的。

4.变量可以做比较好的精细控制

如果某个功能影响的变量太多，并且我们也无法知道哪个变量是主导变量，甚至都不知道有哪些变量对它有影响，这时就很难利用 AB 测试了。因为，AB 测试需要调整一个变量同时控制其他变量不变。

如果上面 4 个条件都满足的话，我觉得这个功能点是可以做 AB 测试的。对于 toC 的互联网产品来说，其实上面几个条件是很容易满足的，所以在互联网公司有很多地方都可以通过 AB 测试来优化产品功能，那 AB 测试在互联网公司到底有哪些应用场景呢？

4.AB 测试的应用场景

在互联网公司 AB 测试可以落地的场景是很多的，具体包括如下 3 大类：

1.算法类

各类算法是 AB 测试应用场景最多的地方，算法开发人员通过 AB 测试来验证一个新的算法或者小的算法优化是否可以提升算法的业务指标。包括推荐、搜索、精准广告、精细化运营等涉及到算法的产品和业务都是可以利用 AB 测试技术的。

2.运营类

任何一个互联网产品少不了运营，在互联网红利消失的当下，某个产品是否可以“占领”用户的心智，运营将起到越来越重要的作用，甚至有人说互联网时代将进入一个运营驱动的时代。各类运营手段，如用户运营(用户拉新、会员运营等)、内容运营(视频行业的节目编排等)、活动运营(抽奖等)等都可以借用 AB 测试技术来验证哪种运营策略是更加有效的。

3.UI 展示及交互类

UI 是任何一个互联网产品可直接被用户感知的部分，用户通过 UI 与互联网产品交互，用户对一个产品的感知也是首先通过 UI 建立的。简洁美观的 UI 界面，流畅的 UI 交互往往能够给用户留下好的第一印象。对于 UI 视觉及交互部分的优化，往往凭设计师的经验是不够的，需要利用技术手段来验证哪种 UI 展示风格、哪种交互方式是用户更喜欢的、能够带来最大收益的。

像颜色、字体、按钮形状、页面布局、操控方式的调整及优化都是可以通过 AB 测试来验证的。

现在我们知道了互联网产品哪些模块和功能是可以利用 AB 测试驱动做得越来越好的，那么大家一定想知道我们怎么构建一个高效易用的 AB 测试平台，并怎样通过该平台更好地支撑各类 AB 测试任务。在下面两节我们就来讲讲一个完备可用的 AB 测试平台有哪些模块，怎么构建一个完整的 AB 测试平台。

5.AB 测试平台核心模块

根据作者构建 AB 测试平台的经验，我认为一个完备的 AB 测试平台至少需要分组模块、实验管理平台、业务接入模块、行为记录分析模块、效果评估模块这 5 大部分(见下面图 2)，这其中分组模块、实验管理平台、业务接入模块是构建完整 AB 测试体系必须具备的模块，行为收集分析模块和效果评估模块是配合 AB 测试能够更好的得出可信结论必须具备的支撑模块。下面我们分别对这 5 个模块的功能和价值做简单说明，让大家更好的理解为什么需要这几个模块。

图 2：AB 测试平台核心模块及支撑模块

1.分组模块

分组模块的目的是根据各种业务规则，将流量(用户)分为 AB 两组(或者多组)。可以说分组模块是 AB 测试最核心的模块，好的 AB 分组方案可以让流量分配的更均匀随机。同时需要具备根据用户、地域、时间、版本、系统、渠道、事件等各种维度来对请求进行分组的能力，并且保证分组的均匀性和一致性。

对于推荐系统，“完全个性化范式”和“标的物关联标的物范式”两种推荐范式是主要的推荐范式(不熟悉的读者可以参考《推荐系统的工程实现》第五节推荐系统范式)，第一种范式是个性化推荐，为每个用户生成推荐，这时我们可以对用户做随机分组。对于第二种范式，如果我们对标的物做随机分组，是存在问题的，因为不同的标的物是不一样的，有些是热门的，有些是冷门的，可能存在分配不均的现象。我们可以采用基于时间的分配策略，某段时间标的物 X 分配到 A 组，另一段时间 X 分配到 B 组，只要保证分到 AB 两组的时间是公平的就行(比如第一天分到 A 组第二天分到 B 组)。

我们团队基于分组模块设计了两个算法，在推荐算法 AB 测试中得到大量使用及验证，可以保证分组的均匀性和公平性，并申请了相关专利。

2.实验管理模块

实验管理模块的目的是让产品经理、运营人员或者开发人员方便快速的创建 AB 测试案例，增加新的 AB 测试分组，调整 AB 测试方案各个组的比例，让 AB 测试跑起来。同时也用于管理 AB 测试平台用户创建、权限管理，让用户具备编辑、拷贝、使用 AB 测试实验的能力，做到高效易用。

3.业务接入模块

接入模块的主要目的是方便在产品迭代优化的各个阶段整合 AB 测试能力，对优化点做各种 AB 测试。一般通过提供一个 AB 测试 SDK 或者 AB 测试 Restful 接口的形式供业务方使用。接入模块需要做到高效易用，最好能够适用于产品上所有类型的 AB 测试优化。

我们会在第七节结合我们团队的真实业务情况详细介绍推荐系统 AB 测试的接入实现方案，为读者提供业务接入 AB 测试的参考。

4.行为记录分析模块

行为记录分析模块包含 AB 测试行为数据打点、数据收集、数据分析和数据可视化展示等子模块。

行为记录分析模块主要的目的是当某个产品功能的 AB 测试在线上运行时，记录用户的在 AB 测试模块的行为，将用户的行为收集到数据中心，借助大数据分析平台来做各种效果评估指标的统计分析与评估，最终确定新的优化点是否是有效的。

在业务实现上, 需要前端在用户访问做 AB 测试页面的过程中记录做 AB 测试的业务标识及对应的方法(策略)标识。因为在一段时间或者在同一时间整个产品中会有各类 AB 测试在运行，只有记录了对应的业务和策略, 我们在数据分析时才能更好的区分一条日志到底是哪个业务上的哪个策略产生的。最终方便我们将整个 AB 测试的效果评估、指标分析及可视化做到全自动化，提升整个 AB 测试迭代的速度。

5.效果评估模块

AB 测试效果评估组件是用于跟踪 AB 测试的效果，根据 AB 测试效果来做出业务、运营、算法调整的决策。

AB 测试要评估出 A 方案和 B 方案的好坏，这时就需要一个较好的衡量指标了，一般可以采用人均播放量，人均点击量，人均浏览次数，转化率，CTR 等指标来评估。

具体效果评估指标的定义需要读者根据自己公司行业特点、产品形态、功能点等来定义，指标能够方便量化，并能够直接或者间接跟产品体验、用户增长、商业变现联系起来，毕竟这才是公司整体目标。

定义好各类效果评估指标后，最好可以将指标计算通用化、模块化，方便实验人员快速上线 AB 实验，根据不同产品及 AB 测试案例选择合适的指标。

有些 AB 测试(如猜你喜欢推荐系统)只要 T+1 尺度的指标计算就够了，有些(如广告投放算法的 AB 测试)需要具备分钟级输出 AB 测试结果的能力。尽早知道 AB 测试结果可以快速做有利决策，避免对用户体验产生不好的影响，同时快速决策也可以减少损失或者增加收益。

我们初略介绍完了 AB 测试平台的各个模块，知道了每个模块的作用和价值，那么在实际构建 AB 测试系统时，这些模块是怎么组织起来提供服务的呢？这就涉及到 AB 测试架构实现问题了，这是我们下节主要讲解的。

6.业界流行的 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 测试平台。

7.推荐系统业务 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 测试接口(算法业务调用该接口后返回的 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 测试能力还是需要做很多开发工作的，涉及到前后端、大数据等多个业务部门，因此需要得到很多部门的支持。

8.开发 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 测试真正发挥价值。

9.构建 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 测试实现方案有关，这里不详细说明。