Ano ang Kinokolekta ng AppsFlyer

Ang AppsFlyer SDK ay nagsi-initialize ng session sa sandaling magsimula ang host app at, bilang default, nangongolekta ng bundle ng mga identifier at contextual na signal: ang device-level na advertising identifier (IDFA sa iOS, GAID sa Android), ang vendor-scoped na IDFV sa iOS, isang nabuong AppsFlyer install ID na nagtatagal sa mga session, IP address (ginagamit para sa geo-IP at para sa probabilistic matching na katulad ng fingerprint), user agent, modelo ng device, bersyon ng OS, carrier, at timezone. Pagkatapos ng pag-install, ang SDK ay nag-uulat ng install event sa mga server ng AppsFlyer, kung saan ito ay itutugma sa data ng click na ipinasa ng mga ad network. Kasunod na mga in-app event — Purchase, RegistrationComplete, Tutorial Complete, Custom — ay nagpapaputok sa pamamagitan ng parehong SDK at minana ang parehong hanay ng identifier.

Ang mga regulator ay malinaw na nagsabi na ito ay pagpoproseso ng personal na data sa ilalim ng GDPR. Ang IDFA at GAID ay personal na data dahil sila ay mga persistent na device-level na identifier. Ang probabilistic fingerprint matching na tumatakbo kasabay ay mas mahirap pang ipagtanggol nang walang pahintulot dahil ito ay, sa kahulugan, isang pagtatangka na tukuyin ang isang user nang walang kanilang malinaw na kooperasyon. Ang CNIL, ang Italian na Garante, at ang Spanish na AEPD ay lahat ay nagbukas ng mga imbestigasyon laban sa mga publisher na ang mga attribution stack ay nagpaputok bago ang pahintulot.

Mga Native na Privacy Control ng AppsFlyer

Ang AppsFlyer ay naglalantad ng makabuluhang hanay ng mga native na privacy primitive. Hindi sila kapalit ng tunay na consent framework, ngunit ang pag-unawa sa kanila ay mahalaga dahil sila ang mga lever na ginagamit ng CMP upang kontrolin ang gawi ng SDK.

Ang Start SDK API

Sinusuportahan ng SDK ang isang initialization mode kung saan ito ay naka-configure ngunit hindi nagpapadala ng anumang data hanggang ang start() ay malinaw na tinawag. Ito ang pinaka-mahalagang hook para sa consent gating — bilang default ang SDK ay awtomatikong nagsisimula sa paglulunsad ng app, na siyang maling gawi para sa anumang hurisdiksyon na may kinakailangan ng prior-consent. Itakda ang isStopped sa true sa initialization, o gamitin ang deferred-start API, at tawagan lamang ang start() kapag ang consent signal ay naitala.

Stop API

Kung ang pahintulot ay inalis sa kalagitnaan ng session, ang pagtawag sa stop() ay nagpapatigil ng lahat ng karagdagang pagpapadala. Hindi nito retroactively tinatanggal ang data na naipadala na. Para sa kumpletong pagtanggal kailangan mong maghain ng kahilingan ng pagtanggal ng data subject sa pamamagitan ng privacy portal ng AppsFlyer — isang integration team ang dapat mag-automate nito sa pamamagitan ng AppsFlyer API kaysa sa manu-manong workflow.

setSharingFilter

Fini-filter nito kung aling mga downstream na ad network ang makakatanggap ng postback data. Ito ang tamang primitive para sa granular na bawat-partner na pahintulot — halimbawa, pinapayagan ang attribution sa pangkalahatan ngunit hinaharang ang mga pasulong sa isang partikular na network na tinanggihan ng user.

Apple App Tracking Transparency na integration

Sa iOS, ang AppsFlyer ay nagbabasa ng ATT authorization status at awtomatikong inaangkop ang gawi nito — kung tinanggihan ng user ang ATT, ang IDFA ay hindi ipinadadala. Ang ATT ay independyente mula sa GDPR na pahintulot, at maraming publisher ang nagtatalo sa kanila. Ang ATT ay kumokontrol ng isang iOS-level na signal; ang GDPR na pahintulot ay kumokontrol ng lahat ng iba.

Integration sa iOS

Ang maaasahang pattern sa iOS ay i-install ang AppsFlyer SDK ngunit i-defer ang initialization hanggang sa makumpleto ang parehong ATT at ang in-app consent flow. Ang minimal na sequence ay: ang app ay naglulunsad, ang SDK ay naka-configure gamit ang isStopped = true, ang in-app consent banner ay ipinapakita, ang user ay tumatanggap ng mga kaugnay na kategorya, ang isStopped flag ng SDK ay nali-clear at start() ay tinatawag. Kung ang app ay nangangailangan din ng ATT (na ginagawa nito para sa anumang user kung saan ang IDFA ay mahalaga), ang ATT prompt ay ipinapakita kasabay o pagkatapos ng in-app banner. Karamihan sa mga CMP na sumusuporta sa mobile ay may callback-based na API na naghahatid ng desisyon ng pahintulot; ang callback na iyon ang tamang lugar para tawagan ang start().

Integration sa Android

Ang Android implementation ay kaparalelo ng iOS na may dalawang pagkakaiba. Una, walang katumbas ng ATT — ang GAID ay available maliban kung ginamit ng user ang kanilang device-level na setting na “I-delete ang advertising ID”, na karamihan sa mga user ay hindi ginagawa. Pangalawa, ang lifecycle ng Android ay mas agresibo sa backgrounding, kaya ang SDK initialization ay kailangang nakatali sa consent state na nakaimbak nang patuloy. Basahin ang consent state mula sa local storage sa paglulunsad ng app, i-configure ang SDK nang naaayon, at suriin muli sa resume kung sakaling nag-update ang user ng kanilang pagpipilian habang ang app ay naka-background.

Integration sa Mobile Web

Ang AppsFlyer ay gumagana rin sa mobile web sa pamamagitan ng mga produktong smart banner at OneLink nito. Ang mga ito ay mahalagang mga analytics at deep-link tool sa web-side na nagdadahulog ng cookies at tumatawag sa mga server ng AppsFlyer mula sa browser. Sinusunod nila ang parehong mga patakaran gaya ng anumang ibang web tracking surface: lagyan ng gate ang mga ito sa likod ng marketing category ng CMP, huwag hayaang tumakbo ang smart banner script bago ibigay ang pahintulot, at tiyakin na ang anumang OneLink-triggered na event mula sa email o push campaign ay gumagalang sa consent state ng user.

Mga Karaniwang Pitfall

Apat na pagkakamali sa integration ang paulit-ulit na lumalabas sa mga audit ng mga deployment ng AppsFlyer.

Pagtrato sa ATT bilang GDPR na pahintulot

Ang ATT at GDPR na pahintulot ay iba’t ibang signal na may iba’t ibang saklaw. Ang isang user na tumatanggap ng ATT ay nagpahintulot ng paggamit ng IDFA para sa cross-app tracking; hindi nila pinahintulutan ang lahat ng iba pang ginagawa ng SDK. Para sa EU at UK na trapiko ang parehong signal ay kinakailangan, na ang in-app banner ang nakatali at ang ATT ay isang iOS-specific na layer sa ibabaw.

Pagpapahintulot sa SDK na mag-initialize sa paglulunsad

Ito ang pinaka-karaniwang solong depekto. Ang default na integration ay agad na tumatawag sa start(), na nagpapaputok ng install event na may buong identifier payload bago makita ng user ang consent banner. Ang remediation ay diretso: i-configure ang isStopped = true sa integration time at tawagan ang start() lamang mula sa consent callback.

Pagkalimot na pangasiwaan ang pag-withdraw

Kung ang isang user ay tumatanggap at mamaya ay nagbawi, ang SDK ay kailangang sabihan na itigil ang pagpapadala. Gamitin ang stop() API at i-update ang pinananatiling consent state para igalang ng susunod na paglulunsad ng app ang bagong desisyon.

Pagbabala ng server-to-server postbacks

Ang AppsFlyer ay nagpapadala ng mga conversion event sa mahabang buntot ng mga integrated na ad network sa pamamagitan ng mga server-side postback. Bawat pasulong ay nagdadala ng personal na data at minana ang consent scope ng orihinal na event. Gamitin ang setSharingFilter upang matiyak na ang mga pasulong ay pumupunta lamang sa mga partner na sinasaklaw ng pagpili ng pahintulot ng user, hindi sa bawat partner sa iyong AppsFlyer dashboard.

Audit Checklist

Anim na kongkretong tanong na sasagutin para sa anumang deployment ng AppsFlyer na nakakaapekto sa trapiko ng EU, UK, o California.

• Naghihintay ba ang SDK ng pahintulot? Sa isang sariwang install sa isang test device na nakalagay sa EU, kumpirmahin na walang AppsFlyer endpoint ang makakatanggap ng anumang kahilingan bago tanggapin ng user ang banner.
• Nakahiwalay ba ang ATT mula sa in-app consent? Kumpirmahin na ang in-app banner ang controlling consent signal at ang ATT ay itinuturing bilang karagdagang iOS-specific na layer.
• Nakatakda ba ang partner forwarding sa loob ng pahintulot? Kumpirmahin na ang setSharingFilter ay naka-configure upang ibukod ang mga partner na hindi pinagbigyan ng user.
• Hinihinto ba ng pag-withdraw ang SDK? Kumpirmahin na ang pagtawag sa stop() ay gumagana sa pagbawi ng pahintulot at na ang bagong state ay nagtatagal sa mga paglulunsad.
• Na-audit ba ang mga server postback? Kumpirmahin na ang listahan ng “Configured integrations” ng AppsFlyer dashboard ay malinaw na nag-uugnay sa mga marketing partner na inihayag sa banner.
• Na-automate ba ang pagtanggal ng data? Kumpirmahin na ang mga DSAR request ay nagpapalitaw ng deletion API ng AppsFlyer, hindi ng manu-manong tiket.

Kung Saan Akma ang AppsFlyer sa isang Consent-First Stack

Ang mobile attribution ay isa sa mga pinaka-identifier-heavy na surface sa marketing stack, at ang SDK ng AppsFlyer ay isa sa mga pinaka-makabuluhang solong integration nito. Ang magandang balita ay ang platform ay naglalantad ng mga primitive — Start SDK, Stop, mga sharing filter, mga deletion API — na kailangan upang gawing malinis at na-verify ang pagpapatupad ng pahintulot. Ang gawain para sa mga publisher ay ang ikonekta ang mga primitive na iyon sa isang CMP na nagmamay-ari ng binding na desisyon ng pahintulot, tratuhin ang ATT bilang isang karagdagang signal kaysa sa kapalit, at tiyakin na ang server-side na partner forwarding ay hindi makakalusot sa consent envelope na naitala ng banner. Kapag nagawa nang tama, ang resulta ay isang attribution stack na nagbibigay-kasiyahan sa mga regulator habang pinapanatili ang data ng install at event na umaasa ang mga user acquisition team.