Google-Play-Data-Safety-Angaben korrekt ausfüllen

1. Was das Data-Safety-Formular konkret verlangt

Das Data-Safety-Formular in der Play Console fragt für jede definierte Datenkategorie, etwa Standort, persönliche Informationen, Finanzdaten oder Geräte-IDs, ob die App diese Daten überhaupt erfasst, zu welchem Zweck sie genutzt werden und ob sie zusätzlich an Dritte weitergegeben werden. Jede dieser drei Fragen muss unabhängig voneinander für jede zutreffende Datenkategorie beantwortet werden.

Die Angaben werden anschließend direkt auf der öffentlichen Play-Store-Seite der App angezeigt, sichtbar für jeden potenziellen Nutzer noch vor dem Download. Damit sind sie nicht nur eine interne Compliance-Formalität, sondern ein Sichtbarkeitsfaktor, der die Installationsentscheidung datenschutzbewusster Nutzer direkt beeinflusst.

2. Warum Raten keine tragfähige Strategie ist

Viele Teams füllen das Formular basierend auf dem aus, was die App laut Produktbeschreibung tun soll, statt darauf, was der tatsächlich verbaute Code und die integrierten SDKs technisch wirklich erfassen. Diese Lücke entsteht typischerweise, weil Drittanbieter-SDKs wie Analytics-, Crash-Reporting- oder Werbebibliotheken eigenständig Daten sammeln, ohne dass dies im eigenen Anwendungscode explizit sichtbar wird.

Ein Werbe-SDK etwa kann im Hintergrund Geräte-Kennungen, ungefähren Standort und Nutzungsverhalten erfassen, ganz unabhängig davon, ob die App selbst diese Daten aktiv abfragt. Wer das Formular nur anhand der eigenen Feature-Liste ausfüllt, übersieht solche SDK-eigenen Datenerfassungen systematisch.

3. Eine systematische SDK-Inventur durchführen

Der zuverlässigste Ausgangspunkt ist eine vollständige Liste aller in package.json referenzierten Abhängigkeiten sowie aller nativen Pods und Gradle-Dependencies, ergänzt um eine Prüfung, welche davon tatsächlich Netzwerkanfragen an externe Server stellen. Jedes SDK mit Netzwerkzugriff verdient eine gezielte Prüfung seiner offiziellen Datenschutzdokumentation.

Für gängige SDKs wie Firebase Analytics, Sentry, AdMob oder Facebook SDK veröffentlichen die Hersteller meist eigene Data-Safety-Mapping-Dokumente, die genau auflisten, welche Datenkategorien im Play-Console-Formular für das jeweilige SDK anzukreuzen sind. Diese Dokumente ersetzen keine eigene Prüfung, liefern aber einen verlässlichen Ausgangspunkt statt einer reinen Vermutung.

# Netzwerk-relevante SDKs in einem React-Native-Projekt grob identifizieren
grep -E "analytics|crashlytics|sentry|admob|facebook|amplitude|mixpanel" \
  package.json ios/Podfile.lock android/app/build.gradle

# Native Netzwerk-Endpunkte in gebautem Android-Bundle grob aufspueren
grep -rE "https?://[a-zA-Z0-9.-]+" android/app/build/outputs/apk/release/ 2>/dev/null | sort -u

4. Datenkategorien korrekt zuordnen

Die Play Console unterscheidet unter anderem zwischen Standort, persönlichen Informationen, finanziellen Informationen, Nachrichten, Fotos und Videos, Audiodateien, Geräte-IDs sowie App-Aktivität. Innerhalb jeder Kategorie muss zusätzlich zwischen erfassten und lediglich verarbeiteten Daten unterschieden werden, was in der Praxis häufig zu Verwechslungen führt.

Ein Beispiel: Ein Foto-Upload-Feature, das ein Bild ausschließlich lokal verarbeitet und niemals an einen Server sendet, muss unter Fotos und Videos nicht als erfasst deklariert werden. Landet dasselbe Bild dagegen auch nur zwischenzeitlich auf einem Cloud-Speicher zur Analyse, etwa für eine KI-gestützte Bildbeschreibung, zählt das bereits als Erfassung im Sinne des Formulars.

5. Weitergabe an Dritte von reiner Verarbeitung unterscheiden

Google unterscheidet klar zwischen dem reinen Erfassen von Daten für den eigenen App-Betrieb und der Weitergabe dieser Daten an ein separates Unternehmen zu dessen eigenen Zwecken. Ein Cloud-Hosting-Anbieter, der Daten ausschließlich im Auftrag der App speichert, gilt in der Regel nicht als Weitergabe an Dritte im Sinne des Formulars, solange kein eigenständiger Nutzungszweck des Anbieters vorliegt.

Ein Werbenetzwerk oder ein Analytics-Anbieter, der erfasste Daten zusätzlich für eigene Zwecke wie Marktforschung oder eigene Produktverbesserung nutzt, zählt dagegen eindeutig als Weitergabe an Dritte und muss entsprechend im Formular als solche deklariert werden, unabhängig davon, ob dafür eine gesonderte vertragliche Vereinbarung besteht.

6. Besonderheiten bei React-Native- und Expo-Projekten

In React-Native-Projekten mit Expo lohnt sich zusätzlich ein Blick auf die Expo-eigenen Module und deren Berechtigungen in app.json beziehungsweise app.config.js, da Expo selbst je nach genutzten Modulen zusätzliche Datenkategorien wie Standort oder Kontakte technisch anfordern kann, auch ohne dass diese im eigenen Anwendungscode explizit angefragt werden.

Bei Bare-React-Native-Projekten mit manuell eingebundenen nativen Modulen ist die Prüfung aufwendiger, da jedes native Modul einzeln auf tatsächliche Datenerfassung geprüft werden muss, statt sich auf ein zentrales Konfigurationsformat wie app.json verlassen zu können. Eine vollständige Codesuche nach Berechtigungsanfragen in AndroidManifest.xml und Info.plist bleibt hier der zuverlässigste Ausgangspunkt.

7. Konsequenzen fehlerhafter Angaben

Google prüft Data-Safety-Angaben nicht nur einmalig bei der Einreichung, sondern gleicht sie stichprobenartig automatisiert gegen das tatsächliche Verhalten der App ab, unter anderem über eine Analyse der tatsächlichen Netzwerkkommunikation zur Laufzeit. Wird eine Diskrepanz festgestellt, folgt zunächst meist eine Aufforderung zur Korrektur mit gesetzter Frist, bei wiederholten oder gravierenden Verstößen jedoch eine Entfernung der App aus dem Store.

Über die unmittelbare Store-Konsequenz hinaus beschädigt eine später aufgedeckte Falschangabe das Vertrauen der Nutzer nachhaltig, insbesondere wenn Medien oder Datenschutzorganisationen die Diskrepanz öffentlich machen. Anders als eine technische Ablehnung lässt sich ein solcher Vertrauensverlust nicht einfach durch eine korrigierte Formular-Angabe rückgängig machen.

8. Data Safety als festen Bestandteil des Release-Prozesses etablieren

Da sich der SDK-Bestand einer App mit jedem Release ändern kann, sollte die Data-Safety-Prüfung kein einmaliges Ereignis bei der Erstveröffentlichung bleiben, sondern fester Bestandteil jedes Major-Release-Zyklus werden. Ein neu integriertes Analytics-SDK ohne begleitende Formular-Aktualisierung ist eine der häufigsten Ursachen für spätere Diskrepanzen.

In der Praxis bewährt sich eine kurze Checkliste im Release-Prozess, die bei jeder neuen oder aktualisierten Abhängigkeit mit Netzwerkzugriff explizit prüft, ob sich dadurch Änderungen an den Data-Safety-Angaben ergeben, statt diese Prüfung dem Zufall oder der Erinnerung einzelner Teammitglieder zu überlassen.

9. Häufige Fehlerquellen in der Praxis

Ein verbreiteter Fehler ist, ein SDK zwar korrekt in der Datenkategorie zu erfassen, aber den Zweck falsch anzugeben, etwa Analytics anzukreuzen, obwohl das SDK die Daten tatsächlich auch für personalisierte Werbung nutzt. Ein weiterer häufiger Fehler betrifft Push-Notification-Dienste, deren Geräte-Token-Erfassung regelmäßig übersehen wird, obwohl sie unter Geräte-IDs fällt.

Ebenfalls häufig übersehen wird, dass optionale Features wie ein Kamera-Upload oder eine Standortsuche selbst dann als Datenerfassung deklariert werden müssen, wenn nur ein kleiner Teil der Nutzer diese Funktion tatsächlich aktiv nutzt. Die Deklaration richtet sich nach der technischen Möglichkeit der Erfassung, nicht nach der tatsächlichen Nutzungshäufigkeit im Feld. Ein letzter, oft unterschätzter Punkt betrifft interne Test- und Debug-Builds: Auch wenn Tracking-SDKs dort nur zu Entwicklungszwecken aktiv sind, zählt das technisch als Datenerfassung und sollte konsequent in denselben Prüfprozess einfließen wie der produktive Release.

10. Zusammenfassung

11. FAQ: Google-Play-Data-Safety: Das Wichtigste auf einen Blick