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 Bounce mail management.
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 quarantaine of niet.
-
Harde vlekken
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 golven
De zachte grenzen zijn tijdelijke mislukkingen die ISPs produceert wanneer zij moeilijkheden hebben leverend post. Zachte fouten zullen opnieuw proberen meerdere keren (met variantie afhankelijk van het gebruik van aangepaste of kant-en-klare leveringsinstellingen) om te proberen de levering te voltooien. 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
De Genegeerd Het type fout is bekend als tijdelijk, zoals "Buiten kantoor", of een technische fout, bijvoorbeeld als het type afzender "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. Adressen worden toegevoegd aan de NmsAddress) quarantainetabel en niet de (NmsRecipient) tabel met ontvangers met de Denylisted status. Meer informatie over feedbacklusmechanismen vindt u in het dialoogvenster Handleiding voor best practices voor aflevering van 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 externe server die wordt benaderd door de Adobe Campaign-leveringsserver retourneert direct een foutbericht. 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 teruggestuurd 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 stuittype en de kwalificatie, en stuurt die informatie terug naar Campaign. De stuiterende kwalificaties in de Delivery log qualification tabel wordt niet gebruikt voor synchroon foutberichten over leveringsfout.
-
Asynchrone fouten: De regels die door Campagne worden gebruikt om asynchrone leveringsmislukkingen te kwalificeren zijn vermeld in Administration > Campaign Management > Non deliverables Management > Delivery log qualification knooppunt. Asynchrone stuiteringen worden gekwalificeerd door het inMail-proces via het Inbound email regels. Raadpleeg voor meer informatie hierover Adobe Campaign Classic v7-documentatie.
Opnieuw beheren retries
Als de berichtlevering mislukt na een tijdelijke fout (Zacht of Genegeerd), probeert de campagne opnieuw te 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 u instelt in uw campagneleveringen 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 bijgewerkt van Sent tot Failed in de leveringslogboeken.
Voor meer informatie over de geldigheidsperiode raadpleegt u de Adobe Campaign Classic v7-documentatie.
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 protocolschakelaar wordt gebruikt, koppelt de dienst niet meer wordt geroepen door 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:
- Lengte van lading overschreden, verbindingskwestie, de kwestie van de de dienstbeschikbaarheid: uitgevoerd opnieuw, zachte fout, mislukkingsreden is Refused.
- Apparaatquota overschreden: niet opnieuw proberen, soft error, error reason is Refused.
- Ongeldige of niet-geregistreerde token, onverwachte fout, probleem met afzenderaccount: geen nieuwe poging, harde fout, reden van fout is Refused.
De mobileAppOptOutMgt werkstroom wordt elke 6 uur uitgevoerd om de AppSubscriptionRcp tabel. Voor tokens die niet zijn geregistreerd of niet meer geldig zijn, wordt het veld Uitgeschakeld is ingesteld op Waar en het abonnement op dat apparaattoken wordt automatisch uitgesloten van toekomstige leveringen.
Tijdens de leveringsanalyse, worden alle apparaten die van het doel worden uitgesloten automatisch toegevoegd aan excludeLogAppSubRcp tabel.
- Verbindingsprobleem aan het begin van de levering: type fout Undefined, reden van fout Unreachable, wordt opnieuw geprobeerd.
- Verbinding verloren tijdens levering: zachte fout, reden van mislukking Refused, wordt opnieuw geprobeerd.
- Synchrone fout die door Baidu tijdens het verzenden is geretourneerd: harde fout, oorzaak van fout Refused, wordt het opnieuw proberen niet uitgevoerd.
Voor Android V2
Het Android V2-quarantainemechanisme gebruikt hetzelfde proces als Android V1. Hetzelfde geldt voor de update voor abonnementen en uitsluitingen. Zie voor meer informatie de Android V1 sectie.
SMS-quarantines sms-quarantines
Voor standaardconnectors
De specifieke kenmerken van SMS-kanalen worden hieronder vermeld.
Voor de uitgebreide algemene SMPP-connector
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 gegevens in het dialoogvenster Delivery log qualification tabel (beschikbaar via de Administration > Campaign Management > Non deliverables Management ).
Voordat een nieuw type fout wordt gekwalificeerd, is de reden van de fout altijd ingesteld op Geweigerd standaard.
Voorbeeld van een gegenereerd bericht:
SR Generic DELIVRD 000|#MESSAGE#
-
Alle foutberichten beginnen met SR om SMS-foutcodes te onderscheiden van e-mailfoutcodes.
-
Het tweede deel (Algemeen in dit voorbeeld) van het foutbericht verwijst naar de naam van de SMSC-implementatie, zoals gedefinieerd in de SMSC implementation name veld van de externe SMS-rekening.
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 (LEVERING in dit voorbeeld) van het foutbericht komt overeen met de statuscode die uit de SR is opgehaald met behulp van het statusextractieoverzicht dat in de externe SMS-account is gedefinieerd.
Deze regex wordt gespecificeerd in SMSC specificities tabblad van de externe account.
Standaard extraheert de regex de Status: veld zoals gedefinieerd door de Aanhangsel B van de SMPP 3.4-specificatie. -
Het vierde deel (000 in dit voorbeeld) van het foutbericht komt overeen met de foutcode die uit de SR is geëxtraheerd met behulp van het extraheren van de foutcode die in de externe SMS-account is gedefinieerd.
Deze regex wordt gespecificeerd in SMSC specificities tabblad van de externe account.
Standaard extraheert de regex de fout: veld zoals gedefinieerd door de Aanhangsel B van de SMPP 3.4-specificatie.
-
Alles wat na het buissymbool (|) komt wordt slechts getoond in First text kolom van de Delivery log qualification tabel. 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 begint DELIV, wordt het als een succes beschouwd omdat het overeenkomt met de gemeenschappelijke status LEVERING of AFGELEVERD door de meeste aanbieders worden gebruikt. Elke andere status leidt tot een harde fout.