Show Menu
THEMEN×

Funktionsweise der Quarantäneverwaltung

Über Quarantänen

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.
Dieser Abschnitt gilt für Online-Kanäle: E-Mail, SMS, Push-Benachrichtigungen.

Zustellbarkeit durch Quarantänen optimieren

Die Profile, deren E-Mail-Adressen oder Telefonnummern unter Quarantäne sind, werden während der Nachrichtenvorbereitung automatisch ausgeschlossen (siehe Für einen Versand in Quarantäne befindliche Adressen identifizieren ). 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änefunktion vermeiden Sie, von diesen Providern auf eine Blacklist 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 im Vergleich zur Blacklist

Eine Quarantäne bezieht sich immer nur auf die Adresse, nicht aber auf das Profil selbst. Sollten zwei Profile dieselbe E-Mail-Adresse verwenden, sind beide von der Quarantäne betroffen.
Falls jedoch ein Profil mit einer E-Mail-Adresse in Quarantäne eine neue Adresse angibt, kann es erneut in Versandzielgruppen aufgenommen werden.
Im Gegensatz dazu sind es bei der Blacklist die Profile selbst, die vom Versand ausgeschlossen werden. Dies ist z. B. nach einem Opt-out der Fall.
Wenn ein Benutzer auf eine SMS-Nachricht mit einem Schlüsselwort wie "STOP" antwortet, um sich vom SMS-Versand abzumelden, wird sein Profil nicht wie bei einem E-Mail-Abmeldevorgang auf die Blacklist gesetzt. Die Telefonnummer des Profils wird unter Quarantäne gestellt, sodass der Benutzer weiterhin E-Mail-Nachrichten erhält.

In Quarantäne befindliche Adressen identifizieren

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

Für einen Versand in Quarantäne befindliche Adressen identifizieren

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

Für die gesamte Plattform in Quarantäne befindliche Adressen identifizieren

Administratoren können die für die gesamte Plattform in Quarantäne befindlichen Adressen im Knoten Administration > Kampagnenverwaltung > Unzustellbarkeitsverwaltung > Adressen unzustellbarer Sendungen anzeigen.
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:
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 dass die Empfängertabelle pro Jahr um 50 % wächst, lässt sich der Quarantänezuwachs wie folgt berechnen:
Ende 1. Jahr: (1 x 0,33) / (1 + 0,5) = 22 %. Ende von Jahr 2: ((1,22*0,33)+0,33)/(1,5+0,75)=32,5 %.

In Versandberichten in Quarantäne befindliche Adressen identifizieren

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.

Für einen Empfänger in Quarantäne befindliche Adressen identifizieren

Sie können für jeden Empfänger den Status seiner E-Mail-Adresse prüfen. Klicken Sie hierfür im Empfängerprofil auf den Tab Sendungen . Für jeden an den Empfänger gerichteten Versand wird angezeigt, ob er fehlgeschlagen ist, die Adresse während der Analyse unter Quarantäne gestellt wurde etc. Es besteht des Weiteren die Möglichkeit, nur die Empfänger anzuzeigen, deren Adresse in Quarantäne ist, indem Sie den Anwendungsfilter E-Mail-Adresse in Quarantäne nutzen.

Adresse aus der Quarantäne nehmen

Sie haben die Möglichkeit, eine Adresse aus der Quarantäne zu nehmen, indem Sie manuell ihren Status auf Gültig setzen.
Wenn Sie den Status Auf Whitelist wählen, wird die Adresse auch bei Fehlern systematisch in die Zustellung einbezogen.
Adressen auf der Blacklist sind nicht von der Quarantäneverwaltung betroffen und werden nicht in die Zustellung einbezogen, auch wenn ihr Status manuell geändert wurde.
Sie können außerdem die Fehlerschwelle und die Spanne zwischen zwei Fehlern anpassen. Auf die entsprechenden Parameter kann im Softwareverteilungs-Assistenten (E-Mail-Kanal / erweiterte Parameter) zugegriffen werden. Näheres zum Softwareverteilungs-Assistenten erfahren Sie in diesem Abschnitt .

Ursachen für Quarantänen

Adobe Campaign verwaltet die Quarantäne je nach dem Typ des Versandfehlers und dem Grund, der bei der Qualifizierung von Fehlermeldungen (siehe Bounce-Message-Qualifizierung und Typen und Ursachen für fehlgeschlagene Sendungen ) zugewiesen wurde.
  • 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.
Bei Adressen in Quarantäne zeigt das Feld Fehlerursache an, was die Quarantäne ausgelöst hat. 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.

Verwaltung von Softbounces

Im Gegensatz zu Hardbounces senden Softbounces nicht sofort eine Adresse in die Quarantäne, sondern erhöhen stattdessen einen Fehlerzähler.
  • Wenn der Zähler eine festgelegte Schwelle überschreitet, kommt die Adresse in Quarantäne.
  • Die Standardkonfiguration sieht eine Schwelle von fünf Fehlern vor, die jeweils in einem Abstand von mindestens 24 Stunden auf den vorhergehenden folgen müssen, um berücksichtigt zu werden. Beim fünften Fehler kommt die Adresse in Quarantäne.
  • Die Schwelle für den Fehlerzähler ist einstellbar. 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.

Quarantäne für Push-Benachrichtigungen

Der Quarantänemechanismus für Push-Benachrichtigungen ist global gesehen mit dem allgemeinen Prozess identisch. Näheres dazu erfahren Sie unter Über Quarantänen . 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

Für iOS - binäre Connectoren
Für jede Benachrichtigung empfängt Adobe Campaign die synchronen und asynchronen Fehler vom APNS-Server. Bei den folgenden synchronen Fehlern erzeugt Adobe Campaign Softbounces:
  • Fehler durch Nutzdatenlänge: kein Neuversuch, der Grund für den Fehler ist Unerreichbar .
  • Fehler durch Ablauf des Zertifikats: kein Neuversuch, der Grund für den Fehler ist Unerreichbar .
  • Verbindungsabbruch während der Zustellung: Neuversuch wird unternommen, der Grund für den Fehler ist Unerreichbar .
  • Fehler bei der Konfiguration des Dienstes (ungültiges Zertifikat, ungültiges Passwort für Zertifikat, kein Zertifikat): kein Neuversuch, der Grund für den Fehler ist Unerreichbar .
Der APNS-Server benachrichtigt Adobe Campaign asynchron darüber, dass ein Device Token abgemeldet wurde (wenn die Mobile App durch den Empfänger deinstalliert wurde). Der mobileAppOptOutMgt -Workflow wird alle sechs Stunden durchgeführt. Dabei werden die APNS-Feedback-Services aufgefordert, die Tabelle AppSubscriptionRcp zu aktualisieren. Für jedes deaktivierte Token wird das Feld Deaktiviert auf Wahr gesetzt, und das mit diesem Device Token verknüpfte Abonnement wird automatisch von künftigen Sendungen ausgeschlossen.
Für iOS - HTTP/2-Connector
Mit dem HTTP/2-Protokoll können Feedback und Status für jeden Push-Versand direkt festgestellt werden. Wenn der HTTP/2-Protokoll-Connector verwendet wird, wird der Feedback-Dienst nicht mehr vom mobileAppOptOutMgt -Workflow angerufen. Die abgemeldeten Token werden vom binären iOS-Connector und vom iOS-HTTP/2-Connector unterschiedlich gehandhabt. Ein Token gilt als abgemeldet, wenn eine Mobile App deinstalliert oder erneut installiert wird.
Wenn das APNS für eine Nachricht den Status "abgemeldet" zurückgibt, wird der Target Token sofort in 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 Fehler 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 Anwendung 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

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 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.
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 zehn Minuten, um den Status der versendeten Nachrichten abzurufen, und aktualisiert die Versandlogs. Wenn eine Nachricht als gesendet gemeldet wird, ändert sich der Status der Nachricht in den Versandlogs in Erhalten . Wenn Baidu einen Fehler meldet, wird der Status auf Fehlgeschlagen gesetzt.
Für Android V2
Das Quarantäneverfahren für Android V2 ist identisch mit dem für Android V1. Dasselbe gilt für die Aktualisierung von Anmeldungen und Ausschlüssen. Weiterführende Informationen dazu 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

Quarantäne für SMS

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.
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 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.
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. Siehe diese 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. Siehe auch diese 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. Siehe auch diese Seite .
    Standardmäßig erfolgt die Regex-Extraktion des err: -Felds entsprechend der Definition im Bereich Appendix 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. 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.