GA4 y Consent Mode v2: medir sin romper el RGPD

Hay una tensión que ningún equipo de marketing ni de desarrollo puede esquivar desde hace años: el RGPD dice que no puedes leer ni escribir información en el dispositivo de un usuario sin su consentimiento previo, y el negocio dice que necesita saber qué campañas funcionan. Durante mucho tiempo la salida fue mirar hacia otro lado —banners que solo tenían botón de «Aceptar», etiquetas que cargaban antes de que nadie decidiera nada— hasta que las autoridades de protección de datos empezaron a sancionar y Google decidió que ya no iba a servir de intermediario en esa ambigüedad.

Consent Mode v2 es la respuesta de Google a ese problema: un protocolo que permite a sus etiquetas conocer el estado de consentimiento del usuario y comportarse en consecuencia. No es un plugin ni un producto que se compre; es una capa de señalización que tú tienes que implementar correctamente en tu sitio, y de la que dependen cosas muy tangibles: si tus públicos de remarketing se rellenan, si tus conversiones se importan a Google Ads y si tus informes de GA4 tienen sentido.

Este artículo es una guía técnica para equipos que tienen que implementarlo de verdad, no un resumen del anuncio oficial. Vemos qué exige la normativa, qué cambió entre v1 y v2, cómo se implementa con gtag y con Google Tag Manager, en qué se diferencian el modo básico y el avanzado, qué es exactamente el modelado de conversiones y cuánto recupera, cómo leer un informe de GA4 que mezcla datos observados y modelados, y una lista de los errores de implementación que vemos en prácticamente todas las auditorías.

1. El problema de fondo: consentimiento previo frente a medición

Conviene empezar por la norma, porque muchas discusiones sobre Consent Mode se resuelven solas cuando se entiende qué obliga a qué.

1.1 Qué exige realmente la normativa

El artículo 22.2 de la LSSI en España —trasposición de la Directiva ePrivacy— exige consentimiento informado antes de almacenar o acceder a información en el equipo terminal del usuario. Eso incluye cookies, pero también localStorage, sessionStorage, IndexedDB y cualquier identificador persistente. El RGPD se superpone regulando el tratamiento posterior de esos datos personales, y la guía de la AEPD sobre uso de cookies concreta los requisitos prácticos.

De ahí se derivan tres reglas que condicionan cualquier implementación: el consentimiento debe ser previo (nada se instala antes de la elección), granular (por finalidad, no un todo o nada) y tan fácil de rechazar como de aceptar (el botón de rechazar debe estar en la primera capa y con el mismo peso visual). Los muros de cookies y los banners con «Aceptar» destacado y «Configurar» escondido en gris llevan años siendo el objetivo preferente de las reclamaciones.

1.2 Por qué esto se volvió urgente

Dos presiones convergieron. Por un lado, las resoluciones de varias autoridades europeas que cuestionaron transferencias y configuraciones concretas de herramientas de analítica, obligando a revisar implementaciones que llevaban años funcionando. Por otro, la propia Google, que a partir de la entrada en vigor de la normativa europea de mercados digitales condicionó funcionalidades de sus productos publicitarios a recibir señales de consentimiento válidas.

La consecuencia práctica es simple y poco negociable: sin señales de consentimiento correctamente enviadas, se degradan los públicos de remarketing, el seguimiento de conversiones mejorado y buena parte de la optimización automática de campañas. Si trabajas con Google Ads, esto conecta directamente con cómo estructuras las campañas —lo tratamos en nuestra guía de estructura de campañas en Google Ads y en la comparativa de Performance Max frente a Shopping estándar, donde la calidad de la señal de conversión determina buena parte del resultado.

1.3 Lo que Consent Mode no es

Aclaremos tres malentendidos habituales antes de seguir. Consent Mode no sustituye a un banner de cookies: sigues necesitando una CMP que recoja y almacene la elección del usuario. No te hace conforme al RGPD por sí solo: es un mecanismo técnico, no un certificado de cumplimiento. Y no recupera los datos perdidos: estima agregados a partir de patrones, que es una cosa muy distinta de medir.

2. Qué es Consent Mode v2 y qué cambió respecto a v1

Consent Mode es un conjunto de parámetros que las etiquetas de Google leen antes de decidir qué hacer. La versión 1 manejaba dos: analytics_storage y ad_storage. La v2 añadió dos más y los convirtió en requisito para el Espacio Económico Europeo.

2.1 Los parámetros

• analytics_storage: almacenamiento relacionado con analítica (por ejemplo, la cookie de cliente de GA4).
• ad_storage: almacenamiento con fines publicitarios.
• ad_user_data (nuevo en v2): consentimiento para enviar datos del usuario a Google con fines publicitarios.
• ad_personalization (nuevo en v2): consentimiento para publicidad personalizada y remarketing.

Existen además parámetros complementarios como functionality_storage, personalization_storage y security_storage, que no son obligatorios pero conviene mapear si tu CMP ya distingue esas finalidades.

El matiz que más se pasa por alto: ad_storage habla de guardar en el dispositivo, mientras que ad_user_data habla de transmitir. Son cosas distintas y una CMP mal mapeada puede conceder una y denegar la otra sin que nadie se dé cuenta durante meses.

2.2 Modo básico y modo avanzado

En el modo básico, las etiquetas de Google no se cargan en absoluto hasta que el usuario acepta. Si rechaza, no se envía nada: cero señales. Es la opción más conservadora jurídicamente y la más sencilla de defender ante una inspección, pero renuncia al modelado y deja un agujero proporcional a tu tasa de rechazo.

En el modo avanzado, las etiquetas se cargan siempre, pero arrancan con el consentimiento denegado por defecto. Si el usuario rechaza, se envían pings sin cookies ni identificadores: información agregada y no personal (marca de tiempo aproximada, agente de usuario, referente, consentimiento denegado). Esos pings son el combustible del modelado de conversiones.

La elección no es solo técnica, es también de criterio jurídico, y conviene documentarla con el responsable de privacidad. Nuestra recomendación práctica: el avanzado bien implementado es defendible porque no se accede a información almacenada en el dispositivo, pero exige poder demostrar exactamente qué se envía. Si no puedes demostrarlo, no lo actives.

2.3 Qué pasa si no lo implementas

La degradación no es un apagón, es un goteo: los públicos basados en actividad del sitio dejan de crecer para tráfico del EEE, el seguimiento de conversiones mejorado pierde cobertura, las audiencias similares se resienten y el algoritmo de puja recibe menos señal, con el consiguiente encarecimiento del coste por adquisición. Como el efecto es progresivo, muchos equipos lo atribuyen a «estacionalidad» durante meses.

3. Implementación técnica

Aquí es donde se gana o se pierde el proyecto. El 90 % de las implementaciones rotas que auditamos fallan por lo mismo: el orden de ejecución.

3.1 La regla de oro: default antes que nada

La llamada consent default debe ejecutarse antes de que se cargue cualquier etiqueta de Google. No «pronto»: antes. Si la etiqueta de GA4 se dispara medio segundo antes que el default, esa primera petición viaja con el comportamiento por defecto de la etiqueta y ya no hay vuelta atrás para ese evento.

En una implementación con gtag directo, el bloque de consentimiento va en el <head>, por delante del script del contenedor:

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': 'granted',
  'security_storage': 'granted',
  'wait_for_update': 500
});

El parámetro wait_for_update indica cuántos milisegundos deben esperar las etiquetas por si llega una actualización de consentimiento. Un valor entre 500 y 2000 es lo habitual: demasiado bajo y perderás eventos de usuarios que aceptan rápido; demasiado alto y retrasarás la medición de todos.

Cuando el usuario decide, se emite la actualización:

gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

3.2 Con Google Tag Manager

En GTM el planteamiento cambia: el default se configura en una etiqueta de tipo plantilla de consentimiento (la propia de tu CMP o una personalizada) disparada con el activador Consent Initialization – All Pages, que es el único que se ejecuta antes que Initialization y que All Pages. Usar cualquier otro activador es el error clásico.

Además, cada etiqueta tiene su propia configuración de consentimiento avanzada, donde se declaran los consent checks adicionales que requiere. Conviene revisarlas una a una: las etiquetas de terceros (píxeles de redes sociales, mapas de calor, chats) no entienden Consent Mode y hay que bloquearlas explícitamente por variable de consentimiento de la CMP.

3.3 Elegir CMP

Los criterios que de verdad importan al elegir plataforma de gestión de consentimiento: que esté certificada por Google como CMP compatible, que soporte el TCF de la IAB si trabajas con publicidad programática, que exponga la elección en el dataLayer de forma documentada, que permita bloquear scripts de terceros por categoría, que conserve un registro de consentimientos con marca de tiempo (te lo pedirán si hay reclamación) y que soporte el rescaneo periódico del sitio para detectar cookies nuevas.

Un detalle operativo que se olvida: el registro de consentimiento debe poder exportarse. Si tu CMP lo guarda solo en el navegador del usuario, no tienes prueba de nada.

3.4 Cómo verificar que funciona

Tres comprobaciones que hacemos siempre, en este orden:

1. Consola con el modo de depuración de la etiqueta: revisar que el primer evento de consentimiento es el default y que llega antes que la primera petición a los dominios de Google.
2. Pestaña de red: rechazar todo y comprobar que las peticiones que salen llevan el parámetro de consentimiento denegado y no incluyen identificador de cliente ni cookies.
3. Estado de consentimiento en la vista previa de GTM: comprobar el estado en cada evento, no solo en el primero. Las actualizaciones que no se propagan son un fallo frecuente en sitios con navegación cliente.

Y una comprobación que casi nadie hace: repetir todo lo anterior después de cada despliegue. Una implementación correcta se rompe con facilidad al cambiar el orden de scripts, al activar una optimización de carga diferida o al instalar un plugin de caché que mueve el JavaScript al pie. Si trabajas sobre WordPress, este es exactamente el tipo de regresión silenciosa que conviene incluir en el plan de auditoría de rendimiento y calidad del sitio.

4. Modelado de conversiones: qué es y qué esperar

Cuando activas el modo avanzado, Google usa los pings sin cookies de los usuarios que rechazaron, junto con el comportamiento observado de los que aceptaron, para estimar cuántas conversiones se produjeron en el grupo no consentido. Es un modelo estadístico, no una recuperación de datos.

4.1 Requisitos para que se active

El modelado no se enciende por el mero hecho de implementar el modo avanzado. Requiere volumen: un mínimo de tráfico y de conversiones diarias sostenido durante varias semanas, y una proporción suficiente de usuarios consentidos que sirvan de referencia. Sitios pequeños pueden implementar todo correctamente y no ver nunca datos modelados, lo cual no significa que la implementación esté mal.

4.2 Cómo interpretarlo sin engañarse

Tres cautelas. Primera: los datos modelados no se pueden desglosar indefinidamente; a mayor segmentación, menos fiabilidad, y a partir de cierto nivel de detalle Google directamente no los muestra. Segunda: no compares periodos anteriores y posteriores a la activación como si fueran homogéneos; anota la fecha del cambio en tus informes. Tercera: el modelo estima conversiones, no usuarios; las métricas de usuarios únicos siguen sujetas a lo observado.

La conclusión operativa para un comité de dirección es incómoda pero honesta: con Consent Mode bien implementado recuperas capacidad de optimización de campañas, no exactitud contable. Para cifras que deban cuadrar con facturación, la fuente de verdad es tu backend o tu ERP, nunca la herramienta de analítica. Si esa conexión no existe todavía, es un proyecto de integración en sí mismo: lo describimos en la guía sobre conectar ERP y CRM en un dashboard en tiempo real.

5. Qué cambia en tus informes de GA4

5.1 Datos observados, modelados y con umbral

Un informe de GA4 puede contener tres cosas a la vez: datos observados de usuarios consentidos, datos modelados y datos ocultos por umbrales de privacidad. El icono de aviso en la parte superior del informe indica cuándo se está aplicando un umbral, algo que ocurre con frecuencia al añadir dimensiones demográficas o al segmentar mucho.

Consejo práctico: cambia la identidad de informes entre «combinada» y «solo dispositivo» para ver cuánto cambia una métrica. Si la diferencia es grande, estás mirando mucho dato modelado y conviene ser prudente con las conclusiones.

5.2 Descuadres que son normales y descuadres que no

Es normal que GA4 y Google Ads no coincidan: usan modelos de atribución y ventanas distintas. No es normal que las conversiones caigan un 40 % de un día para otro sin cambio de tráfico: eso apunta a etiqueta rota, orden de carga alterado o mapeo de CMP modificado. Tampoco es normal ver tráfico directo desproporcionado: suele indicar que el referente se pierde por una redirección o por un banner que recarga la página.

5.3 Qué monitorizar de forma continua

• Tasa de aceptación del banner, segmentada por dispositivo y por página de entrada.
• Proporción de eventos con consentimiento concedido frente a denegado.
• Conversiones diarias con alerta automática ante caídas superiores a un umbral.
• Número de cookies detectadas en el rescaneo periódico frente a las declaradas en la política.

6. Server-side tagging: ¿solución o parche?

El etiquetado del lado del servidor mueve la recogida a un contenedor propio, normalmente en tu dominio. Aporta ventajas reales: menos JavaScript de terceros en el navegador —con impacto directo en el rendimiento y por tanto en las métricas de Core Web Vitals—, control sobre qué datos salen hacia cada proveedor y capacidad de enriquecer eventos con información de backend.

Pero conviene desmontar el mito: server-side no elimina la necesidad de consentimiento. Si el evento que llega al servidor se originó leyendo o escribiendo algo en el dispositivo del usuario, la obligación sigue vigente. Y añade coste e infraestructura que hay que mantener. Lo recomendamos cuando existe un problema concreto que resuelve —rendimiento, gobierno del dato, enriquecimiento desde backend—, no como remedio genérico contra la pérdida de datos.

7. Alternativas y complementos

No todo tiene que pasar por la misma herramienta. Combinaciones que funcionan bien en la práctica:

• Analítica sin cookies para las métricas de producto y contenido, que en muchos casos no requiere consentimiento si es verdaderamente anónima y agregada. Da una visión de tráfico sin huecos.
• Medición del lado del servidor de los eventos de negocio (pedidos, altas, tickets) directamente contra tu base de datos: es la única fuente exacta.
• Datos de Search Console para el rendimiento orgánico, que no dependen de consentimiento en el sitio.
• Encuestas de atribución declarada («¿cómo nos conociste?») en el formulario o en el checkout. Es un dato ruidoso, pero cubre justo el hueco que deja el consentimiento denegado.

Esta combinación —analítica agregada para tendencias, backend para cifras exactas y declaración del usuario para atribución— es más robusta que insistir en reconstruir el recorrido completo de cada usuario, algo que la normativa ha hecho estructuralmente inviable.

8. Checklist de auditoría

1. ¿El consent default se ejecuta antes que cualquier etiqueta de Google, en todas las páginas y también en la primera carga sin caché?
2. ¿Los cuatro parámetros v2 están declarados, incluidos ad_user_data y ad_personalization?
3. ¿El mapeo entre las categorías de la CMP y los parámetros de Google está documentado y revisado?
4. ¿El consent update se dispara al aceptar, al rechazar y al cambiar la preferencia después?
5. ¿Las etiquetas de terceros que no entienden Consent Mode están bloqueadas por categoría?
6. ¿El banner permite rechazar en la primera capa, con el mismo peso visual que aceptar?
7. ¿Existe registro exportable de consentimientos con marca de tiempo?
8. ¿La política de cookies coincide con las cookies realmente instaladas, según un rescaneo reciente?
9. ¿Hay alertas automáticas ante caídas bruscas de conversiones?
10. ¿La verificación forma parte del checklist de despliegue?

9. Errores frecuentes

1. Default después de la etiqueta. El error número uno, y casi siempre por usar el activador equivocado en GTM.
2. Olvidar los dos parámetros nuevos de la v2 y creer que la v1 sigue bastando.
3. Confundir ad_storage con ad_user_data al mapear la CMP.
4. No emitir update cuando el usuario cambia de opinión desde el enlace de preferencias.
5. Etiquetas de terceros cargando igualmente porque solo se configuró Consent Mode para las de Google.
6. Plugin de caché u optimizador de JavaScript que reordena los scripts y rompe la secuencia.
7. Banner que recarga la página al aceptar, perdiendo el referente original.
8. Política de cookies desactualizada respecto a lo que realmente se instala.
9. Comparar periodos anteriores y posteriores a la activación sin anotar el cambio.
10. Asumir que el modelado repone los datos y usar GA4 como fuente contable.

10. Conclusión

Consent Mode v2 no es un truco para recuperar lo que la privacidad se llevó: es la forma de seguir midiendo dentro de las reglas. Bien implementado te devuelve capacidad de optimización publicitaria y te da un marco defendible ante una reclamación. Mal implementado —que es lo habitual— produce lo peor de los dos mundos: datos incompletos y exposición legal.

La parte difícil no es escribir las cuatro líneas de gtag('consent', ...). Es garantizar que ese orden de ejecución sobrevive al siguiente despliegue, al siguiente plugin y al siguiente responsable de marketing que añade un píxel «solo para una campaña». Por eso lo tratamos como lo que es: un componente de producción, con su verificación en el checklist de release y su monitorización con alertas.

Y una última idea que ayuda a bajar la ansiedad de los equipos: la medición perfecta ya no existe y no va a volver. Lo que sí existe es una medición honesta, con sus márgenes explicitados, cruzada con los datos exactos de tu propio backend. Eso es suficiente para tomar buenas decisiones, que al final es de lo que se trata.

11. Preguntas frecuentes

¿Consent Mode v2 es obligatorio?

No es una obligación legal en sí misma: la obligación legal es el consentimiento previo. Consent Mode es el mecanismo que Google exige para seguir prestando determinadas funcionalidades publicitarias a tráfico del Espacio Económico Europeo. Si no lo implementas, no te multan por ello, pero pierdes funcionalidad de producto.

¿El modo avanzado cumple el RGPD?

Puede ser conforme si los pings enviados tras el rechazo no incluyen identificadores ni acceden a información almacenada en el dispositivo, y así se documenta. Es una decisión que debe validar el responsable de privacidad de la organización, no el equipo técnico en solitario. Ante la duda, el modo básico es la opción conservadora.

¿Cuánta pérdida de datos es normal?

Depende por completo de tu tasa de aceptación, que varía enormemente según sector, diseño del banner y tipo de tráfico. Lo importante no es el número absoluto sino medirlo: si no conoces tu tasa de aceptación, no puedes interpretar ningún informe.

¿Sirve de algo si mi tráfico es mayoritariamente de fuera de la UE?

La exigencia de Google aplica al tráfico del EEE, Reino Unido y Suiza. Aun así, implementarlo de forma global simplifica el mantenimiento y te prepara para normativas equivalentes que siguen apareciendo en otras jurisdicciones.

¿Puedo usar GA4 sin banner si anonimizo?

No de forma general: GA4 escribe identificadores en el dispositivo, y eso ya activa la obligación de consentimiento previo con independencia de lo que hagas después con el dato. Para métricas sin consentimiento hay que recurrir a analítica verdaderamente sin cookies.

¿Cada cuánto hay que revisar la implementación?

Como mínimo, en cada despliegue que toque plantillas, scripts o caché, y con un rescaneo completo de cookies trimestral. En sitios con muchas campañas y píxeles nuevos, mensual.