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.
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.
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.
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.
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 .
- 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.
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.
SMS-karantän sms-quarantines
För standardanslutningar
Specifikationerna för SMS-kanalen anges nedan.
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.
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.