Tienes GA4 instalado. Los eventos aparecen en el panel. Todo parece funcionar. Pero hay algo que nadie te dice cuando activas los eventos mejorados con un solo clic: que la configuración por defecto de casi todos ellos está pensada para que los datos parezcan correctos, no para que lo sean.
Este artículo no explica qué son los eventos en Google Analytics 4. Para eso ya hay cien guías. Lo que vas a encontrar aquí son los fallos concretos de implementación que generan datos distorsionados, las decisiones equivocadas que provocan y cómo corregirlos sin reinventar la rueda.
Por qué los eventos de GA4 fallan aunque «estén activos»
Un evento activo en GA4 no es un evento bien configurado. La diferencia es enorme. GA4 dispara muchos eventos de forma automática (los llamados eventos de recogida automática y los eventos mejorados), pero su lógica interna parte de supuestos genéricos que rara vez se ajustan a tu sitio. El resultado: datos que técnicamente existen pero que miden algo diferente a lo que crees que están midiendo.
El problema no suele estar en el código. Está en los umbrales, en las condiciones de disparo y en la ausencia de parámetros que den contexto real a cada interacción.
Scroll: el evento que engaña a todo el mundo
El evento scroll de GA4 se dispara cuando el usuario llega al 90% de la página. Solo al 90%. Esto significa que si alguien lee el 80% de un artículo largo y se va, GA4 no registra ningún scroll. Cero. Como si no hubiera abierto la página.
El error de interpretación más típico es usar este dato para medir «engagement» o «interés» en el contenido. Con un único umbral al 90%, lo que mides es si el usuario llegó casi al final, no si el contenido le mantuvo. En páginas largas con mucho contenido valioso en el primer tercio, este evento es casi inútil como indicador de consumo.
¿La solución? Implementar umbrales múltiples (25%, 50%, 75%, 90%) a través de GTM con un activador de profundidad de desplazamiento. No es complejo, pero requiere salir del panel de GA4 y ponerse manos a la obra con Google Tag Manager.
File_download: registra más de lo que parece
El evento file_download se activa automáticamente cuando alguien hace clic en un enlace que apunta a una extensión reconocida como descargable (pdf, xlsx, docx, zip, entre otras). Hasta ahí, bien. El problema viene cuando tu sitio tiene enlaces a documentos externos, recursos de terceros o archivos de sistema que no tienen nada que ver con una descarga deliberada del usuario.
GA4 los cuenta todos por igual. Si tienes un enlace a un PDF de condiciones de uso de un proveedor, ese clic aparece como descarga igual que el catálogo de producto que diseñaste para generar leads. Los datos de conversión se inflan. Y lo peor es que nadie lo nota hasta que alguien se sienta a revisar los datos con calma.
Aquí el truco está en filtrar por el parámetro link_url que acompaña al evento y crear segmentos o conversiones solo sobre los dominios o rutas que te interesan de verdad.
El evento purchase: donde se pierden los ingresos reales
Este es el más crítico de todos, especialmente en ecommerce. El evento purchase en GA4 requiere que envíes el parámetro value con el valor de la transacción. Suena obvio. Pero hay tres fallos que aparecen constantemente en implementaciones reales:
- Value sin IVA vs. con IVA. Algunas plataformas envían el valor bruto, otras el neto. Si no lo revisas, tus ingresos en GA4 y los de tu sistema de facturación nunca van a cuadrar.
- Duplicación de eventos. Si tienes el evento de compra disparado tanto desde GTM como desde el pixel nativo de tu plataforma (Shopify, WooCommerce, PrestaShop), GA4 puede estar contando cada venta dos veces. El informe de ingresos puede estar multiplicado por dos y nadie se da cuenta hasta que llega la revisión contable.
- Ausencia del parámetro transaction_id. Sin este parámetro, GA4 no puede deduplicar compras. Si un usuario recarga la página de confirmación, esa venta se registra de nuevo. Y otra vez. Y otra.
El transaction_id único por pedido es la primera línea de defensa contra el recuento inflado de ingresos. Si tu implementación no lo incluye, estás midiendo mal.
Video engagement: solo funciona si el vídeo es de YouTube
El seguimiento automático de vídeo en GA4 (video_start, video_progress, video_complete) funciona de fábrica únicamente con reproductores de YouTube embebidos con la API de YouTube activada. Si usas Vimeo, un reproductor nativo de HTML5 o cualquier otro sistema, estos eventos simplemente no se disparan.
Muchos equipos asumen que tienen cobertura de vídeo total porque ven datos en el panel, cuando en realidad solo están midiendo una parte del contenido audiovisual de su sitio. El resto, invisible.
Para reproductores no nativos de YouTube necesitas implementación manual vía GTM, con activadores personalizados según la API de cada plataforma.
Session_start y el problema de las sesiones infladas
GA4 genera un evento session_start cada vez que se inicia una nueva sesión. Esto incluye el tráfico de bots, crawlers y herramientas de monitorización que no has filtrado correctamente. En propiedades sin filtro de tráfico interno ni exclusión de IPs de oficina, entre el 5% y el 15% de las sesiones pueden ser tráfico no real, dependiendo del sector.
GA4 tiene un filtro de tráfico interno en Administración → Flujos de datos → Configurar ajustes de etiqueta. Está ahí. Pero muchas implementaciones lo tienen vacío.
Además, GA4 define una sesión como inactiva tras 30 minutos sin actividad. Si un usuario deja el navegador abierto y vuelve 31 minutos después, eso cuenta como sesión nueva. En ecommerce con procesos de compra largos o en B2B con contenidos que se leen despacio, esto infla artificialmente el número de sesiones y reduce el tiempo medio por sesión.
Form_submit: el evento que no ve formularios de terceros
Form_submit: el evento que no ve formularios de terceros
El evento form_submit de los eventos mejorados de GA4 detecta envíos de formularios HTML nativos. Solo esos. Si tu formulario de contacto, tu chat, tu herramienta de reservas o tu popup de captación de leads carga desde un iframe o está construido con un widget externo (Typeform, HubSpot Forms, Calendly), GA4 no registra nada.
El resultado más habitual: en el panel ves cero conversiones de formulario cuando en tu CRM tienes decenas de leads. La analítica dice que el formulario no convierte. La realidad es que la medición no llega hasta él.
Estos casos necesitan, casi siempre, un evento personalizado que se dispare mediante la API de la herramienta externa o mediante escucha de mensajes postMessage desde el iframe. No hay atajo aquí.
Click: demasiado ruido, poca señal
El evento click en GA4 registra clics en enlaces externos. Solo en externos, ojo. Cualquier enlace que lleve fuera de tu dominio. Esto puede parecer útil, pero en la práctica genera una cantidad de datos masiva y poco accionable si no lo filtras.
El error más frecuente es marcar como conversión cualquier clic externo, o intentar sacar conclusiones sobre el comportamiento de usuarios a partir de un evento sin parámetros de contexto. ¿Qué enlace? ¿Desde qué página? ¿En qué posición? Sin filtrar por link_url y cruzar con la página de origen, este evento es ruido.
La buena práctica es no usar el evento click genérico como conversión y, en cambio, crear eventos personalizados para los destinos externos que sí te importan: enlaces a tiendas de apps, perfiles de redes sociales, fichas de Google Business, etc.
Cómo saber si tus eventos están realmente bien configurados
Antes de lanzarte a revisar cada evento, hay dos herramientas que te dan una radiografía rápida: el DebugView de GA4 (en Administración → DebugView) y la extensión de Chrome Google Analytics Debugger. Con ambas puedes ver en tiempo real qué eventos se disparan, con qué parámetros y si hay duplicados.
Un proceso de auditoría básica pasa por estos pasos:
- Navegar por el sitio con DebugView activo y comprobar qué eventos se disparan y con qué valores reales.
- Comparar los ingresos de GA4 con los de la plataforma de pagos durante el mismo periodo. Una desviación superior al 5% señala problema.
- Revisar si hay eventos marcados como conversión que se disparan más de una vez por sesión sin que eso tenga sentido (por ejemplo, un purchase que aparece tres veces en la misma sesión).
- Verificar que los eventos de formulario coinciden, al menos de forma aproximada, con los leads del CRM.
No hace falta hacerlo todo de golpe. Empieza por el evento que afecta a tus conversiones principales. Ese es el que más duele cuando está mal.
Si prefieres no hacer esta auditoría a ciegas, en Analíticamente revisamos tu implementación de GA4 desde los eventos hasta el modelo de atribución, para que los datos que ves en el panel reflejen lo que de verdad pasa en tu negocio.
