Etiquetado y seguimiento del lado del servidor: por qué el consentimiento del RGPD sigue siendo obligatorio

Los gestores de etiquetas se están trasladando al servidor. El contenedor de servidor de Google Tag Manager, Tealium EventStream, Adobe Event Forwarding, Segment y servicios alojados como Stape te permiten enviar eventos a un servidor que controlas tú y reenviarlos desde allí, ya sea en un subdominio como data.example.com o en una ruta de tu dominio principal como example.com/metrics. Nada de esto cambia lo que exigen el RGPD y las reglas de ePrivacy: consentimiento antes de las cookies de analítica y publicidad, y una base jurídica para cada dato personal que envías a una plataforma publicitaria o de analítica.

Lo que cambia es el camino que tiene que recorrer el consentimiento. El banner sigue funcionando en el navegador, pero la decisión de enviar datos a un proveedor se toma ahora en tu servidor, así que la elección del visitante tiene que viajar con cada evento.

Etiquetado y seguimiento del lado del servidor: por qué el consentimiento del RGPD sigue siendo obligatorio

Dos formas de ejecutar etiquetas en tu propio dominio

	Subdominio	Ruta en tu dominio principal
Ejemplo	data.example.com	example.com/metrics
Cómo se configura	Un registro DNS apunta el subdominio a tu servidor de etiquetado	Tu CDN o proxy inverso dirige la ruta a tu servidor de etiquetado
Qué cambia	Las solicitudes y las cookies son propias	Las solicitudes son del mismo origen, así que los scripts de las etiquetas y los eventos se cargan como el resto de tu sitio
Sigue necesitando consentimiento	Sí	Sí

Safari limita la duración de las cookies creadas por un subdominio que apunta a una dirección IP distinta de la de tu sitio principal, y esa es una de las razones por las que cada vez más configuraciones usan una ruta en el dominio principal. Para el consentimiento, la elección no cambia nada: en los dos casos las etiquetas y las cookies son tuyas, y la responsabilidad también.

Por qué el etiquetado del lado del servidor no elimina el consentimiento

Hay cuatro ideas que se oyen a menudo, y ninguna se sostiene.

• «Las cookies del servidor no son cookies». Una cookie que crea tu servidor se sigue guardando en el dispositivo del visitante. Las reglas de ePrivacy regulan el almacenamiento y la lectura de información en un dispositivo, sea quien sea quien la cree.
• «Si es propia, está exenta». No existe ninguna excepción para las cookies propias. Una cookie propia que se usa para analítica o publicidad necesita consentimiento igual que una de terceros. El Digital Omnibus de la UE podría eximir en el futuro parte de la medición propia, pero de momento es un texto en negociación, no una ley.
• «El navegador nunca habla con el proveedor, así que no hay problema». El RGPD se aplica a los datos personales que reenvías, como direcciones IP, correos electrónicos con hash y detalles de pedidos, tanto si salen del navegador como de tu servidor.
• «Los bloqueadores de anuncios no lo ven, así que no cuenta». Ocultar las solicitudes a los bloqueadores no cambia la obligación legal. Lo que puedes recoger lo sigue decidiendo la elección del visitante en tu banner.

El etiquetado del lado del servidor sigue mereciendo la pena. Decides qué sale de tu infraestructura: puedes eliminar direcciones IP, acortar los user agents y quitar los campos que un proveedor no necesita antes de reenviar, lo que favorece la minimización de datos que exige el RGPD. Solo necesita la misma señal de consentimiento que las etiquetas del navegador, entregada de otra forma.

Dónde fallan las configuraciones del lado del servidor

El servidor reenvía eventos sin comprobar el consentimiento

Un contenedor de servidor o un pipeline de eventos reenvía lo que recibe. Las etiquetas de Google leen Google Consent Mode y ajustan lo que envían, pero la mayoría de los demás conectores, como la Meta Conversions API, la TikTok Events API, LinkedIn y la OpenAI Conversions API que se usa para los anuncios de ChatGPT, no comprueban el consentimiento por sí solos. Si se dejan con la configuración por defecto, envían todos los eventos, incluidos los de visitantes que rechazaron.

Los scripts de tu propio dominio se ejecutan antes que el banner

Cuando tu gestor de etiquetas o tu CDN sirve los scripts de las etiquetas desde tu dominio y los añade a tus páginas, es posible que dejes de controlar el orden en que se cargan. Si se ejecutan antes de que tu CMP haya establecido el consentimiento, pueden crear cookies y enviar datos antes de que el visitante haya visto el banner. Es lo que se conoce como una señal de consentimiento tardía. La configuración de CDN en un clic de Google Tag Gateway es un ejemplo habitual.

Las comprobaciones basadas en dominios dejan de funcionar

Los bloqueadores de scripts y las auditorías de etiquetas sencillas reconocen los rastreadores por sus dominios. Cuando todo se carga desde tu propio dominio, no pueden distinguir un rastreador de tu propio código, así que comprueba el consentimiento a partir de las solicitudes que tu sitio envía realmente.

Las cookies que crea el servidor no aparecen en la política de cookies

Las cookies que crea tu servidor de etiquetado llevan tu dominio y es fácil pasarlas por alto. Aun así, tienen que aparecer en tu política de cookies y estar cubiertas por el banner. Un escaneo de cookies también detecta las cookies propias.

Cómo pasar el consentimiento a las etiquetas del lado del servidor

1. Carga primero la CMP. Si tus etiquetas se cargan desde tu propio dominio, sirve el banner de la misma forma para que no sea más lento que las etiquetas: UniConsent admite un dominio propio para la CMP.
2. Envía la elección con cada evento. Añade el estado del consentimiento a cada evento que el navegador envía a tu servidor: los valores de Google Consent Mode para Google, la cadena IAB TCF para los proveedores publicitarios que la leen, y marcas por finalidad o por vendor para todos los demás.
3. Comprueba el consentimiento en el servidor antes de reenviar. Cada conector de proveedor se activa solo cuando la finalidad o el vendor correspondiente está permitido.
4. Guarda un registro. Envía el ID de consentimiento con cada evento para poder demostrar en qué elección se basó cada evento reenviado.

En Google Tag Manager del lado del servidor, la configuración más habitual, las propias etiquetas de Google pasan Consent Mode al contenedor de servidor por ti, así que Google Analytics y Google Ads respetan la elección del visitante. Las demás etiquetas del contenedor no lo hacen. Reenvía desde el contenedor web el valor de consentimiento que necesites y añádelo al activador de cada etiqueta de Meta, TikTok, LinkedIn u OpenAI.

Cómo encaja UniConsent en cualquier configuración del lado del servidor

UniConsent funciona con cualquier gestor de etiquetas que uses en el servidor. Recoge la elección del visitante una sola vez y la pone a disposición del cliente de navegador de tu gestor de etiquetas:

• a través de la Consent Ready API y la JavaScript API, incluido el ID de consentimiento;
• como valores de Google Consent Mode v2, establecidos en denegado para los visitantes de la UE, el EEE, el Reino Unido y Suiza antes de que se ejecute cualquier etiqueta de Google;
• como cadenas IAB TCF y GPP para los proveedores publicitarios que las leen;
• por finalidad, categoría y vendor en la capa de datos, para todas las demás etiquetas.

UniConsent es una CMP certificada por Google y una CMP registrada en el IAB TCF. Incluye etiquetas de consentimiento listas para usar para el Meta Pixel, el TikTok Pixel y Microsoft UET, y vendors personalizados para plataformas que no están en el IAB TCF, como OpenAI. Consent Logging guarda un registro de cada elección. Para las herramientas del lado del servidor de Google, consulta las guías de configuración de GTM del lado del servidor y Google Tag Gateway.

Empieza una prueba gratuita o revisa tu sitio ahora con el Consent Mode Checker gratuito.

Lista de comprobación del consentimiento en el etiquetado del lado del servidor

• La CMP se carga antes que cualquier etiqueta, incluidos los scripts que se sirven desde tu propio dominio.
• Cada evento que se envía a tu servidor lleva el estado de consentimiento del visitante.
• Cada conector de proveedor en el servidor se activa solo con el consentimiento correspondiente.
• Los campos que un proveedor no necesita se eliminan en el servidor antes de reenviar.
• Las cookies que crea tu servidor aparecen en tu política de cookies.
• Rechazar en el banner detiene todo el tráfico de tu servidor hacia plataformas publicitarias. Pruébalo antes de publicar.

Preguntas frecuentes

¿El etiquetado del lado del servidor hace que mi sitio cumpla el RGPD?

No. Te da más control sobre los datos que envías, lo que ayuda, pero sigue haciendo falta consentimiento para las cookies de publicidad y analítica y para compartir datos personales con plataformas publicitarias y de analítica.

¿Necesito un banner de cookies si mis etiquetas se ejecutan en mi propio dominio?

Sí, si usas cookies o tecnologías similares para analítica o publicidad y tienes visitantes en la UE, el EEE o el Reino Unido. Las cookies que se crean desde tu propio dominio siguen siendo cookies.

¿Es mejor un subdominio o una ruta en mi dominio principal para el consentimiento?

Ninguno de los dos cambia las reglas del consentimiento. Una ruta en el dominio principal evita el límite de cookies de Safari para subdominios con otra dirección IP, pero los scripts que se sirven así pueden cargarse antes que el banner si no controlas el orden.

¿Puede mi servidor leer la cadena IAB TCF?

Sí. Envía la cadena TC con cada evento. Tu servidor puede comprobar finalidades y vendors antes de reenviar, y los proveedores compatibles con el TCF pueden leerla por sí mismos.

¿Google Tag Gateway evita el consentimiento?

No. Las etiquetas siguen respetando Google Consent Mode, siempre que tu CMP establezca el consentimiento antes de que se ejecuten. UniConsent está pensado para hacerlo.