Blog · GTM · 12 ago 2026

GTM server side: cuándo compensa y cuándo no

Por Antonio Luis Pérez Carmona, analista digital. Trabajo con medición web y server side sobre más de 1300 webs.

El server side tagging traslada parte de tu medición del navegador a un servidor bajo tu control. El navegador envía un único hit a un subdominio tuyo y el contenedor del servidor lo transforma y lo reparte a GA4, Google Ads o Meta. Compensa cuando inviertes en publicidad y pierdes señal por navegadores y bloqueadores. Con la medición web rota, añade una capa de coste encima de un problema sin resolver.

Me toca montarlo, mantenerlo y también desaconsejarlo. Este artículo reúne el criterio que uso para decidir, con los costes reales que casi ningún vendedor menciona.

Cómo funciona un contenedor server side

Montas un endpoint en un subdominio propio, por ejemplo datos.tudominio.com, corriendo sobre Cloud Run u otra infraestructura. El navegador deja de hablar con una docena de dominios de terceros y envía todo a ese subdominio. Allí, un contenedor de GTM recibe cada hit, lo valida, lo enriquece o lo recorta, y lo reenvía a las plataformas que decidas. Tú eliges qué dato sale, hacia dónde y en qué forma.

Lo que arregla

• La vida de las cookies en Safari. ITP recorta las cookies creadas por JavaScript a 7 días; las que crea tu servidor en primera parte duran lo que configures. Un cliente que vuelve a los 20 días desde Safari pasa de "nuevo usuario" a la verdad: recurrente.
• Parte del bloqueo. Los bloqueadores cazan los dominios de Google y Meta. Un hit hacia tu propio subdominio pasa con más frecuencia. Recuperas una parte del tráfico invisible; los bloqueadores de listas agresivas siguen ganando.
• Control del dato saliente. El navegador envía a cada plataforma lo que su script quiera coger. El servidor envía lo que tú declares, y eso convierte la frase "solo compartimos lo necesario" de tu política de privacidad en algo verificable.
• Conversiones avanzadas y CAPI. Enhanced conversions de Google y la Conversions API de Meta funcionan mejor desde servidor, con el hasheado de datos hecho donde debe.
• Menos JavaScript en la página. Cada script de terceros que sacas del navegador son milisegundos de carga que recuperas.

Lo que sigue igual

• El consentimiento. El RGPD aplica al dato, viaje por donde viaje. El servidor respeta el consent igual que el navegador, y quien te lo presente como vía de escape te está proponiendo mover la infracción de sitio.
• La calidad del dataLayer. Un purchase sin transaction_id llega igual de roto al servidor. El server side transporta; el que ordena eres tú.
• La atribución. Los modelos de GA4 y Ads son los que son. Cambia la cantidad de señal que les llega, no la lógica del reparto.

Cuánto cuesta de verdad

La pregunta incómoda para tu agencia o tu equipo: cuando el contenedor falle un martes a las 9, ¿quién lo mira? Sin respuesta a eso, no montes server side.

Mi criterio para decidir

Recomiendo server side cuando se cumplen las tres:

1. Inviertes más de 2.000 o 3.000 € al mes en Google Ads o Meta. Por debajo, la mejora de señal tarda años en pagar la infraestructura.
2. Vendes online y quieres CAPI o enhanced conversions con datos de cliente bien tratados.
3. Existe un responsable técnico del contenedor, interno o contratado.

Con la medición web coja, el orden correcto es otro: primero el dataLayer, el consent y la deduplicación, que cuestan menos y rinden más. He visto presupuestos de server side aprobados en webs donde el purchase se disparaba dos veces. El duplicado también viaja en primera parte.

Migrar sin romper la medición

1. Espejo: montas el contenedor y le mandas copia del tráfico, sin apagar nada. Los datos de producción siguen saliendo del montaje web.
2. Comparación: dos o tres semanas cruzando ambos caminos. Buscas diferencias por navegador y por tipo de evento, y las explicas una a una.
3. Cambio por plataforma: migras GA4, después Ads, después Meta. Cada una con su ventana de validación.
4. Apagado: retiras las etiquetas web que ya no hacen falta. Este paso se olvida y deja duplicados sueltos.

Errores que veo en migraciones reales

• Doble medición eterna. El paso 4 de la migración se pospone y las etiquetas web conviven meses con las del servidor. Cada compra cuenta dos veces y las campañas optimizan contra humo.
• El subdominio en otro dominio. Contenedores montados sobre el dominio del proveedor o sobre un dominio distinto al de la web. Las cookies dejan de ser de primera parte y la ventaja principal se esfuma.
• Cookies de servidor sin configurar. El contenedor corre, reenvía hits y nadie activó la escritura de la cookie FPID. Safari sigue recortando a 7 días y el proyecto entero pierde su motivo.
• Logs sin mirar. Meta cambia un requisito de la CAPI, los eventos empiezan a rebotar y nadie se entera hasta que el rendimiento de campañas cae semanas después. Una alerta sobre la tasa de error del contenedor cuesta una hora de montar.
• Presupuesto sin partida de mantenimiento. El proyecto se vende como obra única. A los seis meses, el contenedor es de nadie.

Preguntas frecuentes

¿Mejora el SEO?

De rebote y poco: quitar scripts de terceros acelera la página, y la velocidad puntúa. Nadie posiciona por tener server side, y quien lo anuncie como palanca SEO está rellenando la propuesta.

¿Puedo medir sin banner gracias al server side?

No. La obligación de consentimiento depende del dato personal, no del camino que recorra. Existen alternativas cookieless con otra base legal, y de hecho tengo un producto en ese terreno, pero el server side de Google no es eso.

¿Cloud Run o un proveedor gestionado?

Cloud Run cuando tienes quien lo administre; un gestionado (Stape, Addingwell y similares) cuando prefieres pagar por olvidarte de la infraestructura. El contenedor de GTM es idéntico en ambos.