La mayoría de migraciones de contenedor GTM fallan por la misma razón: se copian los tags de un contenedor a otro sin entender por qué algunos datos no llegaban en primer lugar. El resultado es una migración que arrastra el mismo problema al nuevo contenedor.
El síntoma: discrepancias sin explicación
En un proyecto real de migración de e-commerce en el sector hotelero, tras la migración inicial aparecieron discrepancias de datos entre las propiedades origen y destino. La respuesta habitual, “volver a copiar los tags”, no soluciona nada si no se sabe por qué fallaban.
Auditar antes de mover una sola pieza
Se auditó el contenedor completo: 21 tags, 64 triggers y 177 variables. El resultado reveló tres causas de exclusión de datos operando en paralelo, no una sola:
- Una variable global de toggle mal gestionada
- Una lista negra por expresión regular con 35 IDs de exclusión
- Una tabla de sitios bloqueados, completamente independiente de las otras dos
Tres sistemas distintos silenciando datos por razones distintas, cada uno invisible si solo se mira el contenedor de forma superficial.
La migración en sí
Con las tres causas ya identificadas, el export se hizo con resolución recursiva de dependencias: verificando que cada variable, trigger y tag movido mantuviera intacta su cadena de referencias, sin romper nada al reorganizar. En paralelo, se limpiaron los tags heredados de Universal Analytics, ya obsoletos pero aún presentes y generando ruido.
El resultado
El contenedor pasó de 177 a 102 variables y de 21 a 7 tags, sin una sola referencia rota: una reducción de complejidad de más del 40% en variables sin perder funcionalidad. No era un ajuste puntual: era la base de un proyecto pensado para escalar a miles de contenedores cliente, y un contenedor con deuda técnica no habría soportado esa escala.
La checklist mínima antes de migrar cualquier contenedor
- Auditar el 100% de tags, triggers y variables antes de tocar nada
- Buscar explícitamente lógica de exclusión duplicada (toggles, blacklists, tablas externas)
- Resolver dependencias de forma recursiva, no copiar y pegar
- Retirar herencia obsoleta (Universal Analytics y similares) en el mismo proceso
- Validar en Preview antes de dar la migración por cerrada
- Correr ambos contenedores en paralelo unos días y comparar evento a evento antes del corte definitivo
El error más caro no es técnico, es de proceso
En casi todos los proyectos de migración que he visto fallar, la causa raíz no era una variable mal movida — era que nadie definió de antemano cuánto tiempo correrían ambos contenedores en paralelo, ni quién revisaría las discrepancias durante esa ventana. Decidir eso antes de empezar, no durante, es lo que separa una migración controlada de una donde el primero en notar el problema es un cliente preguntando por qué las conversiones bajaron.
Este artículo describe un caso real documentado, ejecutado a través de una agencia de marketing digital. Cliente final anonimizado por confidencialidad.