Die URL zur Kontolöschung, die Google Play verlangt
Die Play Console verlangt eine öffentliche Web-URL unter App content → Data deletion. Was diese Seite Nutzern ohne Anmeldung ermöglichen muss, und die Fehler, wegen derer eine Einreichung zurückkommt.
Google Play verlangt von Apps mit Konten zwei Wege zur Löschung: einen in der App und eine öffentliche Web-URL, über die dieselbe Anfrage ohne Anmeldung und ohne Neuinstallation gestellt werden kann. Die Web-URL geben Sie unter App content → Data deletion an. Die Seite nimmt die Anfrage entgegen; die Daten in Ihren eigenen Systemen zu löschen, bleibt Ihre Aufgabe.
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.
Wenn man in Ihrer App ein Konto anlegen kann, verlangt Google Play zwei Wege, es zu löschen: einen in der App und eine öffentlich erreichbare Web-URL, über die dieselbe Anfrage gestellt werden kann. Die Web-URL geben Sie in der Play Console unter App content → Data deletion an, und die Google Play-Hilfe sagt, dass sie “must be functional (for example, loads without error), relevant in scope” (Übersetzung: „funktionsfähig sein muss (zum Beispiel ohne Fehler lädt) und inhaltlich relevant“). Wer die App bereits deinstalliert hat, muss sie nutzen können.
Das ist die Anforderung in einem Absatz. Der Rest dieser Seite behandelt, was die Seite selbst leisten muss, und die Fehler, wegen derer eine Einreichung zurückkommt.
Hier werden zwei Dinge verlangt, die leicht zu verwechseln sind:
- Eine öffentliche Seite, über die eine Anfrage gestellt werden kann.
- Das tatsächliche Löschen der Daten in Ihren eigenen Systemen, wenn eine Anfrage eingeht.
Das Erste ist ein Hosting-Problem. Das Zweite ist allein Ihre Sache, und kein Dienst kann es für Sie erledigen – wer etwas anderes behauptet, hat keinen Zugriff auf Ihre Datenbank.
Was die Seite Nutzern ermöglichen muss
Die Anforderung ist aus Sicht der Nutzer formuliert, also lesen Sie sie auch so. Wer Ihre App deinstalliert, sein Passwort vergessen oder nie eines gehabt hat, muss die Seite trotzdem erreichen und Sie bitten können, sein Konto zu löschen.
Das schließt einige verbreitete Lösungen aus:
- Eine Seite hinter einem Login. Wenn man sich anmelden muss, um die Löschung zu verlangen, können genau die Menschen, die sie am ehesten brauchen, sie nicht nutzen.
- Nur ein Weg in der App. Der Weg in der App ist ebenfalls Pflicht, ersetzt aber die Web-URL nicht: Diese ist über den Store-Eintrag erreichbar, auch für jemanden, der die App nicht mehr hat.
- Eine URL, die 404 liefert. Das ist der Fehler, der tatsächlich auffällt, weil er trivial zu prüfen ist.
Die Seite sollte sagen, welche Daten gelöscht werden, welche aufbewahrt werden und wie lange (Abrechnungsdaten müssen oft gesetzlich aufbewahrt werden), und wie lange die Löschung dauert.
Der Teil, der oft schiefgeht: die Anfrage empfangen
Eine Seite, die ein Formular anzeigt, reicht allein nicht – die Anfrage muss Sie auch erreichen.
Das ist der eine Teil, den ein reiner Datei-Host allein nicht leisten kann. GitHub Pages, ein Bucket hinter einem CDN: Sie liefern Dateien aus, einen POST können sie nicht annehmen. Die meisten Hosts, die ein Entwickler tatsächlich wählen würde, lösen das – Cloudflare Workers, Funktionen bei Netlify und Vercel, Netlify Forms –, es ist also eine Verdrahtungsaufgabe, keine Mauer. Aber irgendetwas muss die Anfrage empfangen, und der übliche Selbstbau endet an einem von vier Orten:
- eine auf der Seite abgedruckte E-Mail-Adresse, und nichts verhindert, dass sie abgegriffen wird;
- ein Formulardienst eines Drittanbieters, der nun die E-Mail-Adressen Ihrer Nutzer sieht;
- eine Edge-Funktion auf Ihrem Host, nur ein paar Zeilen, aber nun Code, den Sie für jede App pflegen;
- ein kleiner Server, den Sie für vielleicht zwei Anfragen im Jahr am Laufen halten müssen.
Was auch immer Sie wählen, entscheiden Sie es bewusst. Eine Löschseite, die Anfragen stillschweigend verwirft, ist schlimmer als gar keine: Sie sagen Nutzern, ihre Anfrage sei angekommen.
Ein Protokoll führen
Was auch immer Sie bauen, protokollieren Sie die Anfragen: die Adresse, das Datum, was Sie unternommen haben. Wenn eine Aufsichtsbehörde oder ein Store je nachfragt, ist „wir haben es gelöscht“ eine Behauptung, und eine datierte Liste ist ein Beleg.
Was AppFoyer hier tut
Wir hosten die Seite und leiten die Anfrage weiter. Nutzer reichen sie ein, wir speichern sie als Ihr Prüfprotokoll und benachrichtigen Sie – per E-Mail in jedem Tarif, oder per Telegram oder Slack in einem bezahlten. Die Löschung führen Sie in Ihren eigenen Systemen durch – wir haben keinen Zugriff darauf und behaupten das auch nie.
Diese Seite bleibt online, auch wenn Sie uns nicht mehr bezahlen, denn Ihre Nutzer hatten damit nichts zu tun.
Die maßgebliche Quelle
- Provide information about data deletion – Google Play-Hilfe. Lesen Sie sie vor dem Einreichen; diese Seite entscheidet, nicht unsere.