Trustworthy Online Controlled Experiments Part 1 Chap 4
自己构建还是外包 ？
下图显示了Google，LinkedIn和Microsoft在过去几年中如何扩展实验规模，其中Year-1是一年，实验规模扩展到每天超过一项实验（超过365个/年）。该图显示了Bing，Google和LinkedIn在未来四年中的数量级增长。在早期，实验平台功由于功能不完善，会限制使用次数。以Microsoft Office为例，该公司于2017年才开始使用A/B Test 作为功能部署的安全部署机制， 但是对他们来说平台并不是限制因素，因为该平台先前已在Bing中使用。因此，在2018年，Microsoft A/B Test 次数就增长了600% 。当组织拥有“测试一切”的文化时，增长变慢，而此时，限制因素是将思想转换为 A/B Test 的能力。
多年来，Bing，Google，LinkedIn和Office的实验性增长。今天，Google，LinkedIn和Microsoft的运行速度超过每年20,000个受控实验，尽管统计方法有所不同（例如，将曝光率从1％的用户增加到5％到10％可以算作一到三个）。
尽管我们几个作者都在各自公司中积极参与建立内部实验平台的工作，但我们并不一定建议每个公司都应该建立自己的A/B 实验平台。特别是一开始。在决定自己建造实验平台还是购买实验平台时，有几个问题需要考虑：
外购的实验平台是否可以满足要求？
考虑要运行的实验类型，例如前端与后端，服务器与客户端或移动与网络。许多第三方解决方案的通用性不足以涵盖所有类型。例如，基于JavaScript的解决方案不适用于后端实验，或者无法很好地扩展用于许多并发实验。一些供应商在一个渠道上很强，但在其他渠道上却不强（例如，用于移动设备的出色SDK，但处理Web的能力较弱；或用于web的强大的所见即所得编辑器，在移动设备上就会经常崩溃）。
考虑网站速度。几个外部解决方案需要附加的JavaScript，这会减慢页面加载速度（Optimizely 2018，Kingston 2015，Neumann 2017，Kesar 2018，Abrahamse 2016）。如第5章所示，增加的延迟会影响用户的参与度。
考虑可能要使用的规模和指标。例如，某些外部平台会限制你可以使用的指标。在外部工具中可能无法使用复杂指标。即使是百分位数之类的指标（通常用于衡量尾部延迟，它比平均值往往更敏感）也常常不被支持。由于业务报告往往时分散建立的（不同部门单独build 自己的报告），如果使用不同工具，将难以建立通用语言，在这种情况下，确保公司内部一致性可能会更加困难。
考虑要使用的随机化机制以及可接受的数据共享（例如，确保尊重用户隐私）。通常，可以将哪些信息（尤其是有关用户的信息，请参阅第9章）传递给外部方是受限制的，这可能会限制或导致额外的费用。
记录到外部的数据是否易于访问？客户是否需要登录到两个地方（两次登录）？当汇总统计信息发生差异时会发生什么？有调和的工具吗？这些通常是被低估的复杂性，它们降低了信任度，并提出了有关不同系统可靠性的问题。
可以整合其他数据源吗？需要整合购买数据，退货，人口统计信息吗？注意，某些外部系统不允许您加入此类外部数据。
是否需要近实时（NRT）结果？这些通常对于快速检测和停止不良实验很有用。
是否进行了足够的实验以建立自己的机构记忆？许多第三方实验系统没有机构记忆功能。
可以在其最终版本中实现需要的功能吗？许多所见即所得的系统都要求用户重新实现功能，以进行真正的后期实验。这可能会限制实验的规模， 因为你要重新实现一堆功能。
自建一个测试平台成本有多高？
自建测试平台时一个艰难而且花费很多的过程， 我们会在后续章节中展示。
你的实验需求轨迹是什么？
这种类型的基础设施投资与预期有关，也就是说，如果组织准备真正接受A/B Test，它未来将进行多少次实验？ 而不是当前要运行多少次。如果存在足够的需求，并且数量可能会超出外部解决方案所能容纳的范围，那就可以自建。构建内部解决方案需要花费更长的时间，但是集成外部解决方案也需要付出努力，特别是如果需要随着公司规模的扩大而切换到其他解决方案时。
需要集成到系统的配置和部署方法中吗？？
实验可以是连续部署过程中不可或缺的一部分。实验与工程系统如何处理配置和部署之间有很多协同作用（请参阅第15章）。如果需要集成（例如对于更复杂的调试情况），则使用第三方解决方案可能会更困难。
当组织尚未准备好构建自己的平台的投资时，可以利用外部解决方案进行先期尝试。
