Vue d'ensemble du reporting des données brutes

Recommandé pour
Marketeurs Agences
Dernière mise à jour :

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

Lecture connexe : rapports et analyses agrégés

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.

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
  • Télécharger le rapport depuis l'interface utilisateur
  • Format : fichier CSV
 Unique Mise à jour en continu X

Spécifique à l'app

 Spécifique à l'app
API pull*
  • Télécharger le rapport à l'aide des appels d'API.
  • Format : fichiers CSV
 Unique Mise à jour en continu ✓
  • Sélectionnable
  • Par défaut : UTC
  • Sélectionnable
  • Par défaut : USD
Data Locker P
  • Données envoyées vers un compartiment dans le Cloud.
  • Pas de volume maximum
  • Fenêtre de disponibilité des données : 14 jours.
  • Format : CSV ou Parquet
 Multiple Mise à jour continue avec un décalage de plusieurs heures ✓ UTC USD 
API Push P
  • Données sur les parcours utilisateurs (installations, événements in-app, retargeting, SKAN) transmises à vos serveurs en temps réel.
  • Format : JSON ou params de requête
 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)
  • Permet d'obtenir les données de conversion d'attribution dans l'app.
  • Format : JSON
 S/O  Temps réel <5 secondes  ✓ UTC S/O

Remarques/abréviations :
(1) Prend en charge le multi apps
(2) L'actualisation effective des données dépend du rapport, car certains rapports sont quotidiens.
(3) Les données de conversion du SDK récupèrent les données d'attribution des utilisateurs en moins de 5 secondes à compter du premier lancement de l'application, ce qui en fait la méthode la moins précise.
(P) Fonctionnalité Premium
(*) Des limitations sur la génération des rapports s'appliquent

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

Raw_data_-_User_acquisition_.png

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.

      Raw_data_-_Retargeting.png

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
  • Optimisez les campagnes qui ne conduisent pas à l'ouverture d'une app (installation, réattribution, réengagement).
  • Reciblez ces utilisateurs avec différentes campagnes.
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
  • Générez des rapports agrégés en utilisant des champs non disponibles via les outils d'analyse d'AppsFlyer.
  • Cumulez avec d'autres rapports pour une analyse transversale avancée.
  • Analysez les performances à travers différentes dimensions comme les localités, zones métropolitaines, etc.
  • Segmentez les utilisateurs en fonction des pays, localités et langues à des fins de retargeting.
  • Obtenez des ID d'appareil utilisateur à des fins de retargeting.
 Identique aux installations.
Organique ou non organique
  • Non-organique : les groupes de champs d'attribution et d'attribution des contributeurs sont renseignés.
  • Organique : le champ source média est soit vide, soit null, soit organique. Gardez ces éléments à l'esprit lorsque vous chargez les données dans votre système.
 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
  • La structure et les champs du rapport sont identiques à ceux des rapports d'installation.
  • Les champs dédiés décrivent l'événement. Il s'agit notamment du nom de l'événement, de sa valeur, son revenu et son heure.

Cas d'utilisation

Le rapport vous permet de :

  • Obtenir des informations en observant le parcours utilisateur pendant la durée vie de l'utilisateur

  • Cumulez les données brutes d'installation et des événements in-app pour suivre l'ensemble du parcours utilisateur.

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.


{"af_level":"10","af_user_journey":"3387","arena":"7","char_type":"paladin"}

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
  • Les événements in-app de retargeting sont enregistrés deux fois, à la fois dans les rapports UA et les rapports de données brutes d'événements in-app de retargeting.
  • Les événements in-app n'incluent pas l'événement de lancement (af_app_opened). Cette option est disponible dans le rapport de données brutes des sessions.
  • Emplacement geo : provient de l'adresse IP utilisateur au moment où l'événement se produit.

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
  • Ce rapport est mis à jour quotidiennement et non en continu, c'est également le cas pour les autres rapports de parcours utilisateur.
  • Dans le rapport, l'heure de l'événement correspond à l'heure à laquelle AppsFlyer détermine que l'app a été désinstallée, et non à l'heure de la désinstallation en elle-même. Cf Mesure des désinstallations.
Champs disponibles
  • Si l'utilisateur est issu d'une source média non organique, les champs source média sont renseignés.
  • Notez que l'événement de désinstallation est généré par les serveurs AppsFlyer seulement après avoir déterminé que l'utilisateur a effectué la désinstallation. Ce qui explique que de nombreux champs ne sont pas renseignés.
  • Les identifiants utilisateur disponibles sont ceux enregistrés au moment de l'installation. Le CUID n'est jamais disponible. 
  • Les champs géo sont remplis d'après la localisation de l'utilisateur à l'heure de l'engagement avec la source média (par clic ou impression). Si la localisation de l'engagement n'est pas disponible, c'est celle associée à l'événement d'installation qui est utilisée.
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
  • Analyser l'événement de désinstallation, les caractéristiques de l'appareil et de l'utilisateur
  • Créer une audience d'évènement de désinstallation pour le retargeting.

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 - - ✓ - -
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 Facebook sont-elles manquantes ?

Par défaut, les données brutes de Facebook sont attribuées à la source média qui est limitée. Cf Les données Facebook de niveau 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 :

  • Heure du touch attribué: l'heure à laquelle l'utilisateur s'est engagé avec une publicité.
  • Heure d'installation : heure à laquelle l'app est lancée pour la première fois.
  • Heure de l'événement: l'heure où l'événement se produit.

Important :

  • Dans les rapports d'installation, les heures d'installation et d'événement sont les mêmes.
  • Dans les rapports d'événements in-app, les heures d'installation et d'événement diffèrent. L'écart entre les deux peut indiquer le temps écoulé entre le lancement de l'app et l'engagement de l'utilisateur avec l'app.

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 de mesure. Ces rapports sont établis à titre informatif et ne sont pas obligatoires pour l'intégration aux ad networks.

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 :

  1. Allez dans Intégration > Partenaires intégrés. 
  2. Sélectionnez le partenaire intégré.
  3. Dans l'onglet Autorisations, activez l'option Accès à votre tableau de bord Protect360 et aux données brutes via API.
  4. 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.