Google Tag Gateway vs GTM del lado del servidor: ¿cuál necesita realmente tu configuració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, tus scripts de Google se cargan desde una ruta en tu propio dominio, algo así como tu_sitio.com/metrics. La recopilación de datos de GA4 se desplaza desde el punto final de recopilación de Google a esa misma ruta.

El dominio es tuyo. Google gestiona la infraestructura que hay detrás. Tu CDN o equilibrador de carga (Cloudflare, Fastly, Akamai, Google Cloud) reenvía esa ruta a Google. La instalación consiste principalmente en cambiar la configuración de la CDN y actualizar el contenedor.

También hay una segunda forma de ejecutar GTG: habilitándolo dentro de un contenedor GTM existente del lado del servidor. En ese caso, GTG se ejecuta donde se ejecute tu contenedor, normalmente un subdominio como data.yoursite.com.

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 al 4-6% para los datos de Google que, de otro modo, se descartarían a nivel de secuencia de comandos(véanse los datos comparativos de Niek Schlepers).

Dos cosas que GTG no arregla

1. El problema del camino

En primer lugar, GTG no resuelve el problema de la ruta. GTG cambia el dominio y te permite elegir un prefijo de ruta personalizado, pero los patrones de punto final conocidos permanecen en la URL. Una solicitud de recogida de datos GA4 sigue llegando a /g/collect detrás de tu prefijo, algo así como tuweb.com/metrics/g/collect?v=2&tid=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 en la mayoría de las principales listas de bloqueo, independientemente del dominio que lo sirva. Los bloqueadores más sofisticados siguen captando estas solicitudes, 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 server-side correcta 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 otra laguna que cubre GTM server-side. 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 server-side. Si las campañas multicanal están perdiendo señal y esto empieza a notarse en el rendimiento de tu retargeting(aquí te explicamos cómo recuperar la pérdida de datos), la solución estructural reside en una canalización de eventos a todas las plataformas.

¿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 a nivel de nombre de host (las rutas conocidas como /g/collect permanecen expuestas)	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%*

*Comprueba los datos y la comparación en ¿GTG o GTM del lado del servidor? El dilema del lado del servidor por Niek Schlepers

También hay una distinción técnica que merece la pena comprender si te importa el comportamiento del mismo sitio frente al mismo origen. La configuración de la CDN de GTG requiere una ruta en tu dominio raíz (tu_sitio.com/metrics), que tiene el mismo origen que tu sitio. Una implementación típica de sGTM se ejecuta en un subdominio como data.yoursite.com. Es el mismo sitio, pero no el mismo origen. También puedes desplegar sGTM detrás de una ruta de dominio raíz, pero eso requiere un proxy inverso delante de tu contenedor. Algunos navegadores y algunos bloqueadores tratan de forma diferente los subdominios y las rutas del dominio raíz, por lo que la ubicación de tus puntos finales es una elección arquitectónica, no estética.

¿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 server-side 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 server-side 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 datos. sGTM te permite decidir qué se reenvía a cada plataforma, aplicar la lógica de consentimiento server-side 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 las conversiones llegan con el tiempo a la GTM server-side. La GTM puede ser un primer paso útil. Pero no resuelve la cuestión de la infraestructura.

¿Pueden trabajar juntos GTG y Server-Side?

Técnicamente, Google Tag Gateway y GTM server-side operan en capas diferentes, por lo que no siempre entran en conflicto. Sin embargo, por lo general no recomendamos ejecutar ambos a la vez. En la práctica, combinar GTG con tu configuración server-side puede interferir con la configuración existente de tu servidor. Y como el riesgo no siempre es predecible, nuestro consejo es que elijas un enfoque en lugar de superponerlos.

Si ya estás utilizando GTM server-side con TAGGRS, no necesitas GTG para la entrega de scripts. El Script de Seguimiento Mejorado ya se encarga de esa tarea, sirviendo los scripts de etiquetas de Google desde tu propio dominio y gestionando la persistencia de las cookies en el server-side. GTG estaría resolviendo un problema que ya has resuelto, con una complejidad añadida y posibles conflictos por el camino.

¿Quieres evaluar qué configuración se ajusta a tus necesidades? Consulta la tabla comparativa de arriba.

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 utilizas GA4 y Google Ads sin ningún tipo de seguimiento server-side, 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 desde dónde se cargan tus scripts de Google. Tu propio dominio 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 seguir detectando y bloqueando las solicitudes.

El etiquetado server-side 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 publicidad no pueden tocar. Y a diferencia de GTG, sGTM funciona en todas las plataformas con una API server-side, 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 se encarga de la canalización 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.