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 :
- Présentation de l'intégration SDK
- Guide de l'intégration de base du SDK (cet article)
- Intégration complémentaire du SDK
- Vue d'ensemble de la TV connectée (CTV) et de l'OTT (over-the-top)
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 :
- Dans AppsFlyer, rendez-vous dans Configuration > Paramètres de l'app.
- Copiez votre clé dev et transmettez-la à votre développeur mobile.
- 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 globaleApplication
car la classeApplication
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 classeActivity
.
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
- Informez le développeur de vos choix concernant :
- La classe -
Application
ouActivity
- quand démarrer le SDK ?
- Le scénario de demande de consentement à utiliser.
- La classe -
- Transmettez à votre développeur les liens de référence suivants :
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 :
- Quelle est la durée (en secondes) du temps d'attente avant l'envoi des données à AppsFlyer ?
- Le scénario de demande de consentement à utiliser.
- Liens pour les développeurs :
- Démarrer le SDK iOS, un guide du développeur pour savoir comment démarrer le SDK.
-
Comment configurer l'App Tracking Transparency (ATT), pour obtenir des infos sur le flux de données de la méthode
waitForATTUserAuthorization
et son interaction avec l'infrastructure ATT d'IOS.
-
Activer la prise en charge de l'App Tracking Transparency (ATT), un guide du développeur sur
waitForATTUserAuthorization
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 :
- 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.
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
ousetAndroidIdData
. 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.
- Collecte manuelle : l'application transmet l'IMEI ou l'ID Android au SDK via l'API
- 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.
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éfinirwaitForATTUserAuthorization
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 à :
- 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.
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 |
|
Généralement en quelques minutes | Backend | Y | N | Premium |
API pull |
|
|
Backend | Y | Y | Premium pour les rapports de données brutes |
Data Locker |
|
Les rapports horaires sont disponibles sous 1 à 3 heures. |
Stockage sur le cloud via l'une des méthodes suivantes :
|
Y | Y | Premium |
Obtenir des données de conversion (GCD) |
|
Jusqu'à 5 secondes | SDK | Y | Y | Tous les comptes |
Deep linking unifié (DLU) |
|
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.