"En el Preview de GTM la tag se dispara perfectamente, pero en el sitio en vivo no se registra nada." Si usas Tag Manager, este es el patrón más común —y más confuso— de todos. Un Preview en verde (disparado) te hace sentir que la configuración es correcta, pero el sitio en vivo no muestra números después de publicar. Y si no puedes ver en qué se diferencian el Preview y la producción, terminas ajustando configuraciones sin parar.
¿Te suena familiar alguno de estos casos?
- El Preview de GTM muestra que se dispara, pero producción no registra nada
- Creías haber publicado (Submit), pero el cambio no está en vivo
- Solo páginas o botones específicos fallan al disparar la tag
- En DevTools, la solicitud de medición ni siquiera se está enviando
- Los eventos nunca llegan a GA4 o Google Ads
Esta guía organiza qué revisar y en qué orden cuando GTM no está registrando datos, dividiéndolo en seis causas comunes. Antes de reconstruir tags y triggers al azar, revísalas de arriba hacia abajo.
Principio básico: "funciona en Preview" y "funciona en producción" son cosas distintas
La mayor razón por la que el diagnóstico falla es tratar un Preview en verde (disparado) como prueba de que funciona en producción. El Preview de GTM carga tu versión sin publicar, en progreso en tu propio navegador y la ejecuta. Así que incluso cuando el Preview se dispara, ese cambio no necesariamente se está sirviendo a los visitantes reales.
Primero, aclara qué estado estás viendo realmente.
| Estado | De quién son los contenidos que ves | ¿Se registra? |
|---|---|---|
| Preview (Tag Assistant) | La versión de trabajo sin publicar | Solo tu navegador |
| Publicado (después de Submit) | La versión publicada del container | Todos los visitantes |
| Ediciones sin publicar | El borrador del workspace | No se sirve a nadie |
El punto clave: "se dispara en Preview" no equivale a "se registra en producción." Las causas 1 a 6 a continuación están ordenadas de la más común a la más fácil de aislar, siguiendo exactamente esta diferencia.
Causa 1: No publicaste (Submit) el cambio
Esta es la más común y la más pasada por alto. En GTM, crear y guardar una tag o un trigger no lo pone en vivo automáticamente. Pasa a producción solo cuando presionas "Submit" en la esquina superior derecha y publicas una nueva versión. El Preview ejecuta el borrador de tu workspace, por lo que se dispara sin necesidad de publicar —justo por eso ocurre lo de "funciona en Preview pero no en producción."
Cómo verificarlo: abre la pantalla "Versions" en la esquina superior derecha de GTM y confirma si tu último cambio está incluido en la "versión publicada." Si la marca de tiempo de la versión "Published..." es anterior a tus ediciones, aún no has publicado.
Error común: la gran mayoría de los casos de "verde en Preview pero cero en producción" corresponde a esta Causa 1. No te quedes solo con un Preview que se dispara; primero confirma que presionaste Submit y que el cambio está en la versión publicada. Consulta también Cuando una conversión se dispara pero no se registra.
Causa 2: Las condiciones del trigger no coinciden con la situación real de producción
Si una tag se dispara o no lo decide su trigger. Si esas condiciones difieren aunque sea un poco de la página real, no se disparará en producción.
- Desajuste de condición de URL: configuraste "Page URL contiene
/thanks," pero la página de confirmación real es ligeramente distinta:/complete,/thank-you/, una barra final, o un query string (?id=...) - Desajuste del elemento de clic: la clase o el ID del botón es diferente en producción, o en una SPA (un sitio que no recarga entre pantallas) el elemento de clic se reemplaza dinámicamente
- Triggers de envío de formulario: dependiendo de la implementación, el envío estándar del formulario no se detecta, así que no se dispara
Cómo verificarlo: en el Preview (Tag Assistant), revisa si el trigger aparece como "Fired" o "Not Fired" cuando realizas la acción. Si aparece "Not Fired," concilia las condiciones del trigger con los valores reales (URL, elemento de clic).
Error común: cuando "solo una página específica no se registra," sospecha primero de la condición de URL del trigger. Copia la URL real y compárala carácter por carácter con la condición para estar seguro.
Causa 3: Versión publicada o container ID (GTM-XXXX) equivocado
Algo sorprendentemente frecuente: el lugar que estás viendo es distinto del que está en vivo.
- Confusión de container ID: producción tiene incrustado
GTM-AAAA, pero tú estás editandoGTM-BBBB(un container de prueba, de otro sitio, o uno reconstruido) —por más que configures, nada aparecerá en producción - Código antiguo o instalación duplicada: queda código viejo de GTM en el sitio, o hay múltiples GTM instalados por duplicado y se está ejecutando el que no pretendías
Cómo verificarlo: abre DevTools en la página en vivo, busca en el código fuente IDs que empiecen con GTM-, y confirma que coincida con el container ID que estás editando. También revisa si aparece más de un GTM- (instalación duplicada).
Error común: la agencia y el equipo de marketing instalan cada uno un GTM distinto, y "lo configuré pero no aparece nada" se arrastra durante semanas. Primero confirma el container ID real presente en el HTML en vivo.
Causa 4: La tag está "pausada" o desconectada
A veces la tag misma está detenida.
- La tag está configurada en "Pause"
- La tag no tiene ningún trigger asociado (sin condición de disparo, nunca podrá dispararse)
- Una tag de la que depende (una tag de configuración/inicialización) no se está disparando
Cómo verificarlo: en la lista de tags de GTM, confirma que la tag objetivo no tenga el ícono de pausa y que su campo de trigger no esté vacío.
Error común: no es raro pausar una tag para hacer pruebas, publicar mientras sigue pausada, y dejarla detenida así. Revisa el estado de tus tags en la lista antes de publicar.
Causa 5: Está siendo bloqueada por la configuración de consentimiento
La señal de medición puede detenerse justo antes de enviarse. Con el modo de consentimiento (consent mode) de GTM o una integración con un banner de consentimiento de cookies, el disparo de la tag puede quedar retenido o bloqueado mientras el usuario no haya dado su consentimiento.
- Antes de que el banner otorgue permiso, la tag de medición espera o no se dispara
- La medición se restringe para usuarios que eligieron "solo cookies esenciales"
Cómo verificarlo: revisa el estado de consentimiento en el Preview y observa si el disparo cambia antes y después del consentimiento. En producción, confirma que la medición funcione una vez que realmente otorgas el permiso en el banner.
Error común: si "funciona en Preview (tratado como con consentimiento) pero no para los visitantes reales," la configuración de consentimiento puede estar bloqueándolo. Es fácil olvidar que tú, en el Preview, cuentas como que diste consentimiento, mientras que muchos visitantes reales no lo han hecho.
Causa 6: Las variables (data layer) están vacías
Aunque una tag se dispare, si el payload está vacío, la medición puede no completarse o los valores pueden llegar incorrectos. GTM lee montos, IDs de pedido, nombres de evento y demás desde un mecanismo de traspaso llamado data layer. Si eso no está poblado en producción, la tag se dispara pero envía "sin valor."
- La tag se dispara antes de que el sitio escriba los valores en el data layer (un desajuste de tiempos)
- El nombre de la variable está escrito de forma distinta en el sitio y en GTM
- En Preview un desarrollador colocó los valores manualmente, mientras que en producción no están poblados
Cómo verificarlo: en las pestañas "Variables" y "Data Layer" del Preview, confirma que la variable objetivo tenga el valor esperado en el momento del disparo. Si está vacía o undefined, revisa el momento en que el sitio escribe los valores y el nombre de la variable.
Error común: que el monto de compra de un e-commerce llegue como "0" o vacío casi siempre se debe a este desajuste de tiempos del data layer o a un nombre de variable incorrecto. Cruzar esto con la verificación de la tag de GA4 y la verificación de una conversión de Google Ads facilita aislar el problema.
Un detalle que suele pasarse por alto: los triggers de bloqueo detienen el disparo en silencio
Aunque todas las condiciones del trigger de disparo de una tag se cumplan, GTM tiene una función llamada triggers de bloqueo (blocking triggers o exception triggers) que puede impedir el disparo de la tag sin ninguna advertencia. Si alguien agregó un trigger de bloqueo —por ejemplo, para excluir tráfico interno o páginas específicas— y sus condiciones coinciden, la tag no se disparará sin importar el trigger de disparo.
Cómo verificarlo: Abre la tag en GTM, desplázate más allá de los triggers de disparo, y busca si hay algún trigger de bloqueo listado debajo de ellos. En el Preview, una tag que muestra "Not Fired" a pesar de que todas las condiciones del trigger están en verde suele tener un trigger de bloqueo anulándola.
Error común: los triggers de bloqueo son visualmente menos destacados que los de disparo y es fácil olvidarlos. Si una tag misteriosamente no se dispara aunque las condiciones del trigger parezcan correctas, revisa si hay triggers de bloqueo antes de reconstruir la tag. Esta también es una causa común cuando las conversiones se disparan pero no se registran.
El orden para verificar si GTM es la causa
Revisar de arriba hacia abajo te lleva a la causa más rápido.
- En la pestaña "Network" de DevTools, ¿se está enviando la solicitud de medición? (Si no, es un problema de disparo = Causas 1–4)
- En el Preview (Tag Assistant), ¿el trigger objetivo aparece como Fired y las variables tienen valores?
- En la pantalla Versions de GTM, ¿tu último cambio está en la versión publicada?
- ¿El container ID (GTM-XXXX) en el HTML en vivo coincide con el que estás editando?
- Con el permiso otorgado en el banner de consentimiento, ¿se dispara y registra también en producción?
Lo que revisar en tu propia máquina no puede decirte
Revisar las Causas 1 a 6 es útil, pero hacer un solo Preview en tu propia máquina tiene dos limitaciones estructurales.
- Tu entorno no es el entorno de tus visitantes. El Preview carga una versión sin publicar en tu navegador, y tu estado de consentimiento, tu sesión, tus extensiones y tu caché difieren de los de los visitantes reales. Puede dispararse en tu máquina y aun así faltar bajo las condiciones reales de los visitantes (sin consentimiento, otro navegador, una ruta de navegación de SPA distinta).
- Las conversiones que involucran un clic en un anuncio son difíciles de verificar. Para ver correctamente "si de verdad se registra a través de un anuncio," necesitarías hacer clic en un anuncio real para recrear la ruta —lo cual conlleva el riesgo de una violación de las políticas de publicidad por ser un autoclic.
Concluir "se dispara en Preview, así que está bien" tiende a pasar por alto el problema de que los datos se pierdan en la ruta real que siguen tus visitantes.
Bloqueadores de anuncios y herramientas de privacidad: un punto ciego exclusivo de producción
Una proporción creciente de visitantes usa bloqueadores de anuncios, navegadores centrados en la privacidad, o extensiones anti-tracking que bloquean GTM o las solicitudes de medición que envía. Esto crea una brecha invisible en tus propias pruebas si tú no usas esas herramientas.
- Extensiones de navegador como uBlock Origin o Privacy Badger pueden bloquear por completo el script de
googletagmanager.com, de modo que GTM nunca se carga - Navegadores centrados en la privacidad (Brave, Firefox con Enhanced Tracking Protection) pueden bloquear las solicitudes salientes hacia
google-analytics.comogoogleads.g.doubleclick.net - Los firewalls corporativos o bloqueadores a nivel de DNS pueden eliminar las solicitudes de tracking antes de que salgan de la red
Qué significa esto en la práctica: no verás esos hits bloqueados en GA4 ni en Google Ads —simplemente desaparecen. No existe una solución del lado de GTM para los usuarios que bloquean activamente el tracking, pero entender esta brecha evita que persigas un problema de configuración que en realidad no existe. Para más sobre cómo las herramientas de privacidad afectan la medición, consulta bloqueadores de anuncios y bloqueo de píxeles y pérdida de conversiones por Safari ITP.
Consejo: si tus cifras totales de conversión son más bajas de lo esperado pero la configuración ya se confirmó correcta a través de las Causas 1–6, el uso de bloqueadores de anuncios entre tu audiencia puede explicar parte de esa diferencia. GTM del lado del servidor (server-side) puede recuperar parte de esos datos perdidos al enrutar las solicitudes de medición a través de tu propio dominio.
Descarta retrasos en los reportes antes de reconstruir
Después de confirmar que las tags se disparan correctamente, no te alarmes si los números no aparecen de inmediato en GA4 o Google Ads. Los retrasos en los reportes son normales y pueden hacerte pensar erróneamente que el tracking está roto.
- Reporte en tiempo real de GA4: los eventos suelen aparecer en cuestión de segundos a minutos, pero los reportes estándar pueden tardar entre 24 y 48 horas en procesarse por completo
- Conversiones de Google Ads: las acciones de conversión nuevas pueden tardar hasta 24 horas en empezar a aparecer, y la ventana del reporte atribuye las conversiones a la fecha del clic en el anuncio, no a la fecha de la conversión
- Conversion linker: si la tag de conversion linker de Google Ads no se está disparando, las conversiones pueden registrarse pero no atribuirse a la campaña correcta; consulta GCLID e IDs de clic para más detalles
Cómo verificarlo: usa el reporte Realtime de GA4 (Reports > Realtime) para confirmar que los eventos llegan pocos minutos después de tu prueba. En Google Ads, revisa la marca de tiempo "Último registro" de la acción de conversión en Tools > Conversions. Si la marca de tiempo es reciente, el tracking funciona; los reportes estándar simplemente aún no se han puesto al día.
Checklist de verificación
- Publicaste (Submit), y el último cambio está en la versión publicada
- Las condiciones del trigger (URL, elemento de clic) coinciden con los valores reales de producción
- El container ID (GTM-XXXX) en el HTML en vivo coincide con el container que estás editando
- La tag objetivo no está pausada, y tiene un trigger asociado
- Con el permiso otorgado en el banner de consentimiento, se dispara y registra en producción
- En el momento del disparo, el data layer (variables) tiene los valores esperados
- En "Network" de DevTools, la solicitud de medición de producción realmente se envía
Para más información, consulta también el checklist de verificación de conversion tracking.
Preguntas frecuentes
P. Se dispara en el Preview de GTM pero no se registra en producción. R. Lo más común es que no hayas publicado (Submit) el cambio (Causa 1). El Preview muestra la versión sin publicar, así que se dispara sin necesidad de publicar. Después, sospecha de un container ID en producción distinto del que estás editando (Causa 3), o de la configuración de consentimiento bloqueándolo (Causa 5).
P. Solo páginas o botones específicos fallan al disparar la tag. R. Un desajuste en las condiciones del trigger (Causa 2) es el principal sospechoso. Revisa si la barra final o el query string de la URL en vivo, o la clase/ID del botón, realmente coinciden con las condiciones del trigger; concilia esto observando Fired/Not Fired en el Preview.
P. La tag se dispara, pero los montos e IDs de pedido llegan vacíos. R. Es probable que las variables (data layer) estén vacías (Causa 6). Revisa en qué momento el sitio escribe los valores en el data layer, y la ortografía del nombre de la variable. Leer los valores en el momento del disparo en las pestañas "Variables" y "Data Layer" del Preview es la forma confiable de hacerlo.
P. Creía haberlo configurado; ¿dónde reviso si está publicado? R. En la pantalla "Versions" de GTM, en la esquina superior derecha, confirma que tu último cambio esté incluido en la "versión publicada." Si la marca de tiempo de la versión publicada es anterior a tus ediciones, aún no has publicado (Submit).
P. ¿Cómo confirmo que el container ID es el correcto?
R. Abre la página en vivo, busca GTM- en el código fuente con DevTools, y verifica si el ID que aparece coincide con el container ID que estás editando. Si aparecen varios GTM-, es posible que tengas una instalación duplicada.
Conclusión: confirma que publicaste y luego verifica en la ruta real
"GTM no registra datos" casi siempre se reduce a una de estas: ① no publicado (olvidaste el Submit), ② un desajuste en las condiciones del trigger, ③ el container ID equivocado, ④ una tag pausada, ⑤ bloqueo por configuración de consentimiento, o ⑥ un data layer vacío. No te relajes al ver un Preview en verde; aísla el problema de arriba hacia abajo y llegarás a la causa sin reconstruir tags al azar.
Pero las verificaciones de Preview en tu propia máquina tienen límites. Ir más allá —confirmar que los datos realmente se registran, en la ruta real que siguen tus visitantes, en producción— es lo que de verdad significa "estar registrando datos."
ConversionOK ejecuta tu página en vivo en un navegador independiente y aislado, e intercepta las solicitudes de medición de tags realmente enviadas, para luego verificarlas —sin necesidad de hacer clic en tu propio anuncio y sin interferencia de tu entorno de oficina. Empieza con una verificación estática gratuita para confirmar el punto de entrada de tu medición.