En bref : les données au niveau des lignes (c'est à dire les données brutes) décrivent des événements déclenchés par les utilisateurs comme les installations, événements in-app, visites de sites web, installations bloquées par Protect360, revenus publicitaires et postbacks relatifs aux utilisateurs envoyés aux partenaires. Les rapports de données brutes sont disponibles via téléchargement, API et Data Locker.
Le reporting des données brutes : outils et rapports
Les rapports de données brutes vous permettent d'analyser le comportement et le parcours des utilisateurs, de rapprocher les comptes de ad network et enfin d'enrichir vos systèmes CRM et BI. Grâce aux données brutes vous augmentez votre capacité d'analyse, d'optimisation et d'amélioration des performances.
Les rapports sont proposés via des outils de reporting. Les outils présentent chacun des caractéristiques adaptées à des cas d'utilisation précis. Par exemple, pour rapprocher un compte de ad network précis, vous téléchargez le rapport selon les besoins depuis la page Données d'exportation. Pour obtenir les données de performances utilisateur à charger dans vos systèmes BI, vous récupérez les données par programme en utilisant Data Locker ou Pull API.
Astuce
Vous voulez en savoir plus sur vos données brutes ? Suivez cette brève formation sur le portail d'apprentissage AppsFlyer.
Outils de reporting : caractéristiques et fonctionnalités
Les rapports sont proposés via différents outils de reporting détaillés dans cette section.
Attention :
- La plage de dates du rapport correspond à la date de l'activité (réelle) à laquelle l'événement a eu lieu. Ce qui est très différent des rapports agrégés dont la plage de dates est basée sur la LTV.
- Descriptions des champs : cf dictionnaire des champs de données.
Outil de reporting
Outil | Description | App multiple/unique (1) | Capacité d'actualisation des données (2) | Intégré dans des scripts | Fuseau horaire | Devise |
---|---|---|---|---|---|---|
Page d'exportation des données brutes |
|
Unique | Mise à jour en continu | X |
Spécifique à l'app |
Spécifique à l'app |
API pull* |
|
Unique | Mise à jour en continu | ✓ |
|
|
Data Locker P |
|
Multiple | Mise à jour continue avec un décalage de plusieurs heures | ✓ | UTC | USD |
API Push P |
|
Peut utiliser le même point de terminaison | Minutes après l'enregistrement de l'événement dans AppsFlyer | ✓ | UTC + spécifique à l'app | USD + spécifique à l'app |
Données de conversion SDK (3) |
|
S/O | Temps réel <5 secondes | ✓ | UTC | S/O |
Remarques/abréviations : |
Limitations des outils
Limitation | API Pull (*) | API push | Data Locker | Données de conversion SDK |
---|---|---|---|---|
Limitation des données | 1 million de lignes par appel | S/O | S/O | S/O |
Options de sélection des données | Sélectionner les types de données. Options de sélection de champs limitées | Sélectionnez les types de données, les champs et les données in-app | Sélectionnez les types de données, les champs et les données in-app | Non |
Fenêtre de disponibilité des données | 90 jours | S/O | 14 jours | À vie (disponible dans le SDK) |
(*) Des limitations sur la génération des rapports s'appliquent |
Considérations d'intégration
Contrepartie | API pull | API push | Data Locker | Données de conversion SDK |
---|---|---|---|---|
Développement côté serveur | OPTIONNELLE | OBLIGATOIRE | OPTIONNELLE | OPTIONNELLE |
Nécessite un traitement des données | OPTIONNELLE | OBLIGATOIRE | OPTIONNELLE | OPTIONNELLE |
Risque de perte de données | Non | Oui, si les serveurs de réception sont en panne | Non | Faible, si la réponse du ad network est décalée |
Coûts de traitement client-serveur | Aucun | Haut(e) | Faible | Aucun (à moins d'envoyer les données aux serveurs) |
Maintenance client-serveur | Aucun | Haut(e) | Faible | Aucun (à moins d'envoyer les données aux serveurs) |
Format des données | Fichier CSV | Params de requête ou JSON | CSV ou Parquet | JSON |
Les enregistrements de données brutes propres à un contexte donné sont regroupés dans les rapports. Exemple : les installations non organiques, les événements organiques in-app. Pour faciliter la logique, les rapports sont regroupés de la manière suivante :
-
Parcours utilisateur : permet de suivre le parcours et l'engagement d'un utilisateur au sein de l'application.
Exemple : clic > installation > événement in-app > désinstallation. - Fonctionnalité : découle d'une fonctionnalité AppsFlyer donnée, mais ne fait pas partie du parcours principal de l'utilisateur. Exemple : les postbacks envoyés aux ad networks, les rapports sur la fraude et les règles de validation, les rapports sur les revenus publicitaires de niveau utilisateur.
Champs du rapport
Le dictionnaire de champs des données brutes contient des champs qui concernent les rapports de parcours utilisateur, et certains champs liés aux rapports de fonctionnalités. Le principe est le suivant :
-
Parcours utilisateur :
- Doit avoir un ensemble de champs en commun.
- Le champ est rempli en fonction du contexte du parcours. Exemple : les rapports non organiques contiennent la source média à qui l'on impute l'entrée de l'utilisateur.Les champs d'attribution des rapports organiques restent vides car il n'existe aucune source média.
- Fonctionnalité : contient un ensemble de champs propre, ou contient des champs de parcours utilisateur et des champs supplémentaires en lien avec la fonctionnalité. Exemple : les rapports SKAdNetwork ont une liste de champs unique, tandis que les rapports de postback contiennent des champs de parcours utilisateur ET des champs supplémentaires propres à l'envoi de postback aux partenaires.
Conseil! La meilleure façon de vous familiariser avec les rapports est de les parcourir. Vous pouvez télécharger vos rapports sur la page Données d'exportation.
Pour rendre les choses plus claires, les champs du parcours utilisateur sont divisés en groupes liés au contexte.
Groupes de champs de données brutes du parcours utilisateur
Groupe du champ | Concerne les utilisateurs organiques | Exemples de champs |
---|---|---|
Téléchargement | Oui | ID de l'app, nom de l'app, version de l'app, version du SDK, ATT |
Attribution |
Non, sauf pour l'heure d'installation |
Heure d'installation, heure de touch attribué, source média, campagne, adset, publicité, partenaire, type de conversion de retargeting |
Attribution des contributeurs | Non | Partenaire contributeur, type de correspondance |
Infos appareil | Oui | ID publicitaire, GAID, OAID, type d'appareil, ID utilisateur du client |
Localisation de l'appareil | Oui | Adresse IP, localité, pays |
Événement |
Oui |
Champs remplis dans les rapports d'événements in-app : Nom de l'événement, valeur de l'événement, revenu de l'événement |
Rapports de parcours utilisateur
Principes de base du parcours utilisateur
Les rapports de parcours utilisateur contiennent les données en lien avec les événements survenus pendant la durée vie d'un utilisateur. Les données sont divisées en rapports en fonction de :
- La source de l'utilisateur : organique ou non organique
- Contexte du parcours :
- Engagement avec les publicités avant l'installation de l'app (impressions et clics)
- Acquisition
- Retargeting
Les rapports d'acquisition d'utilisateurs (UA) contiennent :
- Les impressions et les clics générés avant l'installation par tout potentiel utilisateur qui interagit avec une publicité.
- Événement d'installation.
- Les événements in-app produits par l'utilisateur qui en découlent.
Les rapports de retargeting contiennent :
- Les impressions et les clics qui se produisent lorsque l'utilisateur est reciblé.
- Événements de conversion : soit un réengagement soit une réattribution.
- Événements in-app réalisés dans le cadre du réengagement qui en découlent. N'oubliez pas :
- Les données de retargeting sont toujours non organiques.
- Les événements in-app de retargeting se trouvent à la fois dans les rapports UA et les rapports d'événements in-app de retargeting. Voir le principe de la double-attribution de retargeting.
Pour suivre un parcours utilisateur, vous devez cumuler les rapports en lien avec les parties du parcours qui vous intéressent, par exemple : les installations et les événements in-app. Une fois fait, vous n'avez qu'à trier le rapport en utilisant l'ID AppsFlyer, l'heure de l'événement et le type de rapport. Le résultat correspond à l'ensemble des événements pour un utilisateur donné au fil du temps, en d'autres termes le parcours utilisateur.
Disponibilité du rapport du parcours utilisateur
- La disponibilité des rapports dépend de votre forfait d'abonnement.
- Les rapports peuvent inclure des utilisateurs organiques, des utilisateurs non organiques ou les deux, comme indiqué.
- Les politiques de rétention s'appliquent aux rapports données brutes historiques et dépendent de l'outil de reporting et de l'origine des données brutes. En général, les données sont disponibles pour les 90 derniers jours. Important ! Les politiques de rétention ne s'appliquent pas aux données agrégées.
Rapports de parcours utilisateur
Catégorie | Propre à Data Locker | Sujet du rapport | Trafic | Non organique |
---|---|---|---|---|
Acquisition des utilisateurs | ✓ | Clics | S/O | |
Retargeting | ✓ | Clics en provenance des campagnes de retargeting | Retargeting non organique uniquement | |
Acquisition des utilisateurs | ✓ | Impressions | S/O | |
Retargeting | ✓ | Impressions des campagnes de retargeting | Retargeting non organique uniquement | |
Acquisition des utilisateurs | - | Installations | ✓ | ✓ |
Acquisition des utilisateurs | - | Évènements in-app | ✓ | ✓ |
Acquisition des utilisateurs | - | Revenus publicitaires attribués | - | ✓ |
Acquisition des utilisateurs | - | Revenus publicitaires organiques | ✓ | - |
Retargeting | - | Revenus publicitaires de retargeting | Retargeting non organique uniquement | |
Retargeting | - | Conversions de retargeting (réengagements et réattributions) | Retargeting non organique uniquement | |
Retargeting | - | Événements in-app de retargeting (réengagements et réattributions) | Retargeting non organique uniquement | |
Retargeting | ✓ | Sessions de retargeting (réengagements et réattributions) | Retargeting non organique uniquement | |
Acquisition des utilisateurs | ✓ | Sessions | ✓ | ✓ |
Acquisition des utilisateurs | - | Désinstallations non organiques | - | ✓ |
Acquisition des utilisateurs | - | Désinstallations organiques | ✓ | - |
Acquisition des utilisateurs | ✓ | Engagements multiplateformes | ✓ | ✓ |
Description des rapports du parcours utilisateur
Clics et impressions
Rapport | Caractéristiques |
---|---|
Contexte |
Un utilisateur s'engage dans une campagne et clique sur une publicité, ou il la visionne. |
Caractéristiques | Les rapports contiennent un enregistrement du lien d'attribution et des en-têtes HTTP présents au moment où un utilisateur clique ou visionne une publicité. |
Cas d'utilisation |
|
Exemple de rapport | Clics |
Remarques |
Données SRN non disponibles. |
Utilisateurs restreints | Dans certains cas, en raison des règles de confidentialité, les données d'impression et de clic sont soit restreintes (elles n'ont pas d'identifiant utilisateur), soit non disponibles. La disponibilité dépend de la source média et de la plate-forme. |
Installations et conversions de retargeting
Nom de rapport |
Acquisition d'utilisateur : installations |
Retargeting : conversions |
---|---|---|
Contexte |
Lorsqu'un utilisateur ouvre une app pour la première fois. |
Lorsqu'un utilisateur s'engage avec une publicité de retargeting, puis finit par ouvrir l'app. Une conversion de retargeting est un réengagement ou une réattribution. Voir notre guide d'attribution du retargeting. |
CAS D'UTILISATION |
|
Identique aux installations. |
Organique ou non organique |
|
Ne s'applique pas |
Exemple de rapport | d'installations | Le rapport des conversions de retargeting possède la même structure que le rapport des installations. Certains champs sont renseignés dans le cadre du retargeting. Cf retargeting des données brutes. |
Évènement in-app
Rapport | Caractéristiques |
---|---|
Contexte du rapport |
Liste chronologique des actions effectuées par les utilisateurs après l'attribution (installation, réattribution ou réengagement) |
Caractéristiques |
|
Cas d'utilisation |
Le rapport vous permet de :
|
Valeurs de l'événement |
Champ valeur de l'événement Le champ valeur de l'événement contient toutes les données relatives à l'événement dans un JSON. Vous pouvez les charger dans votre système BI pour obtenir une analyse plus précise. AstuceVous pouvez utiliser Power Query dans Microsoft Excel pour analyser les paramètres d'événement à partir des chaînes de texte JSON.
Reporting des revenus Dans AppsFlyer, les données des revenus et du ROI proviennent du af_revenue envoyé dans les événements. Lorsque le paramètre af_revenue est envoyé dans un événement in-app, AppsFlyer l'utilise pour renseigner le champ revenu de l'événement. C'est ce champ que AppsFlyer utilise pour mettre à jour le tableau de bord et les rapports agrégés. Attention ! N'utilisez le paramètre af_revenue qu'avec les événements in-app qui décrivent les revenus réellement générés.Pour tout autre événement impliquant des revenus, mais qui n'est pas conclu (ex : add_to_cart), vous devez utiliser des paramètres différents (comme af_price) |
Exemple de rapport |
Évènement in-app |
Remarques |
|
Sessions
Rapport | Caractéristiques |
---|---|
Contexte |
Lorsque l'utilisateur ouvre l'app, un événement de session est envoyé à AppsFlyer. L'événement est enregistré uniquement si la durée entre les sessions dépasse le seuil minimum fixé. |
Caractéristiques |
La structure du rapport est identique à celle des rapports d'événements in-app. Les sessions (événements de session) s'affichent dans un rapport séparé à cause du nombre important de ces événements. |
Cas d'utilisation | Comprendre l'engagement des utilisateurs dans l'application. |
Exemple de rapport | Le rapport des sessions est identique au rapport des événements in-app. Remarque : dans les données brutes, les sessions portent le nom d'événement launch. |
Désinstallations
Rapport | Caractéristiques |
---|---|
Contexte |
Enregistrement des utilisateurs qui désinstallent l'app. |
Caractéristiques |
|
Champs disponibles |
|
Exemple de rapport | Remarque sur les désinstallations ! Dans notre exemple, par souci de clarté, la ligne 2 indique les champs qui sont renseignés si les données disponibles le permettent. |
CAS D'UTILISATION |
|
Disponibilité du rapport de parcours utilisateur selon les outils
Rapport d'engagement publicitaire selon les outils
Rapport | Données d'exportation | API pull | Data Locker | API push | Données de conversion SDK |
---|---|---|---|---|---|
Impressions (1) | - | - | ✓ | - | - |
Clics (1) | - | - | ✓ | - | - |
(1) Les données sur les clics et les impressions sont fournies par les non-SRN. Les SRN ne rendent pas ces données disponibles. |
Rapports d'acquisition d'utilisateurs par outil
Rapport | Données d'exportation | API pull | Data Locker | API push | Données de conversion du SDK |
---|---|---|---|---|---|
d'installations | ✓ | ✓ | ✓ | ✓ | ✓ |
Sessions | - | - | ✓ | - | - |
Évènement in-app | ✓ | ✓ | ✓ | ✓ | - |
Désinstallations | ✓ | ✓ | ✓ | - | - |
Rapports de données brutes de retargeting par outil
Rapport | Données d'exportation | API pull | Data Locker | API push | Données de conversion du SDK |
---|---|---|---|---|---|
Clics (1) | - | - | ✓ | - | - |
Conversions (réattributions + réengagements) | ✓ | ✓ | ✓ | ✓ | ✓ |
Impressions (1) | - | - | ✓ | - | - |
Sessions | - | - | ✓ | - | - |
Évènement in-app | ✓ | ✓ | ✓ | ✓ | - |
(1) Les données sur les clics et les impressions sont fournies par les non-SRN. Les SRN ne rendent pas ces données disponibles. |
FAQ
Détails |
---|
Pourquoi les données brutes de Meta ads sont-elles manquantes ? Par défaut, les données brutes de Meta ads sont attribuées à la source média qui est limitée. Voir données Meta ads au niveau de l'utilisateur. |
Quelle différence existe-t-il entre les horodatages ? Les horodatages sont communs à tous les rapports. Vous pouvez ainsi combiner différents rapports. Les horodatages suivants sont appliqués :
Important :
|
Quel est le rôle du champ contributeur ? Le champ contributeur recense les sources média du contributeur. On l'appelle parfois installations assistées. Dans Protect360, il est également utilisé pour corriger l'attribution des installations détournées. |
Qu'est-ce que le champ mots-clés ? Pourquoi n'est-il pas disponible pour toutes les installations non organiques ? Les installations attribuées à Google Ads ou Apple Search Ads, peuvent contenir les mots-clés (ou l'ID de mot-clé) associés à la publicité qui a généré l'installation. |
Conseils sur les rapports d'installations
Comprendre le parcours utilisateur
Le parcours utilisateur est constitué d'une série d'étapes que l'utilisateur traverse avant d'atteindre un objectif donné (l'achat d'un produit ou la réservation d'un vol par exemple). Analyser le parcours d'un utilisateur vous permet donc de voir les actions de l'utilisateur au sein de l'app, son niveau d'activité et la valeur qu'il produit sur une période donnée.
Vous pouvez identifier et mettre en évidence les parcours utilisateur à l'aide de l'ID AppsFlyer. L'ID est généré pour chaque installation d'app sur un appareil. L'ID reste le même tout au long du cycle vie de l'utilisateur (de l'installation à la désinstallation). L'ID ne disparait pas si l'utilisateur réinitialise l'ID de son appareil.
Les rapports d'installations et ceux des événements in-app ayant la même structure, ils peuvent être fusionnés en un seul rapport. Dans le rapport fusionné, vous pouvez agréger et filtrer en utilisant l'ID AppsFlyer et l'ID utilisateur du client (si disponible) dans le but d'analyser les parcours utilisateur.
Exemples
Un utilisateur engagé - fort
- Un utilisateur installe l'app le 20 août à 09h31.
- Le rapport fusionné indique qu'il a effectué des achats le 20 août à 10h31, le 22 août à 15h22 et le 25 août à 16h47.
- Nous en concluons que l'utilisateur est un utilisateur engagé. Il a effectué un achat une heure après avoir lancé l'application, et a continué ses achats les jours qui ont suivi.
Utilisateur engagé - faible
- Un utilisateur installe l'app le 30 juillet. Le rapport fusionné indique qu'il a ajouté un article à son panier le 15 août, mais qu'aucun événement d'achat n'a suivi.
- Vous pouvez partir du principe que l'utilisateur hésite à effectuer son achat, et ainsi le recibler avec les articles qu'il a ajoutés au panier.
Analyser le parcours utilisateur pour optimiser vos campagnes
- Le manager de l'acquisition d'utilisateurs (UA) d'une app de voyage télécharge les rapports d'installation et d'événements in-app, puis il les fusionne.
- Ensuite, pour consulter les parcours utilisateur dans l'app, il filtre ou agrège les données avec l'ID AppsFlyer.
- Il remarque qu'un certain utilisateur, identifié par son ID AppsFlyer, a téléchargé l'app il y a 12 mois et a réservé un vol quelques jours plus tard.
- Par la suite, l'utilisateur a consulté des offres de vols mais n'a effectué aucune réservation. En poursuivant sa recherche, le manager UA découvre d'autres d'utilisateurs qui ont suivi le même modèle, et continue son analyse.
- Il constate que ces utilisateurs proviennent en majorité de la publicité A de la campagne B diffusée via la source média C. Le manager UA comprend que la publicité et la campagne ont ciblé des utilisateurs souhaitant voyager vers une destination spécifique.
- En analysant le parcours utilisateur, il a pu découvrir que la campagne était trop ciblée, et que les utilisateurs n'étaient pas suffisamment investis dans l'application.
Rapports de fonctionnalités
Rapports relatifs aux fonctionnalités supplémentaires proposées sur la plateforme
Les postbacks
Utilisez les rapports de postback pour examiner les copies des données envoyées à un ad network. Par exemple, pour analyser les écarts ou anomalies. Ces rapports sont établis à titre informatif et ne sont pas obligatoires pour l'intégration aux ad networks.
- Le rapport contient :
- Copies des postbacks envoyées à la source média attribuée.
- Des champs de données brutes et champs supplémentaires tels qu'indiqués dans cette section.
- Le rapport ne contient pas :
- Les installations SRN.
- Événements in-app relatifs à Meta ads, Twitter et Apple Search Ads.
- Postbacks de partenaires non attribués. Cf événements attribués à tout partenaire ou organique.
- Utilisateurs organiques. Cf à propos des installations organiques.
- Campagnes d'installation CPA ayant désactivé les postbacks d'installation.
- Depuis mars 2021, les champs sont renseignés d'après les paramètres de confidentialité avancée du réseau. En d'autres termes, si la confidentialité avancée est activée, certains champs (comme les identifiants utilisateur) ne sont pas inclus. Cf Spécifications caractéristiques des postbacks de confidentialité avancée pour les réseaux publicitaires.
- URI pour les rapports de postback via API Pull
Rapports de postback
(disponibles via la page Données d'exportation et API Pull)
Sujet du rapport | Événements envoyés à la source média attribuée |
---|---|
d'installations | installations non organiques (UA) |
Évènement in-app | Les événements in-app non organiques |
Postbacks de conversion de retargeting |
Retargeting (réengagement et réattribution) |
événements in-app de retargeting |
Les événements in-app de retargeting |
Champs supplémentaires dans les rapports de postback
Champ | Remarques |
---|---|
URL de postback |
Certaines valeurs, comme les revenus, peuvent ne pas apparaître dans le champ approprié, mais ces données seront toujours consultables dans l'URL du postback. |
Méthode de postback | |
Code de réponse HTTP de postback | 200 : confirme que le postback a été reçu par l'ad network. |
Message d'erreur de postback |
Fraude Protect360 et règles de validation
- Cf Protect360 et rapports de données brutes des règles de validation
- Les ad networks et les agences ont besoin d'une autorisation d'annonceur pour accéder aux rapports Protect360 et aux règles de validation.
Pour accorder à un partenaire intégré la permission d'accéder à Protect360 :
- Allez dans Configuration > Intégrations actives.
- Sélectionnez le partenaire intégré.
- Dans l'onglet Autorisations, activez l'option Accès à votre tableau de bord Protect360 et aux données brutes via API.
- Pour donner accès au dashboard des événements in-app (CPA), activez Accès aux données agrégées des événements in-app.