Etiquetado del lado del servidor y consentimiento: qué cambia y qué no

El etiquetado del lado del servidor traslada las etiquetas de los proveedores del navegador del visitante a un servidor que tú controlas: la página envía eventos a tu endpoint y tu servidor los reenvía a las plataformas de analítica y publicidad. Eso puede mejorar el rendimiento y el control de los datos, pero no elimina los requisitos de consentimiento. Las cookies y los identificadores siguen residiendo en el dispositivo del visitante, y los datos personales siguen llegando a los proveedores.

¿Qué es el etiquetado del lado del servidor?

Es una configuración en la que la página envía un único flujo de eventos a un servidor de etiquetado, y es ese servidor, y no el navegador, el que llama a cada proveedor. El servidor suele ejecutarse en un subdominio de tu sitio, como metrics.example.com.

Los contenedores del lado del servidor de Google Tag Manager son un ejemplo conocido, pero el mismo patrón funciona con una función edge o con una pequeña API que escribas tú mismo. En una configuración clásica del lado del cliente, el script de cada proveedor se ejecuta en el navegador del visitante y decide qué recopilar. En una configuración del lado del servidor, el navegador carga menos código de proveedores, y estos reciben lo que tu servidor decide enviarles.

¿Qué cambia al trasladar las etiquetas al servidor?

Sobre todo, el rendimiento y el control. Las ventajas habituales:

• Menos código en el navegador. Menos scripts de proveedores significa menos JavaScript que descargar y ejecutar, lo que mejora la carga y la capacidad de respuesta.
• Un lugar para depurar los datos. Tu servidor puede inspeccionar cada evento antes de reenviarlo: eliminar o truncar direcciones IP, quitar parámetros de URL que pueden contener direcciones de correo electrónico y suprimir los campos que un proveedor no necesita.
• Una mecánica de cookies distinta. Tu servidor puede instalar cookies propias mediante cabeceras HTTP Set-Cookie en lugar de JavaScript. En algunos casos, los navegadores tratan de forma distinta las cookies instaladas por scripts y las instaladas por el servidor, y esas reglas cambian constantemente, así que no planifiques en función de una duración concreta de las cookies.
• Menos conexiones directas con terceros. El navegador del visitante se comunica con tu dominio en lugar de con cada proveedor.

¿Qué no cambia?

El análisis jurídico. A la Directiva ePrivacy y al RGPD les importa lo que ocurre en el dispositivo y lo que les pasa a los datos personales, no qué servidor hay en medio.

Pregunta	Etiquetado del lado del cliente	Etiquetado del lado del servidor
¿Se almacenan identificadores en el dispositivo del visitante?	Sí, los instalan los scripts de los proveedores	Normalmente sí, los instala tu dominio
¿Se aplica el consentimiento de ePrivacy al almacenamiento y acceso no esenciales?	Sí	Sí
¿Llegan datos personales a los proveedores?	Sí, desde el navegador	Sí, desde tu servidor
¿Necesita cada finalidad una base jurídica del RGPD?	Sí	Sí
¿Hay que informar a los visitantes de los destinatarios?	Sí	Sí
¿Quién decide lo que recibe cada proveedor?	En gran medida, el script del proveedor	Tú

El artículo 5, apartado 3, de la Directiva ePrivacy trata del almacenamiento de información en el dispositivo y del acceso a ella. Si tu servidor instala una cookie con un identificador de analítica y la vuelve a leer en cada solicitud, eso es almacenamiento y acceso en el dispositivo, sea cual sea el dominio o el código que lo haga. La excepción depende de la finalidad, es decir, de que sea estrictamente necesaria para un servicio solicitado por el usuario, no de que la cookie sea propia; consulta tipos de cookies.

El RGPD también se aplica a los datos de los eventos. Los identificadores, las direcciones IP y las URL de página relacionadas con una persona son datos personales, así que cada flujo hacia un proveedor necesita una base jurídica conforme al artículo 6 y, cuando esa base es el consentimiento, debe cumplir las condiciones del artículo 7. Si lo que de verdad quieres es medir sin identificadores, la analítica sin cookies es otro tema.

¿Cómo paso el consentimiento al servidor?

Envía el estado del consentimiento con cada evento, aplícalo en el servidor y trata cualquier ausencia como denegación. El servidor tiene que decidir por destino, porque un mismo evento entrante puede distribuirse a varios proveedores con finalidades distintas.

En el cliente, no envíes nada sin consentimiento e incluye el estado en la carga útil:

type ConsentState = { analytics: boolean; marketing: boolean };

export function track(event: string, props: Record<string, unknown>, consent: ConsentState) {
  if (!consent.analytics && !consent.marketing) return; // no se puede enviar nada
  navigator.sendBeacon(
    'https://metrics.example.com/collect',
    JSON.stringify({ event, props, consent, ts: Date.now() }),
  );
}

En el servidor, reenvía a cada destino solo lo que permite su categoría:

export async function handleCollect(req: Request): Promise<Response> {
  const body = await req.json().catch(() => null);
  const analytics = body?.consent?.analytics === true; // si falta, se considera denegado
  const marketing = body?.consent?.marketing === true;
  if (!analytics && !marketing) return new Response(null, { status: 204 });

  const event = minimize(body); // eliminar IP, quitar query strings, suprimir campos no usados
  const jobs: Promise<unknown>[] = [];
  if (analytics) jobs.push(sendToAnalytics(event));
  if (marketing) jobs.push(sendToAdPlatform(event));
  await Promise.allSettled(jobs);

  return new Response(null, { status: 204 });
}

Si usas etiquetas de Google con el modo de consentimiento, el estado del consentimiento viaja con las solicitudes que envían las etiquetas, y Google documenta cómo se comportan sus etiquetas con cada señal. Comprueba que todas las etiquetas de tu contenedor del servidor, en especial las plantillas de terceros, respetan realmente ese estado en lugar de darlo por hecho. Nuestra guía de Google Consent Mode v2 explica las cuatro señales.

¿Qué debe hacer mi servidor con los datos?

Trata el servidor de etiquetado como un sistema de tratamiento de datos con sus propias reglas, no como una simple tubería:

1. Deniega por defecto. Descarta los eventos con campos de consentimiento ausentes o mal formados.
2. Enruta por finalidad. Envía a los proveedores de analítica solo los eventos con consentimiento para analítica, y a los proveedores publicitarios solo los eventos con consentimiento para marketing.
3. Minimiza antes de reenviar. Trunca o elimina las direcciones IP, quita las query strings y los fragmentos, y envía a cada proveedor solo los campos que necesita.
4. Limita la conservación. Los registros de eventos sin procesar de tu servidor también son datos personales. Fija plazos de conservación cortos y restringe el acceso.
5. Documenta cada flujo. Enumera cada proveedor, los datos que recibe y la finalidad en tu aviso de privacidad y en tu política de cookies, porque los visitantes ya no pueden ver estos flujos en su navegador.
6. Audita ambos lados. Los escáneres basados en el navegador no pueden ver el tráfico de servidor a servidor, así que combina una auditoría de cookies periódica con una revisión de las etiquetas y los destinos de tu contenedor del servidor.

En resumen

El etiquetado del lado del servidor cambia dónde se ejecutan las etiquetas y te da más control sobre lo que reciben los proveedores. No cambia cuándo necesitas consentimiento, qué se considera un dato personal ni qué debes comunicar. Haz que el consentimiento forme parte de cada evento, aplícalo en el servidor y minimiza lo que sale de él. Herramientas como Cookiesh pueden proporcionar el estado de consentimiento que necesitan tus etiquetas y tu servidor, mediante su compatibilidad con Google Consent Mode v2, una plantilla para Google Tag Manager y una API de JavaScript.

Este artículo ofrece información general y no constituye asesoramiento jurídico. Para tomar decisiones sobre tu situación concreta, consulta a un profesional cualificado en privacidad.