Casi todas las conversaciones sobre server-side empiezan igual: alguien lo ha oído y viene con la idea de que va a tener más datos. Más tráfico medido, datos de los usuarios que no aceptan cookies, cifras que por fin cuadran. Y hay que decirlo pronto y claro: server-side no te da más datos. No es eso lo que hace, y quien lo monta esperando eso acaba pagando infraestructura y horas de mantenimiento para ver los mismos números de antes.
Lo que sí hace — controlar tu flujo de datos — es valioso de verdad para ciertos negocios. Este artículo va de separar las dos cosas: qué es mito, qué es real, y con qué criterios decidir.
Lo que server-side NO hace
No mide a los usuarios que no aceptan cookies. El consentimiento aplica exactamente igual midiendo desde tu servidor que desde el navegador. Si un usuario rechaza analítica, no puedes procesar sus datos, dé igual por dónde pasen. Server-side no es una vía para “recuperar” ese tráfico, y quien lo venda así te está vendiendo un problema legal.
No genera datos de la nada. El servidor solo reenvía y transforma lo que el navegador le manda. Si un evento no se dispara en la web, tampoco existe en el servidor. La calidad de tu medición sigue dependiendo de la implementación en el cliente. Un dato de proyecto real: en una migración a server-side de un ecommerce de electrónica, la discrepancia entre la analítica y el CMS se mantuvo estable tras el cambio. No fue un fracaso — el proyecto iba de CAPI y de control, no de “más datos” —, pero es la prueba de que server-side no sube el porcentaje de medición por sí solo.
No es obligatorio por privacidad. No hay ninguna norma que exija server-side. Y el argumento de urgencia que lo acompañaba — “prepárate para un mundo sin cookies” — ha caducado: Google renunció en 2025 a retirar las cookies de terceros de Chrome y ese mismo año retiró la mayor parte de Privacy Sandbox. Las cookies de terceros se quedan, con los mismos requisitos de consentimiento de siempre.
No acelera la web de forma que se note. Es un argumento que se repite (menos scripts de terceros en el navegador), pero en los proyectos donde lo hemos medido no hemos visto cambios apreciables de velocidad. Si tu problema es rendimiento, hay sitios mejores donde invertir.
Lo que sí hace (por orden de impacto real)
1. Control total del flujo de datos. Esta es la ventaja de verdad, y de ella cuelgan todas las demás. Con píxeles de terceros en el navegador, cada plataforma lee tu web directamente y tú no controlas qué se lleva. Con server-side, todo pasa por un punto que es tuyo: decides qué recibe cada plataforma, campo a campo. A Meta le mandas esto, a Google esto otro, y este dato no sale hacia nadie.
2. Enriquecer los datos con información que no quieres en el frontal. El servidor puede cruzar cada evento con tus propias tablas antes de reenviarlo. El caso típico: añadir el coste de producto desde una tabla (por ejemplo en Firestore) para que Google Ads optimice contra beneficio en vez de contra ingreso. Ese dato no puede ir en el código de tu web — cualquiera lo vería — pero desde el servidor viaja sin exponerse. Para un ecommerce con inversión fuerte en paid, esto solo ya puede justificar el proyecto.
3. Implementar CAPI de varias plataformas desde un sitio. Meta, Pinterest, TikTok… las APIs de conversiones se implementan de forma natural desde un contenedor server-side, con deduplicación y un solo punto de mantenimiento. Si tu ecommerce está en Shopify, esto conecta con lo que ya contamos sobre cómo medimos con un custom pixel: el pixel alimenta el dataLayer y el servidor reparte.
4. Cookies que duran más en Safari — con letra pequeña. Safari capa a 7 días la vida de las cookies creadas con JavaScript (la analítica tradicional), así que un usuario que vuelve a los 10 días cuenta como nuevo y la atribución se corta. Una cookie puesta desde tu servidor, en tu dominio, conserva su duración completa. Pero ojo a la letra pequeña: desde Safari 16.4, si la IP de tu servidor de medición no “parece” de primera parte (y un Cloud Run detrás de un balanceador no siempre lo parece), el límite de 7 días puede seguir aplicando. Es una mejora real, no una garantía.
5. Medir en entornos que bloquean scripts de terceros. Existe, pero es marginal: hablamos de modos de navegación muy restrictivos con una penetración pequeña. Que nadie te venda el proyecto por esto.
Lo que cuesta de verdad
La infraestructura es lo barato: un server GTM en Google Cloud sale por 50–150 € al mes según tu volumen de tráfico y eventos. Lo que de verdad cuesta es lo otro: la medición se vuelve más compleja de mantener. Ahora hay dos contenedores en vez de uno, transformaciones que viven en el servidor, credenciales de APIs, y cualquier depuración exige mirar en dos sitios. Necesitas un equipo más técnico — interno o agencia — y las horas de mantenimiento suben. El coste real del server-side no está en la factura de Google Cloud: está en las personas.
(Dónde alojar ese contenedor — GCP propio o un tercero tipo Stape — es una decisión con su propia miga; la tratamos aparte. Y si ya tienes claro el GCP propio, la guía paso a paso del despliegue es exactamente el que usamos en producción.)
Cuándo compensa — y cuándo no
Compensa cuando los puntos de arriba son dolores reales en tu organización:
- Inviertes lo suficiente en paid como para que optimizar contra margen (y no contra ingreso) mueva dinero.
- Necesitas CAPI de varias plataformas y quieres una sola implementación mantenible.
- Tienes requisitos serios de control del dato: decidir exactamente qué sale hacia cada tercero.
Y no compensa cuando:
- Lo quieres porque crees que vas a medir a los usuarios sin consentimiento. No vas a medirlos; ese proyecto nace muerto.
- Tu medición actual funciona y ninguno de los puntos de arriba te duele. Un GTM web bien implementado cubre de sobra a la mayoría de los negocios.
- No hay nadie — ni dentro ni fuera — que vaya a mantenerlo. Un server-side abandonado es peor que no tenerlo.
Nosotros hemos desaconsejado montarlo más de una vez, casi siempre por el primer motivo. La pregunta que lo resuelve casi todo: ¿qué dato necesitas controlar, enriquecer o enviar que hoy no puedas? Si tienes respuesta concreta, server-side probablemente te compensa. Si la respuesta es “tener más datos”, todavía no.