Guide de l'intégration de base du SDK

Recommandé pour
Marketeurs
Dernière mise à jour :

En bref : en partenariat avec votre développeur mobile ou d'app CTV, intégrez et installez le SDK dans vos apps Android ou iOS. Une fois les opérations d'intégration de base terminées, votre app sera prête à attribuer les installations et à mesurer les événements in-app.  

 Lectures connexes

Pour savoir comment préparer l'intégration SDK de votre app, pensez à parcourir ces articles :

Récupérer la clé dev

Avant que votre développeur ne puisse installer et intégrer le SDK, vous devez récupérer la clé dev. AppsFlyer utilise la clé dev pour identifier votre compte de manière unique. La clé dev est obligatoire car elle permet au SDK d'envoyer et de récupérer en toute sécurité les données appartenant à votre compte.

Pour récupérer votre clé dev :

  1. Dans AppsFlyer, rendez-vous dans Configuration > Paramètres de l'app. 
  2. Copiez votre clé dev et transmettez-la à votre développeur mobile.

    af_devkey.png

  3. Transférez à votre développeur mobile les instructions concernant l'installation et l'intégration du SDK.

Quand démarrer le SDK ?

Lorsque vous planifiez l'intégration du SDK AppsFlyer, la première chose à savoir est : quand initialiser et démarrer le SDK dans le processus de lancement de votre app ?

La règle d'or c'est que le SDK doit commencer à envoyer des données le plus tôt possible après le lancement de l'app.Cela garantit que le SDK capture l'événement d'installation et tous les événements in-app se de la session.

Cependant, afin de suivre les règles de protection de la confidentialité telles que le RGPD et le CCPA, il est souvent nécessaire d'attendre que les utilisateurs consentent à partager leurs informations avant d'envoyer les données à AppsFlyer.

Démarrer le SDK dans Android

Sélectionner la classe où démarrer le SDK

Choisissez de démarrer le SDK dans la classe globale Application ou dans la classe Activity :

  • Démarrer le SDK dans la classe globale Application : il est généralement recommandé d'initialiser le SDK dans la classe/sous-classe globale Application car la classe Application se charge et s'initialise avant que l'interface utilisateur de l'app ne s'affiche. Cela garantit que le SDK démarre dans n'importe quel contexte, y compris dans le cadre du deep linking.
  • Lancez le SDK dans une classe Activity (démarrage différé) pour permettre aux utilisateurs d'accepter le partage des données. Obtenir le consentement de l'utilisateur requiert en effet d'avoir une interface utilisateur (UI) rendue dans une classe Activity.

Sélectionner le scénario de demande de consentement

Sélectionnez un scénario de demande de consentement qui permet d'appeler start en se conformant aux règles de protection de la confidentialité comme le RGPD ou la CCPA.Vous pouvez par exemple choisir l'un de ces scenarios : refus de consentement à l'installation, refus ponctuel de consentement ou refus de partage des données avec des tiers.

Pour plus d'informations sur les scénarios de demande de consentement disponibles, (avec exemples de code), rendez-vous sur Scénarios de demande de consentement.

Instructions pour les développeurs du SDK Android

Démarrer le SDK dans iOS

Temporiser le démarrage du SDK dans iOS

Pour le choix démarrage du SDK, il est important de savoir s'il faut retarder l'appel de start jusqu'à ce que l'utilisateur donne son consentement.

Le SDK fournit la méthode waitForATTUserAuthorization qui vous permet de définir combien de temps le SDK doit attendre le consentement de l'utilisateur avant d'envoyer les données aux serveurs AppsFlyer.

Pour plus d'infos sur le flux de données de la méthode et son interaction avec l'infrastructure ATT d'iOS, consultez la section Comment configurer l'App Tracking Transparency (ATT).

Sélectionner le scénario de demande de consentement

Sélectionnez un scénario de demande de consentement qui permet d'appeler start en se conformant aux règles de protection de la confidentialité comme le RGPD ou la CCPA.Vous pouvez par exemple choisir l'un de ces scenarios : refus de consentement à l'installation, refus ponctuel de consentement ou refus de partage des données avec des tiers.

Pour plus d'informations sur les scénarios de demande de consentement disponibles, rendez-vous sur Scénarios de demande de consentement.

Instructions pour les développeurs du SDK iOS

Transmettez à votre développeur les éléments suivants :

Attribution

Le SDK collecte les identifiants à des fins d'attribution. En suivant ces directives, vous aurez la garantie que les installations sont enregistrées et attribuées correctement.

Toutes les plateformes

Identifiant unique pour toutes les installations

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 :

Intégrer les ID uniques de votre système BI avec AppsFlyer

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.

Android uniquement

Les sections suivantes présentes les possibilités d'attribution pour Google Play Store ou les app stores tiers.

Attribuer les apps publiées sur Google Play 

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.

Attribuer les apps dans les app stores tiers

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.

iOS uniquement

Les sections suivantes comprennent des informations importantes au sujet de la prise en charge des appareils iOS 14 et +.

Configurer la prise en charge de la transparence du suivi d'app (ATT)

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

 Important !

N'appelez pas waitForATTUserAuthorization si vous n'avez pas l'intention d'invoquer la boîte de dialogue de consentement ATT.

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.

ATT-flowchart_en-us.png

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.

Personnaliser la boîte de dialogue de consentement ATT

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 à :

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.

Prise en charge de l'attribution SKAN

 Remarque

Pour une prise en charge complète de l'attribution SKAN, vous devez passer au SDK iOS V6.2.3 et +.

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 .

Enregistrer les événements in-app

Les événements in-app (IAE) permettent une analyse de ce qui se produit dans votre app. L'enregistrement des évènements in-app vous permet de mesurer certains KPI comme le ROI (retour sur investissement) et la LTV (lifetime value - durée vie). Nous vous recommandons de bien réfléchir aux événements que vous souhaitez enregistrer.

Une fois que vous avez déterminé les événements in-app que vous souhaitez mesurer, transmettez les noms d'évènements et paramètres à votre développeur, accompagnés du lien vers ces instructions. 

Pour en savoir plus sur les événements in-app, consultez notre guide des événements in-app riches.

Toutes les plateformes

Enregistrement du revenu

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.

Valider les achats in-app

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.

Secteur d'activité

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

Lien profond avec OneLink

OneLink est la solution d'AppsFlyer pour l'attribution multiplate-forme, la redirection et le deep linking.

Toutes les plateformes

Détecter et rediriger les appareils

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

Deep Linking

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.

Voir notre guide sur le paramétrage du Deep linking et deep linking différé différé.

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.

Voir notre guide sur le paramétrage du Deep linking et deep linking différé différé.

Accéder aux données d'attribution et de deep linking

Le tableau suivant détaille les différentes méthodes qui permettent de récupérer les données d'attribution et de deep linking :

Méthode Qui est concerné ? Résultats du retour Méthode de récupération Données d'attribution Données de deep linking Disponibilité
API push
  • Marketeur
  • Développeur backend
 Généralement en quelques minutes Backend Y N Premium
API pull
  • Marketeur
  • Développeur backend
  • Par cycle (non en temps réel).
  • Vous pouvez programmer le téléchargement des rapports de données brutes.
 Backend Y Y Premium pour les rapports de données brutes
Data Locker
  • Marketeur
  • Développeur backend

Les rapports horaires sont disponibles sous 1 à 3 heures.

Stockage sur le cloud via l'une des méthodes suivantes :

  • Compartiment appartenant à AppsFlyer (AWS)
  • Stockage dont vous êtes le propriétaire (AWS ou GCS)
 Y Y Premium
Obtenir des données de conversion (GCD)
  • Marketeur
  • Développeur mobile

Voir la documentation destinée aux développeurs

 Jusqu'à 5 secondes SDK Y Y Tous les comptes
Deep linking unifié (DLU)
  • Marketeur
  • Développeur mobile

Voir la documentation destinée aux développeurs

 Jusqu'à 1 seconde SDK N Y Tous les comptes

Ce qui suit s'applique uniquement aux utilisateurs d'iOS 14.5 et + qui n'ont pas donné leur accord :

  • Lorsque vous utilisez le DLU pour les médias payants et propriétaires, les données de deep linking sont disponibles.
  • Lorsque vous utilisez la fonction GCD pour les médias payants, les données sont limitées et n'incluent pas les détails d'attribution et de deep linking.

 Astuce

Ce que nous vous recommandons :

  • Utilisez l'API Push pour récupérer les données d'attribution et les envoyer à vos serveurs pour traitement. Cette méthode permet d'attendre que les données soient disponibles, elle est donc très précise et quasi en temps réel. La GCD renvoie des données en temps réel, mais peut être imprécise lorsque les décisions d'attribution finales sont déterminées après plus de 5 secondes.
  • Utilisez l'API Pull pour traiter par cycle (par exemple chaque jour) les données d'attribution en temps réel, vous éviterez ainsi les éventuelles erreurs de communication.

tester vZtre intégration SDK

Une fois l'intégration SDK terminée, vous pouvez vous rendre dans le tableau de bord AppsFlyer, sur la page Tests d'intégration du SDK, et de là tester les installations organiques et non organiques, les événements in-app ainsi que le deep linking (retargeting). Vous aurez ainsi la certitude que les installations et événements in-app ont été correctement enregistrés et attribués.

Si vous voulez que votre développeur teste l'intégration SDK, vous devez l'ajouter à votre compte en tant qu'utilisateur pour qu'il puisse accéder au tableau de bord.

Pour découvrir des exemples de test et parcourir les instructions, consultez Les tests d'intégration SDK.