Przejdź do treści
AppFoyer
Zacznij

Poradniki Polityka prywatności

Adres URL polityki prywatności, którego potrzebuje aplikacja na Androida

Gdzie wpisać URL, co musi obejmować polityka i pułapka SDK, w którą wpadają deweloperzy przekonani, że ich aplikacja nic nie zbiera.

Oba sklepy wymagają publicznie dostępnego adresu URL polityki prywatności, który ładuje się bez logowania. W Google Play wpisujesz go w App content → Privacy policy; w Apple to pole w App Store Connect. Trudny nie jest sam URL, tylko treść: musi obejmować to, co zbiera każdy SDK w Twoim buildzie.

1:03
Film, 1:03 · otwiera się na YouTube

Zrób to zamiast tego w kilka minut

AppFoyer hostuje strony, o których jest ten poradnik — politykę prywatności, regulamin, wsparcie, usuwanie konta i app-ads.txt — na ich własnej subdomenie, bez Twojej własnej domeny i serwera. Jedna aplikacja jest za darmo, a nic, czego wymaga sklep, nigdy nie jest płatne.

Zacznij za darmo Zobacz działający przykład

Sprawdzono 19 września 2026. Zasady sklepów się zmieniają, czasem bez zapowiedzi. Wszystko poniżej linkuje do oficjalnej dokumentacji i to ona — nie ta strona — jest rozstrzygająca. Jeśli się różnią, rację ma sklep. Ten poradnik jest przetłumaczony z angielskiego; cytaty z dokumentacji sklepów pozostawiono w oryginalnym brzmieniu angielskim.

Oba sklepy chcą publicznie dostępnego adresu URL Twojej polityki prywatności i oba go sprawdzają. Zasady Google Play dotyczące danych użytkownika mówią to wprost — „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” (wszystkie aplikacje muszą zamieścić link do polityki prywatności w wyznaczonym polu w Play Console oraz link do polityki prywatności lub jej tekst w samej aplikacji) — a to pole znajduje się w App content → Privacy policy (Treść aplikacji → Polityka prywatności). Po stronie Apple to pole wymagane w App Store Connect. Strona musi ładować się bez logowania, wymieniać Twoją aplikację i firmę, opisywać, co zbiera aplikacja i wszystko, co w niej jest, i nadal działać po miesiącach — strona aplikacji w sklepie jest sprawdzana więcej niż raz.

Sam wymóg nie jest trudny. Ludzi łapie trzeci punkt z tej listy i to jemu warto poświęcić resztę tej strony.

„Ale moja aplikacja niczego nie zbiera”

To założenie, które kosztuje ludzi tydzień.

Twój kod może niczego nie zbierać. Twoje zależności niemal na pewno zbierają. Narzędzie do raportowania awarii wysyła identyfikatory urządzenia i stack trace’y. SDK analityczne wysyła zdarzenia i identyfikator reklamowy. SDK reklamowe wysyła całkiem sporo. Biblioteka push rejestruje token, który z definicji jest powiązany z urządzeniem.

Uczciwe pytanie nie brzmi więc „co ja zbieram”, tylko „co zbiera wszystko, co jest w moim buildzie”. Otwórz plik zależności i przejdź przez niego linijka po linijce — ta lista jest treścią Twojej polityki prywatności i to z nią weryfikator porównuje Twoje odpowiedzi w Data safety.

Gdy jedno z drugim się nie zgadza, sklep wierzy SDK.

Co musi obejmować polityka

Co najmniej, językiem zrozumiałym dla człowieka:

  • Co jest zbierane — kategorie, a nie schemat bazy danych.
  • Po co — cel każdej kategorii.
  • Kto jeszcze to widzi — wymień podmioty zewnętrzne. Tu trafia Twoja lista SDK.
  • Jak długo dane są przechowywane.
  • Jak się z Tobą skontaktować i jak poprosić o usunięcie.

Jeśli masz użytkowników w UE, Wielkiej Brytanii, Kalifornii lub Brazylii, każdy z tych systemów prawnych oczekuje konkretnych elementów. Ta strona nie powie Ci, które dotyczą Ciebie — to naprawdę zależy od Twoich użytkowników i Twojej działalności, i warto poświęcić na to godzinę prawnika, jeśli w Twojej aplikacji jest coś nietypowego.

Praktyczne powody odrzucenia

  • URL wymagający logowania albo zablokowany w niektórych regionach.
  • PDF lub dokument Google. Czasem akceptowane, często nie, i wygląda na prowizorkę.
  • Polityka wymieniająca inną aplikację lub firmę — znak rozpoznawczy kopiuj-wklej. Weryfikatorzy to zauważają.
  • Polityka sprzeczna z Twoim formularzem Data safety. Są czytane razem.
  • Martwy link. Pół roku po premierze darmowy hosting, którego użyłeś, już nie istnieje.

Czy to musi kosztować?

Nie. Polityka prywatności to tekst na stronie; pieniądze kosztuje domena, miejsce do hostowania, które nadal będzie istnieć za rok, i czas na napisanie czegoś, co pasuje do Twojej faktycznej aplikacji.

Uważaj na generatory rozliczane za aplikację miesięcznie. Wynajmujesz szablon — sprawdź, co się dzieje z Twoim adresem URL, gdy przestajesz płacić, bo URL polityki prywatności, który przestaje działać, gdy jest wpisany na działającej stronie aplikacji w sklepie, to problem, o którym usłyszysz od sklepu, a nie od dostawcy.

Co robi tutaj AppFoyer

Generujemy politykę na podstawie SDK znalezionych w Twoich plikach buildu — przez agenta kodującego, który czyta repozytorium, albo z krótkiego formularza — i hostujemy ją na własnej subdomenie. Checklista ostrzega Cię tak długo, aż zastąpisz tekst zastępczy w miejscu, gdzie wymienione są podmioty zewnętrzne, bo to jest ta część, którą weryfikator naprawdę czyta.

Szablony są punktem wyjścia, a nie poradą prawną, i każda wygenerowana strona to mówi.

Źródła oficjalne