La proposta Attribution Reporting ha subito una serie di modifiche per rispondere al feedback della community, dalle modifiche del meccanismo API alle nuove funzionalità.
Log delle modifiche
- 7 febbraio 2022: aggiunta della sezione relativa al reindirizzamento dell'attivatore di intestazione.
- 27 gennaio 2022: prima pubblicazione dell'articolo.
A chi è destinato questo post?
Questo post fa per te:
- Se comprendi già l'API, ad esempio se hai osservato o partecipato alle discussioni sul repository WICG e vuoi comprendere il gruppo di 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 all'introduzione dell'API.
Migrazione a seguire
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. Puoi anche prendere in considerazione l'utilizzo delle nuove funzionalità.
Questo articolo elenca anche le modifiche per i report aggregabili. Tuttavia, queste modifiche, se implementate, non richiederanno alcuna azione o migrazione, in quanto al momento della stesura di questo documento non esiste ancora un'implementazione tramite browser per i report aggregabili.
Modifiche ai nomi
Report di riepilogo e report aggregabili
I report che potresti aver descritto come report aggregati verranno ora chiamati report di riepilogo.
I report di riepilogo sono l'output finale dell'aggregazione di più report aggregati, precedentemente chiamati contributi o contributi agli istogrammi.
Modifiche ai meccanismi API
Registrazione di 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 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.
Il modo in cui vengono impostati questi parametri sta cambiando.
Nella proposta precedente, i parametri dovevano essere inclusi sul lato client: negli anchor tag 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 viene invece definito sull'adtech server.
Questo presenta una serie di svantaggi, in particolare in termini di sicurezza: il meccanismo di intestazione dà all'origine dei report, in genere una tecnologia pubblicitaria, il controllo diretto sulla registrazione o meno di un'origine di attribuzione nel suo ambito. Questo riduce parzialmente i problemi di attività fraudolenta, poiché con questa modifica un browser autentico non registrerà mai un'origine senza l'attivazione dell'origine report.
Come funziona la registrazione del codice sorgente?
- Per un determinato annuncio, ora la tecnologia pubblicitaria 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-Infoil cui valorenavigationoevent,specifica se la sorgente era rispettivamente un clic o una visualizzazione. - Dopo aver ricevuto questa richiesta, il server di monitoraggio dei clic/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 dei report (precedentemente definita come
attributionreportto).Intestazione risposta HTTP
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Scopri di più nel messaggio esplicativo tecnico
Registrare le origini di attribuzione
Partecipa alla discussione pubblica
Attivatore di attribuzione basata sulle intestazioni (report a livello di evento)
Che cosa cambia e perché?
Proprio come la registrazione di clic o visualizzazioni, la nuova proposta modifica l'attivatore di attribuzione, quando una tecnologia pubblicitaria indica al browser di registrare una conversione, in un approccio basato su intestazioni.
Questo meccanismo è in linea con la registrazione di origine basata su intestazioni ed è più convenzionale rispetto al meccanismo di reindirizzamento utilizzato in precedenza.
Inoltre, nella nuova proposta, è necessario l'attributo attributionsrc nella pagina di conversione.
Il motivo è legato alle autorizzazioni: nella proposta precedente, il sito lato trigger (di solito il sito di un inserzionista) aveva il controllo generale della funzionalità tramite un'intestazione Permissions-Policy, ma
non aveva un controllo granulare a livello di elemento relativo all'invio di una richiesta a una parte
che avrebbe attivato un'attribuzione. attributionsrc modifica questa impostazione: questo indicatore obbligatorio
consente all'inserzionista di monitorare e quindi controllare quali elementi possono attivare
un'attribuzione.
Tieni presente che sul lato dell'origine, di solito il sito di un editore, sono presenti un controllo a livello di pagina tramite Permissions-Policy e un controllo a livello di elemento tramite attributionsrc.
Come funziona l'attivatore di attribuzione?
Dopo aver ricevuto una richiesta di pixel e aver deciso che deve essere classificata come conversione, una tecnologia pubblicitaria 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 un oggetto JSON. Si tratta delle stesse informazioni definite come parametri di query nella proposta precedente.
Intestazione 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 di adtech può rendere la risposta contenente Attribution-Reporting-Register-Event-Trigger una risposta di reindirizzamento.
In questo modo, le terze parti possono osservare l'evento di conversione e indicare al browser di attribuirlo.
Il reindirizzamento è facoltativo; non è necessario quando sia una tecnologia pubblicitaria che una terza parte contengono pixel nella pagina.
Maggiori dettagli sono disponibili in Report di terze parti.
Scopri di più nel messaggio esplicativo tecnico
Partecipa alla discussione pubblica
Nessun worklet (report aggregabili)
Che cosa cambia e perché?
Nella precedente proposta 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. Una tecnologia pubblicitaria definirebbe invece in modo dichiarativo, tramite intestazioni HTTP, 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 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, comunemente utilizzate e ampiamente conosciute dagli sviluppatori, a differenza dei worklet. Inoltre, si allinea strettamente con la piattaforma API per la registrazione dell'origine, semplificando l'apprendimento e l'utilizzo dell'API.
- Adozione: il nuovo design consente a più sistemi di misurazione esistenti di usare 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 worklet richiedeva l'accesso a JavaScript, potrebbe essere stato difficile eseguire la migrazione da alcuni sistemi di misurazione esistenti.
- Robustezza: il nuovo design aiuta a mitigare la perdita di dati, in quanto è più facile integrarla con la semantica di
keepalive, ad esempio se viene registrato un clic o una visualizzazione quando un utente sta abbandonando una pagina.
Come funziona il meccanismo senza worklet?
Questo meccanismo dichiarativo è basato sulle intestazioni HTTP, proprio come la registrazione dell'origine a livello di evento e l'intestazione dell'attivatore di attribuzione. Maggiori dettagli in merito nelle sezioni successive.
Partecipa alla discussione pubblica
Registrazione di origine basata su intestazioni (report aggregabili)
Viene proposto un nuovo meccanismo per registrare una fonte per un report aggregabile; questo meccanismo è uguale alla registrazione della fonte a livello di evento.
Solo il nome dell'intestazione è diverso: Attribution-Reporting-Register-Aggregatable-Source.
Scopri di più nel messaggio esplicativo tecnico
Registrazione dell'origine dell'attribuzione
Attivatore di attribuzione basata sulle 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ù nel messaggio esplicativo tecnico
Registrazione attivatore di attribuzione
Nuove funzionalità
Report di terze parti (report a livello di evento e report aggregabili)
Che cosa cambia e perché?
Due aspetti della nuova proposta contribuiscono a supportare meglio i casi d'uso dei report di terze parti:
- Facoltativamente, le adtech possono reindirizzare le richieste di rete ad altri server di tecnologia pubblicitaria, consentendo a queste ultime di eseguire la propria origine e attivare la registrazione. Si tratta di un modo comune per configurare terze parti. Questo semplifica l'adozione dell'API, tra le altre nei sistemi di generazione di report di terze parti esistenti.
- Le origini della segnalazione, in genere le tecnologie pubblicitarie, non condividono più la maggior parte dei limiti relativi alla privacy. Ciò supporta i 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'attivatore di origine basati sulle risposte si basano sulle intestazioni HTTP. Una tecnologia pubblicitaria può sfruttare i reindirizzamenti HTTP per queste richieste.
Se una richiesta di clic/visualizzazione sul sito di un editore (registrazione di origine) viene successivamente reindirizzata a più parti, ciascuna di queste parti può registrare questa visualizzazione o clic (evento sorgente).
Analogamente, una tecnologia pubblicitaria può reindirizzare una richiesta di attribuzione specifica effettuata da un sito di inserzionisti,
consentendo a più parti di registrare una conversione (attivatore di attribuzione).
Ciascuna 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 reindirizzamenti, aggiungendo più elementi di pixel sul lato delle conversioni (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 clic funzionano in modo unificato:
registerattributionsrc, l'attributo specifico per la vista 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 tutti i clic e le visualizzazioni. Consulta i dettagli in Rumore e trasparenza.
Questa modifica viene proposta per allinearsi al nuovo meccanismo di registrazione basato su intestazioni. Inoltre, semplifica l'esperienza degli sviluppatori quando intendono supportare la misurazione sia di clic che di view-through.
Come funziona la misurazione view-through?
Sia la misurazione view-through che la misurazione dei clickthrough si basano sulla registrazione basata su intestazioni.
Scopri di più nel messaggio esplicativo tecnico
Report a livello di evento (per clic e visualizzazioni)
Partecipa alla discussione pubblica
Debug / analisi del rendimento (report a livello di evento e report aggregabili)
Che cosa cambia e perché?
Alla proposta è stato aggiunto un meccanismo di debug per aiutare gli sviluppatori a rilevare i bug e per confrontare le prestazioni di Attribution Reporting con le soluzioni di misurazione esistenti basate su cookie.
Come funziona il debug?
Sia la registrazione dell'origine che del trigger accettano un nuovo parametro debug_key, un numero intero senza firma a 64 bit (ovvero un numero elevato).
Se un report viene creato con chiavi di debug di origine e di attivazione e se è presente un cookie Samesite=None ar_debug=1 nel contenitore dei cookie dell'origine report al momento della registrazione e dell'origine, verrà inviato un report di debug (JSON) 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, in modo che possano essere associati al report di debug corretto.
Scopri di più nel messaggio esplicativo tecnico
(Facoltativo) Report di debug estesi
Partecipa alla discussione pubblica
Funzionalità di filtro (report a livello di evento e report aggregabili)
Che cosa cambia e perché?
Poiché supportano importanti casi d'uso nell'ecosistema pubblicitario odierno, ora saranno supportati una serie di casi d'uso sia nei report aggregabili a livello di evento:
- Filtro delle conversioni:filtra una conversione in base alle informazioni sul lato origine. Ad esempio, seleziona diversi dati di attivazione (dati sulle conversioni) per clic e visualizzazioni sugli annunci.
- Attribuzione non corrispondente: filtra le conversioni che sono state attribuite in modo errato. Si tratta di un tipo specifico di filtro delle conversioni. Ad esempio, filtra le conversioni che corrispondono al clic/alla visualizzazione dell'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 origine può definire gli elementi che verranno utilizzati successivamente 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 applicare filtri selettivi al fine di impostare trigger_data in base a source_data.
Se le chiavi nel JSON dei filtri corrispondono alle chiavi in source_data, l'attivatore viene
completamente ignorato se l'intersezione è vuota.
Scopri di più nel messaggio esplicativo tecnico
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, uno dei meccanismi di tutela della privacy per le segnalazioni è stato migliorato: le segnalazioni sono
soggette a risposta casuale.
Ciò significa che alcune conversioni reali verranno registrate correttamente e, in una determinata percentuale, alcune conversioni reali verranno soppresse o verranno aggiunte altre false.
Questa nuova tecnica presenta alcuni vantaggi:
- Unifica il meccanismo di privacy per clic e visualizzazioni.
- È più semplice ragionare su un meccanismo in cui i dati degli attivatori (dati sulle conversioni) e il rumore del link dell'origine dell'attivatore sono separati.
- Imposta un framework per la 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 i dati del trigger (dati sulle conversioni) sono stati sostituiti con un valore casuale.
Inoltre, al corpo del report (campo randomized_trigger_rate) è stato aggiunto il valore della probabilità di risposta randomizzata. Questo campo specifica la probabilità (da 0 a 1) che un'origine sia soggetta a risposta randomizzata.
I vantaggi principali sono due:
- Rende il comportamento sottostante del browser transparent per le parti che riceveranno i report (in genere, le tecnologie pubblicitarie).
- È utile in un futuro in cui l'API sarà supportata su tutti i browser: diversi browser potrebbero decidere di applicare livelli di rumore diversi a seconda dei propri obiettivi di privacy e le parti che gestiranno il report dovranno avere visibilità in merito.
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), il browser decide in modo casuale se attribuirà effettivamente le conversioni e invierà report per questo clic/visualizzazione dell'annuncio o se genererà invece un output fasullo.
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 visualizzazioni (0 o 1).
Come le vere segnalazioni, le segnalazioni false non vengono inviate subito dopo la conversione dell'utente. Vengono inviati 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 segnalazione falsa viene assegnata in modo casuale a una delle finestre di segnalazione.
Separatamente, come già indicato nella proposta precedente, l'ordinamento dei report all'interno di una finestra è casuale.
Scopri di più nel messaggio esplicativo tecnico
Esempi di conversioni false rumorose
Partecipa alla discussione pubblica
Limitazioni dei report (report a livello di evento e report aggregabili)
Che cosa cambia e perché?
La nuova proposta limita esplicitamente il numero di parti che possono misurare gli eventi tra due siti.
- Si propone che il numero massimo di origini report univoche (generalmente di tecnologia pubblicitaria) che possono registrare origini per {publisher, advertiser} sia limitato a 100 ogni 30 giorni. Questo contatore verrà incrementato per ogni clic o visualizzazione sull'annuncio (evento di origine), anche per quelli non attribuiti.
- Si propone che il numero massimo di origini report univoche (in genere ad tech) che possano inviare report per {publisher, advertiser} sia limitato a 10 ogni 30 giorni. Questo contatore verrà incrementato per ogni conversione attribuita.
Questi limiti sono pensati per essere sufficientemente elevati da non limitare la capacità degli attori di misurare le conversioni, ma sufficientemente bassi da contribuire a mitigare alcune forme di abuso dell'API.
Limiti di frequenza / attesa per l'attesa dei report
Che cosa cambia e perché?
La riduzione dei report è un meccanismo di privacy che limita la quantità di informazioni totali inviate da un utente tramite questa API in un determinato periodo di tempo.
Nella nuova proposta, è possibile pianificare 100 report per {source site, destination, reporting origin} (in genere {publisher, advertiser, adtech}) per un periodo di 30 giorni.
Superato questo limite, il browser interromperà la pianificazione dei report che corrispondono a {source site, destination, reporting origin} (in genere {publisher, advertiser, adtech}) finché il numero di report continuativi di 30 giorni non scenderà al di sotto di 100 per {source site, destination, reporting origin}.
Scopri di più nel messaggio esplicativo tecnico
Limiti di frequenza e riduzione dei report
Quota limite (solo report a livello di evento)
Che cosa cambia e perché?
La quota limite di destinazione viene modificata per includere l'origine dei report (di solito, una tecnologia pubblicitaria) nell'ambito: per {publisher, adtech} sono consentite 100 destinazioni univoche in attesa (di solito, siti di inserzionisti o siti in cui è previsto che si verifichino conversioni).
Si tratta di una protezione della privacy per limitare la ricostruzione della cronologia di navigazione.
Scopri di più nel messaggio esplicativo tecnico
Limitare il numero di destinazioni univoche coperte da origini in attesa
Tutte le risorse
- Consulta Report sull'attribuzione.
- Leggi l'articolo Cosa devi sapere sull'API.
L'immagine intestazione è di Diana Polekhina su Unsplash.