种子测试回答了一个有用但狭隘的问题：特定的测试邮件出现在选定邮箱中的何处？它不会自动回答所有生产接收者在哪里看到了营销活动。设计测试，以便在任何人使用结果来证明重大基础设施变更的合理性之前明确其限制。
选择您需要观察的事件
SMTP接受和邮箱放置是不同的事件。最终SMTP成功建立了接收跃点的责任，而不是可见的文件夹或人工交互。将发送日志与邮箱观察一起保存，但不要用其中之一替换另一个。 RFC 5321.
定义您的报告区分的文件夹或类别。收件箱、垃圾邮件、隔离区、丢失和未观察到的内容不应在没有解释的情况下折叠成单个二进制值。一个提供者的类别也可能不同于另一个提供者的文件夹模型。记录实际标签和报告映射。
保持样本足够稳定以进行比较
记录每个测试邮箱的提供商、帐户类型、相关规则和最近的测试历史记录。使用您有权检查的帐户。个人过滤器、许可名单和之前的互动可能会使种子的行为与目标受众不同。重复打开每条测试邮件本身可能会更改邮箱历史记录。
为了进行比较，除了实际调查的变量外，保持收件人面板、消息构造和发送路由固定。保留完整的测试修订版和路线标识符。如果多项内容同时发生变化，请将结果报告为综合变化，而不是仅将其归因于新的主题行或 IP。
完成一个缺失观察的例子
假设的面板包含 20 个发明的种子：12 个收件箱、4 个垃圾邮件和 4 个未被观察到的种子。仅观察收件箱比例为 12 除以 16，即 75%。收件箱中确认的整个面板的比例为 12 除以 20，即 60%。这两种说法都可能是正确的，因为它们回答了不同的问题。
未被观察到的四个邮件不会自动成为垃圾邮件。它们需要进一步检查或必须保持失踪状态。手工计算保留了所有四个未知的观察结果；没有声明任何脚本或邮箱测试。它不发送邮件或检查真实的种子帐户，并且这两个百分比都不是关于制作受众的声明。
将变化解释为假设的证据
假设一个提供商的受控测试有所改善，而另一提供商保持不变。结果是检查特定于提供商的路由、消息处理和样本条件的原因。这并不能证明普遍声誉得分有所提高。同样，干净的种子结果不能排除影响不同收件人或路线的问题。
使用其他信号，例如实际拒绝诊断、授权接收者报告和提供商自己的范围遥测。例如，Google 描述了 Postmaster 对个人Gmail流量的观察结果，而不是对每个可能的目的地的观察结果。 邮政局长仪表板。合并证据时保持这个范围。
报告决定及其限制
有用的测试报告会命名消息修订、路由、面板、时间戳、文件夹观察结果和缺失数据。然后它说明结果支持哪个假设以及保留哪些替代方案。不要从缺乏适当抽样设计的便利面板中创建总体置信区间。
选择可以区分其余原因的下一个最小的调查。重复进行受控更改或在获得许可的情况下获取相关生产样品。种子测试的价值在于严格的观察，而不是保证每个接受者获得相同体验的百分比。
选择下一个检查四个未知数
通过假设两个未观察到的种子已确认最终SMTP接受而两个缺乏确认的传输结果来扩展假设面板。对于第一对，请向授权邮箱所有者询问文件夹、隔离或规则证据。对于第二对，首先获取发送队列和事务跟踪。这些是不同的缺失阶段，而不是四个测量的垃圾邮件放置位置。
为每个种子使用一行及其稳定标签、测试修订、路由、时间戳、 SMTP状态、文件夹观察和未解决的检查。仅在双方同意的情况下指定实际收集员。这是建议的报告结构，而不是提供商导出或执行的分类。当所需证据不可用时，争议可能仍悬而未决。
在其阶段解决每个缺失的观察结果
- 已接受并观察收件箱：记录邮箱证据和时间。
- 已接受和观察到垃圾邮件：检查适用的接收处理。
- 已接受但未观察到：获取授权文件夹或隔离证据。
- SMTP结果未知：首先收集发送和接收跟踪。
- 报告：使所有未解决的行保持可见，并避免将便利面板推断给每个人。