Google Tag Gateway: qué es, por qué y cuándo usarlo

En los últimos meses, Google Tag Gateway (también conocido como GTG) ha pasado de ser una implementación poco visible a convertirse en un tema de conversación habitual. Creo que esto se debe a que Google ha empezado a destacarlo cada vez más en sus conversaciones y a que ha aumentado la demanda de seguimiento first-party.

Soy Manisha Mistry, Technical Lead en MeasureU. Me gusta explicar temas como el seguimiento del lado del servidor, por lo que cada vez recibo más preguntas sobre Google Tag Gateway. En concreto, durante los últimos meses me han planteado repetidamente las siguientes cuatro preguntas.

• ¿Qué es Google Tag Gateway?
• ¿Debería utilizarlo?
• ¿Cuál es la diferencia con el seguimiento del lado del servidor?
• ¿Lo necesito si ya utilizo el seguimiento del lado del servidor?

El objetivo de este artículo es responder a estas cuatro preguntas. Como siempre, empezaré por los conceptos básicos y después explicaré en detalle cómo funciona Google Tag Gateway y en qué se diferencia del seguimiento del lado del servidor. Terminaré con un marco de decisión al que puede volver de vez en cuando para determinar qué solución de seguimiento es adecuada para usted y su cliente.

Una breve aclaración antes de empezar: este artículo se basa en mi propia configuración y en mis pruebas de GTG en el momento de redactarlo. Google desarrolla constantemente GTM, GTG, sGTM y el ecosistema de etiquetado en general. Por ello, algunos aspectos pueden cambiar a medida que el producto evoluciona. Los conceptos fundamentales seguirán siendo los mismos, pero las rutas exactas, las opciones y las pantallas pueden cambiar.

Toda configuración de Analytics comienza con el seguimiento del lado del cliente.

Normalmente, esto implica instalar GA4 en su sitio web, ya sea mediante Google Tag Manager (mi opción preferida) o mediante una integración con el sitio web. En ambos casos, los scripts se ejecutan en el navegador del visitante y los dominios utilizados para estos scripts suelen ser de Google.

Por ejemplo, pueden ser...

• www.googletagmanager.com (para el script del contenedor de GTM)
• www.google-analytics.com (para los eventos de recopilación de GA4)
• googleads.g.doubleclick.net (para las conversiones de Google Ads)

Lo importante es que los nombres de host son dominios de Google y no el dominio de su sitio web. Desde el punto de vista del navegador del visitante, se trata de solicitudes de terceros y no de solicitudes de first-party.

Las solicitudes de terceros no son un problema hasta que empieza a perder datos debido a los bloqueadores de anuncios, Safari Intelligent Tracking Prevention (ITP) y cualquier otro mecanismo que pueda bloquearlas.

Cuando está empezando con el seguimiento o su sitio web recibe poco tráfico y tiene un presupuesto publicitario reducido, el seguimiento del lado del cliente es un buen punto de partida y puede ser suficiente. Sin embargo, a medida que aumenta el tráfico y crecen los presupuestos de marketing, usted (o su cliente) empieza a prestar más atención a la diferencia entre «lo que se activó» y «lo que realmente se registró». Es entonces cuando entra en juego el seguimiento first-party.

Antes de hablar específicamente de Google Tag Gateway, detengámonos un momento para entender qué es realmente un gateway y cómo funciona.

La definición técnica de un gateway es un proxy inverso. Se sitúa entre sus visitantes y el endpoint de un proveedor y vuelve a presentar la solicitud como si procediera de su dominio. El contenido de la solicitud NO cambia EN ABSOLUTO; solo cambia el carrier, es decir, el nombre de host.

Hoy en día, los gateways están en todas partes. Por ejemplo, Meta ofrece Conversions API Gateway, TikTok ofrece Events API Gateway, y muchas otras plataformas también están desarrollando gateways. Son populares porque todos los proveedores se enfrentan al mismo problema: su script se ejecuta en el navegador, se bloquea y perdemos señales. Configurar un gateway es la forma más rápida de pasar las solicitudes de terceros a first-party.

Como siempre, me gustan las analogías. Para entender mejor los gateways y explicárselos a los clientes, utilizo una analogía que, según mi experiencia, funciona especialmente bien.

Todos hemos ido a la escuela en algún momento de nuestra vida o tenemos hijos que actualmente van a la escuela. A veces, para celebrar algo, un profesor pedía pizza para su clase y hacía que la entregaran en la escuela.

Donde vivo, las escuelas no permiten que un repartidor entre por la puerta principal, recorra el pasillo y vaya directamente a un aula. Esto se debe a que el repartidor es un tercero para la escuela. No ha pasado una comprobación de antecedentes y no tiene una identificación de la escuela.

La función de la escuela es impedir que terceros como el repartidor entren en los pasillos durante el día para proteger a los alumnos.

En su lugar, el repartidor no lleva la pizza directamente al aula. Va a la escuela, entra en recepción, entrega la pizza a un empleado de la escuela y este lleva la pizza el resto del camino hasta el aula.

La pizza que llega al aula es exactamente la misma que el repartidor llevó a la escuela. Sigue siendo una pizza de pepperoni, sigue caliente y sigue en la misma caja. Lo que ha cambiado es la persona que transporta la pizza por el pasillo. En lugar de un repartidor externo, ahora la lleva un empleado de la escuela que ha pasado todas las comprobaciones necesarias y está autorizado a circular por los pasillos. La clase recibe exactamente la misma pizza, pero desde el punto de vista de la escuela, la transferencia es completamente diferente.

En términos sencillos, eso es un gateway.

El contenido de la solicitud no ha cambiado. Sigue siendo una pizza, pero ha cambiado la persona que la transporta. Nadie que viera la pizza atravesar el pasillo tendría ningún problema, porque el empleado de la escuela forma parte de ella. Trabaja allí y está autorizado a estar en ese lugar.

En cambio, si el repartidor hubiera recorrido la escuela, habría sido un problema. Probablemente no le habrían dejado entrar o lo habrían detenido por el camino, porque no está autorizado a circular por la escuela.

Ahora que entendemos qué es un gateway, veamos Google Tag Gateway (GTG) con más detalle.

Esta es la definición de Google, directamente de su página de ayuda:

En términos sencillos, GTG es un proxy inverso que cambia el nombre de host de sus solicitudes de GA4 y Google Ads: en lugar de utilizar dominios de Google, utilizan el dominio de su sitio web. El contenido de las solicitudes, como eventos, parámetros, cookies y el estado del consentimiento, no cambia; solo cambia el carrier. Piense en la analogía de la pizza: la pizza sigue siendo la misma, solo cambia quién la transporta.

Antes de profundizar en GTG, hay algunos detalles importantes que debe conocer...

• GTG está limitado a Google - GTG está diseñado únicamente para volver a servir scripts de Google como GA4 y Google Ads desde su propio dominio. Esto significa que Meta Pixel, LinkedIn Insight y todas las demás solicitudes seguirán siendo solicitudes de terceros.
• Las cookies siguen siendo cookies de JavaScript - GTG no cambia la forma en que se establecen las cookies. El navegador sigue ejecutando el script de cliente de GA4 y las cookies siguen escribiéndose mediante JavaScript. Por lo tanto, puede seguir estando limitado por el máximo de 7 días de Safari ITP para las cookies de JavaScript.
• GTG no transforma ni elimina datos por sí solo - GTG no permite ajustar ni modificar los datos de la propia solicitud. Solo ajusta el encabezado; el cuerpo de la solicitud (su contenido) permanece exactamente igual.

Es importante comprender estos tres puntos al comparar Google Tag Gateway vs seguimiento del lado del servidor.

La página de documentación de Google presenta tres opciones para implementar GTG. Cada una desplaza una parte diferente de su seguimiento de terceros a first-party y supone un nivel de complejidad distinto. He configurado las tres opciones en mi propio sitio de demostración, datadrivenuniversity.com, para que pueda ver en cada caso una imagen real del antes y el después que muestra cómo ha cambiado el seguimiento.

Hay algo que quiero aclarar antes de empezar. Google presenta estas tres posibilidades como opciones independientes, pero después de configurar cada una, yo no las considero así. Más bien, considero que cada opción se basa en la anterior. Es mi opinión personal, basada en mi experiencia. Dicho esto, veamos cada opción.

Esta es la versión más sencilla de GTG, ya que no necesita modificar su configuración actual y solo requiere unos pocos clics.

Lo que cambia: las solicitudes de recopilación de GA4 y las conversiones de Google Ads se envían desde your-domain.com en lugar de google-analytics.com / googleads.g.doubleclick.net. Se convierten en solicitudes first-party.

Lo que no cambia: el propio script del contenedor de GTM sigue cargándose desde googletagmanager.com. Lo he confirmado en mi propia configuración. El contenido de sus solicitudes de GA4 y GAds también permanece exactamente igual.

Para mostrarlo en la práctica, configuré Google Tag Gateway con Cloudflare en mi sitio de prueba datadrivenuniversity.com. Así se veían mis solicitudes de GA4 antes de activar Google Tag Gateway.

Después configuré GTG con Cloudflare y GTM. Toda la configuración llevó aproximadamente tres clics. Después de eso, puede ver que el mismo hit de GA4 pasa ahora por mi propio dominio datadrivenuniversity.com/bppc.

Nota: observará que los hits de GA4 ahora empiezan por c? en lugar de collect?, debido a GTG.

Con esta implementación, he pasado mis solicitudes de GA4 de terceros a first-party. Ahora pasan por datadrivenuniversity.com/bppc en lugar de google-analytics.com. Lo mismo ocurre con mis conversiones de Google Ads, que pasan de googleads.g.doubleclick.net a la misma ruta first-party.

Al probar la opción 1, observé que mis solicitudes de Google Ads y GA4 habían pasado a first-party, pero el script de mi contenedor de Google Tag Manager seguía cargándose desde googletagmanager.com. Por tanto, GTM seguía siendo una solicitud de terceros. Aquí es donde entra en juego la opción 2, y Google Tag Gateway vs Google Tag Manager resulta especialmente relevante.

Lo que cambia: gtm.js se carga ahora desde su propio dominio, por ejemplo datadrivenuniversity.com/metrics/custom-path, en lugar de googletagmanager.com. De este modo, GTM, GA4 y Google Ads son todos hits first-party desde el punto de vista del navegador del visitante.

He configurado esto con un contenedor sGTM, utilizando un Google Tag Manager: web container client que me permite cargar el contenedor web de GTM desde el contenedor del servidor y definir una ruta personalizada. Existen otras formas de convertir GTM en first-party, pero sGTM es la que he probado.

Lo que no cambia: sus hits que no son de Google, como Meta Pixel, TikTok Pixel, LinkedIn Insight y cualquier otra etiqueta que no sea de Google, siguen siendo solicitudes de terceros.

Para mostrarlo en la práctica, aquí puede ver cómo se veía el script de mi contenedor web de GTM en DevTools antes de añadir el contenedor sGTM y hacer que cargara mi contenedor web.

Después de configurar un servidor y el contenedor sGTM, configurar un cliente y definir la ruta de publicación de las etiquetas, la solicitud ahora utiliza mi dominio y la ruta personalizada.

En este punto, mis solicitudes de GA4 y Google Ads pasan por Cloudflare como first-party, y mi contenedor sGTM también carga mi contenedor web de GTM desde un dominio first-party. Todas las demás plataformas siguen siendo de terceros.

La opción 3 es la implementación de GTG recomendada por Google y, sinceramente, fue la más difícil de configurar y entender. También cambió mi forma de ver Google Tag Gateway del lado del servidor frente al seguimiento del lado del servidor, pero dejaré esa conclusión para el final, para que tenga más sentido después de ver toda la configuración.

Un breve resumen de la situación:

• En la opción 1, pasamos nuestras solicitudes de GA4/Google Ads de terceros a first-party mediante el gateway (por ejemplo, Cloudflare). Esto significa que las solicitudes de los scripts de GA4/GAds (solo Google) y la recopilación de datos pasan a ser first-party.
• En la opción 2, pasamos el script de nuestro contenedor de GTM de terceros a first-party mediante un contenedor del servidor; nuestra recopilación de datos para el seguimiento exclusivo de Google seguía utilizando el gateway.
• En la opción 3, nuestros scripts siguen cargándose exactamente de la misma manera (scripts de GA4 mediante el gateway, GTM mediante el contenedor sGTM). Lo que cambia es que la recopilación de datos pasa por el servidor, lo que permite transformarlos antes de enviarlos a las plataformas posteriores.

Lo que cambia: en lugar de que los datos de nuestros eventos pasen por el CDN como hits first-party y se envíen directamente a Google, ahora pasan por nuestro contenedor sGTM. El contenedor sGTM recibe los eventos y podemos transformar, enriquecer o eliminar determinados datos antes de enviarlos a los sistemas posteriores. En la práctica, el seguimiento del lado del servidor funciona en paralelo con GTG. Utilizamos ambos al mismo tiempo.

Esta configuración también permite convertir las etiquetas que no son de Google, como Facebook, LinkedIn y TikTok, en first-party. Sin embargo, para ello es necesario configurar estas etiquetas en nuestro contenedor sGTM y realizar una implementación completa del seguimiento del lado del servidor. Una vez completada esta configuración en el contenedor sGTM, estos hits también pasan por el servidor y se convierten en hits first-party.

Lo que no cambia: el script de nuestro contenedor de GTM sigue sirviéndose desde nuestro servidor sGTM (heredado de la opción 2). Las llamadas de configuración de GA4 siguen sirviéndose desde nuestro CDN (heredado de la opción 1).

Para mostrarlo en la práctica, aquí puede ver cómo eran mis hits de recopilación de GA4 en la opción 2, cuando pasaban por mi ruta de Cloudflare.

Después de definir la URL del contenedor del servidor en mi etiqueta de configuración del contenedor web de GTM y configurar un cliente de GA4 y una etiqueta de GA4 en mi contenedor sGTM, mis solicitudes de recopilación pasan ahora por el servidor sGTM.

Con esta implementación, la recopilación de mis eventos de GA4 pasa ahora por mi contenedor sGTM, donde puedo dirigir, enriquecer o eliminar los datos antes de enviarlos a las plataformas posteriores. El mismo enfoque puede aplicarse a cualquier otra plataforma, incluidas las plataformas que no son de Google, siempre que configure las etiquetas y los activadores necesarios en mi contenedor web/del servidor.

Ahora que entendemos qué es Google Tag Gateway y las tres formas de implementarlo, la siguiente pregunta lógica que siempre me hacen es: ¿cuál es la diferencia entre Google Tag Gateway y el seguimiento del lado del servidor?

En mi opinión, no son productos competidores.

Google Tag Gateway, y en particular la opción 1, consiste en enrutar sus eventos para que pasen de terceros a first-party a nivel del encabezado de la solicitud. El seguimiento del lado del servidor se centra en el control: tener más control sobre sus datos y, por tanto, pasar al seguimiento first-party. Esto también se refleja en la documentación de Google: en la opción 3 descrita anteriormente, para obtener más control sobre sus datos, debe introducir un contenedor del servidor y hacer pasar sus eventos por ese contenedor.

Para explicar la diferencia entre ambos, aquí tiene una tabla comparativa rápida:

En resumen, Google Tag Gateway y el seguimiento del lado del servidor no son productos competidores. Uno le permite pasar rápidamente al seguimiento first-party, únicamente desde el punto de vista de las solicitudes. El otro le proporciona un control total sobre sus datos. Puede empezar con uno y pasar al otro cuando cambien sus necesidades, y precisamente ahí entra en juego el marco de decisión.

Al comparar Google Tag Gateway vs lado del servidor, puede elegir entre Google Tag Gateway, el seguimiento del lado del servidor o incluso seguir utilizando el seguimiento del lado del cliente. Esta es una de las preguntas que más me hacen, tanto en MeasureU como en la comunidad de LinkedIn. También es una de las primeras cosas que preguntan los clientes cuando comenzamos un proyecto de implementación. Por eso he creado un marco de decisión que le ayudará a tomar esta decisión.

Lo importante es entender que este marco no está pensado para utilizarse una sola vez. Lo recorre una primera vez y vuelve a él periódicamente a medida que evoluciona su proceso de medición. Puede empezar con el seguimiento del lado del cliente, pasar a GTG y adoptar más adelante el seguimiento del lado del servidor cuando cambien sus necesidades.

Recorra hoy el marco para determinar en qué punto se encuentra de su proceso. Después de unas semanas o meses de trabajo, vuelva a él y repítalo. Utilícelo como guía para saber cuándo mejorar la medición de su sitio web o del sitio web de su cliente.

En mi opinión, después de probar Google Tag Gateway, es una excelente solución rápida para el seguimiento exclusivamente de Google. Si elige simplemente la opción 1, sus solicitudes de GA4 y Google Ads pasan de terceros a first-party en unos tres clics.

Sin embargo, como hemos visto en la propia documentación de Google, en cuanto quiera tener más control sobre sus datos, deberá pasar a la opción 3. Esto significa configurar un servidor y un contenedor del servidor y, después, hacer pasar la recopilación de datos por el contenedor sGTM. Cada organización tiene su propia stack de medición, un nivel de tráfico diferente y necesidades específicas de control de datos. Precisamente para eso sirve el marco de decisión y por eso lo he diseñado para utilizarlo varias veces.

Como he trabajado con ambos, diría que Google Tag Gateway, y en particular la opción 1, es una excelente solución rápida para el seguimiento exclusivamente de Google. Dicho esto, en mi opinión, si realmente quiere controlar sus datos en todas las plataformas, la opción 3 requiere en realidad más trabajo que pasar directamente al seguimiento del lado del servidor, porque de todos modos tendría que realizar la mayor parte de ese trabajo. Si ese es su objetivo, le recomiendo pasar directamente al seguimiento del lado del servidor. Puede implementar su propio servidor y contenedor aquí.