Un ID AppsFlyer est automatiquement créé pour chaque nouvelle installation de l'application. Aucune action n'est requise de la part du marketeur.

Avec cet identifiant vous pouvez :

• Envoyez des événements in-app serveur à serveur.
• Faire correspondre l'ID AppsFlyer et les enregistrements utilisateur dans vos systèmes en back-end.
• Télécharger le rapport de données brutes des événements in-app , et utiliser appsflyer_id pour analyser le comportement et le parcours des utilisateurs.

Définissez votre propre ID utilisateur client (CUID) dans le SDK AppsFlyer pour croiser l'ID unique de votre système BI avec l'ID AppsFlyer, ou tout autre identifiant. Le CUID est disponible dans les rapports de données brutes AppsFlyer. Vous pouvez également l'utiliser dans les API de postback pour le croiser avec vos ID internes. 

Cf Instructions à l'attention des développeurs pour implémenter le CUID.

Référent d'installation Google Play

L'API Google Play Install Referrer augmente la précision de l'attribution, protège contre les installations frauduleuses et permet de récupérer en toute sécurité les données de référence de Google Play (ex : la version de l'app au moment de sa première installation). 

Nous vous recommandons de fournir ces instructions à votre développeur avant qu'il n'ajoute l'API de référent d'installation Google Play. 

GAID

Depuis le SDK V4.8.0, AppsFlyer collecte automatiquement cet identifiant d'appareil.

Avec AppsFlyer, vous pouvez attribuer les installations issues d'app stores tiers comme Amazon, Opera, GetJar, Baidu, ou Huawei. Cela vous permet de promouvoir vos apps et de toucher plus d'audiences sur les marchés où Google Play n'est pas disponible

AppsFlyer prend en charge l'attribution dans le contexte des app stores tiers comme suit :

• IMEI ou ID Android : le SDK ne collecte pas automatiquement l'IMEI ou l'ID Android. Cependant, si vous avez besoin de récupérer ces identifiants (par exemple pour une app du marché intérieur chinois), votre développeur peut implémenter l'une des méthodes de collecte suivantes :
  • Collecte manuelle : l'application transmet l'IMEI ou l'ID Android au SDK via l'API setImeiData ou setAndroidIdData. Le SDK envoie les données aux serveurs d'AppsFlyer. 
  • Accord pour collecter les ID d'appareil : oblige le SDK à collecter l'IMEI ou l'ID Android.
• OAID : attribut les installations issues des app stores Android tiers. Pour plus d'informations, cf notre Guide pour implémenter l'OAID.
• Référents d'installation : le SDK prend en charge la récupération des données de référence à partir de Samsung Gallery et Huawei AppGallery.

Arrière-plan

Depuis iOS 14.5, la collecte de l'IDFA est soumise au consentement de l'utilisateur. En pratique, cela signifie que l'accès à l'IDFA est régi par la App Tracking Transparency(ATT). Sur les appareils iOS 14 et +, le SDK utilise l'infrastructure ATT pour obtenir l'accès à l'IDFA de l'appareil.

Pour une introduction à l'ATT, voir la section Principes de l'ATT.

Lorsque l'attribution se produit à l'aide de l'IDFA, il est important que ce dernier soit envoyé lors du premier lancement. C'est la raison pour laquelle le SDK fournit l'utilitaire waitForATTUserAuthorization.

Aperçu de waitForATTUserAuthorization

waitForATTUserAuthorization vous permet de définir combien de temps le SDK doit attendre le statut ATT avant d'envoyer les données aux serveurs AppsFlyer.

Lorsqu'un utilisateur lance l'app, le statut de l'ATT est notDetermined (non défini). En attendant l'expiration du délai de waitForATTUserAuthorization, le SDK stocke en mémoire l'événement de lancement et les événements in-app consécutifs. La même chose se produit lorsque les événements hors ligne sont enregistrés dans les cas suivants.

• Si l'utilisateur donne son accord pour l'ATT (collecte IDFA) :
  • Le SDK ajoute l'IDFA aux événements mis en cache.
  • Le SDK se lance et envoie les événements mis en cache accompagnés de l'IDFA (sans attendre la fin du délai d'expiration).
• L'utilisateur ne donne pas son accord ATT : le SDK démarre et envoie les événements mis en cache sans l'IDFA (sans attendre la fin du délai d'expiration).
• Si le délai expire et que l'ATT est toujours sur notDetermined, le SDK se lance et envoie les événements mis en cache mais sans l'IDFA.

Attention

• Appeler requestTrackingAuthorization sans définir waitForATTUserAuthorization entraînera l'envoi de lancements et d'événements sans IDFA pour les appareils iOS 14+.
• Si l'utilisateur déplace l'app en arrière-plan durant le temps d'attente :
  • Le minuteur se met en pause jusqu'à ce que l'app revienne au premier plan.
  • Les événements sont mis en mémoire cache.
• Si l'utilisateur ferme l'application pedant le délai d'attente :
  • Le minuteur redémarre lorsque l'app est à nouveau lancée.
  • Les événements mis en cache sont perdus.

Vous pouvez personnaliser la boîte de dialogue de consentement ATT. Un message qui énonce clairement l'objet de la demande peut contribuer à augmenter le taux d'adhésion des utilisateurs.

Lorsque vous créez votre message, pensez à :

• Utilisez une formulation qui explique au mieux à vos utilisateurs pourquoi l'app leur demande leur consentement.
• Expliquer aux utilisateurs comment leurs données seront utilisées. En savoir plus sur la confidentialité des utilisateurs et l'utilisation des données.

Une fois votre message terminé, transmettez à votre développeur le texte accompagné des instructions d'implémentation.

Voir quelques exemples de demande de consentement ATT.

SKAN est une classe utilisée par iOS pour valider les installations d'app pilotées par les annonceurs. Le processus de validation d'installation d'une app concerne l'app source et l'app au centre de la promotion. 

Une app source est une application qui participe à une campagne publicitaire en affichant les publicités issues d'un réseau publicitaire. La configuration de votre app propre à l'affichage des publicités sort du cadre d'action du SDK AppsFlyer. Pour effectuer la configuration, veuillez suivre les instructions d'Apple.

Pour l'app au centre de la promotion (l'app avec le SDK AppsFlyer), la solution AppsFlyer SKAN utilise SKAN pour produire le postback d'attribution tandis que AppsFlyer collecte, traduit et agrège les données, et ce tout en protégeant la vie privée des utilisateurs. Lorsque l'app est lancée pour la première fois, la plate-forme AppsFlyer suit la configuration provenant du marketeur pour indiquer au SDK comment définir la valeur de conversion SKAN.

Pour utiliser la solution SKAN :

• Le marketeur doit configurer la mesure de SKAN depuis AppsFlyer. Le développeur n'a aucune action à réaliser.
• Le SDK AppsFlyer appelle automatiquement les API SKAN requises.
• Pensez à désactiver les appels SKAN des autres SDK si vous comptez sur AppsFlyer pour l'attribution SKAN.
• Aucune autre action ou procédure d'inscription n'est requise de la part du développeur ou du marketeur dans l'App Store. 

Pour désactiver l'attribution SKAN, vous devez demander à votre développeur de le faire à l'intérieur du SDK .

Vous pouvez envoyer un revenu avec n'importe quel évènement in-app. Veillez à utiliser le paramètre af_revenue pour inclure le revenu. Il s'agit du seul paramètre d'événement que AppsFlyer considère comme un revenu réel à la fois dans le tableau de bord et les rapports de données brutes. En savoir plus.

Pour les instructions à l'attention des développeurs, voir logging revenue.

Le SDK AppsFlyer effectue une vérification au niveau du serveur pour les achats in-app. La validation d'un achat in-app envoie automatiquement un évènement d'achat in-app à AppsFlyer. Le fait d'envoyer vous-même cet évènement crée un rapport d'évènements en double.

Consultez la liste des événements in-app recommandés par verticale (voyages, gaming, e-commerce, etc).

Pour les utilisateurs qui n'ont pas installé votre app, OneLink détecte le type d'appareil et les redirige vers la bonne destination, par exemple Google Play, l'App Store d'Apple, l'app store tiers ou une page web. Ceci est basé sur les paramètres de votre template OneLink. En savoir plus

Pour les utilisateurs qui ont installé votre app, OneLink ouvre l'app. En plus de l'ouverture de l'app, vous pouvez deep linker les utilisateurs à une activité ou page spécifique de l'app. Cela nécessite que votre développeur implémente le deep linking unifié (DLU).

Remarque :

• Le DLU nécessite un SDK V6.1 et +.
• Les clients qui utilisent déjà OneLink pour le deep linking peuvent utiliser la méthode traditionnelle, plutôt que le DLU.

Consultez notre guide de configuration du deep linking avec OneLink.

Pour les utilisateurs qui n'ont pas installé votre app, OneLink détecte le type d'appareil et les redirige vers la bonne destination : Google Play, l'App Store d'Apple, l'app store tiers ou la page web. Une fois que l'utilisateur a lancé l'app, vous pouvez utiliser le deep linking différé pour qu'il soit redirigé vers une activité ou page spécifique de l'application.

Cela nécessite que votre développeur implémente le deep linking unifié (DLU).

Remarque :

• Le DLU nécessite un SDK V6.1 et +.
• Les clients qui utilisent déjà OneLink pour le deep linking différé peuvent utiliser la méthode traditionnelle au lieu du DLU.

Consultez notre guide pour configurer le deep linking différé avec OneLink.