GA4 vs. event-based: la guía que nadie quiere escribir

La conversación sobre tracking se volvió innecesariamente compleja. Por un lado, GA4 sigue siendo la recomendación por defecto de consultores que no quieren tomar una posición. Por el otro, el mundo de los data warehouses vende que cualquier empresa necesita un stack completo desde el día uno.

La realidad es más aburrida y más útil: depende de tu etapa y de las preguntas que necesitas responder.

1. Qué resuelve GA4 bien (y qué no)

GA4 es una herramienta sólida para empresas que necesitan entender comportamiento de usuarios en web y app sin invertir en infraestructura de datos propia.

Hace bien:

  • Análisis de tráfico, fuentes y comportamiento de sesión.
  • Funnel de conversión básico con eventos configurados.
  • Audiencias para remarketing en Google Ads.
  • Informes de retención a nivel de cohorte (con limitaciones).

Hace mal:

  • Atribución multi-touch real. Su modelo de atribución tiene sesgos que favorecen los canales de Google.
  • Análisis a nivel de usuario individual. El sampling y la anonimización limitan los análisis granulares.
  • Joins con datos de producto o CRM. GA4 vive en su propio silo. Cruzar datos con Salesforce o tu base de datos requiere BigQuery.
  • Confiabilidad en entornos con ad blockers. Hasta el 30% del tráfico puede no registrarse si usas GA4 client-side.

2. Cuándo necesitas un stack de event-based tracking

La señal más clara es cuando empiezas a hacerte preguntas que GA4 no puede responder:

  • "¿Los usuarios que usan la funcionalidad X tienen mayor LTV?"
  • "¿Cuál es la correlación entre el número de integraciones activadas y el churn a 90 días?"
  • "¿Qué secuencia de acciones en los primeros 7 días predice la retención?"

Estas preguntas requieren datos a nivel de evento, a nivel de usuario individual, cruzados con datos de negocio. Requieren un warehouse.

El stack típico para una startup en etapa de crecimiento: Segment o RudderStack (CDP) → BigQuery o Snowflake (warehouse) → dbt (transformaciones) → Metabase o Looker (visualización).

3. Server-side tracking: por qué importa ahora

El tracking del lado del cliente (JavaScript en el navegador) tiene tres problemas que se volvieron críticos:

  • Ad blockers: bloquean los pixels y las librerías de analytics.
  • ITP de Safari: limita las cookies de terceros a 7 días, distorsionando la atribución de campañas largas.
  • Velocidad de página: cargar 5 pixels distintos impacta directamente el Core Web Vitals.

El server-side tracking mueve la lógica de captura al servidor: el browser envía los eventos a tu propio servidor, que luego los distribuye a GA4, Meta, etc. El resultado es datos más completos, mayor control sobre la privacidad y mejor performance de página.

Para la mayoría de empresas, implementar server-side tracking a través de Google Tag Manager Server-Side o Segment con destinos server-side es el mejor tradeoff entre cobertura y complejidad.

4. El decision tree: elige tu stack según tu etapa

  • Pre-product market fit (0-50K usuarios): GA4 + Hotjar. No sobreinviertas en infraestructura de datos que no puedes usar aún. Concéntrate en entender el comportamiento cualitativo.
  • Early growth (50K-500K usuarios): Añade un CDP (Segment o RudderStack) y empieza a enviar eventos a BigQuery. Construye los primeros dashboards de retención y activación.
  • Growth (500K+ usuarios): Stack completo con warehouse, dbt y server-side tracking. La calidad del dato se vuelve una ventaja competitiva.

5. El error más caro: trackear todo sin saber por qué

Más datos no es mejor análisis. El error más común en equipos que implementan un CDP es empezar a trackear 200 eventos porque "puede ser útil después."

El resultado es un warehouse con datos sin documentar, esquemas inconsistentes y analistas que no confían en los números.

Empieza con 10 eventos críticos bien definidos y documentados. Un evento bien trazado con su propósito claro vale más que 50 eventos sin contexto.