Qué es DebugView en Google Analytics

15/02/2026
|In Google analytics
|By Ignacio

Cuando montamos una medición en Google Analytics 4, muchas veces la sensación es: “he lanzado datos a una caja negra, a ver qué pasa mañana”. Los informes estándar pueden tardar horas en procesar la información.

Ahí entra en juego DebugView en GA4: un informe especial que nos muestra, casi en tiempo real, los eventos, parámetros y propiedades de usuario que van llegando desde un dispositivo en modo depuración. Es decir, vemos lo que está entrando ahora mismo, no el histórico procesado de mañana.

Nosotros lo usamos como una especie de “osciloscopio” de analítica:

  • Acabamos de publicar una etiqueta en GTM → abrimos DebugView → navegamos por la web → comprobamos que los eventos viven de verdad.

  • Antes de preocuparnos por atribución, muestreo o filtros, nos aseguramos de que la señal básica (evento + parámetros) es correcta.

Si algo falla aquí, da igual lo bonitos que sean los informes: la medición está coja.

DebugView vs informes en tiempo real y vs vista previa de GTM

Aquí es donde muchos marketers se lían, así que lo separamos bien:

  • Vista previa de Google Tag Manager

    • Depura etiquetas del contenedor (GA4, Google Ads, pixel de Facebook, etc.).

    • Te dice si un tag se dispara o no, con qué triggers.

  • DebugView en GA4

    • Depura los datos que han llegado a tu propiedad de GA4.

    • No le importa el contenedor, solo el resultado final: evento + parámetros que entran.

  • Informe en tiempo real de GA4

    • Sirve para ver actividad agregada de todos los usuarios (campañas en marcha, picos de tráfico…).

    • No es práctico para validar una implementación concreta.

Dicho de forma simple:

GTM Preview = “¿se dispara la etiqueta?”
DebugView = “¿ha llegado bien el evento a GA4?”
Tiempo real = “¿qué está pasando ahora mismo en mi sitio en general?”

Cuándo abrir DebugView: implementaciones, migraciones y auditorías rápidas

En nuestro día a día lo abrimos casi siempre en estos casos:

  • Implementaciones y migraciones

    • Nuevas propiedades GA4.

    • Migraciones desde UA.

    • Integraciones con Shopify Shopify, WordPress/WooCommerce.

    • Ajustes en apps o medición server-side.

  • Validar eventos clave

    • page_view, user_engagement.

    • Conversiones como generate_lead, add_to_cart, begin_checkout, purchase.

  • Auditorías exprés para pymes

    • Ver si hay eventos fantasmas, duplicados o naming raro.

    • Confirmar que no se han roto cosas tras un rediseño o cambio de theme.

Nuestro enfoque es sencillo: si vamos a tomar decisiones con esos datos, antes pasan por DebugView.

Dónde está DebugView en GA4 y cómo activarlo paso a paso

DebugView vive dentro de tu propiedad GA4. Para encontrar la vista de depuración:

  1. Entra en tu cuenta de GA4.

  2. Ve a Admin.

  3. En la sección de configuración de datos (Data display), haz clic en DebugView.

Si no haces nada más, seguramente verás la pantalla vacía: DebugView solo muestra eventos marcados en modo debug. Vamos a ver cómo activar ese modo.

Activar DebugView con el modo vista previa de Google Tag Manager

Si tienes GA4 montado con Google Tag Manager:

  1. Entra en tu contenedor de GTM.

  2. Haz clic en Vista previa.

  3. Introduce la URL de la web y conéctate con Tag Assistant.

  4. Abre otra pestaña con GA4 → DebugView.

  5. Navega normalmente por la web.

Cuando GTM está en vista previa, añade parámetros especiales a las peticiones de GA4 para indicar que ese dispositivo está en modo depuración. GA4 lo detecta y tus eventos empiezan a aparecer en DebugView asociados a ese dispositivo.

Nos gusta este método porque:

  • Depuramos etiquetas en GTM y eventos en GA4 DebugView a la vez.

  • No hace falta instalar nada en el navegador del cliente.

Activar DebugView con la extensión Google Analytics Debugger

Si no tienes acceso a GTM o estás revisando una web de terceros:

  1. Instala la extensión Google Analytics Debugger en Chrome.

  2. Actívala en la web que quieres probar.

  3. Abre GA4 → DebugView.

  4. Actualiza la web y navega.

La extensión añade un parámetro especial (por ejemplo _dbg) a las peticiones de GA4 para indicar que “esto es debug”.

Ventajas:

  • Ideal para revisar implementaciones donde no tenemos GTM.

  • Muy útil para formaciones: cada alumno activa la extensión y vemos sus eventos por separado.

Cómo leer la interfaz de DebugView sin volverse loco

La primera vez que se abre DebugView suele imponer: puntos, columnas, iconos… Vamos por partes.

Flujo de minutos y flujo de segundos: qué significa cada cosa

En la interfaz verás algo así:

  • Columna de la izquierda (Minutes stream)

    • Resumen de lo que ha pasado en los últimos 30 minutos.

    • Cada burbuja representa un minuto con actividad.

  • Columna central (Seconds stream)

    • Eventos de los últimos 60 segundos, en orden cronológico.

    • Cada evento es clicable para ver detalles.

  • Columna derecha

    • Top events de los últimos 30 minutos.

    • User properties (propiedades de usuario activas para ese dispositivo).

Cuando estamos validando un funnel, nos fijamos sobre todo en la columna central: queremos ver la secuencia de eventos tal como el usuario navega.

Eventos, conversiones y propiedades de usuario

Al hacer clic en un evento dentro del flujo de segundos, DebugView muestra:

  • Nombre del evento (por ejemplo purchase).

  • Lista de parámetros (por ejemplo value, currency, items, transaction_id…).

  • Qué eventos se han marcado como conversiones.

  • Propiedades de usuario vigentes en ese momento (user_properties).

Aquí es donde solemos detectar:

  • Parámetros que faltan.

  • Tipos incorrectos (texto en vez de número, formatos de moneda raros, etc.).

  • items[] de eCommerce incompletos o mal formados, según la especificación de eventos de GA4.

3.3. Seleccionar bien el dispositivo de depuración

Arriba verás un selector de dispositivo:

  • Cada “dispositivo” representa un navegador/equipo donde hay debug activo.

  • A veces aparece el nombre del modelo (por ejemplo, móvil Android) o el del navegador.

Problemas típicos que nos encontramos:

  • Estamos depurando y… estamos mirando otro dispositivo en DebugView.

  • Varios miembros del equipo están probando a la vez y mezclamos señales.

Nuestra recomendación:

  • Para pymes y marketers junior, hacer pruebas de uno en uno.

  • Acordar un nombre de dispositivo claro cuando se pueda (por ejemplo, usar siempre el mismo navegador).

Casos prácticos: usar DebugView para validar tu medición

Comprobar page_view, user_engagement y eventos clave de conversión

En una implementación básica, lo primero que revisamos es:

  1. Que page_view aparece cuando cargamos cada página clave.

  2. Que user_engagement se registra durante las sesiones normales.

  3. Que los eventos de conversión importantes (generate_lead, purchase, etc.) se disparan una sola vez en el momento correcto.

Nuestra forma de trabajar:

  • Abrimos DebugView.

  • Navegamos por el sitio como lo haría un usuario real.

  • Simulamos el funnel completo (por ejemplo: land → producto → checkout → gracias).

  • Comprobamos que la secuencia de eventos en el flujo de segundos tiene sentido y no hay duplicidades.

Antes de dar una implementación por buena con un cliente, siempre hacemos al menos una pasada completa de funnel viéndolo en DebugView.

Revisar parámetros de eCommerce: value, currency, items[], transaction_id

En eCommerce, DebugView se convierte en nuestro mejor amigo:

  • Para cada purchase validamos:

    • value correcto (importe total).

    • currency con el formato esperado (por ejemplo EUR).

    • transaction_id único.

  • Dentro del parámetro items[], revisamos que cada producto incluya los campos obligatorios:

    • item_id o item_name.

    • price.

    • quantity.

    • Y cualquier parámetro adicional que usemos para informes (categoría, marca…).

En la práctica, hemos visto de todo:

  • value enviado como texto "39,99" en lugar de número 39.99.

  • items[] montado sin campo item_id.

  • transaction_id siempre igual.

Todo eso, en DebugView, salta a la vista si te acostumbras a revisar los parámetros.

4.3. DebugView para Consent Mode, CMP y medición mejorada

Cuando entran en juego el Consent Mode y las CMP (banners de cookies), DebugView nos ayuda a ver si estamos realmente recogiendo algo:

  • Si un usuario deniega el consentimiento, es posible que no veamos eventos en DebugView o que llegue información limitada.

  • Para usuarios que aceptan, comprobamos que los eventos fluyen con normalidad.

También lo usamos para entender la medición mejorada (Enhanced Measurement):

  • Vemos qué eventos automáticos está generando GA4 (scroll, file_download, outbound_click…).

  • Decidimos si nos interesa mantenerlos o si nos están “ensuciando” el modelo de datos.

En más de una auditoría hemos descubierto que una pyme tenía el tráfico lleno de eventos automáticos irrelevantes, mientras le faltaban las conversiones importantes. DebugView nos permite detectar ese desequilibrio muy rápido.

Problemas típicos con DebugView

El evento no llega a DebugView: checklist rápido

Clásico escenario: en GTM Preview ves que la etiqueta se dispara… pero en DebugView no aparece nada.

Cosas que comprobamos, casi en orden:

  1. ¿Estamos mirando la propiedad y el data stream correctos?

  2. ¿Está realmente activado el modo debug?

    • Vista previa de GTM funcionando.

    • Extensión GA Debugger encendida.

    • Parámetro debug_mode presente.

  3. ¿Hay algún adblocker / extensión de privacidad bloqueando GA4?

  4. ¿Estamos en modo incógnito con extensiones activas?

  5. ¿La CMP ha bloqueado completamente Analytics por falta de consentimiento?

  6. ¿Se ha configurado algún filtro de tráfico interno que está excluyendo nuestro dispositivo?

Hasta que no pasamos estos puntos, no empezamos a tocar etiquetas.

5.2. El evento llega, pero llega mal: parámetros, tipos y atribución

Segundo gran bloque de problemas: el evento se ve en DebugView, pero los datos no son útiles.

Casos reales que nos encontramos a menudo:

  • Parámetros mal nombrados:

    • transactionId en lugar de transaction_id.

    • productID en lugar de item_id.

  • Tipos incorrectos:

    • value como texto en vez de número.

    • Números con coma decimal en vez de punto.

  • items[] mal formateado:

    • Falta de campos obligatorios.

    • Estructura de array incorrecta respecto a la documentación de eventos de GA4.

  • Problemas de UTMs y redirecciones:

    • Vemos el evento en DebugView, pero luego el tráfico aparece como (direct) en los informes por redirecciones intermedias o UTMs mal ubicadas.

Nuestra receta aquí es simple:

  1. Abrir el evento en DebugView.

  2. Comparar los parámetros uno a uno con la documentación oficial del evento que queremos usar.

  3. Arreglar naming, tipos y estructura antes de seguir.

5.3. Eventos duplicados, fantasmas y naming inconsistente

Este es el tipo de problema que las pymes conocen bien: “los números no me cuadran”.

Culpables típicos:

  • Doble etiquetado:

    • gtag + GTM a la vez.

    • Código de GA4 pegado en el theme y etiquetas de GA4 en GTM.

  • Eventos que se disparan en varias páginas por culpa de scripts globales.

  • Diferentes nombres para el mismo evento según la plantilla o el desarrollador (lead, generate_lead, form_submit…).

En DebugView es relativamente fácil ver:

  • Que un mismo evento se dispara dos veces en una misma acción.

  • Que tenemos dos nombres distintos para lo que en negocio es la misma conversión.

Antes de pasar a informes y modelos de atribución, nos gusta dejar limpio el inventario de eventos a base de:

  • Unificar nombres.

  • Quitar disparos duplicados.

  • Documentar qué mide cada evento.

Checklist antes de dar una implementación por buena

6.1. Checklist rápido

Cuando trabajamos con marketers junior o pymes en España, les dejamos algo parecido a este mini-checklist para la vista de depuración de GA4:

  1. ¿Ves tu dispositivo en DebugView?

  2. Para las páginas clave, ¿aparece page_view solo una vez por carga?

  3. ¿Ves tus eventos de conversión cuando completas el funnel (lead, compra, etc.)?

  4. En cada evento clave, ¿los parámetros importantes están presentes y con el tipo correcto?

  5. ¿Las compras tienen value, currency, transaction_id y items[] completo?

  6. Si tienes CMP, ¿con consentimiento denegado desaparecen los eventos (lo esperable)?

  7. ¿No ves duplicidades ni eventos “raros” que no reconozcas?

Con esto cubierto, ya podemos pasar a:

  • Realtime.

  • Informes estándar.

  • Exploraciones.

Errores que hemos cometido

En nuestro trabajo con DebugView en GA4 nos han pasado cosas como:

  • Estar 20 minutos buscando un bug… y resultó que mirábamos otra propiedad distinta a la que estaba etiquetada.

  • Depurar una compra que “no llegaba” y descubrir que el transaction_id estaba llegando vacío, así que el cliente no podía cruzarlo con su ERP.

  • Ver eventos perfectos en consola del navegador, pero vacíos en DebugView porque un banner de consentimiento bloqueaba GA4 en producción.

Por eso ahora:

  • Siempre revisamos primero propiedad + data stream + dispositivo.

  • Validamos la estructura de parámetros en DebugView antes de mirar informes.

  • Integramos la vista de depuración como paso obligatorio de cualquier checklist de implementación.

Preguntas frecuentes sobre DebugView

¿Qué es exactamente DebugView en Google Analytics 4 y para qué sirve?
Es un informe especial de GA4 que muestra, casi en tiempo real, los eventos que llegan desde dispositivos en modo depuración, con sus parámetros y propiedades de usuario. Sirve para validar implementaciones antes de confiar en los informes estándar.

¿DebugView es lo mismo que el informe en tiempo real?

No. El informe en tiempo real muestra actividad agregada de todos los usuarios; DebugView se centra en un dispositivo concreto en modo debug y detalla evento por evento, incluyendo parámetros y user properties.

¿Por qué mis eventos se ven en GTM Preview pero no en DebugView?

Normalmente es por una de estas razones:

  • No se ha activado correctamente el modo debug (vista previa, extensión o debug_mode).

  • Estás mirando otra propiedad o data stream.

  • Un adblocker o la CMP está bloqueando las peticiones de GA4.

¿Cuánto tarda DebugView en mostrar los eventos?
En condiciones normales es casi inmediato, porque los eventos de debug se envían con muy poco retraso. Aun así, puede haber unos segundos de diferencia entre el disparo y la aparición en la columna de segundos.

¿DebugView funciona con Consent Mode activado?
Sí, pero si el usuario deniega el consentimiento, es posible que los eventos no se envíen o lleguen de forma limitada y no aparezcan como esperas. DebugView respeta los mismos controles de privacidad que el resto de GA4.

¿Puedo usar DebugView para comprobar implementaciones de eCommerce?
Totalmente. De hecho, es una de las mejores formas de validar que purchase, add_to_cart, begin_checkout y sus parámetros (items[], value, currency, etc.) llegan bien y con la estructura que recomienda la documentación de GA4.

Conclusión

Antes de culpar a un informe, siempre comprobar en la vista de depuración que los eventos, parámetros y user properties están llegando bien y recorremos el embudo completo con DebugView abierto antes de dar por buena una implementación, una migración o la medición de un eCommerce.

Si trabajas con GA4, merece la pena incorporar DebugView a tu checklist estándar y dedicar un rato a entender su interfaz. No damos nada por cerrado hasta ver los eventos correctos, con los parámetros correctos, entrar en tiempo real. A partir de ahí, los informes dejan de ser una caja negra y pasan a ser algo que realmente controlamos.

Privacy Preference Center

Privacy Preferences