¿Cuáles son los componentes de Google Tag Manager?
Google define cuatro piezas que trabajan juntas:
| Componente | Qué es | Ejemplo típico |
|---|---|---|
| Tag | Fragmento de código que se ejecuta en la página o app | Google tag de GA4, conversión de Google Ads, Floodlight |
| Trigger | Escucha eventos (carga de página, clic, envío de formulario) y decide cuándo dispara un tag | Trigger de evento personalizado purchase |
| Variable | Marcador con nombre para un valor que cambia | Precio del producto, ID de transacción, URL de página |
| Data layer | Estructura que retiene datos en el cliente para que tags, triggers y variables los consuman | dataLayer.push({event: 'purchase', value: 120}) |
La lógica es simple: el data layer expone el dato, la variable lo lee, el trigger decide el momento y el tag lo envía. Si alguna de esas cuatro piezas está mal definida, la medición se rompe aguas abajo, en Google Analytics 4 (GA4) y en las conversiones de Google Ads.
¿Conviene gtag.js o Google Tag Manager?
Es la primera decisión y casi siempre se toma por inercia. El Google tag (gtag.js) se implementa directamente en el código fuente del sitio y es una sola etiqueta que conecta con distintos productos de Google. GTM es un sistema de gestión de etiquetas que se instala una vez y desde el cual administras todo lo demás. La guía de integración entre Google tag y GTM explica qué ocurre entre el sitio, el data layer y cada destino. Google publica una comparación criterio por criterio:
| Criterio | gtag.js (despliegue por código) | Google Tag Manager (sistema de gestión) |
|---|---|---|
| Despliegue | Requiere escribir código para desplegar o modificar la recolección; permite cargar tags adicionales sobre gtag.js (Analytics, Floodlight) sin nuevas ediciones manuales | Despliegas y modificas tags de Google, de terceros y personalizados sin editar el código del sitio |
| Destinos y tags soportados | Solo productos de Google | Tags de Google, de terceros y personalizados |
| Gestión | Dentro del código del sitio; puede exigir duplicar código en distintas salidas | Interfaz web en tagmanager.google.com, para sitios y apps |
| Control de versiones | Depende de cómo gestiones tu código | Workspaces y versionado incorporado |
| Tagging server-side | Posible, pero necesitas Tag Manager para desplegar el contenedor de servidor e interactuar con él | Despliegue directo de tags en el contenedor de servidor |
| Compatibilidad | Generadores de sitios estáticos, CMS, constructores de sitios y HTML escrito a mano que soporte JavaScript | La mayoría de los CMS y constructores de sitios; si tu plataforma no lo soporta, usa gtag.js |
| Costo | Gratuito | Gratuito |
Traducido a una recomendación operativa: si tu medición se agota en productos de Google, el sitio es simple y nadie fuera de desarrollo va a tocar el tagging, gtag.js alcanza y es menos superficie que mantener. En cuanto aparecen píxeles de terceros, más de un equipo tocando la misma implementación, necesidad de revertir cambios o un horizonte de tagging server-side, GTM deja de ser una preferencia y pasa a ser la opción razonable. El costo no es un criterio de desempate: los dos son gratuitos.
Las dos rutas no son excluyentes. Lo habitual en implementaciones sanas es un contenedor de GTM que despliega el Google tag; lo que hay que evitar es tener la misma etiqueta cargada por las dos vías al mismo tiempo.
Cómo se estructura una cuenta: cuenta, contenedor, workspace
- Cuenta: normalmente una por empresa.
- Contenedor: uno por sitio o app. El contenedor web tiene un ID con formato
GTM-XXXXXXXy se instala en el<head>y en el<body>de todas las páginas. - Workspace: el espacio donde trabajas los cambios antes de publicarlos.
Cada contenedor crea un workspace por defecto. En cuentas estándar puedes agregar hasta 2 workspaces adicionales (3 en simultáneo); en cuentas de Google Tag Manager 360 la cantidad es ilimitada. Cuando un workspace se versiona o se publica, sus cambios quedan registrados en la versión y el workspace se elimina; el workspace por defecto se recrea automáticamente.
Deja tu medición lista para crecer sin romperse
Auditamos tu contenedor, ordenamos eventos y conversiones y dejamos una arquitectura que tu equipo pueda mantener.
- 1
Diagnóstico gratuito de tu stack GMP
Un especialista revisa tu implementación actual (GA4, GTM, DV360, Ads) y te dice qué priorizar primero.
- 2
Plan de acción a medida
Sales de la llamada con next steps concretos para tu cuenta, no con una plantilla genérica.
- 3
Sin compromiso, sin venta forzada
Hablas con un especialista técnico, no con un vendedor. Si no encajamos, te lo decimos.
Respuesta a la brevedad
Ordenar mi implementación de GTM
Completa el form y coordinamos una asesoría sobre tu caso.
Cargando el formulario seguro de HubSpot…
No pudimos cargar el formulario. Puedes escribirnos a hola@leadaki.com .
Este formulario lo provee HubSpot y los datos que envíes se procesan allí. Consulta nuestra política de privacidad .
Sin compromiso · Google Marketing Platform Sales Partner
Cómo implementar el data layer correctamente
El data layer es la parte que más se descuida y la que más problemas causa. Google lo describe como un objeto estructurado en formato JSON que se declara antes de que cargue el snippet de Tag Manager:
<script>
window.dataLayer = window.dataLayer || [];
</script>
<!-- Google Tag Manager snippet -->Después, cada acción relevante se empuja como evento:
dataLayer.push({
event: 'purchase',
transaction_id: 'T-10492',
value: 120,
currency: 'ARS'
});Tres reglas que Google documenta explícitamente y conviene respetar:
- El data layer no persiste entre páginas. Cada página debe volver a escribir la información que necesitan los tags.
- Decláralo antes del contenedor. Si el push ocurre después de que el tag necesita el valor, la variable llega vacía.
- Prefiere el data layer sobre el scraping del DOM. Las variables de GTM pueden leer del DOM, de cookies first-party o de variables JavaScript, pero Google recomienda el data layer porque minimiza la pérdida de datos ante cambios de código y simplifica el troubleshooting.
Un naming consistente ahorra meses de retrabajo. Si vas a nombrar campañas y eventos, define la convención antes de empezar y documéntala en algún lado accesible para todo el equipo.
Cómo se publica: versiones, entornos y aprobaciones
Cuando haces clic en Enviar, GTM te ofrece publicar y crear una versión. Una versión es una foto de la configuración del contenedor en un momento dado, lo que permite revertir a un estado anterior si algo se rompe. Los usuarios con permiso de Aprobar o superior pueden crear versiones, y cada publicación deja registro en el historial (quién publicó y cuándo).
Los clientes de Google Marketing Platform ven además una opción de Solicitar aprobación, que habilita un flujo formal de revisión antes de que un cambio llegue a producción. Si trabajas con varias agencias o equipos sobre el mismo contenedor, ese flujo deja de ser un lujo.
Antes de publicar, usa siempre el modo Vista previa para verificar que los tags disparan en el evento correcto, con los valores correctos y una sola vez.
Tag Diagnostics: el control de calidad que casi nadie mira
Vista previa te dice si el tag dispara hoy en tu navegador. Tag Diagnostics te dice cómo se está comportando el tag en producción, en todo el sitio y a lo largo del tiempo. Vive en la configuración del Google tag dentro de Google Ads y de Google Analytics, y también en Google Tag Manager, y es la herramienta que Google señala para encontrar y corregir problemas de recolección antes de que se conviertan en huecos de conversión.
Califica la calidad del tag en una escala de cinco estados:
| Estado | Qué significa |
|---|---|
| Excelente | No se detectaron problemas |
| Bueno | Funciona, con margen de mejora |
| Necesita atención | Hay problemas que degradan la calidad del dato |
| Urgente | Problema crítico con el tag |
| Sin datos recientes | El tag nunca fue detectado en tu sitio |
Cada diagnóstico viene con instrucciones específicas para resolverlo. Estos son los avisos que aparecen con más frecuencia y qué está pasando realmente detrás de cada uno:
| Aviso | Qué está pasando | Qué hacer |
|---|---|---|
| Se detectaron dominios adicionales para configurar | Hay tráfico en dominios que el tag no tiene declarados | Sumar los dominios a la configuración para no perder atribución cross-domain |
| Comando de configuración fuera de orden | El config se ejecuta después de comandos que envían datos | Reordenar el snippet: la configuración va primero |
| Algunas de tus páginas no están etiquetadas | Hay páginas del sitio sin el tag | Cerrar la cobertura; una landing sin taguear no reporta nada |
| Estás usando tags legacy de Universal Analytics | Quedaron etiquetas de una propiedad ya discontinuada | Removerlas del contenedor: no envían datos y ensucian la auditoría |
| Falta consentimiento para usuarios del EEE / falta consentimiento del EEE para personalización | No llegan señales de consentimiento del tráfico europeo | Revisar la implementación de Consent Mode v2 |
| Instalación de Consent Mode fuera de orden | El estado por defecto se declara tarde | Llamar al default antes de cualquier comando que envíe datos |
| Tag encontrado demasiado abajo en la página | El tag carga tarde y pierde eventos de usuarios que rebotan | Subirlo al <head> |
| El Google tag dejó de enviar datos | Recolectaba y dejó de hacerlo | Tratarlo como incidente: suele ser un deploy que pisó el snippet |
| Falta el Conversion Linker | No se preservan los identificadores de clic entre páginas | Agregar el tag de Conversion Linker al contenedor |
| Tasa de consentimiento del 0% detectada | El banner no está comunicando el estado de consentimiento | Verificar la integración de la CMP |
| Falta el ID de transacción en el Google tag | Sin transaction_id no hay deduplicación | Enviar el identificador de transacción en el evento de compra |
| Tus conversiones pueden estar sobrecontadas | Hay doble disparo o doble implementación | Buscar la etiqueta duplicada entre GTM y el código fuente |
La regla práctica: revisa Tag Diagnostics como parte de la rutina, no cuando sospechas que algo se rompió. Google lo plantea explícitamente como una herramienta para adelantarse a los problemas detectados, y la mayoría de estos avisos aparecen semanas antes de que el impacto se vuelva visible en el reporte de conversiones.
Buenas prácticas de implementación
- Un contenedor por propiedad digital, no uno por campaña. Multiplicar contenedores multiplica el peso en el cliente.
- Nombres descriptivos y prefijos:
GA4 - Event - purchase,Ads - Conv - Lead,Trigger - CE - purchase. Un contenedor sin convención se vuelve inauditable en seis meses. - Notas de versión reales: la descripción de la versión es tu changelog. “cambios” no sirve como descripción.
- Consentimiento primero: configura los ajustes de consentimiento de cada tag antes de sumar nuevos píxeles. Revisa cómo se implementa en la guía de Consent Mode v2.
- Limpieza periódica: los tags de proveedores que ya no usas siguen cargando y siguen enviando datos. Audita el contenedor al menos una vez por trimestre.
- Evalúa el server-side: cuando el contenedor web pasa de una decena de tags, la penalización de performance empieza a ser visible. Ahí conviene mover la distribución a un contenedor server-side. Si quieres los beneficios del contexto first-party sin operar infraestructura en Google Cloud, el Google Tag Gateway es el punto de entrada intermedio.
Errores frecuentes que vemos en auditorías
| Error | Consecuencia | Corrección |
|---|---|---|
| Duplicar el tag de GA4 en GTM y en el código fuente | Doble conteo de page_view y sesiones infladas | Dejar una sola vía de implementación |
| Triggers de “All Pages” para tags de conversión | Conversiones registradas en páginas que no convierten | Trigger de evento específico del data layer |
| Variables leídas del DOM | Se rompen con cada rediseño | Migrar a data layer |
| Publicar sin vista previa | Errores en producción sin detección | Preview obligatorio antes de cada publicación |
| Sin gestión de consentimiento | Riesgo regulatorio y pérdida de modelado | Implementar Consent Mode y ajustes por tag |
Sitewide tagging: el principio que sostiene todo lo anterior
Todo lo de arriba —elegir la herramienta, ordenar el data layer, versionar, diagnosticar— cuelga de una sola idea: el tagging tiene que cubrir el sitio entero. Google lo formula así en su material para anunciantes: asegúrate de tener tagging sitewide con el Google tag o con GTM —Ads, Analytics, Floodlight— y de que esas etiquetas estén configuradas según las buenas prácticas. Es lo que te permite capturar el dato que importa y medir de verdad la efectividad del sitio y de los anuncios.
Dos consecuencias prácticas de tomarlo en serio:
- Una infraestructura de tagging robusta es el prerequisito de todo lo demás. Enhanced conversions, Consent Mode, el modelado de conversiones y cualquier solución de medición que preserve privacidad se apoyan sobre la señal que captura el tag. Si la base tiene huecos, cada capa que agregues arriba los hereda.
- Si tienes app, el equivalente es el SDK. Para clientes con aplicaciones móviles, Google señala implementar la última versión del SDK de Google Analytics para Firebase, que es la pieza que cumple el mismo rol que el tag en la web: capturar y organizar los datos que te importan. Hay funciones de medición en iOS que directamente exigen tener el SDK al día.
No es una tarea de una sola vez. Un sitio en producción incorpora páginas, landings de campaña, subdominios y micrositios; la cobertura se degrada sola si nadie la audita. Por eso Tag Diagnostics y la revisión trimestral del contenedor no son burocracia: son lo que mantiene el principio vivo.
Próximo paso
Si quieres saber si tu contenedor está bien armado antes de sumar nuevas campañas, pasa tu implementación por la auditoría de tagging y Consent Mode y revisa el resultado en el Data Strength Score. Si prefieres que lo revise alguien con experiencia en implementaciones de LatAm, habla con un especialista de Leadaki y lo vemos sobre tu contenedor real.