Trustworthy Online Controlled Experiments Part 4 Chap 12

---

第四部分 构建实验平台的高级技术

第四部分从第4章扩展了构建实验平台的内容，这五个简短的章节主要针对工程师和数据科学家。不过产品经理至少应了解此处讨论的问题，因为它们会影响实验设计以及实验分析的数据质量。

在整本书中，为了使讨论变得简单，我们主要关注服务器端实验。但是，有很多胖客户端，特别是移动或桌面应用程序，我们需要在客户端进行实验。本章说明了运行客户端实验时要考虑的主要差异。无论你处于实验成熟的哪个阶段，接下来的两个主题都是基础。

首先，高质量工具是运行可信赖的在线控制实验的先决条件。没有工具，将无法获得数据或指标来分析实验，甚至无法确定系统的基准性能。在这一部分中，我们将在实验的背景下讨论工具的关键点。

接下来，尽管为简化起见，我们假设用户是随机样本，但还有其他选择，例如会话或页面。选择随机单位的机制通常会深入到系统中，这可能会影响用户体验和分析的有效性。我们描述了可以使用的各种选择，并提供了如何选择随机机制的指导。

在扩展实验规模时，需要考虑其他领域。首先，已有原则和可控的方式进行实验对于规模化至关重要。我们讨论了加速实验需要考虑的：权衡速度，质量和风险。

最后，自动化和可扩展的数据分析管道对于扩展实验也至关重要。我们会介绍ScalingExperiment分析中所需的通用步骤，包括处理，计算和显示数据。

位于客户端的实验

理论与实践之间的差异在实践中比在理论上更大。
− Jan L.A. van de Snepscheut

为什么重要：

可以在瘦客户端（例如Web浏览器）上或在胖客户端（例如移动应用或桌面客户端）上运行实验。网页的更改（无论是前端还是后端）都由服务器完全控制。这与胖客户端大不相同。随着移动设备使用量的爆炸性增长，在移动应用程序上运行的实验数量也在增加（Xu和Chen，2016年）。了解由于发行过程，基础架构和用户行为而导致的瘦客户机和胖客户机之间的差异，对于确保实验有效性非常有用。

对于本书的大部分内容，我们在设计和运行实验时都基于瘦客户端，为了使讨论简单。本章专门讨论在胖客户端中的运行实验。

服务器端和客户端之间的差异

为了简化术语，我们将使用“客户端实验”来指代胖客户端中进行的实验。我们将使用“服务器端实验”来指代服务器端进行的实验更改，无论它影响胖客户端还是瘦客户端，无论是UI更改还是后端更改。

服务器端和客户端之间的两个主要差异在于：发布过程和数据通信。

差异1：发布流程

在一个在线网站上，新功能的发布通常是连续发生的，有时一天会发生多次。由于更改基本都是基于服务器控制的，因此作为持续集成和部署的一部分，更新服务器端代码相对容易。当用户访问站点时，服务器将数据（例如HTML）推送到浏览器，而不会中断用户的体验。在受控实验中，用户看到的版本由服务器完全管理，并且不需要最终用户采取任何措施。是显示红色还是黄色按钮，所有这些更改都可以在服务器端部署后立即发生。

对于客户端应用程序，许多功能仍然会受到服务（即服务器端代码）的影响，例如Facebook应用程序中显示的提要内容。更改将遵循上述针对网页的类似发布过程。实际上，我们对服务的依赖程度越高，就越容易在不同客户端之间的敏捷性和一致性方面进行试验。例如，对Bing，Google，LinkedIn和Office的许多更改都是在服务器端进行的，并且影响所有客户端，无论是Web客户端还是移动应用程序之类的胖客户端。

是，客户端本身附带了大量的代码。对此代码所做的任何更改都必须以不同的方式发布。例如，在移动应用程序中，开发人员无法完全控制部署和发布周期。发布过程涉及三方：应用程序所有者（例如Facebook），应用程序商店（例如Google Play或Apple App Store）和最终用户。

代码准备就绪后，应用程序所有者需要将内部版本提交给应用程序商店进行审查。假设该构建通过审核（可能需要几天），将其发布给所有人并不意味着访问该应用程序的每个人都将拥有新版本。相反，获取新版本是软件升级，用户可以选择延迟甚至忽略升级，同时继续使用旧版本。一些最终用户需要数周的时间才能采用。一些企业组织可能不希望有更新，并且不允许用户使用新版本。

某些软件（例如Exchange）在私有云中运行，该私有云被禁止调用未经批准的服务。所有这些因素意味着，在任何给定时间，应用程序所有者都必须支持多种版本的应用程序。尽管可能不涉及应用商店审查过程，但对于桌面客户端（例如Office，Adobe Acrobat，iTunes）也存在类似的挑战。

值得指出的是，Google Play和Apple应用商店现在都支持分阶段推出（Apple，Inc. 2017，Google Console 2019）。它们都允许应用程序所有者使新应用程序仅对一定比例的用户可用，如果发现问题，则暂停发布。分阶段推出可以看成是随机实验，因为符合条件的用户是随机选择的。不幸的是，这些推广不能作为随机实验进行分析，因为应用程序所有者不知道哪些用户有资格接收新应用程序。应用程序所有者仅知道谁“采用”了新应用程序。我们将在本章的后面部分对此进行讨论。

应用程序所有者可能不希望频繁推送新的客户端版本。尽管没有严格限制发布一个新版本的次数，但是每次更新都会占用用户的网络带宽，并且可能会带来恼人的用户体验（取决于更新和通知设置）。 Windows或iOS是无法频繁更新的一个很好的例子，因为某些更新需要重新启动。

差异2：客户端和服务器之间的数据通信

假设，新应用已经安装在客户手机上，它必须与服务器进行通信。客户端需要从服务器获取必要的数据，并且需要将客户端发生的情况将数据传递回服务器。第13章我们会介绍通讯工具，但在这里我们重点介绍了移动应用进行数据通信时的一些关键要素。为了简单，这里只考虑移动应用，但请注意，随着技术的飞速发展，移动设备和台式机之间的鸿沟正变得越来越明显，这反映了设备功能和网络连接的改进。

首先，客户端和服务器之间的数据连接可能受到限制或延迟：

• 互联网连接。 Internet连接可能不可靠或不一致。在某些国家/地区，用户可能会离线几天。即使是通常在线的用户，也可能无法在飞机上访问Internet或暂时处于没有可用的蜂窝或WiFi网络的区域中。结果，服务器端发生的数据更改可能不会推送到这些客户端。同样，客户端上的数据收集可能会延迟传输回服务器。这些延迟因国家或地区而异，必须在工具和下游处理中予以考虑。

• 蜂窝数据带宽。大多数用户的蜂窝数据计划有限，这引发了一个问题，即是仅在用户使用Wi-Fi时还是在任何时间点上载遥测数据。大多数应用选择仅通过Wi-Fi发送遥测数据，这可能会延迟在服务器端接收到该数据的时间。各个国家/地区之间也可能存在异质性，因为在带宽，成本等方面，某些国家/地区的移动基础设施要弱于其他国家。不仅数据连接本身会受到限制，而且即使连接良好，使用网络也会影响设备性能并最终影响用户与该应用的互动（Dutta and Vadermeer 2018）：

• 电池。更多的数据通信意味着电池消耗增加。例如，该应用可以更定期地唤醒以发送更多遥测数据，但这会影响电池消耗。此外，低电量模式下的移动设备对允许执行的应用有限制（Apple，Inc. 2018）。

• CPU，延迟和性能。即使当今许多移动设备的行为都像微型计算机一样，但仍有一些低端移动设备受到CPU功率的限制。设备上频繁的数据聚合以及与服务器之间来回发送数据会使应用程序的响应速度降低，并损害了应用程序的整体性能。

• 内存和存储。缓存是减少数据通信的一种方法，但会影响应用程序的大小，从而影响应用程序性能并增加应用程序的被卸载的几率（Reinhardt 2016）。对于具有较低内存和存储空间的低端设备的用户，这可能是一个大的问题。

通信带宽和设备性能都是同一个设备生态系统的一部分，需要权衡取舍。例如，我们可以通过使用更多的蜂窝数据来获得更一致的Internet连接。我们可以花费更多的CPU在设备上进行计算和聚合，以减少发送回服务器的数据；我们可以等待Wi-Fi，不过这需要更多的设备存储空间来发送跟踪数据。这些折衷会影响对客户端正在发生的事情的可见性，以及用户的参与度和行为（类似于第5章）。

以上两个不同对实验的意味着什么

1：及早预测变化并进行参数化

由于客户端代码无法轻松交付给最终用户，因此任何客户端更改进行的受控实验都需要仔细计划。换句话说，所有实验（包括这些实验中的所有版本）都需要进行编码，并与当前的应用程序构建一起提供。任何新的版本，包括对任何现有版本的错误修复，都必须等待下一个版本。例如，在典型的每月发行版中，Microsoft Office附带了数百种功能，这些功能以受控方式推出以确保安全部署。受控方式有三个含义：

1.在某些功能完成之前，可能会发布新的应用程序，在这种情况下，这些功能由配置参数（称为功能标志）控制，默认情况下会关闭这些功能。以这种方式关闭的功能称为深色功能。该功能完成并准备就绪后，在服务器端更改设置，即可将其打开。

2.客户端内置了更多功能，因此可以从服务器端对其进行配置。这样就可以在A / B测试中对它们进行评估，这不仅有助于通过受控实验来衡量性能，还可以提供安全网。如果某个功能执行不佳，我们可以通过关闭该功能（受控实验中的变体）立即恢复操作，而无需经历漫长的客户端发布周期。这样可以防止最终用户在下一个版本发布之前的数周内一直被有问题的应用所困扰。

3.可以使用更细粒度的参数化，以增加创建新变量的灵活性，而无需客户端版本。这是因为即使无法轻松将新代码推送到客户端，也可以传递新配置，如果客户端了解如何解析配置，则可以有效创建新版本。例如，我们可能想尝试一次从服务器获取的提要项的数量。我们可以将该变量放在客户端代码中，然后仅尝试实验设置的值，或者可以对数字进行参数化，并可以自由地进行发布后的实验。 Windows 10在任务栏中为搜索框文本设置了参数，并在交付后的一年内进行了实验，最优版本提高了户参与度并且必应收入增加了数百万美元。另一个常见示例是从服务器更新机器学习模型参数，以便可以随时间调整模型。

尽管我们认为最好在向所有应用程序用户启动之前测试新功能，这对于用户体验来说是最好的，但应用程序商店可能存在一些限制，在这些限制下，功能可能会以暗色方式发布。我们建议仔细阅读应用商店政策，并适当披露暗色功能。

2：期望延迟记录和有效的启动时间

客户端与服务器之间有限或延迟的数据通信不仅会延迟数据的到达，还会延迟实验本身的开始时间。首先，客户端的实验代码需要随新的应用程序版本一起提供。我们可以为一小部分用户激活实验。但是，即使如此，该实验仍未完全启用，原因是：

• 用户设备可能无法获得新的实验配置，这可能是因为设备处于脱机状态，或者是由于设备处于低带宽的情况，在这种情况下推送新配置可能会导致成本增加或用户体验不佳。

• 如果仅当用户打开应用程序时才获取新的实验配置，则新配置可能要等到下一个会话才能生效，因为我们不想在用户启动当前会话后更改程序。对于每天多次启动应用用户，此延迟很小，但是对于每周访问一次的轻度用户，实验可能要到一周后才能开始。

• 可能有许多设备的旧版本没有新的实验代码，尤其是在新应用发布之后。根据我们的经验，初始采用阶段大约需要一周的时间才能达到更稳定的采用率，根据用户数量和应用类型的不同，该时间的变化可能会很大。

实验开始时间和到达服务器的仪器的这些延迟可能会影响实验分析，尤其是在分析对时间敏感的情况下，例如实时或接近实时的情况下。首先，实验开始时的信号较弱（样本量较小），并且对于倾向于早期采用的频繁用户和Wi-Fi用户也具有强烈的选择偏误。因此，可能需要延长实验的持续时间以解决延迟问题。另一个重要的因素是治疗组和对照组的有效开始时间可能不同。一些实验平台允许使用共享的Control变体，在这种情况下，Control变体可能在“干预”之前生效，因此由于选择偏见而具有不同的用户群。此外，如果控件运行得较早，则缓存会被预热，因此对服务请求的响应会更快，这可能会带来额外的偏差。因此，需要仔细选择比较治疗和控制的时间段。

3：创建故障安全处理脱机或启动案例

用户打开应用程序时，他们的设备可能处于离线状态。出于一致性的原因，我们应该缓存实验分配，以防设备离线时下次打开。此外，如果服务器未响应决定分配所需的配置，则我们应该为实验设置一个默认变体。某些应用程序也作为原始设备制造商（OEM）协议分发。在这种情况下，必须正确设置实验以获得首次运行的经验。这包括检索只会影响下次启动的配置，以及在用户注册或登录之前和之后的稳定随机化ID。

4：触发式分析可能需要客户端实验开启

为客户端实验启用触发分析可需要格外小心。例如，一种捕获触发信息的方法是在使用实验时将跟踪数据发送到服务器。但是，为了减少从客户端到服务器的通信，通常会一次（例如在应用程序启动时）为所有活动的实验获取实验分配信息，而不管是否触发了实验（请参见第20章）。在获取时依赖跟踪数据进行触发分析将导致过度触发。解决此问题的一种方法是在实际使用功能时再发送分配信息，因此需要从客户端发送实验信息。请记住，如果这些跟踪事件的数量很大，则可能会导致延迟和性能问题。

5：跟踪主要的护栏指标还有 APP 健康情况

设备级别的性能可能会影响应用程序的性能。例如，干预方法可能会消耗更多的CPU并消耗更多的电池电量。如果仅跟踪用户参与度数据，则可能不会引发电池电量耗尽的问题。另一个例子是，干预可能会向用户发送更多推送通知，然后导致用户把通知禁用级别提高。在实验过程中，这些指标可能不会表现为参与度的显着下降，但会产生长期的影响。

跟踪应用程序的整体运行状况也很重要。例如，我们应该跟踪应用程序的大小，因为较大的应用程序更有可能减少下载并导致人们卸载（Tolomei 2017，Google Developers 2019）。应用的互联网带宽消耗，电池使用率或崩溃率可能会导致类似的行为。对于崩溃，需要记录下来， 并且允许在下次启动应用时把崩溃时信息发送给服务器。

6：通过拟定的实验方法监控整个应用的发布

并非所有变化可以通过参数调整来进行 A / B 测试。如果要在整个新应用程序上真正进行随机对照实验，需要将两个版本捆绑在同一个应用程序后面，并在新版本中启动一些用户，而其他用户则保留旧版本。对于大多数应用程序来说，这是不切实际或不理想的，因为它会使应用程序的大小增加一倍。另一方面，由于并非所有用户都同时采用新的应用程序版本，因此在一段时间内我们会有两个版本的应用程序为真实用户提供服务。如果我们可以校正选择偏差，则可以有效地提供A / B比较。 Xu和Chen（2016）分享了一些技术，以消除移动采用环境中的偏见。

7：当心多个设备/平台以及它们之间的相互作用

用户通常会通过多种设备和平台（例如，台式机，移动应用程序和移动网络）访问同一站点。这可能有两个问题。

1.不同的设备上可能有不同的ID。结果，同一个用户使用不同设备时，会被当成不同的用户。 （Dmitriev et al.2016）。

2.不同设备之间可能存在潜在的相互作用。现在，包括Edge在内的许多浏览器都具有“在桌面上继续”或“在手机上继续”同步功能，以使用户可以更轻松地在台式机和手机之间进行切换。在移动应用程序和移动网络之间转移流量也是很常见的。例如，如果用户在手机上从Amazon阅读电子邮件并单击，则电子邮件链接可以将其直接带到Amazon应用程序（假设已安装该应用程序）或移动网站。在分析实验时，重要的是要知道它是否可能导致这些相互作用或遭受这些相互作用。如果是这样，我们就不能孤立地评估应用程序的性能，而需要从不同的平台上全面地研究用户行为。需要注意的另一件事是，在一个平台（通常是应用程序）上的用户体验可能比在另一个平台上的用户体验更好。将流量从应用程序定向到网络往往会降低总参与度，这可能造成困惑。

总结

我们在本章中专门讨论了瘦客户端和胖客户端上的差异。虽然有些差异是显而易见的，但许多差异是微妙的但至关重要的。我们需要格外小心，以便正确设计和分析实验。同样重要的是要指出，随着技术的快速发展，它们之间的差异也会持续演化， 产生新的差异。