¿Tengo que migrar mi contenedor ya?

No hay prisa real. El consenso entre quienes ya lo han probado es dejar que los primeros en adoptarlo encuentren los casos límite, y migrar primero un contenedor de bajo riesgo para probar el flujo antes de aplicarlo a producción.

¿Afecta esto a mi configuración de Consent Mode v2?

Sí, y es la parte más relevante. Con el modelo de Destinations, el consentimiento se puede configurar una sola vez a nivel de contenedor en vez de repetirlo tag a tag, lo cual reduce el riesgo de configuraciones de consentimiento desincronizadas entre sí, un problema muy común en contenedores heredados.

¿Cómo pruebo esto sin arriesgar el contenedor de producción?

Duplica el contenedor a un workspace aislado (o a una propiedad de pruebas si tu plan lo permite), migra ahí primero, y valida en Preview/DebugView cada tag afectado antes de tocar el contenedor real. Si algo depende de gtag config y no lo detectaste antes de migrar, en un entorno aislado el fallo no cuesta datos de producción.

¿Esto sustituye la necesidad de una migración de contenedor completa?

No. Son dos cosas independientes: pasar de Tag de Configuración a Google Tag es un cambio de modelo dentro del mismo contenedor. Migrar de un contenedor a otro (por ejemplo, al consolidar varias propiedades) sigue siendo el proceso que ya cubrí en la checklist de migración — de hecho, conviene hacer ambas cosas en el mismo ciclo de auditoría si vas a tocar el contenedor de todas formas.

GTM se está convirtiendo en Google Tag: qué cambia y qué auditar antes de actualizar

Desde el Google Marketing Live de mayo de 2026, Google Tag Manager está cambiando de forma más profunda que un simple rediseño de interfaz. La pieza central es un concepto nuevo: Destinations.

Qué cambia técnicamente

Hasta ahora, cada Google Tag dentro de un contenedor (GA4, Google Ads, Floodlight) cargaba su propio archivo gtag.js por separado. Con el nuevo modelo, un único Google Tag puede gestionar la configuración de varios destinos desde una sola instancia, sin cargas adicionales de librería por cada uno.

El Tag de Configuración de GA4 que todos conocemos está siendo sustituido por el nuevo Google Tag. Por fuera se ven casi iguales: sigues arrastrando un tag, le pones un Measurement ID, lo disparas en todas las páginas. La diferencia importante está por debajo.

El riesgo real no es perder datos

Es la deriva de configuración (configuration drift). Con el nuevo modelo, ciertos ajustes pueden vivir fuera del contenedor, gestionados desde la interfaz del propio producto en vez de desde GTM. Si tu forma de trabajar asume que “el contenedor es la fuente única de verdad” (como asume casi cualquier proceso de gobernanza serio), esa suposición deja de sostenerse del todo.

El escenario típico que esto puede producir: una caída del 12% en conversiones registradas que nadie sabe explicar tres semanas después, porque el cambio no quedó registrado como una versión nueva del contenedor.

Qué revisar antes de tocar nada

Contenedores con consent gating activo en varios tags
Contenedores con múltiples Measurement IDs o conversiones de Google Ads enlazadas a través de GA4
Tags dependientes que asumen que el tag de configuración se disparó antes que ellos
Los nuevos snippets de despliegue ya no incluyen el comando gtag config: si tu configuración depende de él, hace falta gestionar la inicialización con el trigger gtm.init

La parte que sí es una buena noticia

Los ajustes de consentimiento y de medición cross-domain, antes repetidos (y a veces desincronizados) tag a tag, ahora se pueden definir una sola vez a nivel de contenedor mediante Destinations. Para quien ha heredado un contenedor con cinco configuraciones de consentimiento ligeramente distintas entre sí (un problema más común de lo que parece), esto es una mejora real.

La recomendación que se repite en todas las fuentes técnicas serias

Dejar que los primeros adoptantes encuentren los casos límite. Migrar primero un contenedor de bajo riesgo para probar el flujo completo, documentar dónde vive cada destino antes de tocar nada, y validar en un workspace aislado antes de aplicar el cambio a producción.

Si ya vas a tocar el contenedor, aprovecha para auditar el resto

Un cambio de esta magnitud es el momento natural para revisar todo lo que llevas años posponiendo: variables sin usar, triggers duplicados, tags con gates de consentimiento inconsistentes entre sí. Ya documenté el proceso completo de migración de un contenedor de 177 variables reducido a 102 sin perder datos — el mismo criterio aplica aquí, solo que el disparador es Destinations en vez de una consolidación de propiedades.

Este artículo resume anuncios oficiales de Google (Google Marketing Live, mayo de 2026) y análisis técnicos publicados por varias fuentes especializadas entre mayo y julio de 2026. Si quieres que audite tu contenedor antes de decidir si migrar ahora o esperar, puedo ayudarte.