¿Necesitas banner de cookies si usas etiquetado en servidor?

Todos los artículos

Sí, sigues necesitando un banner de cookies aunque uses etiquetado en servidor. El etiquetado en servidor cambia el lugar donde se ejecutan tus etiquetas: del navegador del visitante a un contenedor en un servidor que controlas tú. Lo que no cambia es si puedes recoger esos datos. Eso lo decide el consentimiento, y el consentimiento es justo lo que recoge el banner.

Qué mueve de verdad el etiquetado en servidor

La confusión es lógica, porque el etiquetado en 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 tuyo, y es ese contenedor el que habla con Google, Meta y todos los demás. Ganas peticiones de origen propio desde tu dominio, cookies que duran más y la posibilidad de limpiar o descartar datos antes de que salgan.

Nada de eso afecta al momento en que el visitante decide qué va a permitir. Esa decisión se toma en la página, antes de que arranque toda la maquinaria del servidor. Así se reparte el trabajo.

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 guardar la respuesta. El etiquetado en servidor va de procesar los datos que tienes permiso para recoger. Sobre la pregunta no tiene nada que decir.

La ley lo ve igual. Que necesites consentimiento depende de lo que recoges y de las regiones en las que están tus visitantes, no del servidor en el que se ejecutan tus etiquetas. En la UE, el artículo 5.3 de la Directiva ePrivacy exige consentimiento antes de guardar información en el dispositivo del visitante o de leerla, salvo que sea estrictamente necesario. Ese guardado y esa lectura ocurren en el navegador. A un visitante de la UE o del Reino Unido hay que seguir pidiéndole consentimiento previo. A uno de California hay que seguir ofreciéndole la exclusión. Lleva todas las etiquetas a un contenedor en tu propia nube y la obligación seguirá exactamente donde estaba.

Por dónde tiene que viajar la señal

Esta es la parte que se saltan las guías de los proveedores. Te dicen que la plataforma de consentimiento transmite la señal a tu servidor y ahí lo dejan, como si pasara solo. No pasa solo. 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 en el parámetro gcs. Tu contenedor lo lee y decide qué puede hacer cada etiqueta.

No pierdas de vista la dirección. La elección se recoge en la página y se envía al servidor. El servidor puede respetarla, modelar a partir de ella y enriquecer lo que esté permitido. Lo que no puede es inventarse una elección que nunca se hizo. 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 ni siquiera sabes qué modo usa tu web, te explicamos cómo averiguarlo en Consent Mode básico o avanzado: ¿cuál estás usando?, y la configuración en sí, paso a paso, está en Cómo pasar la señal de consentimiento al contenedor de servidor.

Dónde se rompe esto sin que nadie lo note

Como las peticiones del servidor salen de tu propio dominio, inspiran una confianza que las del navegador no inspiran. Justo por eso aquí los fallos se escapan con facilidad.

El que más vemos es un cliente de GA4 en el contenedor de servidor al que se deja gestionar sus propias cookies. Con ese ajuste, pone un identificador de origen propio en cada petición entrante, incluidos los pings sin cookies que se enviaron precisamente porque el visitante había rechazado. Esos pings dejan de ser anónimos y empiezan a contarse como sesiones reales. Lo encontramos al rehacer el consentimiento de una web en producción, después de semanas viendo cómo subía sin explicación el tráfico Unassigned de un cliente, y cómo te inunda los informes da para un artículo aparte: Por qué tu tráfico de GA4 aparece como Unassigned tras poner un banner. El arreglo fue un solo ajuste. La lección es que aquí el etiquetado en servidor no hizo más seguro el consentimiento. Hizo más difícil detectar el incumplimiento.

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

1. Confirma que el banner sigue cargándose antes que nada

   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 con un estado que nadie eligió.

2. Rechaza y observa la petición

   En una ventana de incógnito, recházalo 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 los dos tipos de almacenamiento están denegados. Esa es la señal con la que va a 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 con un id es el fallo de las cookies gestionadas por el servidor, y te va a inflar las cifras con tráfico que te pidieron dejar en paz.

4. Confirma que las etiquetas publicitarias se quedan quietas

   Con el consentimiento denegado, las etiquetas publicitarias de tu contenedor no deberían reenviar datos identificables. Si se disparan igualmente, el contenedor lee la petición pero no la usa para bloquear nada.

5. Prueba como visitante recurrente

   Vuelve a cargar la web con un rechazo ya guardado. Lo que quieres es una configuración que respete la primera elección en la visita siguiente, sin sobrescribirla a escondidas.

Qué ganas de verdad pasándote al servidor

Nada de esto es motivo para evitar el etiquetado en servidor. Bien hecho, te da datos más limpios y un único punto donde aplicar la elección del visitante. La parte de tu tráfico que se queda detrás del banner varía según la región, la audiencia y el diseño del banner, así que mide la tuya. Mira la tasa de consentimiento en tu CMP, o compara las sesiones de GA4 con las peticiones que registró tu servidor o tu CDN en los mismos días.

Conviene decirlo claro, porque es aquí donde el tema se enreda: lo que ganes viene de una señal más limpia y, cuando se cumplen los umbrales de elegibilidad de Google, del modelado. Nunca de recoger más de lo que el visitante permitió. El etiquetado en servidor se gana el sueldo respetando mejor la elección, no esquivándola. Para ver en conjunto qué sobrevive de verdad a un rechazo, lo tratamos en Qué pasa con tus datos de GA4 cuando rechazan las cookies.

La versión corta

El etiquetado en 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 la obligación de preguntar, que depende de tus regiones y de tus datos. Sigues necesitando el banner. Lo que cambia es que, con un servidor bien configurado, lo que diga el banner se respeta de forma más limpia; con uno mal configurado, se ignora de forma igual de limpia.

Velo recoge la elección en el navegador y la envía con el formato que espera Google, así que la parte de servidor de tu stack trabaja con una señal real y no con una que falta. Cómo funciona lo tienes en la página de producto.

¿Te estrenas con el etiquetado en servidor? El equipo que está detrás de Velo explica sin rodeos qué es el etiquetado en servidor y si de verdad lo necesitas en el blog de Amplio Data.