¿Sigues necesitando un banner de cookies con etiquetado del lado del servidor?

Todos los artículos

Sí, sigues necesitando un banner de cookies con el etiquetado del lado del servidor. El etiquetado del lado del servidor cambia dónde se ejecutan tus etiquetas: pasan del navegador del visitante a un contenedor en un servidor que controlas tú. No cambia si tienes derecho a recoger esos datos. Esa pregunta la responde el consentimiento, y el consentimiento es lo que captura el banner.

Qué mueve realmente el etiquetado del lado del servidor

La confusión es razonable, porque el etiquetado del lado del servidor sí mueve muchas cosas. En lugar de una docena de scripts de proveedores disparándose en el navegador, la página envía una sola petición a un contenedor que es tuyo, y ese contenedor es el que habla con Google, Meta y todos los demás. Consigues peticiones de origen propio desde tu propio dominio, cookies con más vida útil y la oportunidad de limpiar o descartar datos antes de que salgan.

Nada de eso toca el momento en que un visitante decide qué va a permitir. Esa decisión ocurre en la página, antes de que se ponga en marcha ninguna de las piezas del lado del servidor. Este es el reparto.

La decisión de consentimiento nunca salió del navegador

Un banner existe para una sola cosa: preguntar al visitante si puedes usar cookies y rastreadores no esenciales, y registrar la respuesta. El etiquetado del lado del servidor va del procesamiento de los datos que tienes derecho a recoger. No tiene nada que decir sobre la pregunta.

La ley lo lee igual. Que necesites consentimiento depende de qué recojas y de las regiones donde estén tus visitantes, no del servidor en el que se ejecuten tus etiquetas. Un visitante de la UE o del Reino Unido sigue teniendo derecho al consentimiento explícito. Un californiano sigue teniendo derecho a la exclusión. Mueve todas las etiquetas a un contenedor en tu propia nube y el deber sigue exactamente donde estaba.

Por dónde tiene que viajar la señal

Esta es la parte que las guías de los proveedores se saltan. Te dicen que la plataforma de consentimiento transmite la señal a tu servidor y ahí lo dejan, como si fuera automático. No lo es. El banner fija el estado de Consent Mode v2 en el navegador, y ese estado tiene que viajar con la petición que el navegador envía a tu contenedor. En una configuración de Google va como el parámetro gcs. Tu contenedor lo lee y decide qué puede hacer cada etiqueta.

Quédate con la dirección del flujo. La elección se captura en la página y se envía al servidor. El servidor puede respetarla, modelar a su alrededor, enriquecer lo que esté permitido. Lo que no puede hacer es inventar una elección que nunca se tomó. Sin banner no hay señal, y un contenedor al que no le llega nada no cumple por el mero hecho de ser de origen propio. Es un rastreador que nunca preguntó. Si no tienes claro qué modo ejecuta tu sitio, explicamos cómo averiguarlo en qué Consent Mode ejecuta realmente tu sitio, y el montaje en sí, paso a paso, está en cómo pasar la señal de consentimiento a un contenedor de etiquetado del lado del servidor.

Dónde se rompe esto sin hacer ruido

Como las peticiones del lado del servidor salen de tu propio dominio, parecen fiables de una forma en que las del navegador no lo parecen. Justo por eso los fallos aquí se pasan por alto con facilidad.

El que vemos más a menudo es un cliente de GA4 en el contenedor de servidor al que se deja gestionar sus propias cookies. Con ese ajuste, estampa un identificador de origen propio en cada petición entrante, incluidos los pings sin cookies que se enviaron precisamente porque el visitante denegó. Esos pings denegados dejan de ser anónimos y pasan a contarse como sesiones reales. Lo detectamos en una reconstrucción de consentimiento en producción, tras semanas viendo subir el tráfico Unassigned de un cliente sin explicación, y la forma en que inunda tus informes da para un artículo aparte: por qué tu tráfico de GA4 aparece como Unassigned tras añadir un banner de cookies. La solución fue un único ajuste. La lección es que aquí el etiquetado del lado del servidor no hizo el consentimiento más seguro. Hizo la brecha más difícil de ver.

Cómo comprobar que tu configuración respeta el consentimiento

1. Confirma que el banner se sigue disparando primero

   Con servidor o sin él, el valor por defecto de Consent Mode tiene que estar en denegado antes de que se ejecute cualquier etiqueta de Google, en todas las páginas, incluida la primera de la visita. Si el valor por defecto llega después de la etiqueta, el primer hit sale en un estado que nadie eligió.

2. Deniega y observa la petición

   En una ventana de incógnito, rechaza todo y abre el panel de red. Busca la petición que va a tu contenedor de servidor. El parámetro gcs indica el estado, y G100 significa que ambos tipos de almacenamiento están denegados. Esa es la señal sobre la que actuará tu servidor.

3. Comprueba que el ping denegado sigue siendo anónimo

   En esa misma petición denegada, busca un identificador de cliente. Un ping denegado que lleva un id es el fallo de las cookies gestionadas por el servidor, y te inflará las cifras con tráfico que te pidieron dejar en paz.

4. Confirma que las etiquetas de publicidad se contienen

   Con el consentimiento denegado, las etiquetas de publicidad de tu contenedor no deberían reenviar datos identificables. Si se disparan igualmente, el contenedor está leyendo la petición pero no está condicionando nada a ella.

5. Prueba como visitante recurrente

   Vuelve a cargar el sitio con una denegación ya guardada. La configuración que quieres es la que respeta la primera elección en una visita repetida, sin sobrescribirla en silencio.

Cuánto vale de verdad pasarse al lado del servidor

Nada de esto es motivo para evitar el etiquetado del lado del servidor. Bien hecho, es una de las palancas que recupera la medición que un banner te costaría de otro modo. En las implementaciones de clientes de Amplio Data solemos ver alrededor de un 34% de las sesiones detrás del banner, y entre un 20 y un 40% de las conversiones perdidas recuperables una vez que Consent Mode v2 y el etiquetado del lado del servidor están montados como Google espera. 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 tus regiones y de cómo estén configuradas tus etiquetas.

Conviene decirlo claro, porque es donde el tema se enturbia: esa recuperación viene del modelado y de una señal más limpia, no de recoger más de lo que el visitante permitió. El etiquetado del lado del servidor se gana el sueldo respetando mejor la elección, no esquivándola. Para el panorama completo de qué sobrevive de verdad a un rechazo, lo tratamos en qué le pasa a tus datos de GA4 cuando los usuarios rechazan las cookies.

La versión corta

El etiquetado del lado del servidor saca tus etiquetas del navegador del visitante y las lleva a un servidor que controlas tú. No mueve el momento del consentimiento, que sigue en la página, ni elimina el deber de preguntar, que depende de tus regiones y de tus datos. Sigues necesitando el banner. Lo que cambia es que un servidor bien montado le da a ese banner un sitio más limpio donde hacerse respetar, y uno mal montado le da un sitio más limpio donde ser ignorado.

Velo captura la elección en el navegador y la envía con la forma que Google espera, de modo que la parte servidor de tu stack actúa sobre una señal real y no sobre una ausente. El mecanismo está en la página de producto.

¿Vienes nuevo al lado del servidor? El equipo que hay detrás de Velo escribió una respuesta clara sobre qué es el etiquetado del lado del servidor y si de verdad lo necesitas en el blog de Amplio Data.