La proposta di Attribution Reporting ha subito una serie di modifiche per rispondere ai feedback della community, dalle modifiche al meccanismo dell'API alle nuove funzionalità.
Log delle modifiche
- 7 febbraio 2022: aggiunta la sezione sul reindirizzamento dell'attivatore dell'intestazione.
- 27 gennaio 2022: data di prima pubblicazione dell'articolo.
A chi è rivolto questo post?
Questo post è per te:
- Se conosci già l'API, ad esempio se hai osservato o partecipato alle discussioni nel repository WICG e vuoi comprendere il batch di modifiche apportate alla proposta a gennaio 2022.
- Se utilizzi l'API Attribution Reporting in una demo o in un esperimento in produzione.
Se stai appena iniziando a utilizzare questa API e/o non l'hai ancora sperimentata, vai direttamente alla introduzione all'API.
Migrazione imminente
Una volta implementate queste modifiche in Chrome, se utilizzi i report a livello di evento dell'API Attribution Reporting in una demo o in un esperimento in produzione (prova dell'origine), dovrai modificare il codice affinché l'API continui a funzionare. Potresti anche valutare la possibilità di utilizzare le nuove funzionalità.
Questo articolo elenca anche le modifiche ai report aggregabili. Tuttavia, se verranno implementate, queste modifiche non richiederanno alcuna azione o migrazione, in quanto al momento non è ancora disponibile un'implementazione del browser per i report aggregabili.
Modifiche del nome
Report di riepilogo e aggregabili
A ciò che potresti aver visto descritto come report aggregati ora verrà fatto riferimento come report di riepilogo.
I report di riepilogo sono l'output finale dell'aggregazione di più report aggregabili, precedentemente chiamati contributi o contributi dell'istogramma.
Modifiche al meccanismo dell'API
Registrazione delle origini in base all'intestazione (report a livello di evento)
Che cosa cambia e perché?
Quando l'utente visualizza o fa clic su un annuncio, il browser, localmente sul dispositivo dell'utente, registra questo evento, insieme ai parametri specifici per i report sull'attribuzione (come attributionsourceeventid, attributiondestination, attributionexpiry e altri parametri). I valori di questi parametri sono impostati dalla tecnologia pubblicitaria.
La modalità di impostazione di questi parametri sta cambiando.
Nella proposta precedente, i parametri dovevano essere inclusi lato client: nei tag anchor come attributi HTML o come argomenti di una chiamata basata su JS. I parametri dovevano essere noti al momento del clic o della visualizzazione.
Nella nuova proposta, il valore di questi parametri è definito sul server adtech.
Questo ha una serie di vantaggi, in particolare in termini di sicurezza: il meccanismo dell'intestazione consente all'origine report, in genere una tecnologia pubblicitaria, di controllare direttamente se un'origine di attribuzione è registrata nel suo ambito. In questo modo, i problemi di attività fraudolenta vengono mitigati parzialmente, poiché con questa modifica un browser autentico non registrerà mai una sorgente senza l'attivazione dell'origine report.
Come funziona la registrazione delle origini?
- Per un determinato annuncio, la tecnologia pubblicitaria ora deve definire un attributo lato client specifico
attributionsrc. Il valore di questo attributo è un URL a cui il browser invierà una richiesta. Questa richiesta includerà una nuova intestazione HTTPAttribution-Reporting-Source-Infoil cui valore,navigationoevent,, specifica se l'origine è stata rispettivamente un clic o una visualizzazione. - Al ricevimento di questa richiesta, il server di monitoraggio dei clic/delle visualizzazioni deve rispondere con un'intestazione HTTP,
Attribution-Reporting-Register-Source, contenente i parametri di attribuzione desiderati. L'origine che restituisce questa intestazione è ora l'origine report (in precedenza definita
attributionreportto).Intestazione della risposta HTTP
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Scopri di più nella spiegazione tecnica
Registrazione delle origini attribuzione
Partecipa alla discussione pubblica
Attivazione dell'attribuzione basata sull'intestazione (report a livello di evento)
Che cosa cambia e perché?
Come per la registrazione dei clic o delle visualizzazioni, la nuova proposta modifica l'attivatore dell'attribuzione, ovvero il momento in cui la tecnologia pubblicitaria chiede al browser di registrare una conversione, in un approccio basato su intestazioni.
Questo meccanismo è in linea con la registrazione delle sorgenti basata sugli header ed è più convenzionale rispetto al meccanismo di reindirizzamento utilizzato in precedenza.
Inoltre, nella nuova proposta, l'attributo attributionsrc è necessario nella pagina di conversione.
Il ragionamento si basa sulle autorizzazioni: nella proposta precedente, il sito lato trigger, in genere un sito dell'inserzionista, aveva il controllo generale della funzionalità tramite un'intestazione Permissions-Policy, ma non aveva un controllo granulare a livello di elemento sull'eventuale invio di una richiesta da parte di un elemento a una terza parte che avrebbe attivato un'attribuzione. attributionsrc cambia le cose: questo indicatore obbligatorio consente all'inserzionista di monitorare e quindi controllare quali elementi possono attivare un'attribuzione.
Tieni presente che sul lato di origine, in genere un sito del publisher, sono presenti un controllo a livello di pagina tramite Permissions-Policy e un controllo a livello di elemento tramite attributionsrc.
Come funziona l'attivazione dell'attribuzione?
Dopo aver ricevuto una richiesta di pixel e aver deciso che deve essere classificata come conversione, una piattaforma adtech deve rispondere con una nuova intestazione HTTP
Attribution-Reporting-Register-Event-Trigger.
Il valore di questa intestazione specifica come trattare l'evento di attivazione come oggetto JSON. Si tratta delle stesse informazioni che sono state definite come parametri di query nella proposta precedente.
Intestazione della risposta HTTP Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
Reindirizzamento (facoltativo)
Se vuoi, il server adtech può impostare la risposta che contiene Attribution-Reporting-Register-Event-Trigger come risposta di reindirizzamento.
In questo modo, le terze parti possono osservare l'evento di conversione e indicare al browser di attribuirlo.
Il reindirizzamento è facoltativo e non è necessario quando nella pagina sono presenti pixel sia di una piattaforma ad tech sia di terze parti.
Maggiori dettagli in Report di terze parti.
Scopri di più nella spiegazione tecnica
Attribuzione basata su trigger
Partecipa alla discussione pubblica
Nessun worklet (report aggregabili)
Che cosa cambia e perché?
Nella proposta precedente per i report aggregabili, era necessario l'accesso a JavaScript per richiamare un worklet, un meccanismo basato su JavaScript, che generava questi report.
Nella nuova proposta non è richiesto alcun worklet. Un fornitore di tecnologia pubblicitaria, invece, definirebbe in modo dichiarativo, tramite le intestazioni HTTP, le regole che il browser deve utilizzare per generare report aggregabili.
La nuova proposta offre diversi vantaggi:
- Implementazione nei browser:il nuovo design, a differenza del design dei worklet, è molto più semplice perché non richiede un nuovo ambiente di esecuzione nei browser.
- Esperienza dello sviluppatore: il nuovo design si basa su intestazioni, che sono comunemente utilizzate e ampiamente conosciute dagli sviluppatori, a differenza dei worklet. Inoltre, è strettamente in linea con l'interfaccia API per la registrazione delle origini, rendendo l'API più facile da imparare e utilizzare.
- Adozione: il nuovo design consente a un maggior numero di sistemi di misurazione esistenti di utilizzare i report aggregabili. Molte soluzioni di misurazione sono solo HTTP: si basano su richieste di immagini (richieste di pixel) che non richiedono l'accesso a JavaScript. Tuttavia, poiché l'approccio dei worklet richiedeva accesso a JavaScript, la migrazione da alcuni sistemi di misurazione esistenti potrebbe essere stata difficile.
- Robustezza:il nuovo design contribuisce a ridurre la perdita di dati perché è più facile da integrare con la semantica
keepalive, ad esempio se un clic o una visualizzazione viene registrato quando un utente esce da una pagina.
Come funziona il meccanismo senza worklet?
Questo meccanismo dichiarativo si basa sulle intestazioni HTTP, proprio come la registrazione della sorgente a livello di evento e l'intestazione dell'attivatore dell'attribuzione. Scopri di più nelle sezioni successive.
Partecipa alla discussione pubblica
Registrazione delle origini in base all'intestazione (report aggregabili)
Viene proposto un nuovo meccanismo per registrare una sorgente per un report aggregabile. Questo meccanismo è lo stesso della registrazione delle sorgenti a livello di evento.
Solo il nome dell'intestazione è diverso: Attribution-Reporting-Register-Aggregatable-Source.
Scopri di più nella spiegazione tecnica
Registrazione dell'origine dell'attribuzione
Attivazione dell'attribuzione basata sugli header (report aggregabili)
Viene proposto un nuovo meccanismo per registrare un'origine per un report aggregabile. Questo meccanismo è lo stesso dell'attivatore di attribuzione a livello di evento.
Solo il nome dell'intestazione è diverso: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
Scopri di più nella spiegazione tecnica
Registrazione dell'attivatore dell'attribuzione
Nuove funzionalità
Report di terze parti (report a livello di evento e aggregabili)
Che cosa cambia e perché?
Due aspetti della nuova proposta contribuiscono a supportare meglio i casi d'uso dei report di terze parti:
- Se vuoi, le ad tech possono indirizzare le richieste di rete ad altri server ad tech, in modo che queste altre ad tech possano eseguire la propria registrazione e attivare l'origine. Questo è un modo comune di configurare le terne parti oggi. In questo modo, l'API è più facile da adottare, ad esempio nei sistemi di generazione di report di terze parti esistenti.
- Le origini report, in genere le tecnologie pubblicitarie, non condividono più la maggior parte dei limiti relativi alla privacy. Questo supporta casi d'uso in cui più tecnologie pubblicitarie collaborano con gli stessi publisher o inserzionisti.
Come funzionano i report di terze parti?
Nella nuova proposta, la registrazione e l'attivazione delle origini basate sulle risposte si basano sulle intestazioni HTTP. Una tecnologia adtech può sfruttare i reindirizzamenti HTTP per queste richieste.
Se una richiesta di clic/visualizzazione su un sito del publisher (registrazione dell'origine) viene successivamente reindirizzata a più parti, ciascuna di queste parti può registrare questa visualizzazione o questo clic (evento di origine).
Analogamente, una tecnologia adtech può reindirizzare una richiesta di attribuzione specifica effettuata da un sito dell'inserzionista,
consentendo a più parti di registrare una conversione (attivatore dell'attribuzione).
Ogni parte può accedere ai propri report separati e configurarli con dati distinti.
Registra più attivatori senza reindirizzamenti
È anche possibile registrare più attivatori di attribuzione senza utilizzare i reindirizzamenti, aggiungendo più elementi di pixel lato conversione (uno per attivatore).
Partecipa alla discussione pubblica
Misurazione view-through (report a livello di evento e aggregabili)
Che cosa cambia e perché?
Nella nuova proposta, la misurazione delle visualizzazioni e la misurazione dei clic funzionano in modo unificato:
registerattributionsrc, l'attributo specifico della visualizzazione che indicava al browser di registrare le visualizzazioni insieme ai clic, non fa più parte della proposta.- I meccanismi di privacy sono ora unificati per clic e visualizzazioni. Per maggiori dettagli, consulta la sezione Rumore e trasparenza.
Questa modifica è proposta per allinearsi al nuovo meccanismo di registrazione basato sugli header. Inoltre, semplifica l'esperienza degli sviluppatori che intendono supportare sia la misurazione dei clic sia quella delle visualizzazioni indirette.
Come funziona la misurazione delle visualizzazioni indirette?
La misurazione delle conversioni view-through e la misurazione delle conversioni clickthrough si basano entrambe sulla registrazione basata su intestazioni.
Scopri di più nella spiegazione tecnica
Report a livello di evento (per clic e visualizzazioni)
Partecipa alla discussione pubblica
Debug / analisi del rendimento (report a livello di evento e aggregabili)
Che cosa cambia e perché?
Alla proposta è stato aggiunto un meccanismo di debug per aiutare gli sviluppatori a rilevare i bug, nonché a confrontare il rendimento dei report sull'attribuzione con le soluzioni di misurazione basate sui cookie esistenti.
Come funziona il debug?
Sia la registrazione della sorgente sia quella dell'attivatore accetterà un nuovo parametro debug_key, un numero intero senza segno di 64 bit (ovvero un numero grande).
Se un report viene creato con chiavi di debug di origine e attivazione e se un cookie Samesite=None ar_debug=1 è presente nel contenitore dei cookie dell'origine report al momento della registrazione dell'origine e dell'attivatore, un report di debug (JSON) verrà inviato a un endpoint .well-known/attribution-reporting/debug:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
I report aggregabili e a livello di evento includeranno anche questi due nuovi parametri, in modo che possano essere associati al report di debug corretto.
Scopri di più nella spiegazione tecnica
(Facoltativo) Report di debug estesi
Partecipa alla discussione pubblica
Funzionalità di filtro (report a livello di evento e aggregabili)
Che cosa cambia e perché?
Poiché supportano casi d'uso importanti nell'attuale ecosistema pubblicitario, ora un certo numero di casi d'uso sarà supportato sia nei report aggregabili sia a livello di evento:
- Filtro delle conversioni:filtra una conversione in base alle informazioni lato sorgente. Ad esempio, puoi selezionare dati di attivazione (dati sulle conversioni) diversi per i clic e le visualizzazioni degli annunci.
- Mancata corrispondenza dell'attribuzione:filtra le conversioni che sono state attribuite erroneamente. Si tratta di un tipo specifico di filtro delle conversioni. Ad esempio, filtra le conversioni associate al clic/alla visualizzazione dell'annuncio sbagliato a causa dell'ambito della destinazione etld+1 nell'API.
Come funzionano le funzionalità di filtro? (per i report a livello di evento)
Un campo source_data facoltativo nell'oggetto JSON lato sorgente può definire gli elementi che verranno successivamente utilizzati dal browser al momento della conversione per applicare la logica di filtro.
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
La registrazione dell'attivatore ora accetta un'intestazione facoltativa Attribution-Reporting-Filters.
Intestazione della risposta HTTP Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
In alternativa, l'intestazione Attribution-Reporting-Register-Event-Trigger può essere estesa con un
filters campo per applicare un filtro selettivo e impostare trigger_data in base a source_data.
Se le chiavi nel file JSON dei filtri corrispondono alle chiavi in source_data, l'attivatore viene
completamente ignorato se l'intersezione è vuota.
Scopri di più nella spiegazione tecnica
Filtri di attribuzione facoltativi
Partecipa alla discussione pubblica
Numero del problema 194
Numero del problema 201
Modifiche alla protezione della privacy
Rumore e trasparenza (report a livello di evento e aggregabili)
Che cosa cambia e perché?
Nella nuova proposta, è stato migliorato uno dei meccanismi di privacy per i report: i report sono soggetti a risposte randomizzate.
Ciò significa che alcune conversioni reali verranno registrate correttamente e, in una certa percentuale di casi, alcune conversioni reali verranno eliminate o verranno aggiunte conversioni false.
Questa nuova tecnica presenta alcuni vantaggi:
- Unifica il meccanismo di privacy per clic e visualizzazioni.
- È più semplice da comprendere rispetto a un meccanismo in cui i dati sugli attivatori (dati sulle conversioni) e il rumore del collegamento dell'attivatore all'origine vengono separati.
- Consente di configurare un framework per la privacy che, con le giuste impostazioni di rumore, potrebbe garantire che nessuna parte possa fare affidamento sull'API per sapere con certezza se un singolo utente ha effettuato una conversione (o meno) per un determinato annuncio.
Questo nuovo meccanismo sostituisce quello precedente in cui il 5% delle volte i dati di attivazione (dati sulle conversioni) venivano sostituiti con un valore casuale.
Inoltre, il valore della probabilità di risposta casuale è stato aggiunto al corpo del report
(campo randomized_trigger_rate). Questo campo specifica la probabilità (da 0 a 1) che un'origine sia
soggetta a una risposta casuale.
Questo approccio presenta due vantaggi principali:
- Rende trasparente il comportamento del browser sottostante alle parti che riceveranno i report (in genere, le adtech).
- È utile per un futuro in cui l'API sarà supportata su tutti i browser: browser diversi potrebbero decidere di applicare livelli diversi di rumore a seconda dei loro scopi di privacy e le parti che gestiranno il report avranno bisogno di visibilità in merito.
Come funziona il rumore?
Nella nuova proposta, al momento della registrazione di un'origine (ovvero quando viene registrato un clic o una visualizzazione dell'annuncio), il browser decide in modo casuale se attribuire in modo veritiero le conversioni e inviare report per questo clic/visualizzazione dell'annuncio oppure se generare un output falso.
L'output falso può essere:
- Nessun report, indipendentemente dal fatto che l'utente effettui o meno una conversione.
- Una o più segnalazioni false, indipendentemente dal fatto che l'utente effettui o meno una conversione.
Nei report falsi, i dati di attivazione (dati sulle conversioni) sono casuali: un valore di 3 bit casuale per i clic (qualsiasi numero compreso tra 0 e 7) e un valore di 1 bit casuale per le visualizzazioni (0 o 1).
Come i report reali, i report falsi non vengono inviati immediatamente dopo la conversione dell'utente. Vengono inviati alla fine di un'intervallo di generazione dei report casuale.
Esistono tre finestre di generazione di report per i clic (2 giorni, 7 giorni o 30 giorni dopo il clic). Ogni report simulato viene assegnato in modo casuale a una delle finestre di generazione dei report.
Inoltre, come già indicato nella proposta precedente, l'ordinamento dei report all'interno di una finestra è casuale.
Scopri di più nella spiegazione tecnica
Esempi di conversioni false con elevato livello di rumore
Partecipa alla discussione pubblica
Numero del problema 84
Numero del problema 273
Limitazioni dei report (report a livello di evento e aggregabili)
Che cosa cambia e perché?
La nuova proposta limita esplicitamente il numero di parti che possono misurare gli eventi tra due siti.
- È stato proposto di limitare a 100 per 30 giorni il numero massimo di origini report univoche (in genere adtech) che possono registrare fonti per {publisher, advertiser}. Questo conteggio verrà incrementato per ogni clic o visualizzazione dell'annuncio (evento di origine), anche per quelli non attribuiti.
- È stato proposto di limitare a 10 per 30 giorni il numero massimo di origini report univoche (in genere adtech) che possono inviare report per {publisher, advertiser}. Questo contatore verrà incrementato per ogni conversione attribuita.
Questi limiti devono essere sufficientemente elevati da non limitare la capacità di misurare le conversioni da parte di alcun attore, ma sufficientemente bassi da contribuire a mitigare alcune forme di abuso dell'API.
Tempo di attesa / limiti di frequenza per i report
Che cosa cambia e perché?
Il tempo di attesa dei report è un meccanismo di privacy che limita la quantità di informazioni totali inviate tramite questa API in un determinato periodo di tempo per un utente.
Nella nuova proposta, è possibile pianificare 100 report per {source site, destination, reporting origin} (in genere {publisher, advertiser, adtech}) in un periodo di 30 giorni.
Oltre questo limite, il browser smetterà di pianificare i report corrispondenti a questo determinato {source site, destination, reporting origin} (in genere {publisher, advertiser, adtech}), finché il conteggio dei report su 30 giorni non scende al di sotto di 100 per {source site, destination, reporting origin}.
Scopri di più nella spiegazione tecnica
Tempo di attesa / limiti di frequenza dei report
Limite di destinazione (solo report a livello di evento)
Che cosa cambia e perché?
Il limite di destinazione viene modificato in modo da includere l'origine report (in genere, una tecnologia pubblicitaria) nell'ambito: sono consentite 100 destinazioni pending univoche (in genere, siti dell'inserzionista o siti in cui si prevede che si verifichino le conversioni) per {publisher, adtech}.
Si tratta di una protezione della privacy per limitare la ricostruzione della cronologia di navigazione.
Scopri di più nella spiegazione tecnica
Limitare il numero di destinazioni univoche coperte dalle origini in attesa
Tutte le risorse
- Consulta la sezione Report sull'attribuzione.
- Leggi l'articolo Cosa devi sapere sull'API.
L'immagine intestazione è di Diana Polekhina su Unsplash.