Ce Colectează AppsFlyer

SDK-ul AppsFlyer inițializează o sesiune imediat ce aplicația gazdă porneśte şi, implicit, colectează un pachet de identificatori şi semnale contextuale: identificatorul de publicitate la nivel de dispozitiv (IDFA pe iOS, GAID pe Android), IDFV cu sferă de furnizor pe iOS, un ID de instalare AppsFlyer generat care persistă între sesiuni, adresa IP (folosită pentru geo-IP şi potrivire probabilistică de tip fingerprint), user agent, model de dispozitiv, versiune OS, operator şi fus orar. După instalare, SDK-ul raportează evenimentul de instalare către serverele AppsFlyer, unde este corelat cu datele de clic transmise de rețelele publicitare. Evenimentele ulterioare în aplicație — Purchase, RegistrationComplete, Tutorial Complete, Custom — sunt trimise prin acelaśi SDK şi mośtenesc acelaśi set de identificatori.

Autoritățile de reglementare au fost explicite că aceasta este prelucrare de date cu caracter personal în conformitate cu GDPR. IDFA şi GAID sunt date cu caracter personal deoarece sunt identificatori persisteni la nivel de dispozitiv. Potrivirea probabilistică de tip fingerprint care se desfăşoară în paralel este şi mai dificil de justificat fără consimțământ, deoarece este, prin definiție, o încercare de a identifica un utilizator fără cooperarea sa explicită. CNIL, Garante italian şi AEPD spaniol au deschis cu toții anchete împotriva editorilor ale căror stive de atribuire s-au activat înainte de consimțământ.

Controale Native de Confidențialitate AppsFlyer

AppsFlyer expune un set semnificativ de primitive native de confidențialitate. Acestea nu sunt un substitut pentru un cadru real de consimțământ, dar înțelegerea lor este esențială deoarece sunt pârghiile pe care un CMP le foloseśte pentru a controla comportamentul SDK-ului.

Start SDK API

SDK-ul suportă un mod de inițializare în care este configurat dar nu transmite niciun date până când start() nu este apelat explicit. Acesta este cel mai important singur hook pentru controlul consimțământului — implicit, SDK-ul porneśte automat la lansarea aplicației, ceea ce este comportamentul greśit pentru orice jurisdicție cu cerință de consimțământ prealabil. Setați isStopped la true la inițializare sau utilizați API-ul de pornire amânată şi apelați start() doar când semnalul de consimțământ este înregistrat.

Stop API

Dacă consimțământul este retras în mijlocul unei sesiuni, apelarea stop() opreśte toată transmisia ulterioară. Nu śtere retroactiv datele deja trimise. Pentru śtergerea completă, trebuie să depuneți o cerere de śtergere a subiectului de date prin portalul de confidențialitate AppsFlyer — pe care echipele de integrare ar trebui să o automatizeze via API-ul AppsFlyer mai degrabă decât un flux de lucru manual.

setSharingFilter

Aceasta filtrează care rețele publicitare downstream primesc date de postback. Este primitivul potrivit pentru consimțământ granular per-partener — de exemplu, permiterea atribuirii în general, dar blocarea transmiterilor către o anumită rețea pe care utilizatorul a respins-o.

Integrarea Apple App Tracking Transparency

Pe iOS, AppsFlyer citeśte statusul de autorizare ATT şi îi ajustează automat comportamentul — dacă utilizatorul a refuzat ATT, IDFA nu este transmis. ATT este independent de consimțământul GDPR, iar mulți editori îi confundă. ATT controlează un singur semnal la nivel iOS; consimțământul GDPR controlează orice altceva.

Integrare pe iOS

Modelul de încredere pe iOS este să instalați SDK-ul AppsFlyer, dar să amânați inițializarea până când atât ATT, cât şi fluxul de consimțământ din aplicație au fost finalizate. Secvența minimă este: aplicația se lansează, SDK-ul este configurat cu isStopped = true, bannerul de consimțământ din aplicație este afiśat, utilizatorul acceptă categoriile relevante, marcatorul isStopped al SDK-ului este śers şi start() este apelat. Dacă aplicația are nevoie śi de ATT (ceea ce are pentru orice utilizator pentru care IDFA este relevant), promptul ATT este afiśat în paralel cu sau după bannerul din aplicație. Majoritatea CMP-urilor care suportă mobile au un API bazat pe callback care livrează decizia de consimțământ; acel callback este locul potrivit pentru a apela start().

Integrare pe Android

Implementarea Android urmăreśte iOS cu două diferențe. În primul rând, nu există echivalent ATT — GAID este disponibil cu excepția cazului în care utilizatorul a invocat setarea de nivel dispozitiv „Ştergere ID publicitate”, ceea ce puțini utilizatori fac. În al doilea rând, ciclul de viață Android este mai agresiv cu privire la executarea în fundal, deci inițializarea SDK-ului trebuie să fie legată de starea de consimțământ stocată persistent. Citiți starea de consimțământ din stocarea locală la lansarea aplicației, configurați SDK-ul în consecință şi reverificați la reluare în cazul în care utilizatorul şi-a actualizat alegerea în timp ce aplicația era în fundal.

Integrare pe Web-ul Mobil

AppsFlyer operează de asemenea pe web-ul mobil prin produsele sale smart banner şi OneLink. Acestea sunt în esență instrumente de analiză web şi deep-link care plasează cookie-uri şi apelează serverele AppsFlyer din browser. Urmăresc aceleaśi reguli ca orice altă suprafață de urmărire web: pla-sați-le în spatele categoriei de marketing a CMP-ului, nu lăsați scriptul smart banner să ruleze înainte de acordarea consimțământului şi asigurați-vă că orice evenimente declanśate de OneLink din campanii de e-mail sau push respectă starea de consimțământ a utilizatorului.

Capcane Comune

Patru greśeli de integrare apar în mod repetat în auditurile implementarilors AppsFlyer.

Tratarea ATT ca consimțământ GDPR

ATT şi consimțământul GDPR sunt semnale diferite cu domenii diferite. Un utilizator care acceptă ATT a autorizat utilizarea IDFA pentru urmărirea între aplicații; nu a autorizat tot ceea ce face SDK-ul. Pentru traficul EU şi UK, ambele semnale sunt necesare, bannerul din aplicație fiind cel obligatoriu şi ATT fiind un strat specific iOS deasupra.

Permiterea SDK-ului să se inițializeze la lansare

Acesta este cel mai frecvent singur defect. Integrarea implicită apelează start() imediat, ceea ce declanśează evenimentul de instalare cu încărcătura completă de identificatori înainte ca utilizatorul să fi văzut bannerul de consimțământ. Remedierea este simplă: configurați isStopped = true la momentul integrării şi apelați start() numai din callback-ul de consimțământ.

Uitarea de a gestiona retragerea

Dacă un utilizator acceptă şi mai târziu revocă, SDK-ul trebuie informat să oprească transmisia. Utilizați API-ul stop() şi actualizați starea de consimțământ persistentă astfel încât următorul start al aplicației să respecte noua decizie.

Ignorarea postback-urilor server-la-server

AppsFlyer transmite evenimentele de conversie către o serie lungă de rețele publicitare integrate prin postback-uri server-side. Fiecare transmitere poartă date cu caracter personal şi mośteneśte sfera de consimțământ a evenimentului original. Utilizați setSharingFilter pentru a vă asigura că transmiterile merg numai către parteneri acoperiți de alegerile de consimțământ ale utilizatorului, nu către fiecare partener din panoul AppsFlyer.

Listă de Verificare pentru Audit

Şase întrebări concrete la care trebuie să răspundeți pentru orice implementare AppsFlyer care atinge traficul EU, UK sau California.

• SDK-ul aśteaptă consimțământul? La o instalare proaspătă pe un dispozitiv de test localizat în EU, confirmați că niciun endpoint AppsFlyer nu primeśte nicio solicitare înainte ca utilizatorul să fi acceptat bannerul.
• ATT este separat de consimțământul din aplicație? Confirmați că bannerul din aplicație este semnalul de consimțământ de control şi că ATT este tratat ca un strat suplimentar specific iOS.
• Transmiterea către parteneri este limitată la consimțământ? Confirmați că setSharingFilter este configurat pentru a exclude partenerii pe care utilizatorul nu i-a autorizat.
• Retragerea opreśte SDK-ul? Confirmați că apelarea stop() funcționează la revocarea consimțământului şi că noua stare persistă între lansari.
• Postback-urile de server sunt auditate? Confirmați că lista „Integrări configurate” din panoul AppsFlyer se mapează clar la partenerii de marketing dezvaluți în banner.
• Ştergerea datelor este automatizată? Confirmați că solicitările DSAR declanśează API-ul de śtergere AppsFlyer, nu un ticket manual.

Unde se Potriveśte AppsFlyer într-un Stack cu Consimțământul pe Primul Loc

Atribuirea mobilă este una dintre suprafețele cele mai încărcate de identificatori din stiva de marketing, iar SDK-ul AppsFlyer este una dintre cele mai importante integrări individuale ale sale. Vestea bună este că platforma expune primitivele — Start SDK, Stop, filtre de partajare, API-uri de śtergere — necesare pentru a face aplicarea consimțământului curată şi verificabilă. Munca pentru editori este să conecteze aceste primitive la un CMP care deține decizia de consimțământ obligatorie, să trateze ATT ca un semnal complementar mai degrabă decât un înlocuitor şi să se asigure că transmiterea partenerilor server-side nu poate scăpa din plicul de consimțământ înregistrat de banner. Făcut corect, rezultatul este o stivă de atribuire care satisface regulatorii, păstrând în acelaśi timp datele de instalare śi eveniment de care echipele de achiziție a utilizatorilor depind.