Ten dokument zawiera wskazówki dotyczące wyboru odpowiednich identyfikatorów dla aplikacji na podstawie przypadku użycia.
Ogólne informacje o uprawnieniach na Androidzie znajdziesz w artykule Omówienie uprawnień. Sprawdzone metody dotyczące uprawnień na Androidzie znajdziesz w artykule Sprawdzone metody dotyczące uprawnień aplikacji.
Sprawdzone metody pracy z identyfikatorami Androida
Aby chronić prywatność użytkowników, używaj najbardziej restrykcyjnego identyfikatora, który spełnia wymagania Twojej aplikacji. W szczególności postępuj zgodnie z tymi sprawdzonymi metodami:
- W miarę możliwości wybieraj identyfikatory, które użytkownik może zresetować. Aplikacja może realizować większość przypadków użycia, nawet jeśli używa identyfikatorów innych niż niezmienne identyfikatory sprzętowe.
Unikaj używania identyfikatorów sprzętowych. W większości przypadków możesz uniknąć używania identyfikatorów sprzętowych, takich jak IMEI (International Mobile Equipment Identity), bez ograniczania wymaganych funkcji.
Android 10 (interfejs API na poziomie 29) wprowadza ograniczenia dotyczące identyfikatorów, których nie można zresetować, takich jak IMEI i numer seryjny. Aby uzyskać dostęp do tych identyfikatorów, aplikacja musi być aplikacją właściciela urządzenia lub profilu, mieć specjalne uprawnienia operatora lub uprawnienie uprzywilejowane
READ_PRIVILEGED_PHONE_STATE.Używaj identyfikatora wyświetlania reklam tylko do profilowania użytkowników lub w przypadkach użycia związanych z reklamami. Jeśli używasz identyfikatora wyświetlania reklam, zawsze uwzględniaj wybory użytkowników dotyczące śledzenia reklam. Jeśli musisz połączyć identyfikator wyświetlania reklam z informacjami umożliwiającymi identyfikację, możesz to zrobić tylko za wyraźną zgodą użytkownika.
Nie łącz resetowania identyfikatora wyświetlania reklam.
We wszystkich innych przypadkach użycia, z wyjątkiem zapobiegania oszustwom związanym z płatnościami i telefonii, używaj identyfikatora instalacji Firebase (FID) lub przechowywanego prywatnie identyfikatora GUID. W większości przypadków użycia niezwiązanych z reklamami wystarczy identyfikator FID lub GUID.
Używaj interfejsów API, które są odpowiednie dla Twojego przypadku użycia, aby zminimalizować ryzyko związane z prywatnością. Używaj interfejsu DRM API do ochrony wartościowych treści i interfejsów Play Integrity API do ochrony przed nadużyciami. Interfejsy Play Integrity API to najprostszy sposób na określenie, czy urządzenie jest oryginalne, bez narażania prywatności.
W pozostałych sekcjach tego przewodnika omówimy te zasady w kontekście tworzenia aplikacji na Androida.
Praca z identyfikatorami wyświetlania reklam
Identyfikator wyświetlania reklam to identyfikator, który użytkownik może zresetować. Jest on odpowiedni do przypadków użycia związanych z reklamami. Podczas korzystania z tego identyfikatora należy jednak pamiętać o kilku ważnych kwestiach:
Zawsze szanuj decyzję użytkownika o zresetowaniu identyfikatora wyświetlania reklam. Nie wolno omijać resetowania przez użytkownika, używając innego identyfikatora lub odcisku cyfrowego do łączenia kolejnych identyfikatorów wyświetlania reklam bez zgody użytkownika. Polityka treści dla deweloperów w Google Play zawiera te informacje:
„…po zresetowaniu nowy identyfikator wyświetlania reklam nie może zostać połączony z poprzednim ani z danymi uzyskanymi na podstawie poprzedniego identyfikatora bez wyraźnej zgody użytkownika”.
Zawsze przestrzegaj powiązanej flagi reklam spersonalizowanych. Identyfikatory wyświetlania reklam można konfigurować, dzięki czemu użytkownicy mogą ograniczyć zakres śledzenia powiązanego z identyfikatorem. Zawsze używaj metody AdvertisingIdClient.Info.isLimitAdTrackingEnabled(), aby mieć pewność, że nie omijasz preferencji użytkowników. Polityka treści dla deweloperów w Google Play zawiera te informacje:
„…należy stosować się do wybranego przez użytkowników ustawienia rezygnacji z reklam opartych na zainteresowaniach lub personalizacji reklam. Jeśli użytkownik włączył to ustawienie, nie wolno używać identyfikatora wyświetlania reklam do tworzenia profili użytkowników do celów reklamowych ani do kierowania na użytkowników reklam spersonalizowanych. Dozwolone zastosowania obejmują reklamę kontekstową, ograniczanie liczby wyświetleń, śledzenie konwersji, raportowanie, wykrywanie oszustw oraz bezpieczeństwo”.
Zapoznaj się z zasadami ochrony prywatności i bezpieczeństwa związanymi z używanymi przez Ciebie pakietami SDK, które dotyczą korzystania z identyfikatora wyświetlania reklam.
Jeśli na przykład przekazujesz true do metody enableAdvertisingIdCollection() z pakietu SDK Google Analytics, zapoznaj się ze wszystkimi obowiązującymi zasadami dotyczącymi pakietu SDK Analytics i ich przestrzegaj.
Pamiętaj też, że zgodnie z Polityką treści dla deweloperów w Google Play identyfikator wyświetlania reklam „nie może być powiązany z informacjami umożliwiającymi identyfikację ani z żadnym stałym identyfikatorem urządzenia (np. identyfikatorem SSAID, adresem MAC, numerem IMEI itp.)”.
Załóżmy na przykład, że chcesz zebrać informacje, aby wypełnić tabele bazy danych tymi kolumnami:
| TABLE-01 | |||
timestamp |
ad_id |
account_id |
clickid |
| TABLE-02 | |||
account_id |
name |
dob |
country |
W tym przykładzie kolumnę ad_id można połączyć z informacjami umożliwiającymi identyfikację za pomocą kolumny account_id w obu tabelach, co stanowiłoby naruszenie Polityki treści dla deweloperów w Google Play, jeśli nie masz wyraźnej zgody użytkowników.
Pamiętaj, że powiązania między identyfikatorem reklamodawcy a informacjami umożliwiającymi identyfikację nie zawsze są tak jednoznaczne. Możliwe jest występowanie „quasi-identyfikatorów”, które pojawiają się zarówno w tabelach z kluczem informacji umożliwiających identyfikację, jak i w tabelach z kluczem identyfikatora reklamy, co również powoduje problemy. Załóżmy na przykład, że zmieniamy TABLE-01 i TABLE-02 w ten sposób:
| TABLE-01 | ||||
timestamp |
ad_id |
clickid |
dev_model |
|
| TABLE-02 | ||||
timestamp |
demo |
account_id |
dev_model |
name |
W tym przypadku, przy wystarczająco rzadkich zdarzeniach kliknięcia, nadal można połączyć identyfikator reklamodawcy z TABELI-01 z informacjami umożliwiającymi identyfikację zawartymi w TABELI-02, używając sygnatury czasowej zdarzenia i modelu urządzenia.
Chociaż często trudno jest zagwarantować, że w zbiorze danych nie ma takich quasi-identyfikatorów, możesz zapobiec najbardziej oczywistym zagrożeniom związanym z łączeniem, uogólniając unikalne dane tam, gdzie to możliwe. W poprzednim przykładzie oznaczałoby to zmniejszenie dokładności sygnatury czasowej, tak aby dla każdej sygnatury czasowej pojawiało się wiele urządzeń tego samego modelu.
Inne rozwiązania:
Nie twórz tabel, które wyraźnie łączą informacje umożliwiające identyfikację z identyfikatorami wyświetlania reklam. W pierwszym przykładzie powyżej oznaczałoby to, że w tabeli TABLE-01 nie ma kolumny
account_id.Oddzielanie i monitorowanie list kontroli dostępu dla użytkowników lub ról, które mają dostęp zarówno do danych powiązanych z identyfikatorem wyświetlania reklam, jak i do informacji umożliwiających identyfikację. Dzięki ścisłej kontroli i audytowi możliwości jednoczesnego dostępu do obu źródeł (np. przez połączenie tabel) zmniejszasz ryzyko powiązania identyfikatora wyświetlania reklam z informacjami umożliwiającymi identyfikację. Ogólnie rzecz biorąc, kontrola dostępu oznacza:
- Listy kontroli dostępu (ACL) dla danych powiązanych z identyfikatorem reklamodawcy i informacji umożliwiających identyfikację powinny być rozłączne, aby zminimalizować liczbę osób lub ról, które znajdują się na obu listach.
- Zastosuj rejestrowanie i audytowanie dostępu, aby wykrywać wyjątki od tej reguły i nimi zarządzać.
Więcej informacji o odpowiedzialnym korzystaniu z identyfikatorów wyświetlania reklam znajdziesz w dokumentacji interfejsu API AdvertisingIdClient.
Praca z identyfikatorami FID i GUID
Najprostszym rozwiązaniem do identyfikacji instancji aplikacji działającej na urządzeniu jest użycie identyfikatora instalacji Firebase (FID). Jest to zalecane rozwiązanie w większości przypadków użycia niezwiązanych z reklamami. Dostęp do tego identyfikatora ma tylko instancja aplikacji, dla której został on udostępniony. Można go (stosunkowo) łatwo zresetować, ponieważ jest on przechowywany tylko tak długo, jak aplikacja jest zainstalowana.
Dzięki temu identyfikatory FID zapewniają lepszą ochronę prywatności niż niezmienne identyfikatory sprzętowe na poziomie urządzenia. Więcej informacji znajdziesz w dokumentacji API firebase.installations.
W przypadkach, gdy identyfikator instalacji Firebase nie jest praktyczny, możesz też używać niestandardowych globalnie unikalnych identyfikatorów (GUID) do jednoznacznego identyfikowania instancji aplikacji. Najprostszym sposobem jest wygenerowanie własnego identyfikatora GUID za pomocą tego kodu:
Kotlin
var uniqueID = UUID.randomUUID().toString()
Java
String uniqueID = UUID.randomUUID().toString();
Identyfikator jest unikalny w skali globalnej, więc można go używać do identyfikowania konkretnej instancji aplikacji. Aby uniknąć problemów związanych z łączeniem identyfikatora w różnych aplikacjach, przechowuj identyfikatory GUID w pamięci wewnętrznej, a nie zewnętrznej (współdzielonej). Więcej informacji znajdziesz na stronie z omówieniem przechowywania danych i plików.
nie działają z adresami MAC,
Adresy MAC są globalnie unikalne, nie można ich zresetować i nie są usuwane po przywróceniu ustawień fabrycznych. Z tych powodów, aby chronić prywatność użytkowników, w Androidzie w wersji 6 i nowszych dostęp do adresów MAC jest ograniczony do aplikacji systemowych. Aplikacje innych firm nie mają do nich dostępu.
Zmiany dostępności adresu MAC w Androidzie 11
W aplikacjach kierowanych na Androida 11 lub nowszego randomizacja adresów MAC w sieciach Passpoint jest przeprowadzana na poziomie profilu Passpoint, co powoduje wygenerowanie unikalnego adresu MAC na podstawie tych pól:
- Pełna i jednoznaczna nazwa domeny (FQDN)
- Obszar
- Dane logowania na podstawie danych logowania użytych w profilu Passpoint:
- Dane logowania użytkownika: nazwa użytkownika
- Dane logowania certyfikatu: certyfikat i typ certyfikatu
- Dane uwierzytelniające karty SIM: typ EAP i IMSI
Dodatkowo aplikacje bez uprawnień nie mają dostępu do adresu MAC urządzenia. Widoczne są tylko interfejsy sieciowe z adresem IP. Ma to wpływ na metody getifaddrs() i NetworkInterface.getHardwareAddress(), a także na wysyłanie wiadomości RTM_GETLINK Netlink.
Oto lista sposobów, w jakie ta zmiana wpłynie na aplikacje:
NetworkInterface.getHardwareAddress()zwraca wartość null dla każdego interfejsu.- Aplikacje nie mogą używać funkcji
bind()w gniazdachNETLINK_ROUTE. - Polecenie
ipnie zwraca informacji o interfejsach. - Aplikacje nie mogą wysyłać wiadomości
RTM_GETLINK.
Pamiętaj, że większość deweloperów powinna używać interfejsów API wyższego poziomu ConnectivityManager, a nie interfejsów API niższego poziomu, takich jak NetworkInterface, getifaddrs() czy gniazda Netlink. Na przykład aplikacja, która potrzebuje aktualnych informacji o bieżących trasach, może je uzyskać, nasłuchując zmian w sieci za pomocą ConnectivityManager.registerNetworkCallback() i wywołując powiązany z siecią LinkProperties.getRoutes().
Cechy identyfikatora
System operacyjny Android oferuje wiele identyfikatorów o różnych cechach. To, którego identyfikatora należy użyć, zależy od tego, jak poniższe cechy sprawdzają się w Twoim przypadku użycia. Te cechy mają jednak również wpływ na prywatność, dlatego ważne jest, aby zrozumieć, jak te cechy ze sobą współdziałają.
Zakres
Zakres identyfikatora określa, które systemy mogą uzyskać do niego dostęp. Zakres identyfikatora Androida zwykle występuje w 3 odmianach:
- Pojedyncza aplikacja: identyfikator jest wewnętrzny dla aplikacji i niedostępny dla innych aplikacji.
- Grupa aplikacji: identyfikator jest dostępny dla wstępnie zdefiniowanej grupy powiązanych aplikacji.
- Urządzenie: identyfikator jest dostępny dla wszystkich aplikacji zainstalowanych na urządzeniu.
Im szerszy zakres uprawnień przyznanych identyfikatorowi, tym większe ryzyko, że zostanie on użyty do śledzenia. Jeśli natomiast identyfikator jest dostępny tylko dla jednej instancji aplikacji, nie można go używać do śledzenia urządzenia w ramach transakcji w różnych aplikacjach.
Możliwość resetowania i trwałość
Możliwość zresetowania i trwałość określają okres ważności identyfikatora i wyjaśniają, jak można go zresetować. Typowe przyczyny resetowania to: resetowanie w aplikacji, resetowanie w ustawieniach systemu, resetowanie przy uruchomieniu i resetowanie przy instalacji. Identyfikatory Androida mogą mieć różny czas życia, ale zwykle jest on związany ze sposobem resetowania identyfikatora:
- Tylko sesja: nowy identyfikator jest używany za każdym razem, gdy użytkownik ponownie uruchamia aplikację.
- Resetowanie po instalacji: nowy identyfikator jest używany za każdym razem, gdy użytkownik odinstaluje i ponownie zainstaluje aplikację.
- Resetowanie do ustawień fabrycznych: nowy identyfikator jest używany za każdym razem, gdy użytkownik przywróci urządzenie do ustawień fabrycznych.
- Trwały po przywróceniu do ustawień fabrycznych: identyfikator nie jest usuwany po przywróceniu do ustawień fabrycznych.
Możliwość zresetowania pozwala użytkownikom utworzyć nowy identyfikator, który nie jest powiązany z żadnymi istniejącymi informacjami w profilu. Im dłużej i bardziej niezawodnie identyfikator jest przechowywany, np. po przywróceniu ustawień fabrycznych, tym większe ryzyko, że użytkownik będzie śledzony przez dłuższy czas. Jeśli identyfikator jest resetowany po ponownej instalacji aplikacji, zmniejsza to trwałość i umożliwia resetowanie identyfikatora, nawet jeśli nie ma wyraźnej kontroli użytkownika nad resetowaniem go w aplikacji lub ustawieniach systemu.
Unikalność
Unikalność określa prawdopodobieństwo kolizji, czyli występowania identycznych identyfikatorów w powiązanym zakresie. Na najwyższym poziomie unikalny identyfikator globalny nigdy nie powoduje kolizji, nawet na innych urządzeniach lub w innych aplikacjach.
W przeciwnym razie poziom unikalności zależy od entropii identyfikatora i źródła losowości użytego do jego utworzenia. Na przykład prawdopodobieństwo kolizji jest znacznie wyższe w przypadku losowych identyfikatorów, których ziarnem jest data instalacji (np. 2019-03-01), niż w przypadku identyfikatorów, których ziarnem jest sygnatura czasowa instalacji w systemie Unix (np. 1551414181).
Ogólnie rzecz biorąc, identyfikatory kont użytkowników można uznać za unikalne. Oznacza to, że każda kombinacja urządzenia i konta ma unikalny identyfikator. Z drugiej strony im mniej unikalny jest identyfikator w populacji, tym większa jest ochrona prywatności, ponieważ jest on mniej przydatny do śledzenia poszczególnych użytkowników.
Ochrona integralności i niezaprzeczalność
Możesz użyć identyfikatora, który jest trudny do sfałszowania lub odtworzenia, aby udowodnić, że powiązane urządzenie lub konto ma określone właściwości. Możesz na przykład udowodnić, że urządzenie nie jest urządzeniem wirtualnym używanym przez spamera. Identyfikatory, które trudno sfałszować, zapewniają też niezaprzeczalność. Jeśli urządzenie podpisuje wiadomość kluczem tajnym, trudno jest twierdzić, że wiadomość została wysłana z urządzenia innej osoby. Niezaprzeczalność może być pożądana przez użytkownika, np. podczas uwierzytelniania płatności, lub niepożądana, np. gdy użytkownik wysyła wiadomość, której żałuje.
Typowe przypadki użycia i odpowiednie identyfikatory
W tej sekcji znajdziesz alternatywne rozwiązania, które nie wymagają używania identyfikatorów sprzętowych, takich jak IMEI. Nie zalecamy używania identyfikatorów sprzętowych, ponieważ użytkownik nie może ich zresetować i są one ograniczone do urządzenia. W wielu przypadkach wystarczy identyfikator ograniczony do aplikacji.
Konta
Stan przewoźnika
W takim przypadku aplikacja korzysta z funkcji telefonu i SMS-ów na urządzeniu za pomocą konta operatora.
Zalecane identyfikatory: IMEI, IMSI i Line1.
Dlaczego ta rekomendacja?
Korzystanie z identyfikatorów sprzętowych jest dopuszczalne, jeśli jest to wymagane do działania funkcji związanych z operatorem. Możesz na przykład używać tych identyfikatorów do przełączania się między operatorami komórkowymi lub gniazdami SIM albo do dostarczania SMS-ów przez IP (w przypadku Line1) – kont użytkowników opartych na karcie SIM. W przypadku aplikacji bez uprawnień zalecamy jednak używanie logowania na konto w celu pobierania informacji o urządzeniu użytkownika po stronie serwera. Jednym z powodów jest to, że w Androidzie 6.0 (interfejs API na poziomie 23) i nowszych wersjach te identyfikatory mogą być używane tylko za pomocą uprawnień w czasie działania aplikacji. Użytkownicy mogą wyłączyć to uprawnienie, więc aplikacja powinna odpowiednio obsługiwać takie wyjątki.
Stan subskrypcji mobilnej
W takim przypadku musisz powiązać funkcje aplikacji z określonymi subskrypcjami usług mobilnych na urządzeniu. Możesz na przykład wymagać weryfikacji dostępu do niektórych funkcji aplikacji premium na podstawie subskrypcji mobilnych urządzenia za pomocą karty SIM.
Zalecany identyfikator: Subscription ID API do identyfikowania kart SIM używanych na urządzeniu.
Identyfikator subskrypcji zawiera wartość indeksu (zaczynającą się od 1) służącą do jednoznacznego identyfikowania zainstalowanych kart SIM (w tym fizycznych i elektronicznych) używanych na urządzeniu. Dzięki temu identyfikatorowi aplikacja może powiązać swoje funkcje z różnymi informacjami o subskrypcji dla danej karty SIM. Ta wartość jest stała dla danej karty SIM, chyba że urządzenie zostanie przywrócone do ustawień fabrycznych. Może się jednak zdarzyć, że ta sama karta SIM będzie miała inny identyfikator subskrypcji na różnych urządzeniach lub różne karty SIM będą miały ten sam identyfikator na różnych urządzeniach.
Dlaczego ta rekomendacja?
Niektóre aplikacje mogą obecnie używać do tego celu identyfikatora ICC. Ponieważ identyfikator ICC jest unikalny globalnie i nie można go zresetować, od Androida 10 dostęp do niego jest ograniczony do aplikacji z uprawnieniem READ_PRIVILEGED_PHONE_STATE. Od Androida 11 dostęp do identyfikatora ICCID przez interfejs API getIccId() jest jeszcze bardziej ograniczony, niezależnie od docelowego poziomu interfejsu API aplikacji. W aplikacjach, których dotyczy ten problem, należy zamiast tego używać identyfikatora subskrypcji.
Logowanie jednokrotne
W tym przypadku aplikacja oferuje logowanie jednokrotne, umożliwiając użytkownikom powiązanie istniejącego konta z Twoją organizacją.
Zalecany identyfikator: konta zgodne z menedżerem kont, np. połączone z kontem Google.
Dlaczego ta rekomendacja?
Łączenie z kontem Google umożliwia użytkownikom powiązanie ich dotychczasowego konta Google z Twoją aplikacją, co zapewnia bezproblemowy i bezpieczniejszy dostęp do usług Twojej organizacji. Możesz też zdefiniować niestandardowe zakresy OAuth, aby udostępniać tylko niezbędne dane. Dzięki temu zwiększysz zaufanie użytkowników, jasno określając, jak ich dane są wykorzystywane.
Reklamy
Kierowanie
W tym przypadku aplikacja tworzy profil zainteresowań użytkownika, aby wyświetlać mu trafniejsze reklamy.
Zalecany identyfikator: jeśli Twoja aplikacja używa identyfikatora do wyświetlania reklam i jest przesyłana lub publikowana w Google Play, musi to być identyfikator wyświetlania reklam.
Dlaczego ta rekomendacja?
Jest to przypadek użycia związany z reklamami, który może wymagać identyfikatora dostępnego w różnych aplikacjach organizacji, więc użycie identyfikatora wyświetlania reklam jest najbardziej odpowiednim rozwiązaniem. Zgodnie z Polityką treści dla deweloperów w Google Play używanie identyfikatora wyświetlania reklam jest obowiązkowe w przypadku wyświetlania reklam, ponieważ użytkownik może go zresetować.
Niezależnie od tego, czy udostępniasz dane użytkownika w aplikacji, jeśli zbierasz je i wykorzystujesz do celów reklamowych, musisz zadeklarować te cele w sekcji Bezpieczeństwo danych na stronie Zawartość aplikacji w Konsoli Play.
Pomiary
W takim przypadku aplikacja tworzy profil użytkownika na podstawie jego zachowania w aplikacjach organizacji na tym samym urządzeniu.
Zalecany identyfikator: identyfikator wyświetlania reklam lub interfejsy API Play Install Referrer.
Dlaczego ta rekomendacja?
Jest to przypadek użycia związany z reklamami, który może wymagać identyfikatora dostępnego w różnych aplikacjach organizacji, więc użycie identyfikatora wyświetlania reklam jest najbardziej odpowiednim rozwiązaniem. Jeśli używasz identyfikatora do celów reklamowych, musi to być identyfikator wyświetlania reklam, ponieważ użytkownik może go zresetować. Więcej informacji znajdziesz w Polityce treści dla deweloperów w Google Play.
Konwersje
W tym przypadku śledzisz konwersje, aby sprawdzić, czy Twoja strategia marketingowa jest skuteczna.
Zalecany identyfikator: identyfikator wyświetlania reklam lub interfejsy API Play Install Referrer.
Dlaczego ta rekomendacja?
Jest to przypadek użycia związany z reklamami, który może wymagać identyfikatora dostępnego w różnych aplikacjach organizacji, więc użycie identyfikatora wyświetlania reklam jest najbardziej odpowiednim rozwiązaniem. Zgodnie z Polityką treści dla deweloperów w Google Play używanie identyfikatora wyświetlania reklam jest obowiązkowe w przypadku wyświetlania reklam, ponieważ użytkownik może go zresetować.
Remarketing
W tym przypadku aplikacja wyświetla reklamy na podstawie wcześniejszych zainteresowań użytkownika.
Zalecany identyfikator: identyfikator wyświetlania reklam.
Dlaczego ta rekomendacja?
Jest to przypadek użycia związany z reklamami, który może wymagać identyfikatora dostępnego w różnych aplikacjach organizacji, więc użycie identyfikatora wyświetlania reklam jest najbardziej odpowiednim rozwiązaniem. Zgodnie z Polityką treści dla deweloperów w Google Play używanie identyfikatora wyświetlania reklam jest obowiązkowe w przypadku wyświetlania reklam, ponieważ użytkownik może go zresetować.
Analityka aplikacji
W tym przypadku aplikacja ocenia zachowanie użytkownika, aby pomóc Ci określić:
- Które z innych produktów lub aplikacji Twojej organizacji mogą być odpowiednie dla użytkownika.
- Jak utrzymać zainteresowanie użytkowników aplikacją.
- Mierzenie statystyk użytkowania i statystyk dotyczących wylogowanych lub anonimowych użytkowników.
Możliwe rozwiązania:
- Identyfikator zestawu aplikacji: umożliwia analizowanie zachowań użytkownika w różnych aplikacjach należących do Twojej organizacji, o ile nie używasz danych użytkownika do celów reklamowych. Jeśli kierujesz reklamy na urządzenia z usługami Google Play, zalecamy używanie identyfikatora zestawu aplikacji.
- Identyfikator Firebase (FID): identyfikator FID jest ograniczony do aplikacji, która go tworzy, co zapobiega używaniu go do śledzenia użytkowników w różnych aplikacjach. Można go też łatwo zresetować, ponieważ użytkownik może wyczyścić dane aplikacji lub zainstalować ją ponownie. Proces tworzenia identyfikatora FID jest prosty – zapoznaj się z przewodnikiem po instalacjach Firebase.
Tworzenie aplikacji
Zgłaszanie awarii
W tym przypadku aplikacja zbiera dane o tym, kiedy i dlaczego ulega awarii na urządzeniach użytkowników.
Zalecany identyfikator: FID lub identyfikator zestawu aplikacji.
Dlaczego ta rekomendacja?
Identyfikator FID jest ograniczony do aplikacji, która go tworzy, co uniemożliwia używanie go do śledzenia użytkowników w różnych aplikacjach. Można go też łatwo zresetować, ponieważ użytkownik może wyczyścić dane aplikacji lub zainstalować ją ponownie. Proces tworzenia identyfikatora FID jest prosty – zapoznaj się z przewodnikiem po instalacjach Firebase. Identyfikator zestawu aplikacji umożliwia analizowanie zachowań użytkownika w wielu aplikacjach należących do Twojej organizacji, o ile nie używasz danych użytkownika do celów reklamowych.
Raportowanie skuteczności
W takim przypadku aplikacja zbiera wskaźniki wydajności, takie jak czas wczytywania i wykorzystanie baterii, aby pomóc w poprawie jakości aplikacji.
Zalecany identyfikator: Monitorowanie skuteczności w Firebase
Dlaczego ta rekomendacja?
Monitorowanie skuteczności w Firebase pomaga skupić się na danych, które są dla Ciebie najważniejsze, i przetestować wpływ ostatniej zmiany w aplikacji.
Testowanie aplikacji
W takim przypadku aplikacja ocenia wrażenia użytkownika związane z aplikacją na potrzeby testowania lub debugowania.
Zalecany identyfikator: FID lub identyfikator zestawu aplikacji.
Dlaczego ta rekomendacja?
Identyfikator FID jest ograniczony do aplikacji, która go tworzy, co uniemożliwia używanie go do śledzenia użytkowników w różnych aplikacjach. Można go też łatwo zresetować, ponieważ użytkownik może wyczyścić dane aplikacji lub zainstalować ją ponownie. Proces tworzenia identyfikatora FID jest prosty – zapoznaj się z przewodnikiem po instalacjach Firebase. Identyfikator zestawu aplikacji umożliwia analizowanie zachowań użytkownika w wielu aplikacjach należących do Twojej organizacji, o ile nie używasz danych użytkownika do celów reklamowych.
Instalacja na różnych urządzeniach
W takim przypadku aplikacja musi zidentyfikować prawidłową instancję, gdy jest zainstalowana na wielu urządzeniach tego samego użytkownika.
Zalecany identyfikator: FID lub GUID
Dlaczego ta rekomendacja?
Identyfikator FID został zaprojektowany specjalnie w tym celu. Jego zakres jest ograniczony do aplikacji, więc nie można go używać do śledzenia użytkowników w różnych aplikacjach. Jest on resetowany po ponownej instalacji aplikacji. W rzadkich przypadkach, gdy identyfikator FID jest niewystarczający, możesz też użyć identyfikatora GUID.
Bezpieczeństwo
Wykrywanie nadużyć
W tym przypadku próbujesz wykryć wiele fałszywych urządzeń atakujących Twoje usługi backendu.
Zalecany identyfikator: token integralności interfejsu Google Play Integrity API.
Dlaczego ta rekomendacja?
Aby sprawdzić, czy żądanie pochodzi z oryginalnego urządzenia z Androidem, a nie z emulatora lub innego kodu podszywającego się pod inne urządzenie, użyj interfejsu Google Play Integrity API.
oszustwo reklamowe,
W tym przypadku Sprawdzanie aplikacji weryfikuje, czy wyświetlenia i działania użytkownika w aplikacji są autentyczne i możliwe do zweryfikowania.
Zalecany identyfikator: identyfikator wyświetlania reklam.
Dlaczego ta rekomendacja?
Zgodnie z Polityką treści dla deweloperów w Google Play w przypadku reklam należy używać identyfikatora wyświetlania reklam, ponieważ użytkownik może go zresetować.
Zarządzanie prawami cyfrowymi (DRM)
W tym przypadku aplikacja chce chronić przed nieuczciwym dostępem do własności intelektualnej lub płatnych treści.
Zalecany identyfikator: użycie identyfikatora FID lub GUID zmusza użytkownika do ponownej instalacji aplikacji, aby obejść limity treści, co jest wystarczającym utrudnieniem, aby zniechęcić większość osób. Jeśli to nie wystarczy, Android udostępnia interfejs DRM API, który może służyć do ograniczania dostępu do treści i zawiera identyfikator Widevine dla każdego pliku APK.
Preferencje użytkownika
W takim przypadku aplikacja zapisuje stan użytkownika na urządzeniu, zwłaszcza w przypadku użytkowników, którzy nie są zalogowani. Możesz przenieść ten stan do innej aplikacji, która jest podpisana tym samym kluczem na tym samym urządzeniu.
Zalecany identyfikator: FID lub GUID
Dlaczego ta rekomendacja?
Nie zalecamy zachowywania informacji po ponownej instalacji, ponieważ użytkownicy mogą chcieć zresetować swoje preferencje przez ponowne zainstalowanie aplikacji.