Si seguís cualquier blog de marketing digital o agencia técnica, en algún momento del último año te cruzaste con una versión de este mensaje: "tenés que pasarte a server-side tracking". Lo presentan como si fuera el próximo paso obligatorio para cualquier negocio serio, casi una cuestión de higiene básica. Y como suele pasar con cualquier solución vendida en bloque, parte es cierto y parte es marketing.
Server-side tracking (SST) resuelve problemas reales. Pero solo algunos negocios tienen esos problemas en grado suficiente para justificar el costo. Para el resto, implementarlo es gold-plating: invertís tiempo y plata para arreglar algo que no estaba roto.
Esta nota es la guía honesta para saber en qué grupo estás.
Qué hace realmente SST (sin marketing)
En el modelo tradicional (client-side), cuando un usuario entra a tu sitio, su navegador ejecuta una serie de scripts — Google Analytics, Meta Pixel, Google Ads, etc. — que mandan eventos directamente a esas plataformas. Funciona, pero depende del navegador del usuario: si tiene un ad blocker, si su browser está bloqueando cookies de terceros, si la conexión es mala.
En SST, los eventos van primero a un servidor tuyo (o en la nube) y desde ahí se reenvían a las plataformas. Cambian dos cosas concretas:
- La plataforma recibe los datos de tu servidor, no del browser del usuario. Saltás el ad blocker, las restricciones de cookies, y los problemas de browsers exigentes (Safari ITP, Firefox, etc.).
- Vos controlás qué datos se mandan y cómo. Podés enriquecer eventos con información de tu CRM, deduplicar, filtrar bots.
Eso es lo que hace. El resto del discurso — "más privado", "más rápido", "future-proof" — son consecuencias indirectas que dependen de cómo lo implementes.
Los tres problemas que SST resuelve bien
1. Pérdida significativa de eventos por ad blockers o restricciones de browser.
Si tu audiencia es tech-savvy (devs, gamers, productos B2B donde el comprador trabaja con la cabeza), una porción importante de tu tráfico tiene ad blockers. En audiencias así, hasta el 30-40% de los eventos puede perderse en client-side. Para un e-commerce de moda dirigido al público masivo, ese número es muchísimo más bajo (probablemente menos del 10%). La diferencia entre los dos casos es la que decide si SST tiene sentido.
2. Calidad de match en plataformas de ads (Meta CAPI, Google Enhanced Conversions).
Meta y Google premian a los anunciantes que les pasan datos de mejor calidad: emails hasheados, teléfonos, IDs de usuario. Eso lleva a mejor optimización de campañas y, en plataformas como Meta, a CPMs más bajos en algunos casos. SST hace que mandar esa data sea más fácil y más confiable.
Esto vale plata real para anunciantes que invierten fuerte en paid (pensemos $20k+ por mes). Para alguien que gasta $2k al mes en Google Ads, la mejora marginal no compensa el costo de implementación.
3. Privacidad y cumplimiento (GDPR, leyes locales).
Si operás en mercados con regulaciones estrictas, SST te permite controlar qué datos salen de tu infraestructura, anonimizar antes de enviar, y mantener un consentimiento más limpio. Para empresas que enfrentan auditorías o que tienen exposición legal real (salud, finanzas, datos sensibles), esto es decisivo.
Si operás solo en mercados sin enforcement real, es un nice-to-have.
El costo del que nadie habla
Una implementación de SST mínima viable cuesta:
- Setup inicial: entre 30 y 80 horas de trabajo técnico, dependiendo de la complejidad del stack.
- Infraestructura: $50-300/mes (Google Tag Manager Server, hosting en GCP/AWS, contenedor de servidor).
- Mantenimiento: alguien que entienda el sistema y lo arregle cuando se rompa. Y se rompe.
Si tu equipo no tiene a esa persona internamente, vas a depender de una agencia. Y mantener SST con una agencia externa es más caro de lo que parece, porque cada cambio en plataforma (Meta actualiza CAPI, Google cambia un schema) implica horas facturables.
Sumado, una implementación bien hecha y un primer año de mantenimiento puede costar entre $5.000 y $20.000. La pregunta correcta no es "¿es mejor?". Es "¿esos $5.000-20.000 generan más rendimiento que invertirlos en otra cosa?".
Test rápido: ¿lo necesitás?
Tres preguntas. Si respondés "sí" a dos o tres, SST probablemente vale la pena. Si respondés "sí" a una o ninguna, probablemente no.
- ¿Invertís más de $15k/mes en paid (Meta + Google)? Por debajo de ese umbral, la mejora de match calidad rara vez compensa el costo.
- ¿Tu audiencia es notoriamente tech-savvy o tu producto enfrenta ad blockers fuertes? Software, gaming, finanzas tech, B2B SaaS suelen calificar. E-commerce masivo, servicios locales, hospitality casi nunca.
- ¿Operás bajo regulación de privacidad real, con auditorías o riesgo legal por mal manejo de datos? Si la respuesta es sí, SST deja de ser optativo.
Si dijiste sí a las tres, el negocio probablemente te lo pide. Si dijiste sí a dos, vale la pena evaluar costo-beneficio con números reales en la mesa. Si dijiste sí a una o cero, fijate primero en otras cosas: tu medición de conversiones está bien configurada, tu stack de attribution funciona, tu CAC payback es positivo. Esas cosas casi siempre dan más retorno que migrar a SST.
Lo que sí hacemos cuando no recomendamos SST
A los clientes para los que SST es gold-plating, recomendamos otras dos cosas que dan retorno parecido a un costo mucho menor: enhanced conversions client-side (que cubre buena parte del beneficio de match calidad sin necesidad de servidor) y consent mode v2 bien configurado (que mejora dramáticamente la atribución sin tocar arquitectura).
Combinadas, esas dos intervenciones suelen capturar el 70% del beneficio que daría una implementación full de SST, a una fracción del costo. Para la mayoría de los negocios PyME y startup, eso es más que suficiente.
La regla general que aplicamos en Empire DMC: SST cuando hay un problema concreto que justifica resolverlo. Nunca SST porque sí, ni porque "es el futuro". El futuro es largo y caro de comprar por adelantado.