Arrivare al 2023 non sarà una banalità: Google interviene di recente con ulteriori aggiornamenti e beta-testing circa uno degli sviluppi più sofferti della propria storia, quello del Google Privacy Sandbox che dovrebbe veleggiare proprio da fine anno per sostituire i tanti vituperati cookie di terze parti.
Annunciato nel 2019, accidentato da innumerevoli critiche (sia di occhiute autorità che di operatori del settore) battute di arresto e rinvii, Sandbox ora raggiunge una nuova fase: viene annunciata la beta release per la fine del 2022, da implementare negli aggiornamenti del sistema operativo Android.
Tenuto conto che la beta di uno dei suoi componenti modulare chiave, cioè Topics, era stato già messa a disposizione degli sviluppatori da aprile, dopo aver preso il posto del criticatissimo FLoC [Federated Learning of Cohorts]. Nei mesi di maggio e giugno scenderanno in campo altri tasselli: dalla sperimentazione in gruppi circoscritti al c.d. Attribution Reporting. Vediamo di capire meglio che cosa prevedono e le reazioni della platea di stakeholder.
Google Topics, ecco l’alternativa a FLoC per mandare in pensione i cookie
Indice degli argomenti
Google Privacy Sandbox: da soluzione di un problema a problema in sé
Rimandiamo ad altre sedi per riepilogare la cronistoria di Sandbox fin qui, limitandoci a ricordare che la sua finalità primaria dovrebbe essere quella di sostituire, in maniera più conforme soprattutto alla normativa europea sulla protezione dei dati, gli ormai deprecati cookie di terze parti.
Cookie che sono bersagliati da tutti i lati, vuoi da linee guida sempre più stringenti, vuoi da provvedimenti sanzionatori come quelli avverso i Google Analytics, dichiarati in dismissione da Chrome per il 2023.
L’alternativa di Google chiamata Sandbox è in realtà un vero e proprio framework modulare che cercherà di colmare le funzionalità e i risultati, anche numerici, crollati con la dismissione dei cookie di terze parti. Fin dall’esordio è stato oggetto di analisi e commenti spesso negativi, tanto più quando provenienti da operatori del settore o clienti di Google stessa, specie web marketer e advertiser. Google sta cercando di recuperarne la fiducia, pubblicando in Github i vari moduli, confrontandosi quotidianamente con tali player, recependo i feedback e tamponandone i dubbi funzionali e operativi.
Dall’altro lato abbiamo soprattutto gli Stati, i quali vedono con sospetto le soluzioni proposte da Mountain View. Ne è un esempio corposo il Regno Unito, dove l’ICO (autorità per la protezione dei dati personali) sta monitorando il rispetto della data protection da parte delle nuove soluzioni, affiancando la CMA (l’Antitrust britannica) che sta valutando eventuali abusi di posizione dominante sul mercato, o comunque concorrenziali e di tutela consumeristica. Google sta attivamente dialogando con tali autorità, persino con impegni formali, onde prevenire eventuali dichiarazioni e verifiche che potrebbero impattare sul lancio dell’iniziativa.
Insomma, un fuoco concentrato sull’azienda che dovrà accontentare esigenze spesso contrapposte, un compito non facile persino per il colosso californiano. Se dobbiamo trovare una parola chiave sottesa allo scenario, è “fiducia”, quasi tutta da riconquistare. Ricordiamo, a tal proposito, i pilastri dell’impegnativa iniziativa di Google, come da essa stessa proclamati:
- sostenere la capacità degli editori (publisher) di generare entrate e la capacità degli inserzionisti di garantire un buon rapporto qualità-prezzo dalla spesa pubblicitaria;
- supportare una buona esperienza utente durante la navigazione sul web, anche in relazione alla pubblicità digitale;
- fornire agli utenti una sostanziale trasparenza e il controllo in relazione ai propri dati personali mentre navigano sul web;
- non distorcere la concorrenza tra i prodotti e i servizi pubblicitari di Google con quelli di altre imprese del mercato.
Attenzione al passaggio sulla questione dei costi: nell’accordo con la CMA si elencano i fattori di valutazione e l’impatto sulla privacy e sulla normativa annessa è solo uno dei tanti. Tra gli altri troviamo l’impatto sulla concorrenza, sull’attività dei publisher, sulla user experience (UX) e – non marginale – “la fattibilità tecnica, la complessità e i costi per Google”.
I pezzi del lego: i moduli chiave di Sandbox
Riassumendo, il framework Sandbox che sta rilasciando in versione beta per Android, si comporrà soprattutto dei seguenti componenti:
- Topics API, che dovrebbe permettere l’advertising tramite browser, basato su determinati segnali di interesse (c.d. “topics”) degli utenti (si parla di “interest-based advertising”, diverso dal contextual advertising nel suo basarsi su pregresse interazioni utente con determinate app, da cui inferire i correlati interessi) e non già sulla loro identificazione o profilazione diretta, prevedendo comunque una condivisione dei topics con gli inserzionisti; nell’ultima versione si chiarisce che si possono utilizzare al massimo tre topics, a rappresentare determinati interessi dell’utente e che alcuni o tutti tali topics possono essere utilizzati per la personalizzazione degli annunci (esposti nelle app dei partecipanti, in maniera teoricamente più mirata); l’analisi viene effettuata per “epoche”, cioè periodi di computazione del topic, introducendo elementi di casualità che dovrebbero ostacolare l’identificazione utente;
- FLEDGE, che dovrebbe permettere di fare remarketing e custom audience targeting senza effettuare un tracciamento “in chiaro” degli utenti, bensì su una limitazione del flusso di identificatori tra app e dei dati di interazione utente a terze parti; tra le novità in sviluppo, si segnala il controllo dell’utente che dovrebbe permettere di visualizzare quali app abbiano almeno una custom audience associata e di cancellare tali custom audience, impedendo al contempo di aggiungerne di nuove;
- Attribution Reporting, che dovrebbe effettuare misurazioni approfondite dell’audience (le attività, i canali, le campagne specifiche che stanno generando il maggior numero di risultati, ecc.), sempre senza effettuare un tracciamento vero e proprio dell’utente; a sostituire attuali strumenti di tracciamento come Advertising ID sarà la prassi di eliminare gli identificatori, di settare dei limiti per i trigger di conversione (ad es. l’installazione di una app; possono essere app-to-app, web-to-app, app-to-web, web-to-web) e il numero di piattaforme ad tech che possono essere associate a una fonte di attribuzione (click e visualizzazioni di un ad), di incorporare iniezioni di “rumore” statistico (k-randomizzato) nei dati output, così da ostacolare l’identificazione utente.
Come anticipato, si attueranno sperimentazioni tramite “Canary Chrome beta”, in cerchie ristrette di utenti, per poi raccoglierne i riscontri e testarne il grado di maturità per il grande pubblico. L’impegno si manifesta anche nella volontà di pubblicare tutti risultati dei test.
Nell’aggiornamento sullo stato di avanzamento ora pubblicato per gli sviluppatori, possiamo trovare un riepilogo dei nuovi sviluppi e degli aggiornamenti alle proposte di progettazione, le domande chiave e i feedback ricevuti, gli aggiornamenti sulle versioni di anteprima per sviluppatori. Sono resi disponibili anteprime delle API di Attribution Reporting, Topics e dell’SDK Runtime (app fondamentale per eseguire gli SDK in una sandbox separata, a limitazione nell’accesso ai dati utente).
Nel frattempo, ecco Google Enhanced Conversions
In tutto questo periodo che possiamo dire di transizione, Google offre però anche una feature di Google Ads, tramite tag manager o global tag, che – pur non rientrando formalmente nel pacchetto Sandbox – ne vuole attuare i (dichiarati) principi di protezione dei dati, al contempo offrendo risultati commerciali significativi (a detta di Google). Si tratta di Enhanced Conversions, strumento tuttora in versione beta, per controllare e ottenere maggiori conversioni sfruttando dati di prima parte, dei titolari inserzionisti. Sposando in toto la filosofia post-cookie di terze parti a monte del progetto Sandbox, per fornire agli advertiser “dati di conversione più accurati, a vantaggio dell’ottimizzazione e del rendimento complessivo della campagna”: ROI, Smart bidding, Customer journey eccetera.
Il “do ut des” è uno scambio tra i dati “hashati” da parte del titolare e le metriche sulle conversioni da parte di Google. Merita dunque una breve descrizione anche questo strumento già diffuso nell’ecosistema dell’advertising.
La chiave tecnica risiede nell’uso di dati di prima parte, sottoposti a hash “sicuro” con un algoritmo crittografico SHA256, considerato attualmente sufficientemente protettivo. L’hashing avverrebbe, in locale, da parte del titolare, che poi “uploada” solo il risultato a Google, in forma hashata e dunque non leggibile in chiaro da Google stessa o da terzi. Un precedente tecnico si può trovare in Advanced Matching di Facebook/Meta, introdotto nel 2016 e applicato ai pixel, anzi: si può affermare che con Conversions Google cerchi di recuperare il terreno perduto verso Meta proprio a causa di questo strumento.
Di che dati si parla, quali dati sarebbero di “prima parte”? Ad es. i dati identificativi, l’e-mail o il numero di telefono di un utente che li inserisce in un form online per registrarsi su un sito e-commerce. Sono questi i dati sottoposti ad hash e così inviati a Google per le operazioni di monitoraggio, dirette a costruire sì un profilo utente ma non direttamente identificativo (i dati, come detto, non sono in chiaro). Ma si tratta di un utente comunque “identificabile”, ai sensi del GDPR? L’equivoco potrebbe essere nel pensare che l’applicazione dell’hash porti a dati anonimi, dunque non personali.
Non è così: l’hash è pacificamente ritenuto portare al più a una pseudonimizzazione, che riduce soltanto la “linkability” dei dati a un interessato specifico, mantenendo l’attributo di “personali” a questi dati. Con tutti gli adempimenti conseguenti in capo a Google e ai titolari prima parte, soprattutto circa gli specifici consensi da parte degli utenti.
Si offre una maggiore sicurezza dei dati, certamente, ma non una loro anonimizzazione e connesso libero utilizzo. Il profilo costruito da Google con i dati hashati è comunque, plausibilmente, non difficile da ricostruire e re-identificare da parte soprattutto di terzi: basti pensare a tecniche ad es. di rainbow table attack, oltre ai possibili incroci e arricchimenti possibili di big data e arrivare all’interessato – sul tema è interessante la guida all’hash dell’AEPD spagnola. Si badi che Google richiede circa 75 giorni di raccolta e trattamento dei dati prima di poter restituire dati di conversione davvero avanzati, un lasso di tempo di intenso trattamento e connessi rischi.
Difatti Google stessa nella sua promozione della feature pare riferire a un maggior rispetto della privacy non tanto da parte propria (vi è una fase in cui i dati di prima parte, hashati, sono confrontati – si parla proprio di “match” – con i dati di account utenti Google, parimenti hashati), quanto dalle terze parti. Cosa che assume un certo rilievo in uno scenario ove i sistemi di Real Time Bidding (aste pubblicitarie con ad network), come quello TCF di IAB, sono stati censurati proprio per l’immane condivisione dei dati personali, in chiaro o quasi, tra tutti i partecipanti agli ad network.
Che tutto questo, però, rappresenti un significativo passo avanti per la privacy utente è tutto da chiarire, restando sempre e comunque in mano a Google il controllo assoluto dei vari dataset, potendo sempre arricchire i propri con dati di terzi, con un ruolo privacy non sempre cristallino specie nel distinguere tra finalità proprie e conto terzi. Dobbiamo segnalare che ogni utente Google, tramite menù nel proprio account, può comunque limitare il modo in cui si utilizzano i propri dati tramite le impostazioni “Attività web e app” del pannello di controllo “Gestione attività”, come si vede di seguito. Il che dovrebbe avere un effetto di parziale limitazione sull’uso dei dati anche da parte di Conversions, non è molto chiaro fino a che punto.
Per non parlare dei titolari prima parte: sono in grado di fornire ai propri utenti idonea informativa, chiara e specifica a sufficienza, nonché di raccogliere adeguato consenso per le operazioni di matching suddette, come peraltro è Google stessa a richiedere ai propri inserzionisti?
Vedremo come procederanno i successivi aggiornamenti del testing, sicuramente sarà una sfida.
