Wenn Data-safety-Formular und Datenschutzerklärung sich widersprechen

Ihr Data-safety-Formular und Ihre Datenschutzerklärung sind zwei Beschreibungen derselben App, und die Stores lesen sie zusammen. Wenn sie sich widersprechen, ist der Widerspruch das Problem – nicht die Frage, welche von beiden gerade falsch ist. Google Play sagt es deutlich: “When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action.” (Übersetzung: „Wenn Google eine Abweichung zwischen dem Verhalten Ihrer App und Ihrer Angabe bemerkt, können wir geeignete Maßnahmen ergreifen, einschließlich Durchsetzungsmaßnahmen.“)

Apple hat dieselbe Struktur unter anderen Namen: die App-Privacy-Angaben auf Ihrer Produktseite und dazu die verpflichtende URL der Datenschutzerklärung.

Diese Seite handelt davon, beide im Gleichklang zu halten – und von der dritten Sache, an der beide gemessen werden: was Ihre App tatsächlich tut.

Die beiden Dokumente, kurz

Das Data-safety-Formular (Play Console → App content) und die App-Privacy-Angaben (App Store Connect) sind strukturierte Angaben: Kästchen und Kategorien, die in Ihrem Store-Eintrag als Zusammenfassung erscheinen, die Nutzer vor der Installation lesen. Sie sind Antworten auf einen festen Fragebogen.

Die Datenschutzerklärung ist Fließtext unter einer URL, die Sie hosten. Sie sagt dasselbe in Sätzen, dazu das, wofür ein Fragebogen kein Kästchen hat – Ihre Rechtsgrundlage, Speicherdauer, Ansprechpartner, wie man die Löschung verlangt.

Keines ersetzt das andere. Eine Erklärung füllt das Formular nicht aus, und ein ausgefülltes Formular bedeutet nicht, dass Ihre Erklärung stimmt.

Wo sie auseinanderlaufen

Sie werden Monate auseinander geschrieben. Die Erklärung entsteht in der Launch-Woche. Das Formular wird am Tag der Einreichung ausgefüllt, von jemandem, der eine Abhängigkeitsliste liest, und niemand schaut danach noch einmal in die Erklärung.

Ein neues SDK kommt dazu. Sie bauen in einem Sprint einen Crash-Reporter ein. Im Pull Request steht nichts zur Erklärung oder zum Formular, also ändert sich keines von beiden. Google Play sagt ausdrücklich, dass das zählt: Datenerhebung “includes data collected and handled through any third-party libraries or SDKs used in their apps… You must reflect data collection or sharing carried out by such third-party code in the Data safety form for your app.” (Übersetzung: „umfasst Daten, die über in den Apps verwendete Drittanbieter-Bibliotheken oder SDKs erhoben und verarbeitet werden … Sie müssen die Erhebung oder Weitergabe von Daten durch solchen Drittanbieter-Code im Data-safety-Formular Ihrer App abbilden.“) Apple verlangt dasselbe: “You need to identify all of the data you or your third-party partners collect.” (Übersetzung: „Sie müssen alle Daten angeben, die Sie oder Ihre Drittanbieter-Partner erheben.“)

Eine Funktion geht ohne ihre Angabe live. Standort für eine „In der Nähe finden“-Funktion, ein Empfehlungsprogramm, das eine Nutzer-ID mit einem Partner teilt. Die Entwicklungsarbeit ist sichtbar; die Arbeit an der Angabe steht auf niemandes Board.

Für eines von beiden wurde eine Vorlage verwendet. Eine generierte Erklärung, die Werbe-IDs für eine App ohne Werbung aufführt, ist ebenso ein Widerspruch wie eine Auslassung – und der leichter zu erkennende, weil sie einem Formular widerspricht, das Sie ehrlich ausgefüllt haben.

Abgleichen, in der einzigen Reihenfolge, die funktioniert

Beginnen Sie bei der App, nicht bei einem der Dokumente. Beide sollen die App beschreiben; das eine am anderen zu korrigieren, verschiebt den Fehler nur.

1. Öffnen Sie Ihre Abhängigkeitsdateien – build.gradle/libs.versions.toml, Podfile/Package.swift, pubspec.yaml, package.json. Listen Sie jedes Drittanbieter-SDK auf.
2. Notieren Sie für jedes, was es sendet. Ein Crash-Reporter sendet Gerätekennungen und Stacktraces. Ein Analytics-SDK sendet Events und oft eine Werbe-ID. Ein Werbe-SDK sendet noch einiges mehr. Eine Push-Bibliothek registriert ein Geräte-Token. Die Quelle dafür ist die eigene Datenschutzdokumentation des Anbieters.
3. Ergänzen Sie Ihre eigene Erhebung – Konten, Uploads, alles, was Ihr Backend speichert.
4. Prüfen Sie die Berechtigungen und Usage-Strings, die Sie deklarieren – eine zweite, unabhängige Liste dessen, worauf die App zugreifen kann: ACCESS_FINE_LOCATION, NSLocationWhenInUseUsageDescription, Kamera, Kontakte, Fotos.
5. Füllen Sie jetzt das Formular aus dieser Liste aus, und schreiben Sie die Erklärung aus derselben Liste neu. Sie sind am Ende stimmig, weil sie aus einer Quelle stammen – nicht, weil Sie sie miteinander verglichen haben.

Diese Liste, nicht das Formular, ist das, was aktuell bleiben muss. Beide Angaben leiten sich aus ihr ab.

Danach im Gleichklang halten

Die Angaben veralten unbemerkt, also muss die Prüfung an etwas hängen, das nicht unbemerkt bleibt. Google Play verlangt es: “Your Data safety form responses must remain accurate and complete at all times.” (Übersetzung: „Ihre Antworten im Data-safety-Formular müssen jederzeit korrekt und vollständig bleiben.“) Ebenso Apple: “You’re responsible for keeping your responses accurate and up to date.” (Übersetzung: „Sie sind dafür verantwortlich, Ihre Antworten korrekt und aktuell zu halten.“)

Die günstigste Variante, die funktioniert, ist eine Zeile in Ihrer Release-Checkliste – Hat sich in diesem Release eine Abhängigkeit geändert? Wenn ja, Erklärung und Formular neu prüfen –, denn eine geänderte Abhängigkeit ist genau das Ereignis, das beide ungültig macht.

Was diese Seite Ihnen nicht sagen kann

Welches konkrete Regelwerk für Sie gilt. DSGVO, UK GDPR, CCPA/CPRA, LGPD und Regeln zum Datenschutz von Kindern erwarten jeweils bestimmte Inhalte in der Erklärung, und welche davon gelten, hängt davon ab, wo Ihre Nutzer sind und was Ihre App tut. Wenn an Ihrer App etwas ungewöhnlich ist – Gesundheitsdaten, Kinder, alles, was Sie nur ungern in einem Satz erklären würden –, ist das eine Stunde bei einem Anwalt wert. Vorlagen, auch unsere, sind ein Ausgangspunkt, keine Rechtsberatung.

Was AppFoyer hier tut

Wir entwerfen die Datenschutzerklärung aus den SDKs, die in Ihren Build-Dateien gefunden werden – mit einem Coding-Agenten, der das Repository liest, oder über ein kurzes Formular –, sodass die Erklärung und die Antworten, die Sie den Stores geben, aus derselben Abhängigkeitsliste stammen statt aus dem Gedächtnis. Die Checkliste markiert die Seite so lange, bis der Platzhalter für Ihre Drittanbieter ersetzt ist, denn genau diesen Abschnitt vergleicht ein Prüfer mit Ihrem Formular.

Wir füllen das Data-safety-Formular nicht für Sie aus, und kein Dienst kann das: Es ist eine Angabe, die Sie in Ihrer eigenen Konsole abgeben, und Google Play sagt “you alone are responsible for making complete and accurate declarations.” (Übersetzung: „Sie allein sind dafür verantwortlich, vollständige und korrekte Angaben zu machen.“)

Die maßgeblichen Quellen

• Provide information for Google Play’s Data safety section – Google Play Console-Hilfe
• App privacy details on the App Store – Apple
• Privacy policy requirements – Google Play-Hilfe