配信の失敗について delivery-failures

バウンスは、配信の試行とエラーの結果、ISP からエラー通知が返されたものを表します。バウンス処理は、リストの衛生状態の重要な部分です。特定のメールが連続して複数回バウンスした後、このプロセスにより、抑制のフラグが設定されます。

このプロセスでは、システムが無効なメールアドレスの送信を継続するのを防ぎます。バウンスは、IP レピュテーションを判断するために ISP が使用する、データの重要な要素の 1 つです。この指標に目を通すことが重要です。「配信済み」と「バウンス済み」は、おそらくマーケティングメッセージの配信を測定する際の、最も一般的な方法です。配信率が高いほど、より良い結果が得られます。

メッセージをプロファイルに送信できない場合、リモートサーバーは自動的にエラーメッセージを Adobe Campaign に送信します。このエラーは、メールアドレス、電話番号、またはデバイスを強制隔離する必要があるかどうかを判断するために適合されます。バウンスメールの管理を参照してください。

メッセージを送信すると、各プロファイルの配信ステータス、関連するエラーのタイプと理由が配信ログに表示されます。

メールアドレスが強制隔離された場合、またはプロファイルがブロックリストに登録されている場合、配信の準備段階で受信者が除外されます。除外されたメッセージのリストは、配信ダッシュボードに表示されます。

メッセージの配信が失敗した理由 delivery-failure-reasons

メッセージエラーには次の 2 つのタイプがあります。それぞれの配信エラータイプによって、アドレスが強制隔離されるかどうかが決まります。

無視 ​は、一時的であることがわかっているエラー（「外出中」など）、または技術的エラー（送信者タイプが「postmaster」である場合など）です。

フィードバックループはバウンスメールのように機能します。ユーザーがメールをスパムとみなしたら、Adobe Campaign でメールルールを設定して、このユーザーへのすべての配信をブロックできます。このようなユーザーのアドレスは、購読解除リンクをクリックしなかった場合でも、ブロックリストに登録されます。アドレスは受信者テーブル（NmsRecipient）ではなく、強制隔離テーブル（NmsAddress）に追加され、「ブロックリスト登録済み」ステータスとなります。フィードバックループのメカニズムについて詳しくは、Adobe 配信品質のベストプラクティスガイドを参照してください。

同期エラーと非同期エラー synchronous-and-asynchronous-errors

メッセージの配信は、即座に失敗することがあります。その場合は、同期エラーと見なします。メッセージの送信が失敗した場合や送信後に失敗した場合、エラーは非同期的になります。

これらのタイプのエラーは、次のように管理されます。

バウンスメールの選定 bounce-mail-qualification

Adobe Campaign でのバウンスメールの選定の処理方法は、エラータイプによって異なります。

再試行管理 retries

一時的なエラー（ソフト ​または​ 無視）の後でメッセージ配信が失敗した場合、Campaign は送信を再試行します。これらの再試行は、配信期間が終了するまで実行できます。

ソフトバウンスの再試行とその間隔は、メッセージのメールドメインから返されるバウンス応答のタイプと重大度に基づいた MTA によって決定します。

有効期間 valid-period

Campaign 配信の有効期間の設定は、3.5 日以内 ​に制限されています。配信に対して Campaign で 3.5 日を超える値を定義すると、その値は考慮されません。

例えば、Campaign で有効期間がデフォルト値の 5 日間に設定されている場合、ソフトバウンスメッセージは MTA の再試行キューに入り、そのメッセージが MTA に到達してから最大 3.5 日間再試行されます。その場合、Campaign で設定された値は使用されません。

メッセージが MTA キューに置かれた日数が 3.5 日に達しても配信に失敗した場合は、タイムアウトになり、配信ログでのステータスは、送信済み ​から​ 失敗 ​に更新されます。

有効期間について詳しくは、Adobe Campaign Classic v7 ドキュメントを参照してください。

メールのエラータイプ email-error-types

メールチャネルについて、配信エラーの考えられる理由を以下に示します。

プッシュ通知のエラータイプ push-error-types

モバイルアプリチャネルの場合に考えられる配信エラーの理由を次に示します。

iOS での強制隔離 ios-quarantine

HTTP/V2 プロトコルでは、プッシュ配信ごとの直接フィードバックおよびステータスを使用できます。HTTP/V2 プロトコルコネクタを使用する場合、フィードバックサービスが mobileAppOptOutMgt ワークフローによって呼び出されることはありません。モバイルアプリケーションのアンインストールまたは再インストールがおこなわれた場合、トークンは登録解除されたものとみなされます。

同時に、APNs がメッセージに対して登録解除ステータスを返した場合、ターゲットトークンはただちに強制隔離されます。

Android での強制隔離 android-quarantine

Android V1 の場合

Adobe Campaign は通知ごとに FCM サーバーから直接同期エラーを受け取ります。Adobe Campaign はこれを即時に処理し、エラーの重大度に応じてハードエラーまたはソフトエラーを生成します。これにより再試行が実行できるようになります。

mobileAppOptOutMgt ワークフローは 6 時間ごとに実行されます。このワークフローは AppSubscriptionRcp テーブルを更新します。登録解除または無効と宣言されたトークンについて、「無効」フィールドが「True」に設定され、そのデバイストークンにリンクされている購読は自動的にそれ以降の配信から除外されます。

配信分析中に、ターゲットから除外されたすべてのデバイスが自動的に excludeLogAppSubRcp テーブルに追加されます。

Android V2 の場合

Android V2 の強制隔離メカニズムでは、Android V1 と同じプロセスを使用しており、同じことがサブスクリプションと除外の更新にも当てはまります。詳しくは、Android V1 の節を参照してください。

SMS の強制隔離 sms-quarantines

標準コネクタの場合

SMS チャネル特有の方式を以下に示します。

拡張された汎用 SMPP コネクタの場合

SMPP プロトコルを使用して SMS メッセージを送信する場合のエラー管理の方法は異なります。

SMPP コネクタは、返された SR（ステータスレポート）メッセージからデータを取得し、正規表現（regex）を使用して、そのコンテンツをフィルター処理します。このデータは、次に、配信ログの検証 ​テーブル（管理／キャンペーン管理／配信不能件数の管理 ​メニューから使用できます）に見つかった情報と照合されます。

新しいタイプのエラーが検証される前に、エラーの理由はデフォルトで常に「拒否」に設定されます。

生成されるメッセージの例：

SR Generic DELIVRD 000|#MESSAGE#

拡張された汎用 SMPP コネクタは、ヒューリスティックを適用して実用的なデフォルト値を見つけます。例えば、DELIV で始まるステータスは、ほとんどのプロバイダーでよく使用されている DELIVRD または DELIVERED と一致するので、成功とみなされます。これ以外のステータスはハードエラーとみなされます。