Cómo pasar la señal de consentimiento al contenedor de servidor

Todos los artículos

Configura Consent Mode v2 en tu contenedor web de GTM para que el estado quede fijado antes de que se dispare cualquier etiqueta. Google lo adjunta luego a la petición que reenvía, en los parámetros gcs y gcd, así que no hay que enviar nada dos veces. En el contenedor de servidor, lee ese estado, condiciona a él cada etiqueta de proveedor y comprueba que tu cliente de GA4 no esté restaurando un identificador por su cuenta.

La señal no va por otro camino

El error habitual es tratar el consentimiento como algo que hay que comunicarle al contenedor de servidor por separado, con una segunda integración. El estado que eligió el visitante viaja en la misma petición que lleva el evento, así que si la parte web está bien, la de servidor ya lo tiene. La guía de Google sobre Consent Mode con Tag Manager en servidor describe el mismo reparto: el contenedor web recoge el consentimiento y el de servidor dispara las etiquetas en función de él.

Esto tiene una consecuencia que conviene decir claramente, porque determina dónde buscar cuando algo falla: un contenedor de servidor no puede arreglar un problema de consentimiento. No tiene banner ni visitante al que preguntar. Si el estado no salió bien del navegador, cualquier condición que montes ahí está comprobando un campo vacío. La parte de las obligaciones legales la tienes en ¿necesitas banner de cookies si usas etiquetado en servidor?

Cómo pasar la señal de consentimiento al contenedor de servidor

1. Configura Consent Mode v2 en el contenedor web, no en el de servidor

   El consentimiento se decide en el navegador y se configura en tu contenedor web de GTM. La CMP deja denegadas por defecto todas las señales no esenciales antes de que se inicie cualquier etiqueta y las actualiza cuando el visitante elige. El contenedor de servidor no tiene banner ni visitante al que preguntar, así que nunca es ahí donde se arregla un problema de consentimiento.

2. Confirma que el estado va de verdad en la petición saliente

   En una ventana privada, busca la petición que tus etiquetas de Google envían al contenedor de servidor. Ya debería llevar un parámetro gcs: G100 si los dos tipos de almacenamiento están denegados, G111 si los dos están concedidos, y G101 o G110 en los casos mixtos. G1-- significa que la etiqueta se disparó sin ningún estado de consentimiento y que todo lo que viene después va a ciegas.

3. Lee el estado del consentimiento dentro del contenedor de servidor

   Abre la vista previa del contenedor de servidor e inspecciona un evento entrante. El estado llega con la petición y se puede leer ahí, y eso es lo que permite a una etiqueta decidir si se dispara. Crea variables con nombre para las señales que usas como condición, en lugar de leer campos en bruto en cada etiqueta.

4. Condiciona cada etiqueta de proveedor a la señal que realmente necesita

   Cada etiqueta lleva una condición de disparo ligada a su categoría, y las categorías no son intercambiables. Las etiquetas de analítica comprueban la señal de analítica. Los destinos publicitarios, entre ellos una API de conversiones, comprueban las señales de publicidad, y la versión 2 añadió dos que las configuraciones antiguas nunca comprueban. Una etiqueta sin condición se dispara siempre, también cuando se deniega el consentimiento.

5. Comprueba qué hace tu cliente de GA4 con las cookies

   El paso que no sale en ninguna guía, y el que deshace sin hacer ruido los otros cuatro. El cliente de GA4 tiene un ajuste de cookies. Si lo dejas en la opción server managed, genera y restaura por su cuenta un identificador de origen propio, así que puede poner un id persistente en un ping que tenía que ser anónimo. Cámbialo a javascript managed para que el cliente use el identificador que envió el navegador, y nada más.

6. Verifica con un rechazo, no con una aceptación

   Todo el mundo prueba aceptando, porque es el camino en el que aparecen datos. Tú haz lo contrario: rechaza en una ventana privada limpia y sigue ese evento de principio a fin. Mira el estado en la petición, el estado dentro del contenedor, qué etiquetas se dispararon y qué identificador salió hacia cada proveedor.

El fallo que sobrevive a una configuración correcta

Los pasos del uno al cuatro son los que explica cualquier guía, y una configuración que los cumple parece terminada. El quinto es el que seguimos encontrando en contenedores montados con cuidado, y no tiene ninguna pinta de fallo de consentimiento.

El escenario es este: el banner está bien, el valor por defecto es denegado, el estado llega intacto al contenedor y las etiquetas de proveedor están bien condicionadas, así que un evento denegado no dispara ninguna etiqueta publicitaria. Todo lo que probarías sale bien. Pero, mientras tanto, el cliente de GA4 está gestionando sus propias cookies: en cada petición genera o restaura un identificador de origen propio y lo escribe en el evento. Un ping que tenía que salir anónimo sale con un id estable.

El síntoma nunca apunta al consentimiento. Se ve como cifras un poco infladas y sesiones que deberían llegar sin atribuir y llegan atribuidas. Rastreamos exactamente esto en una sesión de depuración de un contenedor de servidor en producción, y se arregló con un solo ajuste. No hubo que tocar las condiciones, porque nunca habían estado mal.

La lección sirve en general. Condicionar las etiquetas y controlar el identificador son dos trabajos distintos. La condición decide si una petición llega a un proveedor. El identificador decide si ese proveedor puede saber de quién se trata. La documentación cubre lo primero y no dice nada de lo segundo, así que un contenedor puede seguir las indicaciones al pie de la letra y aun así estar entregando la identidad de los visitantes.

Lo que vale una configuración que aguanta

Cuánto tráfico queda detrás del banner depende de tus regiones, tu público y el diseño de tu banner. Mide el tuyo: mira la tasa de consentimiento en tu CMP o compara las sesiones de GA4 con las peticiones que recibe tu contenedor de servidor. Una configuración correcta le da a Google una señal de denegación con la que puede modelar, en cuanto tu propiedad alcanza sus umbrales de datos, y mantiene bien atribuido el tráfico que sí tiene permiso.

Lo que ganes vendrá del modelado y del tráfico permitido bien atribuido, nunca de volver a identificar a escondidas a quien dijo que no. Un contenedor que filtra un identificador no está cubriendo un hueco: está recogiendo datos que le negaron, y como deja mejor las cifras del panel, nadie lo detecta.

La versión corta

El consentimiento se decide en el navegador y se configura en el contenedor web. Llega al servidor en la propia petición, en gcs, sin ninguna segunda integración. Léelo ahí, condiciona cada etiqueta de proveedor a la categoría que necesita y configura el cliente de GA4 para que use el identificador que envió el navegador en lugar de generar uno. Después demuéstralo con un evento rechazado. El procedimiento en el navegador lo tienes en cómo comprobar si tu banner envía la señal de Consent Mode v2, y cómo saber qué modo usas, en Consent Mode básico o avanzado.

Velo fija las cuatro señales con un solo fragmento de código antes de que se inicien tus etiquetas, que es la primera mitad de todo lo que acabamos de ver. Cómo funciona lo tienes en la página de producto.

Las etiquetas de servidor de otros proveedores, como la Conversions API de Meta, necesitan su propia comprobación de consentimiento: consulta la guía de etiquetas de Google y tag gateway.

Para el propio contenedor, más allá de esta parte del consentimiento, el equipo que hay detrás de Velo tiene una lista completa de lo que necesita un etiquetado en servidor en producción: buenas prácticas de etiquetado en servidor para 2026, en el blog de Amplio Data.