Migrer vers AppsFlyer à partir d'autres fournisseurs

En bref : planifiez votre migration vers AppsFlyer à partir d'un autre fournisseur d'attribution. Évitez les doubles frais, la duplication et la perte de données pendant la période de migration.

flux de migration

Présentation

La migration vers AppsFlyer depuis un autre fournisseur induit les étapes suivantes :

Vous pouvez travailler sur ces différentes opérations simultanément. Cependant, nous vous recommandons de :

  • Terminer toutes les opérations avant de publier votre app mise à jour avec le SDK AppsFlyer.
  • Mettre en pause les campagnes marketing existantes avant d'effectuer la migration de l'ID d'appareil. 

Opérations à effectuer

Le tableau suivant contient le contenu de chaque opération et ses besoins. Pour suivre votre progression, vous pouvez téléchargez cette feuille de calcul.

Mise en application
Tâche Action requise Personnes concernées Temps estimé Remarques
Conditions préalables
  1. Créer un compte AppsFlyer.
  2. Ajouter l'app dans AppsFlyer
  3. [Facultatif] Modifiez la fenêtre de réattribution par défaut de 90 jours pour l'aligner sur votre définition des utilisateurs actifs.
Utilisateur du tableau de bord AppsFlyer/Marketer

2 heures

 
Intégration SDK
  • Intégrez le SDK AppsFlyer à votre app.
  • Mappez les événements in-app du S2S ou SDK.
  • Mettez à jour la version de l'app dans les app stores.
Développeurs d'apps

1-2 semaines

Une fois toutes les autres tâches terminées, l'app doit être mise à jour dans les app stores.

Migration de l'appareil [facultatif] Migrez les ID d'appareil pour éviter la double attribution de vos utilisateurs existants. Spécialiste des données 1-2 semaines Pensez à interrompre les campagnes existantes avant la migration, et à les relancer une fois la version de l'app mise à jour. 
Migration de campagne

Migrez les campagnes existantes depuis : 

  • Les SRN
  • Ad networks non SRN
  • Médias propres
Marketeur/gestionnaire UA 1-3 semaines
Configuration du rapport de données
  • Adaptez/mappez les structures actuelles vos rapports aux structures d'AppsFlyer.
  • Préparez-vous à recevoir les rapports d'AppsFlyer.
Spécialiste des données 2-4 semaines  

Intégration SDK

Intégration SDK

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.

Migration d'appareil-facultatif

À propos de la migration des appareils

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.

 Exemple

  • Un nouvel utilisateur clique sur une publicité dans Facebook et installe votre app le 15 juin.
  • Le 24 juin, l'utilisateur met à jour l'app avec le SDK AppsFlyer, et la lance. Pour AppsFlyer, il s'agit d'un nouvel utilisateur, qui doit être attribué en temps réel.
  • AppsFlyer interroge Facebook avec l'ID d'appareil de l'utilisateur. Parce que l'utilisateur est toujours dans la fenêtre rétrospective de 28 jours de Facebook, Facebook s'auto-attribue l'utilisateur. Cela entraîne une double facturation au propriétaire de l'app pour le même utilisateur.

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 sur l'activité: montrées comme faisant partie des données organiques.
  • Données de conservation et de cohorte : les appareils migrés n'ont pas de date d'installation. Par conséquent, ils ne sont associés à aucune cohorte et ne peuvent pas être affichés dans les rapports de conservation et de cohorte.

Comment migrer un appareil

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 de la population sélectionnée par l'utilisateur à l'aide de la structure de migration attribuée ou non attribuée.
  4. Envoyez le CSV à votre CSM AppsFlyer.
    Votre CSM migrera les ID d'appareil vers AppsFlyer.

Migration attribuée

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

Nom de la
colonne
Description Obligatoire Exemples
app_id

ID de l'app tel qu'il apparaît dans le tableau de bord d'AppsFlyer

Oui
  • Android : com.great.app1 
  • iOS : id123456789

platform

Plateforme de l'appareil : iOS ou Android

Oui
  • iOS
  • Android

device_id

Android : GAID 

iOS : IDFA ou IDFV

 

Oui
  • GAID (minuscules) : 9c9a82fb-d5de-4cd1-90c3-527441c11828
  • IDFA (majuscules) : 9876F1SS-2983-3855-27RR-2R626772VFNB
  • IDFV (majuscules) : A7328D98-A973-402A-8B87-D22A8611F2AF
id_type

Android : advertiserId 

iOS : idfa ou idfv

Actuellement, les autres identifiants, OAID, IMEI et Android ID ne sont pas pris en charge.
Utilisez la migration non attribuée pour les utilisateurs Android qui ne proviennent pas de Google Play.

Oui
  • ID d'annonceur
  • idfa
  • idfv
install_time

L'heure d'installation de l'app originale avec le format UTC ISO 8601 :
AAAA-MM-JJThh:mm:ss.sss
Si l'heure de migration n'est pas fourni, il est utilisé à la place.

  • Doit être une date antérieure valide.
  • Les appareils avec une heure d'installation antérieure à la date de création du fichier moins la fenêtre de réattribution de l'app ne sont pas migrés avec l'attribution, et sont traités comme de nouvelles installations lors du premier lancement.
    Exemple : un fichier de migration est créé le 1er mai et la fenêtre de réattribution est de 30 jours. Tous les appareils avec une heure d'installation antérieure au 1er avril ne sont pas attribués. Lors du premier lancement, ces appareils sont traités comme de nouvelles installations (probablement organiques).
Non

2018-01-22T08:45:33.412

media_source
  • Soit :
    • ID du partenaire AppsFlyer tel qu'il apparaît dans le tableau de bord AppsFlyer
    • Source média personnalisée (ne peut pas être un ID de partenaire).
  • Assurez-vous d'obtenir la liste des ID exacts des partenaires auprès d'AppsFlyer.
  • Format : les valeurs sont sensibles à la casse
Oui


Non-organique : facebook_int, googleadwords_int

Organique : organic

integrated_partner
  • Indique si la source média est un partenaire intégré ou non. C'est à dire source média organique ou personnalisée.
  • Format : les valeurs sont sensibles à la casse
Oui  
  • Oui
  • non
Campagne

Pour plus de détails sur l'attribution granulaire, fournissez le nom de la campagne originale.

Format : chaîne

Non  
campaign_id

Pour plus de détails sur l'attribution granulaire, fournissez l'ID de la campagne originale.

Format : chaîne, espaces non autorisés

Non  
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.
  • Chaque ligne contient un seul identifiant d'appareil par app.
  • 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
  • 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.

Migration non attribuée

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.

Colonnes Quand l'utiliser Exemple
ID d'app + IDFA/GAID/IDFV
  • Si tous vos utilisateurs Android ont des identifiants GAID.
  • Utilisateurs iOS uniquement 
device_migration_file_option_1.png
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.

Utilisez les chaînes exactes pour la colonne type d'ID : advertiserId, idfa, android_id, imei.

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

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

Migration de campagne

Passez d'une campagne marketing existante à AppsFlyer pour activer l'attribution AppsFlyer, et éviter la double facturation et la perte de données d'attribution.

Remarque : vous pouvez choisir de ne migrer que quelques campagnes de marketing à la fois. Dans ce cas, vous pouvez segmenter celles que vous voulez migrer par source média (ex : ad network ou agence), par géo ou par campagne.

Les SRN

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.

 Remarque

  • Les SRN peuvent exécuter plusieurs MMP (sauf Facebook et Twitter).
  • Facebook ne peut pas dé-dupliquer des événements in-app.

Ad networks non SRN

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. 

Médias propres

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. 

Configuration du rapport de données

Adapter et mapper les structures des rapports

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.

Préparer les méthodes de rapport

Vous pouvez obtenir les données brutes et agrégées du rapport auprès d'AppsFlyer via un certain nombre de méthodes. Familiarisez-vous avec les méthodes et configurez celles qui vous concernent.

Les méthodes de reporting comprennent :

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

Étude de cas

Découvrez comment une grande société de divertissement numérique basée à Hungama en Inde, a migré en toute simplicité vers AppsFlyer avec plus de 65 millions d'utilisateurs mensuels. 

Cet article vous a-t-il été utile ?