[也適用於v8]{class="badge positive" title="亦適用於Campaign v8"}
認識隔離管理 understanding-quarantine-management
Adobe Campaign 管理隔離地址清單。在執行傳遞分析時，預設情況下將不會向被隔離的收件者的電郵地址傳送內容。舉例來說，信箱已滿或地址不存在時，可以隔離電子郵件地址。 在任何情況下，隔離程式都符合下述的特定規則。
透過隔離管理最佳化您的傳遞 optimizing-your-delivery-through-quarantines
郵件準備期間會自動排除其電子郵件地址或電話號碼處於隔離狀態的設定檔（請參閱識別傳送的隔離地址）。 這會加快傳送速度，因為錯誤率對傳送速度有顯著影響。
如果無效地址的比率過高，某些網際網路存取提供者會自動將電子郵件視為垃圾郵件。因此，隔離可讓您避免被這些提供者新增到封鎖清單中。
此外，隔離有助於減少簡訊傳送成本，因為將錯誤的電話號碼排除在遞送服務之外。
如需確保傳送安全並最佳化的最佳實務，請參閱本頁面。
隔離與封鎖清單 quarantine-vs-denylist
隔離和封鎖清單不適用於相同的物件：
-
隔離 只適用於 位址 （或電話號碼等），不適用於設定檔本身。 例如，被隔離的電子郵件地址的設定檔可以更新其設定檔並輸入新地址，然後再次被傳送動作設為目標。 同樣地，如果兩個設定檔碰巧擁有相同的電話號碼，則兩個設定檔在隔離該號碼時都會受到影響。
-
另一方面，如果位於 封鎖清單，則會導致 設定檔 不再被傳遞設為目標，例如在特定頻道的取消訂閱（選擇退出）之後。 例如，如果電子郵件頻道封鎖清單上的設定檔有兩個電子郵件地址，則兩個地址都會從傳送中排除。
您可以在設定檔的 General 索引標籤的 No longer contact 區段中，檢查設定檔是否位於一或多個頻道的封鎖清單中。 請參閱本節。
識別隔離的地址 identifying-quarantined-addresses
可以為特定傳送或整個平台列出隔離的地址。
識別傳送的隔離地址 identifying-quarantined-addresses-for-a-delivery
在傳送準備階段期間，會將特定傳送的隔離地址列在傳送儀表板的傳送記錄中（請參閱傳送記錄與歷史記錄）。
識別整個平台的隔離地址 identifying-quarantined-addresses-for-the-entire-platform
管理員可以列出來自 Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses 節點的整個平台之隔離區中的地址。
每個位址都有以下資訊：
識別傳遞報表中的隔離地址 identifying-quarantined-addresses-in-delivery-reports
下列報表提供關於隔離中地址的資訊：
-
對於每個傳遞，Delivery summary 報告都會顯示傳遞目標中隔離的地址數量。 它顯示：
-
傳遞分析期間被置於隔離的地址數量；
-
進行傳送動作後置於隔離區的地址數。
-
-
Non-deliverables and bounces 報告會顯示隔離中地址、遇到的錯誤型別等資訊，以及依網域劃分的失敗資訊。
您可以查詢此資訊以取得平台(Home page > Reports)的所有傳遞或特定傳遞。 您也可以建立自訂報表，並選取要顯示的資訊。
識別收件者的隔離地址 identifying-quarantined-addresses-for-a-recipient
您可以查詢任何收件者之電子郵件地址的狀態。 若要這麼做，請選取收件者設定檔，然後按一下 Deliveries 標籤。 對於傳送給該收件者的所有郵件，您可以檢視該地址是否失敗、在分析期間是否被隔離等。 對於每個資料夾，您只能顯示其電子郵件地址處於隔離狀態的收件者。 若要這麼做，請使用 Quarantined email address 應用程式篩選器。
將地址傳送到隔離區的條件 conditions-for-sending-an-address-to-quarantine
Adobe Campaign會根據傳送失敗型別和錯誤訊息限定期間指派的原因來管理隔離區（請參閱退回郵件限定和傳送失敗型別和原因）。
- 忽略錯誤：忽略的錯誤不會傳送要隔離的地址。
- 硬錯誤：會立即將相對應的電子郵件地址傳送至隔離區。
- 軟錯誤：軟錯誤不會立即傳送要隔離的地址，但會增加錯誤計數器。如需詳細資訊，請參閱軟性錯誤管理。
如果使用者將電子郵件歸類為垃圾訊息（回饋迴路），郵件會自動重新導向至由Adobe管理的技術信箱。 之後，系統會自動將使用者的電子郵件地址傳送到狀態為 Denylisted 的隔離區。此狀態僅適用於地址，而且設定檔不在封鎖清單中，因此使用者會繼續收到SMS訊息和推播通知。
在隔離地址清單中（請參閱識別整個平台的隔離地址），Error reason 欄位會指出所選地址被置於隔離狀態的原因。
軟性錯誤管理 soft-error-management
與硬錯誤相反，軟錯誤不會立即傳送要隔離的地址，而是會增加錯誤計數器。
將在傳遞期間執行重試。 當錯誤計數器達到限制臨界值時，該地址就會進入隔離區。如需詳細資訊，請參閱傳送暫時失敗後重試。
如果最後一次重大錯誤發生在10天以前，則會重新初始化錯誤計數器。 然後，位址狀態會變更為 有效，而且會由資料庫清理工作流程從隔離清單中刪除該位址。
對於託管或混合安裝，如果您已升級至增強型MTA，在 Erroneous 狀態的情況下要執行的最大重試次數和重試之間的最小延遲，現在取決於IP在歷史和目前指定網域的執行狀況。
對於使用舊版Campaign MTA的內部部署安裝和託管/混合安裝，您可以修改錯誤數量和兩個錯誤之間的期間。 若要這麼做，請變更部署精靈 (Email channel > Advanced parameters)或傳遞層級🔗的中的對應設定。
從隔離中移除地址 removing-a-quarantined-address
自動更新 unquarantine-auto
符合特定條件的地址會由資料庫清理工作流程自動從隔離清單中刪除。
在下列情況下，地址會自動從隔離清單中移除：
- 成功傳送後，會從隔離清單中移除 With errors 狀態的地址。
- 如果最後一次軟退信發生於10天以前，則會從隔離清單中移除 With errors 狀態的地址。 如需軟性錯誤管理的詳細資訊，請參閱本節。
- 狀態為 With errors 且出現 Mailbox full 錯誤退信的地址將在30天後從隔離清單中移除。
其狀態然後變更為 Valid。
手動更新 unquarantine-manual
您也可以手動解除隔離地址。 若要從隔離清單手動移除地址，請將其狀態從 Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses 節點變更為 Valid。
大量更新 unquarantine-bulk
您可能需要對隔離清單執行大量更新，例如ISP中斷的情況。 在這種情況下，電子郵件會錯誤標籤為退回，因為它們無法成功傳遞給收件者。 必須從隔離清單中移除這些地址。
若要執行此動作，請建立工作流程，並在隔離表格上新增 Query 活動，以篩選出所有受影響的收件者。 識別後，可將它們從隔離清單中移除，並包含在未來的Campaign電子郵件傳送中。
以下是此查詢的建議准則：
-
對於在隔離清單的 Error text 欄位中有傳入電子郵件規則資訊的Campaign Classic v7環境：
- 錯誤文字（隔離文字） 包含「Momen_Code10_InvalidRecipient」
- 電子郵件網域(@domain) 等於domain1.com或 電子郵件網域(@domain) 等於domain2.com或 電子郵件網域(@domain) 等於domain3.com
- 在
MM/DD/YYYY HH:MM:SS AM或之後的 更新狀態(@lastModified) - 在
MM/DD/YYYY HH:MM:SS PM或之前的 更新狀態(@lastModified)
-
對於在隔離清單的 Error text 欄位中有SMTP退回回應資訊的Campaign Classicv7執行個體：
- 錯誤文字（隔離文字） 包含「550-5.1.1」且 錯誤文字（隔離文字） 包含「support.ISP.com」
其中「support.ISP.com」可以是：例如「support.apple.com」或「support.google.com」
- 在
MM/DD/YYYY HH:MM:SS AM或之後的 更新狀態(@lastModified) - 在
MM/DD/YYYY HH:MM:SS PM或之前的 更新狀態(@lastModified)
取得受影響的收件者清單後，請新增 Update data 活動以將其電子郵件地址狀態設定為 Valid，以便透過 Database cleanup 工作流程將其從隔離清單中移除。 您也可以從隔離表中刪除它們。
推播通知隔離 push-notification-quarantines
推播通知的隔離機制與一般程式整體相同。 不過，推播通知的特定錯誤會以不同方式管理。 例如，對於某些軟錯誤，不會在同一傳送中執行重試。 推播通知的特定性列於下方。 重試機制（重試次數、頻率）與電子郵件的相同。
被隔離的專案是裝置代號。
iOS隔離 ios-quarantine
HTTP/V2通訊協定允許每個推播傳遞有直接的回饋和狀態。 如果使用HTTP/V2通訊協定聯結器，mobileAppOptOutMgt 工作流程將不再呼叫意見回饋服務。 解除安裝或重新安裝行動應用程式時，Token會視為已解除註冊。
同步時，如果APN針對訊息傳回「未註冊」狀態，則目標Token會立即置於隔離中。
Android隔離 android-quarantine
適用於Android V1 的
對於每個通知，Adobe Campaign會直接從FCM伺服器接收同步錯誤。 Adobe行銷活動會即時處理這些錯誤，並根據錯誤的嚴重性產生硬或軟錯誤，且可執行重試：
- 已超過承載長度、連線問題、服務可用性問題：已執行重試、軟錯誤、失敗原因為 Refused。
- 超過裝置配額：沒有重試、軟錯誤、失敗原因為 Refused。
- 無效的或未登入權杖、未預期的錯誤、寄件者帳戶問題：無重試、硬錯誤、失敗原因為 Refused。
mobileAppOptOutMgt 工作流程每6小時執行一次，以更新 AppSubscriptionRcp 資料表。 對於宣告為未登入或不再有效的權杖，Disabled 欄位設為 True，而且連結至該裝置權杖的訂閱將會自動從未來的傳遞中排除。
在傳遞分析期間，所有從目標排除的裝置都會自動新增至 excludeLogAppSubRcp 表格。
- 傳遞開始時的連線問題：失敗型別 Undefined，失敗原因 Unreachable，已執行重試。
- 傳遞期間連線中斷：軟錯誤，失敗原因 Refused，已執行重試。
- 百度在傳送期間傳回同步錯誤：硬錯誤，失敗原因 Refused，不執行重試。
適用於Android V2 的
Android V2隔離機制使用與Android V1相同的流程，同樣適用於訂閱和排除更新。 如需詳細資訊，請參閱Android V1區段。
SMS隔離 sms-quarantines
適用於標準聯結器
SMS訊息的隔離機制與一般程式在整體上相同。 請參閱關於隔離。 簡訊的特定性列於下方。
延伸通用SMPP聯結器的
使用SMPP通訊協定傳送SMS訊息時，錯誤管理的處理方式不同。 如需有關Extended generic SMPP聯結器的詳細資訊，請參閱此頁面。
SMPP聯結器會擷取使用規則運算式（規則運算式）傳回之SR （狀態報告）訊息的資料，以篩選其內容。 然後，此資料會與 Delivery log qualification 資料表中的資訊進行比對（可透過 Administration > Campaign Management > Non deliverables Management 功能表取得）。
在限定新型別的錯誤之前，失敗原因預設一律設為 已拒絕。
產生的訊息範例：
SR Generic DELIVRD 000|#MESSAGE#
-
所有錯誤訊息都以 SR 開頭，以區分SMS錯誤碼與電子郵件錯誤碼。
-
錯誤訊息的第二部分（Generic，在此範例中）參考SMSC實作的名稱，例如SMS外部帳戶的 SMSC implementation name 欄位中定義的名稱。 請參閱此頁面。
由於對於每個提供者，相同的錯誤碼可能有不同的含義，因此此欄位可讓您知道產生錯誤碼的提供者。 然後您可以在相關提供者的檔案中找到錯誤。
-
錯誤訊息的第三部分（此範例中為 DELIVRD）對應於使用SMS外部帳戶中定義的狀態擷取規則運算式從SR擷取的狀態代碼。
此規則運算式指定於外部帳戶的 SMSC specificities 索引標籤中。 請參閱此頁面。
依預設，規則運算式會擷取 SMPP 3.4規格 的 附錄B 區段所定義的 stat： 欄位。
-
錯誤訊息的第四部分(000)對應於使用SMS外部帳戶中定義的錯誤碼擷取規則運算式從SR擷取的錯誤碼。
此規則運算式指定於外部帳戶的 SMSC specificities 索引標籤中。 請參閱此頁面。
依預設，規則運算式會擷取 SMPP 3.4規格 的 附錄B 區段所定義的 err： 欄位。
-
直立線符號(|)後面的所有專案只會顯示在 Delivery log qualification 表格的 First text 欄中。 訊息標準化之後，此內容一律會由 #MESSAGE# 取代。 此程式會避免因類似錯誤而出現多個專案，與電子郵件的情況相同。 如需詳細資訊，請參閱退回郵件資格。
Extended generic SMPP聯結器會套用啟發式來尋找合理的預設值：如果狀態以 DELIV 開頭，則會被視為成功，因為它符合大多數提供者使用的一般狀態 DELIVRD 或 DELIVERED。 任何其他狀態都會導致硬失敗。