Formularz Data safety w Google Play: kompletny przewodnik

Formularz Data safety to ankieta, którą musisz wypełnić dla każdej aplikacji przesyłanej do Google Play; deklarujesz w niej, jakie typy danych zbiera Twoja aplikacja, w jakim celu i czy te dane są udostępniane stronom trzecim. W Play Console znajdziesz go w Policy > App content > Data safety po wybraniu swojej aplikacji.

Ten formularz zasila sekcję „Data safety", którą użytkownicy widzą na stronie Twojej aplikacji w sklepie; każda zadeklarowana pozycja staje się częścią listy widocznej dla potencjalnych użytkowników przed instalacją. Formularz nie zastępuje osobno wymaganego adresu URL polityki prywatności — oba elementy muszą być uzupełnione.

Nie osiągniesz produkcji bez wypełnienia formularza; sekcja Data safety pozostawiona pusta lub nigdy nieotwarta pojawia się jako blokujące ostrzeżenie w procesie publikacji.

Formularz pyta wzdłuż dwóch odrębnych osi: zbierania danych i udostępniania danych. Zgodnie z oficjalną definicją Google zbieranie oznacza przesyłanie danych poza urządzenie użytkownika — przez Twoją aplikację lub używany przez nią SDK; dane przetwarzane wyłącznie na urządzeniu i nigdy nigdzie niewysyłane (przetwarzanie efemeryczne, lokalne) nie liczą się jako zbieranie i nie trzeba ich deklarować. Udostępnianie oznacza przekazanie zebranych danych użytkownika stronie trzeciej (sieci reklamowej, dostawcy analityki) — niezależnie od pierwotnego celu zbierania, przekazanie ich stronie trzeciej liczy się jako udostępnianie. To nie to samo, a formularz każe zaznaczyć je osobno.

Na przykład SDK reklamowy, który pobiera Advertising ID do personalizacji reklam i wysyła je na własne serwery, liczy się zarówno jako zbieranie, jak i udostępnianie: SDK przesyła dane poza urządzenie (zbieranie), a te dane są przetwarzane na własnych serwerach sieci reklamowej (udostępnianie). Natomiast dane wysyłane wyłącznie do Twojego własnego backendu (serwera, który sam obsługujesz, a nie strony trzeciej) liczą się jako zbieranie, ale nie jako udostępnianie, ponieważ nie ma w tym żadnej strony trzeciej. Dane, które w ogóle nie opuszczają urządzenia — przechowywane tylko lokalnie, np. motyw lub preferencja językowa zapamiętywana przez aplikację lokalnie — w ogóle nie liczą się jako zbieranie; zgodnie z oficjalną definicją Google tego rodzaju danych nie trzeba w ogóle deklarować w formularzu.

Dla każdego typu danych formularz pyta również o cel (funkcjonalność aplikacji, analityka, reklama/marketing, zapobieganie oszustwom, personalizacja i podobne), czy dane są opcjonalne oraz czy są szyfrowane podczas przesyłania. Niedopasowanie tych pól do rzeczywistego zachowania Twojego SDK to najczęstsze źródło wykrywanych niespójności.

Jeśli korzystasz z AdMob, musisz zadeklarować, że Advertising ID jest zbierane i używane do personalizacji reklam; AdMob może też przetwarzać przybliżoną lokalizację oraz informacje o urządzeniu/aplikacji w celu wyświetlania reklam i zapobiegania oszustwom. To deklaracja wymagana przez własne zasady AdMob dla wydawców — pominięcie jej powoduje problemy zarówno podczas weryfikacji Play, jak i w konsoli AdMob.

Jeśli używasz Firebase Analytics, musisz zaznaczyć, że interakcje w aplikacji i dane o użytkowaniu są zbierane w celach analitycznych. Jeśli używasz Firebase Crashlytics, musisz osobno zadeklarować zbieranie dzienników awarii, identyfikatorów urządzenia i danych diagnostycznych — połączenie Crashlytics z Analytics w jednym wierszu może zostać uznane za niedodeklarowanie, ponieważ są to osobne SDK-i zasługujące na osobne wiersze w formularzu.

Jeśli Twoja aplikacja zbiera własne dane niezależnie od jakiegokolwiek SDK — e-mail lub telefon logowania, dane płatności, uprawnienie lokalizacji — zadeklaruj je również osobno. Sekcja dokumentacji każdego SDK dotycząca ujawnień data-safety/prywatności to najbardziej wiarygodne źródło podczas wypełniania formularza; mogą się one zmieniać między wersjami SDK.

Twoje deklaracje Data safety i treść polityki prywatności muszą się ze sobą zgadzać. Zaznaczenie w formularzu „zebrano identyfikator reklamowy", podczas gdy Twoja polityka nigdy nie wspomina o AdMob — lub odwrotnie — może zostać oznaczone jako niespójność podczas weryfikacji, a w najgorszym razie uruchomić proces prowadzący do zawieszenia aplikacji.

Praktyczne podejście: najpierw wypisz każdy używany SDK i to, co on zbiera, a następnie przenieś tę samą listę zarówno do formularza Data safety, jak i do polityki prywatności z takim samym poziomem szczegółowości. Ilekroć dodajesz do aplikacji nowy SDK lub uprawnienie, aktualizacja obu dokumentów w tym samym wydaniu usuwa większość ryzyka późniejszej niespójności.

Najczęstszym problemem jest niedodeklarowanie: aplikacja zbiera dane za pośrednictwem SDK, ale formularz nigdy tego nie odzwierciedla. Zwykle dzieje się to, gdy formularz nie jest aktualizowany po zintegrowaniu SDK, i może zostać wykryte jako niespójność podczas automatycznej lub ręcznej weryfikacji Play.

Drugim przypadkiem jest adres URL polityki prywatności, który jest pusty, niedostępny lub zawiera tekst sprzeczny z deklaracjami formularza; ta niezgodność to osobny powód odrzucenia i może zostać oznaczona niezależnie od samego formularza Data safety.

Trzeci to niesprawdzanie formularza po zmianach w treści: dodanie nowego SDK, nowego uprawnienia (np. lokalizacji) lub nowej integracji ze stroną trzecią bez aktualizacji formularza sprawia, że istniejąca deklaracja przestaje odpowiadać rzeczywistemu zachowaniu aplikacji. Google może okresowo ponownie oceniać wydania pod tym kątem.