Campaign Standard: mancata corrispondenza dei registri di invio nel profilo
In rari casi, Campaign Standard può visualizzare le voci del registro di invio in un profilo che non appartengono effettivamente a tale profilo. Questo può creare l’impressione che le consegne o gli eventi e-mail siano stati associati in modo errato a un destinatario, anche se i record del database sottostanti non sono danneggiati. Il problema è in genere limitato al comportamento di interfaccia utente/query quando un profilo destinatario e un profilo di test condividono lo stesso valore di identificatore interno nelle rispettive tabelle di origine.
Descrizione description
Un cliente ha segnalato che la visualizzazione dei registri di invio per un profilo destinatario reale mostrava eventi e-mail che appartenevano a un profilo di test separato. Alcuni degli eventi visualizzati sono precedenti alla creazione del profilo reale, il che ha reso chiaro che i record non potevano appartenere legittimamente a quel destinatario.
Dall’inchiesta è emerso che:
- Il profilo reale e il profilo di test erano entità separate e non erano collegati funzionalmente.
- Il destinatario reale non era effettivamente oggetto di targeting nelle consegne interessate, in cui venivano visualizzate le voci di registro impreviste.
- I dati di tracciamento sono rimasti coerenti per il destinatario reale.
- Il comportamento imprevisto è stato osservato principalmente nella visualizzazione dei registri di invio e nel comportamento di anteprima delle query, non come prova di un’ampia contaminazione del database.
- Questo ha creato confusione per il cliente perché l’interfaccia utente suggeriva una cronologia di consegna inesatta e ha sollevato il timore che potessero essere influenzate le attività di reporting e analisi del pubblico.
Risoluzione resolution
Causa principale
Il problema è stato causato da un raro conflitto interno tra ID:
- un profilo destinatario memorizzato nel set di dati profili/destinatari e
- un profilo di test memorizzato nel set di dati del membro seed.
Entrambi i tipi di profilo scrivono i dati di registro nella tabella broadLogRcp, che memorizza il profilo correlato o l’identificatore del profilo di test nella stessa colonna profileId. Quando il destinatario e il profilo di test avevano lo stesso valore ID interno, le query per l’invio dei registri restituivano voci per entrambe le entità.
Perché è successo:
- I nuovi profili dei destinatari ottengono gli ID dalla sequenza nmsRecipientId.
- I profili di test ottengono gli ID dalla sequenza xtkNewId.
- In questo caso, il destinatario è stato creato in un momento in cui il suo ID generato corrispondeva a un ID profilo di test già esistente.
- Di conseguenza, l’interfaccia utente e i percorsi di query correlati hanno recuperato tutte le righe del registro di invio che corrispondono a tale ID interno. Poiché l’indirizzo e-mail visualizzato nell’interfaccia utente viene ricavato dal campo indirizzo del registro di invio, gli utenti potevano visualizzare l’e-mail del profilo di test nella cronologia del registro di invio del destinatario anche se i dati del destinatario sottostante non erano misti o danneggiati.
Engineering ha valutato questo come un caso limite a bassa probabilità piuttosto che un problema che probabilmente si ripresenterà in maniera generale.
Risoluzione
Opzioni di risoluzione consigliate:
- Elimina e ricrea il profilo di test interessato. Questa è considerata l’azione correttiva più pulita perché il profilo di test ricreato riceve un nuovo ID interno. Le consegne future a tale profilo di test non verranno più visualizzate nei registri di invio del destinatario reale.
- Se necessario, pulisci manualmente le righe storiche del registro di invio. Se la visibilità storica del registro rappresenta un problema, è possibile rimuovere manualmente le righe precedenti associate all’indirizzo obsoleto del profilo di test. Questa opzione è necessaria solo se si desidera eliminare la cronologia non corrispondente già scritta prima che venga rimossa da Normal Retention.