Consent Mode v2 y Privacy Sandbox: qué queda después de 2025

Desde marzo de 2024, Consent Mode v2 es obligatorio para todos los anunciantes que usan Google Ads, remarketing o seguimiento de conversiones en el EEE y el Reino Unido. Sin un Consent Mode bien implementado, Google deja de publicar anuncios personalizados y desactiva las funciones de remarketing. Al mismo tiempo, en 2025 cambió el punto de partida de todo el sector del tracking: Google ha abandonado en sus partes centrales Privacy Sandbox, presentada durante años como sucesora de las cookies de terceros. Para las empresas B2B en Europa, esto plantea una tarea clara: medir conforme a la ley sin confiar en un futuro de las cookies que no va a llegar.

Este artículo analiza ambos desarrollos desde el punto de vista técnico y explica la configuración correcta de Consent Mode v2, el modelado de conversiones que hay detrás y las consecuencias para la medición del lado del servidor, las Core Web Vitals y la visibilidad ante los rastreadores de IA.

Por qué Consent Mode v2 y el fin de Privacy Sandbox van ahora de la mano

Los dos temas parecen separados, pero están relacionados. Consent Mode v2 regula cómo un anunciante transmite a Google el estado de consentimiento de un usuario. Privacy Sandbox debía aportar la base técnica sobre la que funcionaría la publicidad tras la desaparición de las cookies de terceros. Con el fin de estos planes, la realidad actual se mantiene, y es precisamente esa realidad la que hace tan importante Consent Mode v2.

Los datos son claros: según el HTTP Archive Web Almanac, el 61 % de todas las cookies de los sitios del top 1 millón son cookies de terceros, y en el top 1.000 incluso el 77 % (medición internacional). Casi el 100 % de estas cookies de terceros establecen el atributo SameSite=None para poder enviarse entre sitios. Esto muestra hasta qué punto el ecosistema publicitario sigue dependiendo precisamente de las cookies cuyo fin se anunció durante años.

A esto se suma la pérdida de consentimientos por los banners conformes a la ley. Un estudio de referencia de la región DACH (Alemania, Austria y Suiza) lo demuestra: con un diseño conforme a la ley se pierde de media alrededor del 60 % de los datos de visitas porque los usuarios rechazan (datos de Alemania/UE). Eso equivale a una tasa de aceptación de aproximadamente el 40 %. Quien mide en el EEE trabaja, por tanto, con datos estructuralmente incompletos, y Consent Mode v2 es la respuesta de Google precisamente a ese hueco.

Qué es Consent Mode v2 técnicamente: básico, avanzado y las cuatro señales

Consent Mode v2 es una interfaz que transmite el estado del consentimiento a las etiquetas de Google. En lugar de simplemente bloquear las etiquetas, Consent Mode adapta su comportamiento al estado. Existen dos variantes de implementación.

• Consent Mode básico: las etiquetas de Google solo se cargan después de que el usuario haya dado su consentimiento. Antes del consentimiento no se envía ningún dato a Google, ni siquiera pings sin cookies. Si el usuario rechaza, faltan los datos por completo y Google solo modela a partir de observaciones agregadas.
• Consent Mode avanzado: las etiquetas de Google se cargan desde el principio, pero si falta el consentimiento solo envían señales anónimas sin cookies y sin identificadores personales. Estos pings aportan los datos en los que se basa el modelado de conversiones. En cuanto el usuario da su consentimiento, las etiquetas pasan al modo de medición completo.

Cuatro señales controlan este comportamiento. ad_storage regula el uso de cookies publicitarias. analytics_storage controla las cookies de analítica, por ejemplo en Google Analytics 4. ad_user_data determina si se pueden enviar datos de usuario a Google con fines publicitarios. ad_personalization decide sobre la publicidad personalizada y el remarketing. Las dos últimas señales llegaron con la versión 2 y son la razón por la que el cambio se volvió obligatorio.

Técnicamente, el control funciona con dos comandos. Con el comando default se establece el estado inicial antes de que se dispare cualquier etiqueta. En el EEE, este default debe estar en denied para todas las categorías no necesarias. Con el comando update se actualiza el estado tras la decisión del usuario. El orden y el timing son decisivos: el comando default debe ejecutarse antes de que se carguen las etiquetas de Google; de lo contrario, una etiqueta se dispara antes de conocer el estado del consentimiento. En la práctica, suele ser una plataforma de gestión del consentimiento la que asume este control y transmite las señales a la etiqueta de Google o a Google Tag Manager.

Modelado de conversiones: cómo estima Google las conversiones que faltan

El modelado de conversiones es la verdadera utilidad del Consent Mode avanzado. Cuando un usuario rechaza, falta la atribución directa entre el clic en el anuncio y la conversión. Google llena ese hueco con un modelo estadístico que infiere las rutas no observables a partir de las rutas observables con consentimiento.

La magnitud la documenta la propia Google: de media, el modelado de conversiones de Consent Mode recupera más del 70 % de las rutas de clic en anuncio a conversión perdidas por falta de consentimiento de cookies (datos internacionales de Google, 2021). Importa la salvedad que Google menciona expresamente: los resultados varían mucho según la tasa de aceptación y la calidad de la implementación.

Aquí está justo el problema del B2B. El modelado necesita volumen. Google solo activa el modelado de conversiones en Consent Mode a partir de un volumen mínimo de clics en anuncios y de usuarios. Muchas cuentas B2B no llegan a ese volumen de datos: un proveedor de nicho con unos cientos de clics al mes queda por debajo. Para esas cuentas solo se aplica el modelo más general y menos preciso a nivel de Google.

La expectativa realista para el B2B de poco volumen es, por tanto: el modelado de conversiones no es un interruptor que garantice recuperar las conversiones perdidas. Funciona bien donde hay tráfico suficiente. Quien tiene poco volumen debería centrarse en una buena estrategia de datos propios y en la medición del lado del servidor, en lugar de confiar en el modelado.

Cómo interpretar bien el fin de Privacy Sandbox en 2025

La cronología importa, porque a menudo se presenta de forma simplificada. En abril de 2025, Google anunció que no introduciría en Chrome una ventana de selección propia para las cookies de terceros y que mantendría el modelo actual. En octubre de 2025 llegó el paso decisivo. Según el blog oficial de Privacy Sandbox, Google anunció que abandonaba una serie de tecnologías de Privacy Sandbox, entre ellas la Attribution Reporting API, Protected Audience y Topics, y que en Chrome mantendría el tratamiento actual de la elección sobre cookies de terceros (anuncio del 17 de octubre de 2025).

Un matiz importante para interpretarlo bien: Google abandona una lista concreta de tecnologías, no todas las funciones en bloque. Entre las que se retiran están Topics, Protected Audience, la Attribution Reporting API, Private Aggregation, IP Protection y Related Website Sets. Lo que queda en la práctica:

• Cookies de terceros en Chrome: no desaparecerán en un futuro previsible. El modelo actual se mantiene y no se ha anunciado ninguna ventana de selección nueva e independiente para las cookies.
• CHIPS (Cookies Having Independent Partitioned State): las cookies particionadas se mantienen como mecanismo y pueden usarse con independencia de las API retiradas.
• El marco legal: el RGPD y la normativa ePrivacy no cambian por la decisión de Google. El consentimiento sigue siendo obligatorio, sea cual sea la tecnología de navegador disponible.

La consecuencia para los anunciantes: los años de preparación para un futuro sin cookies basado en las API de Sandbox ya no sirven. En su lugar, el foco se desplaza de forma permanente al consentimiento, los datos propios y la arquitectura del lado del servidor. Las restricciones de los navegadores, como la Intelligent Tracking Prevention de Apple en Safari, que en Europa tiene alrededor del 20 % de cuota de mercado (datos de Europa; Chrome alrededor del 60 %, Edge alrededor del 7 %), siguen vigentes sin cambios.

RGPD, TKG 2021, TDDDG y el Ómnibus Digital de la UE

En Austria, el acceso a los dispositivos finales se rige por la Ley de Telecomunicaciones (TKG 2021), en concreto por su transposición de la Directiva ePrivacy. Las cookies que no son técnicamente necesarias y las tecnologías similares requieren un consentimiento previo y activo. En Alemania cumple la misma función, a través de su § 25, la ley antes conocida como TTDSG y hoy renombrada TDDDG. Ambas exigen el consentimiento explícito para todas las cookies no esenciales; seguir desplazándose por la página no basta.

La jurisprudencia austriaca subió aún más el listón en 2025. En una resolución del 13 de agosto de 2025, el Tribunal Administrativo Federal declaró ilegal un banner Pay-or-Okay global sin posibilidad de elección granular (resolución para Austria). El tribunal criticó que los usuarios no pudieran consentir o rechazar de forma granular fines de tratamiento concretos como la publicidad, la elaboración de perfiles y la analítica. En la práctica, esto significa que la granularidad no es opcional: es requisito para un consentimiento válido.

A nivel de la UE hay movimiento. Con la propuesta de Ómnibus Digital del 19 de noviembre de 2025, la Comisión Europea plantea un botón obligatorio de rechazo con un solo clic, una configuración centralizada de preferencias legible por máquina, por ejemplo en el navegador, y la supresión de los pop-ups de consentimiento para fines sin riesgo, como el simple recuento de visitas (propuesta de la Comisión Europea). Si la propuesta se convierte en ley, podría cambiar de forma notable el panorama de los banners. Hasta entonces, el marco actual, con un botón de rechazo equivalente y fines granulares, sigue vigente sin cambios.

Etiquetado del lado del servidor y datos propios como respuesta a la pérdida de señales

El etiquetado del lado del servidor, implementado normalmente como sGTM (Server-Side Google Tag Manager), es la respuesta técnica a las restricciones de los navegadores y a la pérdida de señales. En lugar de ejecutar las etiquetas en el navegador del usuario, el contenedor de etiquetas funciona en un servidor propio que recibe los datos, los procesa y los reenvía de forma controlada a los sistemas de destino.

La utilidad tiene varias capas:

• Mayor vida útil de las cookies: las cookies que el servidor establece en contexto first-party mediante la respuesta HTTP evitan los plazos cortos que ITP aplica a las cookies establecidas por JavaScript. Pero eso solo vale si Safari no clasifica el servidor de etiquetado como un tercero. Si ITP detecta un tercero a través del CNAME o de la dirección IP, limita también las cookies establecidas en el servidor a 7 días. Un sGTM en un subdominio que apunta por CNAME a un proveedor cloud externo suele entrar en este caso. Si el servidor de etiquetado funciona en el mismo rango de IP que el sitio web, estabiliza la medición en Safari.
• Control de los datos antes de compartirlos: en el servidor se pueden filtrar, recortar o seudonimizar los campos personales antes de que los datos lleguen a terceros. Esto favorece la minimización de datos en el sentido del RGPD.
• Conversiones mejoradas: los datos propios cifrados con hash, como las direcciones de correo electrónico, se transmiten de forma segura desde el servidor y mejoran la atribución de conversiones, siempre que exista un consentimiento válido.

Hay que delimitarlo bien: el etiquetado del lado del servidor no es una forma de eludir el consentimiento. Cambia la arquitectura de los flujos de datos, no la base jurídica. Quien mide en el servidor sin consentimiento infringe la TKG y el RGPD igual que en el lado del cliente. Así que sGTM mejora la calidad y el control de los datos, pero nunca sustituye al consentimiento.

CMP e IAB TCF: obligatorios para editores, a elección de los anunciantes

Para los anunciantes, Google no exige una plataforma de gestión del consentimiento certificada. Consent Mode v2 también se puede implementar con una configuración propia de gtag o Tag Manager, siempre que default y update se transmitan correctamente. Una CMP certificada por Google con IAB Transparency and Consent Framework (TCF) solo es obligatoria para los editores que publican anuncios personalizados en el EEE, el Reino Unido y Suiza a través de AdSense, Ad Manager o AdMob. Según Google, los anunciantes son libres de usar también una CMP que no forme parte del programa de partners de Consent Mode. Aun así, una CMP partner compensa: registra el consentimiento, lo almacena de forma demostrable y transmite de forma fiable las cuatro señales a Consent Mode.

Al elegir e integrar una CMP cuentan tres puntos:

• Entender bien la certificación: los editores con AdSense, Ad Manager o AdMob eligen de la lista de proveedores certificados de Google. Los anunciantes, en cambio, comprueban si la CMP transmite las cuatro señales de Consent Mode. La lista de partners de Google es un buen punto de partida para ello.
• Conexión correcta con Consent Mode: la CMP debe poner las señales default en denied antes de que se carguen las etiquetas y enviar un update tras la decisión del usuario. Este encadenamiento es el punto de fallo más frecuente.
• Reflejar fines granulares: el TCF trabaja con fines y proveedores definidos. La interfaz del banner debe mostrarlos de forma granular para que el consentimiento resista el criterio de la jurisprudencia austriaca.

Efectos en los rastreadores de IA y el GEO

Además de la medición, las configuraciones de consentimiento y tracking influyen en la visibilidad ante rastreadores de IA como GPTBot, ClaudeBot y PerplexityBot. El mecanismo es técnico y es fácil pasarlo por alto.

En un punto clave, los rastreadores de IA se comportan como los bots de los buscadores clásicos: no cierran banners de cookies ni dan su consentimiento. Quien oculta contenido detrás de un muro de cookies o carga bloques de texto centrales con JavaScript solo después del consentimiento corre el riesgo de que ese contenido sea invisible para los sistemas de IA. De ahí se derivan tres principios para el GEO:

• No vincular el contenido al consentimiento: el texto editorial, las definiciones y el contenido especializado van en el HTML inicial, no en scripts que solo se ejecutan tras la aceptación. Solo el tracking y las etiquetas de marketing van detrás del consentimiento.
• Evitar los muros de cookies: un muro de cookies estricto que bloquea todo el contenido perjudica a la indexación clásica y también a la visibilidad en IA. Además, es jurídicamente controvertido.
• Priorizar el renderizado del lado del servidor: el contenido renderizado en el servidor es accesible con independencia del consentimiento y del JavaScript del lado del cliente. En arquitecturas Next.js, es la base más sólida para rastreadores de IA y respuestas de IA.

La separación está clara: la medición, detrás del consentimiento; el contenido, delante. Quien mezcla ambas cosas pierde visibilidad justo en los canales que, en el B2B, deciden cada vez más quién aparece y quién no.

Core Web Vitals: scripts de consentimiento en la ruta crítica

Los scripts de cookies y consentimiento se ejecutan, por naturaleza, pronto y de forma bloqueante, porque el banner debe aparecer antes de cualquier interacción. Eso los convierte en un riesgo para las Core Web Vitals. Un script de CMP pesado retrasa el renderizado y afecta especialmente a dos métricas.

• LCP (Largest Contentful Paint): un script de consentimiento que bloquea el renderizado retrasa el contenido visible más grande. Si el banner se superpone al contenido principal, puede convertirse él mismo en el elemento LCP y empeorar la medición.
• INP (Interaction to Next Paint): una lógica de CMP extensa bloquea el hilo principal y retrasa la respuesta a la primera interacción del usuario, por ejemplo el clic en Aceptar o Rechazar.

Las contramedidas prácticas son mantener el script de la CMP lo más ligero posible, cargarlo de forma asíncrona cuando la lógica lo permita y evitar desplazamientos de diseño reservando espacio para el banner, de modo que el valor de CLS se mantenga estable. Las soluciones de analítica sin cookies y respetuosas con la privacidad, con un script ligero, reducen aún más la carga y ofrecen una perspectiva de medición agregada que no requiere consentimiento.

Errores frecuentes en la implementación

Los errores típicos se repiten y suelen corregirse con un esfuerzo razonable.

• Default en granted en el EEE: si el estado por defecto no se pone en denied, las etiquetas se disparan antes del consentimiento con tracking completo. Es la infracción más grave y la más frecuente.
• Falta la señal de update: el comando default existe, pero falta el update tras la decisión del usuario. Entonces el estado se queda en denied de forma permanente, y tampoco se mide por completo a los usuarios que han dado su consentimiento.
• Orden incorrecto: el snippet de Consent Mode se carga después de las etiquetas de Google. En ese caso, una etiqueta se dispara antes de que se conozca el estado.
• Botón de rechazo no equivalente: un botón de aceptar en color junto a un enlace gris para rechazar se considera nudging no permitido y pone en riesgo la validez del consentimiento.
• Contenido detrás del consentimiento: el texto editorial solo se carga después de la aceptación y, por eso, desaparece para los rastreadores de buscadores y de IA.
• CMP no certificada en editores: quien publica anuncios personalizados a través de AdSense, Ad Manager o AdMob y usa para ello una CMP sin certificación de Google o sin un TCF actualizado incumple el requisito de Google para editores. Para los anunciantes con Consent Mode, una CMP certificada no es obligatoria.

Métricas, medición y depuración

La eficacia de una configuración de Consent Mode v2 debe comprobarse y supervisarse activamente. Un banner configurado una vez no demuestra que funcione correctamente.

• Comprobar Tag Assistant y el estado del consentimiento: con Google Tag Assistant se puede ver qué señales de consentimiento están establecidas y si default se dispara antes que update. En el caso ideal, el modo de depuración muestra el cambio de estado de denied a granted tras la aceptación.
• Supervisar las conversiones modeladas: en Google Ads y GA4 conviene observar las conversiones modeladas como una magnitud propia. Una caída repentina indica una configuración rota.
• La tasa de consentimiento como indicador: la propia tasa de aceptación es una métrica de control. Con una tasa típica en torno al 40 %, ayuda a dimensionar los datos disponibles y a evaluar el diseño del banner.
• Evaluar los umbrales con realismo: sobre todo las cuentas B2B de poco volumen deberían comprobar si hay suficiente volumen para el modelado de conversiones, en lugar de interpretar los valores modelados sin espíritu crítico.
• Tendencias en lugar de valores absolutos: como los datos son incompletos de forma sistemática, la evolución relativa a lo largo del tiempo dice más que las cifras absolutas.

Para profundizar

Consent Mode v2 y el fin de Privacy Sandbox marcan el mismo punto de inflexión: el futuro de la medición no está en una tecnología de navegador sin cookies, sino en el consentimiento, los datos propios y la arquitectura del lado del servidor. Para las empresas B2B en Europa, esto deja un orden claro. Primero, un banner granular con un botón de rechazo equivalente y una CMP que almacene los consentimientos de forma demostrable. Después, una configuración limpia de Consent Mode v2 con default en denied y un update correcto. Sobre esa base, etiquetado del lado del servidor y conversiones mejoradas donde el volumen y el consentimiento lo permitan. Y, en todo momento, la separación entre contenido y medición, para que buscadores y rastreadores de IA vean el contenido mientras el tracking solo se ejecuta tras la aceptación. Quien aplica esta cadena con coherencia mide con seguridad jurídica y sigue siendo visible, venga o se vaya la tecnología de navegador que sea.