Configuración avanzada de GA4 en la práctica: guía completa de seguimiento de eventos y embudos de conversión

El 1 de julio de 2023, Google cerró por completo la recolección de datos de Universal Analytics. Esa mañana abrí el panel, vi cómo la línea de datos en los informes de UA se cortaba de golpe, y solo tenía una pregunta en la cabeza: ¿cómo se supone que hay que usar GA4?

Si, como yo, migraste desde UA y solo instalaste el código básico, mirando la interfaz de GA4 sin saber por dónde empezar — tranquilo, no estás solo. Muchos webmasters van «a ciegas»: ven las visitas a páginas, pero no capturan lo que de verdad importa — qué botones pulsan, cuántos artículos leen o en qué paso se van.

Este artículo no explica qué es GA4; va a lo práctico: cómo usar el seguimiento de eventos para entender el comportamiento, cómo configurar embudos de conversión para encontrar puntos de abandono y, si necesitas análisis profundo, cómo exportar datos a BigQuery y consultarlos con SQL. Empezamos por los tres tipos de eventos.

1. Los tres tipos de seguimiento de eventos en GA4

La lógica central de GA4 es distinta a la de UA. UA usa un modelo de «sesión + vista de página»; GA4 es «todo son eventos».

Seguro que lo has oído muchas veces, pero ¿qué significa en la práctica? En pocas palabras: la vista de página es un evento, el clic en un botón es un evento, reproducir un vídeo es un evento, llegar al final de la página con scroll también. Cada acción del usuario queda registrada como un «evento» independiente.

Pero los eventos no se crean al azar. Google los divide en tres categorías, cada una con su uso y sus límites.

1. Eventos automáticos (Enhanced Measurement): listos para usar

Es el «regalo» que GA4 incluye de serie. Al crear un flujo de datos, Enhanced Measurement viene activado por defecto y rastrea 7 interacciones:

• Vistas de página (page_view)
• Scroll (scroll) — solo al 90% de profundidad
• Clics salientes (click)
• Búsqueda interna (search)
• Interacción con vídeo (video_start, video_progress, video_complete)
• Descarga de archivos (file_download)
• Interacción con formularios (form_start, form_submit)

Suena completo, ¿verdad? Pero hay un truco: el scroll solo se registra al 90%. Si quieres saber cuántos terminan un artículo o medir el 50% o el 75%, Enhanced Measurement no basta — hay que configurarlo con GTM.

Mi consejo: déjalo activado, pero no confíes demasiado en él. Te da datos base; los comportamientos que de verdad importan hay que medirlos tú.

2. Eventos recomendados: siguiendo el guion de Google

Google define un conjunto de «eventos recomendados» por sector. En ecommerce hay add_to_cart, begin_checkout, purchase; en sitios de contenido, sign_up, login, share.

La ventaja: si usas el nombre y los parámetros correctos, GA4 genera informes automáticos. Por ejemplo, con el evento purchase obtienes informes de compra sin montarlos a mano.

Ojo: los recomendados no se disparan solos. Sigues necesitando código en el sitio (o GTM); la diferencia es que nombre y parámetros deben seguir la especificación de Google.

Ejemplo para un blog:

En mi blog configuré sign_up para rastrear suscripciones. Al principio lo llamé signUp (camelCase) y GA4 no lo reconoció — los recomendados exigen snake_case, letra por letra.

3. Eventos personalizados: libertad total, con coste

Cuando lo que quieres medir no está en la lista de Google, defines tu propio evento. Yo uso article_read_complete para «usuario terminó de leer un artículo».

Los personalizados son muy flexibles, pero tienen límites:

1. Tope de parámetros: como máximo 25 parámetros personalizados por evento. Simo Ahava (referencia en GA4) comprobó que, si pasas de 25, los datos siguen exportándose a BigQuery, pero GA4 los ignora en informes nativos.

2. Convención de nombres: solo letras, números y guiones bajos; debe empezar por letra. Usa snake_case, igual que en los recomendados.

3. Retraso en informes: tras configurarlos, pueden tardar 24-48 horas en aparecer. No asumas que falló la configuración; espera un poco.

Prioridad de configuración: un árbol de decisión simple

Si no sabes qué tipo usar, sigue este orden:

1. Mira si Enhanced Measurement ya lo cubre — listo para usar, ahorra trabajo
2. Revisa la lista de recomendados — sigue la spec y obtienes informes automáticos
3. Solo entonces personaliza — más libertad, más mantenimiento

En la mayoría de blogs basta Enhanced Measurement más unos pocos recomendados. Los personalizados son para quien necesita análisis profundo.

2. Configuración práctica del seguimiento de eventos

Con claros los tres tipos, toca configurar.

Hay dos formas habituales: Google Tag Manager (GTM) o gtag.js en la página. Recomiendo GTM: cuesta más aprenderlo, pero mantener triggers después es mucho más cómodo — cambias condiciones sin redesplegar código.

Configurar eventos GA4 con GTM: cuatro pasos

Supón que quieres medir «lectura completa del artículo». El flujo sería:

Paso 1: crear una etiqueta GA4 Event

En GTM, nueva etiqueta, tipo Google Analytics: GA4 Event. Introduce tu Measurement ID y como nombre de evento article_read_complete.

Paso 2: configurar el Trigger

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Aquí le dices a GTM cuándo disparar el evento.

Para «lectura completa» suelo usar scroll al 90%: nuevo Trigger, tipo Scroll Depth, Vertical Scroll Depths en 90%.

Detalle: si tu blog tiene barra de progreso de lectura, puede chocar con el scroll de GTM. Me pasó — barra arriba y eventos de scroll a raudales, datos llenos de ruido. Solución: limitar a un disparo por usuario y artículo.

Paso 3: añadir Event Parameters

Los parámetros son el alma del evento. Saber que alguien terminó de leer no basta; necesitas título, categoría, autor.

En la etiqueta añade Event Parameters:

Mantén el tipo de valor coherente. Si reading_time es numérico, que lo sea siempre; no alternes 5, "5 minutos" — GA4 los tratará como parámetros distintos.

Paso 4: validar en Debug

No publiques a ciegas. Usa Preview en GTM: abre tu blog, scroll al 90% y comprueba en DebugView de GA4 que llega el evento.

DebugView está en Configure > DebugView. Si no ves el evento, revisa el Trigger; si llega sin parámetros, revisa las Variables.

¿Sin GTM? Configuración directa con gtag.js

Si usas un generador estático (Astro, Hugo) y no quieres la complejidad de GTM, gtag.js directo también vale.

// Ejecutar tras cargar la página
window.addEventListener('load', function() {
  // Disparar al llegar al 90% de scroll
  window.addEventListener('scroll', function() {
    var scrollPercent = (window.scrollY / (document.body.scrollHeight - window.innerHeight)) * 100;
    if (scrollPercent >= 90 && !window.articleReadTracked) {
      window.articleReadTracked = true;
      gtag('event', 'article_read_complete', {
        'article_title': document.title,
        'article_category': document.querySelector('meta[name="category"]')?.content || 'unknown',
        'reading_time': parseInt(document.querySelector('meta[name="reading-time"]')?.content || 0)
      });
    }
  });
});

Hace lo mismo que la config GTM: envía article_read_complete al 90%. La diferencia: el código va en la página y cada cambio implica redesplegar.

Trampas habituales (todas las he pisado yo)

Trampa 1: nombres de evento inconsistentes

articleReadComplete, article-read-complete, article_read_complete — en GA4 son tres eventos distintos. Usa solo snake_case, como Google.

Trampa 2: tipos de parámetro mezclados

Hoy reading_time: 5, mañana reading_time: "5 minutes", pasado reading_time: true. GA4 los separa y el informe se vuelve un caos.

Trampa 3: Consent Mode v2 filtra eventos

Si tu sitio atiende usuarios de la UE con Google Consent Mode v2 activo, quien rechace cookies puede no enviar algunos eventos. No es un error de configuración, pero los informes «encogen».

Trampa 4: nombres reservados

page_view, session_start, first_visit están reservados en GA4; no los uses como eventos personalizados. Los parámetros también tienen reservados — consulta la documentación oficial.

Ejemplos prácticos para blogs

Varios eventos que suelo configurar:

Con esto ves en GA4 el comportamiento real en el blog. El siguiente paso es analizar esos datos — ahí entran los embudos de conversión.

3. Configuración y análisis de embudos de conversión

Con el seguimiento listo, la pregunta clave: ¿cuántos se pierden entre la primera visita y completar tu objetivo?

Eso resuelve un embudo de conversión.

Funnel Exploration en GA4 supera con creces a UA. Los embudos de UA eran rígidos; en GA4 defines cada paso, comparas segmentos y analizas tiempos de abandono — funciones que antes pagabas en herramientas de terceros.

Crear tu primer embudo de conversión

En GA4, Explore > Funnel Exploration. Verás una plantilla vacía.

Primero defines los pasos. Puedes poner hasta 10; en blogs suelen bastar 4-5.

Ejemplo de embudo de suscripción:

1. Paso 1: vista de artículo (evento: page_view, condición: page_location contiene /posts/)
2. Paso 2: visita a página de suscripción (evento: page_view, condición: page_location contiene /subscribe)
3. Paso 3: envío del formulario (evento: newsletter_signup)
4. Paso 4: apertura del email de confirmación (evento: email_opened) — requiere tracking en tu servicio de email

Consejo: condiciones simples y claras en cada paso. Combinaciones complejas hacen el embudo difícil de interpretar.

Análisis del embudo: encontrar puntos de abandono

Configurado el embudo, ves tasa de conversión y usuarios perdidos en cada paso.

Supón estos datos en mi blog:

De un vistazo: el primer cuello de botella es «artículo → página de suscripción», solo 8% llega. La entrada a suscripción no se ve o está mal ubicada.

El segundo: «página de suscripción → formulario», 30%. Puede ser formulario largo o valor poco claro.

Luego compara segmentos para ver si el abandono sigue un patrón.

Segmentos: quién se va y quién no

Funnel Exploration permite segmentos para comparar grupos.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Dimensiones habituales:

• Nuevos vs. recurrentes: los nuevos suelen convertir peor porque aún no conocen tu valor
• Móvil vs. escritorio: en móvil los formularios suelen ir peor
• Canal de origen: búsqueda vs. redes sociales

Comparando nuevo vs. recurrente en mi embudo:

Los recurrentes convierten más en cada paso — normal, ya confían en el contenido. Pero en nuevos, «artículo → suscripción» solo 5%: no ven la entrada.

Tras añadir una tarjeta de suscripción visible al final del artículo, los nuevos pasaron del 5% al 12%.

Open Funnel: rutas que no son lineales

Por defecto el embudo es lineal: solo cuenta quien completa los pasos en orden.

En la realidad no siempre es así. Alguien puede suscribirse desde el pie del artículo sin pasar por /subscribe; otro abre el email y vuelve a leer.

Open Funnel no exige orden: si completó un paso, entra en ese paso.

Así descubrí que el 15% de suscriptores enviaban el formulario desde el final del artículo, sin visitar la página dedicada. La entrada al pie del post funciona mejor — conviene optimizar ahí, no solo la landing de suscripción.

Errores frecuentes en embudos

Error 1: mirar solo la conversión final

La tasa total importa, pero los abandonos intermedios son donde mejoras. No te quedes con «1,8% se suscribieron»; mira «en qué paso se fue el 92%».

Error 2: ignorar el tiempo

Puedes fijar ventana de conversión: cuánto tarda alguien del primer al último paso. Si de lectura a pago pasan 7 días, el ciclo es largo — quizá hace falta más confianza o recordatorios.

Error 3: analizar con pocos datos

Con decenas de usuarios por paso, la tasa fluctúa mucho. Mejor esperar a cientos antes de sacar conclusiones firmes.

4. Exportación práctica a BigQuery

Todo lo anterior ocurre en la interfaz de GA4. Pero los informes nativos tienen un límite: con mucho volumen, muestrean. Con 500.000 visitas mensuales, un informe puede basarse solo en el 10% de los datos.

El muestreo acelera la carga; para conversiones exactas o muchas dimensiones a la vez, deja de ser fiable.

Ahí entra la exportación a BigQuery.

Configurar la exportación: tres pasos

BigQuery es el almacén de datos de Google. Exportar GA4 te permite SQL sobre el conjunto completo, sin muestreo.

Paso 1: crear proyecto en BigQuery

En Google Cloud Console, crea un proyecto y activa la API de BigQuery. Cuota gratuita para nuevos usuarios: 10 GB de almacenamiento y 1 TB de consultas al mes — de sobra para un blog.

Paso 2: vincular desde GA4

En GA4 Admin, BigQuery Linking. Clic en Link, elige el proyecto y la frecuencia:

• Daily: exporta una vez al día los datos del día anterior
• Streaming: casi en tiempo real (datos del mismo día en horas)

Recomiendo activar ambos. Daily es estable para análisis a largo plazo; Streaming sirve para el día en curso.

Paso 3: esperar el flujo de datos

Tras configurar, GA4 empieza a exportar en 24 horas. Trampa importante: no hay relleno histórico. Si configuras hoy, solo tendrás datos desde hoy; dos años en GA4 no migran solos.

Si necesitas análisis profundo, configura BigQuery pronto. Cuando quieras historia, ya será tarde.

Estructura de datos en BigQuery

Cada día es una tabla events_YYYYMMDD. Por ejemplo, events_20260429 guarda el 29 de abril de 2026.

Cada fila es un evento con campos como:

Lo que suele atascar a principiantes: event_params no es una columna plana. Para leer valores hay que usar UNNEST.

Consultas SQL útiles

Usuarios únicos de un evento:

SELECT
  COUNT(DISTINCT user_pseudo_id) as unique_users
FROM `your-project.analytics_123456789.events_*`
WHERE event_name = 'article_read_complete'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'

Cuenta cuántos usuarios distintos completaron la lectura en abril.

Distribución de un parámetro:

SELECT
  param.value.string_value as article_category,
  COUNT(DISTINCT user_pseudo_id) as users
FROM `your-project.analytics_123456789.events_*`,
UNNEST(event_params) as param
WHERE event_name = 'article_read_complete'
  AND param.key = 'article_category'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'
GROUP BY article_category
ORDER BY users DESC

Expande event_params y agrupa lecturas completas por categoría de artículo.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

BigQuery vs. informes nativos: cuándo usar cada uno

Regla simple: informes cotidianos en GA4; análisis profundo en BigQuery.

Control de costos en BigQuery

Se cobra por datos procesados en consultas. En blogs el costo suele ser bajo, pero conviene:

1. Limitar fechas con _TABLE_SUFFIX: no escanees toda la historia
2. Filtrar pronto con WHERE: menos datos procesados
3. Vistas materializadas: preagrega consultas frecuentes

Mi blog ronda 1 GB al mes y menos de 100 GB de consultas — dentro de la cuota gratis. Sitios grandes sí deben vigilar; blogs medianos, poco.

5. GA4 vs. UA: lo que un migrante debe saber

Si vienes de UA, este capítulo es para ti.

GA4 no es solo un rediseño: la lógica de fondo cambió. Conceptos «obvios» en UA desaparecen o significan otra cosa.

Modelo de eventos vs. modelo de sesiones

UA gira en torno a la «sesión»: llega, navega, se va — una sesión con varias páginas y eventos.

GA4 gira en torno al «evento»: cada acción es una unidad. La sesión pasa a ser un conjunto de eventos, no el punto de partida del análisis.

¿Qué implica?

En UA mirabas «sesiones» y «páginas por sesión». En GA4 predominan «eventos» y «usuarios».

GA4 aún tiene sesiones, pero enfatiza el «recorrido del usuario». Alguien entra por la mañana y vuelve por la tarde: en UA son dos sesiones; en GA4, un usuario con dos visitas.

Tasa de participación vs. tasa de rebote

En UA muchos obsesionaban con la «tasa de rebote»: cuanto más baja, mejor.

En GA4 desaparece. Entra la «tasa de participación» (Engagement Rate).

¿Por qué? En UA, una sola página y marcharse era rebote — aunque leyera 10 minutos con calma.

En GA4 hay participación si permanece más de 10 segundos, ocurre al menos un evento de conversión o ve más de 2 páginas. Tasa de participación = sesiones con participación / sesiones totales.

No compares la participación de GA4 con el rebote de UA directamente: no son opuestos, miden cosas distintas.

Data Streams vs. Views

UA tenía «vistas»: varias con filtros distintos — solo tráfico nacional, excluir IP interna, etc.

GA4 no tiene vistas. Hay «flujos de datos» (Data Streams): web, iOS, Android.

¿Y filtrar? «Property Filters» — más débiles que las vistas de UA. Solo tráfico interno o spam; no puedes tener varias «lentes» como en UA.

Si dependías de vistas para separar datos, replantea la arquitectura: filtra en BigQuery o crea informes distintos en Looker Studio.

Los Goals de UA hay que remapearlos

Los «Goals» de UA son «eventos de conversión» en GA4.

La configuración también cambió. Un Goal en UA podía ser «visitar una URL», «X minutos en sitio» o «disparar un evento». En GA4 la conversión es «ocurrió un evento» — para una URL como conversión, primero configuras page_view y luego lo marcas como conversión.

Lista tus Goals de UA y mapéalos uno a uno. Es tedioso, pero sin eso no continúas la línea histórica de conversiones.

Para cerrar

En resumen, cuatro ideas:

1. Seguimiento de eventos: entiende automático, recomendado y personalizado; configura por prioridad
2. Embudos de conversión: localiza abandonos, compara segmentos, usa Open Funnel para rutas raras
3. Exportación a BigQuery: si necesitas profundidad, configura pronto — no hay histórico retroactivo
4. Mentalidad de migración: no fuerces métricas de UA sobre GA4; adapta la lógica nueva

Si solo haces una cosa tras leer esto: abre GA4, confirma que Enhanced Measurement está activo y crea un embudo de 3-4 pasos para tu flujo de suscripción.

Los datos no dan la respuesta solos, pero señalan dónde está el problema. Lo que queda es arreglarlo.

Referencias

• Set up events | Google Analytics | Google for Developers — Documentación oficial de eventos GA4
• Recommended events - Analytics Help — Lista de eventos recomendados
• Enhanced measurement events - Analytics Help — Eventos automáticos
• Funnel Exploration Report in GA4 - Analytics Mania — Informes de embudo
• GA4 BigQuery Export Schema Tutorial - Optimize Smart — Tutorial de exportación a BigQuery