从应用看火山引擎 AB 测试 (DataTester) 的最佳实践

Posted 2023-04-23 字节跳动数据平台

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

本文将从外部用户的角度介绍 A/B 测试平台的最佳实践。分享分为四部分，首先整体介绍 A/B 测试的应用场景，接下来结合字节内部和外部的一些应用来介绍各行业的最佳实践，最后分享在实际工作过程中，为了推动 A/B 测试，在一个企业中可持续的应用实践甚至是形成一些实验文化而得到的心得体会。

如下：

• A/B 测试的业务适用性

• 火山引擎 A/B 的内部应用

• 不同行业的最佳实践

• 可持续应用的实验文化

A/B 测试的业务适用性

首先来介绍一下 A/B 测试适用的场景，以及 A/B 平台长什么样子。

1. A/B 测试到底能做什么？有哪些业务场景？

 

大家可以从上图中的数字感受到在字节跳动 A/B 实验应用的广度和深度，并且这些数字还在继续快速上涨。A/B 实验在临床医学和生物制药领域已经有几百年的应用历史，随着互联网的发展和各行业数字化的普及，更多业务搬到了线上，也具备了实验驱动的基础。

A/B 测试是快速迭代和做业务决策的一个基础功能，在功能上线前我们都会先进行一些小流量的验证，对每一个新的想法、方案，我们会先建立假设、运行 A/B 实验，结合业务逻辑对结果的分析理解策略生效过程，从而不断修正方案、做创新尝试，推动整个产品和业务的持续迭代。

接下来结合下图介绍一些具体的场景。

 

 

根据通用的海盗增长模型，刻画了一个企业在它用户的整个生命周期里，到底进行了哪些日常工作。

 

从左到右，描述了各个阶段的一些具体场景，从获取用户到推荐传播。上半部分主要表示了各个部门的各个角色所从事的具体业务活动。下半部分对应应用场景，可以做哪些 A/B 实验。

 

从应用的角度来讲，可以把这张图切成左右两块，左边是流量获取，右边是流量盘活。

 

1）流量获取：即获客。除了有付费拉新的模式，也有一些增长黑客的手段。主要面向的群体是市场营销部门和增长部门。我们可以做一些具体的广告投放的实验、落地页实验、站点优化，以及数值策略的实验。

 

2）流量盘活：即提留促活。从激发活跃一直到传播推荐都属于流量盘活，分为两个阶段，第一个就是激活、提留到营收的阶段，这个阶段主要是从事一些用户体验、使用链路方面的优化、以及用户侧和商业化的产品功能优化，这部分的主要使用群体是产研部门，包括产品、研发、设计、数据分析师，还有算法团队。产研力量的集中也导致了在这个场景下使用深度是最深的。

 

第二个就是推荐传播阶段，常规的私域运营包括活动激励再营销、以及多样的用户裂变玩法，主要使用群体常常是运营团队、业务团队，由产研团队来协同支持。整个流量盘活的部分往往是公司业务运营的核心，创造产品的核心价值。这部分的线上触点也更加丰富，比如 APP 服务端、客户端、小程序，因此可落地的实验类型也更加丰富。

 

产品优化是我们主要在做的 A/B 实验场景，包括传统的功能、链路的体验优化，还有一些搜索排序的实验、内容推荐的算法模型的实验，营销策略的实验和性能优化的实验，再比如一些常见的服务升级迁移、技术框架升级也可以做实验去观测指标避免负向影响。

 

对于不同业务模式的企业，海盗增长模型也可以演变成不同的变体，但内容上都是通用的。这张图也显而易见地说明了实验的普适性：A/B 测试对于一个公司来说，基本上可以涵盖所有线上业务部门的常见工作和活动。因此，一套科学完善的 A/B 实验平台，加上配套的场景解决方案和流程机制，能够帮助各个行业的相关从业者用科学的实验方法去衡量其收益，并更好地作出商业决策。

 

2、A/B 通常都做哪些实验？实验平台长什么样子？

 

一个标准化的实验平台需要五大核心模块：可靠分流，科学统计，实验模板，智能调优和灰度发布。

 

下图展示了火山引擎 A/B 测试实验平台的架构：

 

 

A/B 系统除了要做数据回收计算外，还需要跟业务系统直接对接进行分流，因此整体架构可以分为上图中所示的五层。

 

中间的功能层，就是实验平台前台节目可以看到的产品功能，下面的数据层和上面的接入层都是以后台服务的形式存在的，对接客户系统或是内部业务系统主要就是通过数据层和接入层。会话层和应用层是对客户公司业务的接入终端和实际应用的模拟例举，火山引擎 A/B 测试是通过接入层的 SDK 跟业务终端进行对接的，同时实现分流服务接入和数据上班，从而实现了实验分流和指标计算。

 

产品后台的核心功能是实验管控，包括从实验设计到数据报告、再到上线发布的一站式流程，支持了非常丰富的特型实验；我们还提供了实验辅助工具和 Feature Flag 配置发布等功能，为了提高各行业应用能力，我们也将在今年推出场景模板、智能优化以及开放平台等额外功能。

 

下面介绍一下主要的功能。

 

（一）服务于多场景的实验模块

 

 

这六大类特型实验可以帮助不同职能的用户以更低的门槛快速上手。

 

1）最通用的就是编程实验，主要服务于产研和算法团队，这种方式可以实现几乎所有实验，比如服务端可以做一些产品迭代、算法优化、数据策略还有一些技术性能优化实验；客户端可以做一些界面功能、素材优化实验。

 

2）可视化实验和多链接实验的受众更加倾向于增长部门和运营团队，优势是不需要开发介入就可以做一些站点优化、落地页优化、UI 优化，以及 web 站点重定向的实验等。

 

3）推送实验和流程画布实验主要适用于运营团队，这种类型的实验包含了常用的推送通道和任务管理能力，支持配置不同的任务内容用于 A/B 测试，从而实现对流失召回和个性化运营的内容素材、时间频次进行优化。

 

4）广告实验，主要是服务于市场营销团队和增长团队，这种类型的实验包含了常见广告渠道的投放管理能力，支持配置不同的广告计划来测试和优化广告素材、落地页、投放人群、出价，从而提升广告投放的 ROI，还可以通过问卷数据对比的方式对品牌广告进行增效度量。

 

（二）科学的统计报告

 

保障实验科学性的重要模块是统计报告，我们提供了 P-Value 和置信区间等统计信息来帮助用户甄别数据的可靠性。同时还提供了一些高级统计功能来修正统计结果，比如多重比较修正、序贯检验等功能，可以进一步提升统计评估的准确度，帮助用户在一些复杂场景下更好地做判断。

 

（三）丰富的分析工具

只看 A/B 组的数据对比结果还不足以得到实验结论，我们还需要进一步分析实验的过程，寻找指标涨跌背后的原因。为此，DataTester 提供了丰富的分析工具，比如多维下钻分析、转化漏斗分析、留存和同期群分析，还有常见的热力图等等，帮助用户进一步拆解渠道、人群、路径、点位进行数据深度下钻，知其所以然。

 

（四）FeatureFlag 灵活可靠的配置发布

 

 

A/B 实验也是和研发流程紧密串联的，它和业务系统的服务端、客户端都有深度的对接。想要更大地提升过程中的效率、减少实验风险，还需要有配套的配置管理和发布工具。在 DataTester 中我们为实验开发者们提供了 FeatureFlag，除了便于管理实验功能开关、快速全量之外，还可以进行日常的灰度发布、人群定向发布、一键回滚、异常监控，帮助研发再安全的前提下快速提效。

 

最后我们通过一个电商场景的例子介绍一下 A/B 测试平台是怎么在线上业务里发挥作用的

 

业务在现阶段的核心目标是提升 GMV。拆解到各业务方向后每个团队将会围绕着自己所负责的内容继续优化，例如提升 DAU、丰富商品品类、提升客单价等等。上图中展示了从一个用户首次触达，再到它最后沉睡唤醒的一个留存曲线。每个关键拐点 A/B 实验都是可以发挥作用的。

 

首先，市场投放部门会通过广告去获取流量，广告素材就是触达用户的首个触点，我们可以通过广告投放拆分对比实验来评估不同素材的转化效果，或不同投放策略的转化效果。若用户对广告感兴趣，就可以通过优惠券发放来承接流量进行激活，那么发多少金额、通过什么样的条件和策略发券整体 ROI 更高，就可以通过数值策略实验来验证。

 

当用户进场之后，只有他体验到了产品的核心价值，才会真正的活跃进一步产生购买，此时可以通过客户端和服务端编程实验来迭代产品功能体验，比如优化选购下单流程链路、优化运营 banner 素材。为了让用户停留更久需要让用户能够更快找到喜欢东西，我们要提供更多个性化的服务，比如推荐算法，猜你喜欢，这时就会大量用到推荐算法实验，不断地优化模型效果。

 

对于一些已经低活的用户，可以增加降价提醒的功能和一些营销活动，并通过推送策略实验、H5 营销落地页实验来验证收益。对于已经沉睡的用户，运营同学还可以通过推送实验来优化推送时间、推送内容进行召回。

 

以上介绍的都是常规功能性的实验，除此以外，还有反转实验。还可以做一些特殊设计的理解实验。

 

火山引擎 A/B 的内部应用

 

接下来通过一些实际案例来看一下 A/B 实验的应用。首先来看一下字节内部的应用。

 

第一个案例要分享的是产品团队在做新功能探索时如何用 A/B 实验来验证方向。这是弹幕形态首次在短视频中的尝试，团队希望通过在熟人 Tab 中加入弹幕来强化熟人社交氛围，进而刺激用户多活跃多发视频，形成正向循环。

 

考虑到弹幕在小屏幕下将影响其他的互动按钮布局，因此设计了两个方案：一是将强化弹幕，把常用互动功能在底部折叠；二是既增加弹幕，又保留原来常用的互动功能。

 

实验后结果发现，第二种方案虽然有利于互动率的提升，但会折损核心内容消费、引发投稿率下降，甚至还导致了留存下降，因此最终决策为不上线。

 

但实验失败往往是团队经验的向前推进，经过持续的推敲和探索，最终发现当用户浏览个人视频时弹出熟人互动内容会有更好的体验，找到了弹幕形态的最佳形式。

 

通过这个案例可以看到，A/B 实验既可以通过低风险试错的方式让团队敢于创新探索，又可以在帮助我们通过实验数据解读加深对用户的理解，从而迭代团队的认知、提升整体决策力。

 

第二个案例是一个设计团队极致优化的例子。通过这个例子可以看到，一个非常小的改动，也能够获得超出预期的大收益。

 

在长期的实战中，字节内部逐渐形成了实验理念和文化。

• 用置信结果说话，不自嗨；

• 不唯数据论，合理解读；

• 实验反哺业务，加深业务洞察。

 

我们选择 A/B 测试来辅助决策，主要有以下这四点原因：

1、它可以激发创新，帮助我们小步快跑、积少成多，进而拿到一些增量的收益。

2、A/B 测试是建立在一个科学的统计评估方法之上的，如果通过一套完整的实验评估平台在整个公司产品迭代和决策流程中大规模使用，就可以有效地降低决策风险并大幅提升人效。

3、持续的 A/B 测试可以让每个产品优化项及时获取数据反馈，随着实验经验的积累，团队的业务判断力也持续提升。

4、可以量化团队工作的收益，为管理赋能。

 

不同行业的最佳实践

接下来再来介绍一些不同行业的案例。

 

 

第一个案例是一个天气 APP，为了更好地平衡用户体验和商业化营收团队希望把原有的免费功能转为收费，但这可能带来一些负面影响，甚至导致用户流失，因此决定事前先小流量测试一下：A 方案直接粗暴地增加蒙版和收费按钮，B 方案对历史数据免费并增加天气预测付费订阅的方式进行收费。

 

实验发现，方案 B 订阅率有 5 倍的提升，过于激进的方式不可取，但对于有价值的功能付费订阅也可以被用户接受。

 

 

第二个案例是租车场景中支付流程的优化。原方案中通过一步流程来完成交易，但免押金的开通率和整体支付率并不高，通过实验发现，如果分离押金和租金的支持流程、先付租金再付押金，免押金的开通率会明显变高，同时带动整体支付率 7%的提升。

 

数据证明这种有违常规认知但符合用户付款心理的「一步变两步」反而带来了超乎预期的收益。

 

 

第三个是金融领域的一个案例。泰生活 APP 在改版前的用户调研中收集到首页布局不够清晰的反馈，顺应集团品牌升级的大背景进行了进行了一次较为激进的首页改版，但由于变动比较大，团队采用小流量 AB 实验对新老首页进行了一轮整体测试，以降低负面风险。

 

实验数据显示，整体功能可用性、页面性能均无明显负向影响，并收集到一些持续优化的设计细节，最终决策逐步灰度放量，A/B 测试帮助用户顺利切换到了新版本并获得了更好的体验。

 

可持续应用的实验文化

最后，探讨一下如何可持续地应用 A/B 实验。先来看一下一个实验的完整的生命周期。

 

一个实验从设计到上线大概需要九步。最后五步都是可以通过一个 A/B 实验平台来进行一站式操作的。而前面四步，从发现问题、提出假设、设计实验，到功能开发，是非常重要的。只要完成了前面的几步，再有一个比较好用的实验测试工具，我们就可以正常的运行实验了。

 

但是一个实验的结果和最终通过实验做的决策，还需要人的主观判断，人对于实验的不同解读会影响其结论，影响决策的质量。如果想要用好 A/B 实验，需要可持续运转的一套体系。除了好用的工具之外，机制还有文化都是缺一不可的。下图展示了一个 A/B 测试可持续发展的金三角。

 

 

这个金三角的左右两个角都是比较贴近我们的实际工作和实验落地的。左边是实验机制，它的作用主要有两方面：一方面是项目机制，可以让参与实验的各角色高效协同，让实验快速运行实施；另一方面是决策机制，统一完备的评价标准和决策逻辑是可以贯穿到业务的毛细血管里面的，可以对评价实验效果好坏、是否符合现阶段业务目标和发展原则进行机制层面的拉齐，从而保证每一次功能迭代都是按照正确的方向去演进。

 

右边是平台工具，好的平台工具的作用也是主要有两方面：一方面，可以保证实验的科学性、统一标准，它往往是由一个专业的团队进行研究，除了产研团队之外，还有数据团队或者统计科学的团队等等，这样就可以最大程度上保证实验的科学性和可靠性；第二个作用就是通过工具化进一步降本提效。

 

在金三角上面的是企业文化，它也是会起到微妙的作用的，举个例子，如果公司鼓励尊重客观事实、用数据说话，鼓励创新和试错，那么就会更容易形成比较好的实验文化。

 

这里介绍一个字节实验文化的最佳代表，实验 Launch Review 流程。

 

Launch Review 的会议往往是自上而下推动的，也是复盘文化的一种体现，Review 过程保证了信息的充分透明，不同业务团队可以相互学习借鉴。一般业务专家或 leader 也会参加，在评审时提供一些全局视角和业务长期发展方向的信息，在数据驱动短期价值的同时权衡「追求长期用户价值」。

 

最后是一些良好的实验习惯和理念的分享：

 

第一点建议是明确目标，注重逻辑。在实验设计阶段要更加严谨，客观分析当前的业务问题，合理推导「采用什么样的解决方案」、「预计会达到什么样的目标」、「通过哪些指标来评价」，这个是非常重要的一个实验的习惯。

 

第二点建议是实验方案有所聚焦，不要把想到的方案一股脑全上来碰运气，实验需要敬畏用户，合理使用流量，不要因为有试错的机会而广撒网，要提前过滤方案、聚焦测试目标。

 

第三点建议是把控风险，有所为有所不为。除了用户行为指标和业务指标外，在实验的过程中我们还要注重用户口碑、品牌形象等舆情指标，比如用户社群的反馈、客户之声、NPS 或客户忠诚度等。

 

第四点就是迭代速度。我们推荐将一个大的改动分解成更多的小动作，小步快跑地进行迭代和 A/B 测试。这样可以减少业务决策时的干扰因素、尽可能避免对用户体验的差异化影响。

 

第五点是推崇深入事实，不唯数据论。在看到一个数据结果之后，一定要分析背后的原因，这样才能从源头去解决问题，实验过程的业务沉淀往往比结果更有意义。

 

第六点是通过实验去鼓励探索新的方向，通过 A/B 测试可以帮助一个团队突破自己局部最优解的限制，从想到到做到在过程中 A/B 测试都是可以保驾护航的，让你可以大胆假设，小心求证。

 

最后分享一句字节内部的话：

 

以上就是本次分享的内容，欢迎大家关注我们，加入交流。

Q&A

同期群分析一般用来解决什么问题？

 

同期群分析最常用的一个具体的场景就是看留存，它的一个特点就是把用户的进组时间拉齐来分析第二天留存的情况。我们在做实验的过程中，假如实验周期是一个月，一些活跃的用户实验初期就会进组，但是一些不活跃的用户，他到实验后期才会进组，这样会使得我们在数据分析的时候产生非预期结果导致的差异。同期群分析就是想把活跃的和不活跃的用户分层去看，把他们的进组时间去拉齐，保证在同一基准上进行实验，这样九能得到较好的预期结果。

 

点击跳转 火山引擎A/B测试DataTester 了解更多

火山引擎A/B测试平台设计思路与技术实现

作者介绍：王珂，目前就职于字节跳动数据平台，为火山引擎A/B测试产品——DataTester 研发工程师。

想要获得一个 A/B 实验系统，需要做些什么事情？火山引擎团队会把这些事情分成四个部分。A/B 实验需要通过人群采样，分出对照组和实验组并且下发不同的配置，让用户体会到不同的策略。因此从实践角度来看，四个部分中首先得有一个可靠的实验系统。通过这个实验系统，我们可以采集数据，从而观测用户在不同的策略下的反应。考虑到业务的迭代过程需要保持高效性，因此系统在第二步需要高效的数据建设。当采集到数据之后，我们还需要借助统计学知识，对各组的结果进行分析，以得到正确的实验结论，这第三步被称为科学的统计分析。有了以上三步，我们离一个完整的实验系统还有最后一步。我们考虑实验平台具有一定的成本，测试人员有可能会犯错误，平台运行也可能会出现异常……这些问题都需要系统通过最后一步——精细的治理和运维，来保证实验始终正常运行。

本文的介绍会围绕下面五点展开：

•A/B 实验系统平台概览•灵活的执行组件•高效的数据建设•科学的统计分析

01 A/B 实验系统平台概览

在本文中，我们将以火山引擎 A/B 实验系统平台——DataTester 为例，详细讲解它背后的四个部分。

首先，我们对 DataTester 进行一个整体介绍。俗话说，“皮之不存，毛将焉附”，可靠的实验系统是整个平台最基础的一个部分。图1-1展示的是火山引擎实验平台所具备的能力图谱。一个实验平台的最核心点是对于业务场景的支持。 在字节跳动这家公司里，我们在对内对外都拥有比较广泛的业务场景，比如：推荐、搜索、广告、电商、直播、运营以及推送等一系列业务。不同的场景对产品提出了不同的功能要求，这也推动着实验平台去解决业务场景上所带来的新问题，并且不断地往前迭代。

图1-1火山引擎 DataTester 的能力图谱

围绕着这个核心问题，我们需要三个基础环节的帮助，也就是黄色框中的三个长方形。

•第一个是执行组件，一个实验进行时，首先需要将准确的配置定向下发给准确的用户，也就是做好流量的配置发布。•第二个环节是数据建设，通俗来讲就是我们得将数据采集上来。•第三个是显著性计算环节，当采集完数据之后，实验组与对照组之间产生的差距是否代表新策略会带来收益，会依赖于相关统计指标的计算。

以上三点是平台最基础的能力，围绕着这个实验平台，我们还需要四个紫色框中的辅助功能。

•首先，实验平台本身就具有定向的配置发布能力。在完成一个实验之后，下一步的抉择一般就是将策略废弃或者上线，对接一个完整的配置发布平台，是一个实验必要的后向延续。•下一个部分，探索实验室是针对实验无法处理的评估场景，研究怎么样辅助去做一些决策。在探索实验室里面，我们往往会尝试一些非 AB 实验的东西，比如人工合成对照组，对于一些只能将用户分在实验组中的策略，我们可以通过人工合成的方式，给构建出一个对照组进行实验，比较策略的效果。在决策分析部分，我们之前提到的显著性计算，只是分析过程中的一部分。•除此之外，我们可能还要分析更多东西，比如策略的功效是否足够，是否需要继续提升；比如实验有没有比较严重的首因效应，用户是真正喜欢这个策略，还是因为策略看起来比较新鲜，所以大家多点击了一下。这样一些分析虽然不在显著性分析的范畴里面，但是对于实验的角色分析而言同样非常重要，是决策分析的一个部分。决策分析可以用数据和事实去说话，为业务提供决策的辅助。•最后一个重要的功能是智慧决策。例如，我们在一个典型的推荐场景里面，想通过调整参数来获得收益，可能需要不断尝试新一轮实验来获得比较好的参数。这种方式虽然可行，但是非常耗时。于是，我们想要通过自动调参的方式，根据每次实验所拿到的数据进行一些分析，去选择下一次的实验点位，从而大幅度提升决策的效率。

除了以上提到的几项以外，我们还需要一些别的功能。白色圆圈中指出了迭代控制、需求管理、健康监控、精准熔断四项。所有的组件聚合在一起，就构成了一个可以比较完整的实验平台。

02 灵活的执行组件

DataTester 平台的第一部分，我们来详细讲解一下执行组件。说到执行组件，我们经常会提及到一个词——分流。所谓分流就是随机采样一部分用户来做实验，然后随机分配一半的用户进对照组，一半的用户进实验组。之后，平台将会对照组的用户下发配置A，实验组的用户下发配置B。这一整套流程实际上就是所谓的分流组件，业界通常会有四种不同的接入方式，对应图2-1中的四个框。

图2-1 业界分流的四种接入方式

最常见的两种分流方式是 RPC 和 SDK。 字节跳动在对内的场景里面比较多地使用 RPC。这种方式的好处是接入简单，并且足够灵活，而且对于平台来说比较可控。我们只需要发一个 RPC 调用，就可以知道用户命中的实验以及发布的配置等信息。每当分流组件需要有功能的升级时，只需要升级该功能自己的服务即可。那与之相对应的还有另外一种方式——SDK。考虑到了调用RPC的服务时的效率问题，SDK 接入直接提供了一个库文件在本地做分流。这种接入方式可以发挥机器的极限性能，经过比较好的优化，SDK 的接入效率一定是最高的。但是与 RPC 相比，SDK很难去避免几个问题。第一，当功能升级的时候，由于升级成本的存在，因此控制性可能会略微弱一点，也就是说我们很难保证所有使用 SDK 接入的业务方，都能够做到很好的升级。另外，业务方可能会使用不同的服务端语言，综合考虑不同服务端的 SDK 时，就需要进行多语言覆盖，这个本质上也是一个限制。

举例来说，在推荐系统的一个场景里面，如果需要在三万篇文章里进行召回实验，比如一次性召回五千篇文章。那么 RPC 肯定跑不动这个实验，全部的资源都会去进行 RPC 调用。但是如果用 SDK ，只需要一个 for 循环，就可以完成这个实验。那么，怎么可以结合 RPC 与 SDK 之间的优势呢？这里我们会讲到第三种方式——伴生进程。这种技术方案就是在业务进程的节点上，再添加一个伴生进程，用 C ++ 做封装，然后去做一个 Unix 的 Domain Socket。通过这种方式，网络传输只是在本地本机本节点上去做进程间的一个调用，可以使性能做到很大程度上的提升。同时，我们也可以保证对伴生进程的控制性，当有升级需求的时候，可以一定程度上对他们直接进行升级，而不会影响到业务方的迭代。最后一种是 UDF 分流。这是针对大数据的离线场景下，我们需要用实验去做一些分析和处理，所以会用到离线和流式处理。这边简单总结一下火山引擎会更愿意去用 RPC 进行分流的几个理由：

•第一是从未停止的高速迭代，我们要求对服务有比较强的控制，需要随时去更新它，去迭代它。•第二，多样化的接入场景、功能拼图和服务端技术栈，这些需求会导致在 SDK 这个场景下，成本会略高一些。•第三，我们也有苛刻的性能要求，即使是在 RPC 这样的方式下，我们也会进行大量非常强度的性能优化，以应对苛刻的性能要求。这里提一下，当前我们 RPC 的性能大约优化到了毫秒级的状态。

既然讲到了从未停止的高速迭代，那么，我们的分流到底都在迭代些什么东西呢？图2-2展示了分流的迭代就是围绕着灵活多变的流量复用与隔离展开的。通俗来讲，它是在解决实验与实验之间关系的问题。

图2-2 灵活多变的流量复用与隔离

最简单的实验关系其实就两个：流量的互斥和流量的正交。由于平台侧比较难以在实验开启之前，去界定这两个实验是不是有冲突、需要互斥。如果两个实验会有一些冲突，通常来说业务方在事件设计的时候，就需要知道这两个实验是有冲突的。如果两个实验是互斥的，我们就需要将实验开在同一个实验层上；如果没有互斥，那么实验将开在不同的实验层上，以保持流量的正交。

除此之外，还有互斥域的概念，除了开实验和分实验层这两次基础的哈希，我们会做第三层哈希，以此形成流量层之间的强制隔离。

下一个话题是父子实验。一般来说两个实验之间要么互斥，要么正交，应该没有什么特殊关系。但是，有一类实验会有比较强的血缘关系。比如在进行多轮迭代时，第一轮迭代后，我们发现这个实验组确实挺好，可以对着这个实验组再开一个子实验，这个子实验也有自己的对照组和实验组，然后在这个实验组可以在原实验的基础上，我继续进行迭代。这样，两个实验之间就出现了联系，子实验的流量必须来源于父实验的某一个实验组。

共享对照组这个概念中提到了一个词，叫勤俭节约。有一些场景下，样本实体是用户请求，而每来一个新的请求都是一个新的样本，这个时候做两次哈希是没有太多意义的，我们可以完全让它退化至一次哈希。退化回去之后，我们可以让实验复用同一个对照组，然后让每一个实验都只有实验组。通过这样的方式，在同样的 100% 的流量下可以开启更多的实验。但是，这样的一种实验方式也是有一定的问题的，大家在使用的时候要谨慎。

流量轮转。有一些实验，我们不是想看这个实验的收益，而是确定它就是有害的，只是想看这个实验多有害。但是我们要老针对一群用户进行试验，这对他们的使用体验是有影响的。因此，我们会定期去更新哈希种子，让进实验组的用户定期地进行切换。这样的对用户体验上来说还不错，同时我们又可以看到策略到底有多差的影响。

03 高效的数据建设

第二部分，我们来讲一讲数据建设。“天下武功，唯快不破”，平台的数据建设一定要是够快的。如图3-1所示是数据建设的整个链路图。大家可以看到，整个图分成了两个部分，这是因为数据建设实际上是要解决两个主要问题：

•第一个是离线计算，目的是要通过报告判断策略是否能够上线。•第二个是即席查询，这个部分更倾向于对实验多维度即时分析。

图3-1 数据建设的链路图

离线计算的结果是一个看板或者报告，相对比较固化。业务的核心指标在长时间内大概率是不容易发生变化的。但即席查询需要做多个维度的分析，例如链路分析和漏斗分析等。这些分析经常只针对一个实验有效，甚至是实验分析师临时想到的，即时性会比较强。对于这两个问题，我们会用不同的链路去做执行，但基本逻辑都是做累计指标运算。其实在数据建设中还有第三个需要解决的问题——流失处理。通常我们需要监控上线的新实验，比如看看三个小时之内，线上的指标的异常情况。如果异常很严重，我们要赶紧关掉实验，并且让相关人员排查不符合预期的原因。

图3-2高效的数据建设

如上所示，图3-2展示了数据建设是如何保证高效性能的：

•首先，我们要去做数据管道的建设，来保证指标建设的自动化。•其次，SQL 调优当指标组太多、业务线复杂的时候，不能都让人工去做，也需要自动化进行。•在需求管理方面，专人去对接业务方的效率太低了，自助建设的平台是不可或缺的。•数据管理可以保证数据服务，当我们想查询指标之间的关系时，需要通过数据服务来做灵活查询。•最后，打造一个开放的平台和生态系统，可以让一个试验平台的能力成指数型的增长。

通过上述的自动化和第三方共建，可以在人力、有限的资源的条件下，保证我们的数据建设在高效的状态。

04 科学的统计分析

第三部分我们聊一下科学的统计分析。“今天你显著了吗？”，显著对于一个实验来说还是蛮重要的指标。首先来说一下实验指标微涨时，到底是波动还是策略收益？我们需要通过假设检验来进行验证。图4-1的两个方框展示了对不同业务场景的假设检验方案。

图4-1 不同业务场景的假设检验方案

这里给大家举一个例子：显著性水平在业界通常会定到 5%，实际上与业务场景相关时，大家可以自己进行调整，例如 1% 或者是 10% 其实都是可以的。而对于 5% 的显著性水平，在 100 个实验里面会存在 5 个假阳性情况，当实验变多的时候情况还是蛮严重的。那么，这个时候我们应该怎么办呢？有聪明的人想到了这样一个话题，实验前的数据能不能在假阳性的问题上带来一定收益？在业界来看，实验前的数据应用方式分三种：

•第一种是 SeedFinder 以及变体的 PreAA 校验。原理是在采样用户并且分 AB 组的时候，尽量地让 A 组和 B 组之间的误差减小。方法通过衡量两组用户之间的差异，找到差异最小的两组用户进行实际实验。•另一种方法是双重差分。在实验之前，两个组之间本身会存在差异，此时我们选择做一个 A 实验，不应用任何策略，这时用户的指标天然就会有一些差异。我们采用双层插空的方法，可以尽量真实地评估策略带来的收益。•在字节跳动这边，我们采用第三种方法 CUPED。这种方法通过一些统计方法对实验前的数据进行修正，使修正之后的结果依然可以作为实验数据的无偏估计。同时，我们可以对实验前的数据缩减方差。同样的样本量缩减方差之后，原来因为流量不够而检测不出来的收益就可能被检测出来，实验的假阳性率也可以进一步降低。

05 精细的运维制度

最后讲讲第四部分，精细的运维制度。对于实验平台，我们可能要“像对待孩子细心照料”。如果一个实验平台能够在一家公司里面很好地应用起来，必须自上而下让整个公司都拥有数据驱动的理念，如图5-1所示。

图5-1 数据驱动理念

此外，由于平台不是简简单单就可以使用的，我们还需要丰富的用户教育和文档建设。同时，我们需要有积极的用户响应，只有这样才能够保证业务可以做到高效迭代。其次，为了保证系统的可靠性，我们需要在平台上做监控。例如，通过 AALayer 的方式，我们可以监控系统的安全和健康情况。同时，平台需要透明的数据口径，让所有人都能看到每一个指标的口径、数据的来源以及链路是什么样子的。 异常检查部分，在我们内部有一个代号叫 A/BDoctor 的模块，主要负责异常实验检查和异常流量检查。

•第一种是 SeedFinder 以及变体的 PreAA 校验。原理是在采样用户并且分 AB 组的时候，尽量地让 A 组和 B 组之间的误差减小。方法通过衡量两组用户之间的差异，找到差异最小的两组用户进行实际实验。•另一种方法是双重差分。在实验之前，两个组之间本身会存在差异，此时我们选择做一个 A 实验，不应用任何策略，这时用户的指标天然就会有一些差异。我们采用双层插空的方法，可以尽量真实地评估策略带来的收益。•在字节跳动这边，我们采用第三种方法 CUPED。这种方法通过一些统计方法对实验前的数据进行修正，使修正之后的结果依然可以作为实验数据的无偏估计。同时，我们可以对实验前的数据缩减方差。同样的样本量缩减方差之后，原来因为流量不够而检测不出来的收益就可能被检测出来，实验的假阳性率也可以进一步降低。

DataTester 产品介绍

案例中使用到的A/B实验平台DataTester ，是字节跳动自研的AB实验平台。截至2022年8月，DataTester 已在字节跳动内部累计完成150万次A/B测试。DataTester 集成了字节内部丰富的业务场景中的 A/B 测试经验，并已通过火山引擎，面向外部企业客户开放服务支持。

点击“阅读原文”立即试用火山引擎 DataTester ↓↓↓