Trustworthy Online Controlled Experiments Part 4 Chap 13
发生的所有事情都会按预期发生，如果您仔细观察，就会发现事情是如此。
− Marcus Aurelius
为什么重要
在进行任何实验之前，您必须具有适当的工具以记录用户和系统（例如网站，应用程序）所发生的情况。此外，每个企业都应该对系统的性能以及用户如何与之交互有一个基线的了解， 这也需要工具。在进行实验时，采集有关用户看到的内容，他们的互动（例如点击，悬停和点击时间）以及系统性能（例如等待时间）的数据至关重要。
关于如何检测系统的详细讨论超出了本书的范围，该功能高度依赖于系统体系结构（Wikipedia贡献者，.NET库和框架列表2019，Wikipedia贡献者，Logging as a Service 2019）。本章讨论了实验环境中的仪器关键点。当涉及到仪器时，隐私也是至关重要的考虑因素，我们将在第9章中进行讨论。在本书的上下文中，我们可以互换地使用“仪器”，“跟踪”和“日志”这两个术语。
客户端与服务器端工具
在准备工具时，了解客户端与服务器端会发生什么很重要（Edmons等人2007，Zhang，Joseph和Rickabaugh 2018）。客户端工具的重点是用户的体验，包括他们所看到和做的事情，例如：
-
用户操作：用户执行哪些活动，例如单击，悬停，滚动？这些是什么时候完成的？在没有服务器通信的情况下在客户端上执行了哪些操作？例如，鼠标可能徘徊在错误的位置。
-
幻灯片放映允许用户单击并翻阅幻灯片，因此捕获这些事件的时间很重要。性能：页面（网页或应用程序页面）显示或互动需要多长时间？在第5章中，我们讨论了测量从搜索查询请求到显示整个页面所需时间的复杂性。
-
错误和崩溃：JavaScript错误很常见，并且可能与浏览器有关，因此跟踪客户端软件中的错误和崩溃至关重要。
服务器端检测侧重于系统的功能，包括：
-
性能：服务器生成响应需要多长时间，哪个组件花费的时间最长？第99%百分位数的性能如何？
-
系统响应率：服务器从用户那里收到了多少个请求？服务器提供了多少页？重试如何处理？
-
系统信息：系统会抛出多少个异常或错误？高速缓存命中率是多少？
客户端工具非常有用，因为它提供了用户看到的内容和操作的视图。例如，客户端恶意软件可以覆盖正常服务器发送的内容，而这只能使用客户端工具才能发现（Kohavi等，2014）。但是，客户端工具在数据准确性和用户成本方面存在缺陷。这是基于JavaScript的客户端的特定问题（有关移动方面的问题，请参阅第12章）：
1.客户端工具可能会占用大量CPU周期和网络带宽，并耗尽设备电池，从而影响用户体验。较大的JavaScript代码段会影响加载时间。这种增加的延迟不仅会影响该次访问中的用户交互，还会影响这些用户返回的可能性（请参阅第5章）。
-
JavaScript工具可能是有Bug的（Kohavi，Longbotham和Walker 2010）：Web信标通常用于跟踪用户交互，例如，当用户单击链接进入新站点时；但是，在以下情况下，这些信标可能会丢失：
a. 一种。在成功发送Web信标之前，将加载一个新站点，这意味着可以取消和丢失该信标。由于这种竞争状况而导致的丢失率因浏览器而异。
b. 强制在新站点加载之前发送Web信标，例如通过重定向。尽管信标损耗减少，但这会导致等待时间增加，导致更糟的用户体验，并增加了用户放弃点击的可能性。
c. 可以根据应用选择实施任一方案。例如，由于必须可靠地跟踪广告点击，因为它们与付款和合规性要求有关，因此b）是首选方案，即使增加了延迟也是如此。
d. 客户端时钟可以手动或自动更改。这意味着来自客户端的实际计时可能不会与服务器时间完全同步，这必须在下游处理中加以考虑。例如，永远不要减去客户端和服务器时间，因为即使在调整了时区之后，客户时间也可能会明显偏离正确时间。
服务器端工具受这些问题的影响较小。 它对用户的实际操作不太清楚，但是可以更详细地了解系统内部发生的情况以及原因。例如，可以记录生成页面HTML的时间。由于不受网络影响，因此数据的方差往往较小，从而允许使用更敏感的指标。在搜索引擎结果中，存在内部得分，这些得分指示为什么返回特定搜索结果及其排名。记录这些分数对于调试和调整搜索算法很有用。另一个例子是记录请求来自于哪个实际服务器或数据中心，这允许调试的时候查找具体的服务器，或者数据中心。重要的是要记住，服务器也需要经常同步。在某些情况下，请求由一台服务器提供服务而信标由另一台服务器记录，从而造成时间戳不匹配。
处理来自多个来源的日志
可能会有来自不同检测流（Google 2019）的多个日志，例如：
- 来自不同客户端类型（例如浏览器，移动设备）的日志
- 来自服务器的日志
- 每个用户的状态（例如，选择加入和退出）
重要的是，确保相关的日志可以被下游处理轻松利用和合并。首先，必须有一种载入日志的方法。理想的情况是在所有日志中都具有一个公共标识符以用作联接关键字。连接键必须指出哪些事件是针对同一用户或随机单位的（请参见第14章）。您能还需要特定事件的联接键。例如，可能存在一个客户端事件，该事件表明用户已查看特定的屏幕，而相应的服务器端事件可以说明用户为何看到特定屏幕及其元素的原因。此连接键将表明哪些事件是显示给同一用户的同一事件的两个视图。
接下来，使用一些共享格式以简化下游处理。此共享格式可以是通用字段（例如时间戳，国家/地区，语言，平台）和自定义字段。公用字段通常是用于分析和定位的细分的基础。
工具的文化
工具应被视为对现场环境至关重要。想象一下在面板上破损的仪器上飞机。这显然是不安全的，但是团队可能会声称破损的仪器不会对用户造成影响。但是，他们怎能知道到底有么有问题呢？如果没有适当的工具，他们就不知道自己的判断是否正确， 就会盲目飞行。工具最困难的部分是首先让工程师进行工具测试。这种困难既源于时滞（从编写代码到检查结果的时间），也源于功能上的差异（即，开发工具的人不是分析日志的人）。以下是有关如何改善这种功能分离的一些技巧：
-
建立文化规范：没有工具就什么也没有。将工具作为规范的一部分。确保损坏的工具与损坏的软件功能具有相同的优先级。如果气压计或高度计损坏，即使它仍然可以飞行，也有可能冒险驾驶飞机。
-
在开发过程中投资测试工具。创建功能的工程师可以添加任何必要的工具，并且可以在提交代码之前（并由代码审阅者检查！）先测试工具。
-
监视原始日志的质量。这包括诸如键维度的事件数，或应该为真的不变量（即时间戳落入特定范围内）之类的东西。确保有工具可以检测异常值。当检测到工具存在问题时，开发人员应立即修复该问题。
网友评论