Firebase Analytics

Firebase Analytics and GA4 have merged into a single measurement platform, but the distinction still matters architecturally. Firebase provides the SDK for native iOS and Android apps, while GA4's gtag.js handles web. Both feed into the same GA4 property, the same BigQuery export, and the same reporting interface. Understanding this convergence — and its rough edges — is essential for any organisation operating both web and app properties.

The Firebase SDK collects app events with a different paradigm than web analytics. Screen views replace pageviews. App lifecycle events (app_open, app_remove, first_open) have no web equivalent. User properties persist across sessions by default (unlike web, where cross-session identity requires authentication). In-app purchases are tracked automatically with revenue attribution. This means your BigQuery export contains two fundamentally different event schemas in the same tables — and your dbt models need to handle both.

Cross-platform measurement — understanding a user's journey from app to web and back — is Firebase's strongest analytical proposition. When a user signs in on both platforms, GA4's User-ID feature links their activity. In BigQuery, you can query complete cross-platform journeys: app install → web browse → app purchase. The reality is messier than the marketing: User-ID coverage is typically 15-40% of total users (only authenticated sessions), and the stitching logic has edge cases (multiple devices, shared accounts, delayed sign-in) that produce phantom journeys.

Firebase's predictive audiences are production-grade for app analytics. The 'likely to churn' and 'likely to purchase' predictions use on-device ML models trained on your app's specific engagement patterns. Unlike GA4's web predictive audiences (which require minimum event thresholds that most web properties don't hit), Firebase predictions work well for apps with daily active usage. Using these audiences for re-engagement campaigns typically yields 25-40% better click-through rates versus demographic targeting.

Remote Config and A/B Testing are Firebase features that web analysts often overlook. Remote Config lets you change app behaviour without deploying a new version — feature flags, UI copy, threshold values. A/B Testing runs controlled experiments using Remote Config variables with Firebase Analytics as the measurement layer. The integration is tighter than any web-based experimentation tool: variant assignment, event collection, and statistical analysis all happen within the Firebase ecosystem. The statistical methodology uses Bayesian inference with expected loss calculations — more decision-ready than frequentist p-values.

Crashlytics integration creates a unique analytical capability: correlating crash rates with user behaviour and conversion funnels. When you see a conversion rate drop on a specific device model, you can cross-reference with Crashlytics to identify whether crashes on that device explain the drop. This crash-analytics correlation is something no web analytics tool can offer, and it's invaluable for app-dependent businesses.

The BigQuery export from Firebase follows the same schema as GA4 web exports, which means your dbt models can process both in a unified pipeline. The key differences: Firebase exports include user_properties as an array (not just event parameters), device.advertising_id for mobile attribution (not available on web), and app-specific events (in_app_purchase, notification_receive). Build platform-aware dbt models that handle these schema differences with conditional logic rather than separate pipelines.

For organisations running both web and app, the recommended architecture: Firebase SDK for native apps, GA4 gtag.js for web, both feeding a single GA4 property. BigQuery export as the analytical foundation. dbt models with a platform dimension that normalises web and app events into comparable metrics. Robin Signals for cookieless web traffic truth (where GA4's consent dependency biases web data). This multi-source architecture gives you complete coverage with each tool handling what it does best.