Cómo pasar la señal de consentimiento a un contenedor de etiquetado del lado del servidor

Configura Consent Mode v2 en tu contenedor web de GTM para que el estado quede fijado antes de que se dispare ninguna etiqueta. Google lo adjunta entonces a la petición que envía hacia adelante, como el parámetro gcs, 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 en silencio.
La señal no va por una ruta aparte
La forma habitual de construir esto mal es tratar el consentimiento como algo de lo que hay que informar al contenedor de servidor por separado, con una segunda integración. El estado que eligió el visitante viaja adjunto a la misma petición que lleva el evento, así que si el lado web está bien, el lado del servidor ya lo tiene.
Eso tiene una consecuencia que conviene decir sin rodeos, porque determina adónde vas cuando algo se rompe: un contenedor de servidor no puede reparar un problema de consentimiento. No tiene banner ni visitante a quien preguntar. Si el estado nunca salió bien del navegador, cada condición que construyas ahí está comprobando un campo vacío. La parte de la obligación legal está en ¿sigues necesitando un banner de cookies con etiquetado del lado del servidor?.
Cómo pasar la señal de consentimiento a un contenedor de etiquetado del lado del servidor
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 fija un valor por defecto denegado para cada señal no esencial antes de que se inicialice ninguna etiqueta, y lo actualiza cuando el visitante elige. El contenedor de servidor no tiene banner ni visitante a quien preguntar, así que nunca es el sitio donde arreglar un problema de consentimiento.
Confirma que el estado va de verdad en la petición de salida
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 ambos tipos de almacenamiento están denegados, G111 si ambos están concedidos, G101 y G110 para los casos mixtos. G1-- significa que la etiqueta se disparó sin estado de consentimiento adjunto y que todo lo que viene después va a ciegas.
Lee el estado de 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í, que es lo que permite a una etiqueta decidir si se dispara. Créate variables con nombre para las señales que uses como condición, en lugar de leer campos en bruto en cada etiqueta.
Condiciona cada etiqueta de proveedor a la señal que realmente necesita
Cada etiqueta recibe una condición de disparo ligada a la categoría correcta, y las categorías no son intercambiables. Las etiquetas de analítica comprueban la señal de analítica. Los destinos publicitarios, una API de conversiones entre ellos, 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 con todo, denegaciones incluidas.
Comprueba qué hace tu cliente de GA4 con las cookies
El paso que ninguna guía incluye y el que deshace en silencio los otros cuatro. El cliente de GA4 tiene un ajuste de cookies. Si lo dejas en la opción server managed, genera y restaura un identificador propio, así que puede adjuntar un id persistente a un ping que debía ser anónimo. Ponlo en javascript managed para que el cliente use el identificador que envió el navegador y nada más.
Verifica con una denegación, no con una aceptación
Todo el mundo prueba aceptando, porque es la ruta donde aparecen los datos. Rechaza en su lugar, en una ventana privada limpia, y sigue ese único evento: 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 lo que cubre cualquier guía, y una configuración que los pasa parece terminada. El paso cinco es el que seguimos encontrando en contenedores construidos con cuidado, y no parece un fallo de consentimiento en absoluto.
La forma que tiene es esta: el banner está bien, el valor por defecto es denegado, el estado llega íntegro al contenedor y las etiquetas de proveedor están condicionadas correctamente, así que un evento denegado no dispara ninguna etiqueta publicitaria. Todo lo que se te ocurriría probar pasa. Mientras tanto, el cliente de GA4 gestiona sus propias cookies, así que en cada petición genera o restaura un identificador propio y lo escribe en el evento. Un ping que debía salir anónimo sale con un id estable.
El síntoma nunca apunta al consentimiento. Se lee como recuentos algo altos y como sesiones que deberían haber quedado sin atribuir llegando atribuidas. Rastreamos exactamente esto en una sesión de depuración de un contenedor de servidor en producción, y la solución fue un solo ajuste. Nada de las condiciones de disparo cambió, porque nunca habían estado mal.
La lección se generaliza. Condicionar las etiquetas y controlar el identificador son dos trabajos distintos. Una condición decide si una petición llega a un proveedor. Un identificador decide si ese proveedor puede saber de quién se trataba. La documentación cubre lo primero y calla sobre lo segundo, así que un contenedor puede seguir las indicaciones al pie de la letra y aun así repartir identidad.
Lo que vale el montaje cuando aguanta
En las implementaciones de clientes de Amplio Data, la referencia medida está en torno al 34% de las sesiones detrás del banner, con un 20 a 40% de las conversiones perdidas recuperables una vez que el consentimiento se configura como Google espera y el identificador se trata con honestidad. Las cifras son rangos medidos en implementaciones de clientes de Amplio Data, no una garantía. La recuperación depende de tu mezcla de tráfico, de las regiones y de cómo estén configuradas tus etiquetas.
Esa recuperación viene del modelado y del tráfico permitido correctamente atribuido, nunca de volver a identificar en silencio a quien dijo que no. Un contenedor que filtra un identificador no está recuperando datos, está recogiendo datos que le fueron negados, y el hecho de que el panel salga favorecido es justo lo que lo esconde.
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, dentro de gcs, sin una 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 compruébalo con un evento rechazado. El procedimiento del lado del navegador está en cómo comprobar que tu banner envía la señal, y qué modo estás usando lo tienes en Consent Mode básico frente a avanzado.
Velo fija las cuatro señales desde un solo fragmento de código antes de que se inicialicen tus etiquetas, que es la mitad aguas arriba de todo lo anterior. El mecanismo está en la página de producto.
Si estás construyendo el contenedor en sí, no solo el cableado del consentimiento, el equipo que hay detrás de Velo mantiene una lista completa de lo que necesita una configuración del lado del servidor en producción en buenas prácticas de etiquetado del lado del servidor para 2026, en el blog de Amplio Data.
Preguntas habituales
Lo que la gente pregunta sobre este tema.
¿Cómo pasas la señal de consentimiento a un contenedor de etiquetado del lado del servidor?
No la envías por separado. Configura Consent Mode v2 en tu contenedor web para que el estado quede fijado antes de que se dispare ninguna etiqueta, y la etiqueta de Google lo adjunta a la petición que envía hacia adelante, donde llega como el parámetro gcs. En el servidor, léelo, condiciona cada etiqueta de proveedor a la categoría que necesita y verifica con un rechazo que las etiquetas correctas se quedaron calladas.
¿Configuras Consent Mode en el contenedor de servidor o en el contenedor web?
El contenedor web. El banner, el valor por defecto denegado y la actualización viven en el navegador, y el contenedor de servidor no tiene visitante a quien preguntar. Solo actúa sobre un estado decidido aguas arriba, y por eso no puede reparar un problema de consentimiento: si el estado nunca salió bien del navegador, ahí no hay nada que una etiqueta pueda comprobar.
¿El etiquetado del lado del servidor significa que ya no necesitas un banner de cookies?
No. Mover la petición a tu propio dominio cambia adónde van los datos, no si tenías permiso para recogerlos. El consentimiento es el permiso para tratar los datos, y eso no depende de qué servidor recibe el hit. El etiquetado del lado del servidor hace que una configuración de consentimiento correcta valga más, pero no elimina nada de la obligación de preguntar.
¿Por qué siguen llegando datos a GA4 con el consentimiento denegado?
Normalmente es el identificador, no la condición de disparo. Si el cliente de GA4 de tu contenedor de servidor gestiona las cookies por su cuenta, puede generar o restaurar un id propio y adjuntarlo a un ping que debía ser anónimo, así que los hits que deberían parecer sin consentimiento llegan pareciendo de un usuario conocido. Apunta el cliente al identificador que envió el navegador. La otra causa es una etiqueta de proveedor sin ninguna condición de disparo.
¿Cómo compruebas que la señal de consentimiento llegó al contenedor de servidor?
Sigue un evento rechazado de principio a fin: el valor gcs en la petición de salida, el estado de consentimiento en el evento entrante dentro de la vista previa del contenedor de servidor, qué etiquetas se dispararon con él y qué identificador llevaba cada petición de salida. Probar solo la ruta de aceptación es el error habitual.
Tu banner, tu consentimiento,
tus datos — todo en un mismo sitio.


