Ce qu'AppsFlyer Collecte

Le SDK AppsFlyer initialise une session dès que l'application hôte démarre et, par défaut, collecte un ensemble d'identifiants et de signaux contextuels : l'identifiant publicitaire au niveau de l'appareil (IDFA sur iOS, GAID sur Android), l'IDFV à portée fournisseur sur iOS, un identifiant d'installation AppsFlyer généré qui persiste entre les sessions, l'adresse IP (utilisée pour le géo-IP et le matching probabiliste de type empreinte digitale), l'agent utilisateur, le modèle d'appareil, la version du système d'exploitation, l'opérateur et le fuseau horaire. Après l'installation, le SDK rapporte l'événement d'installation aux serveurs d'AppsFlyer, où il est mis en correspondance avec les données de clics transmises par les réseaux publicitaires. Les événements in-app ultérieurs — Purchase, RegistrationComplete, Tutorial Complete, Custom — se déclenchent via le même SDK et héritent du même ensemble d'identifiants.

Les régulateurs ont été explicites : il s'agit d'un traitement de données personnelles au sens du GDPR. L'IDFA et le GAID sont des données personnelles car ce sont des identifiants persistants au niveau de l'appareil. Le matching probabiliste d'empreintes digitales qui s'exécute parallèlement est encore plus difficile à défendre sans consentement car il s'agit, par définition, d'une tentative d'identifier un utilisateur sans sa coopération explicite. La CNIL, le Garante italien et l'AEPD espagnole ont tous ouvert des enquêtes contre des éditeurs dont les piles d'attribution se déclenchaient avant le consentement.

Contrôles de Confidentialité Natifs d'AppsFlyer

AppsFlyer expose un ensemble significatif de primitives de confidentialité natives. Elles ne remplacent pas un véritable cadre de consentement, mais les comprendre est essentiel car ce sont les leviers qu'un CMP utilise pour contrôler le comportement du SDK.

L'API Start SDK

Le SDK prend en charge un mode d'initialisation où il est configuré mais ne transmet aucune donnée jusqu'à ce que start() soit explicitement appelé. C'est le hook le plus important pour le contrôle d'accès par consentement — par défaut, le SDK démarre automatiquement au lancement de l'application, ce qui est le mauvais comportement pour toute juridiction ayant une exigence de consentement préalable. Définissez isStopped sur true lors de l'initialisation, ou utilisez l'API de démarrage différé, et n'appelez start() que lorsque le signal de consentement est enregistré.

API Stop

Si le consentement est retiré en cours de session, l'appel de stop() arrête toute transmission ultérieure. Il ne supprime pas rétroactivement les données déjà envoyées. Pour une suppression complète, vous devez déposer une demande de suppression de la personne concernée via le portail de confidentialité d'AppsFlyer — une équipe d'intégration devrait automatiser cette opération via l'API AppsFlyer plutôt que via un workflow manuel.

setSharingFilter

Cela filtre quels réseaux publicitaires en aval reçoivent des données postback. C'est la primitive appropriée pour le consentement granulaire par partenaire — par exemple, autoriser l'attribution en général mais bloquer les transferts vers un réseau spécifique que l'utilisateur a rejeté.

Intégration Apple App Tracking Transparency

Sur iOS, AppsFlyer lit le statut d'autorisation ATT et ajuste automatiquement son comportement — si l'utilisateur a refusé l'ATT, l'IDFA n'est pas transmis. L'ATT est indépendant du consentement GDPR, et de nombreux éditeurs les confondent. L'ATT contrôle un seul signal au niveau iOS ; le consentement GDPR contrôle tout le reste.

Intégration sur iOS

Le schéma fiable sur iOS est d'installer le SDK AppsFlyer mais de différer l'initialisation jusqu'à ce que l'ATT et le flux de consentement in-app soient tous deux terminés. La séquence minimale est : l'application se lance, le SDK est configuré avec isStopped = true, la bannière de consentement in-app s'affiche, l'utilisateur accepte les catégories pertinentes, le drapeau isStopped du SDK est effacé et start() est appelé. Si l'application a également besoin de l'ATT (ce qu'elle fait pour tout utilisateur pour lequel l'IDFA est significatif), l'invite ATT est affichée en même temps que ou après la bannière in-app. La plupart des CMP qui prennent en charge le mobile disposent d'une API basée sur des rappels qui délivre la décision de consentement ; ce rappel est le bon endroit pour appeler start().

Intégration sur Android

L'implémentation Android est parallèle à iOS avec deux différences. Premièrement, il n'y a pas d'équivalent ATT — le GAID est disponible sauf si l'utilisateur a invoqué son paramètre "Supprimer l'identifiant publicitaire" au niveau de l'appareil, ce que la plupart des utilisateurs ne font pas. Deuxièmement, le cycle de vie d'Android est plus agressif vis-à-vis du fonctionnement en arrière-plan, donc l'initialisation du SDK doit être liée à l'état de consentement stocké de manière persistante. Lisez l'état de consentement depuis le stockage local au lancement de l'application, configurez le SDK en conséquence et revérifiez à la reprise au cas où l'utilisateur aurait mis à jour son choix pendant que l'application était en arrière-plan.

Intégration sur le Web Mobile

AppsFlyer opère également sur le web mobile via ses produits de bannière intelligente et OneLink. Ce sont essentiellement des outils d'analytique et de deep-link côté web qui déposent des cookies et appellent les serveurs AppsFlyer depuis le navigateur. Ils suivent les mêmes règles que toute autre surface de suivi web : placez-les derrière la catégorie marketing du CMP, ne laissez pas le script de bannière intelligente s'exécuter avant que le consentement soit accordé, et assurez-vous que tout événement déclenché par OneLink à partir de campagnes e-mail ou push respecte l'état de consentement de l'utilisateur.

Pièges Courants

Quatre erreurs d'intégration apparaissent de manière répétée dans les audits des déploiements AppsFlyer.

Traiter l'ATT comme un consentement GDPR

L'ATT et le consentement GDPR sont des signaux différents avec des portées différentes. Un utilisateur qui accepte l'ATT a autorisé l'utilisation de l'IDFA pour le suivi inter-applications ; il n'a pas autorisé tout ce que fait le SDK. Pour le trafic EU et UK, les deux signaux sont requis, la bannière in-app étant le signal contraignant et l'ATT étant une couche spécifique à iOS par-dessus.

Permettre l'initialisation du SDK au lancement

C'est le défaut unique le plus courant. L'intégration par défaut appelle immédiatement start(), ce qui déclenche l'événement d'installation avec la charge utile complète d'identifiants avant que l'utilisateur ait vu la bannière de consentement. La remédiation est simple : configurez isStopped = true au moment de l'intégration et n'appelez start() que depuis le rappel de consentement.

Oublier de gérer le retrait

Si un utilisateur accepte et révoque ensuite, le SDK doit être informé d'arrêter la transmission. Utilisez l'API stop() et mettez à jour l'état de consentement persisté afin que le prochain lancement de l'application respecte la nouvelle décision.

Ignorer les postbacks de serveur à serveur

AppsFlyer transfère les événements de conversion vers une longue liste de réseaux publicitaires intégrés via des postbacks côté serveur. Chaque transfert porte des données personnelles et hérite de la portée du consentement de l'événement d'origine. Utilisez setSharingFilter pour vous assurer que les transferts vont uniquement vers les partenaires couverts par les choix de consentement de l'utilisateur, et non vers chaque partenaire de votre tableau de bord AppsFlyer.

Liste de Contrôle d'Audit

Six questions concrètes auxquelles répondre pour tout déploiement AppsFlyer touchant le trafic EU, UK ou californien.

• Le SDK attend-il le consentement ? Sur une nouvelle installation sur un appareil de test situé en UE, confirmez qu'aucun point de terminaison AppsFlyer ne reçoit de requête avant que l'utilisateur ait accepté la bannière.
• L'ATT est-il séparé du consentement in-app ? Confirmez que la bannière in-app est le signal de consentement de contrôle et que l'ATT est traité comme une couche iOS supplémentaire.
• Le transfert des partenaires est-il limité au consentement ? Confirmez que setSharingFilter est configuré pour exclure les partenaires que l'utilisateur n'a pas autorisés.
• Le retrait arrête-t-il le SDK ? Confirmez que l'appel de stop() fonctionne lors de la révocation du consentement et que le nouvel état persiste entre les lancements.
• Les postbacks du serveur sont-ils audités ? Confirmez que la liste des "Intégrations configurées" du tableau de bord AppsFlyer correspond clairement aux partenaires marketing divulgués dans la bannière.
• La suppression des données est-elle automatisée ? Confirmez que les demandes DSAR déclenchent l'API de suppression d'AppsFlyer, et non un ticket manuel.

La Place d'AppsFlyer dans une Pile Orientée Consentement

L'attribution mobile est l'une des surfaces les plus chargées en identifiants dans la pile marketing, et le SDK d'AppsFlyer est l'une de ses intégrations uniques les plus importantes. La bonne nouvelle est que la plateforme expose les primitives — Start SDK, Stop, filtres de partage, API de suppression — nécessaires pour rendre l'application du consentement propre et vérifiable. Le travail des éditeurs consiste à relier ces primitives à un CMP qui détient la décision de consentement contraignante, à traiter l'ATT comme un signal complémentaire plutôt que comme un remplacement, et à s'assurer que le transfert de partenaires côté serveur ne peut pas échapper à l'enveloppe de consentement enregistrée par la bannière. Correctement réalisé, le résultat est une pile d'attribution qui satisfait les régulateurs tout en préservant les données d'installation et d'événements dont dépendent les équipes d'acquisition d'utilisateurs.