Discrepancias de datos entre propiedades tras migrar eventos de e-commerce GA4 de un contenedor a otro.
Auditoría de 21 tags, 64 triggers y 177 variables: tres causas de exclusión de datos operando en paralelo (variable de toggle, blacklist regex de 35 IDs, tabla de sitios bloqueados).
Export validado con resolución recursiva de dependencias y limpieza de tags de Universal Analytics obsoletos.
Contenedor reducido de 177 a 102 variables y de 21 a 7 tags, sin referencias rotas. Arquitectura pensada para escalar a miles de contenedores cliente.
Contexto
El proyecto no era una migración puntual, sino la base de un proceso pensado para replicarse en miles de contenedores cliente. Eso cambiaba el criterio de éxito: no bastaba con que la migración funcionara una vez, tenía que ser un proceso repetible sin que cada ejecución requiriera descubrir de cero los mismos problemas.
Cómo se resolvió, en detalle
Tres sistemas de exclusión que nadie había cruzado entre sí
La variable de toggle, la blacklist de 35 IDs por regex, y la tabla de sitios bloqueados se habían añadido en momentos distintos, por necesidades distintas, sin que ninguna documentación las relacionara. Cada una por separado parecía intencional. Juntas, silenciaban datos de formas que se solapaban parcialmente — lo que hacía casi imposible saber, mirando solo los números finales, cuál de las tres estaba actuando en cada caso.
Qué significa "resolución recursiva de dependencias" en la práctica
Antes de mover cualquier tag, se trazó su cadena completa: qué variables lee, de qué otras variables dependen esas variables, y qué triggers las usan en sus condiciones. Migrar sin ese trazado es la causa más común de que un tag llegue al contenedor nuevo pero deje de disparar en silencio — la referencia rota no da ningún error, simplemente deja de funcionar.
Por qué reducir variables no fue el objetivo, fue la consecuencia
Bajar de 177 a 102 variables no era una meta de "limpieza" — fue lo que quedó al eliminar exactamente la lógica duplicada y la herencia de Universal Analytics ya obsoleta. Un contenedor pensado para escalar no puede arrastrar deuda técnica invisible; cada variable de más es una superficie más grande donde el próximo problema puede esconderse.
La causa de una discrepancia de datos casi nunca es una sola cuando el contenedor lleva años en producción. Buscar "el" bug en vez de auditar el 100% del contenedor es la forma más común de arreglar un síntoma y dejar los otros dos intactos.
Preguntas frecuentes
¿Por qué no detectar estas tres causas con una simple comparación de números antes/después?
Porque las tres se solapaban parcialmente — una sesión podía estar excluida por dos de las tres causas a la vez. Comparar solo el total agregado no permite aislar cuánto aporta cada una; hace falta auditar la lógica de cada sistema por separado.
¿Este proceso se documentó para reutilizarse en otros contenedores?
Sí, ese era el objetivo desde el principio — el método de auditoría (trazado de dependencias antes de mover nada) se diseñó explícitamente para no depender de que cada migración futura reinvente el proceso desde cero.