Google Play Data-Safety-Formular: der komplette Leitfaden

Das Data-safety-Formular ist ein Fragebogen, den Sie für jede bei Google Play hochgeladene App ausfüllen müssen; darin geben Sie an, welche Datentypen Ihre App erfasst, wofür, und ob diese Daten mit Dritten geteilt werden. In Play Console finden Sie es unter Policy > App content > Data safety, nachdem Sie Ihre App ausgewählt haben.

Dieses Formular speist den Abschnitt „Data safety", den Nutzer auf Ihrem Store-Eintrag sehen; jeder von Ihnen deklarierte Punkt wird Teil einer Liste, die potenzielle Nutzer vor der Installation sehen. Das Formular ersetzt nicht die separat erforderliche URL zur Datenschutzerklärung — beides muss vollständig sein.

Ohne ausgefülltes Formular erreichen Sie keine Produktion; ein leer gelassener oder nie geöffneter Data-safety-Abschnitt erscheint als blockierende Warnung im Veröffentlichungsablauf.

Das Formular fragt entlang zweier getrennter Achsen: Datenerfassung und Datenweitergabe. Gemäß Googles offizieller Definition bedeutet Erfassung, dass Daten vom Gerät des Nutzers übertragen werden — durch Ihre App oder ein von ihr verwendetes SDK; Daten, die nur auf dem Gerät verarbeitet und niemals irgendwohin gesendet werden (ephemere, geräteinterne Verarbeitung), gelten nicht als Erfassung und müssen nicht deklariert werden. Weitergabe bedeutet, dass erfasste Nutzerdaten an einen Dritten übertragen werden (ein Werbenetzwerk, ein Analytics-Anbieter) — unabhängig vom ursprünglichen Erfassungszweck zählt die Übertragung an einen Dritten als Weitergabe. Beides ist nicht dasselbe, und das Formular lässt Sie beides getrennt ankreuzen.

Ein Werbe-SDK, das beispielsweise die Advertising ID zur Anzeigenpersonalisierung abruft und an seine eigenen Server sendet, zählt sowohl als Erfassung als auch als Weitergabe: Das SDK überträgt die Daten vom Gerät weg (Erfassung), und diese Daten werden auf den eigenen Servern des Werbenetzwerks verarbeitet (Weitergabe). Dagegen zählen Daten, die nur an Ihr eigenes Backend gesendet werden (einen Server, den Sie selbst betreiben, kein Dritter), als Erfassung, aber nicht als Weitergabe, da kein Dritter beteiligt ist. Daten, die das Gerät überhaupt nie verlassen — nur lokal gespeichert, etwa eine Design- oder Sprachpräferenz, die die App lokal merkt — zählen gar nicht erst als Erfassung; nach Googles offizieller Definition muss diese Art von Daten im Formular überhaupt nicht deklariert werden.

Für jeden Datentyp fragt das Formular außerdem nach dem Zweck (App-Funktionalität, Analyse, Werbung/Marketing, Betrugsprävention, Personalisierung und Ähnliches), ob er optional ist, und ob er bei der Übertragung verschlüsselt wird. Diese Felder nicht mit dem tatsächlichen Verhalten Ihres SDKs abzugleichen, ist die häufigste Ursache für gemeldete Inkonsistenzen.

Wenn Sie AdMob verwenden, müssen Sie deklarieren, dass die Advertising ID erfasst und zur Anzeigenpersonalisierung genutzt wird; AdMob kann außerdem den ungefähren Standort sowie Geräte-/App-Informationen zur Anzeigenauslieferung und Betrugsprävention verarbeiten. Diese Deklaration verlangen AdMobs eigene Publisher-Richtlinien von Entwicklern — sie zu überspringen, verursacht Probleme sowohl bei der Play-Prüfung als auch in der AdMob-Konsole.

Wenn Sie Firebase Analytics verwenden, müssen Sie ankreuzen, dass App-Interaktionen und Nutzungsdaten zu Analysezwecken erfasst werden. Wenn Sie Firebase Crashlytics verwenden, müssen Sie separat deklarieren, dass Absturzprotokolle, Geräte-Kennungen und Diagnosedaten erfasst werden — Crashlytics in dieselbe Zeile wie Analytics zu packen, kann als Unterdeklaration gelten, da es sich um separate SDKs handelt, die eigene Zeilen im Formular verdienen.

Wenn Ihre App unabhängig von jedem SDK eigene Daten erfasst — Anmelde-E-Mail oder -Telefonnummer, Zahlungsdaten, Standortberechtigung — deklarieren Sie diese ebenfalls separat. Der jeweilige Dokumentationsabschnitt jedes SDKs zu Data-Safety-/Datenschutzangaben ist beim Ausfüllen des Formulars die zuverlässigste Referenz; diese können sich zwischen SDK-Versionen ändern.

Ihre Data-safety-Angaben und der Text Ihrer Datenschutzerklärung müssen zueinander passen. Im Formular „Advertising ID erfasst" anzukreuzen, während Ihre Richtlinie AdMob nie erwähnt — oder umgekehrt — kann bei der Prüfung als Inkonsistenz markiert werden und im schlimmsten Fall einen Prozess auslösen, der zur Sperrung der App führt.

Der praktische Ansatz: Listen Sie zunächst jedes verwendete SDK und was es jeweils erfasst; übertragen Sie diese Liste dann mit demselben Detailgrad sowohl in das Data-safety-Formular als auch in Ihre Datenschutzerklärung. Wann immer Sie der App ein neues SDK oder eine neue Berechtigung hinzufügen, beseitigt die gleichzeitige Aktualisierung beider Dokumente im selben Release das meiste Risiko einer späteren Inkonsistenz.

Das häufigste Problem ist die Unterdeklaration: Die App erfasst über ein SDK Daten, aber das Formular spiegelt dies nie wider. Das passiert meist, wenn das Formular nach Integration eines SDKs nicht aktualisiert wird, und kann bei Plays automatisierter oder manueller Prüfung als Inkonsistenz erkannt werden.

Zweitens eine URL zur Datenschutzerklärung, die leer, nicht erreichbar ist oder Text enthält, der den Angaben des Formulars widerspricht; diese Diskrepanz ist ein eigenständiger Ablehnungsgrund und kann unabhängig vom Data-safety-Formular selbst gemeldet werden.

Drittens: das Formular nach inhaltlichen Änderungen nicht erneut zu prüfen: Das Hinzufügen eines neuen SDKs, einer neuen Berechtigung (etwa Standort) oder einer neuen Drittanbieter-Integration ohne Aktualisierung des Formulars lässt die bestehende Deklaration mit dem tatsächlichen Verhalten der App aus dem Takt geraten. Google kann Releases hierauf regelmäßig neu bewerten.