Cosa Raccoglie AppsFlyer

L'SDK di AppsFlyer inizializza una sessione non appena l'app host si avvia e, per impostazione predefinita, raccoglie un insieme di identificatori e segnali contestuali: l'identificatore pubblicitario a livello di dispositivo (IDFA su iOS, GAID su Android), l'IDFV con ambito vendor su iOS, un ID di installazione AppsFlyer generato che persiste tra le sessioni, l'indirizzo IP (utilizzato per geo-IP e per il matching probabilistico di tipo fingerprint), user agent, modello del dispositivo, versione del sistema operativo, operatore e fuso orario. Dopo l'installazione, l'SDK segnala l'evento di installazione ai server di AppsFlyer, dove viene abbinato ai dati dei clic inoltrati dalle reti pubblicitarie. Gli eventi in-app successivi — Acquisto, RegistrazioneCompletata, Tutorial Completato, Personalizzato — vengono inviati attraverso lo stesso SDK ed ereditano lo stesso set di identificatori.

I regolatori sono stati espliciti nel dichiarare che si tratta di trattamento di dati personali ai sensi del GDPR. L'IDFA e il GAID sono dati personali perché sono identificatori persistenti a livello di dispositivo. Il matching probabilistico tramite fingerprint che opera in parallelo è ancora più difficile da difendere senza consenso perché è, per definizione, un tentativo di identificare un utente senza la sua cooperazione esplicita. Il CNIL, il Garante italiano e l'AEPD spagnola hanno tutti avviato indagini contro editori i cui stack di attribuzione si attivavano prima del consenso.

Controlli Nativi di Privacy di AppsFlyer

AppsFlyer espone un insieme significativo di primitive di privacy native. Non sono un sostituto di un vero framework di consenso, ma comprenderle è essenziale perché sono le leve che un CMP utilizza per controllare il comportamento dell'SDK.

La Start SDK API

L'SDK supporta una modalità di inizializzazione in cui viene configurato ma non trasmette alcun dato finché start() non viene chiamato esplicitamente. Questo è il singolo hook più importante per il gating del consenso — per impostazione predefinita l'SDK si avvia automaticamente al lancio dell'app, che è il comportamento sbagliato per qualsiasi giurisdizione con un requisito di consenso preventivo. Impostare isStopped su true all'inizializzazione, o utilizzare l'API di avvio differito, e chiamare start() solo quando il segnale di consenso è registrato.

Stop API

Se il consenso viene revocato durante la sessione, chiamare stop() interrompe ogni ulteriore trasmissione. Non cancella retroattivamente i dati già inviati. Per la cancellazione completa è necessario presentare una richiesta di cancellazione dei dati del soggetto attraverso il portale privacy di AppsFlyer — un'integrazione che i team dovrebbero automatizzare tramite l'API di AppsFlyer anziché un flusso di lavoro manuale.

setSharingFilter

Questo filtra quali reti pubblicitarie a valle ricevono i dati dei postback. È la primitiva giusta per il consenso granulare per singolo partner — ad esempio, consentire l'attribuzione in generale ma bloccare gli inoltri verso una rete specifica che l'utente ha rifiutato.

Integrazione con Apple App Tracking Transparency

Su iOS, AppsFlyer legge lo stato di autorizzazione ATT e adatta il proprio comportamento automaticamente — se l'utente ha rifiutato ATT, l'IDFA non viene trasmesso. ATT è indipendente dal consenso GDPR, e molti editori li confondono. ATT controlla un singolo segnale a livello iOS; il consenso GDPR controlla tutto il resto.

Integrazione su iOS

Il pattern affidabile su iOS consiste nell'installare l'SDK di AppsFlyer ma differire l'inizializzazione fino a quando sia ATT che il flusso di consenso in-app non sono completati. La sequenza minima è: l'app si avvia, l'SDK è configurato con isStopped = true, il banner di consenso in-app viene visualizzato, l'utente accetta le categorie pertinenti, il flag isStopped dell'SDK viene azzerato e start() viene chiamato. Se l'app necessita anche di ATT (cosa necessaria per qualsiasi utente per cui l'IDFA è significativo), il prompt ATT viene mostrato insieme o dopo il banner in-app. La maggior parte dei CMP che supportano il mobile hanno un'API basata su callback che fornisce la decisione di consenso; quel callback è il posto giusto per chiamare start().

Integrazione su Android

L'implementazione Android è parallela a iOS con due differenze. Primo, non esiste un equivalente di ATT — il GAID è disponibile a meno che l'utente non abbia invocato l'impostazione a livello di dispositivo "Elimina ID pubblicitario", cosa che la maggior parte degli utenti non fa. Secondo, il ciclo di vita di Android è più aggressivo nel mettere in background le app, quindi l'inizializzazione dell'SDK deve essere legata allo stato di consenso memorizzato in modo persistente. Leggere lo stato di consenso dalla memoria locale al lancio dell'app, configurare l'SDK di conseguenza, e ricontrollare al ripristino nel caso in cui l'utente abbia aggiornato la propria scelta mentre l'app era in background.

Integrazione sul Web Mobile

AppsFlyer opera anche sul web mobile attraverso i suoi prodotti smart banner e OneLink. Questi sono essenzialmente strumenti di analisi e deep-link lato web che rilasciano cookie e chiamano i server di AppsFlyer dal browser. Seguono le stesse regole di qualsiasi altra superficie di tracciamento web: subordinarli alla categoria marketing del CMP, non permettere allo script dello smart banner di eseguirsi prima che il consenso sia concesso, e assicurarsi che qualsiasi evento attivato da OneLink proveniente da campagne email o push rispetti lo stato di consenso dell'utente.

Errori Comuni

Quattro errori di integrazione emergono ripetutamente negli audit delle implementazioni AppsFlyer.

Trattare ATT come consenso GDPR

ATT e il consenso GDPR sono segnali diversi con ambiti diversi. Un utente che accetta ATT ha autorizzato l'uso dell'IDFA per il tracciamento cross-app; non ha autorizzato tutto il resto che l'SDK fa. Per il traffico EU e UK entrambi i segnali sono necessari, con il banner in-app che è quello vincolante e ATT che è un livello specifico iOS aggiuntivo.

Lasciare che l'SDK si inizializzi al lancio

Questo è il singolo difetto più comune. L'integrazione predefinita chiama start() immediatamente, il che invia l'evento di installazione con il payload completo degli identificatori prima che l'utente abbia visto il banner di consenso. La correzione è semplice: configurare isStopped = true al momento dell'integrazione e chiamare start() solo dal callback di consenso.

Dimenticare di gestire la revoca

Se un utente accetta e successivamente revoca il consenso, l'SDK deve essere istruito a interrompere la trasmissione. Utilizzare l'API stop() e aggiornare lo stato di consenso persistente in modo che il prossimo avvio dell'app rispetti la nuova decisione.

Ignorare i postback server-to-server

AppsFlyer inoltra gli eventi di conversione a una lunga lista di reti pubblicitarie integrate tramite postback lato server. Ogni inoltro contiene dati personali ed eredita l'ambito di consenso dell'evento originale. Utilizzare setSharingFilter per assicurarsi che gli inoltri vadano solo ai partner coperti dalle scelte di consenso dell'utente, non a ogni partner nel dashboard AppsFlyer.

Checklist di Audit

Sei domande concrete a cui rispondere per qualsiasi implementazione AppsFlyer che tocca traffico EU, UK o californiano.

• L'SDK attende il consenso? Su un'installazione pulita in un dispositivo di test localizzato in EU, confermare che nessun endpoint AppsFlyer riceva alcuna richiesta prima che l'utente abbia accettato il banner.
• ATT è separato dal consenso in-app? Confermare che il banner in-app è il segnale di consenso vincolante e ATT è trattato come un livello aggiuntivo specifico per iOS.
• L'inoltro ai partner è limitato al consenso? Confermare che setSharingFilter è configurato per escludere i partner che l'utente non ha autorizzato.
• La revoca interrompe l'SDK? Confermare che chiamare stop() funziona alla revoca del consenso e che il nuovo stato persiste tra i lanci successivi.
• I postback server sono verificati? Confermare che la lista "Integrazioni configurate" nel dashboard AppsFlyer corrisponde chiaramente ai partner di marketing dichiarati nel banner.
• La cancellazione dei dati è automatizzata? Confermare che le richieste DSAR attivano l'API di cancellazione di AppsFlyer, non un ticket manuale.

Dove Si Colloca AppsFlyer in uno Stack Consent-First

L'attribuzione mobile è una delle superfici più dense di identificatori nello stack di marketing, e l'SDK di AppsFlyer è una delle sue singole integrazioni più consequenti. La buona notizia è che la piattaforma espone le primitive — Start SDK, Stop, filtri di condivisione, API di cancellazione — necessarie per rendere l'applicazione del consenso pulita e verificabile. Il lavoro per gli editori è collegare quelle primitive a un CMP che possieda la decisione di consenso vincolante, trattare ATT come un segnale complementare anziché un sostituto, e assicurarsi che l'inoltro lato server ai partner non possa sfuggire all'involucro di consenso registrato dal banner. Fatto correttamente, il risultato è uno stack di attribuzione che soddisfa i regolatori preservando al contempo i dati di installazione ed eventi da cui dipendono i team di acquisizione utenti.