Guide de l'intégration de base du SDK

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échargez le rapport de données brutes des événements in-app et utilisez 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 les croiser avec vos ID internes.

Pour en savoir plus sur le CUID, consultez cet article.

RÉFÉRENT D'INSTALLATION GOOGLE PLAY

L'API de référent d'installation Google Play 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 des instructions à votre développeur pour ajouter 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 à l'aide de l'API setImeiData ou setAndroidIdData (voir la référence des fonctions dans les onglets ci-dessous). Le SDK envoie les données aux serveurs d'AppsFlyer.
    Android natifUnity

    Voir la référence du SDK Android pour :

    • setImeiData 
    •  setAndroidIdData 

    Voir la référence du SDK Unity pour :

    • setImeiData
    • setAndroidIdData
  • Accepter la collecte de l'ID de l'appareil : force le SDK à collecter l'IMEI ou l'ID Android à l'aide de setCollectIMEI et setCollectAndroid (voir la référence des fonctions dans les onglets ci-dessous).
    Android natifUnityReact natif

    Voir la référence du SDK Android pour :

    • setCollectIMEI
    • setCollectAndroidID

    Voir la référence du SDK Unity pour :

    • setCollectIMEI
    • setCollectAndroidID

    Voir la référence React Native pour :

    • setCollectIMEI
    • setCollectAndroidID

• OAID : attribut les installations issues des app stores Android tiers. Pour plus d'informations, consultez 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.

CONTEXTE

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 l'infrastructure 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 la méthode 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 :

• Si l'utilisateur donne son accord 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).

• Si 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 sous 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 comprend l'app source et l'app à promouvoir.

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 à promouvoir (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 confidentialité des utilisateurs. Lorsque l'app est lancée pour la première fois, la plateforme 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 SKAdNetwork dans 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'enregistrement 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.

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. Cette action se base 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 sur le paramétrage du deep linking et deep linking différé.

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 différé étendu.

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 sur le paramétrage du deep linking et deep linking différé.