Parte 1 di 3 sul debug dei report sull'attribuzione. Scopri perché il debug è importante e quando utilizzare i report di debug durante i test.
Perché sono necessari i report di debug
Se stai testando l'API Attribution Reporting, dovresti verificare che l'integrazione funzioni correttamente, comprendere le lacune nei risultati di misurazione tra l'implementazione basata sui cookie e l'implementazione di Attribution Reporting e risolvere eventuali problemi relativi all'integrazione.
Per completare queste attività sono necessari report di debug. Pertanto, ti consigliamo vivamente di configurarle.
Glossario
Aspetti principali dei report di debug
Due tipi di report di debug
Sono disponibili due tipi di report di debug. Usali entrambi, in quanto sono adatti a diversi casi d'uso.
Report di debug riuscito
I report di debug riusciti monitorano la generazione riuscita di un report sull'attribuzione. Sono direttamente correlate a un report sull'attribuzione.
I report di debug riusciti sono disponibili a partire dalla versione 101 di Chrome (aprile 2022).
Report di debug dettagliati
I report di debug dettagliati offrono maggiore visibilità sugli eventi di origine e di attivazione, in modo da garantire che le origini siano state registrate correttamente oppure monitorare i report mancanti e determinarne il motivo (errore negli eventi di origine o di attivazione, errore durante l'invio o la generazione del report). I report di debug dettagliati indicano che:
- Casi in cui il browser ha registrato correttamente un'origine.
- Casi in cui il browser non ha registrato correttamente un'origine o un evento di trigger, il che significa che non verrà generato un report sull'attribuzione.
- Casi in cui per qualche motivo un report sull'attribuzione non può essere generato o inviato.
I report di debug dettagliati includono un campo type che descrive una registrazione dell'origine riuscita o il motivo per cui non è stato generato un report sull'origine, sull'attivatore o sull'attribuzione.
I report di debug dettagliati sono disponibili a partire da Chrome 109 (gennaio 2023), ad eccezione dei report di debug dettagliati sulla riuscita della registrazione del codice sorgente che sono stati aggiunti in un secondo momento in Chrome 112.
Esamina i report di esempio nella sezione Parte 2. Configurare i report di debug.
I report di debug sono basati sui cookie
Per utilizzare i report di debug, l'origine report deve impostare un cookie.
Se l'origine configurata per ricevere report è una terza parte, questo cookie sarà un cookie di terze parti. Ciò ha alcune implicazioni chiave:
- I report di debug vengono generati solo se i cookie di terze parti sono consentiti nel browser dell'utente.
- I report di debug non saranno più disponibili dopo l'eliminazione graduale dei cookie di terze parti.
I report di debug vengono inviati immediatamente
I report di debug vengono inviati immediatamente dal browser all'origine del report. Questo è diverso dai report sull'attribuzione, che vengono inviati con ritardo.
I report di debug riuscito vengono generati e inviati non appena viene generato il report sull'attribuzione corrispondente, ovvero al momento della registrazione dell'attivatore.
I report di debug dettagliati vengono inviati immediatamente al momento della registrazione dell'origine o dell'attivatore.
I report di debug hanno percorsi degli endpoint diversi
Come per i report sull'attribuzione, tutti i report di debug vengono inviati all'origine dei report. I report di debug vengono inviati a tre endpoint separati dell'origine della segnalazione:
- Endpoint per report di debug riusciti, a livello di evento
- Endpoint per report di debug successivi, aggregabili
- Endpoint per report di debug dettagliati, aggregabili a livello di evento.
Per saperne di più, consulta la Parte 2. Configurare i report di debug.
Casi d'uso
Controllo dell'integrazione in tempo reale di base
I report di debug vengono inviati immediatamente al tuo endpoint, a differenza dei report sull'attribuzione che vengono ritardati per proteggere la privacy degli utenti. Utilizza i report di debug per segnalare in tempo reale che l'integrazione con l'API Attribution Reporting funziona.
Per scoprire come farlo, consulta la Parte 3: debug del libro di ricette.
Analisi della perdita
A differenza dei cookie di terze parti, l'API Attribution Reporting include protezioni della privacy integrate, progettate per trovare un equilibrio tra utilità e privacy. Ciò significa che con l'API Attribution Reporting, potresti non essere in grado di raccogliere tutti i dati di misurazione attualmente raccolti con i cookie. Non tutte le conversioni che puoi monitorare con cookie di terze parti generano un report sull'attribuzione.
Un esempio: per i report a livello di evento, puoi registrare al massimo una conversione per impressione. Ciò significa che, per una determinata impressione dell'annuncio, riceverai un solo report sull'attribuzione, indipendentemente da quante volte l'utente effettua una conversione.
Utilizza i report di debug per ottenere visibilità sulle differenze tra i risultati delle misurazioni basate sui cookie e i risultati ottenuti con l'API Attribution Reporting. Individua quali conversioni vengono registrate, quante non vengono registrate e in particolare quali e perché.
Scopri come eseguire un'analisi della perdita nella Parte 3: debug del libro di ricette.
Risoluzione dei problemi
Anche se è prevista una perdita causata dalle protezioni della privacy o delle risorse, un'altra perdita potrebbe essere involontaria. Errori di configurazione o bug nel browser stesso possono causare la perdita dei report.
Puoi utilizzare i report di debug per rilevare e risolvere un problema di implementazione da parte tua o per segnalare un potenziale bug ai team dei browser. Per scoprire come farlo, consulta la Parte 3: debug del libro di ricette.
Controllo della configurazione avanzata
Alcune funzionalità dell'API Attribution Reporting consentono di personalizzare i comportamenti dell'API. Le regole di filtro, le regole di deduplicazione e le regole di priorità sono alcuni esempi.
Quando usi queste funzionalità, utilizza i report di debug per verificare che la logica generi il comportamento previsto in produzione, senza attendere i report sull'attribuzione. Per scoprire come farlo, consulta la Parte 3: debug del libro di ricette.
Test locali con report aggregabili
A differenza dei report sull'attribuzione aggregabili che sono criptati, i report di debug aggregabili includono il payload non criptato.
Usare report di debug aggregabili per convalidare i contenuti aggregabili e generare report di riepilogo con lo strumento di aggregazione locale a scopo di test.
Rielaborazione dei report dei servizi di aggregazione
Un altro vantaggio dell'utilizzo della modalità di debug è che consente di elaborare nuovamente i report. Pertanto, per elaborare i report più di una volta, assicurati di avere abilitato i report di debug. Ti consigliamo di rielaborare i report nei seguenti casi:
- di eseguire il debug del servizio di aggregazione.
- sperimentare diverse strategie di batch.
- sperimentare con diversi valori epsilon.
Recupero dati
Consigliamo ai tecnici pubblicitari di attivare la modalità di debug per ricevere report di debug in modo da poter recuperare i dati dei report. Questa opzione è utile in caso di problemi del servizio di aggregazione, ad esempio servizi non disponibili o non reattivi che potrebbero causare la mancata generazione dei report di riepilogo.