Die URL zur Datenschutzerklärung, die eine Android-App braucht
Wo die URL eingetragen wird, was die Erklärung abdecken muss und die SDK-Falle, in die Entwickler tappen, die sicher sind, dass ihre App nichts erhebt.
Beide Stores verlangen eine öffentlich erreichbare URL zur Datenschutzerklärung, die ohne Anmeldung lädt. Bei Google Play gehört sie unter App content → Privacy policy; bei Apple ist sie ein Feld in App Store Connect. Das Schwierige ist nicht die URL, sondern der Inhalt: Er muss abdecken, was jedes SDK in Ihrem Build erhebt.
Erledigen Sie das stattdessen in wenigen Minuten
AppFoyer hostet die Seiten, um die es in diesem Ratgeber geht – Datenschutzerklärung, Nutzungsbedingungen, Support, Kontolöschung und app-ads.txt –, auf einer eigenen Subdomain, ohne eigene Domain oder eigenen Server. Eine App ist kostenlos, und nichts, was ein Store verlangt, steht jemals hinter einer Bezahlschranke.
Geprüft am 19. September 2026. Store-Richtlinien ändern sich, manchmal ohne Ankündigung. Alles Folgende verlinkt die offizielle Dokumentation, und maßgeblich ist die dort verlinkte Seite, nicht diese hier. Widersprechen sich beide, hat der Store recht. Dieser Ratgeber ist aus dem Englischen übersetzt; Zitate aus der Store-Dokumentation bleiben im englischen Original.
Beide Stores wollen eine öffentlich erreichbare URL zu Ihrer Datenschutzerklärung, und beide prüfen sie. Die User-Data-Richtlinie von Google Play sagt es klar – „all apps must post a privacy policy link in the designated field within Play Console, and a privacy policy link or text within the app itself“ (alle Apps müssen einen Link zur Datenschutzerklärung im dafür vorgesehenen Feld in der Play Console sowie einen Link oder Text zur Datenschutzerklärung in der App selbst bereitstellen) –, und dieses Feld liegt unter App content → Privacy policy (App-Inhalte → Datenschutzerklärung). Auf der Apple-Seite ist es ein Pflichtfeld in App Store Connect. Die Seite muss ohne Anmeldung laden, Ihre App und Ihr Unternehmen nennen, beschreiben, was die App und alles darin erhebt, und auch Monate später noch funktionieren – ein Eintrag wird mehr als einmal geprüft.
Die Anforderung ist nicht schwer. Woran Leute scheitern, ist der dritte Punkt dieser Liste, und er ist den Rest dieser Seite wert.
„Aber meine App erhebt doch nichts“
Das ist die Annahme, die Leute eine Woche kostet.
Ihr Code erhebt vielleicht nichts. Ihre Abhängigkeiten tun es mit ziemlicher Sicherheit. Ein Crash-Reporter sendet Gerätekennungen und Stacktraces. Ein Analytics-SDK sendet Events und eine Werbe-ID. Ein Werbe-SDK sendet ziemlich viel. Eine Push-Bibliothek registriert ein Token, das per Definition an ein Gerät gebunden ist.
Die ehrliche Frage ist also nicht „Was erhebe ich?“, sondern „Was erhebt alles in meinem Build?“. Öffnen Sie Ihre Abhängigkeitsdatei und gehen Sie sie Zeile für Zeile durch – diese Liste ist die Substanz Ihrer Datenschutzerklärung, und genau sie vergleicht ein Prüfer mit Ihren Antworten im Data-safety-Formular.
Wo die beiden voneinander abweichen, glaubt der Store dem SDK.
Was die Erklärung abdecken muss
Mindestens, in einer Sprache, die ein Mensch lesen kann:
- Was erhoben wird – Kategorien, kein Datenbankschema.
- Warum – der Zweck jeder Kategorie.
- Wer es sonst noch sieht – nennen Sie die Drittanbieter. Hier gehört Ihre SDK-Liste hin.
- Wie lange es aufbewahrt wird.
- Wie man Sie erreicht und wie man die Löschung beantragt.
Wenn Sie Nutzer in der EU, im Vereinigten Königreich, in Kalifornien oder in Brasilien haben, erwartet jedes dieser Regelwerke bestimmte Angaben. Diese Seite kann Ihnen nicht sagen, welche davon für Sie gelten – das hängt wirklich von Ihren Nutzern und Ihrem Geschäft ab, und wenn an Ihrer App irgendetwas ungewöhnlich ist, ist es eine Stunde bei einem Anwalt wert.
Praktische Gründe für eine Ablehnung
- Eine URL, die eine Anmeldung verlangt, oder eine, die regional gesperrt ist.
- Ein PDF oder ein Google Doc. Manchmal akzeptiert, oft nicht, und es wirkt improvisiert.
- Eine Erklärung, die eine andere App oder ein anderes Unternehmen nennt – das verräterische Zeichen von Copy-and-paste. Prüfer bemerken es.
- Eine Erklärung, die Ihrem Data-safety-Formular widerspricht. Die beiden werden zusammen gelesen.
- Ein toter Link. Sechs Monate nach dem Launch gibt es den kostenlosen Host nicht mehr, den Sie benutzt haben.
Muss das Geld kosten?
Nein. Eine Datenschutzerklärung ist Text auf einer Seite; Geld kosten eine Domain, ein Ort zum Hosten, der nächstes Jahr noch da ist, und die Zeit, etwas zu schreiben, das zu Ihrer tatsächlichen App passt.
Seien Sie vorsichtig bei Generatoren, die pro App und Monat abrechnen. Was Sie mieten, ist eine Vorlage – prüfen Sie, was mit Ihrer URL passiert, wenn Sie nicht mehr zahlen. Denn eine Datenschutz-URL, die offline geht, während sie in einem aktiven Store-Eintrag steht, ist ein Problem, von dem Sie vom Store erfahren, nicht vom Anbieter.
Was AppFoyer hier tut
Wir generieren die Datenschutzerklärung aus den SDKs, die in Ihren Build-Dateien gefunden werden – mit einem Coding-Agent, der das Repository liest, oder aus einem kurzen Formular – und hosten sie auf einer eigenen Subdomain. Die Checkliste warnt Sie so lange, bis Sie den Platzhalter ersetzt haben, an dem Ihre Drittanbieter genannt werden, denn das ist der Teil, den ein Prüfer tatsächlich liest.
Die Vorlagen sind ein Ausgangspunkt, keine Rechtsberatung, und jede generierte Seite sagt das.
Die maßgeblichen Quellen
- User Data policy – Google Play-Hilfe. Das Zitat oben stammt von dieser Seite.
- Privacy policy requirements – Google Play-Hilfe, für die Lage des Felds
- App Store Review Guidelines, section 5.1 – Apple