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.

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:

E-poststudsar bounce-mail-qualification

Hur studseffekter hanteras i Adobe Campaign beror på feltypen:

Å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.

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:

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 .

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#

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.

Felsökning av leveransfel troubleshooting

I det här avsnittet finns vägledning om diagnostisering och lösning av vanliga leveransproblem.

Status misslyckades med personaliseringsfel personalization-errors

Om statusen för en e-postleverans är Failed kan den länkas till ett problem med personaliseringsblock. Personaliseringsblock i en leverans kan generera fel när scheman inte matchar leveransmappningen.

Leveransloggar är viktiga för att lära sig varför en leverans misslyckades. Här är ett vanligt fel som du kan råka ut för:

Mottagarmeddelanden misslyckas med felet "Onåbar" som anger:

Error while compiling script 'content htmlContent' line X: `[table]` is not defined. JavaScript: error while evaluating script 'content htmlContent

Orsak: Personaliseringen inom HTML försöker anropa en tabell eller ett fält som inte har definierats eller mappats i den överordnade målsättningen eller i leveransens målmappning.

Upplösning: Granska arbetsflödes- och leveransinnehållet för att specifikt avgöra vilken personalisering som försöker anropa tabellen i fråga. Ta sedan bort anropet till den här tabellen i HTML eller åtgärda mappningen till leveransen.

Läs mer om personalisering i det här avsnittet.

Fel med flera personaliseringsvärden multiple-values-error

När en leverans misslyckas kan följande fel visas i leveransloggarna:

DLV-XXXX The count of message prepared (123) is greater than the number of messages to send (111). Please contact support.

Orsak: Det finns ett anpassningsfält eller -block i e-postmeddelandet som har mer än ett värde för mottagaren. Ett personaliseringsblock används och hämtar mer än en post för en viss mottagare.

Upplösning: Kontrollera de personaliseringsdata som används och kontrollera sedan målet för mottagare som har mer än en post för något av dessa fält. Du kan också använda en Deduplication-aktivitet i målarbetsflödet före leveransaktiviteten för att se till att det bara finns ett personaliseringsfält åt gången. Mer information om borttagning av dubbletter finns i arbetsflödesdokumentationen.

Automatisk svarshantering auto-reply-handling

Vissa leveranser kan misslyckas med felet "Onåbar" som anger:

Inbound email bounce (rule 'Auto_replies' has matched this bounce).

Förklaring: Det innebär att leveransen lyckades, men Adobe Campaign fick ett automatiskt svar från mottagaren (t.ex. ett frånvaromeddelande) som matchade e-postreglerna för inkommande e-post för Auto_responses).

E-postadressen för automatiskt svar ignoreras av Adobe Campaign och mottagarens adress skickas inte till karantän. Detta är ett förväntat beteende som inte tyder på ett leveransfel.

Relaterade ämnen

Leveransstatus förklarar de olika statusvärden en leverans kan ha under sin livscykel.

Övervaka leveranser i Campaign-gränssnittet ger vägledning om hur du använder kontrollpanelen för leverans för att spåra leveransresultat och diagnostisera problem.

Karantänhantering förklarar hur Campaign hanterar adresser i karantän för att skydda ditt sändningsrykte.

Övervaka din leveransförmåga ger vägledning om hur du kan upprätthålla bra leveransförmåga och avsändarens anseende.

Bästa tillvägagångssätt vid leverans omfattar bästa praxis för att skapa och skicka leveranser i Campaign.