Chrome Privacy Sandbox e a Topics API: A Guía do Editor de 2026 sobre Consentimento, Segmentación e Medición

Durante a maior parte da última década, a publicidade dixital funcionou cunha suposición simple: as cookies de terceiros sempre estarían aí, transportando silenciosamente identificadores de usuario por toda a web. Esa suposición está agora rota. O camiño de eliminación de Chrome cambiou varias veces, pero a dirección da viaxe non: o rastrexo entre sitios a través da cookie de terceiros está a rematar, e o Privacy Sandbox de Google é o substituto que Chrome quere que os editores e anunciantes adopten. O Sandbox non é un produto único. É un conxunto de API de navegador — Topics, Protected Audience, Attribution Reporting, Fenced Frames, Shared Storage e máis — cada un substituíndo un caso de uso específico que as cookies adoitaban cubrir. Para un editor, a parte difícil non é comprender as API individualmente. É construír unha capa de consentimento e un camiño de monetización que mantén os fluxos de Privacy Sandbox, o cumprimento do GDPR e a lei de privacidade estatal todos aliñados simultáneamente. Esta guía percorre as pezas en movemento en 2026 e como ten que verse a túa pila de consentimento.

O que Privacy Sandbox realmente substitúe

As cookies de terceiros portaban catro funcións publicitarias distintas: segmentación baseada en intereses, reorientación, medición de conversión e limitación de frecuencia. Privacy Sandbox divide estas en API separadas, cada unha cun seu propio perfil de consentimento.

Topics API — Segmentación baseada en intereses

A API Topics asigna a cada navegador un pequeno conxunto de temas de interese de grano grueso — aproximadamente cinco temas por semana, extraídos dunha taxonomía curada de uns centos de categorías. Cando un editor chama a document.browsingTopics(), o navegador devolve ata tres temas que o ecosistema adtech pode usar para a personalización contextual sen ningún identificador entre sitios. Os temas calcúlanse localmente, almacénanse no dispositivo, rotan semanalmente e están suxeitos aos controis do usuario en chrome://settings/adPrivacy.

Protected Audience API — Reorientación e remarketing

Protected Audience, anteriormente FLEDGE, mantén a reorientación viva sen un identificador entre sitios compartido. Os anunciantes unen a un usuario a un grupo de interese no seu propio sitio; cando o usuario visita un editor participante, execútase unha poxa no dispositivo nun Fenced Frame e selecciónase un creativo. O anuncio gañador renderízase sen que o editor saiba que grupo de interese coincidiu.

Attribution Reporting API — Medición de conversión

Attribution Reporting substitúe os píxeles de conversión para un subconxunto de casos de uso de medición. Admite informes a nivel de evento (ruidosos, con perdas, por conversión) e informes de resumo agregados (acumulacións estatisticamente desviadas). A diferenza do píxel herdado, non expón o enlace individual usuario-a-conversión.

Shared Storage e Fenced Frames

Shared Storage é un almacén de clave-valor de escritura en calquera lugar, lectura en sandbox para casos de uso entre sitios como a limitación de frecuencia e a coherencia de experimentos A/B. Os Fenced Frames son iframes illados que evitan que a páxina circundante lea o anuncio renderizado ou os seus datos de interacción.

Require Privacy Sandbox consentimento?

Esta é a pregunta máis malentendida no panorama adtech de 2026, e a resposta é específica da xurisdición.

Baixo GDPR e ePrivacy

O Comité Europeo de Protección de Datos non emitiu unha posición global, pero as autoridades nacionais foron máis explícitas. O ICO do Reino Unido, o Garante italiano e a CNIL de Francia tomaron a posición de que Topics e Protected Audience requiren consentimento previo de opt-in onde procesan datos persoais, incluíndo calquera procesamento que escriba ou lea estado no dispositivo do usuario. A lóxica: o navegador aínda almacena localmente os temas de interese e os grupos de interese, e a chamada document.browsingTopics() transmite datos persoais inferidos a un terceiro. Isto está regulado baixo o artigo 5(3) da Directiva ePrivacy, que require consentimento para calquera acceso a ou almacenamento no equipo terminal do usuario máis alá do estritamente necesario para o servizo solicitado.

A posición de Google é máis permisiva — argumentan que as API están deseñadas para preservar a privacidade e que os requisitos de consentimento poderían non aplicarse en todos os contextos. Esta non é unha posición de regulador. Tratar Privacy Sandbox como exento de consentimento en Europa é unha postura de alto risco.

Baixo CCPA, CPRA e leis estatais de Estados Unidos

Nos Estados Unidos, os fluxos de Privacy Sandbox trátanse xeralmente como compartición de información persoal para publicidade comportamental entre contextos baixo CPRA. Iso significa que activan o dereito de exclusión e deben ser respectados a través dos sinais de Global Privacy Control e outros mecanismos universais de exclusión. O feito de que os datos de Topics se deriven do navegador en lugar de venderse dun intermediario de terceiros non os exime.

Os propios controis de Chrome

Chrome proporciona conmutadores visibles para o usuario en chrome://settings/adPrivacy para Topics, Protected Audience e Attribution Reporting. Estas opcións do usuario están xunto a — non en lugar de — o estado de consentimento do teu CMP. Un usuario que dixo non ás cookies publicitarias no teu banner pero si a Topics na configuración global de Chrome aínda che dixo non a través do banner. A túa pila debe respectar o máis estrito dos dous sinais.

A capa de consentimento que realmente necesitas

Unha pila de consentimento de nivel de produción de 2026 trata as API de Privacy Sandbox como actividades de procesamento distintas, cada unha controlada a través das finalidades IAB TCF ou categorías equivalentes de lei estatal.

Mapeo de API de Sandbox a finalidades de TCF

Mapeo a Google Consent Mode v2

Os sinais de Consent Mode v2 de Google mapéanse ao comportamento de Privacy Sandbox:

Xestión de sinais de estado de Estados Unidos

Para o tráfico dos Estados Unidos, a túa capa de consentimento debe inspeccionar Global Privacy Control e os sinais de exclusión de estado aplicables. Cando un usuario dos Estados Unidos se excluíu do compartimento, suprime document.browsingTopics(), non chames a joinAdInterestGroup e elimina as cabeceiras de rexistro de Attribution Reporting.

Patróns de implementación prácticos

Os editores que xa despregaron Privacy Sandbox xeralmente seguen un dos dous patróns arquitectónicos.

Patrón 1: Orquestración do lado do servidor

Un xestor de etiquetas propias na túa orixe recolle o estado de consentimento, a xurisdición do usuario e calquera substitución de sinais, logo renderiza condicionalmente os ganchos de Privacy Sandbox na páxina. O servidor de anuncios e o SSP reciben os indicadores de consentimento a través da solicitude de oferta, e deciden se chaman a Topics, Protected Audience ou ningún. Este patrón centraliza a lóxica e mantén o estado de consentimento como autoridade.

Patrón 2: Integración do wrapper de header bidding

Prebid.js e outros wrappers de header bidding agora admiten módulos de Privacy Sandbox. O wrapper le o sinal de consentimento, configura o comportamento de chamada de Topics e envía o resultado da poxa a través de Protected Audience cando se permite. Este enfoque é máis lixeiro de despregar, pero empuxa máis lóxica ao cliente e apreta a túa dependencia do ritmo de lanzamento do wrapper.

Que auditar

O que Privacy Sandbox non fai

Varios malentendidos comúns necesitan morrer antes de que presupuestes contra eles.

Non é un contorno do consentimento

As API reducen os datos persoais expostos aos anunciantes, pero non fan que o procesamento subxacente estea exento de consentimento baixo a lei europea. A teoría de cumprimento de que a adopción do Sandbox che permite saltar un CMP é incorrecta en todas as xurisdiciones EU/EEA.

Non é un substituto completo das cookies hoxe

Topics ofrece un sinal de segmentación groso e con perdas que xeralmente é máis débil que as audiencias baseadas en cookies. As escalas de reorientación de Protected Audience aínda están madurando. Attribution Reporting ten pisos de ruído de medición que poden ocultar pequenos incrementos de conversión. Un editor que move toda a monetización ao Sandbox hoxe debe esperar descensos de RPM do 10 ao 30 por cento con respecto a unha pila baseada en cookies no inventario típico.

Non é permanente na súa forma actual

A especificación de Privacy Sandbox aínda está en evolución. A taxonomía de Topics está en expansión, os límites de grupos de interese de Protected Audience están en revisión e a resposta regulatoria está en curso. Deseña a túa capa de consentimento para que sexa impulsada pola configuración, non codificada na especificación actual.

A postura correcta para 2026

Privacy Sandbox enténdese mellor como unha capa dunha estratexia sen cookies máis ampla, xunto con datos propios, audiencias definidas polo vendedor, segmentación contextual e header bidding do lado do servidor. Os editores que ganarán en 2026 serán os que traten o consentimento como o árbitro, non o obstáculo — alimentando API de Sandbox só onde a lei e a elección do usuario o permiten, volvendo limpiamente ao contextual en todo o demais e medindo os resultados en ambos camiños con ferramentas que non asumen a identidade.

A peor postura é a de agardar e ver. Os reguladores xa están escribindo a seguinte onda de regras — os compromisos de Sandbox da Competition and Markets Authority do Reino Unido, a orientación en curso da CNIL e as disposicións de creación de perfís da EU AI Act tocan todo este terreo. Os editores que constrúan Privacy Sandbox nunha pila de consentimento correctamente controlada en 2026 estarán preparados para esas regras. Os que o concretan como substituto de cookie de última hora descubrirán que están rescribindo baixo presión.

← Blog Ler todo →