Migrer vers AppsFlyer à partir d'autres fournisseurs

Le SDK AppsFlyer intégré à l'app est le lien entre l'app et la plateforme AppsFlyer. Il signale les installations et les ouvertures d'app, les événements in-app, etc.

Pour intégrer le SDK AppsFlyer :

1. Intégrez le SDK AppsFlyer dans l'app.Voir les guides de l'intégration du SDK sous Android et iOS
2. Mappez les événements in-app que vous souhaitez enregistrer en utilisant les schémas AppsFlyer.
   Cela peut être fait via le SDK ou S2S.
3. Supprimez le SDK du vendeur d'attribution concurrent.
   Vous pouvez le faire immédiatement et passer exclusivement à AppsFlyer, ou exécuter les deux SDK simultanément pendant quelques semaines. Le tableau ci-dessous présente une ventilation de ces options.
   

   Option	Que se passe-t-il après la sortie de la version mise à jour de l'app ?	Impact
   Supprimer le SDK du concurrent (recommandé)	Seul AppsFlyer enregistre les nouvelles installations et met à jour les utilisateurs. Le concurrent continue de montrer les événements réalisés par les utilisateurs, jusqu'à ce que ces derniers mettent également à jour leur app.	Transition rapide. Pas de double attribution.
   Conserver le SDK du concurrent pendant une période de transition	AppsFlyer et les concurrents attribuent les nouvelles installations et créent des rapports d'événements. À une date ultérieure, retirez le SDK du concurrent.	Validation des données possible. Cela signifie que vous pouvez comparer les données d'AppsFlyer et de l'autre fournisseur. Double attribution, qui peut entraîner une double facturation avec les ad networks. Consultez l'exemple ci-dessous. Charge de travail plus élevée.

4. Une fois que toutes les autres tâches prévues sont terminées, mettez à jour la version de l'app avec le SDK AppsFlyer du marché. Les nouveaux utilisateurs sont attribués par AppsFlyer. 
   Remarque :
   • Veillez à mettre à jour l'app pour iOS, Google Play et tout marché hors magasin Android pertinent.
   • Votre app Android peut exister sur des sites APK non officiels, même si vous ne le savez pas (cherchez sur le web le nom du paquet de votre app pour le découvrir). Les sites APK prennent un certain temps pour se mettre à jour vers la dernière version. Ils peuvent donc amener des utilisateurs organiques, qui installent les anciennes versions sans le SDK AppsFlyer.
   • Le déploiement des mises à jour des apps dans les app stores peut prendre jusqu'à deux jours. Les utilisateurs qui installent pendant cette phase peuvent toujours obtenir la version précédente.

La migration d'appareil consiste à importer dans AppsFlyer la liste des ID de vos appareils existants (IDFA, IDFV, GAID, CUID). Vous devez effectuer cette opération avant de publier la nouvelle version de l'app, qui inclura le SDK AppsFlyer. Il existe deux manières de migrer des appareils, via migration attribuée ou via migration non attribuée.

La migration des appareils vient corriger les erreurs de données qui faisaient que les utilisateurs existants d'une app qui téléchargeaient l'application étaient attribués par votre précédent fournisseur. Par exemple la double facturation SRN, qui a lieu lorsque des utilisateurs initialement attribués à un SRN sous votre précédent fournisseur, et qui se trouvent toujours dans la fenêtre rétrospective, sont attribués une deuxième fois au SRN sous AppsFlyer.

Une fois que vous avez migré les appareils, les données apparaissent dans AppsFlyer comme suit :

• Données relatives aux installations : comme dans le cas des réinstallations, les appareils migrés n'ont pas de données d'installation. Les installations d'appareils migrés ne sont pas affichées dans AppsFlyer.
• Données d'événements et de sessions in-app : enregistrées et affichées comme organiques pour la méthode de migration des appareils non attribués, ou attribuées à la source média et à la campagne, si vous utilisez la méthode attribuée.
• Retargeting : les réattributions et les réengagements s'affichent normalement.
• Données d'activité : affichage normal.
• Données de rétention et de cohorte : il n'y a pas d'enregistrement de l'installation pour les appareils migrés. Par conséquent, ils ne sont associés à aucune cohorte et ne peuvent pas être affichés dans les rapports de rétention et de cohorte. 

Pour migrer les appareils : 

1. Décidez de la population d'utilisateurs à migrer. Vous pouvez migrer tous les utilisateurs existants (ce qui peut vous empêcher d'obtenir des données de réattribution précises d'AppsFlyer), ou uniquement les utilisateurs qui ont récemment installé votre app (ce qui peut entraîner la double facturation pour certains utilisateurs plus anciens).
   Nous vous recommandons de migrer les utilisateurs qui sont actifs pendant votre période de réattribution en cours. Par exemple, si votre app a une fenêtre de réattribution de 90 jours, migrez les utilisateurs qui comptent au moins une session au cours des 90 jours précédents.
2. [Facultatif] Demandez au responsable marketing/UA de mettre en pause les campagnes marketing existantes (des SRN, des réseaux publicitaires non-SRN, des médias propres, etc.) et ce jusqu'à la migration des appareils.
   Si vous décidez de ne pas mettre les campagnes en pause, migrez les ID d'appareil restants du précédent fournisseur dès que la version mise à jour de l'app avec le SDK AppsFlyer est disponible en app store.
3. Préparez un fichier CSV en fonction des options sélectionnées par l'utilisateur à l'aide de la structure de migration attribuée ou non attribuée. Voir l'exemple de fichier CSV
4. Envoyez le CSV à votre CSM AppsFlyer.
   Votre CSM migrera les ID d'appareil vers AppsFlyer.

Les événements in-app et les sessions des appareils migrés vers AppsFlyer avec cette méthode sont enregistrés et affichés d'après la source média indiquée par le fournisseur d'attribution précédent, et selon les politiques de conservation des données des ad networks.

Structure CSV de migration de l'appareil attribué

Règles relatives aux fichiers CSV :

• Le fichier CSV peut contenir des appareils d'utilisateurs provenant de plusieurs apps.
• Ne saisissez pas la même combinaison d'identifiant d'appareil et d'identifiant d'app dans plusieurs lignes. En cas de duplication, la dernière occurrence du fichier est utilisée.
• Tous les en-têtes de colonne doivent être inclus : app_id, platform, device_id, id_type, install_time, media_source, integrated_partner, campaign, campaign_id. Remarque : L'ordre des champs est important et doit être respecté.
• Vous pouvez ajouter l'IDFV et l'IDFA pour le même appareil, mais ils doivent figurer dans des lignes distinctes. Tous les champs des différentes lignes doivent être identiques, à l'exception de device_id.
• Chaque ligne doit contenir exactement 9 champs séparés par des virgules.
• Laissez les champs non obligatoires vides (vierges).
• Les fichiers peuvent contenir jusqu'à 20 millions de lignes.
• Si vous avez plusieurs fichiers, donnez un nom unique à chaque fichier.
• Encodez les données à l'aide d'UTF-8.
• [Facultatif] Compresser les fichiers à l'aide de ZIP ou GZIP.
  

Voir l'exemple de CSV

Les appareils migrés vers AppsFlyer avec cette méthode sont enregistrés comme utilisateurs organiques. Leurs données d'événements et de sessions in-app sont également enregistrées et affichées comme organiques.

Structure de fichier CSV pour la migration des dispositifs non attribués

Colonnes	Quand l'utiliser	Exemple
ID d'app + IDFA/GAID/IDFV	Si tous vos utilisateurs Android ont des identifiants GAID. Utilisateurs iOS uniquement
ID d'app + ID d'appareil + type d'ID d'appareil	Si certains de vos utilisateurs Android n'ont qu'un IMEI ou un identifiant Android, mais pas de GAID (en dehors des marchés hors store, versions Android 4.4.2 ou -). L'ID Android doit avoir un format hexadécimal. Remarque : Utilisez les chaînes exactes pour la colonne de type ID : advertiserId (prend également en charge amazon_aid), idfa, idfv, android_id, imei. Si vous utilisez un ID Android ou un imei, et que AppsFlyer reçoit ultérieurement un meilleur identifiant, une nouvelle attribution peut être enregistrée.

Règles relatives aux fichiers CSV :

• Le fichier CSV peut contenir des appareils d'utilisateurs provenant de plusieurs apps.
• Chaque ligne contient un seul identifiant d'appareil par app.
• Les fichiers doivent comprendre tous les en-têtes de colonne comme suit :
  • Option 1 : le fichier doit inclure tous les en-têtes de colonne comme suit : app_id,device_id
  • Option 2 : app_id,device_id,id_type 
• Les ID d'app en minuscules
• Les ID Android en minuscules
• IDFA/IDFV en majuscules
• Jusqu'à 25 millions de lignes autorisées

Voir l'exemple de CSV

Les SRN répondent aux MMP (Mobile Measurement Partners) lorsqu'ils sont interrogés sur les engagements de certains appareils. Si deux MMP, par exemple AppsFlyer et un fournisseur d'attribution concurrent, interrogent le même SRN sur le même appareil installé, cela peut entraîner une double facturation.

Pour migrer des campagnes SRN :

• Activez et configurez les SRN pertinents dans AppsFlyer.

Les liens d'attribution des ad networks enregistrent les engagements des utilisateurs et sont ensuite utilisés pour attribuer les engagements, qui deviennent des installations réelles.

Pour migrer les campagnes des ad networks non-SRN:

1. Activez les ad networks pertinents dans AppsFlyer.
2. Générer des liens d'attribution AppsFlyer pour chaque ad network.
3. Changez les liens existants dans chacune de vos campagnes avec les liens d'attribution AppsFlyer. 

Les médias propres font référence aux liens d'attribution que vous utilisez dans :

• Partage de contenu
• Web-to-app
• E-mail
• SMS
• Postes social medias
• Blogs
• Communautés internet (Quora, etc.)
• et plus...

Pour ces campagnes, AppsFlyer utilise des liens personnalisés OneLink. Les liens personnalisés OneLink redirigent les utilisateurs en fonction de leur appareil vers la bonne app store, directement dans l'app, ou vers une URL/une page d'accueil.

Pour changer vos liens pour d'autres vendeurs en AppsFlyer OneLinks :

• Contactez votre CSM, qui vous aidera à migrer en bloc tous vos liens. 

Pour l'attribution SKAdNetwork (SKAN), vous ne pouvez mettre la valeur de conversion à jour via le SDK qu'une seule fois. Autrement, les données SKAN perdent toute signification. Par conséquent, assurez-vous qu'après la migration, seul le SDK AppsFlyer met à jour la valeur de conversion SKAN.

Découvrez comment configurer la valeur de conversion SKAN dans AppsFlyer.

Avant la migration, vos systèmes stockent les données d'attribution de votre fournisseur actuel selon les structures de reporting, les champs et les paramètres que vous avez définis avec lui. Pour qu'AppsFlyer puisse rapporter correctement les données, vous devez mapper et adapter vos structures de rapport actuelles à la structure de rapport, aux champs et aux paramètres d'AppsFlyer.

Pour adapter/mapper les structures de vos rapports :

• Contactez votre CSM AppsFlyer pour obtenir de l'aide pour adapter/migrer rapidement vos structures de données de rapport d'Adjust, Branch/Tune ou Kochava vers AppsFlyer.

Vous pouvez obtenir les données brutes et agrégées du rapport auprès d'AppsFlyer de différentes manières. Familiarisez-vous avec ces méthodes et configurez celles qui vous conviennent.

Les méthodes de reporting comprennent :

• Exporter CSV
• API push
• API pull
• Data Locker