GA4 y Firebase Analytics comparten la misma infraestructura de Google por debajo, lo que genera confusión constante sobre cuál usar. En la práctica resuelven necesidades distintas, y la respuesta correcta depende del tipo de producto que estés midiendo.

La versión corta: Firebase Analytics es Google Analytics para Firebase. No es un producto competidor. Los datos de app que recolecta el SDK de Firebase terminan en una propiedad de GA4. La pregunta real casi nunca es “GA4 o Firebase”, sino en qué consola conviene trabajar y qué eventos van a cada lado.

Mismo motor, propósitos distintos

Las dos usan el mismo modelo de datos: eventos con parámetros, en lugar del modelo de sesiones y pageviews de Universal Analytics. Las dos exportan a BigQuery con esencialmente el mismo esquema. Lo que cambia es la superficie construida encima.

Firebase nació pensado para equipos de producto de apps móviles: eventos técnicos, crash reporting con Crashlytics, Remote Config, A/B testing nativo de features, push. GA4 nació pensado para equipos de marketing y analítica web/app combinada: atribución de campañas, embudos de conversión, exportación de audiencias e integración con Google Ads.

Firebase Analytics GA4
Usuario principal Equipos de producto e ingeniería Marketing, growth, analítica
Fuentes de datos SDK nativo (iOS, Android, Flutter, Unity) Web (gtag/GTM) y app, vía Firebase vinculado
Fuerte en Comportamiento in-product, crashes, experimentos Atribución, ROI por canal, journeys cross-platform
Integración con Ads No Sí, nativa con Google Ads
Crash reporting Sí (Crashlytics) No
Remote Config / A/B Sí No
Medición web No Sí
Identidad por defecto Dispositivo / instancia de app Configurable: combinada, observada o por dispositivo
Export a BigQuery Sí Sí, exportación diaria gratuita

Cuándo trabajar en Firebase

Si el producto es una app nativa y las preguntas centrales son de comportamiento dentro del producto —qué feature usan más, dónde crashea, qué variante retiene mejor—, Firebase da herramientas más profundas y nativas, sin pasar por una capa de analítica de marketing. Crashlytics y Remote Config solos ya justifican vivir en esa consola.

Cuándo trabajar en GA4

Si el negocio necesita saber qué canal de marketing trae usuarios que convierten, medir ROI de campañas, o unificar comportamiento entre web y app en un mismo reporte, GA4 es la superficie correcta. Está construida sobre el mismo modelo de eventos pero orientada a atribución, y es la única de las dos que le habla a Google Ads.

Cómo funciona el vínculo, en concreto

Un proyecto de Firebase se conecta a exactamente una propiedad de GA4, y cada app del proyecto pasa a ser un stream de datos de app adentro de esa propiedad. Tres cosas que suelen malentenderse:

El vínculo no es retroactivo. Los eventos recolectados antes de que existiera el vínculo no aparecen en GA4. Es la misma regla que la exportación a BigQuery, y sorprende por el mismo motivo: nada te avisa.

Un proyecto de Firebase, una propiedad de GA4. No podés apuntar el mismo proyecto a dos propiedades. Si necesitás los datos de app en más de un lugar, eso se resuelve en BigQuery, no con una configuración de vinculación.

Desvincular pierde la conexión, no el histórico. Lo que ya está en GA4 se queda ahí. Pero volver a vincular no rellena el hueco que se generó mientras estuvo desconectado.

Por qué los números de Firebase y GA4 no coinciden

Es la pregunta más común que recibo sobre medición en apps, y la respuesta casi nunca es “algo está roto”. Las dos consolas están contando cosas deliberadamente distintas.

Identidad distinta. La consola de Firebase reporta sobre instancias de app, es decir dispositivos. GA4 te deja elegir la identidad de reporte: combinada, observada o por dispositivo. Si GA4 está en combinada y está uniendo usuarios entre dispositivos, su conteo de usuarios va a ser menor que el de Firebase, porque dos dispositivos de una misma persona logueada colapsan en un usuario.

Definiciones distintas de “activo”. Firebase cuenta un usuario activo a partir del evento user_engagement. La definición de usuario activo de GA4 no es idéntica, y varía levemente según la plataforma. Dos definiciones razonables, dos números distintos.

Zonas horarias distintas. La consola de Firebase y la propiedad de GA4 tienen cada una su propia configuración de zona horaria de reporte. Si no coinciden, todos los números diarios quedan corridos — y parece un bug de tracking cuando en realidad es de configuración.

Thresholding en GA4. Con Google Signals activo y pocos registros, GA4 oculta datos por privacidad. La consola de Firebase no aplica el mismo umbral, así que muestra filas que GA4 esconde.

Muestreo en las exploraciones. Los reportes estándar de GA4 no están muestreados; las exploraciones complejas sobre rangos largos sí pueden estarlo. Los reportes de Firebase no se muestrean igual.

Latencia de procesamiento. Las dos pueden demorar, y no demoran igual. Comparar los números de hoy entre dos consolas no es una comparación.

La regla práctica: no intentes reconciliar las dos interfaces. Elegí una como fuente de verdad para cada pregunta —Firebase para producto, GA4 para marketing— y usá BigQuery como árbitro cuando un número importe de verdad. BigQuery es el único lugar con las filas crudas que las dos superficies están resumiendo.

Los límites que rompen implementaciones

Esta es la parte que rara vez aparece en las comparativas, y es donde la mayoría de las implementaciones se rompe de verdad.

  • Los streams de app tienen un tope de 500 nombres de evento distintos. Los de web no. Los equipos que registran boton_click_checkout, boton_click_carrito y demás como eventos separados se comen ese techo rápido: conviene un solo nombre de evento con parámetros.
  • 25 parámetros por evento, y 50 dimensiones personalizadas con alcance de evento en una propiedad estándar. Los parámetros que no registrás como dimensión se recolectan pero no se pueden consultar en la interfaz — aunque sí llegan a BigQuery.
  • Los nombres reservados difieren entre las dos. Firebase autorecolecta eventos como first_open, session_start e in_app_purchase. Pisar un nombre reservado corrompe en silencio el reporte que depende de él.
  • Doble conteo. Si disparás el SDK de Firebase y gtag.js para la misma acción en una app híbrida o con webview, el evento se cuenta dos veces y ninguna interfaz te avisa.
  • La retención es más corta de lo que la gente supone. En una propiedad estándar de GA4, los datos con alcance de usuario y de evento para exploraciones se retienen 2 o 14 meses según la configuración — y el default es el corto. Los reportes estándar agregados duran más, pero el dato granular que necesitarías para una cohorte año contra año vence en silencio. La exportación a BigQuery es la única forma de conservarlo.

El error de usar ambos sin un plan de eventos único

Es común ver implementaciones donde Firebase y GA4 registran eventos con nombres y parámetros distintos para lo mismo, generando dos fuentes de verdad que nunca coinciden. Cuando la dirección pregunta por qué el reporte de la app y el de marketing no dan igual, casi siempre la razón es esta.

Definí primero un plan de medición único: un documento con cada evento, sus parámetros y su definición en castellano llano. Después decidí qué eventos van a cada herramienta. El plan va antes de la implementación, no después de que los números dejen de coincidir.

Checklist de setup

Para un producto con app y web, en este orden:

  1. Escribí el plan de eventos antes de tocar código. Nombres, parámetros, definiciones y a qué pregunta responde cada uno.
  2. Creá primero la propiedad de GA4 y después vinculá Firebase. Poné la misma zona horaria de reporte en las dos, hoy.
  3. Subí la retención de datos a 14 meses en el admin de GA4. Son dos clics y el default te cuesta un año de histórico.
  4. Activá la exportación a BigQuery el mismo día, antes de que alguien la pida.
  5. Registrá como dimensiones personalizadas los parámetros que vas a consultar, dentro del presupuesto de 50 slots. Racionalos a propósito.
  6. Auditá el doble conteo en cualquier pantalla híbrida o con webview, contando eventos por sesión en BigQuery en lugar de confiar en la interfaz.
  7. Definí la fuente de verdad por pregunta, escribila, y dejá de reconciliar el resto.

La recomendación práctica

Para la mayoría de los productos con app y web, la combinación que funciona es GA4 como capa de marketing y atribución, con Firebase como capa de análisis de producto profundo, las dos alimentadas por el mismo plan de eventos, y BigQuery como árbitro cuando las dos interfaces no coinciden.

Rara vez estás eligiendo una. Estás decidiendo qué va en cada una.

Preguntas frecuentes

¿Firebase Analytics es lo mismo que GA4? Comparten el modelo de datos de eventos, el esquema de BigQuery y el pipeline de fondo. Firebase Analytics es la superficie orientada a app; GA4 es la superficie orientada a marketing sobre mayormente los mismos datos. Un proyecto de Firebase se vincula a una propiedad de GA4 y los eventos de app fluyen hacia ahí.

¿Necesito las dos? Si tenés una app nativa y hacés adquisición paga, sí: Firebase para producto y crashes, GA4 para atribución y Google Ads. Si sos sólo web, alcanza GA4. Si tenés app y cero inversión en medios, Firebase sola puede alcanzar.

¿Firebase puede medir mi sitio web? No de forma útil. Firebase Analytics está construido alrededor de SDKs nativos de app. La medición web va en GA4, con gtag.js o Google Tag Manager.

¿Cuál uso para atribución? GA4. Firebase no tiene integración nativa con Google Ads ni modelado de atribución. Si la pregunta es “qué canal generó esta conversión”, es una pregunta de GA4.

¿Por qué mis usuarios de Firebase y de GA4 no dan igual? Casi siempre por la identidad de reporte: Firebase cuenta instancias de app y GA4 puede estar uniendo usuarios entre dispositivos. Las zonas horarias y el thresholding de GA4 explican casi todo el resto. No están pensadas para coincidir exactamente.

¿Vincular Firebase a GA4 importa mi histórico de app? No. El vínculo empieza a recolectar desde el momento en que se crea. No hay backfill, en ninguna de las dos direcciones.

¿Firebase Analytics es gratis? Sí, Google Analytics para Firebase es gratis con reporte ilimitado de eventos estándar. Los costos aparecen en otras partes de Firebase —Cloud Functions, Firestore, hosting— y en BigQuery una vez que pasás los límites del sandbox.

El paso siguiente, sea cual sea la que uses

Activá la exportación a BigQuery el mismo día que creás la propiedad. No es retroactiva: los meses que no exportaste no se recuperan. Exportar GA4 a BigQuery cubre el esquema anidado, cómo controlar el costo y por qué conviene hacerlo antes de necesitarlo.

Si la medición es lo que no te cierra en tu propia cuenta, así trabajo con marcas — el tracking suele ser lo primero que audito.