Chrome Privacy Sandbox i l'API Topics: La guia de l'editor del 2026 sobre consentiment, segmentació i mesurament
Durant la major part de l'última dècada, la publicitat digital funcionava sobre un supòsit senzill: les galetes de tercers sempre hi serien, transportant silenciosament identificadors d'usuari per tota la web. Aquell supòsit ja s'ha trencat. El camí de deprecació de Chrome ha canviat diverses vegades, però la direcció del viatge no ha canviat: el seguiment entre llocs mitjançant la galeta de tercers està acabant, i el Privacy Sandbox de Google és el substitut que Chrome vol que editors i anunciants adoptin. El Sandbox no és un producte únic. És un conjunt d'API de navegador — Topics, Protected Audience, Attribution Reporting, Fenced Frames, Shared Storage i més — cadascun substituint un cas d'ús específic que les galetes solien cobrir. Per a un editor, la part difícil no és entendre les API individualment. Consisteix a construir una capa de consentiment i un camí de monetització que mantingui els fluxos del Privacy Sandbox, el compliment del GDPR i la llei de privadesa estatal tots alineats simultàniament. Aquesta guia recorre les peces mòbils del 2026 i com ha de ser la vostra pila de consentiment.
Què substitueix realment el Privacy Sandbox
Les galetes de tercers portaven quatre funcions publicitàries diferenciades: segmentació basada en interessos, retargeting, mesurament de conversions i limitació de freqüència. El Privacy Sandbox divideix aquestes en API separades, cadascuna amb el seu propi perfil de consentiment.
Topics API — Segmentació Basada en Interessos
L'API Topics assigna a cada navegador un petit conjunt de temes d'interès de gra gruixut — al voltant de cinc temes per setmana, extrets d'una taxonomia curada de pocs centenars de categories. Quan un editor crida document.browsingTopics(), el navegador retorna fins a tres temes que l'ecosistema de tecnologia publicitària pot usar per a la personalització contextual sense cap identificador entre llocs. Els temes es calculen localment, s'emmagatzemen al dispositiu, es rooten setmanalment i estan subjectes als controls de l'usuari a chrome://settings/adPrivacy.
Protected Audience API — Retargeting i Remarketing
Protected Audience, anteriorment FLEDGE, manté el retargeting viu sense un identificador compartit entre llocs. Els anunciants afegeixen un usuari a un grup d'interès al seu propi lloc; quan l'usuari visita un editor participant, una subhasta al dispositiu s'executa en un Fenced Frame i selecciona un creatiu. L'anunci guanyador es mostra sense que l'editor sàpiga quin grup d'interès va coincidir.
Attribution Reporting API — Mesurament de Conversions
Attribution Reporting substitueix els píxels de conversió per a un subconjunt de casos d'ús de mesurament. Admet informes a nivell d'event (sorollosos, amb pèrdues, per conversió) i informes de resum agregat (resums estadísticament neutralitzats). A diferència del píxel heretat, no exposa l'enllaç individual usuari-conversió.
Shared Storage i Fenced Frames
Shared Storage és un magatzem de clau-valor d'escriptura en qualsevol lloc i lectura en sandbox per a casos d'ús entre llocs com la limitació de freqüència i la coherència d'experiments A/B. Els Fenced Frames són iframes aïllats que impedeixen que la pàgina envoltant llegeixi l'anunci renderitzat o les seves dades d'interacció.
El Privacy Sandbox requereix consentiment?
Aquesta és la pregunta més incompresa en el panorama de l'ad tech del 2026, i la resposta és específica de la jurisdicció.
Sota el GDPR i ePrivacy
El Comitè Europeu de Protecció de Dades EDPB no ha emès una posició general, però les autoritats nacionals han estat més explícites. La ICO del Regne Unit, el Garante italià i la CNIL francesa han adoptat la posició que Topics i Protected Audience requereixen consentiment previ opt-in on tracten dades personals, incloent-hi qualsevol tractament que escriu o llegeix l'estat al dispositiu de l'usuari. La lògica: el navegador encara emmagatzema localment temes d'interès i grups d'interès, i la crida a document.browsingTopics() transmet dades personals inferides a un tercer. Això està regulat sota l'article 5(3) de la Directiva ePrivacy, que requereix consentiment per a qualsevol accés o emmagatzematge a l'equip terminal de l'usuari més enllà del que és estrictament necessari per al servei sol·licitat.
La posició de Google és més permissiva — argumenten que les API preserven la privadesa per disseny i que els requisits de consentiment poden no aplicar-se en tots els contextos. Aquesta no és una posició del regulador. Tractar el Privacy Sandbox com a exempt de consentiment a Europa és una postura d'alt risc.
Sota la CCPA, la CPRA i les Lleis Estatals dels EUA
Als Estats Units, els fluxos del Privacy Sandbox se solen tractar com a compartició d'informació personal per a publicitat conductual en contextos creuats sota la CPRA. Això significa que activen el dret de renúncia i han de ser respectats a través dels senyals del Global Privacy Control i altres mecanismes universals de renúncia. El fet que les dades de Topics provinguin del navegador en comptes de ser venudes per un intermediari tercer no les exempta.
Els Controls Propis de Chrome
Chrome proporciona commutadors d'usuari a chrome://settings/adPrivacy per a Topics, Protected Audience i Attribution Reporting. Aquestes opcions de l'usuari es troben al costat de — no en lloc de — l'estat de consentiment del vostre CMP. Un usuari que ha dit no a les galetes de publicitat al vostre bàner però sí a Topics a la configuració global de Chrome encara us ha dit que no a través del bàner. La vostra pila ha de respectar el més estricte dels dos senyals.
La Capa de Consentiment que Realment Necessiteu
Una pila de consentiment de 2026 de grau de producció tracta les API del Privacy Sandbox com a activitats de tractament diferenciades, cadascuna controlada mitjançant finalitats IAB TCF o categories equivalents de llei estatal.
Mapatge d'API del Sandbox a Finalitats TCF
- Topics API — IAB TCF Finalitat 2 (Seleccionar anuncis bàsics) i Finalitat 3 (Crear un perfil d'anuncis personalitzat) com a mínim; Finalitat 4 (Seleccionar anuncis personalitzats) si els temes alimenten la segmentació.
- Protected Audience — Finalitat 3 i 4, a més de la Finalitat 7 (Mesurar el rendiment dels anuncis) si la subhasta usa dades de resultats.
- Attribution Reporting — Finalitat 7 (Mesurar el rendiment dels anuncis) i Finalitat 9 (Entendre les audiències mitjançant estadístiques).
- Shared Storage per a limitació de freqüència — Finalitat 3 on alimenta la personalització, o una base d'interès legítim on és purament control de freqüència.
Mapatge a Google Consent Mode v2
Els senyals del Google Consent Mode v2 es mapegen al comportament del Privacy Sandbox:
- ad_storage denegat — deshabilitar completament les crides a les API Topics i Protected Audience
- ad_user_data denegat — bloquejar que Attribution Reporting enviï dades amb abast d'usuari
- ad_personalization denegat — ometre les entrades de Topics a la lògica de segmentació
Gestió de Senyals d'Estat dels EUA
Per al trànsit dels EUA, la vostra capa de consentiment hauria d'inspeccionar el Global Privacy Control i els senyals de renúncia estatals aplicables. Quan un usuari dels EUA s'ha exclòs de la compartició, suprimiu document.browsingTopics(), no crideu joinAdInterestGroup i elimineu les capçaleres de registre d'Attribution Reporting.
Patrons d'Implementació Pràctics
Els editors que ja han desplegat el Privacy Sandbox generalment segueixen un de dos patrons arquitectònics.
Patró 1: Orquestració del Costat del Servidor
Un gestor d'etiquetes de primera part al vostre origen recull l'estat de consentiment, la jurisdicció de l'usuari i qualsevol substitució de senyals, i després renderitza condicionalment els ganxos del Privacy Sandbox a la pàgina. El servidor d'anuncis i l'SSP reben marques de consentiment a través de la sol·licitud d'oferta, i decideixen si cridar Topics, Protected Audience o cap. Aquest patró centralitza la lògica i manté l'estat de consentiment autoritatiu.
Patró 2: Integració d'Embolcall de Header Bidding
Prebid.js i altres embolcalls de header bidding ara suporten mòduls del Privacy Sandbox. L'embolcall llegeix el senyal de consentiment, configura el comportament de crida de Topics i reenvia el resultat de la subhasta mitjançant Protected Audience quan és permès. Aquest enfocament és més lleuger de desplegar però empeny més lògica cap al client i estreny la vostra dependència del ritme de llançament de l'embolcall.
Què Auditar
- Confirmeu que
document.browsingTopics()no es crida tret que el consentiment de publicitat del CMP sigui afirmatiu i no hi hagi cap senyal de renúncia present - Confirmeu que
joinAdInterestGroupirunAdAuctionestan controlats per les mateixes condicions - Confirmeu que les capçaleres de registre d'Attribution Reporting només s'envien en respostes per a usuaris l'estat de consentiment dels quals permet el mesurament
- Confirmeu que la vostra llista de proveïdors a la cadena TCF encara coincideix amb els SSP i DSP que usen les API del Sandbox al vostre inventari
- Confirmeu que la vostra política de privadesa descriu Topics, Protected Audience i Attribution Reporting com a activitats de tractament diferenciades, amb base legal i retenció
Què No Fa el Privacy Sandbox
Diverses idees errònies habituals han de desaparèixer abans de pressupostar-hi.
No És una Solució per Evitar el Consentiment
Les API redueixen les dades personals exposades als anunciants, però no fan que el tractament subjacent estigui exempt de consentiment sota la llei europea. La teoria de compliment que l'adopció del Sandbox us permet ometre un CMP és incorrecta en totes les jurisdiccions EU/EEA.
Avui No És un Substitut Complet de les Galetes
Topics ofereix un senyal de segmentació groller i amb pèrdues que normalment és més feble que les audiències basades en galetes. Les escales de retargeting de Protected Audience encara estan madurant. Attribution Reporting té nivells mínims de soroll de mesurament que poden amagar petits augments de conversió. Un editor que traslladi tota la monetització al Sandbox avui hauria d'esperar descensos de RPM del 10-30 per cent en relació amb una pila basada en galetes en inventari típic.
No És Permanent en la Seva Forma Actual
L'especificació del Privacy Sandbox encara evoluciona. La taxonomia de Topics s'està ampliant, els límits de grups d'interès de Protected Audience estan sota revisió i la resposta regulatòria continua. Dissenyeu la vostra capa de consentiment perquè estigui controlada per configuració, no codificada de manera rígida a l'especificació actual.
La Postura Correcta per al 2026
El Privacy Sandbox s'entén millor com una capa d'una estratègia sense galetes més àmplia, juntament amb dades de primera part, audiències definides pel venedor, segmentació contextual i header bidding del costat del servidor. Els editors que guanyaran el 2026 seran aquells que tractin el consentiment com l'àrbitre, no l'obstacle — alimentant les API del Sandbox únicament on la llei i l'elecció de l'usuari ho permeten, recaient nètament a la contextual a tot arreu, i mesurant resultats a través d'ambdós camins amb eines que no assumeixen identitat.
La pitjor postura és la d'esperar i veure. Els reguladors ja estan escrivint la propera onada de regles — els compromisos del Sandbox de la UK Competition and Markets Authority, l'orientació continuada de la CNIL i les disposicions de perfilació de la EU AI Act toquen tot aquest terreny. Els editors que integrin el Privacy Sandbox en una pila de consentiment correctament controlada el 2026 estaran preparats per a aquelles regles. Els que l'afegeixin com un substitut d'última hora de les galetes es trobaran reescrivint sota pressió.