[v8 にも適用されます]{class="badge positive" title="Campaign v8 にも適用されます"}
強制隔離管理について understanding-quarantine-management
Adobe Campaign では、強制隔離されたアドレスのリストを管理します。アドレスが強制隔離されている受信者は、配信分析時にデフォルトで除外され、ターゲットにされなくなります。例えば、メールボックスの容量が超過している場合や、アドレスが存在しない場合などに、メールアドレスを強制隔離できます。どのような場合でも、強制隔離手順は、次に説明する特定のルールに従います。
強制隔離管理により配信を最適化 optimizing-your-delivery-through-quarantines
メールアドレスまたは電話番号が強制隔離されているプロファイルは、メッセージ準備の際に自動的に除外されます（配信用の強制隔離アドレスを識別を参照）。これによって配信が迅速になります。エラー率は配信の速度に大きく影響するからです。
一部のインターネットアクセスプロバイダーは、無効なアドレスの割合が高すぎる場合、メールを自動的にスパムと見なします。したがって、強制隔離を使用すると、これらのプロバイダーによってブロックリストに追加されるのを回避できます。
また、強制隔離は、誤りのある電話番号を配信から除外することで、SMS の送信コスト削減にも役立ちます。
配信を保護および最適化するベストプラクティスについて詳しくは、このページを参照してください。
強制隔離とブロックリストの比較 quarantine-vs-denylist
強制隔離とブロックリストは、同じオブジェクトには適用されません。
-
強制隔離 は、プロファイル自体ではなく、アドレス（または電話番号など）にのみ適用されます。例えば、メールアドレスが強制隔離されているプロファイルは、プロファイルを更新して新しいアドレスを入力できるので、再び配信アクションのターゲットになる可能性があります。同様に、2 つのプロファイルの電話番号が同じ場合、その番号が強制隔離されると、両方のプロファイルが影響を受けます。
強制隔離されたアドレスまたは電話番号は、除外ログ（配信の場合）または強制隔離リスト（プラットフォーム全体の場合）に表示されます。
-
一方、ブロックリスト への登録では、特定のチャネルを購読解除（オプトアウト）した後などは、プロファイル は配信のターゲットとなりません。例えば、メールチャネルのブロックリストのプロファイルに 2 つのメールアドレスがある場合、両方のアドレスが配信から除外されます。
プロファイルが 1 つ以上のチャネルのブロックリストに含まれているかどうかは、プロファイルの「一般」タブの「今後の連絡は不要」セクションで確認できます。詳しくは、この節を参照してください。
強制隔離されたアドレスを識別 identifying-quarantined-addresses
強制隔離されたアドレスは、特定の配信先またはプラットフォーム全体について一覧表示できます。
配信用の強制隔離アドレスを識別 identifying-quarantined-addresses-for-a-delivery
特定の配信で強制隔離されたアドレスは、配信準備フェーズ中に配信ダッシュボードの配信ログに一覧表示されます（配信ログおよび履歴を参照）。
プラットフォーム全体の強制隔離アドレスを識別 identifying-quarantined-addresses-for-the-entire-platform
管理者は、プラットフォーム全体で強制隔離されたアドレスのリストを 管理者／キャンペーン管理／配信不能件数の管理／配信不能件数およびアドレス ノードで表示できます。
アドレスごとに次の情報を表示できます。
配信レポートの強制隔離アドレスを識別 identifying-quarantined-addresses-in-delivery-reports
次のレポートには、強制隔離中のアドレスに関する情報が含まれます。
-
配信ごとに、配信ターゲットに含まれている強制隔離中のアドレス数が 配信の概要 レポートに表示されます。次のものが表示されます。
-
配信分析時に強制隔離されたアドレス数
-
配信アクション後に強制隔離されたアドレス数
-
-
配達不能件数とバウンス数 レポートには、強制隔離中のアドレスや発生したエラーのタイプなどに関する情報が表示され、エラーがドメイン別に分類されます。
プラットフォームのすべての配信について（ホームページ／レポート）または特定の配信について、この情報を調べることができます。カスタマイズされたレポートを作成して、表示する情報を選択することもできます。
受信者の強制隔離アドレスを識別 identifying-quarantined-addresses-for-a-recipient
あらゆる受信者のメールアドレスのステータスを調べることができます。そのためには、受信者のプロファイルを選択し、「配信」タブをクリックします。その受信者へのすべての配信について、アドレスへの配信が失敗したかどうか、分析時に強制隔離されたかどうかなどを調べることができます。フォルダーごとに、メールアドレスが強制隔離中の受信者のみを表示できます。そのためには、強制隔離されたメールアドレス アプリケーションフィルターを使用します。
アドレスを強制隔離に送信するための条件 conditions-for-sending-an-address-to-quarantine
Adobe Campaign では、エラーメッセージの選定で割り当てられた配信のエラータイプと理由に応じて強制隔離を管理します（バウンスメールの選定および配信のエラータイプと理由を参照）。
- 無視のエラー：アドレスを強制隔離しません。
- ハードエラー：対応するメールアドレスがただちに強制隔離されます。
- ソフトエラー：ただちにアドレスが強制隔離されることはありませんが、エラーカウンターがインクリメントされます。詳しくは、ソフトエラー管理を参照してください。
ユーザーがメールをスパム（フィードバックループ）と見なした場合、メッセージは、アドビが管理するテクニカルメールボックスに自動的にリダイレクトされます。さらに、そのメールアドレスは自動的に強制隔離され、ステータスが「ブロックリスト登録済み」となります。このステータスはアドレスのみに適用され、プロファイルはブロックリストに登録されていないので、ユーザーは引き続き SMS メッセージやプッシュ通知を受信します。
隔離されたアドレスのリスト（プラットフォーム全体の強制隔離されたアドレスの識別を参照）の「エラー理由」フィールドは、選択したアドレスが強制隔離された理由を示します。
ソフトエラー管理 soft-error-management
ハードエラーとは異なり、ソフトエラーでただちにアドレスが強制隔離されることはありませんが、エラーカウンターがインクリメントされます。
再試行は、配信期間中に実行されます。エラーカウンターが制限しきい値に達すると、アドレスが強制隔離されます。詳しくは、一時的な配信エラーの後の再試行を参照してください。
最後に重大なエラーが発生したのが 10 日以上前の場合、エラーカウンターが再初期化されます。アドレスのステータスが「有効」に変わり、データベースクリーンアップワークフローが強制隔離のリストからアドレスを削除します。
ホストインストールまたはハイブリッドインストールで、Enhanced MTA にアップグレードした場合、エラー ステータスの場合に実行される再試行の最大数および再試行間の最小遅延は現在、IP が特定のドメインで過去と現在の両方でどの程度機能しているかに基づいています。
従来の Campaign MTA を使用したオンプレミスインストールおよびホスト／ハイブリッドインストールの場合、エラーの数と 2 つのエラーの間の期間を変更できます。これを行うには、デプロイメントウィザード（メールチャネル／詳細設定パラメーター）または配信レベルで対応する設定を変更します。
強制隔離からアドレスの削除 removing-a-quarantined-address
自動更新 unquarantine-auto
特定の条件に一致するアドレスは、データベースクリーンアップワークフローによって強制隔離リストから自動的に削除されます。
次の場合、アドレスは強制隔離リストから自動的に削除されます。
- 「エラーあり」ステータスのアドレスは、配信が正常に完了すると、強制隔離リストから削除されます。
- 「エラーあり」ステータスのアドレスは、最後のソフトバウンスが 10 日以上前に発生した場合に、強制隔離リストから削除されます。ソフトエラー管理について詳しくは、この節を参照してください。
- 「エラーあり」ステータスのアドレスで、メールボックス容量超過 エラーでバウンスしたアドレスは、30 日後に強制隔離リストから削除されます。
その後、ステータスは「有効」に変わります。
手動更新 unquarantine-manual
アドレスの強制隔離を手動で解除することもできます。 強制隔離リストからアドレスを手動で削除するには、ステータスを「有効」に変更します（管理／キャンペーン管理／配信不能件数の管理／配信不能件数およびアドレス ノードから）。
一括更新 unquarantine-bulk
例えば、ISP が停止した場合など、強制隔離リストで一括更新を実行する必要が生じる場合があります。 この場合、メールは受信者に正常に配信されないため、誤ってバウンスとマークされます。強制隔離リストからこれらのアドレスを削除する必要があります。
これを実行するには、ワークフローを作成し、強制隔離テーブルに クエリ アクティビティを追加して、影響を受けたすべての受信者を除外します。 特定されると、それらは強制隔離リストから削除され、今後のキャンペーンメール配信に含めることができます。
このクエリで推奨されるガイドラインを次に示します。
-
強制隔離リストの エラーテキスト フィールドにインバウンドメールルール情報が含まれている Campaign Classic v7 環境の場合：
- エラーテキスト（強制隔離テキスト） に「Momen_Code10_InvalidRecipient」が含まれる
- メールドメイン（@domain） が domain1.com と等しい、または メールドメイン（@domain） が domain2.com と等しい、または メールドメイン（@domain） が domain3.com と等しい
- 更新ステータス（@lastModified） が
MM/DD/YYYY HH:MM:SS AM以降 - 更新ステータス（@lastModified） が
MM/DD/YYYY HH:MM:SS PM以前
-
強制隔離リストの「エラーテキスト」フィールドに SMTP バウンス応答情報が含まれている Campaign Classic v7 インスタンスの場合：
- エラーテキスト（強制隔離テキスト） には、「550-5.1.1」が含まれ、かつ エラーテキスト（強制隔離テキスト） には、「support.ISP.com」が含まれている
例えば、「support.ISP.com」は「support.apple.com」または「support.google.com」になります
- 更新ステータス（@lastModified） が
MM/DD/YYYY HH:MM:SS AM以降 - 更新ステータス（@lastModified） が
MM/DD/YYYY HH:MM:SS PM以前
影響を受ける受信者のリストを受信したら、データを更新 アクティビティを追加して、メールアドレスのステータスを「有効」に設定し、データベースクリーンアップ ワークフローで強制隔離リストから削除されるようにします。また、強制隔離テーブルから削除するだけでもかまいません。
プッシュ通知の強制隔離 push-notification-quarantines
プッシュ通知の強制隔離メカニズムは、全体として通常のプロセスと同じです。ただし、プッシュ通知では一部のエラーの管理方法が異なります。例えば、一部のソフトエラーでは、同じ配信の再試行は実行されません。プッシュ通知特有の方式を以下に示します。再試行の方式（再試行の回数、頻度）はメールの場合と同じです。
強制隔離される項目はデバイストークンです。
iOS での強制隔離 ios-quarantine
HTTP/V2 プロトコルでは、プッシュ配信ごとの直接フィードバックおよびステータスを使用できます。HTTP/V2 プロトコルコネクタを使用する場合、フィードバックサービスが mobileAppOptOutMgt ワークフローによって呼び出されることはありません。モバイルアプリケーションのアンインストールまたは再インストールがおこなわれた場合、トークンは登録解除されたものとみなされます。
同時に、APNs がメッセージに対して登録解除ステータスを返した場合、ターゲットトークンはただちに強制隔離されます。
Android での強制隔離 android-quarantine
Android V1 の場合
Adobe Campaign は通知ごとに FCM サーバーから直接同期エラーを受け取ります。Adobe Campaign はこれを即時に処理し、エラーの重大度に応じてハードエラーまたはソフトエラーを生成します。これにより再試行が実行できるようになります。
- ペイロードの長さの超過、接続の問題、サービスの使用可否の問題：再試行が実行され、ソフトエラーが生成されます。エラーの理由は「拒否」です。
- デバイスの割当量の超過：再試行はなく、ソフトエラーが生成されます。エラーの理由は「拒否」です。
- 無効または登録解除されたトークン、予期しないエラー、送信者のアカウントの問題：再試行はなく、ハードエラーが生成されます。エラーの理由は「拒否」です。
mobileAppOptOutMgt ワークフローは 6 時間ごとに実行されます。このワークフローは AppSubscriptionRcp テーブルを更新します。登録解除または無効と宣言されたトークンについて、「無効」フィールドが「True」に設定され、そのデバイストークンにリンクされている購読は自動的にそれ以降の配信から除外されます。
配信分析中に、ターゲットから除外されたすべてのデバイスが自動的に excludeLogAppSubRcp テーブルに追加されます。
- 配信開始時の接続の問題：エラータイプは「未定義」で、エラーの理由は「未到達」です。再試行は実行されます。
- 配信中の接続切断：ソフトエラーが生成され、エラーの理由は「拒否」です。再試行は実行されます。
- 送信中に Baidu により同期エラーが返される：ハードエラーが生成され、エラーの理由は「拒否」です。再試行はありません。
Android V2 の場合
Android V2 の強制隔離メカニズムでは、Android V1 と同じプロセスを使用しており、同じことがサブスクリプションと除外の更新にも当てはまります。詳しくは、Android V1 の節を参照してください。
SMS の強制隔離 sms-quarantines
標準コネクタの場合
SMS メッセージの強制隔離メカニズムは、全体として通常のプロセスと同じものです。強制隔離についてを参照してください。SMS 特有の方式を以下に示します。
拡張された汎用 SMPP コネクタの場合
SMPP プロトコルを使用して SMS メッセージを送信する場合のエラー管理の方法は異なります。拡張された汎用 SMPP コネクタについて詳しくは、このページを参照してください。
SMPP コネクタは、返された SR（ステータスレポート）メッセージからデータを取得し、正規表現（regex）を使用して、そのコンテンツをフィルター処理します。このデータは、次に、配信ログの検証 テーブル（管理／キャンペーン管理／配信不能件数の管理 メニューから使用できます）に見つかった情報と照合されます。
新しいタイプのエラーが検証される前に、エラーの理由はデフォルトで常に「拒否」に設定されます。
生成されるメッセージの例：
SR Generic DELIVRD 000|#MESSAGE#
-
SMS のエラーコードをメールのエラーコードと区別するために、すべてのエラーメッセージは SR で始まります。
-
エラーメッセージの 2 つ目の部分（この例では Generic）は、SMSC 実装の名前（例えば、SMS 外部アカウントの「SMSC 実装名」フィールドに定義されている名前）を指します。このページを参照してください。
同じエラーコードであってもプロバイダーごとに意味が異なる場合があるので、エラーコードを生成したプロバイダーがこのフィールドでわかります。これにより、該当するプロバイダーのドキュメントでエラーを調べることができます。
-
エラーメッセージの 3 つ目の部分（この例では DELIVRD）は、SMS 外部アカウントに定義されたステータス抽出用正規表現を使用して SR から取得されたステータスコードに対応します。
この正規表現は、外部アカウントの「SMSC 特異性」タブで指定します。このページを参照してください。
デフォルトでは、SMPP 3.4 仕様 の 付録 B に規定されているとおり、stat: フィールドが抽出されます。
-
エラーメッセージの 4 つ目の部分（この例では 000）は、SMS 外部アカウントに定義されたエラーコード抽出用正規表現を使用して SR から抽出されたエラーコードに対応します。
この正規表現は、外部アカウントの「SMSC 特異性」タブで指定します。このページを参照してください。
デフォルトでは、SMPP 3.4 仕様 の 付録 B に規定されているとおり、err: フィールドが抽出されます。
-
パイプ記号（|）以降の文字列は、配信ログの検証 テーブルの 最初のテキスト 列にのみ表示されます。このコンテンツは、常に、メッセージが正規化された後に #MESSAGE# で置き換えられます。これにより、同じようなエラーに対して複数のエントリが含まれるのを防ぐことができます。これは、メールの場合と同じです。詳しくは、バウンスメールの選定を参照してください。
拡張された汎用 SMPP コネクタは、ヒューリスティックを適用して実用的なデフォルト値を見つけます。例えば、DELIV で始まるステータスは、ほとんどのプロバイダーでよく使用されている DELIVRD または DELIVERED と一致するので、成功とみなされます。これ以外のステータスはハードエラーとみなされます。