Förstå leveransfel delivery-failures

Satser är resultatet av ett leveransförsök och fel där Internet-leverantören tillhandahåller meddelanden om misslyckanden. Hantering av studsar är en viktig del av listhygienen. När ett visst e-postmeddelande har studsat flera gånger i rad flaggas det för undertryckning i den här processen.

Den här processen förhindrar att system fortsätter att skicka ogiltiga e-postadresser. Satser är en av de viktigaste data som internetleverantörer använder för att fastställa IP-anseendet. Det är viktigt att hålla ett öga på denna mätmetod. "Levererat" jämfört med "studsat" är förmodligen det vanligaste sättet att mäta leveransen av marknadsföringsmeddelanden: ju högre procenttal som levereras, desto bättre.

Om ett meddelande inte kan skickas till en profil skickar fjärrservern automatiskt ett felmeddelande till Adobe Campaign. Det här felet är kvalificerat för att avgöra om e-postadressen, telefonnumret eller enheten ska sättas i karantän. Se E-posthantering.

När ett meddelande har skickats kan du visa leveransstatus för varje profil och tillhörande feltyp och orsak i leveransloggarna.

När en e-postadress sätts i karantän, eller om en profil finns på blockeringslista, utesluts mottagaren vid leveransförberedelsesteget. Exkluderade meddelanden visas på kontrollpanelen för leverans.

Varför misslyckades meddelandeleveransen delivery-failure-reasons

Det finns två typer av fel när ett meddelande misslyckas. Varje typ av leveransfel avgör om en adress skickas till karantän eller inte.

  • Hårda studsar
    Hårda studsar är permanenta fel som genereras efter att en Internet-leverantör har fastställt att ett postförsök till en prenumerantadress inte kan levereras. Inom Adobe Campaign läggs hårda gränser som kategoriseras som olevererbara till i karantänlistan, vilket innebär att de inte kommer att försökas igen. I vissa fall ignoreras ett hårt studsfall om orsaken till felet är okänd.

    Här är några vanliga exempel på hårda domäner: Adressen finns inte, Konto inaktiverat, Felaktig syntax, Dålig domän

  • Mjuka studsar
    Mjuka studsar är tillfälliga fel som internetleverantörer genererar när de har svårt att leverera e-post. Mjuka fel försökerigen flera gånger (med varians beroende på om anpassade leveransinställningar eller leveransinställningar som är klara används) för att försöka leverera korrekt. Adresser som kontinuerligt mjuka studsar kommer inte att läggas till i karantän förrän det maximala antalet försök har gjorts (som återigen varierar beroende på inställningarna).

    Några vanliga orsaker till mjuka studsar är: Postlådan är full, Tar emot e-postserver, Senderns anseendeproblem

Feltypen Ignorerad är känd som tillfällig, till exempel "Frånvarande", eller ett tekniskt fel, till exempel om avsändartypen är "postmaster".

Feedback-slingan fungerar som studsmeddelanden: när en användare kvalificerar ett e-postmeddelande som skräppost kan du konfigurera e-postregler i Adobe Campaign så att alla leveranser till den här användaren blockeras. Adresserna till dessa användare är blocklist trots att de inte klickade på länken för att ta bort prenumerationen. Adresser läggs till i karantäntabellen (NmsAddress) och inte i mottagartabellen (NmsRecipient) med statusen Denylisted. Läs mer om feedbackloopmekanismen i Adobe Deliverability Best Practices Guide.

Synkrona och asynkrona fel synchronous-and-asynchronous-errors

En meddelandeleverans kan misslyckas omedelbart, i så fall kvalificerar vi det som ett synkront fel. Om meddelandet inte kan skickas eller senare, efter att det har skickats, är felet asynkront.

Följande typer av fel hanteras:

  • Synkront fel: Fjärrservern som kontaktas av Adobe Campaign leveransserver returnerar omedelbart ett felmeddelande. Leveransen får inte skickas till profilens server. MTA (Mail Transfer Agent) bestämmer studstypen och kvalificerar felet och skickar tillbaka informationen till Campaign för att avgöra om e-postadresserna ska placeras i karantän. Se Kvalifikation av studsmeddelanden.

  • Asynkront fel: ett studsmeddelande eller en SR skickas senare av den mottagande servern. Det här felet är kvalificerat med en etikett som är relaterad till felet. Asynkrona fel kan uppstå upp till en vecka efter att en leverans har skickats.

NOTE
Som användare av Hanterade Cloud Service konfigureras studspostlådan av Adobe.

E-poststudsar bounce-mail-qualification

Hur studseffekter hanteras i Adobe Campaign beror på feltypen:

  • Synkrona fel: MTA fastställer studstyp och kvalificering och skickar tillbaka informationen till Campaign. Studskompetensen i tabellen Delivery log qualification används inte för synkrona leveransfelmeddelanden.

  • Asynkrona fel: Regler som används av Campaign för att kvalificera asynkrona leveransfel visas i noden Administration > Campaign Management > Non deliverables Management > Delivery log qualification. Asynkrona studsar kvalificeras av inMail-processen via reglerna Inbound email. Mer information finns i Adobe Campaign Classic v7-dokumentationen.

Återförsökshantering retries

Om meddelandeleveransen misslyckas på grund av ett tillfälligt fel (Mjuk eller Ignorerad), skickas kampanjen igen. Dessa återförsök kan utföras till slutet av leveransens varaktighet.

MTA avgör vilken typ av avhoppssvar som skickas tillbaka från meddelandets e-postdomän och hur lång tid det tar mellan dem.

NOTE
Inställningar för nya försök i leveransegenskaperna används inte av Campaign.

Giltighetsperiod valid-period

Giltighetsperiodens inställning i kampanjleveranser är begränsad till ,3,5 dagar eller mindre. Om du definierar ett värde som är högre än 3,5 dagar för en leverans i Campaign beaktas det inte.

Om giltighetsperioden till exempel är inställd på standardvärdet 5 dagar i Campaign, kommer meddelanden med mjuk studsning att hamna i MTA-återförsökskön och provas igen i upp till 3,5 dagar från den dag då meddelandet nådde MTA. I så fall används inte det värde som angetts i Campaign.

När ett meddelande har funnits i MTA-kön i 3,5 dagar och inte kunnat levereras, kommer det att gå ut och dess status kommer att uppdateras från Sent till Failed i leveransloggarna.

Mer information om giltighetsperioden finns i Adobe Campaign Classic v7-dokumentationen.

E-postfeltyper email-error-types

För e-postkanalen anges möjliga orsaker till leveransfel nedan.

Feletikett
Feltyp
Tekniskt värde
Beskrivning
Kontot är inaktiverat
Mjuk/hård
4
Kontot som är länkat till adressen är inte längre aktivt. När IAP (Internet Access Provider) upptäcker en lång inaktivitetsperiod kan den stänga användarens konto. Det går då inte att skicka till användarens adress. Om kontot är tillfälligt inaktiverat på grund av sex månaders inaktivitet och fortfarande kan aktiveras, tilldelas statusen Med fel och kontot provas igen tills felräknaren når 5. Om felet signalerar att kontot är permanent inaktiverat ställs det in direkt på Karantän.
Adress i karantän
Hård
9
Adressen placerades i karantän.
Adressen har inte angetts
Hård
7
Ingen adress har angetts för mottagaren.
Felaktig adress
Ignorerad
14
Kvalitetsklassificeringen för den här adressen är för låg.
Blocklist adress
Hård
8
Adressen lades till i blockeringslista vid tidpunkten för sändningen. Den här statusen används för att importera data från externa listor och externa system till Adobe Campaign-karantänlistan.
Kontrolladress
Ignorerad
127
Mottagarens adress ingår i kontrollgruppen.
Dubbel
Ignorerad
10
Mottagarens adress fanns redan i den här leveransen.
Felet ignorerades
Ignorerad
25
Adressen är på tillåtelselista. Felet ignoreras därför och ett e-postmeddelande skickas.
Uteslutet efter skiljedom
Ignorerad
12
Mottagaren uteslöts av en kampanjtypologiregel av typen "medling".
Exkluderad av en SQL-regel
Ignorerad
11
Mottagaren uteslöts av en kampanjtypologiregel av typen SQL.
Ogiltig domän
Mjuk
2
Domänen för e-postadressen är felaktig eller finns inte längre. Den här profilen används igen tills felantalet är 5. Därefter anges posten till Karantänstatus och inga nya försök följer.
Postlådan är full
Mjuk
5
Den här användarens postlåda är full och kan inte ta emot fler meddelanden. Den här profilen används igen tills felantalet är 5. Därefter sätts postens status till Karantän och inga nya försök görs.
Den här typen av fel hanteras av en rensningsprocess. Adressen har en giltig status efter 30 dagar.
Varning! Det tekniska arbetsflödet för databasrensning måste startas för att adressen automatiskt ska tas bort från listan över adresser i karantän.
Inte ansluten
Ignorerad
6
Mottagarens mobiltelefon är avstängd eller inte ansluten till nätverket när meddelandet skickas.
Ej definierad
Ej definierad
0
Adressen kvalificerar sig eftersom felet ännu inte har ökats. Den här typen av fel inträffar när ett nytt felmeddelande skickas av servern: det kan vara ett isolerat fel, men om det inträffar igen ökar felräknaren, som varnar de tekniska teamen. De kan sedan utföra meddelandeanalys och kvalificera det här felet via noden Administration / Campaign Management / Hantering av icke-slutprodukter i trädstrukturen.
Erbjudandena är inte giltiga
Ignorerad
16
Mottagaren var inte berättigad till erbjudandena i leveransen.
Avvisad
Mjuk/hård
20
Adressen har placerats i karantän på grund av säkerhetsfeedback som en skräppostrapport. Enligt felet görs ett nytt försök att ange adressen tills felräknaren når 5, eller så skickas den direkt till karantän.
Målet är begränsat
Ignorerad
17
Den maximala leveransstorleken har uppnåtts för mottagaren.
Okvalificerad adress
Ignorerad
15
Postadressen har inte kvalificerats.
Onåbar
Mjuk/hård
3
Ett fel har uppstått i meddelandeleveranskedjan. Det kan vara en incident på SMTP-relä, en domän som inte går att nå för tillfället, osv. Enligt felet görs ett nytt försök att ange adressen tills felräknaren når 5, eller så skickas den direkt till karantän.
Okänd användare
Hård
1
Adressen finns inte. Inga fler leveransförsök kommer att göras för den här profilen.

Feltyper för push-meddelanden push-error-types

För mobilappskanalen anges möjliga orsaker till leveransfel nedan.

iOS karantän ios-quarantine

HTTP/V2-protokollet tillåter direkt feedback och status för varje push-leverans. Om HTTP/V2-protokollkopplingen används anropas inte längre feedbacktjänsten av arbetsflödet mobileAppOptOutMgt. En token betraktas som oregistrerad när ett mobilprogram avinstalleras eller installeras om.

Synkront, om APN:er returnerar status "unregistered" för ett meddelande, sätts måltoken omedelbart i karantän.

Scenario
Status
Felmeddelande
Feltyp
Felorsak
Försök igen
Målenheten är påslagen
OK
Målenheten är avstängd
OK
Användaren inaktiverar meddelanden för programmet
OK
Fas för att skapa/analysera meddelanden - nyttolasten är för stor
Fel
Nyttolasten är för lång
Mjuk
Avvisad
Nej
Fas för att skapa/analysera meddelanden - oväntat innehållsformatproblem
Fel
Olika felmeddelanden enligt felet
Mjuk
Odefinierad
Nej
Certifikatproblem (lösenord, fel osv.) och testa anslutningen till APN-problemet
Fel
Olika felmeddelanden enligt felet
Mjuk
Avvisad
Nej
Nätverksanslutningen bröts under sändning av
Fel
Anslutningsfel
Odefinierad
Onåbar
Ja
Avvisning av APN-meddelande: Avregistrering
har tagits bort av användaren eller så har token upphört att gälla
Fel
Oregistrerad
Hård
Okänd användare:
Nej
Meddelandeavvisande för APN: alla andra fel
Fel
Felavvisandeorsaken kommer att finnas i felmeddelandet
Mjuk
Avvisad
Nej

Android karantän android-quarantine

För Android v1

För varje meddelande får Adobe Campaign synkrona fel direkt från FCM-servern. Adobe Campaign hanterar dem i farten och genererar hårda eller mjuka fel beroende på hur allvarligt felet är, och nya försök kan utföras:

  • Nyttolastlängden har överskridits, anslutningsproblem, problem med tjänsttillgänglighet: återförsök utförd, mjukt fel, felorsak är Refused.
  • Enhetskvoten har överskridits: inga nya försök, inget mjukt fel, felorsaken är Refused.
  • Ogiltig eller oregistrerad token, oväntat fel, problem med avsändarkontot: inget nytt försök, hårt fel, felorsaken är Refused.

Arbetsflödet mobileAppOptOutMgt körs var sjätte timme för att uppdatera tabellen AppSubscriptionRcp. För tokens som deklarerats som oregistrerade eller inte längre giltiga ställs fältet Inaktiverad in på Sant och prenumerationen som är länkad till den enhetstoken exkluderas automatiskt från framtida leveranser.

Under leveransanalysen läggs alla enheter som är undantagna från målet automatiskt till i tabellen excludeLogAppSubRcp .

NOTE
Här är olika typer av fel för kunder som använder Baidu-kontakten:
  • Anslutningsproblem i början av leveransen: feltyp Undefined, felorsak Unreachable, nytt försök utförs.
  • Anslutningen bröts under en leverans: mjukt fel, felorsak Refused, nytt försök utförs.
  • Synkront fel returnerades av Baidu under sändning: hårt fel, felorsak Refused, inga nya försök utförs.
Adobe Campaign kontaktar Baidu-servern var 10:e minut för att hämta det skickade meddelandets status och uppdaterar sändningarna. Om ett meddelande deklareras som skickat anges meddelandets status i utsändningsloggarna till Received. Om Baidu deklarerar ett fel anges statusen till Failed.

För Android V2

Android V2-karantänmekanismen använder samma process som Android V1, samma sak gäller för prenumerations- och exkluderingsuppdateringen. Mer information finns i avsnittet Android V1.

Scenario
Status
Felmeddelande
Feltyp
Felorsak
Försök igen
Fas för skapande/analys av meddelanden: ogiltiga nyckelord används i anpassade fält
Fel
Följande nyckelord kan inte användas: {1}
Mjuk
Nej
Fas för att skapa/analysera meddelanden: nyttolasten är för stor
Fel
Meddelandet är för stort: {1} bitar, endast {2} är auktoriserade
Mjuk
Avvisad
Nej
Nätverksanslutningen bröts under sändning av
Fel
Inget svar från tjänsten Firebase Cloud Messaging på adressen: {1}
Mjuk
Onåbar
Ja
FCM-meddelandeavvisande: FCM-servern är inte tillgänglig för tillfället (till exempel med timeout).
Fel
Tjänsten Firebase Cloud Messaging är inte tillgänglig för tillfället
Mjuk
Onåbar
Ja
FCM-meddelandeavvisande: Fel vid autentisering av avsändarkontot
Fel
Det gick inte att identifiera utvecklarkontot. Kontrollera ditt ID och lösenord
Mjuk
Avvisad
Nej
FCM-meddelandeavvisande: Enhetskvoten har överskridits
Fel
Mjuk
Avvisad
Ja
FCM-meddelandeavvisande: Ogiltig registrering/inte registrerad
Fel
Hård
Okänd användare:
Nej
FCM-meddelandeavvisande: Alla andra fel
Fel
Firebase Cloud Messaging-servern returnerade en oväntad felkod: {1}
Avvisad
Nej
FCM-meddelandeavvisande: Ogiltigt argument
Fel
INVALID_ARGUMENT
Ignorerad
Odefinierad
Nej
FCM-meddelandeavvisande: Autentiseringsfel från tredje part
Fel
THIRD_PARTY_AUTH_ERROR
Ignorerad
Avvisad
Ja
FCM-meddelandeavvisande: Avsändarens ID matchar inte
Fel
SENDER_ID_MISMATCH
Mjuk
Okänd användare:
Nej
FCM-meddelandeavvisande: Avregistrerad
Fel
OREGISTRERAD
Hård
Okänd användare:
Nej
FCM-meddelandeavvisande: Intern
Fel
INTERN
Ignorerad
Avvisad
Ja
FCM-meddelandeavvisande: Otillgänglig
Fel
OTILLGÄNGLIG
Ignorerad
Avvisad
Ja
FCM-meddelandeavvisande: oväntad felkod
Fel
oväntad felkod
Ignorerad
Avvisad
Nej
Autentisering: Anslutningsproblem
Fel
Det går inte att ansluta till autentiseringsservern
Ignorerad
Avvisad
Ja
Autentisering: Oauktoriserad klient eller omfång i begäran.
Fel
unauthorized_client
Ignorerad
Avvisad
Nej
Autentisering: Klienten saknar behörighet att hämta åtkomsttoken med den här metoden, eller klienten har inte behörighet för de begärda scopen.
Fel
unauthorized_client
Ignorerad
Avvisad
Nej
Autentisering: Åtkomst nekad
Fel
access_deny
Ignorerad
Avvisad
Nej
Autentisering: Ogiltig e-postadress
Fel
invalid_grant
Ignorerad
Avvisad
Nej
Autentisering: Ogiltig JWT
Fel
invalid_grant
Ignorerad
Avvisad
Nej
Autentisering: Ogiltig JWT-signatur
Fel
invalid_grant
Ignorerad
Avvisad
Nej
Autentisering: Ogiltig OAuth-scope eller angiven ID-tokenpublik
Fel
unauthorized_client
Ignorerad
Avvisad
Nej
Autentisering: OAuth-klienten inaktiverad
Fel
disabled_client
Ignorerad
Avvisad
Nej

SMS-karantän sms-quarantines

För standardanslutningar

Specifikationerna för SMS-kanalen anges nedan.

NOTE
Tabellen Delivery log qualification gäller inte för den allmänna SMPP -anslutningen Extended.
Scenario
Status
Felmeddelande
Feltyp
Felorsak
Skickat till providern
Skickat
Mottaget på mobilen
Mottaget
Ett fel returnerades av providern
Fel
Ett fel uppstod när data togs emot (SR eller MO)
Mjuk
Onåbar
Ogiltig MT-bekräftelse
Fel
Felet {1} uppstod när bekräftelseramen för sändningsfrågan
bearbetades
Mjuk
Onåbar
Ett fel uppstod när MT
skickades
Fel
Fel när meddelanden
skickades
Mjuk
Onåbar

För den utökade allmänna SMPP-anslutningen

När SMPP-protokollet används för att skicka SMS-meddelanden hanteras felhanteringen på ett annat sätt.

SMPP-kopplingen hämtar data från SR-meddelandet (statusrapport) som returneras med reguljära uttryck (regex) för att filtrera innehållet. Dessa data matchas sedan mot informationen i tabellen Delivery log qualification (som är tillgänglig via menyn Administration > Campaign Management > Non deliverables Management).

Innan en ny typ av fel kvalificeras är felorsaken alltid inställd på Refused som standard.

NOTE
Feltyperna och orsakerna till felet är desamma som för e-postmeddelanden.
Be leverantören om en lista över status- och felkoder för att ange korrekta feltyper och orsaker till felet i tabellen för leveransloggens kvalificeringsregister.

Exempel på ett genererat meddelande:

SR Generic DELIVRD 000|#MESSAGE#
  • Alla felmeddelanden börjar med SR för att skilja mellan SMS-felkoder och e-postfelkoder.

  • Den andra delen (Allmänt i det här exemplet) av felmeddelandet refererar till namnet på SMSC-implementeringen, som definieras i fältet SMSC implementation name i det externa SMS-kontot.

    Eftersom samma felkod kan ha olika innebörd för varje provider kan du med det här fältet veta vilken provider som genererade felkoden. Du kan sedan hitta felet i den aktuella providerns dokumentation.

  • Den tredje delen (DELIVRD i det här exemplet) av felmeddelandet motsvarar statuskoden som hämtats från SR med statusextraheringsregex som definierats i det externa SMS-kontot.

    Den här regionen anges på fliken SMSC specificities i det externa kontot.
    Regex extraherar som standard fältet stat: enligt definitionen i avsnittet Bilaga B i specifikationen SMPP 3.4.

  • Den fjärde delen (000 i det här exemplet) av felmeddelandet motsvarar den felkod som extraheras från SR med hjälp av den felkodsextraheringsregex som definierats i det externa SMS-kontot.

    Den här regionen anges på fliken SMSC specificities i det externa kontot.

    Regex extraherar som standard fältet err: enligt definitionen i avsnittet Bilaga B i specifikationen SMPP 3.4.

  • Allt som kommer efter lodstreck (|) visas bara i kolumnen First text i tabellen Delivery log qualification. Det här innehållet ersätts alltid av #MESSAGE# efter att meddelandet har normaliserats. Med den här processen undviker du att ha flera poster för liknande fel och den är samma som för e-postmeddelanden.

Den utökade generiska SMPP-anslutningen använder en heuristisk metod för att hitta rimliga standardvärden: om statusen börjar med DELIV betraktas den som lyckad eftersom den matchar de vanliga statusvärdena DELIVRD eller DELIVERED som används av de flesta leverantörer. All annan status leder till ett allvarligt fel.

recommendation-more-help
35662671-8e3d-4f04-a092-029a056c566b