發送儀表板可以報告發送情況良好，而收件人說他們從未看到過該訊息。分歧通常來自不同的定義，而不是錯誤的算術。在更改基礎架構或內容之前，確定調查需要解釋哪些事件：接受責任的伺服器、特定資料夾中出現的訊息或完成預期操作的人員。
在計算費率之前定義事件
當接收系統在訊息資料後傳回相關的最終成功回應時， SMTP接受發生。它建立了責任的轉移，而不是保證人們看到了該訊息。一個應用程式說「已發送」可能只意味著它的提交服務接受了該請求。識別每個事件所代表的躍點。 RFC 5321第 3.3 節和 6.1 節.
對於提交群組接受度指標，在分母中對每個訊息和收件人提交進行一次計數，如果在視窗內的指定躍點達到接受度，則在分子中進行計數。單獨報告單獨的重試成功；不要混合這些單位。說明您如何處理重試、未解決的延期和多位收件人。將每次重試都算作新的行銷活動接收者會導致分母增大。將未解決的延遲視為永久失敗會改變問題。保持這些狀態單獨可見，直到觀察視窗關閉。
使用明確的採樣邊界測量放置
收件匣放置需要來自接收郵箱或其他明確描述的觀察方法的證據。發送方 250 回應無法告訴您選擇了哪個資料夾。種子帳戶可以提供受控觀察，但它們是一個樣本，有自己的歷史、設定和參與。不要將一個小型的種子小組作為製作觀眾的普查。
記錄提供者、郵箱類型、接收時間、觀察資料夾、樣本選擇和缺失觀察值。在將變更歸因於DNS修改之前，先比較同類樣本。如果面板在測量之間發生變化，請在百分比旁邊顯示變化。缺失的觀察應該保持未知，而不是默默地被算作收件匣或垃圾郵件。
將參與視為不完美的行為訊號
圖像請求與人閱讀不是同一事件。遺失影像請求並不能證明訊息被忽略。隱私功能和收件者內容設定可能會影響遠端內容載入； Apple 的文件描述了私人載入以及遠端內容在等待許可時被保留的情況。 Apple Mail 遠端內容指南.
點選還需要事件定義。在報告唯一收件人時消除重複點擊，公開任何過濾並將連結請求與已完成的業務操作區分開來。安全掃描和自動化客戶端是調查可疑模式而不是宣布每次點擊都是人為的原因。當實際目標是購買、預訂或確認帳戶操作時，使用核准的應用程式端完成事件。
透過有限的示例進行工作
在一個假設的手動範例中，有 1,000 次收件者嘗試提交和 950 次接受的提交，接受率為 95%。一個單獨的小組觀察了 20 個郵箱中 15 個郵箱的收件匣放置情況，其中 75% 位於該小組內。在該隊列中接受的 950 份訊息和收件人提交內容中，有 60 份在同一觀察窗口內至少有一個已記錄的連結請求。每次提交最多計算一次，得出 60/950，約 6.32%。收到兩個訊息的一個收件人可以貢獻兩次提交，因此這不是一個唯一的人的比率。這些是不同的分母，不能互相取代。
此算術使用發明的教學輸入：950/1,000用於接受，15/20用於抽樣放置，60/950用於帶有記錄的連結請求的已接受提交，在同一視窗中對每個訊息和收件人提交進行重複資料刪除。不要求腳本、郵件投遞或郵箱檢查。它不是客戶基準或提供者交付測試。它的有益教訓是，95% 的接受率和 75% 的抽樣安置可以共存，並不矛盾。點擊數也不能證明 60 個不同的人閱讀了整個訊息。
從失敗的事件中選擇下一個調查
調查接受度惡化時的交通反應。當接受度穩定但放置發生變化時，檢查接收觀察結果並發送聲譽。當訊息到達但預期的行動下降時，審查受眾的期望、內容和完成過程。將身份驗證證據保留在圖片中，而不是將其視為每個指標的答案。
關閉包含事件、分母、時間視窗、樣本限制和下一步操作的報告。由觀察結果支持的更窄的結論比單一的無法解釋的交付率更具可操作性。
選擇一個能夠回答問題的指標
- 傳輸：命名接受跳躍和接收者提交隊列。
- 放置：報告觀察到的資料夾和所選面板遺失的案例。
- 參與：區分遠端請求和已識別的人類行為。
- 完成：使用與業務目標相關的已批准的應用程式事件。
- 比較：在聲明更改之前保留分母、重試、觀察視窗和範圍。