Chrome Privacy Sandbox e Topics API: La guida 2026 per publisher su consenso, targeting e misurazione
Per gran parte dell'ultimo decennio, la pubblicità digitale ha funzionato su una semplice assunzione: i cookie di terze parti sarebbero sempre stati lì, trasportando silenziosamente gli identificatori degli utenti attraverso il web. Quell'assunzione è ora infranta. Il percorso di deprecazione di Chrome è cambiato più volte, ma la direzione di marcia non è cambiata: il tracciamento cross-site tramite il cookie di terze parti sta finendo, e la Privacy Sandbox di Google è il sostituto che Chrome vuole che publisher e inserzionisti adottino. La Sandbox non è un singolo prodotto. È un insieme di API del browser — Topics, Protected Audience, Attribution Reporting, Fenced Frames, Shared Storage e altro ancora — ognuna che sostituisce un caso d'uso specifico che i cookie erano soliti coprire. Per un publisher, la parte difficile non è capire le API singolarmente. È costruire un livello di consenso e un percorso di monetizzazione che mantengano i flussi di Privacy Sandbox, la conformità GDPR e le leggi sulla privacy statali tutti allineati contemporaneamente. Questa guida illustra i componenti in movimento nel 2026 e come deve apparire il tuo stack di consenso.
Cosa sostituisce realmente la Privacy Sandbox
I cookie di terze parti svolgevano quattro funzioni pubblicitarie distinte: targeting basato sugli interessi, retargeting, misurazione delle conversioni e frequency capping. La Privacy Sandbox divide questi in API separate, ciascuna con il proprio profilo di consenso.
Topics API — Targeting basato sugli interessi
La Topics API assegna a ogni browser un piccolo set di argomenti di interesse a grana grossa — circa cinque argomenti alla settimana, estratti da una tassonomia curata di poche centinaia di categorie. Quando un publisher chiama document.browsingTopics(), il browser restituisce fino a tre argomenti che l'ecosistema ad tech può utilizzare per la personalizzazione contestuale senza alcun identificatore cross-site. Gli argomenti vengono calcolati localmente, archiviati sul dispositivo, ruotano settimanalmente e sono soggetti ai controlli degli utenti in chrome://settings/adPrivacy.
Protected Audience API — Retargeting e remarketing
Protected Audience, precedentemente FLEDGE, mantiene il retargeting in vita senza un identificatore cross-site condiviso. Gli inserzionisti aggiungono un utente a un gruppo di interesse sul proprio sito; quando l'utente visita un publisher partecipante, un'asta sul dispositivo viene eseguita in un Fenced Frame e seleziona una creatività. L'annuncio vincente viene renderizzato senza che il publisher sappia quale gruppo di interesse corrisponde.
Attribution Reporting API — Misurazione delle conversioni
Attribution Reporting sostituisce i pixel di conversione per un sottoinsieme di casi d'uso di misurazione. Supporta report a livello di evento (rumorosi, con perdita, per conversione) e report di riepilogo aggregati (rollup statisticamente corretti). A differenza del pixel legacy, non espone il collegamento utente-conversione individuale.
Shared Storage e Fenced Frames
Shared Storage è un archivio chiave-valore scrivibile ovunque e leggibile in sandbox per casi d'uso cross-site come il frequency capping e la coerenza degli esperimenti A/B. I Fenced Frames sono iframe isolati che impediscono alla pagina circostante di leggere l'annuncio renderizzato o i relativi dati di interazione.
La Privacy Sandbox richiede il consenso?
Questa è la domanda più fraintesa nel panorama ad tech del 2026, e la risposta è specifica per giurisdizione.
Ai sensi del GDPR e dell'ePrivacy
L'European Data Protection Board non ha emesso una posizione generale, ma le autorità nazionali sono state più esplicite. L'ICO del Regno Unito, il Garante italiano e la CNIL francese hanno tutti preso la posizione che Topics e Protected Audience richiedono il consenso opt-in preventivo dove trattano dati personali, compreso qualsiasi trattamento che scriva o legga lo stato sul dispositivo dell'utente. La logica: il browser memorizza ancora localmente argomenti di interesse e gruppi di interesse, e la chiamata document.browsingTopics() trasmette dati personali desunti a una terza parte. Questo è regolato dall'articolo 5(3) della Direttiva ePrivacy, che richiede il consenso per qualsiasi accesso o archiviazione sul dispositivo terminale dell'utente al di là di quanto strettamente necessario per il servizio richiesto.
La posizione di Google è più permissiva — sostengono che le API sono progettate per preservare la privacy e che i requisiti di consenso potrebbero non applicarsi in tutti i contesti. Questa non è una posizione delle autorità di regolamentazione. Trattare la Privacy Sandbox come esente dal consenso in Europa è una postura ad alto rischio.
Ai sensi di CCPA, CPRA e leggi statali USA
Negli Stati Uniti, i flussi di Privacy Sandbox sono generalmente trattati come condivisione di informazioni personali per la pubblicità comportamentale cross-contesto ai sensi del CPRA. Ciò significa che attivano il diritto di opt-out e devono essere rispettati tramite i segnali Global Privacy Control e altri meccanismi universali di opt-out. Il fatto che i dati di Topics siano derivati dal browser piuttosto che venduti da un broker di terze parti non li esonera.
I controlli propri di Chrome
Chrome fornisce interruttori rivolti all'utente in chrome://settings/adPrivacy per Topics, Protected Audience e Attribution Reporting. Queste scelte degli utenti si affiancano — non sostituiscono — lo stato di consenso del CMP. Un utente che ha detto no ai cookie pubblicitari nel tuo banner ma sì a Topics nelle impostazioni globali di Chrome ti ha comunque detto no attraverso il banner. Il tuo stack deve rispettare il più restrittivo dei due segnali.
Il livello di consenso di cui hai realmente bisogno
Uno stack di consenso di livello produzione per il 2026 tratta le API Privacy Sandbox come attività di trattamento distinte, ciascuna controllata tramite gli scopi IAB TCF o categorie equivalenti di legge statale.
Mappatura delle API Sandbox agli scopi TCF
- Topics API — IAB TCF Scopo 2 (Seleziona annunci di base) e Scopo 3 (Crea un profilo di annunci personalizzati) come minimo; Scopo 4 (Seleziona annunci personalizzati) se gli argomenti alimentano il targeting.
- Protected Audience — Scopo 3 e 4, più Scopo 7 (Misura le prestazioni degli annunci) se l'asta utilizza dati di risultato.
- Attribution Reporting — Scopo 7 (Misura le prestazioni degli annunci) e Scopo 9 (Comprendi i pubblici attraverso le statistiche).
- Shared Storage per il frequency capping — Scopo 3 dove alimenta la personalizzazione, o una base di interesse legittimo dove è puramente controllo della frequenza.
Mappatura su Google Consent Mode v2
I segnali di Google Consent Mode v2 si mappano sul comportamento di Privacy Sandbox:
- ad_storage negato — disabilita completamente le chiamate alle API Topics e Protected Audience
- ad_user_data negato — blocca Attribution Reporting dall'invio di dati con ambito utente
- ad_personalization negato — salta gli input di Topics nella logica di targeting
Gestione dei segnali degli stati USA
Per il traffico USA, il tuo livello di consenso dovrebbe ispezionare Global Privacy Control e i segnali di opt-out statali applicabili. Quando un utente USA ha rinunciato alla condivisione, sopprimi document.browsingTopics(), non chiamare joinAdInterestGroup e rimuovi le intestazioni di registrazione Attribution Reporting.
Modelli di implementazione pratici
I publisher che hanno già distribuito Privacy Sandbox seguono generalmente uno di due modelli architetturali.
Modello 1: Orchestrazione lato server
Un tag manager first-party sul tuo dominio di origine raccoglie lo stato di consenso, la giurisdizione dell'utente e qualsiasi override dei segnali, quindi renderizza condizionalmente gli hook di Privacy Sandbox nella pagina. Il server degli annunci e l'SSP ricevono i flag di consenso attraverso la richiesta di offerta e decidono se chiamare Topics, Protected Audience o nessuno dei due. Questo modello centralizza la logica e mantiene autorevole lo stato di consenso.
Modello 2: Integrazione Header Bidding Wrapper
Prebid.js e altri header bidding wrapper ora supportano i moduli Privacy Sandbox. Il wrapper legge il segnale di consenso, configura il comportamento della chiamata Topics e invia il risultato dell'asta attraverso Protected Audience quando consentito. Questo approccio è più leggero da distribuire ma spinge più logica nel client e stringe la dipendenza dalla cadenza di rilascio del wrapper.
Cosa verificare
- Conferma che
document.browsingTopics()non venga chiamato a meno che il consenso pubblicitario del CMP non sia affermativo e non sia presente alcun segnale di opt-out - Conferma che
joinAdInterestGrouperunAdAuctionsiano controllati dalle stesse condizioni - Conferma che le intestazioni di registrazione Attribution Reporting vengano inviate solo nelle risposte per gli utenti il cui stato di consenso consente la misurazione
- Conferma che il tuo elenco di fornitori nella stringa TCF corrisponda ancora agli SSP e DSP che utilizzano le API Sandbox nel tuo inventario
- Conferma che la tua privacy policy descriva Topics, Protected Audience e Attribution Reporting come attività di trattamento distinte, con base giuridica e conservazione
Cosa non fa la Privacy Sandbox
Diversi malintesi comuni devono essere eliminati prima di fare previsioni di budget.
Non è un modo per aggirare il consenso
Le API riducono i dati personali esposti agli inserzionisti, ma non rendono il trattamento sottostante esente dal consenso ai sensi del diritto europeo. La teoria di conformità secondo cui l'adozione della Sandbox consente di saltare un CMP è errata in ogni giurisdizione EU/EEA.
Non è un sostituto completo dei cookie oggi
Topics fornisce un segnale di targeting grezzo e con perdita che è tipicamente più debole dei pubblici basati sui cookie. Le scale di retargeting di Protected Audience sono ancora in maturazione. Attribution Reporting ha soglie di rumore di misurazione che possono nascondere piccoli incrementi di conversione. Un publisher che sposta tutta la monetizzazione su Sandbox oggi dovrebbe aspettarsi cali di RPM del 10-30 percento rispetto a uno stack basato sui cookie su un inventario tipico.
Non è permanente nella sua forma attuale
La specifica di Privacy Sandbox è ancora in evoluzione. La tassonomia di Topics si sta espandendo, i limiti dei gruppi di interesse di Protected Audience sono sotto revisione e la risposta normativa è in corso. Progetta il tuo livello di consenso in modo che sia guidato dalla configurazione, non codificato rigidamente rispetto alla specifica attuale.
La postura giusta per il 2026
La Privacy Sandbox si comprende meglio come uno strato di una strategia cookieless più ampia, insieme ai dati first-party, ai pubblici definiti dal venditore, al targeting contestuale e all'header bidding lato server. I publisher che vincono nel 2026 saranno quelli che trattano il consenso come l'arbitro, non l'ostacolo — alimentando le API Sandbox solo dove la legge e la scelta dell'utente lo consentono, ripiegando pulitamente sul contestuale ovunque altrove, e misurando i risultati su entrambi i percorsi con strumenti che non presuppongono l'identità.
La postura peggiore è quella attendista. I regolatori stanno già scrivendo la prossima ondata di regole — gli impegni Sandbox dell'Autorità per la concorrenza e i mercati del Regno Unito, le linee guida CNIL in corso e le disposizioni di profilazione dell'AI Act UE toccano tutti questo territorio. I publisher che integrano Privacy Sandbox in uno stack di consenso correttamente controllato nel 2026 saranno pronti per quelle regole. Quelli che lo aggiungono all'ultimo minuto come sostituto dei cookie si troveranno a riscrivere sotto pressione.