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.
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.
Tâche | Action requise | Personnes concernées | Temps estimé | Remarques |
---|---|---|---|---|
Conditions préalables |
|
Utilisateur du tableau de bord AppsFlyer/Marketer |
2 heures |
|
Intégration SDK |
|
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 :
|
Marketeur/gestionnaire UA | 1-3 semaines | |
Configuration du rapport de données |
|
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 :
- Intégrez le SDK AppsFlyer dans l'app.Voir les guides de l'intégration du SDK sous Android et iOS
- 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. - 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.
- 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 :
-
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. - [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. - 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.
- 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 |
|
platform |
Plateforme de l'appareil : iOS ou Android |
Oui |
|
device_id |
Android : GAID iOS : IDFA ou IDFV
|
Oui |
|
id_type |
Android : advertiserId iOS : idfa ou idfv Actuellement, les autres identifiants, OAID, IMEI et Android ID ne sont pas pris en charge. |
Oui |
|
install_time |
L'heure d'installation de l'app originale avec le format UTC ISO 8601 :
|
Non |
2018-01-22T08:45:33.412 |
media_source |
|
Oui |
Organique : organic |
integrated_partner |
|
Oui |
|
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 |
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.
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:
- Activez les ad networks pertinents dans AppsFlyer.
- Générer des liens d'attribution AppsFlyer pour chaque ad network.
- 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
- 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.