Resumen
El server-side tagging traslada la recogida de datos del navegador del usuario a un servidor que usted controla. Esto le permite filtrar, anonimizar o bloquear datos antes de enviarlos a terceros (Google, Facebook, etc.), sortear los bloqueadores de anuncios y las restricciones de los navegadores (ITP de Safari, retirada de las cookies de terceros en Chrome) y ampliar la vida útil de las cookies propias. Sin embargo, el server-side tagging no elimina la obligación de consentimiento: si recoge datos personales, se aplican el RGPD y la Directiva ePrivacy, tanto si el tracking es client-side como server-side.
¿Qué es el server-side tagging?
El server-side tagging (etiquetado del lado del servidor) es un método de recogida de datos que traslada la ejecución de las etiquetas (scripts de seguimiento) desde el navegador del usuario a un contenedor de servidor gestionado por su organización. En lugar de que el navegador del usuario envíe los datos directamente a Google Analytics, Facebook u otros servicios de terceros, los datos pasan primero por su servidor, que decide qué transmitir, a quién y de qué forma.
En el modelo tradicional client-side (el modelo dominante hasta ahora), cada etiqueta de terceros se carga en el navegador del usuario. Esto significa que Google, Facebook y todos los demás servicios de terceros reciben los datos directamente del navegador, sin que usted pueda controlar con precisión lo que se transmite.
Con el server-side tagging, el navegador solo envía datos a su servidor (normalmente un subdominio de su propio dominio, como analytics.yoursite.com). Después, su servidor procesa esos datos y los redistribuye a los servicios de terceros mediante conexiones de servidor a servidor. Así tiene control total sobre los datos que salen de su infraestructura.
¿Por qué el server-side tagging gana terreno en 2026?
Varios factores convergen para convertir el server-side tagging en el nuevo estándar de recogida de datos.
Restricciones de los navegadores
Safari (ITP) limita a 7 días las cookies creadas por JavaScript y bloquea las cookies de terceros desde 2020. La protección mejorada contra el rastreo de Firefox bloquea por defecto los scripts de seguimiento conocidos. Chrome empezó a restringir las cookies de terceros en 2025. Estas restricciones reducen la vida útil y la fiabilidad de las cookies client-side, lo que degrada la calidad de los datos de analítica y publicidad.
Bloqueadores de anuncios
Más del 40 % del público tecnológico en Europa y Norteamérica utiliza bloqueadores de anuncios. Estas herramientas bloquean las etiquetas client-side (GTM, GA4, Meta Pixel) a partir de listas de dominios conocidos. El server-side tagging desplegado en un subdominio propio es invisible para estos bloqueadores, porque las peticiones parecen proceder de su propio dominio.
Control de los datos
El server-side tagging le permite filtrar, anonimizar o eliminar datos antes de enviarlos a terceros. Por ejemplo, puede eliminar la dirección IP del usuario antes de enviar los datos a Google Analytics, o aplicar un hash a las direcciones de correo electrónico antes de transmitirlas a Facebook para las conversiones. Este control es un elemento clave del cumplimiento del RGPD (principio de minimización de datos).
Eliminar la dirección IP no resuelve, sin embargo, todas las dudas sobre la herramienta de Google, como explica nuestro análisis sobre si Google Analytics es conforme al RGPD.
Rendimiento del sitio
Cada etiqueta client-side carga un script en el navegador, lo que ralentiza la carga de la página. Al trasladar el procesamiento al servidor, disminuye el número de scripts en el navegador, lo que mejora la velocidad de carga y, por extensión, el SEO y la experiencia de usuario.
¿El server-side tagging elimina la obligación de consentimiento?
No. Es el mito más extendido y el más peligroso. El server-side tagging no elimina la obligación de consentimiento prevista en el RGPD y la Directiva ePrivacy.
La Directiva ePrivacy (artículo 5, apartado 3, transpuesto en Francia por el artículo 82 de la Ley de Protección de Datos) exige el consentimiento para cualquier acceso a información almacenada en el terminal del usuario o cualquier almacenamiento en él, salvo para las cookies estrictamente necesarias. Si su implementación server-side coloca cookies propias para identificar a los usuarios, el consentimiento es obligatorio.
El RGPD se aplica a cualquier tratamiento de datos personales. Las direcciones IP, los identificadores de cliente, los user agents y otra información transmitida en las peticiones HTTP constituyen datos personales según el RGPD. Aunque elimine las cookies, el mero hecho de recoger y procesar estos datos en su servidor constituye un tratamiento que requiere una base jurídica (consentimiento, interés legítimo, etc.).
En resumen: el server-side tagging cambia el «dónde» y el «cómo» de la recogida, no el «si». Sigue necesitando un banner de cookies conforme y una CMP para obtener el consentimiento antes de recoger datos no esenciales.
Lo que el server-side tagging cambia realmente para el consentimiento
Aunque el server-side tagging no elimina la obligación de consentimiento, sí cambia de forma significativa cómo se aplica técnicamente el consentimiento.
Aplicación del consentimiento en el servidor
En modo client-side, el bloqueo de etiquetas depende del navegador: la CMP debe impedir que los scripts se carguen antes del consentimiento. Si un script se carga de todos modos (error de configuración, problema de timing, caché), la cookie se coloca. En modo server-side, el consentimiento puede verificarse en el servidor antes de transmitir los datos a terceros. Esto constituye una capa de verificación adicional, más fiable que el bloqueo client-side por sí solo.
Filtrado y anonimización de datos
El servidor puede eliminar o anonimizar datos personales antes de transmitirlos. Por ejemplo: eliminar la dirección IP antes del envío a GA4, aplicar un hash a los correos electrónicos para las API de conversión (Facebook CAPI, Google Enhanced Conversions) o eliminar parámetros de URL que contengan identificadores personales.
En el caso de Meta, nuestra guía sobre Meta Pixel, cookies y cumplimiento del RGPD explica cómo mantener el píxel bloqueado hasta que el visitante dé su consentimiento.
Cookies propias con mayor vida útil
Las cookies definidas por el servidor (mediante cabeceras HTTP Set-Cookie en la respuesta) no están sujetas a las mismas restricciones que las cookies creadas por JavaScript. El ITP de Safari limita las cookies JavaScript a 7 días, pero las cookies server-side (creadas desde un subdominio propio) pueden tener una vida útil más larga. Esto mejora la calidad del seguimiento de los visitantes recurrentes, pero no cambia la obligación de consentimiento para estas cookies.
Cómo integrar el server-side tagging con Consent Mode
Consent Mode v2 funciona tanto en modo client-side como en modo server-side. En una arquitectura server-side, el flujo es el siguiente.
La CMP recoge el consentimiento en el lado del cliente (en el navegador). El estado del consentimiento se transmite al contenedor de servidor de GTM con cada evento. El contenedor de servidor comprueba el estado del consentimiento antes de transmitir datos a servicios de terceros. Si el consentimiento es «denied», los datos no se transmiten (modo básico) o se transmiten como pings anonimizados (modo avanzado).
Para la parte del cliente, la documentación de Consent Mode v2 de FlowConsent explica cómo se fijan los valores predeterminados en «denied» antes de que se cargue cualquier etiqueta.
Esta arquitectura ofrece una doble verificación: la CMP bloquea los scripts en el lado del cliente y el servidor verifica el consentimiento antes de cada transmisión. Es la configuración más sólida para garantizar que los datos no salgan de su infraestructura sin consentimiento.
Para comprobar en la práctica que se respetan los rechazos, la verificación de cumplimiento de FlowConsent escanea sus páginas rechazando el consentimiento y conserva la prueba.
Errores frecuentes (y cómo evitarlos)
Creer que el server-side tagging elimina la necesidad de consentimiento. Es falso. El RGPD y la Directiva ePrivacy se aplican tanto si el tracking es client-side como server-side. Solución: mantenga su banner de consentimiento y su CMP, incluso con una arquitectura server-side.
Usar el server-side tagging para sortear los bloqueadores sin consentimiento. Desplegar el tracking en un subdominio propio para sortear los bloqueadores de anuncios es técnicamente posible, pero hacerlo sin consentimiento supone recoger datos infringiendo el RGPD. Solución: sortear los bloqueadores de anuncios solo es legal para los usuarios que han dado su consentimiento.
Olvidar que las cookies server-side también requieren consentimiento. Una cookie colocada mediante una cabecera HTTP Set-Cookie desde su servidor sigue siendo una cookie según la Directiva ePrivacy. Si no es estrictamente necesaria, se requiere consentimiento. Solución: incluya las cookies server-side en su política de cookies y en la configuración de su CMP.
No auditar los datos que transmite el servidor. El server-side tagging le da el control, pero ese control no sirve de nada si no verifica lo que realmente se transmite. Solución: audite con regularidad los flujos de datos salientes de su contenedor de servidor para comprobar que los datos personales se filtran o anonimizan correctamente.
En el lado del navegador, una auditoría completa de las cookies de su sitio sigue siendo el punto de partida para saber qué se instala realmente en los dispositivos de sus visitantes.
Subestimar la complejidad técnica. El server-side tagging requiere un servidor (normalmente Google Cloud Run o AWS), configuración DNS (subdominio propio) y mantenimiento continuo. No es un plugin que se instala con un clic. Solución: prevea los recursos técnicos necesarios o trabaje con un proveedor especializado.
Pensar que el server-side resuelve el problema de los datos que faltan. El server-side tagging mejora la cobertura (menos interferencias de los bloqueadores de anuncios, cookies más duraderas), pero los usuarios que rechazan el consentimiento siguen siendo invisibles. Solución: combine el server-side tagging con una tasa de consentimiento optimizada y el modelado de conversiones para maximizar la cobertura.
Checklist: server-side tagging y cumplimiento en materia de cookies
- El banner de consentimiento se mantiene incluso con una arquitectura server-side.
- El estado del consentimiento se transmite del cliente al contenedor de servidor con cada evento.
- El contenedor de servidor verifica el estado del consentimiento antes de cualquier transmisión a terceros.
- Las cookies server-side (propias) están declaradas en la política de cookies.
- Los datos personales (IP, correo electrónico, identificadores) se filtran o anonimizan en el servidor antes de enviarlos a terceros.
- El subdominio propio está configurado (por ejemplo, analytics.yoursite.com) con los registros DNS correctos.
- Consent Mode v2 está implementado y sus señales se propagan al contenedor de servidor.
- Una auditoría de cookies confirma que no se colocan cookies no esenciales antes del consentimiento, incluidas las cookies server-side.
- Los flujos de datos salientes del servidor se auditan con regularidad.
- La documentación de la arquitectura técnica está actualizada en el registro de actividades de tratamiento.
Conclusión
El server-side tagging es una evolución importante de la recogida de datos que ofrece más control, más resistencia frente a las restricciones de los navegadores y los bloqueadores de anuncios, y más capacidad para filtrar datos personales. Pero no cambia las reglas fundamentales del consentimiento: el RGPD y la Directiva ePrivacy se aplican tanto si el tracking es client-side como server-side.
La arquitectura ideal combina el server-side tagging con una CMP conforme y Consent Mode v2 para garantizar que el consentimiento se verifique tanto en el lado del cliente como en el del servidor. Es la configuración más sólida para conciliar cumplimiento y calidad de los datos.
Para comprobar que su sitio no coloca cookies antes del consentimiento, incluidas las cookies server-side, haga un escaneo gratuito con FlowConsent.