Los bloqueadores de anuncios bloquean el seguimiento y también los banners de consentimiento de cookies

Los bloqueadores de anuncios pueden impedir que los scripts de la CMP se carguen por completo. Cuando se bloquea una Plataforma de Gestión del Consentimiento (CMP), el banner de consentimiento no aparece y el estado de consentimiento del usuario nunca se registra, y las etiquetas dependientes de Consent Mode V2 se disparan en un estado indefinido. Esto crea tanto una brecha de cumplimiento del GDPR como una brecha de medición.

Este artículo cubre lo que ocurre técnicamente, lo que exigen los organismos encargados de hacer cumplir el GDPR, y cómo el GTM server-side con alojamiento CMP de primera parte elimina la vulnerabilidad.

¿Qué ocurre cuando un bloqueador de anuncios bloquea tu banner de consentimiento?

La secuencia comienza con el script del CMP. La mayoría de los CMP (como Cookiebot, OneTrust o Quantcast) entregan ese script desde una CDN de terceros. Cada proveedor utiliza dominios CDN que son conocidos públicamente, consistentes en miles de implementaciones y actualizados en calendarios predecibles.

Esa coherencia es lo que las hace targetizables. Las listas de filtros funcionan comparando los destinos de las solicitudes con dominios conocidos. Un dominio CDN que aparece en miles de sitios es exactamente el tipo de patrón estable que buscan los mantenedores de listas de filtros. EasyPrivacy, los filtros de privacidad de uBlock Origin y varios bloqueadores nativos del navegador ya incluyen dominios CDN CMP comunes.

Cuando un visitante con uno de esos bloqueadores activos entra en una página, el navegador solicita el script CMP. El bloqueador lo intercepta. El script nunca se carga. La página se muestra sin un banner de consentimiento.

El visitante ve la página normalmente. Nada parece roto. Por parte del sitio, no hay ningún estado de consentimiento registrado para esa sesión.

Lo que ocurra a continuación depende de cómo gestione la configuración de la etiqueta una señal de consentimiento ausente:

• Las etiquetas configuradas con Consent Mode V2 esperan una señal que nunca llega.
• Las etiquetas con valores por defecto funcionan con los valores por defecto que se hayan establecido.
• Las etiquetas sin configuración de consentimiento explícito pueden disparar sin base legal.

En los tres casos, nunca se mostró al usuario una pancarta. No hay constancia de ninguna decisión.

Qué hace Consent Mode V2 cuando el consentimiento no está definido

Consent Mode V2 de Google controla el comportamiento de las etiquetas mediante estados de señal por categoría:

analytics_storage, ad_storage y ad_personalization. Cada categoría se establece como concedida o denegada. Las etiquetas esperan la señal correspondiente antes de actuar.

Cuando el CMP está bloqueado, no se dispara ninguna señal. La etiqueta no recibe denegado y retiene. No recibe concedido y no se dispara. Pasa a su estado por defecto, una configuración que vive en el contenedor GTM, normalmente dentro de una plantilla de etiqueta o de un bloque de inicialización.

Algunas configuraciones omiten por completo los valores predeterminados explícitos. Se supone que el CMP se carga rápido y lanza una señal antes de que actúe cualquier etiqueta. Esa suposición funciona cuando se carga el CMP.

El comportamiento de la plataforma en el caso indefinido no suele ser el que esperan los equipos:

• GA4: un estado indefinido puede permitir el paso de señales de modelado.
• Etiquetas publicitarias: el disparo parcial en un estado indefinido puede registrar un evento que alimente la atribución.
• Algunas plantillas de etiquetas: la ausencia de una denegación explícita se trata como concedida.

El resultado son datos de medición que no pueden atribuirse a un registro de consentimiento verificado.

Por qué esto es un problema de cumplimiento del GDPR, no sólo un problema de UX

El artículo 7 del RGPD hace recaer la carga de la prueba en el responsable del tratamiento. El consentimiento debe ser libre, específico, informado e inequívoco. En caso de impugnación, el responsable del tratamiento debe poder demostrar que se dio el consentimiento, con registros, para esa sesión.

Un CMP bloqueado deja al responsable del tratamiento sin pruebas: sin registro de la presentación del banner, sin registro de la respuesta del usuario. Tres organismos de control de la UE han abordado esta cuestión directamente:

1. La DPA holandesa (Autoriteit Persoonsgegevens) ha declarado que el rastreo sin un registro de consentimiento válido infringe el GDPR, independientemente de la causa del fallo del mecanismo de consentimiento. Los fallos técnicos en el flujo de consentimiento no transfieren la responsabilidad al responsable del tratamiento. (Fuente: autoriteitpersoonsgegevens.nl)
2. La CNIL francesa ha publicado orientaciones según las cuales debe recabarse el consentimiento antes de procesar cualquier dato personal, y las organizaciones son responsables de garantizar que sus mecanismos de consentimiento funcionen realmente. Las etiquetas que se disparan en un estado de retroceso indefinido quedan fuera de esa norma. (Fuente: cnil.fr)
3. La DSK (Datenschutzkonferenz) alemana ha reforzado que el tratamiento dependiente del consentimiento debe ser verificable y reproducible. Las sesiones que se llevan a cabo sin un registro del consentimiento no cumplen ese requisito. (Fuente: datenschutzkonferenz-online.de)

Los tres organismos han citado la fiabilidad del flujo de consentimiento en casos de aplicación activa.

La única forma de garantizar el cumplimiento es no enviar nada por defecto. Es un camino de oro en el mercado del seguimiento y la analítica, pero junto con los bloqueadores de anuncios, puede causar un daño real a tus datos.

La pérdida de datos, y a quién afecta realmente

El camino conforme tiene un coste real. Las sesiones en las que se bloqueó el CMP no generan datos de atribución, ni señales de conversión para las plataformas publicitarias, ni eventos GA4.

La escala depende de la audiencia. Aproximadamente el 30% de los usuarios de Internet de todo el mundo utilizan algún tipo de bloqueador de anuncios (GWI, 2025). Para las audiencias técnicas (desarrolladores, vendedores, profesionales del análisis) el porcentaje es mayor.

La mayoría de esos usuarios no bloquean la medición intencionadamente. La investigación de GWI de 2025 muestra que sólo el 26,6% de los usuarios de bloqueadores de anuncios a nivel mundial citan "detener la recopilación de datos" como razón para utilizar uno. La mayoría (63,5%) dice que hay demasiados anuncios. Otro 53,5% dice que los anuncios interfieren en la navegación, según Backlinko, 2025.

Esta distinción es importante. La mayoría de los usuarios que tienen instalado un bloqueador de anuncios no están optando por la analítica. Quieren menos anuncios y cargas de página más rápidas. Si les llega un banner de consentimiento, muchos lo aceptarán, y sus datos fluirán con una base legal.

Las sesiones que permanecen oscuras son aquellas en las que el banner nunca apareció, no porque el usuario lo rechazara, sino porque el mecanismo de consentimiento falló silenciosamente.

Arreglar la entrega CMP recupera esas sesiones.

Cómo GTM server-side elimina la vulnerabilidad del banner de consentimiento

La raíz del problema es dónde está alojado el script CMP. Una CDN de terceros tiene un dominio fijo y conocido. Ese dominio aparece en las listas de filtros. Cualquier CMP enviado desde una CDN conocida es un objetivo estable.

Alojar el script CMP en un subdominio propio cambia eso. El subdominio pertenece al sitio. No aparece en las listas de filtros genéricas dirigidas a proveedores de CMP. Un bloqueador no puede enfrentarse a él sin bloquear también los propios activos de origen del sitio, que la mayoría de las listas de filtros evitan específicamente.

Cuando el navegador solicita el script CMP desde un dominio que el sitio controla, el script se carga. Se muestra el banner. El usuario ve el aviso, y se emite una señal de consentimiento antes de que se haya disparado ninguna etiqueta.

Se trata del mismo principio de infraestructura descrito en el artículo Por qué el seguimiento server-side puede seguir perdiendo datos (y cómo lo soluciona el script de seguimiento mejorado). Allí, mover la solicitud de seguimiento a un punto final de primera parte impedía que los bloqueadores la compararan con patrones CDN de análisis conocidos. Aplicado a la capa de consentimiento, la misma configuración server-side protege una pieza diferente: el CMP llega al navegador en lugar de ser interceptado antes de que pueda aparecer el banner.

La GTM server-side puede gestionar la entrega de CMP como parte de una configuración first-party más amplia. Cuando el script CMP se sirve desde el mismo subdominio que el contenedor del servidor, la señal de consentimiento llega al contenedor antes de que se dispare ninguna etiqueta de medición o publicidad.

El panel TAGGRS puede ayudar a verificar que esto funciona. En los análisis server-side, comprueba si las etiquetas de consentimiento se disparan en sesiones sin ninguna solicitud CMP registrada. Ese patrón, eventos activos pero sin llamada CMP visible, significa que el banner de consentimiento no está llegando a parte de la audiencia.

Qué requiere una configuración de consentimiento resistente

1. Aloja el script CMP en un subdominio de origen. Elimina el dominio CDN fijo de la ecuación. Las listas de filtros no pueden bloquear silenciosamente un subdominio que el sitio controla.

2. Establece el Consent Mode V2 explícito por defecto para todas las regiones. Cada etiqueta del contenedor debe tener un comportamiento definido para el caso de que no se haya disparado ninguna señal de consentimiento. Ninguna etiqueta debe funcionar en un estado de retroceso indefinido.

3. Dispara primero las etiquetas banner de consentimiento en el contenedor GTM. Configura el bloque de inicialización del consentimiento para que se ejecute antes de cualquier medición o etiqueta publicitaria. La señal debe existir antes de que nada actúe sobre ella.

4. Verifícalo a través del panel TAGGRS. Comprueba que las etiquetas de consentimiento no se disparan en sesiones en las que no se registra ninguna solicitud de CMP. Detecta las lagunas antes de que aparezcan en una auditoría.

5. Documenta la arquitectura del consentimiento. Registra el proveedor de CMP, la ruta de alojamiento y los estados predeterminados explícitos para cada región y categoría de etiqueta. Cuando un regulador solicita pruebas, la documentación es lo primero que produce un controlador.

PREGUNTAS FRECUENTES

¿Los bloqueadores de anuncios pueden bloquear cualquier CMP, o sólo plataformas específicas?

Cualquier CMP que entregue su script desde una CDN de terceros está expuesto. Las instalaciones por defecto de Cookiebot, OneTrust y Quantcast cargan el script desde la propia infraestructura del proveedor. Los CMP que admiten el alojamiento de origen como opción de configuración no se ven afectados intrínsecamente, pero la función debe estar activada de forma activa.

¿Cómo puedo saber si mi banner de consentimiento está siendo bloqueado para algunos visitantes?

La señal más clara es un desajuste entre el volumen de solicitudes del server-side y las entradas del registro de consentimiento del CMP. Si el contenedor del servidor recibe solicitudes en sesiones en las que no aparece ninguna señal de consentimiento en los registros del CMP, es probable que el banner no se haya cargado para esos usuarios. El panel TAGGRS lo hace visible a través de las categorías de solicitudes. También puedes probarlo directamente habilitando una lista de filtros comunes en un navegador y comprobando si se carga tu propio banner de consentimiento.

¿Es suficiente establecer el Consent Mode V2 por defecto en "denegado" para seguir cumpliendo la GDPR cuando se bloquea un CMP?

Maneja correctamente el comportamiento de las etiquetas, pero no soluciona el problema de fondo. Establecer los valores por defecto como denegados significa que las etiquetas no se dispararán en el estado indefinido, que es la configuración correcta. Lo que no puede hacer es mostrar a los usuarios un banner que nunca se les dio. Un regulador que pida ver pruebas del consentimiento para una sesión concreta no las encontrará. Los valores predeterminados abordan el cumplimiento en la capa de etiquetas. El alojamiento CMP de primera parte aborda el cumplimiento en la capa de recogida del consentimiento.

¿Cuál es la diferencia entre un banner de consentimiento bloqueado y aquello contra lo que protege el Script de Seguimiento Mejorado?

El Script de Seguimiento Mejorado protege la solicitud de seguimiento una vez recogido el consentimiento. Evita que los bloqueadores de anuncios intercepten el evento navegador-servidor antes de que llegue al contenedor del servidor. Un banner de consentimiento bloqueado es un paso anterior: al usuario nunca se le mostró una solicitud, nunca se registró ninguna señal de consentimiento, y cualquier etiqueta que se disparó lo hizo sin una base legal. Los dos problemas comparten la misma solución de infraestructura (entrega de primera parte), pero se sitúan en puntos diferentes del flujo de datos. El Script de Seguimiento Mejorado de TAGGRS es una herramienta perfecta para ocultar el CMP de los adblockers y cargar correctamente un banner de cookies a través del contenedor GTM del servidor.