[v7]{class="badge informative" title="Gäller Campaign Classic v7"} [v8]{class="badge positive" title="Gäller även Campaign v8"}
Förstå karantänhantering understanding-quarantine-management
Adobe Campaign hanterar en lista med adresser i karantän. Mottagare vars adress sätts i karantän exkluderas som standard vid leveransanalys och anges inte som mål. En e-postadress kan sättas i karantän, till exempel när postlådan är full eller om adressen inte finns. Under alla omständigheter uppfyller karantänförfarandet de särskilda regler som beskrivs nedan.
Optimera leveransen genom karantänhantering optimizing-your-delivery-through-quarantines
Profilerna vars e-postadresser eller telefonnummer är i karantän exkluderas automatiskt vid meddelandeförberedelsen (se Identifiera adresser i karantän för en leverans). Detta snabbar upp leveranserna eftersom felfrekvensen avsevärt påverkar leveranshastigheten.
Vissa internetleverantörer betraktar automatisk e-post som skräppost om antalet ogiltiga adresser är för högt. Med karantän kan du därför undvika att läggas till i blockeringslista av dessa leverantörer.
Dessutom bidrar karantäner till att minska SMS-kostnaderna genom att utesluta felaktiga telefonnummer från leveranser.
Mer information om de bästa sätten för att skydda och optimera leveranser finns på den här sidan.
Karantän mot blockeringslista quarantine-vs-denylist
Karantän och blockeringslista gäller inte för samma objekt:
-
Karantän gäller endast för adress (eller telefonnummer osv.), inte själva profilen. En profil vars e-postadress är placerad i karantän kan till exempel uppdatera sin profil och ange en ny adress. Därefter kan den användas av leveransåtgärder igen. Om två profiler råkar ha samma telefonnummer, påverkas båda om numret sätts i karantän.
Adresserna eller telefonnumren i karantän visas i exkluderingsloggar (för leverans) eller i karantänlista (för hela plattformen).
-
Att vara på blockeringslista å andra sidan resulterar det i profil som inte längre används av leveransen, t.ex. efter en avanmälan (avanmälan), för en viss kanal. Om en profil på blockeringslista för e-postkanalen till exempel har två e-postadresser, kommer båda adresserna inte att levereras.
Du kan kontrollera om det finns en profil på blockeringslista för en eller flera kanaler i dialogrutan No longer contact del av profilens General -fliken. Se det här avsnittet.
Identifiera adresser i karantän identifying-quarantined-addresses
Adresser i karantän kan användas för en viss leverans eller för hela plattformen.
Identifiera adresser i karantän för en leverans identifying-quarantined-addresses-for-a-delivery
Adresser i karantän för en viss leverans listas i leveransloggarna på kontrollpanelen under leveransförberedelsefasen (se Leveransloggar och historik).
Identifiera adresser i karantän för hela plattformen identifying-quarantined-addresses-for-the-entire-platform
Administratörer kan lista adresserna i karantän för hela plattformen från Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses nod.
Följande information finns för varje adress:
Identifiera adresser i karantän i leveransrapporter identifying-quarantined-addresses-in-delivery-reports
Följande rapporter innehåller information om adresserna i karantän:
-
För varje leverans visas Delivery summary rapporten visar antalet adresser i karantän i leveransmålet. Den visar:
-
Antalet adresser som placerats i karantän under leveransanalysen.
-
Antalet adresser som placerats i karantän efter leveransåtgärden.
-
-
The Non-deliverables and bounces rapporten innehåller information om adresserna i karantän, typer av fel som uppstått osv. samt felinformation per domän.
Du kan söka efter den här informationen för alla leveranser av plattformen (Home page > Reports) eller för en viss leverans. Du kan också skapa anpassade rapporter och välja vilken information som ska visas.
Identifiera adresser i karantän för en mottagare identifying-quarantined-addresses-for-a-recipient
Du kan slå upp status för e-postadressen för alla mottagare. Det gör du genom att markera mottagarprofilen och klicka på knappen Deliveries -fliken. För alla leveranser till den mottagaren kan du ta reda på om adressen misslyckades, placerades i karantän under analysen osv. För varje mapp kan du bara visa mottagare vars e-postadress är i karantän. Använd Quarantined email address programfilter.
Villkor för att skicka en adress till karantän conditions-for-sending-an-address-to-quarantine
Adobe Campaign hanterar karantän enligt typ av leveransfel och den orsak som tilldelats vid kvalificering av felmeddelanden (se E-poststudsar och Typ av leveransfel och orsaker).
- Ignorerad avvikelse: ignorerade avvikelser skickar ingen adress till karantänen.
- Kritisk avvikelse: motsvarande e-postadress skickas omedelbart till karantänen.
- Icke-kritisk avvikelse: En icke-kritiskt avvikelse skickar inte en adress till karantän omedelbart men ökar dock felräknaren. Mer information finns i Mjuk felhantering.
Om en användare kvalificerar ett e-postmeddelande som skräppost (feedback-slinga) dirigeras meddelandet automatiskt om till en teknisk brevlåda som hanteras av Adobe. Användarens e-postadress skickas sedan automatiskt till karantänen med status Denylisted. Den här statusen avser endast adressen, profilen finns inte på blockeringslista, så att användaren fortsätter att ta emot SMS-meddelanden och push-meddelanden.
I listan över adresser i karantän (se Identifiera adresser i karantän för hela plattformen), Error reason anger varför den valda adressen placerades i karantän.
Mjuk felhantering soft-error-management
I motsats till hårda fel skickar inte mjuka fel en adress direkt till karantän, utan i stället ökar de en felräknare.
Försök utförs igen under leveransvaraktighet. När felräknaren når gränsvärdet sätts adressen i karantän. Mer information finns i Försök igen efter ett tillfälligt leveransfel.
Felräknaren initieras om om det senaste allvarliga felet inträffade för mer än 10 dagar sedan. Adressstatusen ändras sedan till Giltig och tas bort från listan över karantäner av Databasrensning arbetsflöde.
För värdbaserade eller hybridinstallationer, om du har uppgraderat till Förbättrad MTA, det maximala antalet försök som ska utföras om Erroneous status och minsta fördröjning mellan återförsök baseras nu på hur bra en IP-adress fungerar både historiskt och för närvarande på en viss domän.
För lokala installationer och värdbaserade/hybridinstallationer som använder det äldre Campaign MTA kan ni ändra antalet fel och perioden mellan två fel. Om du vill göra det ändrar du motsvarande inställningar i dialogrutan distributionsguide (Email channel > Advanced parameters) eller på leveransnivå.
Ta bort en adress från karantän removing-a-quarantined-address
Automatiska uppdateringar unquarantine-auto
Adresser som matchar specifika villkor tas automatiskt bort från karantänlistan av Databasrensning arbetsflöde.
Adresserna tas automatiskt bort från karantänlistan i följande fall:
- Adresser i en With errors status kommer att tas bort från karantänlistan efter en slutförd leverans.
- Adresser i en With errors status tas bort från karantänlistan om den senaste mjuka studsen inträffade för mer än 10 dagar sedan. Mer information om mjuk felhantering finns i det här avsnittet.
- Adresser i en With errors status som studsade med Mailbox full felet tas bort från karantänlistan efter 30 dagar.
Status ändras sedan till Valid.
Manuella uppdateringar unquarantine-manual
Du kan också ta bort karantänen för en adress manuellt. Om du vill ta bort en adress från karantänlistan manuellt ändrar du dess status till Valid från Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses nod.
Massuppdateringar unquarantine-bulk
Du kan behöva göra satsvisa uppdateringar i karantänlistan, t.ex. om en Internet-leverantör är i ett driftstopp. I så fall markeras e-postmeddelanden felaktigt som studsar eftersom de inte kan levereras till mottagaren. Dessa adresser måste tas bort från karantänlistan.
Skapa ett arbetsflöde och lägg till en Query aktivitet i karantäntabellen för att filtrera bort alla påverkade mottagare. När de har identifierats kan de tas bort från karantänlistan och inkluderas i framtida e-postleveranser för kampanjer.
Nedan följer de rekommenderade riktlinjerna för den här frågan:
-
För Campaign Classic v7-miljöer med regelinformation för inkommande e-post i Error text karantänlistans fält:
- Feltext (karantäntext) innehåller "Momen_Code10_InvalidRecipient"
- E-postdomän (@domän) lika med domain1.com OR E-postdomän (@domän) lika med domain2.com OR E-postdomän (@domän) lika med domain3.com
- Uppdateringsstatus (@lastModified) på eller efter
MM/DD/YYYY HH:MM:SS AM - Uppdateringsstatus (@lastModified) på eller före
MM/DD/YYYY HH:MM:SS PM
-
För Campaign Classic v7-instanser med SMTP-studssvarsinformation i Error text karantänlistans fält:
- Feltext (karantäntext) innehåller "550-5.1.1" AND Feltext (karantäntext) innehåller "support.ISP.com"
där "support.ISP.com" kan vara: "support.apple.com" eller "support.google.com", till exempel
- Uppdateringsstatus (@lastModified) på eller efter
MM/DD/YYYY HH:MM:SS AM - Uppdateringsstatus (@lastModified) på eller före
MM/DD/YYYY HH:MM:SS PM
När du har en lista över mottagare som påverkas lägger du till en Update data aktivitet för att ange e-postadressstatus till Valid så att de tas bort från karantänlistan av Database cleanup arbetsflöde. Du kan även ta bort dem från karantäntabellen.
Kantlinjer för push-meddelanden push-notification-quarantines
Karantänmekanismen för push-meddelanden är globalt densamma som den allmänna processen. Vissa fel hanteras dock på olika sätt för push-meddelanden. För vissa mjuka fel utförs till exempel inga försök inom samma leverans. Specifikationerna för push-meddelanden anges nedan. Mekanismen för återförsök (antal återförsök, frekvens) är densamma som för e-post.
Objekten som sätts i karantän är enhetstoken.
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.
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-kampanjen 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.
- 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.
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.
SMS-karantän sms-quarantines
För standardanslutningar
Karantänmekanismen för SMS-meddelanden är globalt densamma som den allmänna processen. Se Om karantäner. Specifikationerna för SMS anges nedan.
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. Mer information om den utökade generiska SMPP-anslutningen finns i den här sidan.
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.
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. Läs den här sidan.
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. Läs den här sidan.
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. Läs den här sidan.
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. Mer information finns i E-poststudsar.
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.