Google Tag Gateway vs GTM del lado del servidor: ¿cuál necesita realmente tu configuración?
Mariusz Brucki | 13 mayo 2026 | Última actualización: Google Tag Gateway aterrizó en 2024 e inmediatamente dividió las opiniones. Algunos equipos lo consideraron el final de la conversación sobre el Seguimiento del lado del servidor. Otros lo descartaron como una solución ligera.
En realidad, ninguna de las dos cosas es exacta.
La realidad es: las 2 herramientas abordan problemas diferentes en capas distintas de tu configuración. GTG cambia desde dónde se cargan los scripts. GTM del lado del servidor cambia dónde se procesan los datos y dónde se escriben las cookies. No son lo mismo, y confundirlas conduce a configuraciones que parecen completas sobre el papel, pero que dejan abiertas verdaderas lagunas de seguimiento.
En este artículo, descubrirás lo que Google Tag Gateway cambia en tu configuración y lo que deja intacto, cómo GTM del lado del servidor gestiona de forma diferente el procesamiento de eventos, la vida útil de las cookies y la cobertura multiplataforma, una comparación directa de ambas herramientas en 7 dimensiones y un marco claro para decidir qué configuración (o qué combinación) se ajusta a tu pila de seguimiento.
¿Qué es Google Tag Gateway?
Google Tag Gateway es un proxy gestionado por Google para tus etiquetas de Google. En lugar de cargarse desde googletagmanager.com, tu script GTM procede de un subdominio que tú controlas, algo así como gtg.yoursite.com. La recopilación de datos GA4 se desplaza desde el punto final de recopilación de Google a ese mismo subdominio.
El subdominio es tuyo. Google gestiona la infraestructura que hay detrás. La configuración es principalmente un cambio de DNS y una actualización del contenedor.
Una restricción dura que merece la pena nombrar por adelantado: GTG sólo cubre los productos de Google. Por tanto, GA4, Google Ads, Floodlight y Google Tag están incluidos. Si utilizas Meta, TikTok, Klaviyo o cualquier otro producto fuera de ese ecosistema, GTG no afecta a esos eventos.
¿Qué arregla la GTG?
La mayoría de los bloqueadores de anuncios funcionan bloqueando las peticiones a nombres de host de terceros conocidos. googletagmanager.com está en todas las listas de bloqueo importantes. GTG lo elude enrutando esas peticiones a través de tu dominio, que no está en ninguna lista.
Es una mejora real. Los datos agregados del mundo real sitúan la mejora en torno a 1,5 ó 2,5 puntos porcentuales para los datos de Google que, de otro modo, se descartarían a nivel de secuencia de comandos.
Dos cosas que GTM no soluciona
1. El problema del camino
En primer lugar, GTG no resuelve el problema de la ruta. GTG cambia la parte del dominio de la URL de la solicitud, pero los patrones de ruta siguen siendo los mismos. Una solicitud de recogida de datos GA4 sigue llegando a /g/collect en tu subdominio, algo así como gtg.yoursite.com/g/collect/?id=G-12345678 . Los bloqueadores de anuncios como Ghostery y uBlock Origin no sólo se basan en nombres de host. También filtran por firmas de rutas conocidas, y /g/collect es un patrón bien documentado que aparece en la mayoría de las principales listas de bloqueo. Mover la solicitud a tu subdominio no cambia eso. Los bloqueadores más sofisticados siguen captando estas peticiones, lo que limita la capacidad real de recuperación de GTG.
2. Duración de la cookie
Las cookies siguen siendo establecidas por el JavaScript que se ejecuta en el navegador. Cuando tu contenedor GTM se ejecuta en el lado del cliente, escribe cookies a través de document.cookie. La Prevención de Seguimiento Inteligente de Safari limita esas cookies a 7 días. No importa qué dominio sirvió el script. El origen de la cookie es el entorno JavaScript del navegador. GTG no cambia esa capa.
Para cualquier viaje de atribución de más de una semana, o para cualquier visitante que vuelva para convertir después de 7 días en Safari, se sigue aplicando el límite de 7 días. Igual que antes. La carga del script mejoró; el problema de las cookies no se movió.
¿Qué es GTM del lado del servidor?
GTM del lado del servidor retira por completo el procesamiento de eventos del navegador y lo coloca en un servidor que tú controlas.
Tu navegador envía un evento a tu servidor. El servidor lo recibe, lo procesa y lo reenvía a cada plataforma mediante llamadas API de servidor a servidor. Si utilizas el Script de Seguimiento Mejorado junto con tu contenedor de servidor, los bloqueadores de publicidad no tienen visibilidad sobre esas llamadas. No hay nada ejecutándose en el navegador que bloquear.
¿Cómo funciona GTM del lado del servidor de forma diferente?
La situación de las cookies cambia significativamente. Tu servidor escribe cookies utilizando cabeceras de respuesta HTTP Set-Cookie. El límite de 7 días de la PTI está dirigido a las cookies escritas por JavaScript. Las cookies establecidas a través de cabeceras de un origen de primera parte quedan fuera de esa restricción. Una configuración correcta del servidor puede escribir cookies de origen que duren 365 días o más.
Para los sitios en los que los clientes tardan semanas en decidirse, esa diferencia en la duración de las cookies es la diferencia entre una atribución precisa y una atribución incompleta por diseño.
La cobertura es otro vacío que llena GTM del lado del servidor. El mismo contenedor puede dirigir eventos a GA4, Google Ads Enhanced Conversions, Meta Conversions API, TikTok Events API y la mayoría de las demás plataformas que ofrecen una API del lado del servidor. Si las campañas multicanal están perdiendo señal y está empezando a notarse en el rendimiento de tu retargeting(aquí te explicamos cómo recuperar la pérdida de datos), una canalización de eventos a todas las plataformas es donde se encuentra la solución estructural.
¿La contrapartida? GTM necesita alojamiento, configuración y conocimientos de GTM para funcionar bien. No es un cambio rápido.
Google Tag Gateway vs GTM del lado del servidor: una comparación directa
| Google Tag Gateway | GTM del lado del servidor | |
| Qué cambia | Desde dónde se cargan los guiones | Dónde ocurre el procesamiento de eventos |
| Configuración de cookies | JavaScript (navegador) | Cabeceras HTTP (servidor) |
| Impacto de la PTI | Sin cambios | Las cookies pueden durar más de 365 días (con una configuración sst adecuada) |
| Anulación del bloqueador de anuncios | Sólo carga de scripts | Llamadas completas de servidor a servidor |
| Cobertura de la plataforma | Sólo productos Google | Cualquier plataforma con una API de servidor |
| Complejidad de la instalación | Baja | Media a alta |
| Elevación típica de datos | 4-6%* | 14-20%* |
También hay una distinción técnica entre GTG y sGTM que merece la pena comprender si te importa el comportamiento del mismo sitio frente al mismo origen. GTG se ejecuta desde un subdominio como gtg.yoursite.com. Eso es mismo sitio, pero no mismo origen con tu dominio principal. Una configuración sGTM completa puede servir eventos a través de una ruta en tu dominio raíz: tu_sitio.com/collect. Mismo origen. Algunos navegadores y algunos mecanismos de seguimiento los tratan de forma diferente, y el enfoque sGTM te da más control, ya que eso importa más.
*Comprueba los datos y la comparación en ¿GTG o GTM del lado del servidor? El dilema del lado del servidor por Niek Schlepers
¿Qué configuración es la adecuada para tu caso de uso?
GTG es la elección correcta si
- Tu pila es sólo de productos Google (GA4, Google Ads, Floodlight)
- La mayoría de tus usuarios utilizan Chrome
- Los ciclos de conversión son inferiores a 7 días
- Quieres una mejora poco onerosa con una configuración mínima
sGTM es la elección correcta si
- Realizas el seguimiento en múltiples plataformas (Meta, TikTok, Klaviyo, Google)
- Tus clientes tardan más de 7 días en convertirse
- Necesitas cookies que persistan más allá del límite de ITP de Safari
- Quieres la aplicación del consentimiento en el servidor y el control de la IPI antes de que los datos salgan de tu infraestructura
- Quieres comprender todo el alcance de lo que recupera el rastreo del lado del servidor
He aquí un ejemplo.
Realizas un seguimiento entre plataformas. Una configuración Meta del lado del servidor depende de sGTM, no de GTG. TikTok, Klaviyo y todo lo demás fuera del ecosistema de Google también lo hace.
Tus clientes tardan en convertir. Los viajes de varias semanas en Safari necesitan cookies que sobrevivan más allá del séptimo día. GTG no proporciona eso.
Quieres ver lo que pierdes realmente. La imagen completa de lo que recupera el seguimiento del lado del servidor es difícil de apreciar hasta que ejecutas ambas configuraciones y las comparas.
Necesitas un control de los datos que vaya más allá de la recuperación de los mismos. sGTM te permite decidir qué se reenvía a cada plataforma, aplicar una lógica de consentimiento en el servidor y eliminar la información personal antes de que los datos salgan de tu infraestructura.
La mayoría de los equipos que se toman en serio el seguimiento de conversiones acaban llegando a la GTM del lado del servidor. La GTM puede ser un primer paso útil. Pero no resuelve la cuestión de la infraestructura.
¿Pueden trabajar juntos GTG y Server-Side?
Sí, Google Tag Gateway y el servidor Google Tag Manager operan en capas diferentes y pueden funcionar juntos sin entrar en conflicto. No se trata de elegir entre una cosa u otra.
Con sGTM ya instalado, tu contenedor del lado del navegador sigue cargando scripts y disparando eventos. GTG se encarga específicamente de la capa de entrega de scripts para las etiquetas de Google. El propio contenedor se puede servir desde tu subdominio o ruta de dominio sGTM. Añadir GTG encima no interfiere con eso.
Un ejemplo concreto: si utilizas el Script de Seguimiento Mejorado TAGGRS para la escritura de cookies en el servidor, éste se encarga del problema de la vida útil de las cookies. GTG se encarga de la parte de carga del script. Dos trabajos diferentes, mismo dominio, sin solapamientos.
Para la mayoría de las configuraciones que han ido más allá de la configuración básica, la combinación práctica es:
- GTG para la entrega del script de etiquetas de Google
- sGTM para el canal de eventos, la persistencia de cookies y el enrutamiento multiplataforma.
GTG y sGTM: ¿dónde encaja TAGGRS?
El GTM del lado del servidor necesita un servidor en el que ejecutarse. Para la mayoría de los equipos, el requisito real no es la gestión de la infraestructura. Es el rendimiento, la fiabilidad y la configuración adecuada del consentimiento sin tiempo dedicado a DevOps.
TAGGRS proporciona una infraestructura sGTM alojada con conectores incorporados para las principales plataformas publicitarias, integración del Consent Mode y controles de privacidad. ¿Estás preparado para superar la capa GTG y quieres entender cómo es la recuperación de datos para tu configuración específica?
PREGUNTAS FRECUENTES
¿Necesito Google Tag Gateway?
Si ejecutas GA4 y Google Ads sin ningún tipo de seguimiento del lado del servidor, GTG es una mejora práctica que merece la pena configurar. Recupera los datos perdidos por el bloqueo basado en el nombre de host con muy poca sobrecarga de implementación. Si ya estás ejecutando sGTM, la ganancia incremental de GTG es menor. Tus eventos ya se mueven de servidor a servidor. GTG ayuda principalmente a la capa de carga de scripts, que tu configuración de sGTM ya puede manejar dependiendo de cómo esté configurado tu contenedor.
¿Arregla Google Tag Gateway la PTI de Safari?
No. La GTG no cambia cómo se escriben las cookies. La PTI se aplica a las cookies escritas por JavaScript, independientemente del dominio que sirvió el script.
¿Cuál es la diferencia entre Google Tag Gateway y el etiquetado en el servidor?
Google Tag Gateway cambia el lugar desde el que se cargan tus scripts de Google. Un subdominio que tú controlas en lugar del dominio de Google. Los scripts siguen ejecutándose en el navegador, las cookies siguen siendo escritas por JavaScript y se sigue aplicando la PTI. Los bloqueadores de anuncios sofisticados que se basan en patrones de ruta en lugar de sólo en nombres de host pueden detectar y bloquear las solicitudes.
El etiquetado del lado del servidor traslada el procesamiento de eventos del navegador a un servidor. Las cookies se escriben a través de cabeceras HTTP, lo que las deja fuera del alcance de la PTI. Los eventos llegan a las plataformas a través de llamadas API de servidor a servidor que los bloqueadores de anuncios no pueden tocar. Y a diferencia de GTG, sGTM funciona en todas las plataformas con una API de servidor, no sólo en la de Google.
Funcionan en capas diferentes. GTG mejora la entrega de secuencias de comandos para las etiquetas de Google; sGTM gestiona el canal de eventos, la vida útil de las cookies y el enrutamiento de señales multiplataforma. Para configuraciones en las que ambos problemas son importantes, funcionan juntos.
¿Necesito GTM en el servidor si ya utilizo Google Tag Gateway?
GTG mejora la entrega de scripts para las etiquetas de Google. Si utilizas plataformas que no son de Google, necesitas que las cookies duren más de 7 días o quieres evitar por completo el bloqueador de anuncios en todas las plataformas, sGTM cubre esas lagunas.
