The short version: yes, enable Google Analytics inside Firebase for almost any app that isn’t handling health data, children’s data, or highly regulated financial data without a proper consent flow already built. The reporting is free, the setup takes ten minutes, and skipping it means flying blind on retention and conversion data you’ll wish you had six months from now. The catch nobody mentions in the setup wizard is what happens to that data once you flip the switch, and that’s the part worth reading before you click “Enable.”
What “enabling Google Analytics inside Firebase” means
This trips people up because Firebase Analytics and Google Analytics used to be separate products, and technically they still show up as two different things in your console. Since Google rebuilt Firebase Analytics on the GA4 measurement model back in 2020, “enabling Google Analytics” inside Firebase really means linking your Firebase project to a Google Analytics 4 property. Every new Firebase project prompts you to do this during setup, but plenty of developers click through it or a project gets handed to a marketer years later with the box left unchecked.
Once linked, every app event Firebase already tracks automatically (first open, app update, screen view, app remove) plus every custom event you fire gets sent to a GA4 property you can view either inside the Firebase console or inside analytics.google.com. If you already run a website through GA4, you can link the app and the site to the same property and see a combined user journey, phone app open on Tuesday, website checkout on Thursday, same person.
A real example: the fintech app that nearly skipped it
I worked with a small UK fintech app team last year, four people, building a budgeting tool aimed at freelancers. They’d built the whole MVP in Firebase and were three weeks from launch when their lead developer flagged that turning on Google Analytics felt risky given they were handling bank connection data through Open Banking. Reasonable instinct. Wrong conclusion.
What they needed wasn’t to skip Analytics, it was to scope it. We kept Google Analytics for Firebase switched on for behavioural events (screen views, onboarding completion, feature usage) and explicitly excluded anything touching account balances or transaction categories from ever being logged as a custom event parameter. Took an afternoon to audit the event list and strip out three parameters that were accidentally passing account nicknames. Nobody needed to see that in a dashboard. The app launched with Analytics on and a clean event schema, and within six weeks they could see that 61% of users who completed onboarding never opened the app again after day three, a number they’d have had zero visibility on otherwise.
That’s the pattern I see over and over. The instinct to disable Analytics because “we handle sensitive data” is almost always solving the wrong problem. The fix is controlling what you send, not whether you send anything at all.
The step-by-step: how to link it
If you’re deciding whether to do this, it helps to see how little friction is involved:
- Open the Firebase console and go to Project settings, then the Integrations tab.
- Find Google Analytics and click Enable, or Manage if it’s already partially set up.
- Choose whether to link to an existing GA4 property (do this if you already have a website property you want app data feeding into) or create a new one.
- Pick your data sharing settings, which by default include Google products and services, benchmarking, and technical support. Every one of these is a toggle you can turn off individually.
- Set your data retention window under Analytics Data Settings. The default is 2 months for user and event level data. You can extend it to 14 months, and for most apps you should, because 2 months of retention makes cohort analysis nearly useless.
That’s the whole technical process. The decision-making around it is where the time should go, not the button clicking.
Why most teams should say yes
The case for enabling it is straightforward and rarely disputed, so I’ll keep this part short:
- It’s free at any volume for the Analytics collection itself, no matter how many users your app has.
- You get Audiences you can push straight into Google Ads for App campaigns, which is the only reliable way to get Google’s bidding algorithm optimising toward in-app purchases rather than just installs.
- Crash-adjacent behavioural data (what someone did in the ten screens before a crash) becomes visible, which product teams rarely get any other way without paying for a separate tool like Amplitude or Mixpanel.
- You unlock Firebase Predictions and the ability to export raw event data to BigQuery, though that export itself requires upgrading from the free Spark plan to the pay-as-you-go Blaze plan. BigQuery storage runs around $0.02 per GB per month once you’re there, which for most small-to-mid apps is a few pounds a month, not the barrier people assume it is.
If your app has any connection to paid acquisition, and most do eventually, this is the same underlying account structure I walk through in how to link Google Ads with Google Analytics correctly, because the Firebase-to-Ads link uses the exact same conversion tracking logic as the web version. Get one wrong and you’ll get the other wrong too.
The part the setup wizard doesn’t make obvious
Here’s the bit that gets glossed over on most guides. When you leave the default data sharing settings on, Google gets permission to use your app’s Analytics data to improve its own products, including ad products used across the wider Google ecosystem, not just to optimise your own campaigns. That’s not a conspiracy, it’s written plainly in Google’s own data sharing settings, most people just never open that screen because the wizard defaults everything to “on” and moves you along.
For a UK or EU business, that matters because UK GDPR treats device identifiers and app instance IDs as personal data in most contexts, and Firebase collects some of this automatically the moment the SDK initialises, before a user has necessarily given consent through a proper consent banner. If your app doesn’t have a real consent management flow built in before first launch, and a lot of MVP-stage apps don’t, you can end up with data flowing to Google before anyone’s agreed to it. This is the uncomfortable bit nobody wants to slow launch down to fix, and it’s exactly why I tell clients to audit their event schema and consent flow together, in the same sitting, not as two separate to-do items three sprints apart.
None of this means don’t enable Analytics. It means enable it deliberately, with the sharing toggles reviewed rather than accepted, and with a consent flow that gates SDK initialisation for EU and UK users. That’s a half-day job for a developer. Skipping it isn’t privacy-friendly, it’s just privacy-invisible until someone complains.
When it’s better to leave it off
There are a handful of situations where I’d push back on enabling it, or at least delay:
- Apps handling protected health information where the added exposure isn’t worth the reporting benefit, especially anything falling under stricter health data rules.
- Children’s apps, where COPPA and the UK’s Age Appropriate Design Code make default Google data sharing a genuine compliance headache rather than a minor tweak.
- Apps already running a dedicated analytics tool like Mixpanel or Amplitude where the team has decided one source of truth matters more than free duplication, and running both just creates two dashboards that never quite agree with each other.
- Very early prototype apps with under 50 users, where the effort of doing consent and event scoping outweighs any insight you’d act on yet.
Outside those four situations, I’ve never seen a legitimate reason to leave it disabled. The teams who skip it usually aren’t doing it for privacy reasons anyway, they’re doing it because nobody assigned the task, which brings me to the last point.
Who should be making this call
This decision keeps landing on developers because it’s presented as a technical checkbox, but it’s a data strategy decision dressed up as one. The developer knows how to click Enable. They usually don’t know what marketing needs from event naming conventions, or what the compliance team needs from a retention window, or what the growth lead needs from Google Ads conversion signals. I’ve sat in on more Firebase setup calls than I can count where three people in the same company would have made three different choices on the sharing settings, because nobody had had the conversation.
If you’re rebuilding how a small business runs its marketing stack around AI tools and analytics, which is roughly what I’ve spent the last year doing in public, this is exactly the kind of unglamorous foundation work that gets skipped in favour of shinier projects, and it’s covered in more detail in how I rebuilt my marketing business with AI, because the analytics layer underneath everything else quietly decides whether the AI tools on top have anything useful to work with. Garbage event data in, garbage AI-generated insight out, every time.
If your team is more than one person, get whoever owns Google Ads, whoever owns product, and whoever owns compliance into the same fifteen-minute call before anyone clicks Enable. I’ve seen that one conversation save companies from a painful re-audit eight months later. Access and permissions matter here too, and the same principle I use when setting up shared dashboards is worth applying to Firebase and GA4 access, covered in how to collaborate with team members and clients without a mess, because giving five people admin access to a GA4 property they’ll never look at again is its own kind of clutter.
And if you’re weighing this alongside a bigger decision about whether to bring in outside help to set your whole analytics and AI stack up rather than piecing it together yourselves, that’s the exact conversation I have on AI consultant for small business calls, because Firebase and GA4 are rarely the only tools in the mess by the time someone asks for help.
What the data is worth once it’s flowing
Assuming you enable it, the practical payoff shows up fastest in conversion attribution. Once Firebase Analytics is feeding a GA4 property that’s also linked to Google Ads, you can build audiences of users who completed a specific in-app event (say, added a payment method) and target lookalikes through Google Ads, or exclude existing customers from acquisition spend entirely. For a client running app install campaigns for a subscription product, this cut their cost per trial signup by roughly a third over four months, mostly because the algorithm stopped optimising for cheap installs from users who never converted and started optimising for the actual event that mattered.
That same underlying event data is also what feeds any lead generation work sitting alongside the app, whether that’s a companion website capturing emails before download or a sales team following up trial users manually. If part of your growth plan involves handing qualified leads to an outside team, the quality of that handoff depends entirely on whether the events feeding it were tracked in the first place, which is worth bearing in mind if you’re evaluating options from a list like reliable lead generation companies to work alongside your app.
Frequently asked questions
Is Google Analytics inside Firebase the same as GA4?
Yes, since 2020 Firebase Analytics runs on the same measurement model as GA4, and “enabling Google Analytics inside Firebase” means linking your Firebase project to a GA4 property so app events show up in both the Firebase console and Google Analytics directly.
Does enabling Google Analytics in Firebase cost money?
The Analytics collection itself is free at any scale, but exporting raw event data to BigQuery requires upgrading from Firebase’s free Spark plan to the pay-as-you-go Blaze plan, though BigQuery storage costs are typically only a few pounds a month for small to mid-sized apps.
What data does Firebase collect automatically before I add custom events?
Firebase automatically logs events like first open, app update, in-app purchase, screen view, and app removal, along with device identifiers and app instance IDs, some of which count as personal data under UK GDPR, so consent flow timing matters more than most setup guides mention.
Should a children’s or health app enable Google Analytics in Firebase?
Generally no, or only with significant extra care, since default Google data sharing settings create real compliance exposure under rules like COPPA or the UK’s Age Appropriate Design Code, and the reporting benefit rarely outweighs that added risk for these categories.
