AppsFlyer mobilā atribūcija un sīkdatņu piekrišana: 2026. gada integrācijas ceļvedis lietotņu izdevējiem
Lietotņu izstrādātājiem mobilā mērīšana ir principiāli atšķirīga problēma salīdzinājumā ar tīmekļa mērīšanu. Sīkdatnes, par kurām uztraucas tīmekļa izdevēji, neeksistē natīvajā lietotnē, taču identifikatori, kas tās aizvieto — IDFA, GAID, IDFV, instalācijas ID, šifrēti e-pasti, IP atvasināti ierīces nospiedumi — rada tos pašus juridiskos jautājumus un atbild tiem pašiem regulatoriem. AppsFlyer, visplašāk izvietotais mobilās mērīšanas partneris mobilajās spēlēs, fintech un patērētāju lietotnēs, atrodas šīs cauruļvada vidū. Tā SDK savāc atribūcijas līmeņa identifikatorus, tā serveri tos korelē ar reklāmas tīklu postback ziņojumiem, un iegūtā atribūcija novirza lietotāju piesaistes budžetus visos galvenajos kanālos. Neviena no šīm apstrādēm nenotiek bez likumīga pamata, un likumīgais pamats, ko GDPR un ePrivacy direktīva faktiski pieprasa, ir piekrišana — savākta pirms SDK inicializācijas, ierakstīta kā pierādījums un izplatīta katrai pakārtotajai integrācijai. Šī rokasgrāmata izskata, ko AppsFlyer savāc, kā to integrēt ar piekrišanas pārvaldības sistēmu iOS, Android un mobilajā tīmeklī, un kā platformas paša privātuma primitīvi (Start SDK API, ATT signāli un Datu privātuma ietvars) iekļaujas kopainā.
Ko AppsFlyer savāc
AppsFlyer SDK inicializē sesiju, tiklīdz resursdatora lietotne startē, un pēc noklusējuma savāc identifikatoru un kontekstuālo signālu komplektu: ierīces līmeņa reklāmas identifikatoru (IDFA iOS, GAID Android), piegādātāja tvēruma IDFV iOS, ģenerētu AppsFlyer instalācijas ID, kas saglabājas starp sesijām, IP adresi (izmanto ģeo-IP un pirkstu nospieduma stila varbūtības saskaņošanai), lietotāja aģentu, ierīces modeli, OS versiju, operatoru un laika joslu. Pēc instalācijas SDK ziņo instalācijas notikumu AppsFlyer serveriem, kur tas tiek saskaņots ar klikšķu datiem, ko pārsūtījuši reklāmas tīkli. Turpmākie lietotnes iekšējie notikumi — Pirkums, ReģistrācijaPabeigta, Pamācība pabeigta, Pielāgots — tiek aktivizēti caur to pašu SDK un pārmanto to pašu identifikatoru kopu.
Regulatori ir skaidri norādījuši, ka šī ir personas datu apstrāde saskaņā ar GDPR. IDFA un GAID ir personas dati, jo tie ir pastāvīgi ierīces līmeņa identifikatori. Varbūtības pirkstu nospieduma saskaņošana, kas darbojas paralēli, ir vēl grūtāk aizstāvama bez piekrišanas, jo tā pēc definīcijas ir mēģinājums identificēt lietotāju bez viņa tiešas sadarbības. CNIL, Itālijas Garante un Spānijas AEPD ir uzsākušas izmeklēšanas pret izdevējiem, kuru atribūcijas steki aktivizējās pirms piekrišanas.
AppsFlyer natīvās privātuma vadīklas
AppsFlyer piedāvā nozīmīgu natīvo privātuma primitīvu kopu. Tie nav reālas piekrišanas sistēmas aizstājēji, bet to izpratne ir būtiska, jo tie ir sviras, ko CMP izmanto SDK uzvedības kontrolei.
Start SDK API
SDK atbalsta inicializācijas režīmu, kurā tas ir konfigurēts, bet nepārsūta nekādus datus, kamēr nav skaidri izsaukts start(). Šis ir vissvarīgākais āķis piekrišanas vārtēšanai — pēc noklusējuma SDK startē automātiski lietotnes palaišanas brīdī, kas ir nepareiza uzvedība jebkurai jurisdikcijai ar iepriekšējas piekrišanas prasību. Iestatiet isStopped uz true inicializācijā vai izmantojiet atliktā starta API un izsauciet start() tikai tad, kad piekrišanas signāls ir ierakstīts.
Stop API
Ja piekrišana tiek atsaukta sesijas laikā, stop() izsaukšana aptur visu turpmāko pārsūtīšanu. Tā retroaktīvi neizdzēš jau nosūtītos datus. Pilnīgai dzēšanai jāiesniedz datu subjekta dzēšanas pieprasījums caur AppsFlyer privātuma portālu — integrācijas komandām tas jāautomatizē caur AppsFlyer API, nevis manuālu darbplūsmu.
setSharingFilter
Šis filtrē, kuri pakārtotie reklāmas tīkli saņem postback datus. Tas ir pareizais primitīvs detalizētai piekrišanai pa partneriem — piemēram, atļaujot atribūciju kopumā, bet bloķējot pārsūtīšanu konkrētam tīklam, ko lietotājs ir noraidījis.
Apple App Tracking Transparency integrācija
iOS ierīcēs AppsFlyer nolasa ATT autorizācijas statusu un automātiski pielāgo savu uzvedību — ja lietotājs noraidīja ATT, IDFA netiek pārsūtīts. ATT ir neatkarīgs no GDPR piekrišanas, un daudzi izdevēji tos sajauc. ATT kontrolē vienu iOS līmeņa signālu; GDPR piekrišana kontrolē visu pārējo.
Integrācija iOS
Uzticamais modelis iOS ir instalēt AppsFlyer SDK, bet atlikt inicializāciju, līdz gan ATT, gan lietotnes iekšējā piekrišanas plūsma ir pabeigta. Minimālā secība ir: lietotne startē, SDK tiek konfigurēts ar isStopped = true, lietotnes iekšējais piekrišanas baneris tiek parādīts, lietotājs pieņem attiecīgās kategorijas, SDK isStopped karodziņš tiek notīrīts un tiek izsaukts start(). Ja lietotnei ir nepieciešams arī ATT (kas ir nepieciešams jebkuram lietotājam, kuram IDFA ir nozīmīgs), ATT uzvedne tiek parādīta līdztekus vai pēc lietotnes iekšējā banera. Lielākajai daļai CMP, kas atbalsta mobilo, ir uz atzvanīšanu balstīta API, kas piegādā piekrišanas lēmumu; šī atzvanīšana ir pareizā vieta, kur izsaukt start().
Integrācija Android
Android implementācija paralēli atkārto iOS ar divām atšķirībām. Pirmkārt, nav ATT ekvivalenta — GAID ir pieejams, ja vien lietotājs nav aktivizējis ierīces līmeņa "Dzēst reklāmas ID" iestatījumu, ko lielākā daļa lietotāju nedara. Otrkārt, Android dzīves cikls ir agresīvāks attiecībā uz fona režīmu, tāpēc SDK inicializācijai jābūt piesaistītai piekrišanas stāvoklim, kas tiek pastāvīgi glabāts. Nolasiet piekrišanas stāvokli no lokālās krātuves lietotnes palaišanas brīdī, attiecīgi konfigurējiet SDK un atkārtoti pārbaudiet atsākšanas brīdī gadījumam, ja lietotājs atjaunināja savu izvēli, kamēr lietotne bija fonā.
Integrācija mobilajā tīmeklī
AppsFlyer darbojas arī mobilajā tīmeklī caur saviem viedā banera un OneLink produktiem. Tie būtībā ir tīmekļa puses analītikas un dziļo saišu rīki, kas ievieto sīkdatnes un izsauc AppsFlyer serverus no pārlūkprogrammas. Tie pakļaujas tiem pašiem noteikumiem kā jebkura cita tīmekļa izsekošanas virsma: vārtējiet tos aiz CMP mārketinga kategorijas, neļaujiet viedā banera skriptam darboties pirms piekrišanas piešķiršanas un nodrošiniet, ka jebkuri OneLink aktivizēti notikumi no e-pasta vai push kampaņām ievēro lietotāja piekrišanas stāvokli.
Biežākās kļūdas
Četras integrācijas kļūdas atkārtoti parādās AppsFlyer izvietojumu auditos.
ATT uzskatīšana par GDPR piekrišanu
ATT un GDPR piekrišana ir dažādi signāli ar dažādu tvērumu. Lietotājs, kurš pieņem ATT, ir autorizējis IDFA izmantošanu starplietotņu izsekošanai; viņš nav autorizējis visu pārējo, ko SDK dara. EU un UK trafikam ir nepieciešami abi signāli, kur lietotnes iekšējais baneris ir saistošais un ATT ir iOS specifisks papildslānis.
SDK inicializēšanas atļaušana palaišanas brīdī
Šis ir visbiežākais atsevišķais defekts. Noklusējuma integrācija izsauc start() nekavējoties, kas aktivizē instalācijas notikumu ar pilnu identifikatoru slodzi pirms lietotājs ir redzējis piekrišanas baneri. Labojums ir vienkāršs: konfigurējiet isStopped = true integrācijas laikā un izsauciet start() tikai no piekrišanas atzvanīšanas.
Aizmirstot apstrādāt atsaukšanu
Ja lietotājs pieņem un vēlāk atsauc, SDK ir jāpaziņo, lai pārtrauc pārsūtīšanu. Izmantojiet stop() API un atjauniniet pastāvīgi saglabāto piekrišanas stāvokli, lai nākamā lietotnes palaišana ievērotu jauno lēmumu.
Servera-servera postback ignorēšana
AppsFlyer pārsūta konversijas notikumus garai integrēto reklāmas tīklu rindai caur servera puses postback. Katra pārsūtīšana satur personas datus un pārmanto oriģinālā notikuma piekrišanas tvērumu. Izmantojiet setSharingFilter, lai nodrošinātu, ka pārsūtīšanas nonāk tikai pie partneriem, kurus aptver lietotāja piekrišanas izvēles, nevis pie katra partnera jūsu AppsFlyer panelī.
Audita kontrolsaraksts
Seši konkrēti jautājumi, uz kuriem jāatbild jebkuram AppsFlyer izvietojumam, kas skar EU, UK vai Kalifornijas trafiku.
- Vai SDK gaida piekrišanu? Svaigā instalācijā EU atrašanās vietas testa ierīcē apstipriniet, ka neviens AppsFlyer galapunkts nesaņem nekādu pieprasījumu pirms lietotājs ir pieņēmis baneri.
- Vai ATT ir atdalīts no lietotnes iekšējās piekrišanas? Apstipriniet, ka lietotnes iekšējais baneris ir kontrolējošais piekrišanas signāls un ATT tiek uzskatīts par papildu iOS specifisko slāni.
- Vai partneru pārsūtīšana ir tvērta atbilstoši piekrišanai? Apstipriniet, ka setSharingFilter ir konfigurēts, lai izslēgtu partnerus, kurus lietotājs nav autorizējis.
- Vai atsaukšana aptur SDK? Apstipriniet, ka stop() izsaukšana darbojas piekrišanas atsaukšanas brīdī un ka jaunais stāvoklis saglabājas starp palaišanām.
- Vai servera postback ir auditēti? Apstipriniet, ka AppsFlyer paneļa "Konfigurētās integrācijas" saraksts tīri saskan ar mārketinga partneriem, kas atklāti banerī.
- Vai datu dzēšana ir automatizēta? Apstipriniet, ka DSAR pieprasījumi aktivizē AppsFlyer dzēšanas API, nevis manuālu pieteikumu.
Kur AppsFlyer iekļaujas piekrišanas prioritātes stekā
Mobilā atribūcija ir viena no identifikatoru intensīvākajām virsmām mārketinga stekā, un AppsFlyer SDK ir viena no tā nozīmīgākajām atsevišķajām integrācijām. Labā ziņa ir tāda, ka platforma piedāvā primitīvus — Start SDK, Stop, koplietošanas filtrus, dzēšanas API — kas nepieciešami, lai piekrišanas izpilde būtu tīra un pārbaudāma. Izdevēju darbs ir savienot šos primitīvus ar CMP, kas pārvalda saistošo piekrišanas lēmumu, uzskatīt ATT par papildinošu signālu, nevis aizstājēju, un nodrošināt, ka servera puses partneru pārsūtīšana nevar izkļūt no piekrišanas aploksnes, ko baneris ierakstīja. Pareizi izdarīts, rezultāts ir atribūcijas steks, kas apmierina regulatorus, vienlaikus saglabājot instalācijas un notikumu datus, no kuriem ir atkarīgas lietotāju piesaistes komandas.