Què Recull AppsFlyer

El SDK d'AppsFlyer inicialitza una sessió tan aviat com l'aplicació amfitriona s'inicia i, per defecte, recull un paquet d'identificadors i senyals contextuals: l'identificador publicitari a nivell de dispositiu (IDFA a iOS, GAID a Android), l'IDFV amb àmbit de proveïdor a iOS, un ID d'instal·lació d'AppsFlyer generat que persisteix entre sessions, adreça IP (utilitzada per geo-IP i per a coincidències probabilístiques d'estil empremta digital), agent d'usuari, model de dispositiu, versió d'OS, operador i zona horària. Després de la instal·lació, el SDK informa de l'esdeveniment d'instal·lació als servidors d'AppsFlyer, on es fa coincidir amb les dades de clic reenviades per xarxes publicitàries. Els esdeveniments posteriors dins l'aplicació —Purchase, RegistrationComplete, Tutorial Complete, Custom— es disparen a través del mateix SDK i hereten el mateix conjunt d'identificadors.

Els reguladors han estat explícits que això és processament de dades personals segons el GDPR. L'IDFA i el GAID són dades personals perquè són identificadors persistents a nivell de dispositiu. La coincidència d'empremtes digitals probabilístiques que s'executa al costat és encara més difícil de defensar sense consentiment perquè és, per definició, un intent d'identificar un usuari sense la seva cooperació explícita. La CNIL, la Garante italiana i l'AEPD espanyola han obert totes investigacions contra editors els stacks d'atribució dels quals es disparaven abans del consentiment.

Controls Nadius de Privacitat d'AppsFlyer

AppsFlyer exposa un conjunt significatiu de primitives nadives de privacitat. No són un substitut d'un marc de consentiment real, però entendre-les és essencial perquè són les palanques que un CMP utilitza per controlar el comportament del SDK.

L'API Start SDK

El SDK suporta un mode d'inicialització on es configura però no transmet cap dada fins que start() es crida explícitament. Aquest és el ganxo individual més important per a la porta de consentiment —per defecte el SDK s'inicia automàticament a l'arrencada de l'aplicació, que és el comportament incorrecte per a qualsevol jurisdicció amb un requisit de consentiment previ. Establiu isStopped a true a la inicialització, o utilitzeu l'API d'inici diferit, i només crideu start() quan el senyal de consentiment estigui registrat.

API Stop

Si el consentiment es retira a mig sessió, cridar stop() atura tota transmissió posterior. No elimina retroactivament les dades ja enviades. Per a una eliminació completa necessiteu presentar una sol·licitud d'eliminació de dades de subjecte de dades a través del portal de privacitat d'AppsFlyer —una integració que els equips haurien d'automatitzar via l'API d'AppsFlyer en lloc d'un flux de treball manual.

setSharingFilter

Això filtra quines xarxes publicitàries posteriors reben dades de postback. És la primitiva adequada per al consentiment granular per soci —per exemple, permetre l'atribució generalment però bloquejar els reenviaments a una xarxa específica que l'usuari ha rebutjat.

Integració d'Apple App Tracking Transparency

A iOS, AppsFlyer llegeix l'estat d'autorització ATT i ajusta el seu comportament automàticament —si l'usuari va declinar ATT, l'IDFA no es transmet. ATT és independent del consentiment GDPR, i molts editors els confonen. ATT controla un únic senyal a nivell d'iOS; el consentiment GDPR controla tot el resta.

Integració a iOS

El patró fiable a iOS és instal·lar el SDK d'AppsFlyer però diferir la inicialització fins que tant ATT com el flux de consentiment dins l'aplicació s'hagin completat. La seqüència mínima és: l'aplicació s'inicia, el SDK es configura amb isStopped = true, el bàner de consentiment dins l'aplicació es mostra, l'usuari accepta les categories rellevants, la bandera isStopped del SDK s'esborra i start() es crida. Si l'aplicació també necessita ATT (que ho fa per a qualsevol usuari on l'IDFA sigui significatiu), l'indicador d'ATT es mostra al costat o després del bàner dins l'aplicació. La majoria de CMPs que suporten mòbil tenen una API basada en callbacks que lliura la decisió de consentiment; aquest callback és el lloc adequat per cridar start().

Integració a Android

La implementació d'Android és paral·lela a iOS amb dues diferències. Primer, no hi ha equivalent d'ATT —el GAID està disponible tret que l'usuari hagi invocat la seva configuració a nivell de dispositiu "Eliminar ID publicitari", que la majoria d'usuaris no fan. Segon, el cicle de vida d'Android és més agressiu sobre l'execució en segon pla, així que la inicialització del SDK s'ha de vincular a l'estat de consentiment emmagatzemat de manera persistent. Llegiu l'estat de consentiment des de l'emmagatzematge local a l'arrencada de l'aplicació, configureu el SDK en conseqüència, i torneu a comprovar en reprendre per si l'usuari ha actualitzat la seva elecció mentre l'aplicació estava en segon pla.

Integració al Web Mòbil

AppsFlyer també opera al web mòbil a través dels seus productes de bàner intel·ligent i OneLink. Aquestes són essencialment eines d'analítica del costat web i enllaços profunds que deixen cookies i criden servidors d'AppsFlyer des del navegador. Segueixen les mateixes regles que qualsevol altra superfície de seguiment web: poseu-les darrere la categoria de màrqueting del CMP, no deixeu que l'script del bàner intel·ligent s'executi abans que es concedeixi el consentiment, i assegureu-vos que qualsevol esdeveniment activat per OneLink des de campanyes de correu electrònic o notificacions push honori l'estat de consentiment de l'usuari.

Paranys Comuns

Quatre errors d'integració apareixen repetidament en auditories de desplegaments d'AppsFlyer.

Tractar ATT com a consentiment GDPR

ATT i el consentiment GDPR són senyals diferents amb àmbits diferents. Un usuari que accepta ATT ha autoritzat l'ús d'IDFA per al seguiment entre aplicacions; no ha autoritzat tot el que fa el SDK. Per al trànsit d'EU i UK ambdós senyals són requerits, sent el bàner dins l'aplicació el vinculant i ATT sent una capa específica d'iOS a sobre.

Permetre que el SDK s'inicialitzi a l'arrencada

Aquest és el defecte individual més comú. La integració per defecte crida start() immediatament, que dispara l'esdeveniment d'instal·lació amb la càrrega útil completa d'identificadors abans que l'usuari hagi vist el bàner de consentiment. La remediació és directa: configureu isStopped = true en el moment de la integració i crideu start() només des del callback de consentiment.

Oblidar gestionar la retirada

Si un usuari accepta i més tard revoca, s'ha de dir al SDK que deixi de transmetre. Utilitzeu l'API stop() i actualitzeu l'estat de consentiment persistit perquè el següent llançament de l'aplicació respecti la nova decisió.

Ignorar postbacks de servidor a servidor

AppsFlyer reenvia esdeveniments de conversió a una llarga cua de xarxes publicitàries integrades via postbacks del costat del servidor. Cada reenviament porta dades personals i hereta l'àmbit de consentiment de l'esdeveniment original. Utilitzeu setSharingFilter per assegurar que els reenviaments només vagin a socis coberts per les eleccions de consentiment de l'usuari, no a cada soci al vostre tauler d'AppsFlyer.

Llista de Verificació d'Auditoria

Sis preguntes concretes a respondre per a qualsevol desplegament d'AppsFlyer que toqui trànsit d'EU, UK o Califòrnia.

• El SDK espera el consentiment? En una instal·lació nova en un dispositiu de prova ubicat a la UE, confirmeu que cap punt final d'AppsFlyer rep cap sol·licitud abans que l'usuari hagi acceptat el bàner.
• ATT està separat del consentiment dins l'aplicació? Confirmeu que el bàner dins l'aplicació és el senyal de consentiment controlador i ATT es tracta com una capa addicional específica d'iOS.
• El reenviament de socis està limitat al consentiment? Confirmeu que setSharingFilter està configurat per excloure socis que l'usuari no ha autoritzat.
• La retirada atura el SDK? Confirmeu que cridar stop() funciona en la revocació del consentiment i que el nou estat persisteix a través dels llançaments.
• Els postbacks del servidor estan auditats? Confirmeu que la llista "Integracions configurades" del tauler d'AppsFlyer es correspon clarament amb els socis de màrqueting divulgats al bàner.
• L'eliminació de dades està automatitzada? Confirmeu que les sol·licituds DSAR activen l'API d'eliminació d'AppsFlyer, no un tiquet manual.

On Encaixa AppsFlyer en un Stack Centrat en Consentiment

L'atribució mòbil és una de les superfícies més carregades d'identificadors del stack de màrqueting, i el SDK d'AppsFlyer és una de les seves integracions individuals més conseqüents. La bona notícia és que la plataforma exposa les primitives —Start SDK, Stop, filtres de compartició, APIs d'eliminació— necessàries per fer que l'aplicació del consentiment sigui neta i verificable. El treball per als editors és connectar aquestes primitives a un CMP que posseeixi la decisió de consentiment vinculant, tractar ATT com un senyal complementari en lloc d'un substitut, i assegurar-se que el reenviament de socis del costat del servidor no pugui escapar de l'envoltura de consentiment que el bàner va registrar. Fet correctament, el resultat és un stack d'atribució que satisfà els reguladors mentre preserva les dades d'instal·lació i esdeveniment de les quals depenen els equips d'adquisició d'usuaris.