Google Analytics for Firebase (GA4) sends user data to Google LLC. Because event data, an app-instance identifier and a derived location leave the device and are processed on Google's infrastructure, this is a third-party data transfer that App Store review, Google Play and the GDPR all require you to disclose in your privacy policy. Generate a full privacy policy with this clause built in →
Does Google Analytics for Firebase need a privacy policy disclosure?
Yes. The Firebase SDK for Google Analytics is the analytics component of Firebase — it records screen views, sessions, custom events, in-app purchase events and automatically collected events, then uploads them to Google along with an app-instance ID and technical device attributes. This is a broader topic than the general Firebase privacy policy guide; this page focuses only on the analytics SDK and its exact data types.
Google acts as your processor for Analytics data by default, but if you enable Google signals, link a Google Ads account, or turn on Google's data-sharing settings, Google may also use the data as an independent controller for advertising and product improvement. Under Apple's Guideline 5.1.2, enabling Google signals or IDFA collection turns Analytics into "tracking" and requires an App Tracking Transparency prompt.
What data does Google Analytics for Firebase collect?
| Data type | Purpose | Linked to the user? | Used for tracking? |
|---|---|---|---|
| App instance ID (and IDFV; IDFA only if AdSupport is linked) | Distinguish app installs, sessionization | Not by default; yes if you set a User ID or enable Google signals | No by default; yes if Google signals or IDFA is enabled |
| Product interaction / event data (screen views, sessions, custom and automatic events) | Analytics and reporting | Not by default | No by default |
| In-app purchase events (product ID, name, price, currency) | Revenue reporting | Not by default | No |
| Coarse / general location (country, region, city derived from a masked IP) | Geographic reporting | Not by default | No |
| Device and OS attributes (model, OS version, language, app version, network type) | Analytics, compatibility | Not by default | No |
| Crash data (only if Crashlytics is used with Analytics) | Diagnostics | Not by default | No |
Google states that Firebase Analytics unconditionally drops the full IP address after deriving a coarse location — there is no raw IP logging and no setting to change that. The exact list above still depends on your configuration: setting a User ID, enabling Google signals, linking Google Ads, linking AdSupport.framework for IDFA, or logging personal data inside custom event parameters all expand what you must disclose.
Copy-paste privacy policy clause for Google Analytics for Firebase
Analytics. We use Google Analytics for Firebase, a service provided by
Google LLC, to understand how our app is used. The SDK collects an
app-instance identifier, in-app events and screen views, in-app purchase
events, device and operating-system attributes, and a coarse location
(country, region, city) that Google derives from an IP address it does
not retain. Google processes this data as our processor to provide
analytics reporting. If we enable Google signals or advertising
features, Google may also use this data as an independent controller for
advertising and to improve its own services, and that use constitutes
cross-app tracking. We do not sell this data. Learn more at
https://firebase.google.com/support/privacy and
https://policies.google.com/privacy.Adapt this: delete the Google signals sentence if you never enable advertising features, and add any custom event parameters that carry personal data. You are responsible for making sure the wording matches what your build actually does; this text is a starting point, not legal advice.
App Store "App Privacy" label answers
In App Store Connect, a default Firebase Analytics integration typically requires you to declare:
- Identifiers > Device ID — purpose "Analytics", not linked to the user, not used to track (unless you enable Google signals or IDFA, then linked and used to track).
- Usage Data > Product Interaction — purpose "Analytics", not linked to the user, not used to track.
- Purchases > Purchase History — purpose "Analytics", not linked, not used to track (only if you log purchase events).
- Diagnostics > Crash Data and Performance Data — only if Crashlytics runs alongside Analytics.
- General location is reported by Google under "Coarse Location" for Data Safety but Apple has no coarse-location bucket, so IP-derived city is generally not declared as Location on the App Store as long as you do not use Core Location.
If you set a User ID or enable Google signals, switch Device ID and Product Interaction to "Linked to the user" and "Used to track you", and present an ATT prompt.
Google Play Data Safety answers
For a standard Firebase Analytics setup, declare in the Play Console Data Safety form:
- Device or other IDs — Collected: Yes. Shared: No (Yes if advertising features are on). Purpose: Analytics. Not processed ephemerally.
- App activity > App interactions, plus Page views and taps in app and Other user-generated content if applicable — Collected: Yes. Shared: No. Purpose: Analytics.
- App info and performance > Crash logs and Diagnostics — only with Crashlytics. Collected: Yes. Shared: No. Purpose: Analytics.
- Location > Approximate location — Google's own guidance lists this because Analytics derives coarse location from IP. Collected: Yes. Shared: No. Purpose: Analytics.
- App activity > In-app purchase history — only if you log purchase events.
Users can request deletion of their data; Firebase provides a deletion API keyed on the app-instance ID, and you should mention that route in your policy.
Google Analytics for Firebase-specific gotchas
- Google signals flips everything. Turning it on in the GA4 property (not in code) converts Analytics into cross-device, cross-app tracking — you then owe an ATT prompt and "Used to track you" labels even though nothing changed in your app binary.
- IDFA is opt-in via linking, not code. The SDK collects the IDFA only if AdSupport.framework is present in the build; many teams pull it in transitively through an ads SDK without realizing it.
- Consent Mode must be wired up. The SDK keeps collecting an app-instance ID until you call the Consent API with
analyticsStoragedenied; there is no automatic EEA gate. - Custom parameters are your liability. Anything you pass into
logEvent(emails, user IDs, free text) is stored by Google and must be disclosed — Google's "no raw IP" promise does not cover data you put in yourself. - The latest SDK ships no privacy manifest. Google states current Firebase Analytics is not subject to Apple's privacy-manifest rule, so Xcode will not aggregate its data types for you — fill the label in manually. The iOS SDK also registers for SKAdNetwork attribution on first open unless you set the opt-out flag.
Related
See the sibling clauses for Mixpanel, Amplitude, PostHog and Segment. For the full document, use the privacy policy page generator, and for the wider Firebase picture (Crashlytics, Cloud Messaging, Auth) read the Firebase privacy policy generator guide.