Adres URL usuwania konta, o który prosi Google Play

Jeśli Twoja aplikacja pozwala zakładać konta, Google Play wymaga dwóch dróg do ich usunięcia: jednej w aplikacji i publicznie dostępnego adresu URL, pod którym można złożyć tę samą prośbę. Adres URL deklarujesz w Play Console w App content → Data deletion (Zawartość aplikacji → Usuwanie danych), a Pomoc Google Play mówi, że “must be functional (for example, loads without error), relevant in scope” (w tłumaczeniu: musi działać, na przykład ładować się bez błędów, i dotyczyć właściwego zakresu). Musi z niego móc skorzystać ktoś, kto już odinstalował aplikację.

To całe wymaganie w jednym akapicie. Reszta tego poradnika opisuje, co musi robić sama strona, i błędy, przez które zgłoszenie wraca do poprawki.

Chodzi tu o dwie rzeczy, które łatwo pomylić:

1. Publiczną stronę, na której można złożyć prośbę.
2. Faktyczne usunięcie danych we własnych systemach, gdy prośba dotrze.

Pierwsza to problem hostingu. Druga należy wyłącznie do Ciebie i żadna usługa nie zrobi jej za Ciebie. Każdy, kto twierdzi inaczej, nie ma dostępu do Twojej bazy danych.

Co strona musi umożliwić użytkownikowi

Wymaganie jest napisane z perspektywy użytkownika, więc czytaj je z tej strony. Ktoś, kto odinstalował Twoją aplikację, zapomniał hasła albo nigdy go nie miał, nadal powinien móc dotrzeć do strony i poprosić Cię o usunięcie konta.

To wyklucza kilka popularnych rozwiązań:

• Strona za logowaniem. Jeśli użytkownik musi się zalogować, by poprosić o usunięcie, to osoby, które najbardziej tego potrzebują, nie mogą z niej skorzystać.
• Tylko ścieżka w aplikacji. Droga w aplikacji też jest wymagana, ale nie zastępuje adresu URL: ten jest dostępny ze strony aplikacji w sklepie dla kogoś, kto nie ma już aplikacji.
• Adres URL, który zwraca 404. To właśnie ten błąd jest faktycznie wychwytywany, bo bardzo łatwo go sprawdzić.

Strona powinna mówić, jakie dane są usuwane, jakie są zachowywane i jak długo (dokumentację rozliczeniową często trzeba przechowywać z mocy prawa) oraz ile trwa usunięcie.

Część, którą ludzie robią źle: odbieranie prośby

Strona, która wyświetla formularz, sama w sobie nie wystarczy: prośba musi do Ciebie dotrzeć.

To jedyna część, której zwykły hosting plików nie zrobi sam. GitHub Pages, bucket za CDN: serwują pliki, nie przyjmą żądania POST. Większość hostów, które deweloper faktycznie by wybrał, to rozwiązuje (Cloudflare Workers, funkcje Netlify i Vercel, Netlify Forms), więc to kwestia podłączenia, a nie mur. Ale coś musi odebrać prośbę, a typowa droga „zrób to sam” kończy się w jednym z czterech miejsc:

• adres e-mail wypisany na stronie i nic, co chroni go przed zebraniem przez boty;
• zewnętrzna usługa formularzy, która od teraz widzi adresy e-mail Twoich użytkowników;
• funkcja edge na Twoim hoście, która ma kilka linijek, ale to teraz kod, który utrzymujesz w każdej aplikacji;
• mały serwer, który musisz utrzymywać przy życiu dla może dwóch próśb rocznie.

Cokolwiek wybierzesz, zdecyduj świadomie. Strona usuwania, która po cichu gubi prośby, jest gorsza niż jej brak: mówisz użytkownikowi, że jego prośba została przyjęta.

Prowadź rejestr

Cokolwiek zbudujesz, prowadź rejestr próśb: adres, data, co z tym zrobiłeś. Jeśli kiedyś zapyta regulator albo sklep, „usunęliśmy to” jest twierdzeniem, a lista z datami jest dowodem.

Co robi tu AppFoyer

Hostujemy stronę i przekazujemy prośbę. Użytkownik ją wysyła, my zapisujemy ją jako Twój ślad audytowy i powiadamiamy Cię: e-mailem w każdym planie albo przez Telegram lub Slack w planie płatnym. Usunięcie wykonujesz Ty we własnych systemach: nie mamy do nich dostępu i nigdy nie twierdzimy inaczej.

Ta strona pozostaje online, nawet jeśli przestaniesz nam płacić, bo Twoi użytkownicy nie mieli z tym nic wspólnego.

Źródło oficjalne

• Provide information about data deletion — Pomoc Google Play. Przeczytaj ją przed zgłoszeniem; to ona rozstrzyga, nie ten poradnik.