AppsFlyer Atrybucja Mobilna i Zgoda na Pliki Cookie: Przewodnik Integracji 2026 dla Wydawców Aplikacji
Dla deweloperów aplikacji pomiar mobilny jest zasadniczo różnym problemem od pomiaru w sieci. Pliki cookie, którymi martwią się wydawcy webowi, nie istnieją wewnątrz natywnej aplikacji, ale identyfikatory, które je zastępują — IDFA, GAID, IDFV, identyfikatory instalacji, zahashowane e-maile, odciski urządzeń wywodzone z IP — rodzzą te same pytania prawne i odpowiadają przed tymi samymi regulatorami. AppsFlyer, najszerzej wdrożony partner pomiarowy dla moblinych gier, fintech i aplikacji konsumenckich, znajduje się w środku tego potoku. Jego SDK zbiera identyfikatory klasy atrybucji, jego serwery korelują je z postbackami sieci reklamowych, a wynikająca atrybucja zasila budżety pozyskiwania użytkowników na wszystkich głównych kanałach. żadne z tych przetwarzań nie odbywa się bez podstawy prawnej, a podstawą prawną, której faktycznie wymagają GDPR i Dyrektywa ePrivacy, jest zgoda — zebrana przed inicjalizacją SDK, zarejestrowana jako dowód i propagowana do każdej integracji poniżej. Ten przewodnik omówia, co zbiera AppsFlyer, jak zintegrować go z frameworkiem zarządzania zgodą na iOS, Androidzie i mobilnej sieci, oraz jak własne prymitywy prywatności platformy (Start SDK API, sygnały ATT i Data Privacy Framework) wpisują się w ten obraz.
Co zbiera AppsFlyer
SDK AppsFlyer inicjalizuje sesję natychmiast po uruchomieniu aplikacji hosta i domyślnie zbiera zbiór identyfikatorów oraz sygnałów kontekstowych: identyfikator reklamy na poziomie urządzenia (IDFA na iOS, GAID na Androidzie), IDFV o zakresie dostawcy na iOS, wygenerowany identyfikator instalacji AppsFlyer utrzymujący się między sesjami, adres IP (używany do geo-IP i probabilistycznego dopasowywania w stylu fingerprint), user agent, model urządzenia, wersja systemu operacyjnego, operator i strefa czasowa. Po instalacji SDK raportuje zdarzenie instalacji do serwerów AppsFlyer, gdzie jest dopasowywane do danych kliknięć przekazywanych przez sieci reklamowe. Kolejne zdarzenia w aplikacji — Purchase, RegistrationComplete, Tutorial Complete, Custom — wysyłane są przez ten sam SDK i dziedziczą ten sam zestaw identyfikatorów.
Regulatorzy jednoznacznie stwierdzili, że jest to przetwarzanie danych osobowych na podstawie GDPR. IDFA i GAID są danymi osobowymi, ponieważ są trwałymi identyfikatorami na poziomie urządzenia. Probabilistyczne dopasowywanie odcisków, które odbywa się równolegle, jest jeszcze trudniejsze do obrony bez zgody, ponieważ jest — z definicji — próbą identyfikacji użytkownika bez jego wyraźnej współpracy. CNIL, włoski Garante i hiszpański AEPD wszczęli śledztwa przeciwko wydawcom, których stosy atrybucji uruchomiły się przed udzieleniem zgody.
Natywne kontrole prywatności AppsFlyer
AppsFlyer udostępnia znaczący zestaw natywnych prymitywów prywatności. Nie są one substytutem prawdziwego frameworku zgody, ale zrozumienie ich jest kluczowe, ponieważ są to dźwignie, których CMP używa do kontroli zachowania SDK.
Start SDK API
SDK obsługuje tryb inicjalizacji, w którym jest skonfigurowany, ale nie przesyła żadnych danych, dopóki start() nie zostanie wyraźnie wywołany. Jest to najważniejszy pojedynczy hak do bramkowania zgody — domyślnie SDK uruchamia się automatycznie przy starcie aplikacji, co jest błędnym zachowaniem dla każdej jurysdykcji z wymogiem uprzedniej zgody. Ustaw isStopped na true przy inicjalizacji lub użyj API opóźnionego startu, i wywołuj start() tylko gdy sygnał zgody jest zarejestrowany.
Stop API
Jeśli zgoda zostaje cofnięta w trakcie sesji, wywołanie stop() wstrzymuje wszelką dalszą transmisję. Nie usuwa wstecznie danych już wysłanych. Aby całkowicie usunąć dane, należy złożyć wniosek o usunięcie danych podmiotu danych za pośrednictwem portalu prywatności AppsFlyer — co zespoły integracyjne powinny automatyzować za pomocą API AppsFlyer zamiast ręcznego procesu.
setSharingFilter
Filtruje to, które z dalszych sieci reklamowych otrzymują dane postback. Jest to właściwy prymityw dla szczegółowej zgody per partner — na przykład zezwalając ogólnie na atrybucję, ale blokując przekierowania do konkretnej sieci, którą użytkownik odrzucił.
Integracja Apple App Tracking Transparency
Na iOS AppsFlyer odczytuje status autoryzacji ATT i automatycznie dostosowuje swoje zachowanie — jeśli użytkownik odrzucił ATT, IDFA nie jest przesyłane. ATT jest niezależne od zgody GDPR, a wielu wydawców je miesza. ATT kontroluje jeden sygnał na poziomie iOS; zgoda GDPR kontroluje wszystko inne.
Integracja na iOS
Niezawodny wzorzec na iOS polega na instalacji SDK AppsFlyer, ale odroczeniu inicjalizacji do momentu zakończenia zarówno ATT, jak i przepływu zgody w aplikacji. Minimalna sekwencja jest następująca: aplikacja startuje, SDK jest skonfigurowany z isStopped = true, baner zgody w aplikacji wyświetla się, użytkownik akceptuje odpowiednie kategorie, flaga isStopped SDK jest czyszczona i wywoływane jest start(). Jeśli aplikacja potrzebuje również ATT (a potrzebuje go dla każdego użytkownika, dla którego IDFA jest istotny), monit ATT jest wyświetlany wraz z banerem w aplikacji lub po nim. Większość CMP obsługujących urządzenia mobilne ma oparty na funkcji zwrotnej API dostarczający decyzję o zgodzie; ta funkcja zwrotna jest właściwym miejscem do wywołania start().
Integracja na Androidzie
Implementacja na Androidzie równolegli iOS z dwiema różnicami. Po pierwsze, nie ma odpowiednika ATT — GAID jest dostępny, chyba że użytkownik skorzystał z ustawienia urządzenia „Usuń identyfikator reklamowy”, czego większość użytkowników nie robi. Po drugie, cykl życia Androida jest bardziej agresywny w kwestii pracy w tle, więc inicjalizacja SDK musi być powiązana z trwale przechowanym stanem zgody. Odczytaj stan zgody z lokalnego magazynu podczas startu aplikacji, odpowiednio skonfiguruj SDK i ponownie sprawdzaj przy wznawianiu w przypadku, gdy użytkownik zaktualizował swój wybór, gdy aplikacja działała w tle.
Integracja w mobilnej sieci
AppsFlyer działa także w mobilnej sieci za pośrednictwem produktów smart banner i OneLink. Są to w zasadzie narzędzia analityczne i głębokich linków po stronie sieci, które umieszczają pliki cookie i wywołują serwery AppsFlyer z przeglądarki. Obowiązują te same reguły co dla każdej innej powierzchni śledzenia w sieci: bramkuj je za kategorią marketingową CMP, nie pozwalaj, aby skrypt smart banner działał przed udzieleniem zgody, i zadbaj, aby wszelkie zdarzenia wyzwalane przez OneLink z kampanii e-mailowych lub push respektowały stan zgody użytkownika.
Częste pułapki
Cztery błędy integracyjne pojawiają się wielokrotnie podczas audytów wdrożeń AppsFlyer.
Traktowanie ATT jako zgody GDPR
ATT i zgoda GDPR to różne sygnały o różnym zakresie. Użytkownik, który akceptuje ATT, autoryzował użycie IDFA do śledzenia między aplikacjami; nie autoryzował wszystkiego innego, co robi SDK. Dla ruchu EU i UK oba sygnały są wymagane, przy czym baner w aplikacji jest wiążący, a ATT jest warstwą specyficzną dla iOS na wierzchu.
Pozwalanie SDK na inicjalizację przy starcie
To najczęstszy pojedynczy defekt. Domyślna integracja wywołuje start() natychmiast, co wysyła zdarzenie instalacji z pełnym ładunkiem identyfikatorów przed wyświetleniem użytkownikowi banera zgody. Naprawa jest prosta: skonfiguruj isStopped = true w czasie integracji i wywołuj start() tylko z funkcji zwrotnej zgody.
Zapomnienie o obsłudze cofnięcia
Jeśli użytkownik zaakceptuje, a później cofnie zgodę, SDK musi zostać poinformowany o zaprzestaniu transmisji. Użyj API stop() i zaktualizuj trwały stan zgody, aby następne uruchomienie aplikacji respektowało nową decyzję.
Ignorowanie postbacków serwer-serwer
AppsFlyer przekazuje zdarzenia konwersji do długiego ogona zintegrowanych sieci reklamowych za pośrednictwem postbacków po stronie serwera. Każde przekazanie niesie dane osobowe i dziedziczy zakres zgody oryginalnego zdarzenia. Użyj setSharingFilter, aby zapewnić, że przekazania trafiają tylko do partnerów objętych wyborami zgody użytkownika, a nie do każdego partnera w panelu AppsFlyer.
Lista kontrolna audytu
Sześć konkretnych pytań do odpowiedzi dla każdego wdrożenia AppsFlyer dotykającego ruchu EU, UK lub Kalifornii.
- Czy SDK czeka na zgodę? Przy świeżej instalacji na urządzeniu testowym zlokalizowanym w EU, potwierdzono, że żaden punkt końcowy AppsFlyer nie odbiera żadnego żądania przed zaakceptowaniem banera przez użytkownika.
- Czy ATT jest oddzielony od zgody w aplikacji? Potwierdzono, że baner w aplikacji jest kontrolnym sygnałem zgody, a ATT jest traktowany jako dodatkowa warstwa specyficzna dla iOS.
- Czy przekazywanie do partnerów jest ograniczone do zgody? Potwierdzono, że setSharingFilter jest skonfigurowany tak, aby wykluczać partnerów, których użytkownik nie autoryzował.
- Czy cofnięcie wstrzymuje SDK? Potwierdzono, że wywołanie stop() działa przy cofnięciu zgody i że nowy stan utrzymuje się między uruchomieniami.
- Czy postbacki serwera są audytowane? Potwierdzono, że lista „Skonfigurowanych integracji” w panelu AppsFlyer mapuje się jasno na partnerów marketingowych ujawnionych w banerze.
- Czy usuwanie danych jest zautomatyzowane? Potwierdzono, że żądania DSAR wyzwalają API usuwania AppsFlyer, a nie ręczny bilet.
Gdzie AppsFlyer pasuje do stosu z priorytetem zgody
Atrybucja mobilna jest jedną z najbardziej obciążonych identyfikatorami powierzchni w stosie marketingowym, a SDK AppsFlyer jest jedną z jego najważniejszych pojedynczych integracji. Dobrą wiadomością jest to, że platforma udostępnia prymitywy — Start SDK, Stop, filtry udostępniania, API usuwania — potrzebne do czystego i weryfikowalnego egzekwowania zgody. Praca dla wydawców polega na podłączeniu tych prymitywów do CMP, który posiada wiążącą decyzję o zgodzie, traktowaniu ATT jako sygnału uzupełniającego, a nie zastępstwa, i upewnieniu się, że przekazywanie po stronie serwera do partnerów nie może uciec poza kopertę zgody zarejestrowanej przez baner. Wykonane prawidłowo, efektem jest stos atrybucji, który satysfakcjonuje regultorów, jednocześnie zachowując dane dotyczące instalacji i zdarzeń, od których zależą zespoły pozyskiwania użytkowników.