Datos de producto estructurados significa que cada dato del producto vive en un atributo tipado, con…
Server-side tracking en e-commerce: la medición vuelve a ser completa
El server-side tracking traslada el envío de eventos de analítica y conversión desde el navegador de tus visitantes a un servidor que controlas tú. Así los eventos llegan a GA4, Meta, TikTok o a tu data warehouse incluso cuando adblockers, restricciones del navegador o scripts interrumpidos los habrían hecho desaparecer. No sustituye al consentimiento: medición completa significa que llega cada evento que tienes derecho a medir.
Por qué la medición del lado del cliente tiene huecos
El tracking clásico se basa en tags de JavaScript en el navegador. Cada tag se carga, lee cookies y envía datos directamente a un dominio de terceros. Ese modelo falla en cuatro puntos:
- Los adblockers y las extensiones de privacidad filtran las peticiones a dominios de tracking conocidos. El evento nunca sale del navegador y tus informes no se enteran.
- Las restricciones de los navegadores acortan la vida de los datos del lado del cliente. Safari bloquea por defecto las cookies entre sitios desde 2020, y WebKit elimina el almacenamiento escribible por script de un sitio tras siete días de uso de Safari sin interacción con ese sitio. Los clientes recurrentes parecen entonces visitantes nuevos y la atribución se rompe.
- Los rechazos de consentimiento son un hueco legítimo. Quien rechaza, queda fuera. Así debe ser, y ninguna arquitectura lo cambia.
- El peso y el timing de los scripts también cuestan datos. Los tags que cargan tarde pierden eventos cuando un visitante se va rápido, y cada script adicional compite con tu storefront por el main thread.
Según el Web Almanac 2025 de HTTP Archive, al menos el 90 % de las páginas incluye uno o más terceros. Cada uno es un pequeño riesgo para la calidad de los datos y para la velocidad.
Qué es el server-side tracking y qué no es
Qué hace
En lugar de una docena de tags, el storefront envía los eventos a un único endpoint first-party, idealmente en tu propio subdominio. Un servidor los recibe, los valida, los enriquece y los reenvía a los destinos: GA4, la Meta Conversions API, la TikTok Events API o un data warehouse. Google resume sin rodeos la ventaja principal de su server-side tagging: menos tags de medición en la web significa menos código ejecutándose en el cliente. Con un dominio propio, el servidor de tagging puede además establecer cookies HttpOnly que los scripts de la página no pueden leer.
Qué no hace
El server-side tracking no es una forma de saltarse el consentimiento. Las normas europeas de consentimiento se refieren al acceso a la información del dispositivo del usuario y a la finalidad del tratamiento, no al lugar donde se ejecuta un tag. Las directrices del EDPB sobre el ámbito técnico de la Directiva ePrivacy, adoptadas en 2024, incluyen de forma explícita técnicas como los píxeles de seguimiento y el tracking basado en URL. En la práctica, un setup limpio transmite el estado del consentimiento con cada evento y el servidor solo alimenta los destinos que el visitante ha aceptado. El consent mode de Google para server-side tagging también transmite el estado del consentimiento al contenedor de servidor. Este artículo no es asesoramiento jurídico: la base legal la decide tu delegado de protección de datos.
Tres variantes de arquitectura
Los tres enfoques habituales resuelven el mismo problema con prioridades distintas.
Google Tag Manager Server-Side
Un contenedor de servidor se ejecuta en tu propio entorno cloud, por ejemplo en Google Cloud Run, y es accesible a través de un subdominio propio. Muchos equipos ya conocen su lógica de tags y activadores gracias al contenedor web. La contrapartida: operas tú la infraestructura y sigues manteniendo los tags, así que el frontend sigue siendo un cuello de botella si cada evento nuevo exige trabajo manual.
Pipeline CDP con RudderStack
Una pipeline de datos de cliente como RudderStack recoge los eventos de forma centralizada, los transforma y los distribuye a un gran número de destinos. La propia RudderStack indica más de 200 integraciones predefinidas y tiene un enfoque warehouse-native. Encaja con equipos para los que el data warehouse es la fuente de verdad.
Edge con Cloudflare Zaraz
Cloudflare Zaraz carga las herramientas de terceros del lado del servidor, en el edge, de modo que su código no se ejecuta en el navegador. Zaraz incluye su propia gestión del consentimiento. Es la variante que requiere menos infraestructura propia.
Calidad de datos: esquema de eventos y deduplicación
Del lado del servidor no significa automáticamente limpio. Dos disciplinas deciden si tus cifras ganan fiabilidad.
Un esquema de eventos compartido. Define cada evento una sola vez: nombre, parámetros obligatorios, moneda, IDs de producto y contexto de consentimiento. Si "add_to_cart" tiene tres nombres distintos, un servidor solo reenvía el caos más rápido. El lugar adecuado para esa definición son los componentes del storefront, no las reglas de los tags.
Deduplicación entre navegador y servidor. Meta recomienda usar la Conversions API junto al Meta Pixel. Para que la misma compra no cuente dos veces, ambos eventos necesitan el mismo nombre de evento y el mismo ID de evento. Meta deduplica en las 48 horas posteriores a recibir el primer evento con ese ID. TikTok funciona igual: parámetros event y event_id idénticos, deduplicación dentro de una ventana de 48 horas.
Una checklist breve para empezar:
- Genera en el frontend un ID de evento único por interacción.
- Envía ese ID tanto con el evento del navegador como con el evento del servidor.
- Transmite el estado del consentimiento con cada evento y filtra los destinos en el servidor.
- Compara durante dos semanas el número de eventos por destino antes de retirar los tags de cliente.
- Retira de forma consecuente los tags de navegador sustituidos, o la mejora de rendimiento nunca llegará.
Rendimiento: menos JavaScript de terceros en el navegador
Cada tag que pasa al servidor es código que el navegador ya no tiene que descargar, analizar y ejecutar. Eso descarga el main thread, algo que beneficia sobre todo a métricas de interacción como INP. Por qué esto importa para la facturación lo explicamos en nuestro artículo sobre Core Web Vitals para e-commerce y rendimiento del frontend. Un proyecto, dos efectos: datos más estables y un frontend más rápido. Para la parte de plataforma, consulta Rendimiento y Core Web Vitals.
Cómo aborda Laioutr el server-side tracking
Laioutr es una Frontend Management Platform (FMP) que se sitúa sobre tu backend de commerce existente. En un Composable Storefront, el tracking se divide en dos niveles:
- Base de tracking, incluida: la captura básica de eventos se realiza a través del esquema de componentes. Como la plataforma conoce cada componente, interacciones como clics, cambios de pestaña y visualizaciones se registran como eventos sin etiquetado manual.
- Server Side Tracking, add-on: esos eventos se reenvían del lado del servidor, así que los tags de marketing ya no se ejecutan en el navegador. Eso hace la medición más robusta frente a los adblockers, y el reenvío sigue siendo first-party y controlado por el consentimiento. Entre los destinos: GA4, Meta, TikTok, tu data warehouse y RudderStack. Como proveedor eliges entre Cloudflare Zaraz, GTM Server-Side u otro setup.
Base incluida, reenvío del lado del servidor como add-on. Todos los detalles en la página Tracking & Analytics.
FAQ
¿El server-side tracking cumple el RGPD?
El server-side tracking es una arquitectura, no un estatus jurídico. Ayuda porque controlas qué datos llegan a qué destino, pero las obligaciones de consentimiento siguen vigentes. La base legal la revisa tu delegado de protección de datos.
¿El server-side tracking esquiva los adblockers?
Hace la medición más robusta frente a los adblockers, porque los eventos van a un endpoint first-party en lugar de a dominios de tracking conocidos. El límite sigue siendo el consentimiento: quien lo ha rechazado no se rastrea.
¿Sigo necesitando tags en el navegador tras el cambio?
A menudo queda un componente de cliente ligero que pasa los eventos al servidor. Meta recomienda un setup redundante de navegador y servidor, y en ese caso la deduplicación por ID de evento es obligatoria.
GTM Server-Side, RudderStack o Cloudflare Zaraz: ¿cuál encaja?
GTM Server-Side encaja con equipos que dominan GTM y operan su propio cloud. RudderStack encaja con estrategias de datos centradas en el warehouse. Zaraz encaja con equipos que quieren trabajar en el edge con la mínima infraestructura propia.
Próximos pasos
Empieza por un inventario: ¿qué tags se ejecutan en tu storefront y dónde difieren los pedidos de tu sistema de e-commerce de las conversiones en analítica? Esa diferencia te muestra lo que el server-side tracking puede recuperar. Si quieres ver cómo la captura de eventos basada en componentes y el reenvío del lado del servidor trabajan juntos, reserva una demo con nuestro equipo.