Tester l'intégration du SDK mobile dans l'app – AppsFlyer Support

En bref : testez l'intégration de votre app Android/iOS avec AppsFlyer.

Test et débogage de l'intégration SDK

Testez l'intégration du SDK avant de soumettre l'application à l'app store. Dans cet article, SDK englobe à la fois les SDK IOS et Android d'AppsFlyer.

Cas particuliers de test et de débogage

Smart TV : le SDK est compatible avec les Smart TV basés sur Android et Apple TV (tvOS). Testez les apps Smart TV en suivant les instructions énoncées dans ce guide.
Applications tvOS non publiées : voir la section Test de l'intégration tvOS avant publication.
Amazon Fire TV : voir la section Test de stores Android autres.

Pourquoi dois-je déboguer et tester ?

Une intégration soigneusement testée assure une collecte de données précise et complète. En testant l'intégration SDK, vous êtes sûr que les installations et événements in-app sont correctement enregistrés et attribués.

Test et débogage de l'intégration SDK

Utilisez l'une des méthodes suivantes pour tester et déboguer l'intégration SDK.

Test de base :
- Test de l'intégration à l'aide de liens d'attribution
- Le modèle d'attribution AppsFlyer utilise des liens d'attribution. La réalisation de tests à l'aide de liens d'attribution est fortement recommandée.
- Lorsque vous testez une intégration SDK à l'aide de liens d'attribution, vous obtenez un aperçu détaillé du modèle d'attribution AppsFlyer. Vous avez ainsi la possibilité d'optimiser vos opérations marketing ainsi que vos analyses.
Test avancé :
- Débogage directement depuis l'environnement de développement.
- La section Test d'intégration du SDK limite les tests à un ensemble limité de fonctionnalités. Testez les éléments suivants dans l'environnement de développement en utilisant le journal de débogage :
  - Validation d'achat
  - Données de conversion
  - Erreurs de configuration du SDK. Vous pouvez les tester dans l'environnement de développement à l'aide du journal de débogage.

Lectures connexes à l'usage des ad networks : Test d'intégration du ad network.

Avec la page des tests d'intégration SDK, vous pouvez localiser les problèmes d'intégration de votre projet. C'est là que vous pouvez tester les installations, les évènements in-app et le deep linking.

Tester l'intégration SDK

Pour tester l'intégration du SDK :

Préparez un appareil (iOS ou Android) sur lequel l'app n'est pas installée. Si nécessaire, désinstallez (supprimez) l'app de l'appareil.
Enregistrez l'appareil comme appareil de test. Remarque ! iOS : si vous utilisez TestFlight pour installer l'app, il est inutile d'enregistrer l'appareil.
Dans AppsFlyer, sélectionnez l'application.
Allez à la page Intégration > Tests d'intégration du SDK.
La page des tests d'intégration du SDK s'ouvre.
Sélectionnez une option de test :
- installations non organiques
- Évènement in-app
- Deep Linking
Utilisez la procédure de test qui suit en fonction du type de test choisi.

Tester les installations organiques

Installez l'app sur un appareil de test enregistré.
Lancez l'app.
Le tableau de bord de l'app affiche une nouvelle installation organique.

Tester des installations non organiques

Sélectionnez Installation non organique.
Sélectionnez un appareil dans la liste.
Sélectionnez la source de l'app l:
- Android :
  - Google play
  - Autre (hors magasin)
- iOS :
  - App Store
  - XCode
  - TestFlight
Scannez le code QR avec l'appareil de test enregistré et suivez les instructions sur l'appareil.
Attendez que l'installation non organique soit enregistrée sur la page Test d'intégration SDK, indiquant que le test est réussi. Cela peut prendre jusqu'à 2 minutes.

Si l'app n'enregistre pas d'installation non organique dans les temps, veuillez consulter la section Résolution des problèmes présente dans la page Tests d'intégration du SDK.

Pour tester les installations LAT :

Activez le mode LAT sur votre appareil.
Effectuez un test d'installation non organique.

Pour tester les installations dénuées d'accord ATT (sans IDFA) :

Dans la boîte de dialogue d'd'accord ATT, cliquez sur Demander à l'application de ne pas suivre.
Effectuez un test d'installation non organique.

Test des événements in-app

Cliquez sur Exécuter le test sous Évènements in-app.
Sélectionnez un appareil de test enregistré dans le menu déroulant, puis cliquez sur Suivant.
Lancez votre app et commencez à générer des événements in-app.
Vous découvrirez un journal de ces événements puisqu'ils sont enregistrés en temps réel.

Tester les Deep Links

OneLink doit être défini pour votre application afin de pouvoir tester le Deep Linking. Consultez notre guide OneLink ici. Il est important de noter que l'implémentation du Deep Linking du SDK est fortement recommandée, comme indiqué dans le Guide d'intégration Deep Linking.
Vérifiez que l'option retargeting est activée.
Cliquez sur Exécuter le test sous Deep linking
Sélectionnez un appareil de test enregistré dans le menu déroulant et cliquez sur Suivant.
Sélectionnez Type de test :
- OneLink - Sélectionnez le OneLink que vous souhaitez tester dans la liste déroulante Sélectionnez un OneLink.
- Schéma d'URI - spécifiez le schéma d'URI que vous souhaitez tester. Par exemple, greatapps://cars.
Scannez le QR code avec votre appareil de test enregistré, et suivez les instructions qui s'affichent sur l'appareil.
Une fois ces deux tests terminés, le test Deep Linking s'affiche comme réussi.

Test de l'intégration SDK à l'aide d'applications de débogage

Lorsque vous effectuez des tests à l'aide de liens d'attribution, des données sont enregistrées dans le tableau de bord de l'app. Une fois que les données sont enregistrées, elles ne peuvent plus être supprimées. Si vous ne souhaitez pas que les données de test soient enregistrées comme faisant partie d'une application réelle, vous pouvez tester l'intégration SDK à l'aide d'apps de débogage.

Si vous n'avez pas besoin d'une app de test ou si vous ne craignez pas de mélanger les données de test et les données réelles, vous pouvez ignorer cette section.

Les apps de débogage sont des copies exactes des applications publiées dans les app stores. En exécutant des tests d'intégration SDK sur des apps de débogage, vous ne mélangez pas les données de test et les données réelles.

Les apps de débogage diffèrent des apps de production par les points suivants :

Elles ont un ID app différent
Elles ont leur propre tableau de bord
Elles ne sont pas publiées sur les app stores

Création d'une app de test Android

Duplication de votre application Android

Faites une copie du dossier du projet Android et renommez-la
Ouvrez le projet récemment copié dans Android Studio
Dans Android Studio, développez les dossiers jusqu'au package
Cliquez avec le bouton droit sur le nom du package et choisissez Refactoriser, puis Renommer
Renommez le package
Dans le niveau d'application build.grade, remplacez l'applicationId par le nouveau nom de package

Ajout de l'app de test Android à votre tableau de bord AppsFlyer

Suivez les instructions pour ajouter une nouvelle application dans votre tableau de bord AppsFlyer. Assurez-vous que le nom du package est identique au nom de package de la nouvelle app de test créée, et non au nom du package de l'application d'origine. Assurez-vous également de définir le statut de l'application sur Approbation en attente ou non publiée.

Vous pouvez maintenant exécuter des tests sur la nouvelle app de test.

Création d'une app de test iOS

Duplication de votre application iOS

Ouvrez le dossier du projet dans le Finder
Dupliquez le dossier
Ouvrez le projet dupliqué dans XCode
Dans la classe AppDelegate, dans la méthode didFinishLaunchingWithOptions, définissez un nouvel ID d'app :
Objective C

Swift

Remarque

L'ID d'app est l'ID attribué à l'application une fois qu'elle est publiée sur l'App Store. Cependant, puisqu'il s'agit d'une app de test, vous pouvez lui attribuer l'identifiant de votre choix tant qu'il n'est pas utilisé par une autre app. Le format doit être 11111****. Par exemple, 111117538.

Assurez-vous que l'ID est composé de 9 chiffres. Démarrez l'ID avec cinq 1. Les chiffres restants doivent être aléatoires. Voir l'exemple d'ID ci-dessus.

Ajout de l'app de test iOS à votre tableau de bord AppsFlyer

Suivez les instructions pour ajouter une nouvelle application dans votre tableau de bord AppsFlyer. Assurez-vous que l'ID d'app est identique à celui de la nouvelle app de test. Assurez-vous également de définir le statut de l'application sur Approbation en attente ou non publiée.

Vous pouvez maintenant exécuter des tests sur la nouvelle app de test.

Tests utilisant des liens d'attribution

Cette section montre comment tester l'intégration à l'aide de liens d'attribution.

Avant de commencer :

Enregistrez les appareils que vous utilisez pour les tests
Lorsque vous testez les réattributions, assurez-vous de supprimer l'appareil enregistré de la liste des appareils autorisés.
Si vous testez l'attribution des apps disponibles dans les app stores Android tierces, vous devez définir le paramètre af_r sur le lien d'attribution pour référencer l'app store spécifique.

Vous pouvez tester l'intégration SDK même si l'app est toujours en attente (non répertoriée dans Google Play ou Apple Store).

Sujets abordés dans cette section :

Test d'attribution d'installation
Test des événements in-app
Test du retargeting (réattribution et réengagement)

Test d'attribution d'installation

Le test des installations vous permet de déterminer que le SDK d'AppsFlyer est capable d'attribuer correctement les installations à diverses sources de média.

Étape 1 :

Copiez le lien ci-dessous :

https://app.appsflyer.com/<app_id>?pid=Test&c=Test&advertising_id=<GAID>

https://app.appsflyer.com/<app_id>?pid=Test&c=Test&idfa=<IDFA>

Remplacez le paramètre app_id par votre ID d'app (sans oublier le préfixe id. Exemple : id0123456789).

Le paramètre c indique le nom de la campagne.
Le paramètre pid indique le nom de la source média à laquelle l'installation est attribuée.
Si vous testez une app disponible via une store Android tierce : ajoutez af_r parameter au lien d'attribution.

Si vous testez le clic depuis un ordinateur, ajoutez le GAID pour Android (Google Advertising ID) ou l'IDFA pour iOS.

Étape 2 :

Copiez le lien, envoyez-le à l'appareil de test et accédez au lien à l'aide du navigateur.

Remarque

Dans iOS, utilisez iMessage ou un e-mail pour envoyer le lien vers l'appareil. Ne copiez-collez pas le lien dans l'app iOS Notes avant de cliquer dessus, car cela pourrait rompre le lien.

Si l'application est en temps réel, procédez à l'installation.
Si l'application est en attente, installez-la à partir de votre environnement de développement :
-- Pour Android : installez l'application à partir d'Android Studio ou du Shell ADB.
-- Pour iOS : installez l'application à partir de XCode.

Étape 3 :

Prévoyez jusqu'à deux minutes pour que l'installation apparaisse dans le tableau de bord de l'application. Vous devriez voir une installation attribuée au test de source média sous la campagne Test.

Pour une vérification plus poussée, vous pouvez télécharger le rapport de données brutes d'installation :

Dans AppFlyer, rendez-vous dans Rapports > Données d'exportation.
Dans la section Rapports de données brutes téléchargez le rapport de données brutes des installations.

Pour plus d'informations, reportez-vous à notre article sur le rapport de données brutes d'installation.

Test des événements in-app

Vous pouvez tester les évènements in-app pour vous assurer qu'ils affichent le revenu qui leur est associé et qu'ils sont attribués à la source média générant l'installation.

Après avoir installé l'application à l'aide du lien d'attribution, déclenchez quelques événements in-app. Prévoyez jusqu'à deux minutes pour que les événements apparaissent dans le tableau de bord. Ouvrez le tableau de bord de l'app et cliquez sur Événements dans le menu de gauche.

Les événements, leurs revenus (si des revenus leur sont associés) et la source média à laquelle ils sont associés doivent s'afficher.

Pour une vérification plus élaborée, vous pouvez télécharger le rapport de données brutes des évènements in-app.

Dans le tableau de bord de l'application, cliquez sur Exporter les données sous Rapports. Dans la section Rapports de données brutes, téléchargez le rapport de données brutes Évènement in-app.

Pour plus d'informations, reportez-vous à notre article sur le rapport de données brutes des évènements in-app.

Test de OneLink

OneLink ™ vous permet de définir un seul lien d'attribution pour iOS et Android. OneLink reconnaît l'appareil de l'utilisateur et le redirige vers l'app store approprié.

De plus, OneLink permet le deep linking. Le deep linking vous permet d'ouvrir l'application dans le cadre d'une activité spécifique tout en diffusant un contenu personnalisé.

Pour plus d’informations, consultez notre guide sur les tests des URL OneLink.

Test du retargeting

Conditions préalables pour tester le retargeting

Modèle OneLink : voir Configuration du modèle OneLink
Activer le retargeting dans les paramètres de l'application
Dans le tableau de bord de l'application, cliquez sur Paramètres de l'application et activez l'option Activer la mesure de la campagne de retargeting.

Android iOS
Un appareil non enregistré

Le test de retargeting est simple. Créez un lien d'attribution personnalisé à partir d'un modèle OneLink. Assurez-vous d'activer l'option Campagne de retargeting.

Une fois que le lien d'attribution personnalisé est prêt, l’écran suivant apparaît et vous permet de récupérer la version longue de l’URL :

Il est également possible de récupérer la version longue de l'URL via la page Gestion des liens.

Dans la page Gestion des liens repérez le lien d'attribution.
Dans la partie droite, cliquez sur les trois points situés sous Actions.
Cliquez sur Afficher les détails du lien
Copiez le lien long

Important !

Lors du test de retargeting (réattribution et réengagement), l'ID publicitaire doit être spécifié dans l'URL du lien d'attribution.
Les réinstallations de retargeting (alias réattribution) ne peuvent pas être testées avec des dispositifs de test enregistrés. Ce qui inclut les appareils d'utilisateur qui sont répertoriés dans la liste des appareils de test. Vous pouvez utiliser n'importe quel autre appareil pour réaliser cette action.
Pour afficher les GAID ou IDFA, veuillez suivre les instructions détaillées dans l'article Enregistrer un appareil de test. Important !

Le OneLink final est le suivant :

https://go.onelink.me/2rAD?pid=Test&c=Test&is_retargeting=true&advertising_id=<GAID>

https://go.onelink.me/2rAD?pid=Test&c=Test&is_retargeting=true&idfa=<IDFA>

Test de la réattribution

Vous pouvez tester la réattribution pour vérifier que vous pouvez enregistrer les installations de votre app par les utilisateurs qui la réinstallent après l'avoir désinstallée à un moment donné.

Assurez-vous que l'appareil de test n'est PAS enregistré
Si l'application vient d'être installée, attendez quelques minutes
Désinstallez l'application de l'appareil
Répétez les mêmes étapes pour tester l’attribution d’installations : utilisez le format OneLink ci-dessus.
Prévoyez jusqu'à deux minutes pour que les installations de retargeting apparaissent dans le tableau de bord.
Ouvrez le tableau de bord de l'application et cliquez sur Retargeting dans le menu de gauche
L’installation de retargeting attribuée à la source média Test devrait s'afficher sous le nom de la campagne Test

Pour une vérification plus élaborée, vous pouvez télécharger le rapport de données brutes de conversion.

Dans le tableau de bord de l'application, cliquez sur Exporter les données sous Rapports. Dans la section Rapports de retargeting, téléchargez le rapport de données brutes Conversions.

Test de réengagement

Le ré-engagement se produit lorsqu’un utilisateur existant qui a installé l’application s'engage dans une campagne de retargeting et lance l'application.

Test de réengagement via ouverture d'application

Un réengagement via ouverture d'application signifie que l'utilisateur est redirigé vers l'app store où un bouton d'ouverture d'application s'affiche. S'il clique sur le bouton Ouvrir et lance l'application, un réengagement est enregistré.

Pour tester les réengagements, il vous suffit de suivre les étapes suivantes :

Assurez-vous que l'application est installée sur votre appareil de test et qu'elle a été lancée plusieurs fois
Si l'application vient d'être installée, attendez quelques minutes
Utilisez le même OneLink que celui utilisé pour tester la réattribution
Ajoutez l'ID d'appareil au lien et envoyez-le à votre appareil mobile
Accédez au lien en utilisant un navigateur
Ouvrez manuellement l'application via le bouton Ouvrir de la boutique ou à partir de la plateforme de lancement de l'appareil.

Vous devriez voir un réengagement attribué à la source média Test sous la campagne Test.

Test du réengagement via le deep linking

Le réengagement via le deep linking vous permet de lancer l'app immédiatement après que l'utilisateur a cliqué sur le lien de suivi. Avantages liés à l'utilisation du réengagement avec le deep linking :

Meilleure expérience utilisateur : l'utilisateur n'est pas redirigé vers la boutique et l'application se lance automatiquement
Meilleures campagnes : vous pouvez ouvrir une activité liée à une campagne spécifique et ainsi optimiser les résultats de la campagne de retargeting.

Vous pouvez tester l'attribution de réengagement à l'aide du Deep Linking. Il s'agit de la même procédure que pour tester le réengagement avec un lien d'attribution. La seule différence est que le lien d'attribution contient un paramètre af_dp qui redirige l'utilisateur vers une activité spécifique de l'app.

Pour tester les réengagements à l'aide du deep linking, il vous suffit de suivre les étapes suivantes :

Assurez-vous de configurer le deep linking de votre application
Assurez-vous que l'application est installée sur votre appareil de test et qu'elle a été lancée plusieurs fois
Si l'application vient d'être installée, attendez quelques minutes
Générez un lien de retargeting avec l'ID d'appareil
Ajoutez le paramètre af_dp et ajoutez-y le schéma que vous avez configuré à l'étape 1
Accédez au lien en utilisant un navigateur
Si l'application est installée, le lien lance l'application dans l'activité spécifiée dans le lien

Vous devriez voir un réengagement attribué à la source média Test sous la campagne Test.

Pour plus d'informations, suivez notre guide sur les tests du deep linking.

Autres méthodes de tester l'intégration SDK

Il existe deux méthodes supplémentaires pour tester l’intégration SDK :

Cette section montre comment déboguer le SDK. Consultez cette section pour effectuer des tests avancés et résoudre les problèmes liés à l’intégration du SDK.

Débogage pour Android

Le débogage du SDK vous donne une perspective détaillée de son intégration à votre app. Le débogage vous aide à résoudre les problèmes liés à l'enregistrement des événements in-app, aux données de conversion et à la validation d'achat.

Activation du mode de débogage du SDK Android

Pour démarrer le débogage du SDK Android, ajoutez la ligne suivante à la classe AFApplication :

AppsFlyerLib.getInstance().setDebugLog(true);

Avertissement !

Le débogage doit se limiter à la phase de développement uniquement. Ne distribuez pas l'application aux app stores avec le débogage activé. Cela pose des risques majeurs pour la sécurité et la vie privée.

Affichage de la sortie de débogage

Pour afficher la sortie de débogage, ouvrez le terminal Logcat dans Android Studio. Choisissez le nom du package d'application en tant que processus débogable, définissez le niveau de journal sur Débogage et filtrez par « AppsFlyer_ ».

Résoudre les problèmes fréquemment rencontrés avec le SDK Android

Installation toujours attribuée à organique

Scénario

Vous testez l'attribution à l'aide de liens d'attribution. Vous avez implémenté le port d'écoute de conversion du SDK, mais le journal indique toujours que l'installation est organique. De plus, aucune installation non organique n'est enregistrée dans le tableau de bord.

Possibles raisons

Votre clé dev est incorrecte. Si vous spécifiez une clé dev incorrecte, l'installation ne peut pas être attribuée.
le lien d'attribution que vous utilisez est incorrect. Consultez notre guide des liens d'attribution.
Assurez-vous que l'appareil de test est enregistré
Un canal non approprié est défini dans le manifeste

Installation non détectée ou attribuée

Scénario

Vous testez l'attribution de l'installation, mais le journal ne contient aucune donnée relative à l'installation, telle que le type, le premier lancement, etc.

Possibles raisons

Assurez-vous que les méthodes startTracking et init sont appelées dans la classe AFApplication.
Assurez-vous que l'appareil de test est enregistré

Je reçois une erreur 404 sur l'installation ou l'enregistrement d'évènement

Scénario

Vous testez des évènements in-app pour vous assurer qu'ils sont attribués à la source média appropriée. Cependant, la réponse 404 apparaît pour l'installation et les envois d'évènements in-app. Ni l'installation ni les évènements in-app n'apparaissent dans le tableau de bord.

Possibles raisons

Une réponse 404 indique que l'ID d'app est incorrect. Assurez-vous que l'ID d'app dans le paramètre applicationId du fichier build.gradle est identique à celui de votre tableau de bord.

Les revenus ne sont pas enregistrés correctement

Scénario

Vous testez des évènements in-app avec des revenus. Les évènements apparaissent dans le tableau de bord mais les revenus ne sont pas enregistrés

Possibles raisons

Le paramètre de revenu n'est pas formaté correctement. Veillez à ne PAS formater la valeur de revenu. Elle ne doit pas contenir de séparateurs sous forme de virgules, de symbole monétaire ou de texte. Un événement de revenu doit être similaire à 1234.56, par exemple.

Le journal indique « Le SDK AppsFlyer ne peut envoyer aucun évènement sans DevKey » lorsque je teste des évènements in-app

Scénario

Vous essayez de voir les évènements in-app dans le journal. Lorsque vous déclenchez des événements, le journal indique uniquement « Le SDK AppsFlyer ne peut envoyer aucun événement sans DevKey ».

Possibles raisons

Vous appelez la méthode startTracking sans transmettre la clé dev en tant que paramètre. Transmettez la clé dev à la méthode.

Le journal indique « Envoi des données en attente de la clé dev » dans le journal lorsque je teste des évènements in-app

Scénario

Vous essayez de tester les événements in-app dans le journal. Lorsque vous déclenchez des événements, le journal indique uniquement « Envoi des données en attente de la clé dev ».

Possibles raisons

Vous appelez la méthode init et vous transmettez la clé dev sous la forme d'une chaîne vide. Transmettez la clé dev à la méthode.

Je reçois une réponse 400 lorsque je teste des évènements in-app

Scénario

Vous essayez de tester les événements in-app dans le journal. Lorsque vous déclenchez des événements, vous recevez une réponse 400 dans les journaux.

Possibles raisons

Cela pourrait indiquer un problème avec la clé dev. Vérifiez que la clé dev est correcte. Assurez-vous également que la clé dev ne contient que des caractères alphanumériques.

Le journal indique « AVERTISSEMENT : les Google Play Services sont manquants »

Scénario

Le logcat affiche le message d'avertissement « AVERTISSEMENT : les Google Play Services sont manquants »

Possibles raisons

Les dépendances des Google Play Services sont absentes de l'application. Cela pourrait empêcher le SDK de collecter le GAID, ce qui pourrait poser des problèmes d'attribution.

Ajoutez les lignes suivantes

implementation 'com.google.android.gms:play-services-base:15.0.1'
implementation 'com.google.android.gms:play-services-ads:15.0.1'

Dans le fichier build.grade de niveau module (app).

Je reçois la réponse 403 lors de l'installation ou de l'enregistrement des évènements

Scénario

Vous voulez tester les installations et les autres évènements de conversion dans le journal. Lorsque vous déclenchez ces événements, vous voyez s'afficher la réponse 403 (interdit) dans les journaux.

Possibles raisons

Cela peut s'expliquer par le fait que vous avez le forfait Zéro, qui ne comprend pas les données d'attribution, mais uniquement les données concernant les clics et impressions. Pour pouvoir recevoir les données d'attribution, consultez les différents forfaits AppsFlyer et procédez à une mise à jour si nécessaire. Vous pouvez également contacter notre équipe chargée de l'engagement sur hello@appsflyer.com si vous avez des questions concernant nos forfaits.

Débogage pour iOS

Activation du mode de débogage du SDK iOS

Pour commencer le débogage du SDK iOS, ajoutez la ligne suivant à la méthode didFinishLaunchingWithOptions :

Ajoutez la ligne suivante à AppDelegate.m :

[AppsFlyerLib shared].isDebug = true;

Ajoutez la ligne suivante à AppDelegate.swift :

AppsFlyerLib.shared().isDebug = true

Avertissement !

Le débogage doit se limiter à la phase de développement uniquement. Ne distribuez pas l'application à l'App Store avec le débogage activé. Cela pose des risques majeurs pour la sécurité et la vie privée.

Affichage de la sortie de débogage

Pour afficher la sortie de débogage, ouvrez le terminal de débogage dans XCode et filtrez par « AppsFlyer ».

Résoudre les problèmes fréquemment rencontrés avec le SDK IOS

Les installations et les évènements ne sont pas enregistrés

Il peut y avoir plusieurs raisons pour lesquelles les installations et les évènements ne sont pas enregistrés :

Si vous spécifiez un ID d'app dans un format incorrect, les installations et les événements ne sont pas enregistrés. Lorsque vous définissez l'ID d'app dans le fichier Delegate, assurez-vous qu'il ne comporte que des chiffres.

Vous pouvez trouver votre clé dev dans le tableau de bord AppsFlyer, dans les paramètres de l'application :

Correct :

[AppsFlyerTracker sharedTracker].appleAppID = @"340954503";

Incorrect :

[AppsFlyerTracker sharedTracker].appleAppID = @"id340954503";

Incorrect :

[AppsFlyerTracker sharedTracker].appleAppID = @"com.appslyer.sampleapp";

Si le format de l'ID d'app est incorrect, le journal affiche l'erreur suivante :

[ERROR] AppsFlyer: -[AppsFlyerTracker validateAppID] 
AppsFlyer Error: appleAppID should be a number!

Si vous spécifiez un ID d'app qui n'existe pas dans votre compte, l'installation et les événements ne sont pas enregistrés. Le journal affiche l'erreur suivante :

AppsFlyer: -[AppsFlyerHTTPClient sendRequestEventToServer:isRequestFromCache:appID:isDebug:
completionHandler:]_block_invoke sent information to server, status = 404

L'erreur 404 indique que le SDK ne parvient pas à trouver l'application dans votre compte.

Si vous spécifiez un ID de clé dev incorrect, les installations et les événements ne sont pas enregistrés. Le journal affiche l'erreur suivante :

AppsFlyer: -[AppsFlyerHTTPClient sendRequestEventToServer:isRequestFromCache:appID:isDebug:completionHandler:]
_block_invoke sent information to server, status = 400

L'erreur 400 indique que le SDK ne peut pas authentifier la demande pour enregistrer les installations et les événements. Vérifiez que la clé dev est correcte. Assurez-vous également que la clé dev ne contient que des caractères alphanumériques.

L'ID app et la clé dev sont corrects, mais l'installation n'est pas enregistrée

Scénario

L'application contient l'ID app et la clé dev corrects, mais les installations ne sont pas enregistrées.

Possibles raisons

Le SDK n'est pas lancé correctement. Assurez-vous d’appeler la méthode trackAppLaunch dans applicationDidBecomeActive :

- (void)applicationDidBecomeActive:(UIApplication *)application { 
	[[AppsFlyerTracker sharedTracker] trackAppLaunch]; 
}

func applicationDidBecomeActive(application: UIApplication) { 
	AppsFlyerTracker.shared().trackAppLaunch() 
}

Le journal indique « La clé dev AppsFlyer est manquante ou vide. Abandon »

Scénario

Vous essayez de voir les installations et les évènements in-app dans le journal. Le journal indique « La clé dev AppsFlyer est manquante ou vide. Abandon ».

Possibles raisons

La clé dev n'est pas définie. Assurez-vous de la définir dans appDelegate dans la méthode didFinishLaunchingWithOptions :

[AppsFlyerTracker sharedTracker].appsFlyerDevKey = @"YOUR_DEV_KEY";

AppsFlyerTracker.shared().appsFlyerDevKey = "YOUR_DEV_KEY"

Installation toujours attribuée à organique

Scénario

Possibles raisons

le lien d'attribution que vous utilisez est incorrect. Consultez notre guide des liens d'attribution.
Assurez-vous que l'appareil de test est enregistré

Les revenus ne sont pas enregistrés correctement

Scénario

Vous testez des évènements in-app avec des revenus. Les évènements apparaissent dans le tableau de bord mais les revenus ne sont pas enregistrés

Possibles raisons

Je reçois une erreur 404 sur l'installation ou l'enregistrement d'évènement

Scénario

Vous testez des installations et des évènements in-app pour vous assurer qu'ils sont attribués à la source média appropriée. Cependant, la réponse 404 apparaît pour les installations et les évènements in-app. Ni l'installation ni les évènements in-app n'apparaissent dans le tableau de bord.

Possibles raisons

Une réponse 404 indique que l'ID d'app est incorrect. Reportez-vous à la section Installations et événements non enregistrés.

Je reçois la réponse 400 lors de l'installation ou de l'enregistrement des évènements

Scénario

Vous essayez de tester les événements in-app dans le journal. Lorsque vous déclenchez des événements, vous recevez une réponse 400 dans les journaux.

Possibles raisons

Cela pourrait indiquer un problème avec la clé dev. Vérifiez que la clé dev est correcte. Assurez-vous également que la clé dev ne contient que des caractères alphanumériques. Reportez-vous à la section Installations et événements non enregistrés.

Je reçois la réponse 403 lors de l'installation ou de l'enregistrement des évènements

Scénario

Possibles raisons

Débogage pour Unity

Activation du mode de débogage dans Unity

Pour déboguer le SDK Unity, ajoutez la ligne suivante à la méthode de démarrage dans AF GameObject

AppsFlyer.setIsDebug (true);

Avertissement !

Affichage de la sortie de débogage

L'affichage de la sortie de débogage se fait via Android Studio ou XCode.

Résoudre les problèmes fréquemment rencontrés avec le SDK Unity

Unity construit simplement des applications Android et iOS. Reportez-vous aux problèmes communs à chaque plate-forme pour plus d'informations :

Problèmes courants avec le SDK Android
Problèmes courants avec le SDK iOS

Remarque

Lorsque vous avez terminé de tester et de déboguer l'intégration du SDK, désactivez les journaux du SDK.