Leveringsfouten begrijpen delivery-failures
De grenzen zijn het resultaat van een leveringspoging en mislukking waar ISP achtermislukkingsberichten verstrekt. De verwerking van de stuitbehandeling is een kritiek deel van lijsthygiëne. Nadat een bepaalde e-mail meerdere keren achter elkaar is teruggestuurd, wordt deze tijdens dit proces gemarkeerd voor onderdrukking.
Hierdoor wordt voorkomen dat systemen ongeldige e-mailadressen blijven verzenden. De grenzen zijn één van de belangrijkste stukken van gegevens die ISPs gebruikt om IP reputatie te bepalen. Het is belangrijk om deze maatstaf in de gaten te houden. "Geleverd" versus "teruggestort" is waarschijnlijk de meest gebruikelijke manier om de levering van marketingberichten te meten: hoe hoger het geleverde percentage, hoe beter.
Als een bericht niet naar een profiel kan worden verzonden, verzendt de externe server automatisch een foutbericht naar Adobe Campaign. Deze fout is gekwalificeerd om te bepalen of het e-mailadres, het telefoonnummer of het apparaat in quarantaine moet worden geplaatst. Zie stuiteren postbeheer.
Zodra een bericht wordt verzonden, kunt u de leveringsstatus voor elk profiel en het bijbehorende mislukkingstype en de reden in de leveringslogboeken bekijken.
Wanneer een e-mailadres in quarantaine wordt geplaatst, of als een profiel op lijst van gewezen personen is, wordt de ontvanger uitgesloten bij de stap van de leveringsvoorbereiding. Uitgesloten berichten worden vermeld in het leveringsdashboard.
Waarom is de berichtlevering mislukt delivery-failure-reasons
Er zijn twee typen fouten wanneer een bericht mislukt. Elk type van leveringsmislukking bepaalt als een adres wordt verzonden naar quarantaineof niet.
-
Harde grenzen
De harde stegels zijn permanente mislukkingen die worden geproduceerd nadat ISP een postingspoging aan een abonneeadres als niet te leveren niet bepaalt. In Adobe Campaign worden harde golven die als niet-leverbaar zijn gecategoriseerd, toegevoegd aan de quarantainelijst, wat betekent dat ze niet opnieuw zouden worden opgewekt. In sommige gevallen wordt een harde stuit genegeerd als de oorzaak van de fout onbekend is.Hier zijn enkele voorbeelden van harde grenzen: Adres bestaat niet, Account uitgeschakeld, Onjuiste syntaxis, Onjuist domein
-
Zachte grenzen
De zachte grenzen zijn tijdelijke mislukkingen die ISPs produceert wanneer zij moeilijkheden hebben leverend post. De zachte mislukkingen zullen 🔗 veelvoudige tijden (met variantie afhankelijk van gebruik van douane of uit-van-doos leveringsmontages) opnieuw proberen om een succesvolle levering te proberen. Adressen dat voortdurend zachte stuit niet aan quarantaine zal worden toegevoegd tot het maximumaantal herpogingen is geprobeerd (die opnieuw afhankelijk van montages) variëren.Sommige gemeenschappelijke oorzaken van zachte grenzen omvatten het volgende: De volledige brievenbus, Ontvangend e-mailserver neer, de kwesties van de de reputatie van de Afzender
Het genegeerde type van fout is gekend om tijdelijk, zoals "uit bureau"te zijn, of een technische fout, bijvoorbeeld als het afzendertype "postmaster"is.
De feedbacklus werkt als e-mailberichten stuiteren: wanneer een gebruiker een e-mailbericht kwalificeert als spam, kunt u e-mailregels in Adobe Campaign configureren om alle leveringen aan deze gebruiker te blokkeren. De adressen van deze gebruikers worden gevoegd op lijst van gewenste personen alhoewel zij niet de unsubscription verbinding klikten. De adressen worden toegevoegd aan (NmsAddress) quarantainelijst en niet aan (NmsRecipient) ontvankelijke lijst met de Denylisted status. Leer meer over terugkoppel lusmechanisme in de Gids van de Beste praktijken van de Levering van de Adobe.
Synchrone en asynchrone fouten synchronous-and-asynchronous-errors
Een berichtlevering kan onmiddellijk ontbreken, in dat geval kwalificeren wij dit als synchrone fout. Als het verzenden van het bericht mislukt of later, nadat het is verzonden, is de fout asynchroon.
Deze soorten fouten worden als volgt beheerd:
-
Synchrone fout: de verre server die door de leveringsserver van Adobe Campaign wordt gecontacteerd keert onmiddellijk een foutenmelding terug. De levering mag niet naar de server van het profiel worden verzonden. De agent van de Overdracht van de Post (MTA) bepaalt het stuittype en kwalificeert de fout, en verzendt die informatie terug naar Campagne om te bepalen of de e-mailadressen in kwestie zouden moeten worden quarantined. Zie Kwalificatie van niet-bezorgde e-mails.
-
Asynchrone fout: een stuiterende post of een SR wordt teruggebracht later door de ontvangende server. Deze fout is gekwalificeerd met een label dat gerelateerd is aan de fout. Asynchrone fouten kunnen optreden tot een week nadat een levering is verzonden.
Bounce mail-kwalificatie bounce-mail-qualification
De manier waarop de postkwalificatie van de stuiterende in Adobe Campaign wordt behandeld hangt van het foutentype af:
-
Synchrone fouten: MTA bepaalt het stuitertype en de kwalificatie, en verzendt terug die informatie naar Campagne. De stuitkwalificaties in de Delivery log qualification lijst worden niet gebruikt voor synchrone de foutenmeldingen van de leveringsmislukking.
-
Asynchrone fouten: De regels die door Campagne worden gebruikt om asynchrone leveringsmislukkingen te kwalificeren zijn vermeld in de Administration > Campaign Management > Non deliverables Management > Delivery log qualification knoop. Asynchrone stuiteringen worden door het inMail-proces via de Inbound email -regels gekwalificeerd. Voor meer op dit, verwijs naar Adobe Campaign Classic v7 documentatie.
Opnieuw beheren retries
Als de berichtlevering na een tijdelijke fout (Zacht of Genegeerde) ontbreekt, probeert de Campagne opnieuw het verzenden. Deze pogingen kunnen tot het eind aan de leveringsduur worden uitgevoerd.
De zachte stuitpogingen en de tijdsduur tussen hen worden bepaald door MTA gebaseerd op het type en de strengheid van de stuiteringsreacties die van het e-maildomein van het bericht terugkomen.
Geldigheidsperiode valid-period
De geldigheidsperiode die in uw levering van de Campagne plaatst is beperkt tot 3.5 dagen of minder. Als u voor een levering een waarde opgeeft die hoger is dan 3,5 dagen in Campagne, wordt hiermee geen rekening gehouden.
Bijvoorbeeld, als de geldigheidsperiode aan de standaardwaarde van 5 dagen in Campagne wordt geplaatst, zullen de zachte-stuiterende berichten in de MTA hertry rij gaan en slechts 3.5 dagen vanaf toen dat bericht MTA bereikte opnieuw worden geprobeerd. In dat geval wordt de waarde die is ingesteld in Campaign niet gebruikt.
Zodra een bericht 3.5 dagen in de MTA rij is geweest en niet heeft geleverd, zal het uit tijd en zijn status van Sent aan Failed in de leveringslogboeken worden bijgewerkt.
Voor meer op de geldigheidsperiode, zie de documentatie van Adobe Campaign Classic v7.
Typen e-mailfouten email-error-types
Voor het e-mailkanaal worden de mogelijke oorzaken van een leveringsfout hieronder vermeld.
Typen fouten in pushmeldingen push-error-types
Voor het mobiele app-kanaal worden de mogelijke oorzaken van een leveringsfout hieronder vermeld.
iOS quarantaine ios-quarantine
Met het HTTP/V2-protocol kunt u rechtstreeks feedback geven en de status van elke push-levering bepalen. Als de HTTP/V2-protocolconnector wordt gebruikt, wordt de feedbackservice niet meer aangeroepen door de mobileAppOptOutMgt -workflow. Een token wordt als niet-geregistreerd beschouwd wanneer een mobiele toepassing wordt verwijderd of opnieuw wordt geïnstalleerd.
Synchroon, als APNs een "unregistered"status voor een bericht terugkeert, zal het doelteken onmiddellijk in quarantaine worden geplaatst.
Android quarantaine android-quarantine
voor Android V1
Voor elke melding ontvangt Adobe Campaign de synchrone fouten rechtstreeks van de FCM-server. Adobe Campaign verwerkt deze bestanden direct en genereert harde of zachte fouten op basis van de ernst van de fout. U kunt het opnieuw proberen:
- Payloadlengte overschreden, verbindingsprobleem, probleem met beschikbaarheid van service: opnieuw uitgevoerd, soft error, reden van fout is Refused .
- Apparaatquota overschreden: geen nieuwe poging, soft error, reden van mislukking is Refused .
- Ongeldige of niet-geregistreerde token, onverwachte fout, probleem met afzenderaccount: geen nieuwe poging, harde fout, reden van mislukking is Refused .
De mobileAppOptOutMgt werkschemalooppas om de 6 uur om de AppSubscriptionRcp lijst bij te werken. Voor de tekenen die niet geregistreerd of niet meer geldig worden verklaard, wordt het gebied Gehandicapten geplaatst aan Waar en het abonnement verbonden aan dat apparatenteken zal automatisch van toekomstige leveringen worden uitgesloten.
Tijdens de leveringsanalyse, worden alle apparaten die van het doel worden uitgesloten automatisch toegevoegd aan de excludeLogAppSubRcp lijst.
- Verbindingsprobleem aan het begin van de levering: type fout Undefined, reden mislukt Unreachable , wordt opnieuw geprobeerd.
- Verbinding die tijdens een levering verloren gaat: zachte fout, reden van mislukking Refused, wordt opnieuw geprobeerd wordt uitgevoerd.
- Synchrone fout die door Baidu tijdens het verzenden is geretourneerd: harde fout, reden van mislukking Refused; opnieuw proberen wordt niet uitgevoerd.
voor Android V2
Het Android V2-quarantainemechanisme gebruikt hetzelfde proces als Android V1. Hetzelfde geldt voor de abonnementen en uitsluitingen-update. Voor meer op dit verwijs naar Android V1sectie.
SMS-quarantines sms-quarantines
voor standaardschakelaars
De specifieke kenmerken van SMS-kanalen worden hieronder vermeld.
voor de Uitgebreide generische schakelaar SMPP
Wanneer het gebruiken van het protocol SMPP om de berichten van SMS te verzenden, wordt het foutenbeheer verschillend behandeld.
De schakelaar SMPP wint gegevens van het bericht van SR (Status Report) terug dat gebruikend regelmatige uitdrukkingen (regexes) is teruggekeerd om zijn inhoud te filtreren. Deze gegevens worden vervolgens vergeleken met de informatie in de tabel Delivery log qualification (beschikbaar via het menu Administration > Campaign Management > Non deliverables Management ).
Alvorens een nieuw type van fout wordt gekwalificeerd, wordt de mislukkingsreden altijd geplaatst aan Verworpen door gebrek.
Voorbeeld van een gegenereerd bericht:
SR Generic DELIVRD 000|#MESSAGE#
-
Alle foutenmeldingen beginnen met SR om de foutencodes van SMS van e-mailfoutencodes te onderscheiden.
-
Het tweede deel (Algemeen in dit voorbeeld) van het foutenbericht verwijst naar de naam van de implementatie SMSC zoals die in het SMSC implementation name gebied van de externe rekening van SMS wordt bepaald.
Omdat dezelfde foutcode voor elke provider een andere betekenis kan hebben, kunt u in dit veld weten welke provider de foutcode heeft gegenereerd. U kunt de fout dan vinden in de relevante documentatie van de leverancier.
-
Het derde deel (LEVERT in dit voorbeeld) van het foutenbericht beantwoordt aan de statuscode die van SR wordt teruggewonnen gebruikend de regex van de statusextractie die in de externe rekening van SMS wordt bepaald.
Deze regex wordt opgegeven op het tabblad SMSC specificities van de externe account.
Door gebrek, haalt regex de staat: gebied zoals die door de wordt bepaald Bijlage B sectie van de 3.4 specificatie van SMPP. -
Het vierde deel (000 in dit voorbeeld) van het foutenbericht beantwoordt aan de foutencode die uit SR wordt gehaald gebruikend de de extractieregex van de foutencode die in de externe rekening van SMS wordt bepaald.
Deze regex wordt opgegeven op het tabblad SMSC specificities van de externe account.
Door gebrek, haalt regex err: gebied zoals die door de wordt bepaald Bijlage B sectie van de 4} SMPP 3.4 specificatie.
-
Alles wat na het buissymbool (|) komt wordt slechts getoond in de First text kolom van de Delivery log qualification lijst. Deze inhoud wordt altijd vervangen door #MESSAGE# nadat het bericht is genormaliseerd. Dit proces voorkomt het hebben van veelvoudige ingangen voor gelijkaardige fouten en is het zelfde als voor e-mail.
De uitgebreide generische schakelaar SMPP past heuristisch toe om verstandige standaardwaarden te vinden: als de status met LEVERT begint, wordt het beschouwd als een succes omdat het de gemeenschappelijke statussen LEVERT of LEVERDE aanpast die door de meeste leveranciers worden gebruikt. Elke andere status leidt tot een harde fout.