DokumentationCampaignCampaign Classic v7 – Dokumentation

[Gilt auch für v8]{class="badge positive" title="Gilt auch für Campaign v8"}

Funktionsweise der Quarantäneverwaltung :headding-anchor:understanding-quarantine-management

Last update: Thu Sep 12 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Erstellt für:

  • Benutzende

Adobe Campaign erlaubt die Verwaltung von Quarantäne-Adressen. Empfänger, deren Adresse in Quarantäne ist, werden standardmäßig zum Zeitpunkt der Versandanalyse ausgeschlossen und fließen somit nicht in die Berechnung der Zielgruppe ein. Eine E-Mail-Adresse kann in Quarantäne kommen, weil z. B. das Postfach voll ist oder die Adresse nicht existiert. Nachfolgend werden die Regeln, die eine Quarantäne auslösen, näher erläutert.

NOTE
Dieser Abschnitt gilt für Online-Kanäle: E-Mail, SMS, Push-Benachrichtigungen.

Optimieren Ihres Versands durch die Quarantäneverwaltung :headding-anchor:optimizing-your-delivery-through-quarantines

Die Profile, deren E-Mail-Adressen oder Telefonnummern unter Quarantäne sind, werden während der Nachrichtenvorbereitung automatisch ausgeschlossen (siehe Identifizieren von für einen Versand in Quarantäne befindlichen Adressen). Dies beschleunigt die Zustellung, da sich die Fehlerrate maßgeblich auf die Zustellgeschwindigkeit auswirkt.

Teilweise werden E-Mails von Providern automatisch als Spam eingestuft, wenn die Anzahl ungültiger Adressen zu hoch ist. Durch die Quarantäne können Sie also vermeiden, von diesen Providern auf eine Blockierungsliste gesetzt zu werden.

Zusätzlich helfen Ihnen Quarantänen, die Kosten des SMS-Versands zu senken, indem fehlerhafte Telefonnummern aus dem Versand ausgeschlossen werden.

Weiterführende Informationen zu Best Practices zur Durchführung und Optimierung von Sendungen finden Sie auf dieser Seite.

Quarantäne vs. Blockierungsliste :headding-anchor:quarantine-vs-denylist

Die Quarantäne und die Blockierungsliste gelten nicht für dasselbe Objekt:

  • Die Quarantäne bezieht sich nur auf eine Adresse (oder Telefonnummer usw.), nicht aber auf das Profil selbst. Wenn beispielsweise ein Profil mit einer in Quarantäne befindlichen E-Mail-Adresse eine neue Adresse angibt, kann es erneut in Versandzielgruppen aufgenommen werden. Wenn zwei Profile dieselbe Telefonnummer haben, sind sie beide betroffen, wenn die Nummer unter Quarantäne gestellt wird.

    Die unter Quarantäne gestellten Adressen oder Telefonnummern werden in den Ausschlusslogs (für einen Versand) oder in der Quarantäneliste (für die gesamte Plattform) angezeigt.

  • Die Aufnahme in die Blockierungsliste führt dagegen dazu, dass das Profil vom Versand ausgeschlossen wird. Dies ist z. B. nach einer Abmeldung (Opt-out) von einem Kanal der Fall. Wenn beispielsweise ein Profil, das auf der Blockierungsliste für den E-Mail-Kanal steht, zwei E-Mail-Adressen hat, werden beide Adressen vom Versand ausgeschlossen.

    Im Abschnitt Nicht mehr kontaktieren der Registerkarte Allgemein des Profils können Sie überprüfen, ob sich ein Profil auf der Blockierungsliste für einen oder mehrere Kanäle befindet. Weitere Informationen finden Sie in diesem Abschnitt.

NOTE
Die Quarantäne beinhaltet den Status Auf die Blockierungsliste gesetzt, der angewendet wird, wenn Empfängerinnen bzw. Empfänger Ihre Nachricht als Spam melden oder auf eine SMS mit einem Keyword wie „STOP“ antworten. In diesem Fall wird die betroffene Adresse oder Telefonnummer des Profils unter Quarantäne gestellt und erhält den Status Auf die Blockierungsliste gesetzt. Weiterführende Informationen zur Verwaltung von STOP-SMS-Nachrichten finden Sie in diesem Abschnitt.

Identifizieren von in Quarantäne befindlichen Adressen :headding-anchor:identifying-quarantined-addresses

Die in Quarantäne befindlichen Adressen können für einen bestimmten Versand oder für die gesamte Plattform angezeigt werden.

Identifizieren von für einen Versand in Quarantäne befindlichen Adressen :headding-anchor:identifying-quarantined-addresses-for-a-delivery

Die für einen bestimmten Versand in Quarantäne befindlichen Adressen werden während der Versandvorbereitung in den Versandlogs des Versand-Dashboards angezeigt (siehe Versandlogs und Versandverlauf).

Identifizieren von für die gesamte Plattform in Quarantäne befindlichen Adressen :headding-anchor:identifying-quarantined-addresses-for-the-entire-platform

Administratoren können die für die gesamte Plattform in Quarantäne befindlichen Adressen im Knoten Administration > Kampagnenverwaltung > Unzustellbarkeitsverwaltung > Adressen unzustellbarer Sendungen anzeigen.

NOTE
In diesem Menü werden unter Quarantäne gestellte Elemente für die Kanäle E-Mail, SMS und Push-Benachrichtigungen aufgeführt.

Folgende Informationen stehen für jede Adresse zur Verfügung:

NOTE
Mit zunehmendem Alter der Datenbank steigt auch die Zahl der Adressen in Quarantäne. Wenn man beispielsweise davon ausgeht, dass eine E-Mail-Adresse eine Lebensdauer von etwa drei Jahren hat und die Empfängertabelle pro Jahr um 50 % wächst, lässt sich der Quarantänezuwachs wie folgt berechnen:
Ende 1. Jahr: (1 * 0,33) / (1 + 0,5) = 22 %.
Ende 2. Jahr: ((1,22 * 0,33) + 0,33) / (1,5 + 0,75) = 32,5 %.

Identifizieren von in Quarantäne befindlichen Adressen in Versandberichten :headding-anchor:identifying-quarantined-addresses-in-delivery-reports

Folgende Berichte enthalten Informationen zu Adressen in Quarantäne:

  • Die Versandzusammenfassung gibt Aufschluss über die Anzahl der Adressen in Quarantäne in der Zielgruppe. Sie zeigt insbesondere

    • die Adressen, die bei der Versandanalyse ausgeschlossen wurden,

    • die Adressen, die infolge des Versands neu unter Quarantäne gestellt wurden.

  • In Fehler und Bounces finden sich neben den Informationen bezüglich der Quarantäne-Adressen auch Hinweise auf die Fehlertypen und die Verteilung der Fehler nach Domains.

Diese Informationen stehen für alle Sendungen der Plattform (Startseite > Berichte) oder versandspezifisch zur Verfügung. Sie haben auch die Möglichkeit, benutzerdefinierte Berichte zu erstellen und die dort angezeigten Daten Ihren Bedürfnissen entsprechend zu konfigurieren.

Identifizieren von für einen Empfänger in Quarantäne befindlichen Adressen :headding-anchor:identifying-quarantined-addresses-for-a-recipient

Sie können den Status der E-Mail-Adresse sämtlicher Empfangenden aufrufen. Wählen Sie dazu das Empfängerprofil aus und klicken Sie auf die Registerkarte Sendungen. Sie können für alle Sendungen an diese Empfängerin bzw. diesen Empfänger feststellen, ob beispielsweise die Adresse fehlerhaft war, während der Analyse unter Quarantäne gestellt wurde usw. Sie können für jeden Ordner nur die Empfangenden anzeigen, deren Adresse in Quarantäne ist. Verwenden Sie dazu den Anwendungsfilter E-Mail-Adresse in Quarantäne.

Bedingungen für die Quarantäne von Adressen :headding-anchor:conditions-for-sending-an-address-to-quarantine

Adobe Campaign verwaltet die Quarantäne je nach dem Typ der fehlgeschlagenen Sendung und dem Grund, der bei der Qualifizierung von Fehlermeldungen zugewiesen wurde (siehe Bounce-Message-Qualifizierung und Typen und Ursachen für fehlgeschlagene Sendungen).

  • Ignorierter Fehler: Bei ignorierten Fehlern wird eine Adresse nicht unter Quarantäne gestellt.
  • Hardbounce: Die E-Mail-Adresse kommt sofort in Quarantäne.
  • Softbounce: In diesem Fall wird die Adresse nicht sofort unter Quarantäne gestellt, sondern der Fehlerzähler nur hinaufgesetzt. Weitere Informationen hierzu finden Sie unter Verwaltung von Softbounces.

Wenn ein Benutzer eine E-Mail als Spam kennzeichnet (Feedback Loop), wird die Nachricht automatisch an ein von Adobe verwaltetes technisches Postfach weitergeleitet. Die E-Mail-Adresse des Benutzers wird dann automatisch unter Quarantäne gestellt und der Status in Auf Blockierungsliste geändert. Der Status bezieht sich ausschließlich auf die Adresse und das Profil wird nicht auf die Blockierungsliste gesetzt, sodass der Empfänger nach wie vor SMS-Nachrichten und Push-Benachrichtigungen erhält.

NOTE
Bei der Quarantänefunktion in Adobe Campaign wird die Groß-/Kleinschreibung beachtet. Achten Sie darauf, E-Mail-Adressen in Kleinbuchstaben zu importieren, damit sie später nicht erneut verwendet werden.

Bei Adressen in Quarantäne (siehe Identifizieren von für die gesamte Plattform in Quarantäne befindlichen Adressen) zeigt das Feld Fehlerursache an, wodurch die Quarantäne ausgelöst wurde.

Verwaltung von Softbounces :headding-anchor:soft-error-management

Im Gegensatz zu Hardbounces senden Softbounces eine Adresse nicht sofort in die Quarantäne, sondern erhöhen stattdessen einen Fehlerzähler.

Während der Versandlaufzeit werden noch weitere Zustellversuche durchgeführt. Sollte der Zähler eine festgelegte Schwelle überschreiten, wird die Adresse unter Quarantäne gestellt. Weitere Informationen hierzu finden Sie unter Weitere Zustellversuche nach einem vorübergehend fehlgeschlagenen Versand.

Der Fehlerzähler wird erneut initialisiert, wenn der letzte signifikante Fehler vor mehr als 10 Tagen aufgetreten ist. Der Status der Adresse wird auf Gültig gesetzt und mithilfe des Workflows Datenbankbereinigung wird die Adresse aus der Quarantäneliste gelöscht.

Wenn Sie bei gehosteten oder hybriden Installationen ein Upgrade auf Enhanced MTA durchgeführt haben, basiert die maximale Anzahl weiterer Versuche, die im Falle des Status Fehlerhaft durchgeführt werden, sowie die Mindestverzögerung zwischen Wiederholungsversuchen jetzt darauf, wie gut eine IP in einer bestimmten Domain sowohl in der Vergangenheit funktioniert hat als auch aktuell funktioniert.

Bei On-Premise-Installationen und gehosteten/hybriden Installationen, die den veralteten Campaign MTA verwenden, können die Anzahl der Fehler und der Zeitraum zwischen zwei Fehlern geändert werden. Ändern Sie dazu die entsprechenden Einstellungen im Bereitstellungsassistenten (E-Mail-Kanal > Erweiterte Parameter) oder auf Versandebene.

Entfernen einer Adresse aus der Quarantäne :headding-anchor:removing-a-quarantined-address

Automatische Aktualisierungen :headding-anchor:unquarantine-auto

Adressen, die bestimmte Bedingungen erfüllen, werden automatisch durch den Datenbankbereinigungs-Workflow aus der Quarantäneliste gelöscht.

In den folgenden Fällen werden die Adressen automatisch aus der Quarantäneliste entfernt:

  • Adressen mit dem Status Fehlerhaft werden nach einem erfolgreichen Versand aus der Quarantäneliste entfernt.
  • Adressen mit dem Status Fehlerhaft werden aus der Quarantäneliste entfernt, wenn der letzte Softbounce mehr als 10 Tage zurückliegt. Weitere Informationen zum Umgang mit Softbounces finden Sie in diesem Abschnitt.
  • Adressen mit dem Status Fehlerhaft, die mit dem Fehler Postfach voll zurückkommen, werden nach 30 Tagen aus der Quarantäneliste entfernt.

Ihr Status ändert sich dann in Gültig.

IMPORTANT
Empfängerinnen und Empfänger mit einer Adresse im Status Quarantäne oder Auf Blockierungsliste werden niemals entfernt, auch wenn sie eine E-Mail erhalten.

Manuelle Aktualisierungen :headding-anchor:unquarantine-manual

Sie können die Quarantäne für eine Adresse auch manuell aufheben. Um eine Adresse manuell aus der Quarantäneliste zu entfernen, ändern Sie im Knoten Administration > Kampagnen-Management > Unzustellbarkeitsverwaltung > Adressen unzustellbarer Sendungen ihren Status in Gültig.

Massenaktualisierungen :headding-anchor:unquarantine-bulk

Möglicherweise müssen Sie Massenaktualisierungen auf der Quarantäneliste durchführen, z. B. im Falle eines ISP-Ausfalls. In diesem Fall werden E-Mails fälschlicherweise als Bounce gekennzeichnet, da sie ihren Empfängerinnen und Empfängern nicht erfolgreich zugestellt werden können. Diese Adressen müssen aus der Quarantäneliste entfernt werden.

Erstellen Sie dazu einen Workflow und fügen Sie eine Abfrage-Aktivität in Ihrer Quarantänetabelle hinzu, um alle betroffenen Empfängerinnen und Empfänger herauszufiltern. Sobald sie identifiziert sind, können sie aus der Quarantäneliste entfernt und in zukünftige E-Mail-Sendungen in Campaign aufgenommen werden.

Nachfolgend befinden sich die empfohlenen Richtlinien für diese Abfrage:

  • Für Campaign Classic v7-Umgebungen mit Regelinformationen für eingehende E-Mails im Feld Fehlertext der Quarantäneliste:

    • Fehlertext (Quarantänetext) enthält „Momen_Code10_InvalidRecipient“
    • E-Mail-Domain (@domain) gleich domain1.com ODER E-Mail-Domain (@domain) gleich domain2.com ODER E-Mail-Domain (@domain) gleich domain3.com
    • Statusaktualisierung (@lastModified) MM/DD/YYYY HH:MM:SS AM oder später
    • Statusaktualisierung (@lastModified) MM/DD/YYYY HH:MM:SS PM oder früher

  • Für Campaign Classic v7-Umgebungen mit SMTP-Bounce-Antwortinformationen im Feld Fehlertext der Quarantäneliste:

    • Fehlertext (Quarantänetext) enthält „550-5.1.1“ UND Fehlertext (Quarantänetext) enthält „support.ISP.com“,

    wobei „support.ISP.com“ zum Beispiel: „support.apple.com“ oder „support.google.com“ sein kann

    • Statusaktualisierung (@lastModified) am oder später als MM/DD/YYYY HH:MM:SS AM
    • Statusaktualisierung (@lastModified) am oder früher als MM/DD/YYYY HH:MM:SS PM

Sobald Sie die Liste der betroffenen Empfängerinnen und Empfänger haben, fügen Sie die Aktivität Daten aktualisieren hinzu, um den Status der E-Mail-Adressen auf Gültig zu setzen, damit sie durch den Workflow Datenbankbereinigung aus der Quarantäneliste entfernt werden. Sie können sie auch einfach aus der Quarantänetabelle löschen.

Quarantäne für Push-Benachrichtigungen :headding-anchor:push-notification-quarantines

Der Quarantänemechanismus für Push-Benachrichtigungen ist global gesehen mit dem allgemeinen Prozess identisch. Bestimmte Fehler werden jedoch für Push-Benachrichtigungen unterschiedlich verwaltet. Bei bestimmten Soft-Fehlern werden beispielsweise innerhalb desselben Versands keine weiteren Versuche unternommen. Die Besonderheiten bei Push-Benachrichtigungen sind unten aufgeführt. Der Wiederholungsmechanismus (Anzahl weiterer Versuche, Frequenz) entspricht dem für E-Mails.

Bei den unter Quarantäne gestellten Objekten handelt es sich um Device Token.

Quarantäne bei iOS-Geräten :headding-anchor:ios-quarantine

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.

Szenario
Status
Fehlernachricht
Typ des Fehlschlagens
Grund des Fehlschlagens
Erneut versuchen
Zielgerät eingeschaltet
OK
Zielgerät ausgeschaltet
OK
Empfänger deaktiviert Benachrichtigungen für die Anwendung
OK
Nachrichtenerstellung/Analysephase - Nutzdaten zu groß
Fehlgeschlagen
Nutzdaten zu lang
Soft
Zurückgewiesen
Nein
Nachrichtenerstellung/Analysephase - Problem mit Inhalt mit unerwartetem Format
Fehlgeschlagen
Verschiedene Fehlernachrichten je nach Fehler
Soft
Unbestimmt
Nein
Problem mit Zertifikat (Passwort, Beschädigung etc.) und Problem bei Testverbindung mit APNs
Fehlgeschlagen
Verschiedene Fehlernachrichten je nach Fehler
Soft
Zurückgewiesen
Nein
Netzwerkverbindung während des Versands abgebrochen
Fehlgeschlagen
Verbindungsfehler
Unbestimmt
Unerreichbar
Ja
Zurückweisung von APNS-Nachricht: Abmeldung
Benutzer hat die Mobile App entfernt oder das Token ist abgelaufen
Fehlgeschlagen
Abgemeldet
Hard
Unbekannter Nutzer
Nein
Zurückweisung von APNS-Nachricht: alle anderen Fehler
Fehlgeschlagen
Der Grund für Zurückweisung wird in der Fehlernachricht angegeben
Soft
Zurückgewiesen
Nein

Quarantäne bei Android-Geräten :headding-anchor:android-quarantine

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 der Prioritätsstufe des Fehlers. Es können weitere Zustellversuche vorgenommen 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 Workflow mobileAppOptOutMgt läuft alle 6 Stunden, um die Tabelle AppSubscriptionRcp zu aktualisieren. Für jedes abgemeldete oder nicht mehr gültige 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.

NOTE
Im Folgenden finden Sie die unterschiedlichen Fehlertypen für den Baidu-Connector:
  • Verbindungsproblem zu Beginn des Versands: Fehlertyp Undefiniert, Grund Unerreichbar, Neuversuch wird unternommen.
  • Verbindung während des Versands unterbrochen: Softbounce, Grund für den Fehler Abgelehnt, Neuversuch wird unternommen.
  • Während des Versands von Baidu synchroner Fehler zurückgegeben: Hardbounce, Grund für den Fehler Abgelehnt, es wird kein Neuversuch unternommen.
Adobe Campaign kontaktiert den Baidu-Server alle 10 Minuten, um den Status der gesendeten Nachricht abzurufen, und aktualisiert die Broadlogs. Wenn eine Nachricht als gesendet gemeldet wird, wird der Status der Nachricht in den Broadlogs auf Erhalten festgelegt. Wenn Baidu einen Fehler meldet, wird der Status auf Fehlgeschlagen festgelegt.

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.

Szenario
Status
Fehlernachricht
Typ des Fehlschlagens
Grund des Fehlschlagens
Erneut versuchen
Nachrichtenerstellung/Analysephase: unzulässige Schlüsselwörter in den benutzerdefinierten Feldern verwendet
Fehlgeschlagen
Folgende Schlüsselwörter dürfen nicht benutzt werden: {1}
Soft
Nein
Nachrichtenerstellung/Analysephase: Nutzdaten zu groß
Fehlgeschlagen
Die Benachrichtigung ist zu groß: {1} Bit statt maximal {2}.
Soft
Zurückgewiesen
Nein
Netzwerkverbindung während des Versands abgebrochen
Fehlgeschlagen
Keine Antwort von Firebase Cloud Messaging für die Adresse: {1}
Soft
Unerreichbar
Ja
Zurückweisung von FCM-Nachricht: Der FCM-Server ist vorübergehend nicht verfügbar (z. B. durch Timeouts).
Fehlgeschlagen
Firebase Cloud Messaging ist zurzeit nicht verfügbar
Soft
Unerreichbar
Ja
Zurückweisung von FCM-Nachricht: Fehler bei der Authentifizierung des Absenderkontos
Fehlgeschlagen
Entwicklerkonto konnte nicht identifiziert werden, bitte Kennung und Kennwort prüfen.
Soft
Zurückgewiesen
Nein
Zurückweisung von FCM-Nachricht: Gerätequote überschritten
Fehlgeschlagen
Soft
Zurückgewiesen
Ja
Zurückweisung von FCM-Nachricht: ungültige Registrierung/nicht registriert
Fehlgeschlagen
Hard
Unbekannter Nutzer
Nein
Zurückweisung von FCM-Nachricht: alle anderen Fehler
Fehlgeschlagen
Der Firebase Cloud Messaging Server hat einen unerwarteten Fehlercode ausgegeben: {1}
Zurückgewiesen
Nein
Zurückweisung von FCM-Nachricht: ungültiges Argument
Fehlgeschlagen
INVALID_ARGUMENT
Ignoriert
Unbestimmt
Nein
Zurückweisung von FCM-Nachricht: Authentifizierungsfehler bei Drittanbieter
Fehlgeschlagen
THIRD_PARTY_AUTH_ERROR
Ignoriert
Zurückgewiesen
Ja
Zurückweisung von FCM-Nachricht: Sender ID stimmt nicht überein
Fehlgeschlagen
SENDER_ID_MISMATCH
Soft
Unbekannter Nutzer
Nein
Zurückweisung von FCM-Nachricht: abgemeldet
Fehlgeschlagen
UNREGISTERED
Hard
Unbekannter Nutzer
Nein
Zurückweisung von FCM-Nachricht: intern
Fehlgeschlagen
INTERNAL
Ignoriert
Zurückgewiesen
Ja
Zurückweisung von FCM-Nachricht: nicht verfügbar
Fehlgeschlagen
UNAVAILABLE
Ignoriert
Zurückgewiesen
Ja
Zurückweisung von FCM-Nachricht: unerwarteter Fehlercode
Fehlgeschlagen
Unerwarteter Fehlercode
Ignoriert
Zurückgewiesen
Nein
Authentifizierung: Verbindungsproblem
Fehlgeschlagen
Verbindung zum Authentifizierungs-Server nicht möglich
Ignoriert
Zurückgewiesen
Ja
Authentifizierung: Nicht autorisierter Client oder Perimeter in Anfrage.
Fehlgeschlagen
unauthorized_client
Ignoriert
Zurückgewiesen
Nein
Authentifizierung: Der Client ist nicht berechtigt, Zugriffs-Token mit dieser Methode abzurufen, oder der Client ist für keinen der angeforderten Perimeter autorisiert.
Fehlgeschlagen
unauthorized_client
Ignoriert
Zurückgewiesen
Nein
Authentifizierung: Zugriff verweigert
Fehlgeschlagen
access_denied
Ignoriert
Zurückgewiesen
Nein
Authentifizierung: ungültige E-Mail-Adresse
Fehlgeschlagen
invalid_grant
Ignoriert
Zurückgewiesen
Nein
Authentifizierung: ungültiger JWT
Fehlgeschlagen
invalid_grant
Ignoriert
Zurückgewiesen
Nein
Authentifizierung: ungültige JWT-Signatur
Fehlgeschlagen
invalid_grant
Ignoriert
Zurückgewiesen
Nein
Authentifizierung: ungültiger OAuth-Perimeter oder ungültige ID-Token-Zielgruppe angegeben
Fehlgeschlagen
unauthorized_client
Ignoriert
Zurückgewiesen
Nein
Authentifizierung: OAuth-Client deaktiviert
Fehlgeschlagen
disabled_client
Ignoriert
Zurückgewiesen
Nein

Quarantäne für SMS :headding-anchor:sms-quarantines

Für Standard-Connectoren

Der Quarantänemechanismus für SMS-Nachrichten ist global gesehen mit dem allgemeinen Prozess identisch. Näheres dazu erfahren Sie unter Über Quarantänen. Die Besonderheiten bei SMS-Nachrichten sind unten aufgeführt.

NOTE
Die Tabelle Versandlogqualifizierung gilt nicht für den Connector Erweitertes allgemeines SMPP.
Szenario
Status
Fehlernachricht
Typ des Fehlschlagens
Grund des Fehlschlagens
An Anbieter gesendet
Gesendet
Auf Mobiltelefon erhalten
Erhalten
Fehler von Provider gemeldet
Fehlgeschlagen
Fehler beim Abrufen von Daten (SR oder MO)
Soft
Unerreichbar
Ungültige MT-Quittierung
Fehlgeschlagen
Fehler '{1}' bei der Verarbeitung des Empfangsbestätigungs-Frames eines Sendeauftrags
Soft
Unerreichbar
Fehler beim Senden von MT
Fehlgeschlagen
Fehler beim Senden der Nachrichten
Soft
Unerreichbar

Für den Connector für erweitertes allgemeines SMPP

Bei der Verwendung des SMPP-Protokolls zum Versand von SMS-Nachrichten werden Fehler anders gehandhabt. Weiterführende Informationen zum Connector für erweitertes allgemeines SMPP finden Sie auf dieser Seite.

Der SMPP-Connector ruft Daten aus der zurückgegebenen SR (Status Report)-Meldung mithilfe regulärer Ausdrücke (Regexes) ab, um den Inhalt zu filtern. Diese Daten werden dann mit den Informationen in der Tabelle Versandlogqualifizierung abgeglichen (verfügbar über das Menü Administration > Kampagnen-Management > Unzustellbarkeitsverwaltung).

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

NOTE
Die Typen und Ursachen für Fehlschläge sind dieselben wie für E-Mails. Siehe Typen und Ursachen für fehlgeschlagene Sendungen.
Erkundigen Sie sich bei Ihrem Provider nach einer Liste mit Status- und Fehlercodes, um in der Versandlogqualifizierungs-Tabelle die korrekten Fehlertypen und -ursachen anzugeben.

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 Generic) bezieht sich auf den Namen der SMSC-Implementierung entsprechend der Definition im Feld Name der SMSC-Implementierung des externen SMS-Kontos. Weitere Informationen finden Sie auf dieser Seite.

    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. Weitere Informationen finden Sie auf dieser Seite.

    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. Weitere Informationen finden Sie auf dieser Seite.

    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 angezeigt. Dieser Inhalt wird immer durch #MESSAGE# ersetzt, nachdem die Nachricht normalisiert wurde. Dadurch wird verhindert, dass mehrere Einträge für ähnliche Fehler vorliegen, und der Prozess ist mit dem für E-Mails identisch. Weitere Informationen hierzu finden Sie unter Bounce-Message-Qualifizierung.

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.

recommendation-more-help
601d79c3-e613-4db3-889a-ae959cd9e3e1