Si tienes un contenedor server-side de Google Tag Manager con más de 50 tags, hay una posibilidad real de que algunos estén enviando datos personales a plataformas publicitarias incluso cuando el usuario ha denegado el consentimiento. No es una hipótesis. Es lo que encontramos en una auditoría reciente.
El síntoma no siempre es visible
El caso concreto: un contenedor server-side enviaba email, nombre, país y código postal a Meta CAPI, TikTok Events API y Google Ads en sesiones donde ad_storage y ad_user_data estaban en estado denegado (gcs=G100). Desde fuera, todo parecía funcionar: las campañas reportaban conversiones con normalidad. El problema solo aparece cuando se audita tag a tag.
Cómo se diagnostica de verdad
Una revisión superficial del banner de cookies no detecta esto. Hace falta bajar a los 154 tags individuales del contenedor y comprobar el estado de sus gates uno por uno. En este caso, 128 de 154 tenían el gate ausente o mal configurado: un 83% del contenedor sin control real de consentimiento.
La causa raíz añadía una segunda capa de dificultad: una race condition en el CMP, que en determinadas condiciones de carga marcaba el consentimiento como concedido antes de que el usuario hubiera interactuado con el banner. En la mayoría de sesiones el orden era correcto, así que el fallo pasaba desapercibido en pruebas rápidas.
La corrección
Se implementaron gates explícitos de ad_storage y ad_user_data en los 15 tags server-side afectados, bloqueando su publicación hasta confirmar que ningún tag pudiera dispararse sin la señal de consentimiento correcta, y correctamente temporizada respecto a la interacción real del usuario.
Por qué esto no es solo un problema técnico
Las sanciones de RGPD pueden alcanzar el 4% de la facturación global anual. Un contenedor con la mayoría de sus tags mal configurados no es un detalle de optimización: es una exposición legal activa que, en la mayoría de los casos, nadie sabe que existe hasta que se audita.
Cómo diagnosticarlo en tu propio contenedor
No hace falta esperar a una auditoría externa para saber si tienes este problema. El método es el mismo que usamos en el caso, reducido a lo esencial:
1. Abre tu web en una ventana de incógnito
2. F12 → Network → filtra por el dominio de destino (facebook.com,
tiktok.com, google-analytics.com, o el endpoint de tu servidor
server-side)
3. Rechaza todo en el banner de cookies
4. Busca el parámetro gcs en las peticiones que sigan saliendo
5. Si ves G1xx en vez de G100 (o si no hay parámetro gcs en absoluto),
ese tag no está respetando el rechazo
6. Repite tag por tag si tienes acceso al contenedor — no asumas que
porque uno esté bien, todos lo estánServer-side no es más seguro por defecto
Hay una idea extendida de que migrar a server-side tagging automáticamente mejora el cumplimiento de privacidad, porque “el dato pasa por tu servidor, no directo al tercero”. Es al revés en la práctica: un contenedor server-side mal configurado puede reenviar exactamente los mismos datos a exactamente los mismos terceros, solo que con un salto intermedio que da una falsa sensación de control. El gate de consentimiento tiene que existir en el tag server-side igual que en uno client-side — moverlo de sitio no lo arregla solo.
Este artículo describe un caso real documentado, ejecutado a través de una agencia de marketing digital. Cliente final anonimizado por confidencialidad.