Durante años, medir una campaña consistía en pegar en la web el píxel de cada plataforma. Funcionaba, pero cada vez se pierden más datos por el rechazo de cookies, las restricciones de los navegadores y los bloqueadores, y la web se llena de código de terceros que no controlas.
El tracking server-side, también llamado etiquetado del lado del servidor, cambia el recorrido de esos datos. En este artículo explicamos cómo funciona, qué mejora, qué no resuelve y cuándo merece la pena.
En resumen
- Los eventos de tu web o tu app van primero a un servidor en un subdominio tuyo, como tag.tudominio.com, y desde ahí a cada plataforma por API.
- Ganas control sobre qué datos compartes, cookies propias más duraderas y menos scripts de terceros en la página.
- No sustituye al consentimiento ni es una medición sin cookies mágica: el usuario sigue decidiendo.
- Si combinas eventos del navegador y del servidor, hay que deduplicarlos con un event_id.
- Tiene coste de hosting y necesita un responsable técnico. No todos los anunciantes lo necesitan.
Qué es el tracking server-side
En el etiquetado del lado del cliente (client-side), el navegador del usuario carga la etiqueta de cada plataforma y envía los eventos directamente a Google, Meta o TikTok. Cada proveedor recibe lo que su script recoge.
En el etiquetado del lado del servidor (server-side), la web envía los eventos a un único destino: un servidor de etiquetado que vive en un subdominio tuyo. Ese servidor recibe el evento, lo procesa y lo reenvía a cada plataforma por sus APIs.
Qué cambia frente al etiquetado en el navegador
Las peticiones van a tu propio dominio
El navegador ya no habla con decenas de dominios de terceros, sino con un subdominio tuyo. Para el navegador es tráfico propio (first-party).
El servidor decide qué llega a cada plataforma
Puedes quitar la IP o parámetros de la URL antes de reenviar, mandar a cada plataforma solo los eventos que le corresponden y descartar tráfico que no quieres contar, como bots o pruebas internas. Es el cambio más importante: decides tú qué se comparte.
Cookies propias que duran más
Safari, con su Intelligent Tracking Prevention (ITP), limita a siete días las cookies creadas por JavaScript, y las de terceros directamente no las admite. Las cookies que fija tu servidor en una respuesta HTTP desde tu dominio pueden durar más, así que un usuario que vuelve a las dos semanas sigue siendo reconocible. Un matiz: Safari también limita las cookies de servidor cuando el subdominio de etiquetado apunta a una infraestructura muy distinta de la de tu web, así que cómo se configura importa.
Menos código de terceros en la página
Si varias plataformas se alimentan desde el servidor, puedes retirar algunos de sus scripts de la web. Menos JavaScript de terceros suele significar una página que carga antes.
Qué no hace el tracking server-side
- No evita el consentimiento. Si el usuario rechaza las cookies de publicidad o analítica, esos datos no se pueden enviar, vayan por el navegador o por el servidor. El servidor tiene que leer la señal de tu CMP y respetarla.
- No es medición sin cookies por arte de magia. Sigue usando cookies, solo que propias. Lo que mejora es su duración y el control, no la necesidad de permiso.
- No esquiva todos los bloqueadores. Un subdominio propio resiste mejor que los dominios conocidos de las plataformas, pero algunos bloqueadores detectan también los scripts o las rutas habituales del etiquetado.
Qué piezas hacen falta
- Un servidor de etiquetado. La opción más extendida es Google Tag Manager server-side, que se puede desplegar en Google Cloud Run o en un proveedor gestionado que lo aloja por ti.
- Un subdominio propio. Por ejemplo, tag.tudominio.com, apuntando a ese servidor.
- Un contenedor web. El GTM de toda la vida o la etiqueta de Google en la página, configurados para enviar los eventos a tu servidor en lugar de a cada plataforma.
- Un contenedor de servidor. Recibe las peticiones mediante «clientes» que las interpretan y dispara las etiquetas de cada destino.
- Las etiquetas de cada plataforma. La API de conversiones de Meta, las conversiones mejoradas de Google Ads, la Events API de TikTok y el Measurement Protocol de GA4, entre otras.
La pieza de Meta la explicamos en la guía de la API de conversiones.
Deduplicación: cuando el navegador y el servidor envían el mismo evento
Muchas instalaciones mantienen el píxel en el navegador y añaden el envío desde el servidor. Es razonable, pero la misma compra llega dos veces. Para que la plataforma la cuente una sola, los dos envíos tienen que llevar el mismo identificador: en Meta y en TikTok, el mismo nombre de evento y el mismo event_id; en Google Ads, el mismo ID de transacción. Sin eso, las conversiones se inflan y las pujas aprenden de datos duplicados.
Enriquecer los eventos con datos de tu negocio
El navegador solo sabe lo que pasa en la web. Tu servidor puede consultar otros sistemas antes de reenviar el evento: el margen del pedido desde el ERP, la calidad del lead desde el CRM o si el cliente ya había comprado antes. Lo que ocurre días después, como una venta cerrada por teléfono o una devolución, se completa con conversiones offline desde tu fuente de la verdad.
Costes y mantenimiento
Un servidor de etiquetado es infraestructura y cuesta dinero cada mes. En Cloud Run, Google recomienda varias instancias para producción, y el coste crece con el tráfico. Un proveedor gestionado simplifica el despliegue a cambio de una cuota.
El coste menos visible es el de mantenimiento. Alguien tiene que vigilar que el servidor responde, actualizar las plantillas y comprobar que el consentimiento y la deduplicación siguen funcionando tras cada cambio en la web. Sin un responsable técnico, un montaje server-side se degrada en silencio.
Cuándo lo necesitas y cuándo no
Te compensa si se cumplen varias de estas condiciones:
- Inviertes en varias plataformas y sus pujas automáticas dependen de las conversiones que reciben.
- Una parte relevante de tu tráfico llega desde Safari o desde iOS.
- Quieres controlar qué datos personales recibe cada proveedor.
- Quieres enviar valores de negocio, como margen o calidad del lead, y no solo el evento.
- Tienes a alguien, interno o externo, que se ocupe de mantenerlo.
Probablemente no lo necesitas todavía si inviertes poco en medios, usas una sola plataforma con su integración nativa o tus conversiones ya llegan desde el CRM como conversiones offline.
Errores habituales
- Montarlo para saltarse el consentimiento. Es un riesgo legal y, además, no es para lo que sirve.
- Duplicar eventos. Enviar desde el navegador y desde el servidor sin un
event_idcomún. - Usar un dominio que no es el tuyo. Sin subdominio propio, se pierde buena parte de la ventaja de las cookies first-party.
- No tener dueño. Nadie revisa el servidor hasta que las conversiones caen.
Cómo lo hace Babuin
En MonkeyFlux, los eventos de tu web y tu app pasan por un servidor en tu propio dominio, como tag.tudominio.com, con cookies first-party. Ahí se aplica el consentimiento, se deduplican los eventos por event_id y se enriquecen con datos de tu CRM y tu ERP, como margen, LTV, calidad del lead o devoluciones. Después se envían a cada plataforma por Conversions API, Enhanced Conversions, Events API o Measurement Protocol. Es compatible con tu contenedor server-side de GTM.
Con esas señales, Babuin mide cada medio contra los resultados de tu negocio, MonkeyBot puja hacia valor real y DBA reparte cada día el presupuesto entre canales.
Preguntas frecuentes
¿El tracking server-side evita pedir consentimiento de cookies?
No. El consentimiento se aplica igual tanto si los datos salen del navegador como si salen de tu servidor. Lo correcto es que el servidor lea la señal de tu CMP y solo envíe a cada plataforma los datos de los usuarios que han aceptado ese uso.
¿Qué diferencia hay entre GTM web y GTM server-side?
GTM web se ejecuta en el navegador del usuario y envía los datos directamente a cada plataforma. GTM server-side se ejecuta en un servidor tuyo: recibe los eventos del contenedor web y decide qué reenvía a cada destino, con qué datos y en qué momento.
¿Cuánto cuesta Google Tag Manager server-side?
GTM es gratuito, pero el servidor donde se ejecuta no. El coste depende del tráfico, del número de instancias y de si lo alojas en Google Cloud Run o en un proveedor gestionado. A eso hay que sumar el tiempo de quien lo mantiene.
¿El tracking server-side sustituye al píxel de Meta?
No necesariamente. Muchas instalaciones combinan el píxel con la API de conversiones y deduplican los eventos con el mismo event_id. Así Meta recibe el evento aunque uno de los dos envíos falle, y lo cuenta una sola vez.