La proposta Attribution Reporting ha subito diverse modifiche per feedback della community, dalle modifiche al meccanismo delle API alle nuove funzionalità.
Log delle modifiche
- 7 febbraio 2022: è stata aggiunta una sezione sul reindirizzamento dell'attivatore di intestazione.
- 27 gennaio 2022: pubblicazione dell'articolo per la prima volta.
A chi è destinato questo post?
Questo post è per te:
- Se conosci già l'API, ad esempio se hai osservato o partecipare alle discussioni sul repository WICG e desiderano comprendere il batch modifiche apportate alla proposta a gennaio 2022.
- Se utilizzi l'API Attribution Reporting in una demo o in un esperimento in produzione.
Se hai appena iniziato a utilizzare questa API e/o non l'hai ancora sperimentata, vai direttamente alle introduzione all'API .
Migrazione in corso
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 per consentire all'API di continuare a funzionare. Puoi anche valutare l'uso delle nuove funzionalità.
Questo articolo elenca anche le modifiche per i report aggregabili. Tuttavia, se implementate, queste modifiche non richiederanno alcuna azione o migrazione, in quanto al momento della stesura di questo documento non esiste ancora un'implementazione del browser per i report aggregabili.
Modifiche ai nomi
Report di riepilogo e report aggregabili
Quelli che potresti aver visto, descritti come report aggregati, verranno ora chiamati come report di riepilogo.
I report di riepilogo sono l'output finale dell'aggregazione di più report integrabili, precedentemente chiamati contributi o contributi istogrammi.
Modifiche al meccanismo dell'API
Registrazione dell'origine basata su intestazioni (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 l'evento.
insieme a parametri specifici dei report sull'attribuzione (come il
attributionsourceeventid, attributiondestination, attributionexpiry e altri parametri). La
e 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 sul lato client, ovvero negli anchor tag come attributi HTML o come argomenti di una chiamata basata su JS. I parametri dovevano essere noti al clic o alla visualizzazione nel tempo.
Nella nuova proposta, il valore di questi parametri viene invece definito sul server adtech.
Ciò presenta una serie di lati positivi, in particolare in termini di sicurezza: il meccanismo dell'header dà al reporting origine, in genere un adtech, controllo diretto sulla registrazione o meno di una fonte di attribuzione nel proprio l'ambito di attività. Questo riduce parzialmente i problemi di attività fraudolenta, poiché con questa modifica un browser originale non Registrare una sorgente senza l'opzione di attivazione dell'origine del report.
Come funziona la registrazione di origine?
- Per un determinato annuncio, ora AdTech deve definire un attributo lato client specifico
attributionsrc. Il valore di questo attributo è un URL a cui il browser invia una richiesta; questa richiesta includerà una nuova intestazione HTTPAttribution-Reporting-Source-Infonavigationoevent,specifica se l'origine era rispettivamente un clic o una visualizzazione. - Alla ricezione di questa richiesta, il server di monitoraggio dei clic/visualizzazioni deve rispondere con un messaggio HTTP
intestazione
Attribution-Reporting-Register-Source, che contiene l'attribuzione desiderata parametri. L'origine che restituisce questa intestazione è ora l'origine dei report (precedentemente definita come
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
Registrare le origini di attribuzione
Partecipa alla discussione pubblica
Attivatore di attribuzione basata su intestazioni (report a livello di evento)
Che cosa cambia e perché?
Proprio come per fare clic o visualizzare la registrazione, la nuova proposta cambia l'attivatore di attribuzione, quando
adtech indica al browser di registrare una conversione con un approccio basato su intestazioni.
Questo meccanismo è in linea con la registrazione dell'origine basata su intestazioni ed è più
convenzionale rispetto al meccanismo di reindirizzamento usato in precedenza.
Inoltre, nella nuova proposta, l'attributo attributionsrc è necessario nella pagina di conversione.
La logica è una questione di autorizzazioni: nella proposta precedente, il sito lato trigger, in genere,
il sito di un inserzionista: aveva un controllo generale della funzionalità tramite un'intestazione Permissions-Policy, ma
non aveva un controllo granulare a livello di elemento sulla possibilità di inviare o meno una richiesta a una parte da un elemento
che potrebbero attivare un'attribuzione. attributionsrc modifica questo indicatore obbligatorio
offre all'inserzionista la possibilità di monitorare e, di conseguenza, di controllare quali elementi possono attivare un
l'attribuzione dei contenuti.
Tieni presente che sul lato sorgente, in genere il sito di un publisher, è un controllo a livello di pagina tramite
Sono presenti 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 deciso che deve essere classificata come conversione,
deve rispondere con un nuovo HTTP
intestazione Attribution-Reporting-Register-Event-Trigger.
Il valore di questa intestazione specifica come trattare l'evento di trigger come oggetto JSON. È lo stesso informazioni 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)
Facoltativamente, il server AdTech può generare la risposta che contiene Attribution-Reporting-Register-Event-Trigger una risposta di reindirizzamento.
Ciò consente a terze parti di osservare l'evento di conversione e di indicare al browser di attribuirlo.
Il reindirizzamento è facoltativo; non è necessario quando sia una tecnologia pubblicitaria sia una terza parte contengono pixel sulla pagina.
Puoi trovare ulteriori dettagli nei report di terze parti.
Scopri di più nella spiegazione tecnica
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 una un meccanismo basato su JavaScript che genera questi report.
Nella nuova proposta non è richiesto alcun worklet. Invece, un adTech definirebbe in modo dichiarativo, tramite HTTP Intestazioni: le regole che il browser dovrebbe utilizzare per generare report aggregabili.
La nuova proposta offre diversi vantaggi:
- Implementazione del browser: il nuovo design, a differenza di quello del worklet, è sostanzialmente più semplice perché non richiede un nuovo ambiente di esecuzione nei browser.
- Esperienza di sviluppo: il nuovo design si basa sulle intestazioni, di uso comune ampiamente conosciuti dagli sviluppatori, a differenza dei worklet. Inoltre, è in linea con la piattaforma API registrazione di origine, che semplifica l'apprendimento e l'utilizzo dell'API.
- Adozione: il nuovo design consente a un maggior numero di sistemi di misurazione esistenti da usare aggregabili report. Molte soluzioni di misurazione sono solo HTTP: si basano su richieste di immagini (pixel) che non richiedono l'accesso a JavaScript. Ma poiché l'approccio del worklet richiedeva ad accedere a JavaScript, potrebbe essere stato difficile eseguire la migrazione da alcuni sistemi di misurazione esistenti.
- Robustness: il nuovo design aiuta a mitigare la perdita di dati perché è più facile da integrare
con semantica
keepalive, ad esempio se un clic o una visualizzazione viene registrato quando un utente lascia l'azienda una pagina.
Come funziona il meccanismo "worklet-free"?
Questo meccanismo dichiarativo si basa sulle intestazioni HTTP, proprio come la registrazione dell'origine a livello di evento e l'intestazione dell'attivatore di attribuzione. Ulteriori dettagli sono disponibili nelle sezioni successive.
Partecipa alla discussione pubblica
Registrazione dell'origine basata su intestazioni (report aggregabili)
Viene proposto un nuovo meccanismo per registrare una fonte per un report aggregabile; questo meccanismo è uguale alla registrazione dell'origine a livello di evento.
Solo il nome dell'intestazione è diverso: Attribution-Reporting-Register-Aggregatable-Source.
Scopri di più nella spiegazione tecnica
Registrazione origine attribuzione
Attivatore di attribuzione basata su intestazioni (report aggregabili)
Viene proposto un nuovo meccanismo per registrare una fonte per un report aggregabile; questo meccanismo è uguale all'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
Attivazione della registrazione per l'attribuzione
Nuove funzionalità
Report di terze parti (report a livello di evento e aggregabili)
Che cosa cambia e perché?
Due aspetti della nuova proposta aiutano a supportare meglio i casi d'uso dei report di terze parti:
- Facoltativamente, i fornitori di tecnologia pubblicitaria possono reindirizzare le richieste di rete ad altri server di tecnologia pubblicitaria, il che consente a quegli altri adtech di eseguire la propria fonte e attivare la registrazione. Questo è un modo comune per sono configurate oggi. Ciò semplifica l'adozione dell'API, tra le altre cose nelle applicazioni sistemi di reporting di terze parti.
- Le origini dei report, in genere le adtech, non condividono più la maggior parte dei limiti di privacy. Ciò supporta l'utilizzo casi in cui più adtech collaborano con gli stessi publisher o inserzionisti.
Come funzionano i report di terze parti?
Nella nuova proposta, la registrazione dell'origine basata sulla risposta e il trigger si basano Intestazioni HTTP. Un AdTech può sfruttare i reindirizzamenti HTTP per queste richieste.
Se una richiesta di clic/visualizzazione sul sito di un publisher (registrazione di origine) viene successivamente reindirizzata a
Più parti, ognuna di queste parti può registrare questa visualizzazione o clic (evento di origine).
Analogamente, un adTech può reindirizzare una specifica richiesta di attribuzione effettuata da un sito dell'inserzionista.
consentendo a più parti di registrare una conversione (attivatore di attribuzione).
Ciascuna parte è in grado di accedere ai propri report separati e di configurarli con dati separati.
Registra più attivatori senza reindirizzamenti
È anche possibile registrare più attivatori di attribuzione senza utilizzare i reindirizzamenti, aggiungendo più elementi pixel sul lato della conversione (uno per attivatore).
Partecipa alla discussione pubblica
Misurazione view-through (report a livello di evento e report aggregabili)
Che cosa cambia e perché?
Nella nuova proposta, la misurazione view-through e la misurazione dei clickthrough funzionano in modo unificato:
registerattributionsrc, l'attributo specifico della visualizzazione che ha indicato al browser di registrare le visualizzazioni insieme ai clic, non fa più parte della proposta.- I meccanismi relativi alla privacy sono ora unificati per clic e visualizzazioni. Vedi i dettagli in Rumore. e trasparenza.
Si propone questa modifica per allinearsi al nuovo meccanismo di registrazione basato su intestazioni. Semplifica inoltre l'esperienza degli sviluppatori che intendono supportare sia clickthrough che view-through misurazione.
Come funziona la misurazione view-through?
La misurazione view-through e quella dei 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 aggregabili a livello di evento)
Che cosa cambia e perché?
Alla proposta è stato aggiunto un meccanismo di debug per aiutare gli sviluppatori a rilevare i bug, nonché Confrontare il rendimento di Attribution Reporting con quello di soluzioni di misurazione basate sui cookie esistenti.
Come funziona il debug?
Sia la registrazione di origine che quella di trigger accetteranno un nuovo parametro debug_key, un token non firmato a 64 bit
intero (ossia un numero grande).
Se viene creato un report con chiavi di debug di origine e di attivazione e se un cookie Samesite=None ar_debug=1
è presente nel contenitore dei cookie dell'origine report all'origine e attiva al momento della registrazione, un
report (JSON) verrà inviato a un endpoint .well-known/attribution-reporting/debug:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
I report aggregabili a livello di evento includeranno anche questi due nuovi parametri, associate al report di debug corretto.
Scopri di più nella spiegazione tecnica
Facoltativo: report di debug esteso
Partecipa alla discussione pubblica
Funzionalità di filtro (report a livello di evento e report aggregabili)
Che cosa cambia e perché?
Poiché supportano casi d'uso importanti nell'ecosistema pubblicitario odierno, numerosi casi d'uso sarà supportata nei report aggregabili a livello di evento:
- Filtro delle conversioni:filtra una conversione in base a informazioni lato sorgente. Per Ad esempio, seleziona dati di attivazione diversi (dati sulle conversioni) per i clic sugli annunci e le visualizzazioni.
- Mancata corrispondenza dell'attribuzione: filtra le conversioni che sono state attribuite erroneamente. questo è un tipo specifico di filtro delle conversioni. Ad esempio, filtra le conversioni corrispondenti a clic/visualizzazione sull'annuncio errati 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 di origine 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 del trigger ora accetterà 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
Campo filters per eseguire un filtro selettivo e impostare trigger_data in base a source_data.
Se le chiavi nei filtri JSON corrispondono alle chiavi in source_data, l'attivatore è
completamente ignorato se l'incrocio è vuoto.
Scopri di più nella spiegazione tecnica
Filtri di attribuzione facoltativi
Partecipa alla discussione pubblica
Modifiche alla protezione della privacy
Rumore e trasparenza (report a livello di evento e report aggregabili)
Che cosa cambia e perché?
Nella nuova proposta è stato migliorato uno dei meccanismi di tutela della privacy per i report: i report sono
in base alla risposta randomizzata.
Ciò significa che alcune conversioni reali verranno registrate correttamente; e una determinata percentuale del
tempo, alcune conversioni reali verranno soppresse oppure verranno aggiunte alcune conversioni false.
Questa nuova tecnica offre alcuni vantaggi:
- Unifica il meccanismo di tutela della privacy per i clic e le visualizzazioni.
- È più semplice da ragionare rispetto a un meccanismo in cui i dati di attivazione (dati sulle conversioni) e il rumore dei link dell'origine dell'attivatore sono separati.
- Configura un framework sulla privacy che potrebbe, con le giuste impostazioni del rumore, garantire che nessuna parte possa fare affidamento sull'API per sapere con certezza che un singolo utente ha effettuato o meno una conversione per un determinato annuncio.
Questo nuovo meccanismo sostituisce quello precedente, in cui il 5% delle volte attiva i dati (dati sulle conversioni) è stato sostituito con un valore casuale.
Inoltre, al corpo del report è stato aggiunto il valore di probabilità di risposta randomizzata.
(campo randomized_trigger_rate). Questo campo specifica la probabilità (da 0 a 1) che un'origine sia
in base a una risposta randomizzata.
Ciò presenta due vantaggi principali:
- Rende il comportamento del browser sottostante trasparente per le parti che riceveranno i report. (di solito le tecnologie pubblicitarie).
- È utile in un futuro in cui l'API sarà supportata in browser: browser diversi possono decidere di applicare livelli di rumore diversi a seconda della gli obiettivi di privacy; inoltre, le parti che gestiranno il report avranno bisogno di visibilità al riguardo.
Come funziona il rumore?
Nella nuova proposta, nel momento in cui viene registrata una sorgente (ovvero viene registrato un clic o una visualizzazione sull'annuncio), browser decide casualmente se attribuirà effettivamente le conversioni e invierà i relativi report clic/visualizzazione sull'annuncio o se verrà generato un output falso.
L'output falso può essere:
- Nessun report, indipendentemente dal fatto che l'utente effettui una conversione.
- Una o più segnalazioni false, indipendentemente dal fatto che l'utente effettui una conversione.
Nei report falsi, i dati di attivazione (dati sulle conversioni) sono casuali: un valore casuale a 3 bit per i clic (qualsiasi numero compreso tra 0 e 7) e un valore casuale a 1 bit per le viste (0 o 1).
Come nel caso di report reali, le segnalazioni false non vengono inviate immediatamente dopo la conversione dell'utente. Vengono inviate all'indirizzo alla fine di una finestra di report casuale.
Esistono tre finestre di report per i clic (2 giorni, 7 giorni o 30 giorni dopo il clic). Ogni falso viene assegnato in modo casuale a una delle finestre di segnalazione.
Separatamente, come ha già detto nella proposta precedente, l'ordine dei report all'interno di una finestra è casuale.
Scopri di più nella spiegazione tecnica
Esempi di conversioni false con rumore
Partecipa alla discussione pubblica
Limitazioni dei report (report a livello di evento e report aggregabili)
Limiti per l'origine dei report
Che cosa cambia e perché?
La nuova proposta limita esplicitamente il numero di parti che possono misurare gli eventi tra due siti.
- Il numero massimo di origini di segnalazione uniche (di solito adtech) che possono essere registrate di origini per {publisher, inserzionista} si propone di essere limitato a 100 ogni 30 giorni. Questo verrà incrementato per ogni clic o visualizzazione sull'annuncio (evento sorgente), anche quelli che non sono vengono attribuite.
- Il numero massimo di origini di segnalazione uniche (di solito le tecnologie pubblicitarie) che possono inviare report per Si propone di limitare {publisher, advertiser} a 10 ogni 30 giorni. Questo contatore verrà viene incrementato per ogni conversione attribuita.
Questi limiti sono pensati per essere sufficientemente alti da non limitare la capacità di nessun attore di misurare conversioni, ma abbastanza basso da contribuire a mitigare alcune forme di abuso delle API.
Attenuazione dei report / limiti di frequenza
Che cosa cambia e perché?
L'attenuazione dei report è un meccanismo di tutela della privacy che limita la quantità di informazioni totali inviate. tramite questa API in un determinato periodo di tempo per un utente.
Nella nuova proposta, 100 report per {sito di origine, destinazione, origine report} (in genere {publisher, advertiser, adtech}) possono essere programmati su 30 giorni.
Oltre questo limite, il browser interromperà la pianificazione dei report che corrispondono a {source site, destination, reporting origin} (in genere {publisher, advertiser, adtech}), fino ai 30 giorni consecutivi il numero di report è inferiore a 100 per {source site, destination, reporting source}.
Scopri di più nella spiegazione tecnica
Riduzione dei report / limiti di frequenza
Quota limite della destinazione (solo report a livello di evento)
Che cosa cambia e perché?
Il limite della destinazione viene modificato per includere l'origine report (in genere, una tecnologia pubblicitaria) nell'ambito: 100 univoci destinazioni in attesa (di solito, siti di inserzionisti o siti in cui si prevede che le conversioni place) sono consentiti 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 uniche coperte da origini in attesa
Tutte le risorse
- Consulta Report sull'attribuzione.
- Leggi l'articolo Informazioni sull'API.
L'immagine intestazione è tratta da Diana Polekhina su Unsplash.