Chrome Privacy Sandbox y la API Topics: La guía del editor de 2026 sobre consentimiento, segmentación y medición
Durante la mayor parte de la última década, la publicidad digital funcionó bajo un supuesto simple: las cookies de terceros siempre estarían ahí, transportando silenciosamente identificadores de usuario a través de la web. Ese supuesto ya está roto. La ruta de deprecación de Chrome ha cambiado varias veces, pero la dirección del viaje no: el seguimiento entre sitios mediante la cookie de terceros está llegando a su fin, y el Privacy Sandbox de Google es el reemplazo que Chrome quiere que editores y anunciantes adopten. El Sandbox no es un producto único. Es un conjunto de API del navegador — Topics, Protected Audience, Attribution Reporting, Fenced Frames, Shared Storage y más — cada una reemplazando un caso de uso específico que antes cubrían las cookies. Para un editor, la parte difícil no es entender las API individualmente. Es construir una capa de consentimiento y un camino de monetización que mantenga los flujos de Privacy Sandbox, el cumplimiento del GDPR y la ley de privacidad estatal todos alineados simultáneamente. Esta guía recorre las piezas en movimiento en 2026 y cómo debe verse su pila de consentimiento.
Qué reemplaza realmente el Privacy Sandbox
Las cookies de terceros llevaban cuatro funciones publicitarias distintas: segmentación basada en intereses, retargeting, medición de conversiones y limitación de frecuencia. El Privacy Sandbox las divide en API separadas, cada una con su propio perfil de consentimiento.
Topics API — Segmentación Basada en Intereses
La API Topics asigna a cada navegador un pequeño conjunto de temas de interés de grano grueso — alrededor de cinco temas por semana, extraídos de una taxonomía curada de unos pocos cientos de categorías. Cuando un editor llama a document.browsingTopics(), el navegador devuelve hasta tres temas que el ecosistema de tecnología publicitaria puede usar para personalización contextual sin ningún identificador entre sitios. Los temas se calculan localmente, se almacenan en el dispositivo, rotan semanalmente y están sujetos a controles de usuario en chrome://settings/adPrivacy.
Protected Audience API — Retargeting y Remarketing
Protected Audience, anteriormente FLEDGE, mantiene el retargeting activo sin un identificador compartido entre sitios. Los anunciantes incorporan a un usuario en un grupo de interés en su propio sitio; cuando el usuario visita un editor participante, una subasta en el dispositivo se ejecuta en un Fenced Frame y selecciona un creativo. El anuncio ganador se renderiza sin que el editor sepa qué grupo de interés coincidió.
Attribution Reporting API — Medición de Conversiones
Attribution Reporting reemplaza los píxeles de conversión para un subconjunto de casos de uso de medición. Admite informes a nivel de evento (ruidosos, con pérdidas, por conversión) y informes de resumen agregados (resúmenes estadísticamente corregidos). A diferencia del píxel heredado, no expone el enlace individual usuario-conversión.
Shared Storage y Fenced Frames
Shared Storage es un almacén de clave-valor que se puede escribir desde cualquier lugar y leer dentro del sandbox para casos de uso entre sitios como la limitación de frecuencia y la consistencia de experimentos A/B. Los Fenced Frames son iframes aislados que impiden que la página circundante lea el anuncio renderizado o sus datos de interacción.
¿Requiere consentimiento el Privacy Sandbox?
Esta es la pregunta más malentendida en el panorama del ad tech de 2026, y la respuesta es específica por jurisdicción.
Bajo el GDPR y ePrivacy
El Comité Europeo de Protección de Datos EDPB no ha emitido una posición general, pero las autoridades nacionales han sido más explícitas. La ICO del Reino Unido, el Garante italiano y la CNIL francesa han adoptado la postura de que Topics y Protected Audience requieren consentimiento previo opt-in donde procesan datos personales, incluido cualquier procesamiento que escriba o lea el estado en el dispositivo del usuario. La lógica: el navegador aún almacena localmente temas de interés y grupos de interés, y la llamada a document.browsingTopics() transmite datos personales inferidos a un tercero. Eso está regulado bajo el Artículo 5(3) de la Directiva ePrivacy, que requiere consentimiento para cualquier acceso o almacenamiento en el equipo terminal del usuario más allá de lo estrictamente necesario para el servicio solicitado.
La posición de Google es más permisiva — argumentan que las API son de privacidad por diseño y que los requisitos de consentimiento pueden no aplicarse en todos los contextos. Esta no es una posición regulatoria. Tratar el Privacy Sandbox como exento de consentimiento en Europa es una postura de alto riesgo.
Bajo CCPA, CPRA y Leyes Estatales de EE. UU.
En los Estados Unidos, los flujos de Privacy Sandbox generalmente se tratan como compartición de información personal para publicidad conductual entre contextos bajo la CPRA. Eso significa que activan el derecho de exclusión voluntaria y deben ser respetados a través de señales de Global Privacy Control y otros mecanismos universales de exclusión. El hecho de que los datos de Topics sean derivados por el navegador en lugar de vendidos por un intermediario tercero no los exime.
Los Propios Controles de Chrome
Chrome proporciona conmutadores orientados al usuario en chrome://settings/adPrivacy para Topics, Protected Audience y Attribution Reporting. Estas opciones del usuario se encuentran junto a — no en lugar de — el estado de consentimiento de su CMP. Un usuario que ha dicho no a las cookies de publicidad en su banner pero sí a Topics en la configuración global de Chrome aún le ha dicho no a través del banner. Su pila debe respetar el más estricto de las dos señales.
La Capa de Consentimiento que Realmente Necesita
Una pila de consentimiento de 2026 de grado de producción trata las API del Privacy Sandbox como actividades de procesamiento diferenciadas, cada una controlada mediante propósitos IAB TCF o categorías equivalentes de ley estatal.
Mapeo de API del Sandbox a Propósitos TCF
- Topics API — IAB TCF Propósito 2 (Seleccionar anuncios básicos) y Propósito 3 (Crear un perfil de anuncios personalizado) como mínimo; Propósito 4 (Seleccionar anuncios personalizados) si los temas alimentan la segmentación.
- Protected Audience — Propósito 3 y 4, más Propósito 7 (Medir el rendimiento de los anuncios) si la subasta usa datos de resultados.
- Attribution Reporting — Propósito 7 (Medir el rendimiento de los anuncios) y Propósito 9 (Comprender audiencias a través de estadísticas).
- Shared Storage para limitación de frecuencia — Propósito 3 donde alimenta la personalización, o una base de interés legítimo donde es puramente control de frecuencia.
Mapeo a Google Consent Mode v2
Las señales de Google Consent Mode v2 se mapean al comportamiento del Privacy Sandbox:
- ad_storage denegado — deshabilitar completamente las llamadas a las API Topics y Protected Audience
- ad_user_data denegado — bloquear que Attribution Reporting envíe datos de alcance de usuario
- ad_personalization denegado — omitir entradas de Topics en la lógica de segmentación
Manejo de Señales de Estado de EE. UU.
Para el tráfico de EE. UU., su capa de consentimiento debe inspeccionar el Global Privacy Control y las señales de exclusión voluntaria estatales aplicables. Cuando un usuario de EE. UU. ha optado por no compartir, suprima document.browsingTopics(), no llame a joinAdInterestGroup y elimine los encabezados de registro de Attribution Reporting.
Patrones de Implementación Prácticos
Los editores que ya han lanzado el Privacy Sandbox generalmente siguen uno de dos patrones arquitectónicos.
Patrón 1: Orquestación del Lado del Servidor
Un administrador de etiquetas de primera parte en su origen recopila el estado de consentimiento, la jurisdicción del usuario y cualquier anulación de señal, luego renderiza condicionalmente los hooks de Privacy Sandbox en la página. El servidor de anuncios y el SSP reciben indicadores de consentimiento a través de la solicitud de puja, y deciden si llamar a Topics, Protected Audience o ninguno. Este patrón centraliza la lógica y mantiene el estado de consentimiento autoritativo.
Patrón 2: Integración de Wrapper de Header Bidding
Prebid.js y otros wrappers de header bidding ahora admiten módulos de Privacy Sandbox. El wrapper lee la señal de consentimiento, configura el comportamiento de llamada de Topics y reenvía el resultado de la subasta a través de Protected Audience cuando está permitido. Este enfoque es más ligero de implementar pero empuja más lógica al cliente y estrecha su dependencia del ritmo de lanzamiento del wrapper.
Qué Auditar
- Confirme que
document.browsingTopics()no se llama a menos que el consentimiento de publicidad del CMP sea afirmativo y no haya señal de exclusión voluntaria presente - Confirme que
joinAdInterestGroupyrunAdAuctionestán controlados por las mismas condiciones - Confirme que los encabezados de registro de Attribution Reporting solo se envían en respuestas para usuarios cuyo estado de consentimiento permite la medición
- Confirme que su lista de proveedores en la cadena TCF aún coincide con los SSP y DSP que usan API del Sandbox en su inventario
- Confirme que su política de privacidad describe Topics, Protected Audience y Attribution Reporting como actividades de procesamiento diferenciadas, con base legal y retención
Lo que No Hace el Privacy Sandbox
Varios conceptos erróneos comunes deben desaparecer antes de presupuestar contra ellos.
No Es un Atajo para Evitar el Consentimiento
Las API reducen los datos personales expuestos a los anunciantes, pero no hacen que el procesamiento subyacente esté exento de consentimiento bajo la ley europea. La teoría de cumplimiento de que la adopción del Sandbox le permite omitir un CMP es incorrecta en cada jurisdicción EU/EEA.
Hoy No Es un Reemplazo Completo de las Cookies
Topics ofrece una señal de segmentación gruesa y con pérdidas que típicamente es más débil que las audiencias basadas en cookies. Las escalas de retargeting de Protected Audience aún están madurando. Attribution Reporting tiene niveles mínimos de ruido de medición que pueden ocultar pequeños incrementos de conversión. Un editor que mueva toda la monetización al Sandbox hoy debería esperar caídas de RPM del 10-30 por ciento con respecto a una pila basada en cookies en inventario típico.
No Es Permanente en su Forma Actual
La especificación del Privacy Sandbox aún está evolucionando. La taxonomía de Topics se está expandiendo, los límites de grupos de interés de Protected Audience están bajo revisión y la respuesta regulatoria continúa. Diseñe su capa de consentimiento para que esté controlada por configuración, no codificada de forma rígida a la especificación actual.
La Postura Correcta para 2026
El Privacy Sandbox se entiende mejor como una capa de una estrategia sin cookies más amplia, junto con datos de primera parte, audiencias definidas por el vendedor, segmentación contextual y header bidding del lado del servidor. Los editores que ganen en 2026 serán aquellos que traten el consentimiento como el árbitro, no el obstáculo — alimentando las API del Sandbox solo donde la ley y la elección del usuario lo permitan, recayendo limpiamente en lo contextual en cualquier otro lugar y midiendo resultados en ambas rutas con herramientas que no asumen identidad.
La peor postura es la de esperar y ver. Los reguladores ya están escribiendo la próxima ola de normas — los compromisos de Sandbox de la UK Competition and Markets Authority, la orientación continua de la CNIL y las disposiciones de perfilado del EU AI Act todas tocan este terreno. Los editores que construyan el Privacy Sandbox en una pila de consentimiento correctamente controlada en 2026 estarán listos para esas normas. Los que lo añadan como sustituto de última hora de las cookies se encontrarán reescribiendo bajo presión.