Server-side tracking y RGPD: qué cambia y qué no

El server-side tracking se suele vender a los equipos de marketing europeos como tres ventajas a la vez: los bloqueadores dejan de bloquear, los datos dejan de filtrarse a los proveedores y el problema del consentimiento desaparece. La primera es en gran parte cierta. La segunda solo lo es si lo configuras así. La tercera es un malentendido, y es la que suele acabar en la bandeja de entrada del DPO.

Este artículo separa el cambio técnico de las preguntas legales. No es asesoramiento jurídico, y las conclusiones sobre una implantación real corresponden a tu DPO y a las guías de tu autoridad nacional. La prueba legal completa para la analítica está en nuestro análisis de RGPD y ePrivacy.

Qué es realmente el server-side tracking

En una implantación client-side, las etiquetas del navegador envían los datos directamente a cada proveedor. En una server-side, el navegador envía los datos a un servidor que gestionas tú, normalmente en un subdominio de tu web, y ese servidor decide qué reenvía a cada proveedor. El etiquetado server-side de Google funciona así: un contenedor de servidor procesa los eventos que llegan y los dirige a servidores de recogida.

Hay dos cosas que no cambian. Sigue habiendo código en el navegador que recoge y envía los datos. Y salvo que los elimines, los datos que llegan a tu servidor —dirección IP, user agent, cookies, parámetros de URL— son los mismos que antes iban directamente al proveedor.

Tres preguntas legales que un contenedor de servidor no responde

1. ¿Se guarda algo en el dispositivo o se lee de él?

El artículo 5(3) de la Directiva ePrivacy exige consentimiento para guardar información en el dispositivo de un usuario, o acceder a la ya guardada, salvo que se aplique una exención. El EDPB, citando al Tribunal de Justicia en Planet49, afirma que esa protección se aplica a cualquier información guardada en el dispositivo, sea o no dato personal. Dónde se procesen después los datos es irrelevante para este paso.

Las implantaciones server-side mantienen a menudo una cookie first-party, muchas veces fijada por el propio contenedor de servidor para que sobreviva a los límites de los navegadores con las cookies escritas por JavaScript. Sigue guardada en el dispositivo. Y en sus Directrices 2/2023, adoptadas en su versión final en octubre de 2024, el EDPB va más allá: el JavaScript que ordena al navegador enviar peticiones asíncronas con la información buscada entra en el artículo 5(3), igual que los píxeles de seguimiento, las URL de seguimiento y, en algunos casos, el seguimiento basado solo en la dirección IP. Las mismas directrices recuerdan que su aplicación no implica sistemáticamente que haya que recoger consentimiento: las exenciones hay que valorarlas.

2. ¿Se tratan datos personales, y con qué base?

El RGPD se aplica siempre que se tratan datos personales, en tu servidor o en el de cualquiera. Las direcciones IP, los client IDs y los user IDs que llegan a un contenedor de servidor los tratas tú como responsable, y todo lo que reenvías convierte al proveedor en destinatario. Una arquitectura server-side necesita la misma base legal, los mismos registros y los mismos contratos que la client-side a la que sustituye.

3. ¿Salen datos de la UE?

Alojar el contenedor en la UE no cambia lo que pasa después. Si reenvía datos personales a un proveedor que los trata fuera de la UE, eso es una transferencia y necesita un mecanismo que la ampare. El server-side solo evita la transferencia si no reenvía nada personal, o si no reenvía a nadie fuera de la UE.

Lo que el server-side sí puede cambiar

Usado a propósito, un servidor intermedio es un buen sitio para minimizar. El ejemplo público más claro es la guía de la CNIL de 2022 sobre medición de audiencia y transferencias de datos, que describía un proxy para Google Analytics capaz de reducir el riesgo de transferencia solo con un conjunto de medidas:

• No transferir la dirección IP del visitante a los servidores de la herramienta.
• Sustituir el identificador de usuario en el servidor proxy.
• Eliminar cualquier parámetro contenido en las URL recogidas.
• Suprimir el referrer externo y retratar los user agents.
• No recoger datos entre sitios y eliminar cualquier dato que permita reidentificar.
• Un alojamiento que evite transferencias a países sin una protección esencialmente equivalente.

La CNIL añadió que cambiar solo la configuración de la IP en la herramienta no basta. Además de minimizar, el server-side puede llevar el procesamiento a una ubicación de la UE que elijas, reducir el número de scripts de terceros en tus páginas y hacer mucho menos probable el bloqueo cuando el endpoint es tu propio subdominio.

El coste en atribución de hacerlo bien

Relee la lista de la CNIL con ojos de marketing. Eliminar los parámetros de las URL quita las UTM y los click IDs sobre los que se construye cualquier informe de campañas. Suprimir el referrer externo quita la señal que distingue búsqueda, redes y referencias. Sustituir el identificador corta el historial que necesitan los modelos de atribución por usuario. Un proxy configurado con esas condiciones mantiene la herramienta funcionando y la deja con poco que decir sobre qué canales produjeron los ingresos.

Ese es el verdadero equilibrio detrás del “server-side para cumplir”: cuantos más datos personales e identificadores quitas, menos sobrevive de la atribución por la que compraste la herramienta. Es la misma tensión, vista desde otro ángulo, que se explica en Consent Mode: qué mide GA4 y qué modela.

Cinco afirmaciones que conviene comprobar antes de aprobar un proyecto server-side

Una lista de revisión para el DPO

1. Dispositivo: enumera cada cookie, clave de almacenamiento y petición iniciada por script, incluidas las que fija o desencadena el servidor.
2. Datos de entrada: enumera los campos que llegan al servidor: IP, user agent, identificadores, URL completas, referrer.
3. Datos de salida: para cada proveedor, los campos que se reenvían tras el procesamiento, y si alguno identifica a una persona.
4. Ubicación: dónde se ejecuta el contenedor y dónde trata los datos cada destinatario.
5. Conservación: cuánto tiempo se guardan en el servidor los eventos en bruto y los registros.
6. Consentimiento: qué reglas de reenvío dependen del estado de consentimiento del visitante y cómo llega ese estado al servidor.

Dónde encaja Sealmetrics, y dónde no

Sealmetrics no es un contenedor de servidor para otros proveedores. Un pequeño script en el navegador envía cada hit a Sealmetrics, si quieres a través de un subdominio propio, y el procesamiento se hace en servidores en Dublín; en Shopify, las compras llegan en servidor por el webhook de la tienda. No instala cookies ni usa almacenamiento local o de sesión. No conserva direcciones IP —se usan solo en memoria— ni identificadores de usuario; un marcador de sesión vive en memoria unas dos horas; el país sale de la zona horaria del navegador; y las filas de eventos se borran al día. Los detalles están en demostrar cumplimiento.

Como no reenvía nada a proveedores publicitarios, conserva las UTM y el referrer de la página de llegada, que es lo que necesita la atribución de campañas. Pero no se libra del análisis anterior. Según la lectura del EDPB, un script que envía información desde el navegador puede entrar en el artículo 5(3), así que la pregunta para cualquier herramienta de analítica —también la nuestra— es si se aplica una exención a esa configuración en tu mercado. Varias autoridades, entre ellas la CNIL, publican criterios para la medición de audiencia que puede usarse sin consentimiento; valorar si una implantación los cumple te corresponde a ti y a tu DPO. El concepto se explica en analítica sin consentimiento.