Firebase Analytics and GDPR 2026: What Applies to App Data

What Firebase actually does in the background

A new app is planned, the dev team says "we'll use Firebase, it's standard", and three months later the app is in the store. Tracking is live, conversions are visible, everyone's happy. Until someone asks: "Are we actually GDPR-compliant with this?"

That's where it gets interesting. The honest answer: from the default settings, probably not. From the right settings, yes. And the difference between "probably not" and "yes" is roughly five switches, a contract, and consent logic.

Firebase is like a car you pick up from the dealer. Everything built in. Climate, airbags, on-board computer. When you drive off the lot, many of the comfort features are preset to "full on", including some that aren't really needed on European roads in legal terms. Don't know the presets, and you drive off with unnecessary active features.

With a MedTech app we took over two years ago, Firebase was running with default settings: IP logging on, ad identifiers were sent before consent, automatic data retention at 14 months. The app had been running since launch, nobody had touched the defaults.

Here are the five things to adjust.

1. Sign the Google DPA, before anything goes live

Without a signed Data Processing Agreement between your company and Google, the processing of personal data through Firebase isn't legally covered. Full stop.

The DPA is available in the Google Cloud Console and costs nothing. But it has to be actively accepted, not "it's already there because we use Google". If you don't have the DPA in your documentation, you don't have it.

Where the error typically arises: the dev team sets up Firebase, uploads the app to the store, everything runs. Nobody clicks through the Cloud Console admin section. Six months later a data-protection request arrives. The DPA has to be obtained retroactively, embarrassing but solvable, and it gets harder with apps that handle health data, where regulators ask about it earlier.

2. EU data routing & automatic IP anonymisation

The 2022 advice "activate IP anonymisation" is obsolete in 2026. Firebase Analytics drops the last octet of the IP address automatically, before anything is logged. The switch that older guides recommend no longer exists in the UI; there's nothing to activate.

Actual 2026 homework: verify EU data routing. That's the region Firebase processes analytics data in, and it isn't automatically EU. For projects created before 2023 the default region is often us-central1 or nam5. App data then flows through US infrastructure. With all the Schrems II follow-up questions.

Here's how to check and (if needed) fix it:

1. Firebase Console → Project Settings → General. Under "Default GCP resource location", the region is shown. It should be set to an EU region, europe-west1 (Belgium), europe-west3 (Frankfurt), or eu-multi-region.
2. Google Analytics 4 → Admin → Property Settings → Data Settings → Data Collection. Make sure "Google Signals" for EU users is either disabled or clearly covered in the consent layer as consent-required.
3. Important: the default region in Firebase cannot be changed retroactively, if you're in the wrong region, you need to recreate the project + migrate data. Lock it in before launch, don't try to fix it later.

Background: IP anonymisation alone isn't enough as proof in 2026. Regulators ask directly about the processing region and the transfer tools (Standard Contractual Clauses, EU-US Data Privacy Framework status). Region sits at the start of the compliance chain.

3. Send advertising identifiers (IDFA / AAID) only after consent

On iOS the advertising identifier is the IDFA, on Android the AAID. Both are unique device IDs that ad platforms use to recognise users across apps.

Apple has required the App Tracking Transparency dialog before any IDFA use since iOS 14.5. Android has had similar restrictions since 13. But: Firebase tries to read these identifiers by default as soon as the app starts, even before the user has consented.

Required: a consent layer in the app that only fires the "ad ID tracking enabled" signal to Firebase after explicit consent. On iOS via Firebase.app().setAutomaticScreenReportingEnabled(false) plus an IDFA request after the AppTrackingTransparency answer. On Android via the Firebase Analytics Consent Mode integration.

In a retail app we integrated with OneTrust, the audit revealed that Firebase had already read the IDFA 4 seconds before the consent dialog appeared. Four seconds sounds small, but it's a clear compliance gap that any data-protection test catches immediately.

The iOS dual consent is the 2026 classic. In Europe, the GDPR requires a cookie/tracking banner before any data transfer. Apple separately requires the ATT prompt before IDFA use. Neither replaces the other, both have to be implemented cleanly, and the ATT prompt should only fire after the user has granted ads consent in the GDPR banner. Otherwise the ATT answer lands in a void.

4. Reduce data retention to the minimum

Firebase stores event data for 14 months by default. For most apps that's much longer than legally necessary or business-relevant.

GDPR-aligned: 2 months for most use cases (conversion tracking, funnel analysis). For apps with longer customer-lifecycle requirements (e.g. SaaS with annual billing) up to 14 months is justifiable, but with a reason, not just inertia.

Configurable in the Google Analytics property under Admin → Data Settings → Data Retention. Set to the lowest value that still serves your internal analyses.

Side effect: less stored data = lower risk on data-protection requests, less compliance overhead in audits.

5. Implement Consent Mode v2 correctly in the app. DMA-mandated in 2026

This is the hardest of the five points. And in 2026 the one with the highest penalty risk. Since full DMA enforcement, Google enforces Consent Mode v2 status for all EU users, concretely: ad_user_data and ad_personalization have to be set explicitly, otherwise Google Ads audiences in the EU simply stop populating. For marketing this means: without correct Consent Mode v2 the active audience size drops by a double-digit percentage.

On the web this goes through GTM. In the app world it goes through the Firebase SDK directly. The concept: before the first event call, you tell Firebase which consent categories are currently active (analytics_storage, ad_storage, ad_user_data, ad_personalization). Firebase then models based on these signals.

The exact syntax per platform, iOS, Android, Flutter, looks similar but differs. The interactive example below shows all three side by side:

// iOS. Firebase Consent Mode v2 (Swift)
import FirebaseAnalytics

// Default-State VOR dem ersten Event setzen:
Analytics.setConsent([
  .analyticsStorage: .denied,
  .adStorage: .denied,
  .adUserData: .denied,
  .adPersonalization: .denied
])

// Nach CMP-Antwort:
Analytics.setConsent([
  .analyticsStorage: .granted,
  .adStorage: .granted,
  .adUserData: .granted,
  .adPersonalization: .granted
])

What goes wrong without this layer: Firebase logs events unfiltered, the CMP in the app correctly shows "user rejected", but data was sent anyway. From a GDPR view: a break between UI promise and technical reality. From a DMA view: a direct violation of Google's own platform requirements, and so the risk that Google-Ads audiences get switched off platform-side.

Special case: health apps under Art. 9 GDPR

If an app processes health data, including indirect data like sleep phases, fitness values, medication reminders. Article 9 GDPR applies. That's its own category. Standard anonymisation isn't enough, standard consent isn't enough.

Which data types tip where, the risk radar below shows it interactively:

What you also need:

• Explicit consent, not "Yes, I accept the T&Cs", but a separate, clearly worded consent specifically for the processing of health data.
• Pseudonymisation, not just anonymisation, data isn't just stored "anonymously" but actively linked with a pseudonym that can be used for deletion when needed.
• Data-flow control, where does the information go? Does it stay in the EU? Is it transferred to third parties? For health data this has to be documented in detail in the DPIA.

With a MedTech app we run, Firebase operates with a minimal event set, full Consent Mode setup, and explicit pseudonymisation. The app is active in the Apple Health ecosystem and had to submit a DPIA in two EU countries before launch, without the setup above it wouldn't have passed.

Concrete next steps

If you're planning an app or running one with Firebase, three steps before the next sprint:

• Check DPA + EU region. In the Google Cloud Console, verify the DPA is accepted and the Firebase project runs in an EU region. If not in EU region: plan a migration, you can't change it in place.
• Check defaults. Data retention configured sensibly (≤ 2 months for most apps), ad-ID behaviour documented, Consent Mode v2 defaults set.
• Test the consent layer. Before the first event hits the backend, does the consent information match? In QA, click "reject" and verify whether events are still sent. On iOS, also walk through the ATT dual consent.

If a setup wobbles at any of these points, an external audit is the fastest path to clarity. We do this regularly for app providers, especially health and finance apps where Art. 9 GDPR applies. More on the methodology on the Measurement & Privacy Engineering service page.

Need an outside view on your Firebase setup? Request an audit sprint →, from €1,500 · 2-week turnaround.