Google cambió cómo GTM maneja gtag config. Tus triggers pueden fallar
Por el equipo de Mayab Media
La mayoría del tracking roto no truena con ruido. Simplemente empieza a contar cosas dos veces y nadie se da cuenta en tres meses.
Ese es el riesgo de un cambio pequeño en Google Tag Manager que salió el 8 de octubre de 2026. Si tu contenedor tiene un trigger "atrapa todo", o si tu desarrollador pegó hace años un snippet de GTM junto a una línea suelta de gtag config, tienes que revisarlo ya. No el próximo trimestre.
Qué cambió Google en realidad
Las notas de versión de Tag Manager lo registran como "Standardizing gtag('config') command behavior". Pasaron dos cosas.
Primero, todo snippet de contenedor gtm.js ahora se inicializa cuando carga el contenedor, haya o no un comando gtag('config') en la página. Antes, algunas configuraciones esperaban esa llamada de config.
Segundo, cualquier comando gtag('config') en la página ahora se envía al dataLayer como un evento gtag.config. Suena inofensivo. No lo es, para un grupo específico de personas.
Google lo dice sin rodeos: si tus contenedores usan triggers de evento personalizado con comodín, esos tags ahora podrían dispararse con los nuevos eventos de config. Un trigger comodín es un trigger de Custom Event configurado como .* con coincidencia por regex. Se dispara con cada evento que llega al dataLayer. Ahora hay un evento más con el cual dispararse.
La cobertura de PPC Land agrega la otra mitad. Los sitios que cargan un snippet de contenedor gtm.js y luego llaman gtag config con un ID G-, AW- o DC- por su cuenta (sin el snippet completo de gtag.js) tienen una configuración que Google considera no compatible. Google les mandó un correo a los dueños de contenedores en esa situación y les pidió cambiar al snippet completo de gtag.js. No dijo cuántas personas recibieron ese correo.
Este cambio también encaja en un plan más grande. Google lleva todo el año integrando el Google tag dentro de Tag Manager, y los nuevos snippets de implementación ya no van a incluir ningún comando de config. Así que no es algo aislado. Es hacia donde van las cosas.
Por qué te cuesta dinero
Esta es la reacción en cadena.
Un trigger comodín se dispara una vez extra en cada página donde corre config. Si ese trigger está ligado, por ejemplo, a un evento personalizado del Meta Pixel, a un tag de LinkedIn o a un evento de "interacción con la página" que mandas a Google Ads como conversión secundaria, acabas de inflar un número.
Las conversiones infladas hacen dos cosas malas. Tus reportes se ven mejor que la realidad, así que sigues financiando campañas que no rinden. Y si el evento se usa para pujar, la puja automática aprende de una señal falsa y empieza a perseguir a los usuarios equivocados.
La configuración de snippet no compatible es peor, de una forma más silenciosa. Google dice que esos sitios podrían ver cambios inesperados en el comportamiento de los tags. Inesperado normalmente significa "algo dejó de dispararse y tus conversiones bajaron". Si no sabías que tu configuración estaba en ese grupo, vas a culpar a la campaña, a la temporada o a los creativos. Y vas a estar equivocado.
Nuestra opinión honesta: los triggers comodín siempre fueron un atajo. Son útiles para depurar y registrar. Son mala idea en producción para cualquier cosa que toque plataformas de anuncios. Este cambio solo hace visible el costo.
Tu plan de acción para esta semana
En la mayoría de los contenedores lo haces en menos de una hora.
-
Busca triggers comodín en tu contenedor. En GTM, abre Triggers y busca cualquier trigger de Custom Event con el nombre de evento
.*y la casilla "Use regex matching" marcada. Anota cada tag que use uno. -
Decide si cada uno debe existir. Para cada tag con trigger comodín, pregúntate: ¿de verdad necesita dispararse con cada evento del dataLayer? Casi siempre la respuesta es no. Cámbialo por un trigger para los eventos específicos que te importan.
-
Filtra el evento de config donde conserves comodines. El consejo de Simo Ahava, citado por PPC Land, es excluir
gtag.configa nivel de trigger. En la práctica, agrega una condición al trigger para que solo se dispare cuando Event no sea igual agtag.config. Y anota el cambio en tus anotaciones para que tu yo del futuro entienda cualquier salto en los datos. -
Revisa cómo carga tu sitio los tags de Google. Mira el código fuente de algunas páginas clave (inicio, producto, checkout, página de gracias). Busca un snippet de GTM (gtm.js) más una línea separada de
gtag('config', 'G-...')o'AW-...'sin la etiqueta completa del script gtag.js. Si ves esa combinación, cámbiala por el snippet completo de gtag.js de Google o mueve la config a GTM de forma correcta. -
Usa el modo Preview y observa el flujo de eventos. Carga una página en Tag Assistant. Ahora deberías ver un evento
gtag.configdonde haya comandos de config. Dale clic y revisa qué tags se dispararon. Si se disparó algo relacionado con anuncios, encontraste una fuga. -
Compara conversiones antes y después del 8 de octubre. Saca las conversiones diarias de cada plataforma de anuncios de las dos semanas anteriores y posteriores. Un salto repentino hacia arriba sin cambios en la campaña es una alerta roja. Una caída repentina, también.
-
Revisa tu bandeja de entrada. Busca en el correo ligado a tu cuenta de GTM mensajes de Google sobre instalaciones no compatibles. Si te llegó uno, esa es tu corrección más urgente.
Qué vigilar después
Google está empujando a todos hacia un solo modelo: contenedores de Tag Manager que manejan directamente los destinos de Google, sin llamadas de config sueltas. Cada paso de ese movimiento va a desacomodar configuraciones que funcionaban "de casualidad". El momento más barato para limpiar es antes del próximo cambio, no después de un mes de datos malos.
Si no has abierto tu contenedor de GTM desde que se fue quien lo armó, esa es tu señal.
En resumen: un solo evento nuevo en el dataLayer puede inflar en silencio cada tag con trigger comodín, así que audita esos triggers esta semana.
¿Quieres que revisemos cómo te afecta esto? Agenda una auditoría gratis.
