Errores comunes en implementaciones de GTM que he visto repetirse
Después de años implementando Google Tag Manager en proyectos de todos los tamaños, hay errores que aparecen una y otra vez. Te cuento cuáles son y cómo evitarlos.
He implementado Google Tag Manager en webs de todos los tamaños, desde pequeños proyectos de startups hasta implementaciones enterprise con cientos de tags y decenas de personas tocando el mismo contenedor. Y hay errores que se repiten con una regularidad sorprendente independientemente del tamaño del proyecto o del perfil técnico del equipo.
No son errores de principiantes. Algunos los he cometido yo mismo. Son errores que tienen sentido en el momento en que se toman las decisiones pero que a medio plazo generan problemas de calidad del dato, de mantenimiento o de rendimiento.
1. No tener un data layer bien diseñado desde el principio
Es el error más costoso de los que aparecen en esta lista, porque es el más difícil de corregir una vez la web está en producción.
GTM puede funcionar sin data layer, usando variables automáticas, clics en elementos del DOM, visibilidad de elementos. Y muchas implementaciones empiezan así porque es más rápido. El problema es que esas variables son frágiles. Un cambio en el HTML de la web, un rediseño, un nuevo componente, un cambio de clase CSS,… puede romper decenas de tags sin que nadie se dé cuenta inmediatamente.
Un data layer bien diseñado es un contrato entre el equipo de desarrollo y el equipo de analytics. El desarrollo se compromete a publicar ciertos eventos con ciertos datos en ciertos momentos. Analytics se compromete a usar esos eventos y no a rascar datos del DOM. Cuando ese contrato existe, los cambios en el frontend no rompen el tracking.
La inversión en diseñar un buen data layer al principio se recupera muchas veces en mantenimiento evitado.
2. Publicar sin probar en modo vista previa
El modo vista previa de GTM es una de las herramientas más potentes que tiene y una de las más ignoradas.
He visto implementaciones donde los tags se publican directamente a producción sin pasar por el modo vista previa. El razonamiento suele ser “es un cambio pequeño, no puede fallar”. Y a veces no falla. Pero cuando falla, el impacto es directo: datos perdidos en producción que no se pueden recuperar.
El modo vista previa permite verificar exactamente qué tags se disparan, en qué orden, con qué datos, antes de que ningún usuario real sea afectado. No hay excusa para no usarlo en cada publicación.
Una buena práctica es además documentar el proceso de QA — qué páginas se verifican, qué eventos se comprueban, qué datos se validan. Así el proceso es reproducible y no depende de la memoria de una persona.
3. Usar el mismo contenedor para múltiples dominios sin gestionar la configuración
GTM permite usar el mismo contenedor en múltiples dominios o subdominios. Es tentador hacerlo para centralizar la gestión en un solo lugar donde ver y editar todos los tags. El problema es que los triggers y las variables suelen ser específicos de cada dominio, y mezclarlos en un solo contenedor sin una buena organización acaba generando tags que se disparan donde no deben.
La solución no es necesariamente tener un contenedor por dominio, en algunos casos tiene sentido compartirlo. Pero si se comparte hay que usar carpetas para organizar los tags por dominio, variables de tipo constant para los valores específicos de cada entorno, y triggers muy bien segmentados para que cada tag solo se dispare donde corresponde.
4. Triggers demasiado amplios
Un trigger de tipo “All Pages” para un tag que solo debería dispararse en determinadas páginas es una fuente constante de datos incorrectos.
Lo veo mucho en implementaciones de eventos de conversión, el tag de “gracias por tu compra” que se dispara en todas las páginas que contienen /gracias en la URL, incluyendo la página de “gracias por suscribirte a la newsletter” o “gracias por contactarnos”. Tres tipos de conversión completamente diferentes que acaban mezclados en el mismo evento.
Los triggers deben ser tan específicos como sea posible. Mejor un trigger que tardas diez minutos en configurar correctamente que uno genérico que contamina los datos durante meses.
5. No gestionar versiones con criterio
GTM tiene un sistema de versiones que permite ver el historial de cambios, comparar versiones y hacer rollback si algo sale mal. Es una funcionalidad muy potente que muchos equipos usan de forma deficiente.
Los problemas más habituales:
Versiones sin nombre descriptivo: “Version 47” no te dice nada cuando estás intentando encontrar cuándo se introdujo un cambio específico. Cada versión debería tener un nombre que describa qué se cambió y por qué.
Un commit por cada cambio pequeño: publicar una versión por cada tag que añades o modificas genera un historial enorme e imposible de seguir. Mejor agrupar los cambios relacionados en una sola publicación.
No hacer rollback cuando algo falla: si se detecta un problema en producción, la primera acción debería ser hacer rollback a la versión anterior mientras se investiga el problema. Muchos equipos prefieren “arreglarlo hacia adelante” publicando una corrección, lo que puede llevar más tiempo del necesario con datos incorrectos en producción.
6. Variables sin documentar
Las variables en GTM acumulan como el polvo. Empiezas con diez variables bien nombradas y después de dos años tienes ochenta variables, la mitad de las cuales nadie sabe exactamente para qué sirven ni si siguen siendo necesarias.
La documentación de variables no tiene que ser compleja, basta con una descripción clara en el campo de notas de GTM y un nombre que explique exactamente qué contiene. Variable - URL completa es mejor que Var_URL. Variable - ID de producto en página de detalle es mejor que Prod_ID.
Un audit de variables cada X meses (en mi caso me gusta cada 6 meses, 2 veces al año), revisando cuáles se usan activamente y desactivando o eliminando las que no, mantiene el contenedor manejable.
7. Disparar tags sin consentimiento
Con el GDPR y la normativa de cookies, disparar tags que recopilan datos personales sin el consentimiento del usuario no es solo un error técnico, es un problema legal.
El error más habitual es implementar el banner de cookies y el Consent Mode de Google pero no conectar correctamente el consentimiento con los tags. Los tags se disparan para todos los usuarios independientemente de si han aceptado o rechazado las cookies.
Cada tag que recopila datos personales debe tener un trigger que verifique el estado del consentimiento antes de dispararse. Y hay que verificar que eso funciona correctamente en todos los escenarios: usuario que acepta, usuario que rechaza, usuario que cierra el banner sin elegir.
8. No tener un entorno de desarrollo separado
GTM permite crear entornos. Es decir, versiones diferentes del contenedor que puedes publicar en entornos específicos. La idea es tener una versión de desarrollo donde probar los cambios antes de publicarlos a producción.
Muchos equipos no usan esta funcionalidad y hacen todos los cambios directamente en el contenedor de producción. El resultado es que cualquier error: un tag mal configurado, un trigger que no funciona como se esperaba,… afecta directamente a los datos reales.
Configurar un entorno de desarrollo tiene un coste bajo y un beneficio alto. Es especialmente importante en implementaciones grandes donde múltiples personas tocan el mismo contenedor.
9. Ignorar el rendimiento
Cada tag que añades a GTM es JavaScript que se ejecuta en el navegador del usuario. Cuantos más tags, más lenta carga la web.
No todos los tags tienen el mismo impacto, algunos son muy ligeros y otros (Google AdSense, ciertos scripts de personalización) pueden ser bastante pesados. El problema es que se añaden tags de forma acumulativa sin revisar el impacto total.
Un audit de rendimiento periódico: revisando qué tags están activos, cuánto tiempo tarda en cargar cada uno y si realmente son necesarios, puede tener un impacto significativo en el tiempo de carga de la web.
La regla general es: si un tag ya no se usa activamente, se desactiva. No se deja “por si acaso”.
10. No tener un propietario claro del contenedor
En proyectos con múltiples equipos (marketing, analytics, desarrollo, agencias externas,…) GTM acaba siendo tierra de nadie. Cada uno añade lo que necesita sin coordinación y sin responsabilidad sobre el estado general del contenedor.
El resultado predecible es un contenedor con cientos de tags, muchos desactivados o sin usar, con nombres inconsistentes, sin documentación y sin nadie que sepa exactamente qué está pasando.
Un contenedor de GTM necesita un propietario, una persona o equipo responsable de aprobar los cambios, mantener la documentación y hacer audits periódicos. No tiene que ser una persona a tiempo completo, pero sí alguien con responsabilidad clara sobre la salud del contenedor.
¿Reconoces alguno de estos errores en tu implementación actual? Si necesitas ayuda con una auditoría de GTM escríbeme.
