Show Menu
トピック×

強制隔離管理の理解

強制隔離について

Adobe Campaign では、強制隔離されたアドレスのリストを管理します。アドレスが強制隔離されている受信者は、配信分析時にデフォルトで除外され、ターゲットにされなくなります。例えば、メールボックスの容量が超過している場合や、アドレスが存在しない場合などに、E メールアドレスを強制隔離できます。どのような場合でも、強制隔離手順は、次に説明する特定のルールに従います。
この節は、オンラインチャネル(E メール、SMS、プッシュ通知)に当てはまります。

強制隔離による配信の最適化

E メールアドレスまたは電話番号が強制隔離されているプロファイルは、メッセージ準備の際に自動的に除外されます( 配信用の強制隔離アドレスの識別 を参照)。これによって配信が迅速になります。エラー率は配信の速度に大きく影響するからです。
一部のインターネットアクセスプロバイダーは、無効なアドレスの割合が高すぎる場合、E メールを自動的にスパムとみなします。そのため、強制隔離することで、こうしたプロバイダーによるブラックリストへの登録を回避できます。
また、強制隔離は、誤りのある電話番号を配信から除外することで、SMS の送信コスト削減にも役立ちます。配信を保護および最適化するベストプラクティスについて詳しくは、 このページ を参照してください。

強制隔離とブラックリストへの登録

強制隔離 ​は、プロファイル自体ではなく、アドレスのみに適用されます。つまり、2 つのプロファイルに同じ E メールアドレスがある場合、そのアドレスが強制隔離されると、両方のプロファイルが影響を受けます。
同様に、E メールアドレスが強制隔離されているプロファイルは、プロファイルを更新して新しいアドレスを入力できるので、再び配信アクションのターゲットになる可能性があります。
一方、 ブラックリストへの登録 ​では、登録されたプロファイルが、購読解除(オプトアウト)後のように、それ以降はどのような配信のターゲットにもならなくなります。
SMS 配信からのオプトアウトのために「STOP」のようなキーワードを使ってユーザーが SMS メッセージに返信しても、そのユーザーのプロファイルは、E メールのオプトアウトプロセスのようにはブラックリストに登録されません。強制隔離されるのはプロファイルの電話番号なので、そのユーザーは引き続き E メールメッセージを受信できます。

強制隔離アドレスの識別

強制隔離されたアドレスは、特定の配信またはプラットフォーム全体を対象としてリストすることができます。

配信用の強制隔離アドレスの識別

特定の配信について強制隔離されたアドレスのリストは、配信準備フェーズの途中で、配信ダッシュボードの配信ログに記録されます( 配信ログと履歴 を参照)。

プラットフォーム全体の強制隔離アドレスの識別

管理者は、プラットフォーム全体で強制隔離されたアドレスのリストを​ 管理者/キャンペーン管理/配信不能件数の管理/配信不能件数およびアドレス ​ノードで表示できます。
このメニューでは、 E メール SMS および​ プッシュ通知 ​チャネルの強制隔離された要素のリストが表示されます。
アドレスごとに次の情報を表示できます。
強制隔離数の増加は、データベースの「老朽化」に関連する、正常な影響です。例えば、E メールアドレスの寿命が 3 年と考えられ、受信者テーブルが毎年 50%増加する場合、強制隔離の増加は次のように計算できます。
1 年目の終了時:(1 0.33)/(1+0.5)=22% 2 年目の終了時:((1.22 0.33)+0.33)/(1.5+0.75)=32.5%

配信レポートでの強制隔離アドレスの識別

次のレポートには、強制隔離中のアドレスに関する情報が含まれます。
  • 配信ごとに、配信ターゲットに含まれている強制隔離中のアドレス数が​ 配信の概要 ​レポートに表示されます。次のものが表示されます。
    • 配信分析時に強制隔離されたアドレス数
    • 配信アクション後に強制隔離されたアドレス数
  • 配達不能件数とバウンス数 ​レポートには、強制隔離中のアドレスや発生したエラーのタイプなどに関する情報が表示され、エラーがドメイン別に分類されます。
プラットフォームのすべての配信について( ホームページ/レポート )または特定の配信について、この情報を調べることができます。カスタマイズされたレポートを作成して、表示する情報を選択することもできます。

受信者の強制隔離アドレスの識別

あらゆる受信者の E メールアドレスのステータスを調べることができます。そのためには、受信者のプロファイルを選択し、「 配信 」タブをクリックします。その受信者へのすべての配信について、アドレスへの配信が失敗したかどうか、分析時に強制隔離されたかどうかなどを調べることができます。フォルダーごとに、E メールアドレスが強制隔離中の受信者のみを表示できます。そのためには、 強制隔離された E メールアドレス ​アプリケーションフィルターを使用します。

強制隔離されたアドレスの削除

強制隔離からアドレスを削除する必要がある場合は、アドレスのステータスを手動で「 有効 」に変更します。
ステータスを「 ホワイトリストに含まれる 」に変更すると、エラーが発生した場合でも、このアドレスは毎回システマティックにターゲットになります。
ブラックリストに登録されたアドレスは強制隔離システムで扱わないので、このアドレスのステータスを変更してもターゲットにはなりません。
エラー数およびエラーとエラーの間隔も変更できます。そのためには、デプロイウィザードの設定(E メールチャネル/詳細設定)を変更します。デプロイウィザードについて詳しくは、 この節 を参照してください。

アドレスを強制隔離する条件

Adobe Campaign では、エラーメッセージの選定で割り当てられた配信のエラータイプと理由に応じて強制隔離を管理します( バウンスメールの選定 および 配信のエラータイプと理由 を参照)。
  • 無視のエラー :アドレスを強制隔離しません。
  • ハードエラー :対応する E メールアドレスがただちに強制隔離されます。
  • ソフトエラー :ただちにアドレスが強制隔離されることはありませんが、エラーカウンターがインクリメントされます。詳しくは、 ソフトエラー管理 を参照してください。
ユーザーが E メールをスパム( フィードバックループ )と評価した場合、メッセージはアドビが管理するテクニカルメールボックスに自動的にリダイレクトされます。さらに、その E メールアドレスは自動的に強制隔離されます。
強制隔離されたアドレスのリストの「 エラー理由 」フィールドには、選択されたアドレスが強制隔離された理由が示されます。Adobe Campaign の強制隔離では、大文字と小文字が区別されます。後から再度ターゲットされることのないよう、E メールアドレスは必ず小文字でインポートしてください。

ソフトエラー管理

ハードエラーとは異なり、ソフトエラーでただちにアドレスが強制隔離されることはありませんが、エラーカウンターがインクリメントされます。
  • エラーカウンターが制限しきい値に達すると、アドレスが強制隔離されます。
  • デフォルトの設定では、しきい値はエラー 5 回に設定されています。2 つのエラーは、24 時間以上間隔を開けて発生した場合に別のエラーとしてカウントされます。5 回目のエラー発生時にアドレスが強制隔離されます。
  • エラーカウンターのしきい値は変更できます。詳しくは、 一時的な配信エラーの後の再試行 を参照してください。
最後に重大なエラーが発生したのが 10 日以上前の場合、エラーカウンターが再初期化されます。アドレスのステータスが「 有効 」に変わり、 データベースクリーンアップ ​ワークフローが強制隔離のリストからアドレスを削除します。

プッシュ通知の強制隔離

プッシュ通知の強制隔離メカニズムは、全体として通常のプロセスと同じものです。 強制隔離について を参照してください。ただし、プッシュ通知では一部のエラーの管理方法が異なります。例えば、一部のソフトエラーでは、同じ配信の再試行は実行されません。プッシュ通知特有の方式を以下に示します。再試行の方式(再試行の回数、頻度)は E メールの場合と同じです。
強制隔離される項目はデバイストークンです。

iOS での強制隔離

iOS の場合:バイナリコネクタ
Adobe Campaign は通知ごとに APNS サーバーから同期エラーと非同期エラーを受け取ります。次の同期エラーについては、ソフトエラーが生成されます。
  • ペイロード長の問題:再試行はありません。エラーの理由は「 未到達 」です。
  • 証明書の有効期限の問題:再試行はありません。エラーの理由は「 未到達 」です。
  • 配信中の接続切断:再試行が実行されます。エラーの理由は「 未到達 」です。
  • サービス設定の問題(証明書が無効、証明書のパスワードが無効、証明書がない):再試行はありません。エラーの理由は「 未到達 」です。
APNS サーバーは Adobe Campaign に対し、デバイストークンが(モバイルアプリケーションがユーザーによりアンインストールされた時点で)登録解除されたことを非同期的に通知します。 mobileAppOptOutMgt ワークフローは 6 時間ごとに実行されます。このワークフローは APNS フィードバックサービスにアクセスし、 AppSubscriptionRcp テーブルを更新します。無効になっているすべてのトークンについて、「 無効 」フィールドが「 True 」に設定され、そのサービストークンにリンクされている購読は自動的にそれ以降の配信から除外されます。
iOS の場合:HTTP/2 コネクタ
http/2 プロトコルでは、プッシュ配信ごとの直接フィードバックおよびステータスを使用できます。http/2 プロトコルコネクタを使用する場合、フィードバックサービスが mobileAppOptOutMgt ワークフローによって呼び出されることはありません。登録解除されたトークンの処理は、iOS バイナリコネクタと iOS http/2 コネクタでは異なります。モバイルアプリケーションのアンインストールまたは再インストールがおこなわれた場合、トークンは登録解除されたものとみなされます。
同時に、APNS がメッセージに対して登録解除ステータスを返した場合、ターゲットトークンはただちに強制隔離されます。
シナリオ ステータス エラーメッセージ エラータイプ エラーの理由 再試行
ターゲットデバイスの電源がオン OK
ターゲットデバイスの電源がオフ OK
ユーザーがアプリケーションの通知を無効化 OK
メッセージの作成/分析フェーズ - ペイロードが大きすぎる 失敗 ペイロードが長すぎる ソフト 拒否 ×
メッセージの作成/分析フェーズ - 予期しないコンテンツ形式の問題 失敗 エラーによってエラーメッセージが異なる ソフト 未定義 ×
証明書の問題(パスワード、破損など)と、APNS へのテスト接続の問題 失敗 エラーによってエラーメッセージが異なる ソフト 拒否 ×
送信中にネットワーク接続が切断 失敗 接続エラー 未定義 未到達
APNS メッセージ却下:登録解除 ユーザーがアプリケーションを削除した、またはトークンの期限切れ 失敗 登録解除 ハード 不明なユーザー ×
APNS メッセージ却下:その他のすべてのエラー 失敗 エラー拒否の原因がエラーメッセージに表示されます ソフト 拒否 ×

Android での強制隔離

Android V1 の場合
Adobe Campaign は通知ごとに FCM サーバーから直接同期エラーを受け取ります。Adobe Campaign はこれを即時に処理し、エラーの重大度に応じてハードエラーまたはソフトエラーを生成します。これにより再試行が実行できるようになります。
  • ペイロードの長さの超過、接続の問題、サービスの使用可否の問題:再試行が実行され、ソフトエラーが生成されます。エラーの理由は「 拒否 」です。
  • デバイスの割当量の超過:再試行はなく、ソフトエラーが生成されます。エラーの理由は「 拒否 」です。
  • 無効または登録解除されたトークン、予期しないエラー、送信者のアカウントの問題:再試行はなく、ハードエラーが生成されます。エラーの理由は「 拒否 」です。
mobileAppOptOutMgt ワークフローは 6 時間ごとに実行されます。このワークフローは AppSubscriptionRcp テーブルを更新します。登録解除または無効と宣言されたトークンについて、「 無効 」フィールドが「 True 」に設定され、そのサービストークンにリンクされている購読は自動的にそれ以降の配信から除外されます。
配信分析中に、ターゲットから除外されたすべてのデバイスが自動的に excludeLogAppSubRcp テーブルに追加されます。
Baidu コネクタを使用している場合、さらに別の種類のエラーがあります。
  • 配信開始時の接続の問題:エラータイプは「 未定義 」で、エラーの理由は「 未到達 」です。再試行は実行されます。
  • 配信中の接続切断:ソフトエラーが生成され、エラーの理由は「 拒否 」です。再試行は実行されます。
  • 送信中に Baidu により同期エラーが返される:ハードエラーが生成され、エラーの理由は「 拒否 」です。再試行はありません。
Adobe Campaign は 10 分ごとに Baidu サーバーにアクセスし、送信済みメッセージのステータスを取得し、broadLog を更新します。メッセージが送信済みと宣言されると、broadLog のメッセージのステータスが「 受信済み 」に設定されます。Baidu がエラーを宣言すると、ステータスは「 失敗 」に設定されます。
Android V2 の場合
Android V2 の強制隔離メカニズムでは、Android V1 と同じプロセスを使用しており、購読と除外の更新についても同様です。詳しくは、 Android V1 の節を参照してください。
シナリオ ステータス エラーメッセージ エラータイプ エラーの理由 再試行
メッセージの作成/分析フェーズ:カスタムフィールドでの不正なキーワードの使用 失敗 次のキーワードは使用できません:{1} ソフト ×
メッセージの作成/分析フェーズ:ペイロードが大きすぎる 失敗 通知が長すぎます:{1} ビット。許可されているのは {2} ビットのみです ソフト 拒否 ×
送信中にネットワーク接続が切断 失敗 次のアドレスの Firebase Cloud Messaging サービスからの応答がありません:{1} ソフト 未到達
FCM メッセージ却下:FCM サーバーが一時的に使用不可(タイムアウトなど) 失敗 Firebase Cloud Messaging サービスを一時的に利用できません ソフト 未到達
FCM メッセージ却下:送信者アカウントの認証中にエラー発生 失敗 デベロッパーアカウントを識別できませんでした。ID とパスワードを確認してください ソフト 拒否 ×
FCM メッセージ却下:デバイスの割当量を超過 失敗 ソフト 拒否
FCM メッセージ却下:無効な登録または未登録 失敗 ハード 不明なユーザー ×
FCM メッセージ却下:その他すべてのエラー 失敗 Firebase Cloud Messaging サーバーから予期しないエラーコードが返されました:{1} 拒否 ×

SMS の強制隔離

標準コネクタの場合
SMS メッセージの強制隔離メカニズムは、全体として通常のプロセスと同じものです。 強制隔離について を参照してください。SMS 特有の方式を以下に示します。
配信ログの選定 ​テーブルは、 拡張された汎用 SMPP コネクタには適用されません。
シナリオ ステータス エラーメッセージ エラータイプ エラーの理由
プロバイダーに送信済み 送信済み
モバイルで受信済み 受信済み
プロバイダーがエラーを返した 失敗 データの受信中にエラーが発生しました (SR または MO) ソフト 未到達
MT 確認が無効 失敗 送信クエリの確認フレームの処理中にエラー「{1}」が発生しました ソフト 未到達
MT の送信中にエラーが発生 失敗 メッセージの送信中にエラーが発生 ソフト 未到達
拡張された汎用 SMPP コネクタの場合
SMPP プロトコルを使用して SMS メッセージを送信する場合のエラー管理の方法は異なります。拡張された汎用 SMPP コネクタについて詳しくは、 このページ を参照してください。
SMPP コネクタは、返された SR(ステータスレポート)メッセージからデータを取得し、正規表現(regex)を使用して、そのコンテンツをフィルター処理します。このデータは、次に、 配信ログの検証 ​テーブル( 管理 キャンペーン管理 配信不能件数の管理 ​メニューから使用できます)に見つかった情報と照合されます。
新しいタイプのエラーが検証される前に、エラーの理由はデフォルトで常に「 拒否 」に設定されます。
エラーのタイプと理由は E メールの場合と同じです。 配信エラーのタイプと理由 を参照してください。 配信ログの検証テーブルに適切なエラータイプおよび理由を設定するために、ステータスコードおよびエラーコードのリストをプロバイダーに問い合わせてください。
生成されるメッセージの例:
SR Generic DELIVRD 000|#MESSAGE#

  • SMS のエラーコードを E メールのエラーコードと区別するために、すべてのエラーメッセージは 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# で置き換えられます。これにより、同じようなエラーに対して複数のエントリが含まれるのを防ぐことができます。これは、E メールの場合と同じです。詳しくは、 バウンスメールの選定 を参照してください。
拡張された汎用 SMPP コネクタは、ヒューリスティックを適用して実用的なデフォルト値を見つけます。例えば、 DELIV で始まるステータスは、ほとんどのプロバイダーでよく使用されている DELIVRD または DELIVERED と一致するので、成功とみなされます。これ以外のステータスはハードエラーとみなされます。