Firebase Analytics und DSGVO 2026: Was für App-Daten gilt

Was Firebase im Hintergrund eigentlich macht

Eine neue App ist geplant, das Dev-Team sagt „Firebase nehmen wir, ist Standard“, und drei Monate später steht die App im Store. Tracking läuft, Conversions sind sichtbar, alle sind zufrieden. Bis jemand fragt: „Sind wir damit eigentlich DSGVO-konform?“

An dieser Stelle wird es interessant. Denn die ehrliche Antwort lautet: aus den Standardeinstellungen heraus eher nicht. Aus den richtigen Einstellungen heraus, ja. Und der Unterschied zwischen „eher nicht“ und „ja“ sind ungefähr fünf Schalter, ein Vertrag und eine Consent-Logik.

Firebase lässt sich gut mit einem Auto vergleichen, das man beim Händler abholt. Es hat alles eingebaut. Klimaanlage, Airbags, Bordcomputer. Beim Verlassen des Hofs sind viele Komfort-Features aber auf „voll an“ voreingestellt. Auch solche, die auf europäischen Straßen rechtlich nicht so gebraucht werden. Wer die Voreinstellungen nicht kennt, fährt mit unnötig vielen aktivierten Funktionen los.

In einer App, die wir vor zwei Jahren übernommen haben, war Firebase mit Standardeinstellungen aktiviert: IP-Logging an, Werbe-Identifier wurden vor Consent gesendet, automatische Datenspeicherung auf 14 Monate. Die App lief seit Launch, niemand hatte die Defaults angerührt.

Hier sind die fünf Dinge, die anzupassen sind.

1. Google DPA abschließen, bevor irgendwas live geht

Ohne abgeschlossenes Data Processing Agreement (Auftragsverarbeitungsvertrag) zwischen dem nutzenden Unternehmen und Google ist die Verarbeitung personenbezogener Daten durch Firebase rechtlich nicht abgedeckt. Punkt.

Das DPA ist in der Google Cloud Console verfügbar und kostet nichts. Es muss aber aktiv akzeptiert werden, nicht „ist schon da, weil wir Google nutzen“. Wer das DPA nicht in den Unterlagen liegen hat, hat es nicht.

Wo der Fehler typisch entsteht: Das Dev-Team setzt Firebase auf, lädt die App in den Store, alles läuft. Niemand klickt durch die Cloud-Console-Admin-Section. Sechs Monate später kommt eine Datenschutz-Anfrage. Das DPA muss nachträglich besorgt werden, peinlich aber lösbar, und schwieriger wird es bei Apps mit Gesundheitsdaten, wo die Aufsicht das früher fragt.

2. EU Data Routing & automatische IP-Anonymisierung

Die 2022er-Empfehlung „IP-Anonymisierung aktivieren“ ist 2026 obsolet. Firebase Analytics droppt das letzte Oktett der IP-Adresse automatisch, bevor irgendwas geloggt wird. Der Schalter, den ältere Anleitungen empfehlen, existiert in der UI nicht mehr; es gibt nichts mehr zu aktivieren.

Echte Hausaufgabe 2026: EU Data Routing prüfen. Das ist die Region, in der Firebase die Analytics-Daten verarbeitet, und sie ist nicht automatisch EU. Bei vor 2023 angelegten Projekten ist die Default-Region oft us-central1 oder nam5. App-Daten fließen dann durch US-Infrastruktur. Mit allen Folgefragen aus Schrems II.

So wird das geprüft und (wenn nötig) korrigiert:

1. Firebase Console → Project Settings → General. Unter „Default GCP resource location“ steht die Region. Sollte auf einer EU-Region stehen, europe-west1 (Belgien), europe-west3 (Frankfurt) oder eu-multi-region.
2. Google Analytics 4 → Admin → Property Settings → Data Settings → Data Collection. Sicherstellen, dass „Google Signals“ für EU-Nutzer entweder deaktiviert ist oder klar einwilligungspflichtig im Consent-Layer abgedeckt wird.
3. Wichtig: die Default-Region in Firebase lässt sich nicht nachträglich ändern, wer in einer falschen Region ist, muss neu anlegen + Daten migrieren. Vor Launch festzurren, nicht nachträglich versuchen.

Hintergrund: IP-Anonymisierung allein reicht 2026 nicht mehr als Nachweis. Aufsichtsbehörden fragen direkt nach der Verarbeitungs-Region und nach den Transfer-Tools (Standardvertragsklauseln, EU-US-Data-Privacy-Framework-Status). Die Region steht damit am Anfang der Compliance-Kette.

3. Werbe-Identifier (IDFA / AAID) erst nach Consent senden

Auf iOS heißt der Werbe-Identifier IDFA, auf Android AAID. Beide sind eindeutige Geräte-IDs, mit denen Werbeplattformen Nutzer plattformübergreifend wiedererkennen.

Apple zwingt seit iOS 14.5 zum App Tracking Transparency-Dialog vor jeder IDFA-Nutzung. Android hat seit 13 ähnliche Restriktionen. Aber: Firebase versucht standardmäßig, diese Identifier zu lesen, sobald die App startet, auch bevor der Nutzer eingewilligt hat.

Notwendig: ein Consent-Layer in der App, der erst nach expliziter Einwilligung das „Werbe-ID-Tracking aktiviert“-Signal an Firebase gibt. In iOS via Firebase.app().setAutomaticScreenReportingEnabled(false) plus IDFA-Request nach AppTrackingTransparency-Antwort. In Android entsprechend über die Firebase Analytics Consent Mode Integration.

In einem App-Audit fanden wir, dass Firebase die IDFA bereits vier Sekunden vor dem Consent-Dialog gelesen hatte. Vier Sekunden klingen wenig, sind aber eine klare Compliance-Lücke, die jeder Datenschutz-Test sofort findet.

Der iOS-Doppel-Consent ist 2026 der Klassiker. In Europa verlangt das GDPR ein Cookie-/Tracking-Banner, das vor dem Datentransfer abgefragt wird. Apple verlangt separat den ATT-Prompt vor der IDFA-Nutzung. Keiner der beiden ersetzt den anderen, beide müssen sauber implementiert sein, und der ATT-Prompt darf erst gefeuert werden, nachdem der User im GDPR-Banner Werbe-Consent erteilt hat. Sonst greift die ATT-Antwort ins Leere.

4. Datenspeicherung auf das Minimum reduzieren

Firebase speichert standardmäßig Event-Daten 14 Monate lang. Für die meisten Apps ist das deutlich länger als rechtlich nötig oder geschäftlich sinnvoll.

Art. 5(1)(e) DSGVO nennt keine Monatszahl. Die Speicherdauer muss zum dokumentierten Zweck passen, und der 14-Monats-Default ist bei kaum einer App durch diesen Zweck gedeckt. Für Conversion-Tracking und Funnel-Analyse kommen die meisten Apps mit 2 Monaten aus. Längere Customer-Lifecycles, etwa SaaS mit jährlicher Abrechnung, rechtfertigen auch 14 Monate. Entscheidend ist die dokumentierte Begründung, nicht die Zahl.

Einstellbar im Google Analytics Property unter Admin → Data Settings → Data Retention. Auf den niedrigsten Wert stellen, der für die internen Auswertungen ausreicht.

Nebeneffekt: weniger gespeicherte Daten = weniger Risiko bei Datenschutz-Anfragen, weniger Compliance-Aufwand bei Audits.

5. Consent Mode v2 in der App korrekt implementieren. 2026 DMA-Pflicht

Das ist der schwierigste der fünf Punkte. Und 2026 der mit dem höchsten Strafrisiko. Seit der vollen DMA-Durchsetzung erzwingt Google den Consent-Mode-v2-Status für alle EU-Nutzer, konkret: ad_user_data und ad_personalization müssen explizit gesetzt sein, sonst werden Google-Ads-Audiences in der EU schlicht nicht mehr befüllt. Aus Marketing-Sicht heißt das: ohne korrekten Consent Mode v2 verliert das Performance-Marketing einen zweistelligen Prozentsatz an aktiver Audience-Größe.

In der Web-Welt geht das über GTM. In der App-Welt direkt über das Firebase SDK. Konzept: an Firebase wird vor dem ersten Event-Call eine Information gesendet, welche Consent-Kategorien gerade aktiv sind (analytics_storage, ad_storage, ad_user_data, ad_personalization). Firebase modelliert dann auf Basis dieser Signale.

Die exakte Syntax pro Plattform, iOS, Android, Flutter, sieht ähnlich aus, aber unterscheidet sich. Das interaktive Beispiel unten zeigt alle drei nebeneinander:

// 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
])

Was schiefgeht, wenn dieser Layer fehlt: Firebase loggt Events ungefiltert, das CMP-System der App zeigt korrekt „User hat abgelehnt“, aber Daten wurden trotzdem gesendet. Aus DSGVO-Sicht ein Bruch zwischen UI-Zusage und technischer Realität. Aus DMA-Sicht ein direkter Verstoß gegen Googles eigene Plattformanforderungen, und damit das Risiko, dass Google-Ads-Audiences plattformseitig ausgeknipst werden.

Sonderfall: Health-Apps unter Art. 9 DSGVO

Wenn eine App Gesundheitsdaten verarbeitet, auch indirekte wie Schlaf-Phasen, Fitness-Werte, Medikations-Erinnerungen, gilt Artikel 9 DSGVO. Das ist eine eigene Kategorie. Standard-Anonymisierung reicht nicht, Standard-Consent reicht nicht.

Welche Datentypen wo kippen, das Risiko-Radar unten zeigt es interaktiv:

Was zusätzlich nötig wird:

• Explizite Einwilligung, nicht „Ja, ich akzeptiere die AGB“, sondern eine separate, klar formulierte Zustimmung speziell zur Verarbeitung von Gesundheitsdaten.
• Pseudonymisierung statt nur Anonymisierung. Daten werden nicht nur „anonym“ gespeichert, sondern aktiv mit einem Pseudonym verknüpft, das im Bedarfsfall auch zur Löschung benutzt werden kann.
• Datenflusskontrolle, wo geht die Information hin? Bleibt sie in der EU? Wird sie an Drittparteien übermittelt? Bei Gesundheitsdaten muss das in der Datenschutz-Folgeabschätzung detailliert dokumentiert sein.

Bei einer MedTech-App, die wir betreuen, läuft Firebase mit minimalem Event-Set, vollständigem Consent-Mode-Setup und expliziter Pseudonymisierung. Die App ist im Apple Health-Ökosystem aktiv und musste bei der Markteinführung in zwei EU-Ländern eine Datenschutz-Folgeabschätzung vorlegen, ohne das Setup oben wäre das nicht durchgegangen.

Konkrete Schritte

Wer gerade eine App plant oder eine bestehende mit Firebase betreut, drei Schritte, die vor dem nächsten Sprint anstehen:

• DPA + EU-Region prüfen. In der Google Cloud Console nachsehen, ob das DPA akzeptiert ist und das Firebase-Projekt in einer EU-Region läuft. Wenn nicht in EU-Region: Migration planen, geht nicht inplace.
• Defaults prüfen. Speicherdauer am dokumentierten Zweck ausgerichtet (für die meisten Apps reichen 2 Monate), Werbe-ID-Verhalten dokumentiert, Consent-Mode-v2-Defaults gesetzt.
• Consent-Layer testen. Bevor der erste Event ans Backend geht, passt die Consent-Information dazu? Im QA-Test einen „Ablehnen“-Klick durchspielen und prüfen, ob trotzdem Events gefeuert werden. Bei iOS zusätzlich den ATT-Doppel-Consent durchspielen.

Wenn ein Setup an einer dieser Stellen wackelt, ist ein externer Audit der schnellste Weg zur Klarheit. Wir machen das regelmäßig für App-Anbieter, speziell bei Gesundheits- oder Finanz-Apps, wo Art. 9 DSGVO greift. Mehr zur Methodik gibt es auf der Measurement & Privacy Engineering Service-Seite.