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 med studs.

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ök igen flera gånger (med olika variationer beroende på hur anpassade leveransinställningar eller leveransinställningar som är klara) 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

The Ignorerad typen av fel är temporär, t.ex."Frånvarande", eller ett tekniskt fel, t.ex. 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 (NmsAddress) karantänregister och inte till (NmsRecipient) mottagartabell med Denylisted status. Läs mer om feedbackloopmekanismen i Guide för bästa praxis för Adobe-leverans.

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 avgör studstyp och kvalifikationer och skickar tillbaka den informationen till Campaign. Studenternas kvalifikationer i Delivery log qualification tabellen används inte för synkron felmeddelanden vid leveransfel.

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

Återförsökshantering retries

Om meddelandeleveransen misslyckas efter ett tillfälligt fel (Mjuk eller Ignorerad) skickas kampanjåterförsök. 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

Giltighetsperioden i kampanjleveranserna ä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 uppdateras från Sent till Failed i leveransloggarna.

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

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 felmeddelandet talar om 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 listan över Adobe Campaign-karantän.
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! För att adressen ska tas bort automatiskt från listan över adresser i karantän måste det tekniska arbetsflödet för databasrensning startas.
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 göra en meddelandeanalys och kvalificera felet via Administration / Campaign Management / Hantering av ej 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 skickas direkt till karantän.
Målet är begränsat
Ignorerad
17
Den maximala leveransstorleken har uppnåtts för mottagaren.
Okvalificerad adress
Ignorerad
15
Posten 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 skickas 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 mobileAppOptOutMgt arbetsflöde. 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ålenhet aktiverad
OK
Målenheten är avstängd
OK
Användaren inaktiverar meddelanden för programmet
OK
Skapande/analys av meddelande - nyttolasten är för stor
Fel
Nyttolasten är för lång
Mjuk
Avvisad
Nej
Fas för att skapa/analysera meddelanden - oväntat problem med innehållsformat
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
Fel
Anslutningsfel
Odefinierad
Onåbar
Ja
Avvisning av APN-meddelande: Avregistrering
användaren har tagit bort programmet eller token har gått ut
Fel
Oregistrerad
Hård
Okänd användare
Nej
Avvisning av APN-meddelande: 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 Refused.
  • Enhetskvoten har överskridits: inga nya försök, mjukt fel, felorsak Refused.
  • Ogiltig eller oregistrerad token, oväntat fel, problem med avsändarkontot: inget nytt försök, hårt fel, felorsaken är Refused.

The mobileAppOptOutMgt arbetsflödet körs var 6:e timme för att uppdatera AppSubscriptionRcp tabell. Fältet för tokens som har deklarerats som oregistrerade eller inte längre giltiga Handikappade är inställd på True och prenumerationen som är länkad till denna enhetstoken exkluderas automatiskt från framtida leveranser.

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

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, återförsök utförs.
  • Anslutningen bröts under leveransen: mjukt fel, felorsak Refused, återfö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 ställs statusen in på Failed.

För Android V2

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

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 tillåtna
Mjuk
Avvisad
Nej
Nätverksanslutningen bröts under sändning
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
Avvisning av FCM-meddelande: Oregistrerad
Fel
OREGISTRERAD
Hård
Okänd användare
Nej
Avvisning av FCM-meddelande: Internt
Fel
INTERN
Ignorerad
Avvisad
Ja
FCM-meddelandeavvisande: Otillgängligt
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 publik för OAuth-scope eller ID-token har angetts
Fel
unauthorized_client
Ignorerad
Avvisad
Nej
Autentisering: OAuth-klient inaktiverad
Fel
disabled_client
Ignorerad
Avvisad
Nej

SMS-karantän sms-quarantines

För standardanslutningar

Specifikationerna för SMS-kanalen anges nedan.

NOTE
The Delivery log qualification tabellen gäller inte för Utökad allmän SMPP koppling.
Scenario
Status
Felmeddelande
Feltyp
Felorsak
Skickat till providern
Skickat
Mottaget på mobilen
Mottaget
Ett fel returnerades av providern
Fel
Fel vid mottagning av data (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
Fel när MT skickades
Fel
Fel när meddelanden skickades
Mjuk
Onåbar

För den utökade generiska 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 Delivery log qualification tabell (tillgänglig via Administration > Campaign Management > Non deliverables Management meny).

Innan en ny typ av fel har kvalificerats anges felorsaken alltid till Avvisad 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.

  • Andra delen (Allmän i det här exemplet) refererar felmeddelandet till namnet på SMSC-implementeringen som definieras i SMSC implementation name fält för SMS-externt konto.

    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 (LEVERERA i det här exemplet) motsvarar felmeddelandet statuskoden som hämtats från SR med statusextraheringsregex som definierats i det externa SMS-kontot.

    Denna region anges i SMSC specificities fliken för det externa kontot.
    Regexen extraherar som standard stat: fält enligt definitionen i Tillägg B i Specifikation för SMPP 3.4.

  • Fjärde delen (000 i det här exemplet) motsvarar felmeddelandet den felkod som extraheras från SR med den felkodsextraheringsregex som definieras i det externa SMS-kontot.

    Denna region anges i SMSC specificities fliken för det externa kontot.

    Regexen extraherar som standard err: fält enligt definitionen i Tillägg B i Specifikation för SMPP 3.4.

  • Allt som kommer efter rörlighetssymbolen (|) visas bara i First text kolumn i Delivery log qualification tabell. Det här innehållet ersätts alltid av #MESSAGE# när 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 kod för att hitta rimliga standardvärden: om statusen börjar med DELIV anses det vara en framgång eftersom det matchar de vanliga statusvärdena LEVERERA eller LEVERERAD används av de flesta leverantörer. All annan status leder till ett allvarligt fel.

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