Ursachen für das Fehlschlagen von Sendungen

Bounces sind das Ergebnis eines Versandversuchs und -fehlers, bei dem der ISP Fehlermeldungen zurückgibt. Die Bounce-Verarbeitung ist ein wichtiger Bestandteil der Listenhygiene. Nach mehrmaligen Bounces einer E-Mail wird sie von diesem Prozess markiert und unterdrückt.

Dadurch wird verhindert, dass Systeme weiterhin E-Mails mit ungültigen E-Mail-Adressen versenden. Bounces sind eines der wichtigsten Kriterien, mit denen ISPs die IP-Reputation bestimmen. Es ist wichtig, diese Metrik im Auge zu behalten. Die häufigste Methode zur Messung des Versands von Marketing-Nachrichten ist wahrscheinlich der Vergleich von „Zugestellt“ mit „Bounce“. Je höher der Prozentsatz der zugestellten Mails ist, desto besser.

Wenn eine Nachricht nicht an ein Profil gesendet werden kann, sendet der Remote-Server automatisch eine Fehlermeldung an Adobe Campaign. Dieser Fehler wird qualifiziert, um festzustellen, ob die E-Mail-Adresse, die Telefonnummer oder das Gerät unter Quarantäne gestellt werden soll. Siehe Bounce-Message-Verwaltung.

Nach dem Versand einer Nachricht können Sie den Versandstatus für jedes Profil sowie den damit verbundenen Fehlertyp und die Ursache in den Versand-Logs einsehen.

Wenn eine E-Mail-Adresse unter Quarantäne gestellt wird oder sich ein Profil auf der Blockierungsliste befindet, wird der Empfänger bei der Versandvorbereitung ausgeschlossen. Ausgeschlossene Nachrichten werden im Versand-Dashboard aufgeführt.

Warum ist der Nachrichtenversand fehlgeschlagen?

Es gibt zwei Typen von fehlgeschlagenen Sendungen. Jeder Fehlertyp bestimmt, ob eine Adresse in Quarantäne gestellt wird oder nicht.

• Hardbounces
  Hardbounces sind dauerhafte Fehler, die erzeugt werden, wenn ein ISP feststellt, dass eine E-Mail nicht an eine Abonnentenadresse zugestellt werden kann. Innerhalb von Adobe Campaign werden Hardbounces, die als nicht zustellbar kategorisiert sind, zur Quarantäneliste hinzugefügt, was bedeutet, dass kein erneuter Zustellversuch stattfindet. In manchen Fällen wird ein Hardbounce ignoriert, wenn die Ursache des Fehlers unbekannt ist.

  Im Folgenden finden Sie einige gängige Beispiele für Hardbounces: Adresse existiert nicht, Konto deaktiviert, fehlerhafte Syntax, ungültige Domain

• Softbounces
  Softbounces sind temporäre Fehler, die von ISPs bei Versandproblemen von E-Mails erzeugt werden. Bei Softbounces werden mehrfache erneute Zustellversuche unternommen (abhängig von den benutzerdefinierten oder vorkonfigurierten Versandeinstellungen), um einen erfolgreichen Versand durchzuführen. Adressen, die kontinuierlich einen Softbounce verursachen, werden erst dann unter Quarantäne gestellt, wenn eine maximale Anzahl erneuter Zustellungen versucht wurde (was wiederum je nach Einstellungen variiert).

  Einige häufige Ursachen für Softbounces sind: Postfach voll, empfangender E-Mail-Server heruntergefahren, Probleme mit der Versender-Reputation.

Ignoriert: Vorübergehender Fehler, beispielsweise "Out of office" oder technischer Fehler bei Absendern vom Typ "Postmaster".

Die Feedback-Schleife funktioniert wie Bounce-E-Mails: Wenn ein Benutzer eine E-Mail als Spam kennzeichnet, können Sie E-Mail-Regeln in Adobe Campaign so konfigurieren, dass alle Sendungen an diesen Benutzer blockiert werden. Die Adressen dieser Benutzer befinden sich dann auf der Blockierungsliste, obwohl sie nicht auf den Abmelde-Link geklickt haben. Adressen werden in die Quarantänetabelle (NmsAddress) und nicht in die Empfängertabelle (NmsRecipient) mit dem Status Auf die Blockierungsliste gesetzt aufgenommen. Im Handbuch von Adobe mit Best Practices für die Zustellbarkeit erfahren Sie mehr über den Mechanismus der Feedback-Schleife.

Synchrone und asynchrone Fehler

Ein Nachrichtenversand kann sofort fehlschlagen. In diesem Fall wird dies als synchroner Fehler qualifiziert. Wenn der Nachrichtenversand zu einem späteren Zeitpunkt fehlschlägt, ist der Fehler asynchron.

Diese Fehlertypen werden wie folgt verwaltet:

• Synchroner Fehler: Der vom Adobe Campaign-Versand-Server angesprochene Remote-Server gibt sofort eine Fehlermeldung zurück. Die Nachricht kann nicht an den Server des Profils gesendet werden. Der Mail Transfer Agent (MTA) bestimmt den Bounce-Typ und qualifiziert den Fehler, bevor er diese Informationen an Campaign zurücksendet, um zu ermitteln, ob die betroffenen E-Mail-Adressen unter Quarantäne gestellt werden sollen. Siehe Bounce-Message-Qualifizierung.

• Asynchroner Fehler: Eine Bounce Message oder ein Statusbericht (SR) wird vom empfangenden Server verzögert zurückgesendet. Dieser Fehler wird mit einer mit dem Fehler verbundenen Bezeichnung qualifiziert. Asynchrone Fehler können bis zu eine Woche nach einem Versand auftreten.

Qualifizierung von Bounce Messages

Die Art und Weise, wie die Bounce-Message-Qualifizierung in Adobe Campaign verarbeitet wird, hängt vom Fehlertyp ab:

• Synchrone Fehler: Der MTA bestimmt den Bounce-Typ und die Qualifizierung und sendet diese Informationen an Campaign zurück. Die Bounce-Qualifizierungen in der Tabelle Versandlogqualifizierung werden nicht für Fehlernachrichten bei synchronen Sendungen verwendet.

• Asynchrone Fehler: Die von Campaign zur Qualifizierung von fehlgeschlagenen Sendungen verwendeten Regeln werden im Knoten Administration > Campaign Management > Unzustellbarkeitsverwaltung > Versandlogqualifizierung aufgelistet. Asynchrone Bounces werden vom InMail-Prozess über die Regeln für eingehende E-Mails qualifiziert. Mehr dazu finden Sie in der Dokumentation zu Campaign Classic v7.

Verwaltung von erneuten Zustellversuchen

Wenn der Nachrichtenversand aufgrund eines temporären Fehlers fehlschlägt (Soft oder Ignoriert), versucht Campaign eine erneute Zustellung. Diese weiteren Zustellversuche können bis zum Ende der Versandlaufzeit durchgeführt werden.

Weitere Zustellversuche aufgrund von Softbounces und die Zeitdauer zwischen ihnen werden durch den MTA bestimmt, basierend auf Typ und Schweregrad der Bounce-Antworten, die von der E-Mail-Domain der Nachricht zurückgegeben werden.

Gültigkeitszeitraum

Die Einstellung des Gültigkeitszeitraums in Ihren Campaign-Sendungen ist auf 3,5 Tage oder weniger begrenzt. Wenn Sie für Ihren Versand in Campaign einen Wert von mehr als 3,5 Tagen definieren, wird dieser nicht berücksichtigt.

Wenn der Gültigkeitszeitraum in Campaign beispielsweise auf den Standardwert von 5 Tagen eingestellt ist, werden Softbounce-Nachrichten in die Warteschlange für Wiederholungsversuche des MTA aufgenommen. Wiederholungsversuche werden dann nur bis zu 3,5 Tage ab dem Zeitpunkt, an dem die Nachricht beim MTA empfangen wurde, durchgeführt. In diesem Fall wird der in Campaign eingestellte Wert nicht verwendet.

Sobald eine Nachricht 3,5 Tage lang in der Warteschlange des MTA war und nicht gesendet werden konnte, wird sie mit einem Timeout beendet, und ihr Status ändert sich von Gesendet in Fehlgeschlagen (in den Versandlogs).

Weitere Informationen zum Gültigkeitszeitraum finden Sie im Abschnitt Dokumentation zu Adobe Campaign Classic v7.

E-Mail-Fehlertypen

Für den E-Mail-Kanal sind im Folgenden mögliche Ursachen für einen fehlgeschlagenen Versand aufgeführt.

Fehlertypen bei Push-Benachrichtigungen

Für den Mobile-App-Kanal sind unten mögliche Ursachen für einen fehlgeschlagenen Versand aufgeführt.

Quarantäne bei iOS-Geräten

Das HTTP/V2-Protokoll ermöglicht für jeden Push-Versand ein direktes Feedback zu dessen Status. Bei Verwendung des Connectors für das HTTP/V2-Protokoll wird der Feedback-Dienst des Workflows mobileAppOptOutMgt nicht mehr aufgerufen. Ein Token gilt als abgemeldet, wenn eine Mobile App deinstalliert oder neu installiert wird.

Wenn der APNS für eine Nachricht den Status "abgemeldet" zurückgibt, wird der Ziel-Token direkt unter Quarantäne gestellt.

Quarantäne bei Android-Geräten

Für Android V1

Für jede Benachrichtigung erhält Adobe Campaign die synchronen Fehler direkt vom FCM-Server. Adobe Campaign verarbeitet diese unmittelbar und erstellt Hard- und Softbounces entsprechend des Schweregrads des Fehlers. Es können weitere Zustellversuche unternommen werden:

• Nutzdatenlänge überschritten, Verbindungsproblem, Problem mit Dienstverfügbarkeit: Neuversuch wird unternommen, Softbounce, Grund für den Fehler ist Abgelehnt.
• Gerätequote überschritten: kein Neuversuch, Softbounce, Grund für Fehler ist Abgelehnt.
• Ungültiger oder abgemeldeter Token, unerwarteter Fehler, Problem mit Absenderkonto: kein Neuversuch, Hardbounce, Grund für Fehler ist Abgelehnt.

Der mobileAppOptOutMgt-Workflow wird alle sechs Stunden zur Aktualisierung der AppSubscriptionRcp-Tabelle durchgeführt. Für jeden abgemeldeten oder nicht mehr gültigen Token wird das Feld Deaktiviert auf Wahr gesetzt und das mit dem Gerät verknüpfte Abonnement wird automatisch von künftigen Sendungen ausgeschlossen.

Während der Versandanalyse werden alle Geräte, die von der Zielgruppe ausgeschlossen werden, automatisch zur Tabelle excludeLogAppSubRcp hinzugefügt.

Für Android V2

Der Quarantänemechanismus für Android V2 verwendet denselben Prozess wie für Android V1. Dasselbe gilt für die Aktualisierung von Anmeldungen und Ausschlüssen. Weiterführende Informationen hierzu finden Sie im Abschnitt Android V1.

Quarantäne für SMS

Für Standard-Connectoren

Die Besonderheiten für den SMS-Kanal sind unten aufgeführt.

Für den Connector für erweitertes allgemeines SMPP

Bei Verwendung des SMPP-Protokolls zum Senden von SMS-Nachrichten wird die Fehlerverwaltung anders gehandhabt.

Der SMPP-Connector ruft zum Filtern des Inhalts mithilfe regulärer Ausdrücke (regexes) Daten von der zurückgegebenen Empfangsbestätigung ab. Diese Daten werden dann mit den Informationen in der Tabelle Versandlogqualifizierung abgeglichen. Der Zugriff darauf erfolgt über das Menü Administration > Kampagnenverwaltung > Unzustellbarkeitsverwaltung.

Bevor ein neuer Fehlertyp qualifiziert wird, wird der Fehlergrund immer standardmäßig auf Abgelehnt gesetzt.

Beispiel einer generierten Nachricht:

SR Generic DELIVRD 000|#MESSAGE#

• Alle Fehlernachrichten beginnen mit SR, sodass SMS-Fehlercodes von E-Mail-Fehlercodes unterschieden werden können.

• Der zweite Teil der Fehlernachricht (in diesem Beispiel Allgemein) bezieht sich auf den Namen der SMSC-Implementierung entsprechend der Definition im Feld Name der SMSC-Implementierung des externen SMS-Kontos.

  Da derselbe Fehlercode bei jedem Provider eine andere Bedeutung haben kann, sehen Sie in diesem Feld, welcher Provider den Fehlercode erstellt hat. Den Fehler können Sie dann in der entsprechenden Dokumentation des Providers einsehen.

• Der dritte Teil der Fehlernachricht (in diesem Beispiel DELIVRD) entspricht dem Statuscode, der von der Empfangsbestätigung unter Verwendung des – im externen SMS-Konto definierten – regulären Ausdruck zur Statusextraktion abgerufen wurde.

  Dieser reguläre Ausdruck ist im Tab SMSC-Besonderheiten des externen Kontos spezifiziert.
  Standardmäßig erfolgt die Regex-Extraktion des stat:-Felds entsprechend der Definition im Bereich Appendix B der SMPP 3.4-Spezifikation.

• Der vierte Teil der Fehlernachricht (in diesem Beispiel 000) entspricht dem Fehlercode, der von der Empfangsbestätigung unter Verwendung des im externen SMS-Konto definierten regulären Ausdrucks zur Fehlercode-Extraktion extrahiert wurde.

  Dieser reguläre Ausdruck ist im Tab SMSC-Besonderheiten des externen Kontos spezifiziert.

  Standardmäßig erfolgt die Regex-Extraktion des err:-Felds entsprechend der Definition im Bereich Anhang B der SMPP 3.4-Spezifikation.

• Alles, was hinter dem senkrechten Strich (|) steht, wird nur in der Spalte Erster Text der Tabelle Versandlogqualifizierung dargestellt. Nach der Bereinigung der Nachricht wird dieser Inhalt durch #MESSAGE# ersetzt. Dadurch wird vermieden, dass für ähnliche Fehler mehrere Einträge vorgenommen werden. Das Verfahren ist dasselbe wie für E-Mails.

Der Connector für erweitertes allgemeines SMPP wendet eine Heuristik an, um sinnvolle Standardwerte zu finden: Ein mit DELIV beginnender Status wird als erfolgreich bewertet, da dies den üblicherweise von Providern verwendeten Statuswerten DELIVRD oder DELIVERED entspricht. Alle anderen Statuswerte verursachen einen Hardbounce.

Ressourcen für Business.Adobe.com