What Firebase Analytics means for your app's privacy disclosures
Firebase Analytics is a product analytics tool from Google. What it involves, whether it needs the tracking prompt, what goes on the App Store labels and the Play Data safety form, and the rejection it is usually behind.
What Firebase Analytics actually does
Google's free app analytics, and the single most installed SDK in mobile. It arrives with almost every other Firebase product.
What its job necessarily involves
These follow from what the thing is for, so they are true whichever version you installed:
- An app instance identifier, which is per install rather than per person, plus device and locale.
- Screens and events, including any parameter you decided to attach to them.
- Advertising identifiers only if you turn on the ad features or link a Google Ads or AdMob account, which is the switch that changes what this page says about you.
What to open and check in Firebase Analytics
The settings below decide what the honest answer on the forms is, and they are specific to this SDK rather than to its category:
- Whether an AdMob or Google Ads account is linked to the Firebase project. This single setting decides whether the tracking prompt applies to you.
- Whether analytics collection is disabled by default in the build settings and enabled after consent, which is the only clean way to do this in Europe.
- What you pass as event parameters, because those are yours and nobody reviews them.
Firebase Analytics does not need the tracking prompt
It measures your own app rather than following people into other companies' apps, so long as you have not turned on the advertising features. So Firebase Analytics does not on its own require App Tracking Transparency. That is a statement about this SDK, not about your app: add one ad network or one attribution tool and the prompt applies to everything.
Firebase Analytics in Europe: nothing may run before consent
This is the part that gets missed, because the natural place to initialise an SDK is the moment the app launches, and the natural place to ask for consent is a screen that appears after it. Reading or writing anything on the device for product analytics needs agreement first, and that comes from the ePrivacy rules rather than the GDPR, so picking a different legal basis does not get you past it.
Firebase Analytics in California: probably not a sale
Firebase Analytics does its job for you rather than for its own commercial purposes, which normally keeps it a service provider rather than a sale. That depends on your contract saying so, and the standard terms usually do.
Firebase Analytics on the App Store privacy labels
Apple asks what your app collects, and your app collects whatever its SDKs collect. Firebase Analytics is generally declared under Analytics, alongside whatever the rest of your app does for its own reasons.
Firebase Analytics on the Google Play Data safety form
The form asks two things the labels do not: whether data is shared with anyone else, and whether it is encrypted in transit. For this SDK the honest answer is usually collected but not shared, because it processes on your behalf.
Check Google's own privacy manifest for Firebase Analytics
Since 2024 Apple has required third-party SDKs on its list to ship a signed privacy manifest declaring what they collect and which sensitive APIs they use, and your app's combined manifest is built from them. That file is the authoritative answer for Firebase Analytics, it comes from Google, and it changes when they ship.
The rejection Firebase Analytics is usually behind
Firebase came in with Crashlytics or push, nobody decided to add analytics, and the labels were filled in as if it were not there.
What to put in the privacy policy about Firebase Analytics
- Google named as a processor or a recipient, not hidden behind "our partners".
- What it is for, in a sentence someone would understand without knowing what an SDK is.
- Where it runs, and what makes a transfer outside your region lawful.
- How long the data is kept, which is a question the vendor documents and most policies skip.
- That it processes on your instructions rather than for its own purposes.
Keeping it true after launch
A legal page stops being true the moment the product moves past it, usually by adding a payment provider, an analytics SDK or a sign-in. No store re-checks your pages against your build, so the drift is yours to notice.
- Re-read it whenever you add a dependency that sees user data.
- Re-check what loads on the page after any change: the cookie notice and the policy have to agree.
- Keep the URL stable. Changing where a policy lives breaks every listing that points at it.
Common questions
Do I need a privacy policy just because I use Firebase Analytics?
Yes, and you needed one anyway. Both stores ask for the URL before a listing goes live, whatever the app does. The SDK changes what the policy has to say, not whether you need one.
Does Firebase Analytics put me over the line into tracking?
Not by itself. The question is always about your app as a whole, so it is the other things you installed that decide the answer.
Does removing the SDK fix a rejection?
Usually yes and it is the fastest route, but only if you also correct the labels and the form. Reviewers compare what you declared against what the binary contains, and a stale declaration fails on its own.