Adobe Campaign gestisce un elenco di indirizzi in quarantena. I destinatari il cui indirizzo è stato messo in quarantena sono esclusi per impostazione predefinita durante l’analisi della consegna e non saranno oggetto di targeting. Un indirizzo e-mail può essere posto in quarantena, ad esempio, quando la casella di posta è piena o se l’indirizzo non esiste. In ogni caso, la procedura di quarantena è conforme alle norme specifiche descritte di seguito.
Questa sezione si applica ai canali online: e-mail, SMS, notifiche push.
I profili con indirizzi e-mail o numeri di telefono in quarantena vengono automaticamente esclusi durante la preparazione dei messaggi (vedi Identificare gli indirizzi messi in quarantena per una consegna). In questo modo le consegne sono più rapide, poiché il tasso di errore ha un effetto significativo sulla velocità di consegna.
Alcuni provider di accesso a Internet considerano automaticamente le e-mail come spam se il tasso di indirizzi non validi è troppo alto. La quarantena consente quindi di evitare di essere aggiunti al elenco Bloccati da parte di questi provider.
Inoltre, le quarantene contribuiscono a ridurre i costi di invio degli SMS escludendo numeri di telefono errati dalle consegne.
Per ulteriori informazioni sulle best practice per proteggere e ottimizzare le consegne, consulta questa pagina.
Elenco Bloccati La quarantena e il non si applicano allo stesso oggetto:
Quarantena si applica solo a un indirizzo (o numero di telefono, ecc.), non al profilo stesso. Ad esempio, un profilo con un indirizzo e-mail messo in quarantena può aggiornare il profilo e immettere un nuovo indirizzo, per poi essere nuovamente indirizzato mediante azioni di consegna. Allo stesso modo, se due profili hanno lo stesso numero di telefono, saranno entrambi interessati se il numero viene messo in quarantena.
Gli indirizzi o i numeri di telefono in quarantena vengono visualizzati nel registri di esclusione (per una consegna) o nella elenco di quarantena (per l’intera piattaforma).
Essere sul inserisco nell'elenco Bloccati, dall'altro, darà luogo al profilo non sono più oggetto della consegna, ad esempio dopo l’annullamento dell’abbonamento (rinuncia) per un determinato canale. Ad esempio, se un profilo nella inserisce nell'elenco Bloccati di invio del canale e-mail presenta due indirizzi e-mail, entrambi gli indirizzi verranno esclusi dalla consegna.
Puoi verificare se un profilo si trova nel inserisco nell'elenco Bloccati di per uno o più canali nel No longer contact sezione del profilo General scheda. Vedi questa sezione.
La quarantena include Denylisted stato, che si applica quando i destinatari segnalano il messaggio come spam o rispondono a un messaggio SMS con una parola chiave come "STOP". In tal caso, l’indirizzo o il numero di telefono del profilo interessato viene messo in quarantena con il Denylisted stato. Per ulteriori informazioni sulla gestione dei messaggi STOP SMS, consulta questa sezione.
È possibile elencare gli indirizzi messi in quarantena per una consegna specifica o per l’intera piattaforma.
Gli indirizzi in quarantena per una consegna specifica vengono elencati durante la fase di preparazione della consegna, nei registri di consegna del dashboard di consegna (vedi Registri e cronologia delle consegne).
Gli amministratori possono elencare gli indirizzi messi in quarantena per l’intera piattaforma dall’ Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses nodo.
Questo menu elenca gli elementi messi in quarantena per i canali e-mail, SMS e di notifiche push.
Per ogni indirizzo sono disponibili le seguenti informazioni:
L’aumento del numero di quarantene è un effetto normale, legato all’"usura" del database. Ad esempio, se la durata di un indirizzo e-mail è considerata di tre anni e la tabella dei destinatari aumenta del 50% ogni anno, l’aumento delle quarantene può essere calcolato come segue:
Fine anno 1: (1*0,33)/(1+0,5)=22%.
Fine anno 2: ((1,22*0,33)+0,33)/(1,5+0,75)=32,5%.
I seguenti rapporti forniscono informazioni sugli indirizzi in quarantena:
Per ogni consegna, il Delivery summary rapporto mostra il numero di indirizzi in quarantena nel target di consegna. Vengono visualizzati i seguenti elementi:
Il numero di indirizzi messi in quarantena durante l’analisi della consegna,
Il numero di indirizzi messi in quarantena dopo l’azione di consegna.
Il Non-deliverables and bounces Il report visualizza informazioni sugli indirizzi messi in quarantena, sui tipi di errore riscontrati e così via, nonché un raggruppamento degli errori per dominio.
Puoi cercare queste informazioni per tutte le consegne della piattaforma (Home page > Reports) o per una consegna specifica. Puoi anche creare rapporti personalizzati e selezionare le informazioni da visualizzare.
Puoi cercare lo stato dell’indirizzo e-mail di qualsiasi destinatario. A questo scopo, seleziona il profilo del destinatario e fai clic sul pulsante Deliveries scheda. Per tutte le consegne a quel destinatario, puoi scoprire se l’indirizzo non è riuscito, è stato messo in quarantena durante l’analisi, ecc. Per ogni cartella, puoi visualizzare solo i destinatari il cui indirizzo e-mail è in quarantena. A tale scopo, utilizza Quarantined email address filtro applicazione.
Adobe Campaign gestisce la quarantena in base al tipo di consegna non riuscita e al motivo assegnato durante la qualifica dei messaggi di errore (vedi Qualificazione di mail non recapitate e Tipi e motivi di errori di consegna).
Se un utente qualifica un’e-mail come spam (ciclo di feedback), il messaggio viene automaticamente reindirizzato a una casella di posta tecnica gestita da Adobe. L’indirizzo e-mail dell’utente viene quindi messo automaticamente in quarantena con lo stato Denylisted. Questo stato si riferisce solo all’indirizzo, il profilo non è nel inserisco nell'elenco Bloccati di, in modo che l’utente continui a ricevere messaggi SMS e notifiche push.
In Adobe Campaign la quarantena distingue tra maiuscole e minuscole. Accertati di importare gli indirizzi e-mail in lettere minuscole, in modo che non vengano reindirizzate in un secondo momento.
Nell’elenco degli indirizzi messi in quarantena (vedi Identificazione degli indirizzi messi in quarantena per l’intera piattaforma), il Error reason indica il motivo per cui l’indirizzo selezionato è stato messo in quarantena.
Al contrario degli errori rigidi, gli errori morbidi non mettono immediatamente un indirizzo in quarantena, ma incrementano un contatore di errori.
I tentativi verranno eseguiti durante il durata della consegna. Quando il contatore di errori raggiunge la soglia limite, l’indirizzo viene messo in quarantena. Per ulteriori informazioni, consulta Tentativi dopo un errore temporaneo di consegna.
Il contatore degli errori viene reinizializzato se l'ultimo errore significativo si è verificato più di 10 giorni fa. Lo stato dell’indirizzo diventa quindi Valido e viene cancellato dall’elenco delle quarantene dal Database cleanup flusso di lavoro.
Per le installazioni in hosting o ibride, se hai effettuato l’aggiornamento al MTA avanzato, il numero massimo di tentativi da eseguire in caso di Erroneous Lo stato e il ritardo minimo tra i nuovi tentativi si basano ora sulle prestazioni di un IP sia storicamente che attualmente in un determinato dominio.
Per le installazioni on-premise e le installazioni in hosting/ibride che utilizzano l’MTA di Campaign legacy, puoi modificare il numero di errori e il periodo tra due errori. A questo scopo, modifica le impostazioni corrispondenti nella sezione procedura guidata di distribuzione (Email channel > Advanced parameters) o a livello di consegna.
Gli indirizzi che soddisfano condizioni specifiche vengono automaticamente eliminati dall’elenco di quarantena da Database cleanup flusso di lavoro.
Gli indirizzi vengono rimossi automaticamente dall’elenco di quarantena nei seguenti casi:
Il loro stato diventa quindi Valid.
Destinatari con un indirizzo in una Quarantine o Denylisted non vengono mai rimossi, anche se ricevono un’e-mail.
È inoltre possibile rimuovere manualmente la quarantena di un indirizzo. Per rimuovere manualmente un indirizzo dall’elenco di quarantena, modificane lo stato in Valid dal Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses nodo.
Potrebbe essere necessario eseguire aggiornamenti in blocco sull’elenco di quarantena, ad esempio in caso di interruzione del servizio dell’ISP. In questo caso, le e-mail vengono erroneamente contrassegnate come mancate consegne perché non possono essere consegnate correttamente al destinatario. Questi indirizzi devono essere rimossi dall’elenco di quarantena.
Per eseguire questa operazione, crea un flusso di lavoro e aggiungi un Query attività nella tabella di quarantena per filtrare tutti i destinatari interessati. Una volta identificate, possono essere rimosse dall’elenco di quarantena e incluse nelle consegne e-mail future di Campaign.
Di seguito sono riportate le linee guida consigliate per questa query:
Per gli ambienti Campaign Classic v7 con informazioni sulle regole e-mail in entrata nel Error text campo dell’elenco di quarantena:
Per le istanze di Campaign Classic v7 con informazioni di risposta SMTP non recapitate in Error text campo dell’elenco di quarantena:
dove "support.ISP.com" può essere: "support.apple.com" o "support.google.com", ad esempio
Dopo aver visualizzato l’elenco dei destinatari interessati, aggiungi un Update data per impostare lo stato del loro indirizzo e-mail su Valid in modo che vengano rimossi dall’elenco di quarantena dal Database cleanup flusso di lavoro. Puoi anche semplicemente eliminarli dalla tabella di quarantena.
Il meccanismo di quarantena per le notifiche push è globalmente lo stesso del processo generale. Tuttavia, alcuni errori vengono gestiti in modo diverso per le notifiche push. Ad esempio, per alcuni errori soft, non vengono eseguiti nuovi tentativi all’interno della stessa consegna. Le specificità per le notifiche push sono elencate di seguito. Il meccanismo di esecuzione dei nuovi tentativi (numero di tentativi, frequenza) è lo stesso utilizzato per le e-mail.
Gli elementi messi in quarantena sono token del dispositivo.
Il protocollo HTTP/V2 consente un feedback diretto e uno stato per ogni consegna push. Se si utilizza il connettore del protocollo HTTP/V2, il servizio di feedback non viene più chiamato dal mobileAppOptOutMgt flusso di lavoro. Un token viene considerato non registrato quando un’app mobile viene disinstallata o reinstallata.
In modo sincrono, se il servizio APN restituisce lo stato "unregistered" per un messaggio, il token di destinazione verrà messo immediatamente in quarantena.
Scenario |
Stato |
Messaggio di errore |
Tipo di errore |
Motivo dell’errore |
Riprova |
Dispositivo di destinazione acceso |
OK |
||||
Dispositivo di destinazione spento |
OK |
||||
L'utente disabilita le notifiche per l'applicazione |
OK |
||||
Fase di creazione/analisi dei messaggi - Payload troppo grande |
Errore |
Payload troppo lungo |
Morbido |
Rifiutato |
No |
Fase di creazione/analisi dei messaggi - problema di formato del contenuto imprevisto |
Errore |
Vari messaggi di errore in base all’errore |
Morbido |
Non definito |
No |
Problema del certificato (password, danneggiamento, ecc.) e verifica la connessione al problema APN |
Errore |
Vari messaggi di errore in base all’errore |
Morbido |
Rifiutato |
No |
Connessione di rete persa durante l'invio |
Errore |
Errore di connessione |
Non definito |
Non raggiungibile |
Sì |
Messaggio APNs rifiutato: annullamento registrazione l’utente ha rimosso l’applicazione o il token è scaduto |
Errore |
Non registrato |
Rigido |
Utente sconosciuto |
No |
Rifiuto messaggio APNs: tutti gli altri errori |
Errore |
La causa del rifiuto dell’errore sarà presente nel messaggio di errore |
Morbido |
Rifiutato |
No |
Per Android V1
Per ogni notifica, Adobe Campaign riceve gli errori sincroni direttamente dal server FCM. Adobe campaign li gestisce al volo e genera errori rigidi o morbidi in base alla gravità dell’errore. È possibile eseguire nuovi tentativi:
Il mobileAppOptOutMgt viene eseguito ogni 6 ore per aggiornare AppSubscriptionRcp tabella. Per i token dichiarati non registrati o non più validi, il campo Disabilitato è impostato su Vero e l’abbonamento collegato a tale token dispositivo verrà automaticamente escluso dalle consegne future.
Durante l’analisi della consegna, tutti i dispositivi esclusi dalla destinazione vengono aggiunti automaticamente alla excludeLogAppSubRcp tabella.
Per i clienti che utilizzano il connettore Baidu, di seguito sono riportati i diversi tipi di errori:
Adobe Campaign contatta il server Baidu ogni 10 minuti per recuperare lo stato del messaggio inviato e aggiorna i broadLog. Se un messaggio viene dichiarato come inviato, lo stato del messaggio nei broadLog viene impostato su Received. Se Baidu dichiara un errore, lo stato viene impostato su Failed.
Per Android V2
Il meccanismo di quarantena di Android V2 utilizza lo stesso processo di Android V1, lo stesso si applica all’aggiornamento delle sottoscrizioni e delle esclusioni. Per ulteriori informazioni, consulta Android V1 sezione.
Scenario |
Stato |
Messaggio di errore |
Tipo di errore |
Motivo dell’errore |
Riprova |
Fase di creazione/analisi del messaggio: utilizzo di parole chiave non valide nei campi personalizzati |
Errore |
Impossibile utilizzare le seguenti parole chiave: {1} |
Morbido |
No |
|
Fase di creazione/analisi del messaggio: payload troppo grande |
Errore |
Notifica troppo pesante: {1} bit, mentre solo {2} sono autorizzati |
Morbido |
Rifiutato |
No |
Connessione di rete persa durante l'invio |
Errore |
Nessuna risposta dal servizio Firebase Cloud Messaging sull'indirizzo: {1} |
Morbido |
Non raggiungibile |
Sì |
Rifiuto del messaggio FCM: il server FCM è temporaneamente non disponibile (ad esempio con timeout). |
Errore |
Il servizio Firebase Cloud Messaging non è al momento disponibile |
Morbido |
Non raggiungibile |
Sì |
Messaggio FCM rifiutato: errore durante l'autenticazione dell'account mittente |
Errore |
Impossibile identificare l'account sviluppatore, verifica ID e password |
Morbido |
Rifiutato |
No |
Messaggio FCM rifiutato: quota dispositivo superata |
Errore |
Morbido |
Rifiutato |
Sì |
|
Messaggio FCM rifiutato: registrazione non valida / non registrata |
Errore |
Rigido |
Utente sconosciuto |
No |
|
Messaggio FCM rifiutato: tutti gli altri errori |
Errore |
Il server Firebase Cloud Messaging ha restituito un codice di errore imprevisto: {1} | Rifiutato |
No |
|
Messaggio FCM rifiutato: argomento non valido |
Errore |
ARGOMENTO_NON VALIDO | Ignorato | Non definito |
No |
Messaggio FCM rifiutato: errore di autenticazione di terze parti |
Errore |
ERRORE_AUTH_TERZE PARTI | Ignorato | Rifiutato |
Sì |
Messaggio FCM rifiutato: mancata corrispondenza ID mittente |
Errore |
SENDER_ID_MISMATCH | Morbido | Utente sconosciuto |
No |
Messaggio FCM rifiutato: non registrato |
Errore |
NON REGISTRATO | Rigido | Utente sconosciuto |
No |
Messaggio FCM rifiutato: interno |
Errore |
INTERNO | Ignorato | Rifiutato |
Sì |
Messaggio FCM rifiutato: non disponibile |
Errore |
NON DISPONIBILE | Ignorato | Rifiutato |
Sì |
Messaggio FCM rifiutato: codice di errore imprevisto |
Errore |
codice di errore imprevisto | Ignorato | Rifiutato |
No |
Autenticazione: problema di connessione |
Errore |
Impossibile connettersi al server di autenticazione | Ignorato | Rifiutato |
Sì |
Autenticazione: client o ambito non autorizzato nella richiesta. |
Errore |
unauthorized_client | Ignorato | Rifiutato |
No |
Autenticazione: il client non è autorizzato a recuperare i token di accesso utilizzando questo metodo oppure non è autorizzato per nessuno degli ambiti richiesti. |
Errore |
unauthorized_client | Ignorato | Rifiutato |
No |
Autenticazione: accesso negato |
Errore |
accesso negato | Ignorato | Rifiutato |
No |
Autenticazione: e-mail non valida |
Errore |
invalid_grant | Ignorato | Rifiutato |
No |
Autenticazione: JWT non valido |
Errore |
invalid_grant | Ignorato | Rifiutato |
No |
Autenticazione: firma JWT non valida |
Errore |
invalid_grant | Ignorato | Rifiutato |
No |
Autenticazione: il pubblico specificato per l’ambito OAuth o il token ID non è valido |
Errore |
unauthorized_client | Ignorato | Rifiutato |
No |
Autenticazione: client OAuth disabilitato |
Errore |
disabled_client | Ignorato | Rifiutato |
No |
Per connettori standard
Il meccanismo di quarantena per i messaggi SMS è globalmente lo stesso del processo generale. Consulta Informazioni sulla quarantena. Le specificità per gli SMS sono elencate di seguito.
Il Delivery log qualification la tabella non si applica SMPP generico esteso connettore.
Scenario |
Stato |
Messaggio di errore |
Tipo di errore |
Motivo dell’errore |
Inviato al provider |
Inviato |
|||
Ricevuto sul dispositivo mobile |
Ricevuto |
|||
Errore restituito dal provider |
Errore |
Errore durante la ricezione dei dati (SR o MO) |
Morbido |
Non raggiungibile |
Conferma MT non valida |
Errore |
Errore '{1}' durante l'elaborazione del frame di conferma per la query di invio |
Morbido |
Non raggiungibile |
Errore durante l’invio del messaggio MT |
Errore |
Errore durante l’invio dei messaggi |
Morbido |
Non raggiungibile |
Per il connettore SMPP generico esteso
Quando si utilizza il protocollo SMPP per inviare messaggi SMS, la gestione degli errori viene gestita in modo diverso. Per ulteriori informazioni sul connettore SMPP generico esteso, consulta questa pagina.
Il connettore SMPP recupera i dati dal messaggio SR (Status Report) restituito utilizzando espressioni regolari (regex) per filtrarne il contenuto. Questi dati vengono quindi confrontati con le informazioni presenti nella Delivery log qualification (disponibile tramite il Administration > Campaign Management > Non deliverables Management menu).
Prima di qualificare un nuovo tipo di errore, il motivo dell’errore è sempre impostato su Rifiutato per impostazione predefinita.
I tipi di errore e i motivi dell’errore sono gli stessi delle e-mail. Consulta Tipi e motivi di errori di consegna.
Chiedi al provider un elenco di stati e codici di errore per impostare i tipi di errore e i motivi dell’errore nella tabella Qualificazione del registro di consegna.
Esempio di messaggio generato:
SR Generic DELIVRD 000|#MESSAGE#
Tutti i messaggi di errore iniziano con SR per distinguere i codici di errore SMS dai codici di errore e-mail.
La seconda parte (Generico in questo esempio) del messaggio di errore si riferisce al nome dell’implementazione SMSC, come definito nella SMSC implementation name campo dell’account esterno SMS. Consulta questa pagina.
Poiché lo stesso codice di errore può avere un significato diverso per ogni provider, questo campo consente di sapere quale provider ha generato il codice di errore. L’errore è quindi disponibile nella documentazione del provider pertinente.
La terza parte (CONSEGNA in questo esempio) del messaggio di errore corrisponde al codice di stato recuperato dall’SR utilizzando il regex di estrazione dello stato definito nell’account esterno SMS.
Questo regex è specificato nel SMSC specificities dell’account esterno. Consulta questa pagina.
Per impostazione predefinita, il codice regex estrae stat: campo definito dalla Appendice B sezione del Specifiche SMPP 3.4.
La quarta parte (000 in questo esempio) del messaggio di errore corrisponde al codice di errore estratto dall’SR utilizzando l’estrazione del codice di errore regex definita nell’account esterno SMS.
Questo regex è specificato nel SMSC specificities dell’account esterno. Consulta questa pagina.
Per impostazione predefinita, il codice regex estrae errore: campo definito dalla Appendice B sezione del Specifiche SMPP 3.4.
Tutto ciò che segue il simbolo di barra verticale (|) viene visualizzato solo nel First text colonna del Delivery log qualification tabella. Questo contenuto viene sempre sostituito da #MESSAGE# dopo la normalizzazione del messaggio. Questo processo evita di inserire più voci per errori simili ed è lo stesso delle e-mail. Per ulteriori informazioni, consulta Qualificazione di mail non recapitate.
Il connettore SMPP generico esteso applica un’euristica per trovare valori predefiniti sensibili: se lo stato inizia con DELIV, viene considerato un successo perché corrisponde agli stati comuni CONSEGNA o CONSEGNATO utilizzato dalla maggior parte dei provider. Qualsiasi altro stato comporta un errore grave.