首先我们看一个案例。字节跳动有一款中视频产品叫西瓜视频，最早它叫做头条视频。为提升产品的品牌辨识度，团队想给它起个更好的名字。经过一些内部调研和头脑风暴，征集到了西瓜视频、奇妙视频、筷子视频、阳光视频 4 个名字，于是团队就针对一共 5 个 APP 名称进行了 A/B 实验。这个实验中唯一改变的是应用市场里该产品的名称和对应的 logo，实验目的是为了验证哪一个应用名称能更好地提升“头条视频” APP 在应用商店的点击率。最后西瓜视频和奇妙视频的点击率位列前二，但差距不显著，结合用户调性等因素的综合考量后，最终决定头条视频正式更名为西瓜视频。
通过这个案例能够正常的看到，A/B 测试能够在一定程度上帮助业务做最终决策。结合案例的直观感受，我们大家可以这样来定义 A/B 测试：在同一时间对目标受众做科学抽样、分组测试以评估效果。
● A/B 测试不可能对全用户都进行实验，所以要进行科学抽样，选择小部分流量进行实验。
● 抽样之后需要对样本做分组，比如 A 组保持现状，B 组的某一个因素有所改变。
以上就是我们对 A/B 测试的定义。目前，A/B 测试已被 Google、Facebook、亚马逊等大型网络公司广泛采用；字节跳动更是在 2012 年成立之初便开始使用 A/B 测试，企业内部一直流传一句话：一切皆可 A/B 测试。A/B 测试在字节跳动已是非常基础的设施和文化，目前，字节跳动累计已有 80W+ 的 A/B 实验，日新增实验 1500+，同时运行试验 1W+，服务 500+ 业务线。
● 风险控制：小流量实验能够尽可能的防止直接上线效果不好造成损失。其次，实验迭代的过程中，决策都是有科学依据的，能够尽可能的防止系统性的偏差。
● 因果推断：我们始终相信 A/B 实验中的优化和改变最终能影响到线上数据及用户的行为。在这个前提下，A/B 测试就是最好的因果推断工具。
● 复利效应：A/B 测试是能持续不断进行的实验，即使一次实验提升的效果不大，但是长期下来复利效应的积累会产生很大的变化和回报。
了解了我们为何需要做 A/B 测试，下面我们的角度来看一下火山引擎的 A/B 检测系统是怎么来实现的。
● 基础设施层：会用到关系型数据库和键值对。因为 A/B 测试要处理很大的数据量，这一层也会使用离线和实时的大数据组件。
● 服务层：包括实验所需的分流服务、元信息服务、调度服务等。在 A/B 测试中我们也需要标识用户，因此这一层有设备服务。为了提供多种数据查询，还有 OLAP 引擎。
● 客户端已经集成了火山引擎 A/B 检测系统的 SDK，向 A/B 检测系统请求分流服务，判断用户命中哪些实验哪些版本，下发参数；
● 服务端实验的 SDK 是跟业务系统比如服务端集成在一起。客户是从其他 C 端用户直接请求业务的服务端，该服务端会在本地 SDK 做决策；
● 确定业务的指标体系：可以从宏观/微观、长期/短期、横向/纵向三个角度建设指标体系。
● 分类检验：对指标进行置信度计算的时候，并不会每次都用同一套方法，而是针对不一样的指标类型（包括转化类、人均类、CTR 类等）进行不同的建模采用不一样的方法。
● 统计修正：如果一个实验开了多个组，可能犯了多重比较的错误。还有时开完实验之后天天都会查看结果，这就犯了连续观测的错误。所以在实践中需要有一些统计修正的方法来修正行为。
● 基于叶贝斯体系的探索：区别于经典的假设检验，我们也在探索基于叶贝斯体系，如何评估实验效果，降低面向用户使用时候的理解门槛。在智能流量调优、模型超参数搜索等场景下有具体落地。
● 避免过度曝光：A/B 实验中有一个很关键的点是决策哪些样本应该进入实验。如果所有打开应用的人都能命中实验，实验结果就不会很明显。
● 进组和出组：假设我们对北京的用户进行了实验，有些人出差或者旅游离开北京之后还能命中实验吗？我们大家可以把这个决策留给实验者，让实验者自己决定是进组还是出组。
● 和 Feature Flag 的珠联璧合：实验之前可以把能进行实验的内容抽象成 Feature Flag，简单理解成功能开关。实验完成之后的上线或者重复实验，也可用 Feature Flag 进行管理。
在字节跳动，A/B 测试已经是一种企业文化，大家都认可其价值，达成共识才能一起探讨。A/B 测试跟别的环节是紧密相关的。我们在收集和分析数据之后会得到一些洞察，基于这些洞察不难得知有些环节是比较薄弱的，可进行提升，然后就可以提出假设，设计 A/B 实验，完成实验之后评估效果。有可能实验未达到预期效果，可以对实验进行迭代继续收集数据，这样就形成了以 A/B 测试为核心的业务增长闭环。
关于怎么样产生好的实验想法，我们大家可以从定量分析和定性分析几个角度来看。前面提到的构建完善的指标体系就是定量分析，这里不再赘述。在收集到指标数据以后，对于指标发生的异动进行现象分析，针对已有一定的问题（非异动），则能够直接进行新的产品策略或者运营策略迭代执行。
● 产品本身的价值主张是什么？比如一款打车 APP 的价值主张是通过共享经济实现社会的效率提升，这样的产品有没有很好地体现价值主张？可以从这一方面产生一些实验想法。
相关性：同一个页面中如果有不相关的功能，用户大概率也不会点击，这样的设计就没有效果。
焦虑性：有的地方可能给了用户很多选择，也会造成选择困难，不自觉地形成一种焦虑感，不如简单一些只设计一个选择。
我们需要针对一个用户群体做出改变，然后产生一定的影响。但是这个假设不是无脑定的，要有逻辑性是合理的，最终能通过指标来评估变化的影响。针对这几个要素，我们总结出了设计 A/B 实验的 PICOT 原则，即 Population、Intervention、Comparison、Outcome、Time，明确对什么样的用户做出了什么样的改变，接着进行分组比较，最终要设计衡量结果的指标，并决策实验要进行多长时间。
上图是一份 A/B 测试实验报告，能够正常的看到指标在实验版本里是绝对值，还有变化值以及置信区间。置信区间是指假设策略全量上线% 的把握会看到真实的指标收益在 [,] 这个范围内。置信区间越窄且不包含 0，可信度就越高。从「查看图表」进入选择差异值可以观察累计 diff 趋势图，如果呈现置信区间逐渐变窄的现象，说明随着样本量慢慢的变大，我们对评估结果的信心就越来越强。
● 正向显著：说明当前样本容量条件下，实验版本优于对照版本，实验结果和假设一致；
● 负向显著：说明当前样本容量条件下，实验版本不优于对照版本，实验结果和假设不一致；
确实不显著：可以借鉴 MDE 指标是不是满足预期，若符合，则说明结果确实不显著。
其他问题造成的不显著：比如样本容量小，指标对应的用户行为渗透率低，实验时长较短等。在这一些状况下，如果实验效果不显著，能更加进一步优化实验，比如增大样本量，扩大流量、再观察一段时间积累更多进组用户等。
今日头条 UI 整体风格偏大龄被诟病已久，不利于年轻和女性用户泛化，历史上几次红头改灰头实验都对大盘数据显著负向。因此团队设计了 A/B 实验，目标是在可接受的负向范围内，改一版用户评价更好的 UI。经过控制变量法，对以下变量分别开展数次 A/B 实验：
某款短视频在刚面世时，很多用户都不知道上滑的玩法，因此就设计实验验证如何能更好地引导用户上滑。实验目标定为优化后提升新用户留存，上滑操作渗透率提升 1%，错误操作渗透率下降 1%。定向受众为新用户，面向 10% 的线 个月的实验。
我们做了两轮实验，第一轮实验结果并不符合预期，上滑操作渗透率下降 1% 且显著，错误操作渗透率提升 1.5%，不符合预期。新用户留存未见显著上升。但在不符合预期的情况下，还是能做一些分析来发现原因。因此经过改进我们做了第二轮实验，结果上滑操作渗透率上升 1.5% 且显著，新用户 7 日内留存提升 1%-1.8%，且指标结果呈显著，符合预期。
● 最后想跟大家一起展望一下 A/B 测试行业未来的情况。从行业前景来看：
● 认知率和普及率在高速提升：我们之前做过一个调研，发现 A/B 测试在国内整体认知度较低，可能低到一个很难来想象的数字。我们大家都认为在未来 5-10 年内，A/B 测试的认知度可能会出现 50-100 倍的提升，这一个市场还是一片蓝海。
● 从 nice-to-have 到 must-have：现在很多人认为 A/B 测试是一个锦上添花的工具，但在数据驱动逐渐重要的今天，A/B 测试是必须要掌握的工具，是企业开展业务过程中的刚需，否则在行业竞争中就会失去优势。
● 破圈：我们也发现 A/B 测试正在破圈。大家的印象中 A/B 测试只有网络公司会用，但是我们在交流的过程中发现，很多传统企业虽没线上业务，但如果能解决数据收集的问题，A/B 测试也能满足传统企业优化的诉求。
● 智能化：A/B 测试目前还处在早期阶段，一些实验结论或实验洞察对数据和用户属性的利用还不是很充分。如果 A/B 测试能和统计方法、算法模型相结合，很可能提高整个行业的水平。
● 场景化：很多场景还没有开始使用 A/B 测试，未来更多的行业场景能和 A/B 测试相结合，让 A/B 测试更易用。
● 被集成：目前我们的 A/B 测试平台可以一站式管理实验、查看报告，但是一些用户的业务已经很成熟，希望 A/B 测试能够走入业务和系统，更顺滑地使用。所以 A/B 测试技术也需要提高自身被集成的能力，无缝地和各种业务、系统结合起来。
Q：A/B 测试对用户体量有没有基本限制？小用户量在进行 A/B 测试时有什么要注意的吗？
A：A/B 测试方法本身对用户量没有限制，但是如果实验样本太少，就特别难看到显著的结果，收益比较小。
A：我们内部在做的一些事情可以粗略地介绍一下：比如基于多臂的智能实验，已经在开始应用一些算法。此外我们也在探索参数搜索的实验，提升搜索参数的速度，让 A/B 测试更智能化。
A：严格意义上，开多久是和实验能带来的影响有关系的，以我们的经验值来看，一般是要覆盖一个完整的用户生命周期。我们一般是以周为单位，实验至少开启 1-2 周。
Q：A/B 测试在实验结果上有没有自动归因的能力，帮用户直接定位到是什么原因引发实验结果好或者差的？
A：前面提到的一些智能化探索会对自动归因有帮助，但是自动归因还有一个很重要的点是，A/B 测试实验数据背后的原因在大多数情况下要很多业务知识的输入或者很有力的指标建设才能推断出来。
A：我们通过大量的模拟实验，以及对系统监控的自检来保证正交，一经发现数据超过了阈值就会及时做调整。
