種子測試回答了一個有用但狹隘的問題：特定的測試郵件出現在選定郵箱中的何處？它不會自動回答所有生產接收者在哪裡看到了行銷活動。設計測試，以便在任何人使用結果來證明重大基礎設施變更的合理性之前明確其限制。
選擇您需要觀察的事件
SMTP接受和郵箱放置是不同的事件。最終SMTP成功建立了接收躍點的責任，而不是可見的資料夾或人工互動。將發送日誌與郵箱觀察一起保存，但不要用其中一個替換另一個。 RFC 5321.
定義您的報表區分的資料夾或類別。收件匣、垃圾郵件、隔離區、遺失和未觀察到的內容不應在沒有解釋的情況下折疊成單一二進位值。一個提供者的類別也可能不同於另一個提供者的資料夾模型。記錄實際標籤和報告映射。
保持樣本足夠穩定以進行比較
記錄每個測試郵箱的提供者、帳戶類型、相關規則和最近的測試歷史記錄。使用您有權檢查的帳戶。個人過濾器、許可名單和先前的互動可能會使種子的行為與目標受眾不同。重複開啟每個測試郵件本身可能會變更郵箱歷史記錄。
為了進行比較，除了實際調查的變數外，請保持收件人面板、訊息構造和發送路由固定。保留完整的測試修訂版和路線識別碼。如果多項內容同時發生變化，請將結果報告為綜合變化，而不是僅將其歸因於新的主題行或 IP。
完成一個缺失觀察值的例子
假設的面板包含 20 個發明的種子：12 個收件匣、4 個垃圾郵件和 4 個未被觀察到的種子。僅觀察收件匣比例為 12 除以 16，即 75%。收件匣中確認的整個面板的比例為 12 除以 20，即 60%。這兩種說法都可能是正確的，因為它們回答了不同的問題。
未被觀察到的四個郵件不會自動變成垃圾郵件。它們需要進一步檢查或必須保持失踪狀態。手動計算保留了所有四個未知的觀察結果；沒有聲明任何腳本或郵箱測試。它不會發送郵件或檢查真實的種子帳戶，這兩個百分比都不是關於製作受眾的聲明。
將變化解釋為假設的證據
假設一個提供者的受控測試有所改善，而另一提供者保持不變。結果是檢查特定於提供者的路由、訊息處理和樣本條件的原因。這並不能證明普遍聲譽分數有所提升。同樣，乾淨的種子結果不能排除影響不同收件者或路線的問題。
使用其他訊號，例如實際拒絕診斷、授權接收者報告和提供者自己的範圍遙測。例如，Google 描述了 Postmaster 對個人Gmail流量的觀察結果，而不是對每個可能的目的地的觀察結果。 郵政局長儀表板。合併證據時保持這個範圍。
報告決定及其限制
有用的測試報告會命名訊息修訂、路由、面板、時間戳記、資料夾觀察結果和缺失資料。然後它說明結果支持哪個假設以及保留哪些替代方案。不要從缺乏適當抽樣設計的便利面板中建立整體信賴區間。
選擇可以區分其餘原因的下一個最小的調查。重複進行受控變更或在獲得許可的情況下取得相關生產樣品。種子測試的價值在於嚴格的觀察，而不是保證每個接受者獲得相同體驗的百分比。
選擇下一個檢查四個未知數
透過假設兩個未觀察到的種子已確認最終SMTP接受而兩個缺乏確認的傳輸結果來擴展假設面板。對於第一對，請向授權郵箱所有者詢問資料夾、隔離或規則證據。對於第二對，首先取得發送佇列和事務追蹤。這些是不同的缺失階段，而不是四個測量的垃圾郵件放置位置。
為每個種子使用一行及其穩定標籤、測試修訂、路由、時間戳記、 SMTP狀態、資料夾觀察和未解決的檢查。僅在雙方同意的情況下指定實際收集員。這是建議的報告結構，而不是提供者匯出或執行的分類。當所需證據不可用時，爭議可能仍懸而未決。
在其階段解決每個缺失的觀察結果
- 已接受並觀察收件匣：記錄郵箱證據和時間。
- 已接受和觀察到垃圾郵件：檢查適用的接收處理。
- 已接受但未觀察到：取得授權資料夾或隔離證據。
- SMTP結果未知：首先收集發送和接收追蹤。
- 報告：使所有未解決的行保持可見，並避免將便利面板推斷給每個人。