16 December, 2024
· 0 comentarios
El 20 de mayo de 2026, coincidiendo con el Google Marketing Live, Google anunció la unificación de Google Tag Manager y Google Tag en una infraestructura de programación compartida. Los cambios afectan a cómo se carga el JavaScript de etiquetado en la página, al snippet de instalación, y a la forma en que se gestionan las configuraciones de GA4, Google Ads y Floodlight dentro de GTM. Algunos aspectos son menos relevantes para nuestro trabajo diario. Otros en cambio, requieren una revisión completa antes de aceptar la actualización.
En este post vamos a explicarlo todo de forma ordenada, sin rodeos, y con la honestidad de reconocer dónde están todavía los flecos sin resolver. Lo hemos ido destilando de conversaciones internas, del análisis de Simo Ahava en LinkedIn, y de la documentación oficial de Google.
Hasta ahora Google tenía dos sistemas de etiquetado que convivían con cierta incomodidad:
Google Tag Manager es el contenedor clásico y código más antiguo, con IDs tipo GTM-XXXXX. Permite cargar cualquier tipo de etiqueta, tanto de Google como de terceros, con control total sobre triggers, variables y versiones.
Google Tag (antes conocida como gtag.js) es el sistema más moderno, con IDs tipo G-XXXXX para GA4 o AW-XXXXX para Google Ads. Más limitado en alcance: solo envía datos a productos de Google. Carga su propio archivo JavaScript de forma independiente al contenedor GTM.
El problema que hace necesario el nuevo update de Google y la unificación, es que muchos sitios usan (o usaban, si lo lees tras el update total) los dos códigos a la vez. Eso generaba cargas duplicadas de JavaScript y configuraciones fragmentadas de ciertos ajustes entre herramientas. GTM había quedado algo rezagado en desarrollo mientras Google Tag recibía mejoras continuas. Unificarlos resuelve ese desajuste.
Este es el más significativo. Según la documentación oficial del update de Google, los sitios que actualmente despliegan únicamente una Google Tag con ID G- o AW- ganarán acceso a la interfaz completa de Tag Manager, incluyendo herramientas de depuración, control de versiones y configuración desde la interfaz. En teoría no hay cambio en cuanto a funcionamiento anterior, solo ganancia:
Google lo deja claro: «Esta actualización no cambiará el comportamiento de las etiquetas de Google en la página. Lo que implicará es que los anunciantes que utilicen la etiqueta de Google podrán usar las funciones de Google Tag Manager.»
Dicho de otra forma: no cambia lo que las etiquetas hacen en la página. Lo que cambia es que quien solo usaba Google Tag ahora tendrá acceso a toda la potencia de GTM.
Hay un matiz técnico importante aquí que tiene que ver con qué tipo de snippet estamos usando:
GTM-XXXXX: funciona como contenedor GTM completo, con soporte para tags de terceros, HTML personalizado, etc.G- o AW-: queda restringido a enviar datos solo a servicios de Google. No carga otros tipos de etiquetas.Esto importa en entornos donde hay preocupación por el uso no controlado de GTM. Elegir el ID de producto en lugar del ID de contenedor GTM es una forma de acotar el alcance.
Este es el cambio más concreto para quien ya trabaja con GTM y tiene varios productos de Google configurados (GA4, Google Ads, Floodlight, etc.).
Hasta ahora, cada vez que GTM lanzaba una etiqueta de GA4 o de Ads, cargaba una instancia adicional de gtag.js.
Si tenías tres productos de Google, tenías tres cargas adicionales de JavaScript encima del propio
gtm.js.
Tras la optimización, eso desaparece. El contenedor GTM envía datos directamente a los destinos de Google sin necesidad de cargar ese archivo extra por producto. Según Google: «Previously, Google Tag Manager loaded extra JavaScript (gtag.js) to send data to a Google destination, which could cause latency in measurement transmission.»
El impacto práctico es real: menos JavaScript en carga, menor latencia en transmisión de datos, y mejor rendimiento general de la página. Especialmente relevante en conexiones móviles lentas o en mercados con ancho de banda limitado.
Importante: esto no es automático. Google lo dice explícitamente: no se realizarán cambios sin que tú los aceptes. Aparecerá un banner en la interfaz de GTM cuando el despliegue llegue a tu contenedor, y desde ahí puedes iniciar el flujo de optimización, previsualizar todos los cambios antes de publicarlos, y decidir si procedes.
gtag configEste es el cambio técnico que más puede afectar a implementaciones existentes si no se gestiona con cuidado. Y también es el más complejo de explicar.
Todos los nuevos snippets de instalación de GTM/GTAG ahora serán iguales y ya no incluirán el comando gtag('config', ...). No serán personalizables en el código ciertos ajustes, o no como antes.
Hasta ahora ese comando era el que pasaba parámetros de inicialización críticos directamente desde el snippet en el HTML de la página. Cosas como send_page_view: false, configuración de cookies personalizada, o cualquier parámetro que necesitase aplicarse en el momento exacto de carga, antes de que GTM procesara ninguna etiqueta.
La forma correcta de gestionar eso a partir de ahora es a través de una etiqueta de Google dentro del contenedor GTM configurada para dispararse en el trigger de tipo Initialization (el trigger gtm.init, que es el primero en ejecutarse, antes incluso que el All Pages).
Esa etiqueta de Google es donde se establecen los parámetros de inicialización que antes iban a veces en el snippet (en las ocasiones en que se personalizaba este).
Importante: Si tienes parámetros en el gtag config del snippet y no los has trasladado a una etiqueta de inicialización en GTM antes de aceptar la actualización, esas configuraciones dejarán de aplicarse en el momento correcto. El resultado habitual son pageviews duplicados o pérdida de parámetros tipo page_type y similares, en el primer evento.
Google también señala que el trigger de inicialización puede configurarse para esperar al comando config, lo que da una vía de migración parcial para setups construidos con el patrón anterior y cuyo snippet no se pueda o desee cambiar.
La interfaz de GTM tendrá una nueva pestaña Settings que actúa como mapa centralizado del flujo de datos del contenedor hacia los destinos de servicios Google. Desde ahí se gestionarán los destinos de Google a los que aplican las configuraciones globales: seguimiento multidominio, exclusión de tráfico de referencia no deseado, eventos mejorados de GA4, filtros de tráfico interno, etc.
Parte de lo que antes vivía disperso entre la interfaz de Google Analytics, Google Ads y otros productos ahora se puede gestionar desde un único punto. Si haces un cambio ahí, se propaga a todos los destinos que tengas vinculados.
Además, vincular el contenedor a tus cuentas de Google Ads o Analytics hace que sea visible y gestionable directamente desde esos productos. El acceso de lectura se concede por defecto durante la optimización, y se puede ajustar después desde la gestión de usuarios de GTM.
No, al menos no en lo fundamental. Las etiquetas, los triggers y las variables siguen funcionando exactamente igual. Si tienes una etiqueta de GA4 configurada en GTM, sigue ahí y sigue funcionando. El flujo de trabajo diario no cambia.
Lo que cambia es cómo se gestiona la configuración global de los productos de Google, que pasa a centralizarse en la nueva pestaña Settings.
Aquí hay que distinguir dos capas que se mezclan con facilidad.
Por un lado está la carga de la librería gtag.js: esa desaparece. Ya no se carga de forma adicional por cada producto de Google. Eso está claro y es uno de los beneficios principales de la optimización.
Por otro lado está la etiqueta de configuración dentro de GTM — la que dispara en All Pages o en el trigger de inicialización y que define el Measurement ID, el comportamiento del pageview, los parámetros de cookies, etc. Esa, de momento, sigue siendo la forma de inicializar GA4 y los demás productos.
La documentación oficial dice que tras la optimización «Google tag settings will be brought into the new Settings tab» — lo que sugiere que parte de esa configuración base podría centralizarse ahí y dejar de necesitarse en una etiqueta separada. Pero el nivel de detalle sobre qué parámetros concretos migran a Settings y cuáles siguen viviendo en la etiqueta no está suficientemente documentado todavía.
Es decir: no sabemos con certeza si tras aceptar la actualización la etiqueta de configuración de GA4 o de Ads sigue siendo imprescindible tal como la tenemos hoy, o si parte de su función queda absorbida por la pestaña Settings. Esto es algo que habrá que verificar en detalle cuando llegue el banner, revisando exactamente qué cambios propone el flujo de optimización antes de publicarlos.
No en el sentido de que rompa nada. Simo Ahava lo clarificó directamente: la optimización afecta a la entrega de JavaScript en el sitio, pero el control de consentimiento, los triggers, las señales reducidas y todo lo demás funciona igual que antes.
Dicho esto, hay un matiz regulatorio que conviene tener en mente si trabajas en mercados con alta sensibilidad legal como Alemania, Francia o Países Bajos. Algunos analistas han señalado que convertir GTM en un sistema aún más integrado podría ser relevante en interpretaciones regulatorias sobre el umbral de carga antes del consentimiento. No es un problema inmediato, pero es algo a seguir.
Sí. GTM mantiene el sistema de versiones, así que puedes volver a una versión anterior del contenedor si algo no funciona como esperabas. La optimización permite previsualizar todos los cambios antes de publicarlos, lo que da margen para revisar antes de comprometerse.
Es la tercera pata del anuncio. A través de la plataforma unificada, será posible crear eventos y configurar conversiones para productos de Google sin necesidad de código manual. Se pueden seleccionar elementos directamente en el sitio web y el sistema gestiona en segundo plano los selectores y triggers.
De momento está en beta para conversiones de compra en Google Ads, y se irá extendiendo a más casos de uso a lo largo del año.
Cuando te llegue el banner, no lo aceptes sin haber comprobado lo siguiente:
gtag config? Documenta qué parámetros son y planifica trasladarlos a una etiqueta de Google dentro de GTM configurada para disparar en el trigger de Initialization (gtm.init).GTM- o un G-/AW-, porque el comportamiento tras la actualización varía.
El cambio es relevante, pero no es una revolución que rompa lo que tienes montado. Es más una puesta al día de una arquitectura que llevaba tiempo con deuda técnica acumulada. Google ha desarrollado mucho la librería Google Tag en los últimos años y nunca había trasladado esas mejoras con este calado a GTM.
El impacto real está en dos sitios: el rendimiento (menos JavaScript cargando en la página) y la gestión centralizada de configuraciones que antes vivían dispersas. El riesgo está en el cambio del snippet y en los parámetros de inicialización, que requieren atención antes de aceptar la actualización.
Nada que con una revisión ordenada no se pueda gestionar bien.
Fuentes:
16 December, 2024
08 June, 2023
08 June, 2023
Comentarios
Deja un comentario
Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *