Consent Mode v2: cómo implementarlo sin perder datos

Muchas cuentas de Google Ads y GA4 llevan meses reportando la mitad de las conversiones reales sin que nadie lo note. La causa no siempre es una campaña floja: es un banner de cookies mal integrado con Consent Mode v2 que corta el envío de datos a Google sin activar el modelado que debería recuperarlos.

Esta guía técnica explica qué es Consent Mode v2, qué se pierde exactamente cuando no se implementa (o se implementa mal), cómo instalarlo en Google Tag Manager en modo básico y avanzado, cómo encaja con la guía de cookies de la AEPD y qué pasos concretos permiten verificar en vivo que las señales de consentimiento llegan a Google. El foco es medición real, no cumplimiento decorativo.

Resumen

Consent Mode v2 es la capa técnica que traduce las decisiones del usuario sobre cookies a comportamientos concretos de las etiquetas de Google. No sustituye al banner, sino que lo escucha: cuando un usuario acepta o rechaza, el consent state se propaga a GA4, Google Ads y Floodlight, que se comportan de una u otra forma según lo que hayan recibido. Sin él, dos cosas se rompen a la vez: Google Ads deja de recibir señales de conversión para Smart Bidding y GA4 pierde el modelado que rellena los huecos de los usuarios que rechazan. La implementación correcta se apoya en tres pilares: un CMP certificado por Google que emita eventos al dataLayer, la etiqueta de configuración de Consent Mode en GTM disparándose antes que cualquier otra etiqueta de Google, y una verificación real en Tag Assistant que confirme que las cuatro señales de consentimiento (analytics_storage, ad_storage, ad_user_data, ad_personalization) llegan correctamente.

Qué se pierde realmente sin Consent Mode v2

Sin Consent Mode v2 correctamente configurado, cada usuario que rechaza cookies desaparece por completo del sistema de medición: ni GA4 registra su sesión, ni Google Ads recibe la conversión asociada a su clic, ni el modelado de comportamiento tiene datos con los que rellenar el hueco. Un ratio de rechazo del 40-60% —normal en tráfico europeo— se traduce entonces en una infravaloración similar de resultados, con el agravante de que Smart Bidding empieza a optimizar contra datos incompletos.

El impacto no es solo estadístico. Google Ads utiliza el volumen de conversiones observadas para calibrar sus algoritmos de puja automática; cuando ese volumen cae por debajo del umbral de aprendizaje, las campañas entran en modo exploratorio y el CPA sube sin que la calidad del tráfico haya cambiado. Muchos diagnósticos de «campaña que se rompió sin explicación» son en realidad diagnósticos de un consent mode mal puesto.

La diferencia entre tener bien puesto Consent Mode v2 o no tenerlo se ve en tres métricas concretas: conversiones totales atribuidas a Google Ads, usuarios activos en GA4 y coincidencia entre GA4 y el backend/CRM. Las tres se degradan a la vez cuando el consent state no llega, y las tres se recuperan a la vez cuando el modelado empieza a funcionar tras unas semanas de datos. La documentación oficial de Google Tag Manager lo trata como configuración crítica desde marzo de 2024.

Basic Mode vs Advanced Mode: cuál elegir según el caso

La elección entre Basic Mode y Advanced Mode define cuántos datos se recuperan de los usuarios que rechazan cookies, y por tanto define la utilidad real de todo el resto de la medición. Basic Mode es el equivalente a «no medir nada de quien rechaza»: las etiquetas de Google no se cargan hasta que hay consentimiento, y no hay modelado posterior. Advanced Mode carga las etiquetas siempre pero les indica el estado de consent, permitiendo que envíen pings sin cookies para calibrar el modelado.

Basic Mode encaja en sitios donde el jurídico exige que ningún script de Google se cargue antes del consentimiento, típicamente webs institucionales, sanitarias o legales con auditorías estrictas. La pérdida de datos es total para el segmento que rechaza, pero el cumplimiento es máximo y no hay debate. Advanced Mode encaja en la inmensa mayoría de proyectos comerciales: ecommerce, servicios, generación de leads, medios. Los cookieless pings no llevan identificadores personales y son técnicamente compatibles con RGPD, aunque el argumento legal debe validarlo el DPO del cliente.

Implementación paso a paso en Google Tag Manager

La implementación de Consent Mode v2 vía GTM tiene una secuencia que no admite atajos: primero se define el estado por defecto denied, después se conecta el CMP, después se disparan las actualizaciones al aceptar/rechazar y finalmente se verifica. Cada eslabón roto en esa cadena rompe la medición aguas abajo.

Paso 1: activar Consent en el contenedor de GTM

Dentro de GTM, en Admin → Configuración del contenedor, se activa la opción «Habilitar la superposición de consentimiento en la sección de etiquetas». Esto añade una pestaña de consent settings a cada etiqueta y permite marcar qué tipos de consent requiere para dispararse. Sin esta opción activada, las etiquetas ignoran completamente el estado de consent.

Paso 2: declarar el estado de consent por defecto

Se crea una etiqueta HTML personalizada con el comando gtag de default y se dispara en el trigger «Consent Initialization – All Pages». Este es el trigger que ejecuta antes de todos los demás y es la única ventana válida para declarar el default state.

<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'functionality_storage': 'denied',
  'personalization_storage': 'denied',
  'security_storage': 'granted',
  'wait_for_update': 500
});
</script>

El parámetro wait_for_update de 500 milisegundos le da margen al CMP para pisar el default antes de que se disparen las etiquetas. Si el CMP tarda más, se puede subir a 2000 ms; por debajo de 500 ms es común que las etiquetas se disparen con el default denied incluso cuando el usuario ya ha aceptado.

Paso 3: conectar el CMP

Cualquier CMP certificado por Google —Cookiebot, OneTrust, Iubenda, Complianz, CookieYes, Didomi— tiene una plantilla oficial en la Community Template Gallery de GTM que hace este trabajo. Se importa la plantilla, se pega el ID de la cuenta del CMP y se dispara en el mismo trigger «Consent Initialization». A partir de ahí, cada aceptación/rechazo del usuario emite automáticamente el gtag('consent','update',...) correspondiente.

Paso 4: revisar las etiquetas de Google

Las etiquetas modernas de Google Ads y GA4 respetan Consent Mode nativamente sin configuración extra. Las etiquetas de terceros (Meta Pixel, TikTok, LinkedIn Insight) no leen el consent state de Google y necesitan sus propios triggers de consentimiento; la configuración de Pixel + CAPI de Meta requiere su propio bloque de consent aparte del de Google.

Paso 5: dejar la etiqueta de conversión de Ads como «advanced»

En Google Ads → Etiquetas de conversión, cada conversión ofrece la opción de habilitar Enhanced Conversions y aceptar el consent mode advanced. Sin ese switch activo, Google Ads no acepta los pings cookieless aunque GTM los esté enviando, y el modelado no arranca. Este es el fallo más frecuente en implementaciones a medio hacer.

Señales AEPD y encaje con el RGPD español

La AEPD publicó en julio de 2023 una actualización de su Guía de Cookies que endureció los requisitos del banner de consentimiento y afectó de forma directa a cómo debe configurarse Consent Mode v2 en España. Los patrones de «solo aceptar» sin botón equivalente de rechazo y los banners con opción de rechazo escondida detrás de menús han pasado a considerarse infractores. La AEPD ha abierto y resuelto procedimientos sancionadores concretos sobre esos patrones desde 2024, con multas publicadas en su web.

Para Consent Mode v2, esto se traduce en tres requisitos operativos que el equipo técnico debe validar en cada banner antes de darlo por bueno. Primero, el banner debe ofrecer «Aceptar», «Rechazar» y «Configurar» al mismo nivel visual y jerárquico en la primera capa. Segundo, el rechazo debe ser tan fácil como la aceptación: un solo clic, sin capas adicionales. Tercero, el estado por defecto antes de la interacción debe ser denied para todas las categorías salvo las estrictamente necesarias.

La AEPD no exige Consent Mode v2 como tal —es una herramienta técnica de Google, no una obligación legal—, pero sí exige el resultado que Consent Mode v2 permite conseguir: que ninguna cookie ni script de terceros con fines analíticos o publicitarios se dispare antes del consentimiento explícito. Un banner que cumple la Guía de Cookies y un Consent Mode v2 bien configurado son las dos caras de la misma moneda.

Cómo verificar que Consent Mode v2 funciona en vivo

Una implementación sin verificación es exactamente lo mismo que no tener implementación: hasta que no se comprueba que las señales llegan a Google en el estado correcto, no se puede afirmar que Consent Mode v2 esté funcionando. La verificación tiene tres capas y todas se pueden hacer en menos de treinta minutos por sitio.

Verificación 1: Google Tag Assistant

Google Tag Assistant (tagassistant.google.com) se instala como extensión de Chrome y se conecta al sitio con debug mode activo. Al recargar la página, cada etiqueta muestra sus consent settings recibidos: analytics_storage, ad_storage, ad_user_data y ad_personalization deben aparecer con su estado actual y la etiqueta debe indicar si esa disparación es «before consent» o «after consent». Si una etiqueta de GA4 se dispara con analytics_storage denied, algo está mal en el mapeo del CMP.

Verificación 2: Google Ads Diagnostics

Dentro de Google Ads, en Herramientas → Configuración → Consent settings, aparece un diagnóstico que muestra el porcentaje de conversiones que llegan con consent granted, denied o sin señal. Un porcentaje alto de «sin señal» indica que Consent Mode no se está desplegando correctamente en las páginas de conversión; un porcentaje bajo de granted indica que el banner tiene tasas de rechazo altas —lo cual es información valiosa por sí misma sobre la fricción del banner con los usuarios.

Verificación 3: GA4 y coincidencia con backend

En GA4, el informe «Comportamiento de recopilación de datos» incluye desde 2024 métricas específicas de Consent Mode: número de eventos recibidos con y sin consent, número de sesiones modeladas y ratio de recuperación estimado. Cruzando esos números con los que reporta el CRM o backend transaccional, se puede estimar si el gap entre GA4 y realidad es del orden esperado (10-25%) o desproporcionado (más del 40%), en cuyo caso hay un problema estructural que aún no se ha detectado. La configuración inicial de GA4 ya asume Consent Mode como parte del stack.

Los primeros datos de modelado tardan entre 2 y 4 semanas en aparecer en GA4 y en Google Ads después de la implementación. Antes de ese plazo, no es posible juzgar el impacto real; muchas auditorías precipitadas concluyen que «no está funcionando» cuando en realidad todavía no hay suficientes datos para calibrar el modelo.

Errores comunes que rompen la medición sin dar señales

Los errores de Consent Mode v2 rara vez se ven en el frontend: el banner sale, el usuario acepta o rechaza y aparentemente todo funciona. El daño está en las plataformas de destino, y para cuando se detecta suelen haber pasado semanas de campañas optimizando contra datos incompletos. Estos son los cinco fallos más frecuentes en cuentas auditadas.

• 1
  CMP cargado antes que el default state

  El comando gtag('consent','default',...) debe ejecutarse antes que cualquier otro script de Google. Cuando el CMP se carga primero, las etiquetas se disparan con un default vacío que Google interpreta como «sin señal» y no como «denied», con lo cual el modelado no arranca.

• 2
  Etiqueta de conversión de Ads sin modo advanced activo

  Google Ads necesita que cada etiqueta de conversión tenga habilitado el consent mode advanced en su configuración; sin ese switch, los cookieless pings no se aceptan aunque GTM los envíe y no hay modelado para esa conversión concreta.

• 3
  Mezcla de CMP con etiquetas cargadas fuera de GTM

  Cuando parte de las etiquetas de Google están hardcodeadas en el theme o en un plugin y otra parte se gestionan por GTM, el consent state solo llega a las de GTM. Las hardcodeadas se disparan siempre y saltan el consent, generando incidentes de RGPD y datos duplicados a la vez.

• 4
  Falta de mapeo de ad_user_data y ad_personalization

  Las plantillas antiguas de CMP solo mapeaban ad_storage y analytics_storage (el Consent Mode v1). Las dos señales añadidas en v2 —ad_user_data y ad_personalization— tienen que estar explícitamente mapeadas en la plantilla del CMP en GTM; si no, Google Ads las trata como sin señal y no puede reconstruir la conversión.

• 5
  No conectar los eventos personalizados de GA4 al mismo trigger de consent

  Los eventos personalizados que se disparan fuera del bloque de consent (por ejemplo un evento de scroll) pueden acabar enviándose sin respetar el estado denied, exponiendo al sitio a incumplimiento y falseando los datos. Todo evento a GA4 debe pasar por el mismo filtro de consent.

Auditar estos cinco puntos en cualquier cuenta lleva menos de una hora y cierra la mayoría de las incidencias que aparecen tras el despliegue. Cuando el diagnóstico apunta a un problema más profundo —por ejemplo, un desajuste sistémico entre Google Ads y GA4 en la medición de conversiones—, conviene revisar la arquitectura completa de tracking antes de tocar más etiquetas.

El trabajo de dejar Consent Mode v2 correctamente puesto y auditar el impacto en las plataformas de destino es exactamente el tipo de proyecto que ejecuta el servicio de análisis de datos de Advanze cuando una cuenta empieza a reportar cifras que no cuadran con la realidad del negocio.

Preguntas frecuentes