Parte 1 di 3 sul debug dei report sull'attribuzione. Scopri perché il debug è importante e quando utilizzare i report di debug nei test.
Perché sono necessari i report di debug
Se stai testando l'API Attribution Reporting, devi verificare che l'integrazione funzioni correttamente, comprendere le lacune nei risultati di misurazione tra l'implementazione basata sui cookie e quella 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 soddisfano diversi casi d'uso.
Report di debug riusciti
I report di debug riusciti monitorano la generazione riuscita di un report sull'attribuzione. Si riferiscono direttamente 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 ti offrono maggiore visibilità sull'origine e sugli eventi di attivazione, in modo da poter verificare che le origini siano state registrate correttamente oppure monitorare i report mancanti e determinare il motivo per cui mancano (errore nell'origine o eventi di attivazione, errori durante l'invio o la generazione del report). I report di debug dettagliati indicano:
- 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 attivazione, vale a dire che non verrà generato un report sull'attribuzione.
- Casi in cui per qualche motivo non è possibile generare o inviare un report sull'attribuzione.
I report di debug dettagliati includono un campo type che descrive una registrazione dell'origine riuscita o il motivo per cui un'origine, un attivatore o un report sull'attribuzione non è stato generato.
I report di debug dettagliati sono disponibili a partire da Chrome 109 (gennaio 2023), ad eccezione dei report di debug dettagliati che sono stati aggiunti in Chrome 112 in un secondo momento.
Esamina i report di esempio nella Parte 2: configurare i report di debug.
I report di debug sono basati sui cookie
Per utilizzare i report di debug, l'origine dei report deve impostare un cookie.
Se l'origine configurata per ricevere report è di terze parti, questo cookie sarà un cookie di terze parti. Questo comporta alcune implicazioni principali:
- 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 dei report. Questo è diverso dai report sull'attribuzione, che vengono inviati con un ritardo.
I report di debug riusciti vengono generati e inviati non appena viene generato il report sull'attribuzione corrispondente, ovvero alla registrazione del trigger.
I report di debug dettagliati vengono inviati immediatamente al momento della registrazione dell'origine o del trigger.
I report di debug hanno percorsi di 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 dei report:
- Endpoint per i report di debug riusciti, a livello di evento
- Endpoint per i report di debug relativi all'esito positivo, aggregabile
- Endpoint per report di debug dettagliati, aggregabili a livello di evento.
Scopri di più nella 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 di quelli sull'attribuzione, che vengono ritardati per proteggere la privacy degli utenti. Utilizza i report di debug come indicatore in tempo reale del funzionamento dell'integrazione con l'API Attribution Reporting.
Scopri come fare nella Parte 3: Istruzioni sul debug.
Analisi delle perdite
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 riuscire a raccogliere tutti i dati di misurazione attualmente raccolti con i cookie. Non tutte le conversioni che puoi monitorare con i cookie di terze parti generano un report sull'attribuzione.
Ad 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 dal numero di conversioni effettuate dall'utente.
Utilizza i report di debug per vedere le differenze tra i risultati della misurazione basata sui cookie e quelli che ottieni con l'API Attribution Reporting. Identifica le conversioni che vengono registrate, quante non sono incluse nei report e, in particolare, quali e perché.
Scopri come eseguire un'analisi della perdita nella Parte 3: ricettario sul debug.
Risolvere i problemi
Sebbene sia prevista la perdita causata dalla protezione della privacy o delle risorse, altre perdite potrebbero essere involontarie. Errori di configurazione nell'implementazione 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 sul tuo sito o per segnalare un potenziale bug ai team dei browser. Scopri come farlo nella Parte 3: Istruzioni sul debug.
Controllo della configurazione avanzata
Alcune funzionalità dell'API Attribution Reporting ti consentono di personalizzare i comportamenti dell'API. Le regole di filtro, di deduplicazione e di priorità sono solo alcuni esempi.
Quando utilizzi queste funzionalità, usa i report di debug per verificare che la logica porti al comportamento previsto in produzione, senza attendere i report sull'attribuzione. Scopri come fare nella Parte 3: Istruzioni sul debug.
Test locali con report aggregabili
A differenza dei report sull'attribuzione aggregabili, che sono criptati e aggregabili, i report di debug includono il payload non criptato.
Utilizza report di debug aggregabili per convalidare i contenuti dei report aggregabili e generare report di riepilogo con lo strumento di aggregazione locale per i test.
Rielaborazione dei report di Aggregation Service
Un altro vantaggio dell'utilizzo della modalità di debug è che consente di elaborare nuovamente i report. Pertanto, se vuoi elaborare i report più di una volta, assicurati di aver attivato i report di debug. Ti consigliamo di rielaborare i report quando:
- che tentano di eseguire il debug di Aggregation Service.
- sperimentando diverse strategie di batch.
- sperimentando diversi valori di 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. Questo è utile in caso di problemi del servizio di aggregazione, ad esempio servizi non disponibili o non adattabili, che potrebbero causare errori nella generazione dei report di riepilogo.