Što AppsFlyer Prikuplja

AppsFlyer SDK inicijalizira sesiju čim domaćinska aplikacija počne i, prema zadanim postavkama, prikuplja paket identifikatora i kontekstualnih signala: identifikator oglašavanja na razini uređaja (IDFA na iOS-u, GAID na Androidu), IDFV opsega dobavljača na iOS-u, generirani AppsFlyer ID instalacije koji perzistira kroz sesije, IP adresu (koristi se za geo-IP i za probabilističko podudaranje u stilu otiska prsta), korisnički agent, model uređaja, verziju OS-a, mrežnog operatora i vremensku zonu. Nakon instalacije SDK prijavljuje događaj instalacije AppsFlyer serverima, gdje se podudara s podacima klikova koje su proslijedile reklamne mreže. Naknadni događaji unutar aplikacije — Purchase, RegistrationComplete, Tutorial Complete, Custom — okidaju se kroz isti SDK i nasljeđuju isti skup identifikatora.

Regulatori su bili eksplicitni da je ovo procesiranje osobnih podataka prema GDPR-u. IDFA i GAID su osobni podaci jer su trajni identifikatori na razini uređaja. Probabilističko podudaranje otisaka prstiju koje radi uz njih još je teže braniti bez pristanka jer je, po definiciji, pokušaj identifikacije korisnika bez njihove eksplicitne suradnje. CNIL, talijanski Garante i španjolski AEPD svi su otvorili istrage protiv izdavača čiji su atribucijski stogovi okidali prije pristanka.

Nativni Kontrole Privatnosti AppsFlyer-a

AppsFlyer izlaže smislen skup nativnih primitiva privatnosti. Oni nisu zamjena za pravi okvir pristanka, ali razumijevanje njih je ključno jer su to poluge koje CMP koristi za kontrolu ponašanja SDK-a.

Start SDK API

SDK podržava način inicijalizacije gdje je konfiguriran ali ne prenosi nikakve podatke dok se start() eksplicitno ne pozove. Ovo je najvažnija kuka za postavljanje vrata pristanka — prema zadanim postavkama SDK se automatski pokreće pri pokretanju aplikacije, što je pogrešno ponašanje za svaku jurisdikciju s prethodnim zahtjevom pristanka. Postavite isStopped na true pri inicijalizaciji, ili koristite odgođeni start API, i pozovite start() samo kada je signal pristanka zabilježen.

Stop API

Ako se pristanak povuče usred sesije, pozivanje stop() zaustavlja sav daljnji prijenos. Ne briše retroaktivno već poslane podatke. Za potpuno brisanje trebate podnijeti zahtjev za brisanje subjekta podataka putem portala za privatnost AppsFlyer-a — integracijski timovi to trebaju automatizirati putem AppsFlyer API-ja umjesto ručnog toka rada.

setSharingFilter

Ovo filtrira koje reklamne mreže nizvodnog smjera primaju postback podatke. To je pravi primitiv za granularni pristanak po partneru — na primjer, dopuštajući atribuciju općenito ali blokirajući prosljeđivanja određenoj mreži koju je korisnik odbio.

Integracija Apple App Tracking Transparency

Na iOS-u, AppsFlyer čita status autorizacije ATT i automatski prilagođava svoje ponašanje — ako je korisnik odbio ATT, IDFA se ne prenosi. ATT je neovisan od GDPR pristanka, a mnogi izdavači ih miješaju. ATT kontrolira jedan iOS-razinski signal; GDPR pristanak kontrolira sve ostalo.

Integracija na iOS-u

Pouzdani obrazac na iOS-u je instalirati AppsFlyer SDK ali odgoditi inicijalizaciju dok i ATT i tok pristanka unutar aplikacije ne budu dovršeni. Minimalni redoslijed je: aplikacija se pokreće, SDK je konfiguriran s isStopped = true, prikazuje se banner za pristanak unutar aplikacije, korisnik prihvaća relevantne kategorije, zastavica isStopped SDK-a se briše i poziva se start(). Ako aplikacija treba i ATT (što treba za svakog korisnika za kojeg je IDFA značajan), ATT prompt se prikazuje zajedno s ili nakon bannera unutar aplikacije. Većina CMP-ova koji podržavaju mobilne uređaje imaju API temeljen na povratu poziva koji isporučuje odluku o pristanku; taj povrat poziva je pravo mjesto za pozivanje start().

Integracija na Androidu

Android implementacija paralelna je iOS-u s dvije razlike. Prvo, nema ATT ekvivalenta — GAID je dostupan osim ako korisnik nije pozvao svoju postavku na razini uređaja "Izbriši ID oglašavanja", što većina korisnika ne radi. Drugo, Androidov životni ciklus agresivniji je u pogledu prelaska u pozadinu, pa inicijalizacija SDK-a mora biti vezana uz stanje pristanka koje je trajno pohranjeno. Pročitajte stanje pristanka iz lokalnog pohrana pri pokretanju aplikacije, konfigurirajte SDK sukladno tome i ponovo provjerite pri nastavku u slučaju da je korisnik ažurirao svoj izbor dok je aplikacija bila u pozadini.

Integracija na Mobilnom Webu

AppsFlyer također djeluje na mobilnom webu putem svojih proizvoda pametnog bannera i OneLink. To su u suštini analitički alati i alati za duboke linkove na strani weba koji ispuštaju kolačiće i pozivaju AppsFlyer servere iz preglednika. Slijede ista pravila kao i svaka druga web površina za praćenje: stavite ih iza marketinške kategorije CMP-a, ne dopustite pokretanje skripte pametnog bannera prije nego što je odobreni pristanak, i osigurajte da svaki događaj koji je pokrenuo OneLink iz e-mail ili push kampanja poštuje stanje pristanka korisnika.

Uobičajene Zamke

Četiri greške integracije pojavljuju se opetovano u revizijama AppsFlyer implementacija.

Tretiranje ATT-a kao GDPR pristanka

ATT i GDPR pristanak su različiti signali s različitim opsezima. Korisnik koji prihvati ATT ovlastio je korištenje IDFA-e za praćenje između aplikacija; nisu ovlastili sve ostalo što SDK radi. Za EU i UK promet potrebna su oba signala, a banner unutar aplikacije je obvezujući, dok je ATT iOS-specifični sloj povrh njega.

Dopuštanje SDK-u da se inicijalizira pri pokretanju

Ovo je najčešći jedini nedostatak. Zadana integracija odmah poziva start(), što pokreće događaj instalacije s punim identifikatorskim payload-om prije nego je korisnik vidio banner za pristanak. Sanacija je jednostavna: konfigurirajte isStopped = true u trenutku integracije i pozovite start() samo iz povrata poziva pristanka.

Zaboravljanje rukovanja povlačenjem

Ako korisnik prihvati i kasnije opozove, SDK-u treba reći da prestane prenositi. Koristite stop() API i ažurirajte trajno pohranjeno stanje pristanka kako bi sljedeće pokretanje aplikacije poštovalo novu odluku.

Ignoriranje postbackova između servera

AppsFlyer prosljeđuje konverzijske događaje dugom nizu integriranih reklamnih mreža putem postbackova na strani servera. Svako prosljeđivanje nosi osobne podatke i nasljeđuje opseg pristanka originalnog događaja. Koristite setSharingFilter kako biste osigurali da prosljeđivanja idu samo partnerima koje pokrivaju korisnikovi izbori pristanka, a ne svakom partneru u vašoj AppsFlyer nadzornoj ploči.

Kontrolna Lista Revizije

Šest konkretnih pitanja na koja treba odgovoriti za svaku AppsFlyer implementaciju koja dodiruje EU, UK ili kalifornijski promet.

• Čeka li SDK pristanak? Na novoj instalaciji na testnom uređaju smještenom u EU, potvrdite da nijedan AppsFlyer endpoint ne prima nikakav zahtjev prije nego korisnik prihvati banner.
• Je li ATT odvojen od pristanka unutar aplikacije? Potvrdite da je banner unutar aplikacije kontrolirajući signal pristanka i da se ATT tretira kao dodatni iOS-specifični sloj.
• Je li prosljeđivanje partnera ograničeno na pristanak? Potvrdite da je setSharingFilter konfiguriran za isključivanje partnera koje korisnik nije ovlastio.
• Zaustavlja li povlačenje SDK? Potvrdite da pozivanje stop() funkcionira pri opozivu pristanka i da novo stanje perzistira kroz pokretanja.
• Jesu li serverski postbackovi revidirani? Potvrdite da popis "Konfiguriranih integracija" AppsFlyer nadzorne ploče jasno odgovara marketinškim partnerima objavljenim u banneru.
• Je li brisanje podataka automatizirano? Potvrdite da DSAR zahtjevi pokretaju API brisanja AppsFlyer-a, a ne ručni ticket.

Gdje AppsFlyer Odgovara u Stog Temeljen na Pristanku

Mobilna atribucija jedna je od površina s najviše identifikatora u marketinškom stogu, a SDK AppsFlyer-a jedna je od njegovih najvažnijih pojedinačnih integracija. Dobra vijest je da platforma izlaže primitive — Start SDK, Stop, filtre dijeljenja, API-je brisanja — potrebne za čisto i provjerljivo provođenje pristanka. Posao za izdavače je povezati te primitive s CMP-om koji posjeduje obvezujuću odluku o pristanku, tretirati ATT kao komplementarni signal umjesto zamjene, i osigurati da prosljeđivanje partnera na strani servera ne može pobjeći iz omotnice pristanka koji je banner zabilježio. Ispravno napravljeno, rezultat je atribucijski stog koji zadovoljava regulatore uz očuvanje podataka o instalacijama i događajima od kojih ovise timovi za akviziciju korisnika.