尽管在关于如何为软件工程师实施实验的所有技术方面都有大量资源，但很少有资源专注于假设驱动的实验背后的哲学和思考过程。 结果，在选择，设计，执行和分析实验时采用的实际方法千差万别。 对于科技公司而言，这可能会导致不良的实验做法和无法采取行动（甚至产生误导）的结果，进而导致对产品做出错误的决定。 但是，通过实施一系列准则，高科技公司可以保护其产品免受许多常见实验问题的侵害。
有必要强调一些技术公司需要达到的主要检查点，以及在端到端（E2E）（实验）过程中需要避免的主要陷阱。 虽然这绝不是详尽的清单，但它应该是一个很好的起点。
处理：构想和假设提出可以长期使产品受益的功能创意并围绕这些创意形成特定的假设应该是一个持续的过程。
除了为功能提出想法之外，工程师还需要确保他们确定这些功能是否真的是适合进行实验的候选者-他们希望通过实验回答什么问题，而实验将是收集答案数据的正确方法吗？？
尽管这部分看起来有些简单，但确保工程师进行假设驱动的实验绝对至关重要。 如果他们没有明确的假设要进行实验，那么他们就没有实验期限。
没有假设就不可能进行良好的实验！
实验细节这不是完美的，但是在开始设计实验之前，值得检查一下功能更改对于保持实验是否可行。 检查区域包括但不限于：
· 效果大小：公制运动的估计值是多少，可检测到吗？
· 稀释：实验中有多少稀释？ 当测试桶或对照桶中的人员没有"触发"实验时，就会发生稀释。
· 随机污染：具有测试和控制经验的用户。
指标，KPI和启动条件
由于通常需要快速迭代，因此最好采用快速移动的代理指标来评估产品创意。 目的是促进快速测试，以便从产品构想中学习，杀死无效的构想并加倍有效的构想。
· 取得
· 订婚
· 会话号
· 所花费的时间
· 开发特定于流程/功能的UX指标以进行跟踪（例如：流程的成功/失败率）
· Guardrail指标选项-不应降级/下降的指标
· 用户错误率/服务质量下降
在实验开始之前，应该清楚地制定启动标准。 换句话说，工程师需要在启动实验之前定义什么样的"成功"，即在工程师没有说"嗯，一切都平坦/不重要的情况下，我们应该向所有人推出吗？"之后，这样定义。
有众多可供选择的指标，工程师需要非常有意识地了解KPI。
在确定KPI和启动条件之后，应该就如何更改日志记录达成一致。 如果工程师试图衡量诸如流量的成功/失败率之类的变化，这尤其重要。
此外，应该有一个概述，用于衡量定义的KPI（例如目标受众，样本量或测试持续时间）所需的记录类型。 除此之外，还可以考虑以下内容：
· 治疗次数
· 工程师试图追踪多少主要/辅助指标
通常，首选不要进行超过4周的实验，因为这样做有可能污染数据。
随机化
通常，大多数功能实验都是在用户ID级别上随机进行的，但是工程师也可能需要考虑不同的采样方法，以确保有代表性的用户群。
计算正确的样本量至关重要。
运行并监控实验工程师可以对某些新开发的功能强制执行长期（> 3个月）保留，这可以使他们检查更长期的影响（一小部分用户可能较长时间无法使用该功能）。
结果读出和建议在实验之前建立启动标准很重要。 从长远来看，在此步骤中还可能需要做出一些判断，以决定对产品进行最佳更改的方式。
一些挑战工程师在进行实验之前可能无法清楚了解所有日志记录的更改或更新，这使事后跟踪和计算指标变得颇具挑战性。 此外，它们可能无法在实验前就所有重要指标进行调整，这可能导致某些指标无法计算（与日志对齐方式结合使用会使问题更加严重）。 可以遵循有关度量标准和KPI定义的准则来避免这种情况。
(本文翻译自The AI LAB的文章《The Art of Experimentation》，参考：https://medium.com/@ailab/the-art-of-experimentation-a66bfd6dd393)
,
