Guide d'attribution des revenus publicitaires

Premium

Recommandé pour

Marketeurs

Dernière mise à jour : 18 décembre 2023 14:41

En bref : attribuez les revenus publicitaires pour compléter l'affichage des performances LTV.

L'attribution des revenus publicitaires

Les publicités s'affichent dans l'application sur des bannières, des murs d'offres, des interstitiels, etc., et elles génèrent des revenus publicitaires.
La somme des revenus publicitaires, achats in-app et revenus d'abonnement offrent une vision complète de la LTV de l'utilisateur. Le ROI est déterminé en associant la LTV de l'utilisateur et la dépenses des médias de la campagne, et il s'affiche sur la plateforme pour permettre une analyse.

Données des revenus publicitaires attribués :

Obtenues sur les réseaux de médiation et/ou de monétisation publicitaire via les API de serveur, ou via le SDK de reporting intégré à l'app (iOS 14 inclus).
Attribuées à la source média qui a initialement amené l'utilisateur. Par exemple :
- L'utilisateur voit une publicité du réseau A et télécharge votre application.
- La publicité s'affiche au sein de l'application.
- Les recettes publicitaires sont attribuées au réseau A (à l'origine de l'acquisition d'utilisateur), quel que soit l'auteur de la publicité.
La granularité des rapports dépend de l'intégration du réseau de monétisation et du type d'attribution des revenus publicitaires.

Types d'intégration pour l'attribution des revenus publicitaires

L'attribution des revenus publicitaires prend en charge différentes méthodes de granularité. La granularité dépend du réseau de monétisation.

Type d’intégration de l’attribution des revenus publicitaires	Description
Niveau agrégé via API S2S	AppsFlyer obtient le revenu quotidien réparti par zone géographique. Le revenu effectif par action (eRPA) est obtenu en divisant le revenu par le nombre de fois où un événement déclencheur s'est produit. Les événements déclencheurs sont une ouverture d'app, ou des événements in-app spécifiques qui ont été définis dans l'app. Si vous utilisez un réseau de médiation, veillez à désactiver les intégrations de revenus publicitaires pour les partenaires de monétisation médiatisés via ce réseau avant d'activer l'intégration des revenus publicitaires au sein du réseau de médiation. Si vous ne le faites pas, les données apparaitront en double.
Niveau appareil via API S2S	Le réseau de médiation ou de monétisation rapporte le revenu par utilisateur au niveau de l'appareil. Tous les réseaux ne prennent pas en charge la granularité de niveau utilisateur. Ce chiffre d'affaires est attribué à la source média qui a conduit l'utilisateur. L'attribution des revenus publicitaires d'AppsFlyer est conforme aux règles d'attribution de la plateforme, y compris les règles d'attribution du retargeting. Si vous utilisez un réseau de médiation, veillez à désactiver les intégrations de revenus publicitaires pour les partenaires de monétisation médiatisés via ce réseau avant d'activer l'intégration des revenus publicitaires au sein du réseau de médiation. Si vous ne le faites pas, les données apparaitront en double. Le niveau utilisateur via API S2S inclut la totalité des revenus publicitaires et il offre une précision optimale pour les données de type intégration des revenus publicitaires. Les données sont disponibles dans les rapports de données brutes. Nous n'envoyons aucun postback aux partenaires intégrés pour les données de niveau appareil.
Niveau impression via SDK	Le niveau impression concerne la manière dont AppsFlyer reçoit les données. Les données peuvent cependant être rapportées à un niveau de granularité différent (ex : au niveau de l'appareil). Le réseau de médiation ou de monétisation rapporte le revenu par utilisateur au niveau de l'impression. Tous les réseaux ne prennent pas en charge la granularité au niveau de l'impression. Ce chiffre d'affaires est attribué à la source média qui a conduit l'utilisateur. L'attribution des revenus publicitaires d'AppsFlyer est conforme aux règles d'attribution de la plateforme, y compris les règles d'attribution du retargeting. Si vous utilisez un réseau de médiation, veillez à désactiver les intégrations de revenus publicitaires pour les partenaires de monétisation médiatisés via ce réseau avant d'activer l'intégration des revenus publicitaires au sein du réseau de médiation. Si vous ne le faites pas, les données apparaitront en double. Parmi tous les types d'intégration des revenus publicitaires, le niveau impression via SDK est celui qui permet la meilleure actualisation des données. Prend en charge SKAN.
Niveau impression (via le SDK) avec niveau appareil (via API S2S)	Permet aux données de niveau impression qui arrivent via SDK d'être attribuées et rapportées au Jour X, et d'être échangées avec les données de niveau appareil transmises par API le Jour 1, et les suivants. Remarque : Pour Android, les données communiquées via le SDK à partir d'appareils inconnus (sans ID d'appareil disponible) ne sont pas remplacées par les données qui arrivent via l'API. Permet une actualisation des données précise. Vous bénéficiez ainsi de l'actualisation des données au jour X et de la précision des données pour les jours X + 1 et suivants. Prend en charge SKAN.

Implémentation

Les sections suivantes décrivent les types d'attribution de revenus publicitaires existants, ainsi que les opérations nécessaires à leur mise en place et suivi.

Se connecter aux partenaires intégrés de revenus publicitaires

Avant de commencer :

Demandez au partenaire intégré des revenus publicitaires de vous fournir des identifiants API.

Pour activer l'intégration des revenus publicitaires avec le réseau de revenus publicitaires :

Dans AppsFlyer, allez dans ROI360 > Paramètres des revenus > Revenus publicitaires.
Dans Integration des revenus publicitaires, cliquez sur Nouvelle intégration des revenus publicitaires.
Sélectionnez un partenaire des revenus publicitaires et cliquez sur Suivant.
Sélectionnez le type de données des revenus publicitaires que vous souhaitez recevoir. Remarque : tous les réseaux publicitaires ne proposent pas l'intégralité des options ci-dessous.
- Revenus attribués. Signifie que le revenu est basé sur la source d'acquisition d'utilisateurs. Les rapports sur les revenus attribués peuvent être soit :
  - Niveau agrégé via API S2S.
    - Sélectionnez l’événement sur lequel baser les revenus publicitaires. Exemple : si vous choisissez l'événement af_app_opened, le revenu publicitaire total est divisé entre tous les événements correspondant à l'ouverture de l'app, ce qui vous donne le revenu publicitaire par ouverture d'app.
  - Niveau appareil via API S2S
    - Remarque : Si vous activez l'API de revenus publicitaires de niveau appareil pour un réseau de médiation, vous devez désactiver les intégrations de revenus publicitaires des réseaux de monétisation qu'il concilie. Si vous ne le faites pas, les données seront affichées en double.
  - Niveau impression via SDK
  - Niveau impression (via le SDK) avec niveau appareil (via API S2S)
  - Remarque : si vous utilisez un réseau de médiation, veillez à désactiver les intégrations de revenus publicitaires pour les partenaires de monétisation médiatisés via ce réseau avant d'activer l'intégration des revenus publicitaires au sein du réseau de médiation. Si vous ne le faites pas, les données seront dupliquées.
Complétez les identifiants d'API, ou le login, comme l'exige le partenaire intégré. Ne concerne pas les intégrations SDK.
Cliquez sur Enregistrer.
Si le bouton Test de connexion s'affiche (cf image ci-dessus), cliquez sur Test de connexion.
- La clé API vérifiée s'affiche, la procédure est bien terminée.
- Si un autre message s'affiche, consultez la section Statut et test de l'API de revenus publicitaires, et recommencez la procédure.
Si vous ne voyez pas s'afficher le bouton Tester la connexion , la procédure est bien terminée.
AppsFlyer collecte les données du partenaire plusieurs fois par jour.
[Facultatif ] Suivez et comparez les données de revenus publicitaires affichées dans AppsFlyer avec les données de revenu publicitaire présentes dans les tableaux de bord de votre partenaire de médiation et de votre partenaire UA. En savoir plus
[Facultatif] Partagez les données de revenu publicitaire avec vos partenaires via les signaux UA et les postbacks d'événements de revenu publicitaire.

Remarque : si vous passez d’un type d’intégration à l'autre, la modification prend effet à 00 h (minuit) UTC le jour qui suit.

Afficher, modifier et supprimer les revenus publicitaires des partenaires intégrés

Pour afficher, modifier ou supprimer les intégrations des réseaux de revenus publicitaires ::

Dans AppsFlyer, allez dans ROI360 > Paramètres des revenus > Revenus publicitaires et sélectionnez votre app.
Une liste contenant toutes les intégrations de vos partenaires s'affiche, elle inclut des informations sur le produit et le type d'intégration, le statut de l'intégration ainsi que les noms des événements de revenus publicitaires.
Passez la souris sur l'intégration et cliquez sur Modifier ou Supprimer.

Supprimer les doublons des revenus publicitaires croisés

Une partie des données des revenus publicitaires peut se retrouver en double lorsque une app utilise deux plateformes de médiation, et que les deux sont associées au même réseau de monétisation. Dans ce cas, chaque plateforme de médiation rapporte tous les revenus publicitaires générées par le réseau de monétisation qui lui est associé, que ces revenus aient été générées par un seul des réseaux, ou les deux.

Pour éviter la duplication d'une partie des données de revenu lorsque deux plateformes de médiation se croisent :

Dans AppsFlyer, allez dans ROI360 > Paramètres des revenus > Revenus publicitaires.
Dans Paramètres généraux, cliquez sur Supprimer les doublons quand deux plateformes de médiation se croisent.Remarque : Ne supprimez pas les doublons si les deux plateformes média gèrent des formats publicitaires différents. Par exemple, lorsque la plateforme 1 affiche des bannières et des interstitiels, et que la plateforme 2 affiche des publicités Natives et AppOpen.

Granularité agrégée à l'aide d'événements d'ouverture d'app ou d'événements d'in-app

La granularité agrégée des revenus publicitaires fonctionne comme suit :

Le réseau intégré signale le revenu total par jour réparti par géo.
AppsFlyer calcule le revenu effectif par action (eRPA) en divisant le revenu publicitaire par le nombre de fois où un événement déclencheur s'est produit.
AppsFlyer crée un événement _monetized qui inclut le total des eRPA pour chaque appareil attribué. Ex : ad_matched_monetized.
Avec une eRPA le revenu est attribué aux sources média.
Vous pouvez utiliser l'un des types d'événements suivants :
- L'événement d'app unique de monétisation nécessite des modifications de l'app.
- Évènement af_app_opened disponible par défaut.
Ne rapportez pas le montant des revenus publicitaires dans les événements in-app si l'intégration des revenus publicitaires est en cours. Si vous le faites les revenus publicitaires sont dupliqués dans le tableau de bord car AppsFlyer obtient les données de revenus du réseau de monétisation par intégration.

Agrégation des revenus publicitaires à l'aide d'événements

Méthode d'événement	Comment procéder à l'implémentation ?	Attention
Événement d'app unique de monétisation	Un événement d'app est défini au moment de l'affichage de la publicité Cela fournit un nombre distinct d'actions utilisateur, ce qui permet d'effectuer des calculs eRPA supérieurs On peut augmenter le niveau de précision en créant un événement in-app différent pour chaque réseau de monétisation, ce qui permet de ventiler les revenus par réseau de monétisation . Voir le tableau suivant pour une explication avancée.	Nécessite que le développeur modifie l'app Les revenus peuvent être divisés par réseau de monétisation dans le tableau de bord
af_app_opened event	L'événement af_app_opened est envoyé par le SDK Appsflyer par défaut Est déclenché par chaque session d'utilisateur	Aucune modification requise dans l'app Implémentation rapide Les valeurs eRPA sont significativement déformées à moins que vous n'affichiez qu'une seule app par session Pas de répartition des revenus par réseau de monétisation L'événement concerne tous les utilisateurs qui lancent l'app, et dans le cas ou vous n'avez aucune indication de l'intention de l'utilisateur de regarder les publicités ou non

Comparaison des méthodes d'événements d'app

Méthode

Avantages

Inconvénients

Attention

Utilisez le même événement pour tous les réseaux. Ex : ad_watched. Cela génère automatiquement l'événement ad_watched_monetized qui inclut les détails de la monétisation.

Le plus simple à implémenter

Aucune information de qualité, comme le nombre de clics et les revenus publicitaires par réseau

Idéal si l'objectif principal est de trouver des sources/campagnes qui attirent les utilisateurs les plus enclins à cliquer sur les publicités.
N'est pas adapté pour comparer les performances des réseaux de monétisation.

(Recommandé) Attribuez un événement unique à chaque réseau pour le visionnage des publicités. Ex : ad_watch_admob,

ad_watch_vungle.

Visibilité totale et possibilité de comparer les réseaux de monétisation dans le tableau de bord, en plus des données brutes.

Les revenus publicitaires ne se cumulent pas en un seul événement. Le nombre d'événements est équivalent au nombre de réseaux

Permet de comparer la monétisation des réseaux dans le tableau de bord. Les revenus publicitaires sont classés par réseau à l'aide d'un événement in-app par réseau.

Statut et test de l'API pour les revenus publicitaires

Le statut opérationnel de l'intégration des revenus publicitaires est indiqué comme suit :
- Tableau de bord du statut de l'intégration des coûts et revenus publicitaires : la liste exhaustive des partenaires pour qui l'intégration des revenus publicitaires est activée, et ce pour une ou plusieurs apps hébergées sur votre compte.
- Certains partenaires vous permettent de tester la connexion API. Dans ce cas, un bouton Tester la connexion s'affiche.
- Pour vérifier que la connexion API est opérationnelle :
- Cliquez sur Tester la connexion.
  Le message Clé API vérifiée s'affiche. Si le message ne s'affiche pas, suivez les instructions du tableau suivant pour corriger le problème.

Statut	Signification	Remarques/actions requises
Clé API vérifiée	La connexion est active et peut extraire des données. Les données sont extraites une fois par jour.	Aucun
Identifiants invalides.	Un ou plusieurs des identifiants fournis sont incorrects.	Obtenez des identifiants corrects auprès du partenaire de revenus publicitaires.
Détails de configuration manquants	Un ou plusieurs champs d'identifiants sont incomplets	Récupérez les identifiants dans le tableau de bord du partenaire de revenu publicitaire, ou contactez le partenaire pour obtenir les identifiants.

Données sur les revenus publicitaires

Les données sur les revenus publicitaires sont disponibles via les tableaux de bord AppsFlyer et les rapports de données brutes.

Données agrégées des revenus publicitaires

Les revenus publicitaires indiquent la qualité des utilisateurs issus de différentes sources au fil du temps. Plus les utilisateurs lancent l'app et s'engagent dans les publicités, plus leur LTV augmente.

Remarque: les données de revenus publicitaires peuvent être légèrement différentes d'un tableau de bord et d'un rapport à l'autre. En savoir plus.

L'attribution des revenus publicitaires est disponible comme suit :

Basés sur la LTV :
- Les tableaux de bord sont les suivants : Général, Événements,
- Rapports LTV
- Tableau de bord et rapports de cohorte
- Master API
Basés sur l'activité :
- Tableau de bord : Activité
- Données brutes des revenus publicitaires

Tableau de bord général - rapport de performance agrégé

Dans le tableau Vue d'ensemble :

Les valeurs, y compris les revenus, sont des LTV. Voir La LTV et les données d'activité.
La colonne Revenus inclut l'ensemble des revenus, y compris les revenus publicitaires et les achats in-app.
Descendez dans la hiérarchie publicitaire (source média, campagne, ad set, geo) pour consulter les événements monétisés du rapport.

Tableau de bord des événements

Dans le tableau de bord Activité :

Les valeurs qui incluent les revenus sont basées sur la date d'activité. Voir La LTV et les données d'activité.
La moyenne des actions par utilisateur indique la tendance des utilisateurs en termes d'engagement avec les publicités présentées dans l'app.

Exemples

Trois utilisateurs installent une app le 31 décembre 2017. Ils sont attribués comme suit :

Utilisateur A : Réseau A
Utilisateur B : Réseau B
Utilisateur C : Organique

L'app est intégrée à cinq plateformes de monétisation différentes. Chaque plateforme utilise un événement in-app unique via le SDK AppsFlyer, comme indiqué ci-après :

Meta Audience Network : fb_ad_view
Chartboost : chartboost_ad_view
Admob : admob_ad_view
Applovin : applovin_ad_view
IronSource : is_ad_view

Pendant les 4 jours qui suivent l'installation, les utilisateurs voient s'afficher les publicités tel que décrit ci-après :

Utilisateur

Réseau UA

fb_
ad_view

chartboost_
ad_view

admob_
ad_view

applovin_
ad_view

is_ad_view

Total

Réseau A

31/12/2017

01/01/2018

1 $

02/01/2018

1 $

03/01/2018

1 $

04/01/2018

1 $

4 $

Réseau B

31/12/2017

02/01/2018

1 $

04/01/2018

1 $

2 $

Trafic

31/12/2017

01/01/2018

1 $

02/01/2018

1 $

2 $

En examinant les données, nous pouvons maintenant résumer les revenus collectés soit par utilisateur, soit par jour (et par événement in-app) :

Utilisateur	01/01/2018	02/01/2018	03/01/2018	04/01/2018	LTV totale
A	1 $	1 $	1 $	1 $	4 $
B		1 $		1 $	2 $
C	1 $	1 $			2 $
Total	2 $	3 $	1 $	2 $	8 $

Comprendre les rapports :

Comme mentionné, les revenus publicitaires sont liés à la LTV de l'utilisateur. Par conséquent, la période que vous sélectionnez dans le tableau de bord représente la cohorte d'installations pour lesquelles les revenus sont agrégés jusqu'à l'heure et le jour actuels. Examinons un rapport avec deux sélections de dates différentes :

Rapport agrégé : dates sélectionnées : 31/12/2017-05/01/2018

Réseau	Revenus LTV
Trafic	2 $
Réseau A	4 $
Réseau B	2 $
Réseau C	2 $

Dans ce cas, la cohorte est celle des utilisateurs qui ont installé l'app entre le 31/12/2017 et le jour en cours, soit le 05/01/2018. Tous les revenus générés par ces utilisateurs sont liés à la source d'acquisition et représentés dans la LTV de l'utilisateur.

Données brutes des revenus publicitaires

Les rapports de données brutes sur les revenus publicitaires contiennent des données fournies par les réseaux de monétisation intégrés à AppsFlyer au niveau appareil et au niveau impression.

Principes des données brutes sur les revenus publicitaires

Les données sont agrégées par le nombre d'impressions uniques par utilisateur. Les impressions uniques sont dérivées de la combinaison du réseau de monétisation publicitaire, de l'unité publicitaire et du placement.
Les données brutes de niveau impression sont :
- Agrégées au niveau de l'appareil et disponibles dans les rapports de niveau appareil.
- Disponibles dans les rapports de niveau impression dans Data Locker.
- Les données brutes sont actualisées au même rythme que les revenus publicitaires de niveau appareil du tableau de bord Activité.

Rapport	Page Données d'exportation	API Pull	Data Locker
Revenus publicitaires attribués (non organiques)	✓	✓	✓*
Revenus publicitaires organiques	✓	✓	✓*
Revenus publicitaires de retargeting	✓	✓	✓*
Données brutes de niveau impression	-	-	✓
* Un rapport versionné est également disponible, il est actualisé plusieurs fois par jour et comporte des données agrégées au niveau de l’appareil. Les rapports Data Locker non versionnés sont émis quotidiennement.

Caractéristiques et champs des données

Les champs des rapports sur les revenus publicitaires sont remplis :

Par l'événement de revenus publicitaires lui-même, et ils sont répertoriés dans le tableau suivant. Ces champs sont divisés en trois catégories :
- Spécifique : champs spécifiques aux revenus publicitaires. Par exemple, les impressions et le placement. Important ! Les champs renseignés diffèrent selon le partenaire de monétisation, comme le montre le tableau Champs par réseau de cette section.
- Contexte : les champs ayant une signification similaire dans d'autres rapports de données brutes. Par exemple, nom de l'événement, valeur de l'événement, devise.
Correspond à l'attribution de l'événement à la source média qui a drainé l'utilisateur. Ce qui signifie que ces champs sont copiés depuis l'événement de conversion qui a drainé l'utilisateur. Par exemple, la source média et la campagne. Ces champs ne figurent pas dans le tableau qui suit.

Champs alimentés par les revenus publicitaires

api_name	Nom du champ	Type de champ	Description
event_time	Heure de l'évènement	Contexte	Date à laquelle le revenu est attribué
event_name	Nom de l'événement	Contexte	La valeur par défaut est af_ad_revenue Peut également être un événement personnalisé
event_revenue	Devise du revenu des évènements	Contexte	Montant des revenus selon la devise des revenus d'événements. La valeur zéro indique une impression dénuée de revenu
event_revenue_currency	Devise de l'événement	Contexte	Devise du revenu des évènements
event_revenue_XXX	Revenu de l'évènement XXX	Contexte	Sur la page d'exportation : revenu converti dans la devise spécifique à l'app Dans Data Locker, toujours en USD Dans l'API Pull, en fonction de la devise de l'extraction.
country	Pays	Contexte	Pays d'installation de la conversion de l'installation
ad_unit	Unité publicitaire	Spécifique	Type de publicité
segment	Segment	Spécifique	Nom d'emplacement de la publicité
monetization_network	Réseau de monétisation	Spécifique	Réseau qui envoie la publicité
Impressions	Impressions	Spécifique	Nombre de fois où l'utilisateur a vu la publicité
mediation_network	Réseau de médiation	Spécifique	Réseau de médiation qui signale l'événement à AppsFlyer

Champs par réseau

Nom d'affichage	Admob	ironSource	AppLovin MAX	Appodeal	Fyber
Unité publicitaire	✓	✓	✓	✓	✓
Segment	-	(1)	-	-	-
Placement	-	✓	✓	✓	✓
Réseau de monétisation	✓	✓	-	✓	-
Impressions	-	-	✓	✓	-
Réseau de médiation	-	✓	✓	✓	-
(1) L'annonceur doit configurer cet élément dans ironSource

Exemple de rapport sur les données brutes des revenus publicitaires

Actualisation des données

L'actualisation des données dépend du type d'intégration et de la méthode de reporting.

Pour les intégrations d'API S2S, les données sont disponibles au plus tôt :

Tableaux de bord et rapports (via Data Locker), depuis le jour X+1, 08:00 UTC, environ 4 fois par jour, soit toutes les 6 heures.Et pour les abonnés ROI360, les jours 2, 3, 7 et 14, une fois par jour.

Pour les intégrations SDK de niveau impression, les données sont disponibles au plus tôt :

Tableaux de bord et rapports (via Data Locker), au plus tôt depuis le jour X à 05:00 UTC, mise à jour environ 6 fois par jour, soit toutes les 4 heures.
Les rapports de données brutes de niveau impression (via Data Locker) commencent au Jour X à 01:00 UTC, avec une mise à jour toutes les heures.

Pour le niveau impression (via le SDK) avec un niveau appareil (via l'API S2S), l'actualisation des données au jour X et la précision des données pour les jours X+1 sont les suivantes :

Pour les données de niveau impression qui arrivent via SDK :
- Tableaux de bord et rapports (via Data Locker), au plus tôt depuis le jour X à 05:00 UTC, mise à jour environ 6 fois par jour, soit toutes les 4 heures.
- Les rapports de données brutes de niveau impression (via Data Locker) commencent au Jour X à 01:00 UTC, avec une mise à jour toutes les heures.
Pour les données de niveau appareil qui arrivent via API S2S :
- Tableaux de bord et rapports (via Data Locker) depuis le jour X+1, 08:00 UTC, environ 4 fois par jour, soit toutes les 6 heures. Et pour les abonnés ROI360, les jours 2, 3, 7 et 14, une fois par jour.

Pour les intégrations héritées (antérieures à ROI360), les données sont actualisées au jour X+1, au plus tôt à 17:00 UTC.

Remarque : Lors du changement de type d'intégration, les données reçues avec le type d'intégration précédent pour des dates antérieures ne sont pas complétées par le nouveau type d'intégration. Par exemple, si le jour X le type d'intégration est passé de SDK à S2S, les données sont extraites à partir du jour X+1 et ne sont pas extraites pour les jours précédant le jour X.

Rapports Data Locker sur les revenus publicitaires

Nom

Actualisation

Sections du rapport

Revenus publicitaires quotidiens (agrégées au niveau de l'appareil)

Les revenus publicitaires pour un jour donné (jour X) apparaissent dans le rapport du jour suivant (X+1), à 20:00 UTC.

Par exemple, les revenus publicitaires du 1er mai apparaîtront dans le rapport du 2 mai.

Le rapport comprend des sections sur les revenus publicitaires attribués, organiques et provenant du retargeting.

Rapport sur les revenus publicitaires quotidiens (agrégé au niveau de l'appareil)

Le rapport quotidien comprend :

Les versions du jour, créées toutes les 4 heures pendant le jour des revenus (jour X). Les données journalières sont collectées par le connecteur SDK ROI.
Les versions de la journée entière créées les jours 2, 3, 7 et 13, sur la base de données provenant des rapports S2S API.

En d'autres termes, le jeu de versions d'un rapport journalier comprend les versions suivantes :

00:00 — 04:00 au jour X.
00:00 — 08:00 au jour X [connecteur SDK ROI]
00:00 — 12:00 au jour X [connecteur SDK ROI]
00:00 — 24:00 au jour X [connecteur SDK ROI]
00:00 — 24:00 au jour x+1 [S2S]
00:00 — 24:00 au jour x+2 [S2S]
00:00 — 24:00 au jour x+6 [S2S]
00:00 — 24:00 au jour x+13 [S2S]

Chaque version du rapport comprend des sections sur les revenus publicitaires attribués, organiques et provenant du retargeting.

Rapport sur les revenus publicitaires au niveau de l'impression (niveau de l'impression)

Les enregistrements des revenus publicitaires au niveau de l'impression sont enregistrés toutes les heures dans un fichier distinct.

Informations supplémentaires

Migrer d'une granularité de niveau agrégé à un niveau appareil

La migration n'a pas d'impact sur les données historiques des revenus publicitaires. Ces données restent inchangées.
Les données sur les revenus publicitaires sont extraites une fois par jour à 1400 UTC, en utilisant les options de granularité sélectionnées à ce moment-là.
La granularité de niveau appareil ne nécessite pas de définir des événements in-app (comme vous le faites pour les rapports agrégés). Vous pouvez continuer à envoyer ces événements, mais ils n'affectent pas les rapports de granularité de niveau utilisateur dans AppsFlyer.

Signaux UA pour les réseaux publicitaires

Remarque

Travailler avec des réseaux publicitaires pouvant recevoir des signaux UA est une possibilité. Cela signifie que les réseaux publicitaires responsables de l'acquisition d'utilisateurs peuvent recevoir les données des réseaux de médiation pour ce qui concerne les revenus publicitaires, et qu'ils peuvent les mettre à profit pour optimiser les campagnes UA de leurs clients.

Pour transmettre des signaux aux réseaux publicitaires UA, les partenaires de médiation doivent avoir une intégration de niveau impression ou appareil.

Pour savoir ce que le partenaire doit faire pour recevoir le rapport, consultez ce lien.
Pour savoir ce que l'annonceur doit faire pour donner au partenaire l'accès au rapport, veuillez consulter ce lien.

Liste des partenaires de médiation pouvant envoyer des signaux UA aux réseaux publicitaires UA :

Applovin Max
Google AdMob
Appodeal
Chartboost
Fyber
Tapdaq
Topon
Unity
Médiation Unity LevelPlay (anciennement ironSource)
Admost
Tradplusad
Yandex

Liste des réseaux publicitaires UA qui peuvent recevoir des signaux UA :

AdAction
Adamobi
Adjoe
Adonco
Adshow
Appier
Apprainbow
Aura par Unity
Betop
Bidswave
Brandscale
Chameleostudios
Chartboost
Datawave
DLab
Ecomonline
Etusdigital
Foregon
GNA Company
Happimobi
Hybrid
Inflecto
Irismedia
Lambadapp
Leadidadmonster
Lifestreet
Liftoff
Melodong
Mintegral
Mobrand
Moloco
Motive
Mpnd
Msla
Muvmobile
Nexamob
Nftdroper
Nsofmedia
Performadlive
Personalyrtb
Pitatroas
Rebornads
RTBhouse
Runfuns
Scmobi
Shalltry
Shareit
Smadex
Tapjoy
Targetmedia
Thepurpleline
TikTok pour les entreprises
Trademob
Truemoney
Unity Ads
Yandex
Yeahmobi
Z2A Digital
Zoyo

Permettre aux réseaux publicitaires d'obtenir les données brutes de revenus publicitaires

Avant de pouvoir recevoir les données des réseaux de médiation, les réseaux publicitaires responsables de l'acquisition d'utilisateurs doivent obtenir votre autorisation.

Conditions préalables :

L'abonnement à ROI360 Advanced est requis.
Contactez le réseau publicitaire pour confirmer qu'il dispose du processus d'ingestion nécessaire pour traiter au mieux vos données.

Pour permettre aux réseaux publicitaires d'obtenir les données de revenus publicitaires :

Allez dans Configuration > Intégrations actives.
Sélectionnez le partenaire intégré.
Ouvrez l'onglet Intégration.
Vérifiez que Activer le partenaire est coché. Si l'option n'est pas activée, les données ne seront pas partagées.
Allez dans l'onglet Autorisations.
Activez les Autorisations du réseau publicitaire.
Activez Accéder aux données brutes des revenus publicitaires.
Dans Option d'envoi, précisez si vous souhaitez envoyer les données de revenus publicitaires de ce partenaire uniquement (Ce partenaire uniquement) ou celles issues de toutes les sources média (Toutes les sources média, y compris organiques).
Cliquez sur Enregistrer les paramètres.
Contactez le réseau publicitaire pour l'informer que vous lui avez accordé les autorisations.
Assurez-vous que le réseau publicitaire a activé le rapport dans son Data Locker, et configuré ses paramètres de sortie.

Postbacks d'événements des revenus publicitaires pour les réseaux publicitaires

Vous pouvez configurer les postbacks de revenu publicitaire pour les réseaux publicitaires. Cela signifie que les réseaux publicitaires responsables de l'acquisition d'utilisateurs peuvent recevoir les données des réseaux de médiation en temps réel (pour ce qui concerne les revenus publicitaires) et qu'ils peuvent les mettre à profit pour optimiser les campagnes UA de leurs clients.

Pour envoyer des postbacks aux réseaux publicitaires UA, vous devez avoir une intégration de niveau impression via le SDK avec le réseau de médiation. AppsFlyer génère automatiquement un événement af_ad_revenue pour chaque impression. Ces événements peuvent être sélectionnés dans la liste des événements à envoyer au réseau publicitaire UA via les postbacks d'évènements in-app.

Important !

Bien que vous puissiez envoyer des postbacks de revenus publicitaires à des partenaires spécifiques, vous devez valider la façon dont les partenaires utilisent les données avant de commencer l'intégration.

Pour mettre en place des postbacks d'événements générateurs de revenus publicitaires :

Recherchez et sélectionnez votre partenaire, soit à partir du marketplace , soit à partir de la page Configuration > Intégrations actives.
Dans l'onglet Integration, faites défiler vers le bas et activez Postbacks d'évènements in-app.
Sélectionnez l'événement AppsFlyer af_ad_revenue.

Mettez-le en correspondance avec l'événement du réseau publicitaire UA comme suit :

Réseau publicitaire UA	Événement à associer à af_ad_revenue	Capture d'écran
ironSource	adRevenue
Unity Ads	ad_revenue
Moloco	Aucun mappage n'est nécessaire
Mintegral	Aucun mappage n'est nécessaire
Smadex	Aucun mappage n'est nécessaire
Meta Ads	fb_mobile_purchase
TikTok for Business - SRN avancé	ImpressionLevelAdRevenue
Aura par Unity	ad_revenue

Cliquez sur Enregistrer l'intégration.

Liste des partenaires de médiation pouvant envoyer des événements de revenus publicitaires de niveau impression aux réseaux publicitaires UA :

Applovin Max
Google AdMob
Appodeal
Chartboost
Fyber
Tapdaq
Topon
Unity
ironSource
Admost
Tradplusad
Yandex

Liste des réseaux publicitaires UA pouvant recevoir des postbacks d'événements des revenus publicitaires :

ironSource
Unity Ads
Moloco
Mintegral
Meta Ads
Smadex
TikTok for Business - SRN avancé

FAQ

Comment puis-je obtenir le revenu publicitaire total de chaque plateforme ?

L'attribution des revenus publicitaires est liée et s'affiche par rapport à la source d'acquisition utilisateur.
Cela permet d'avoir une vue de la LTV de votre ROI et de vos KPI.
Pour afficher le revenu total de chaque plateforme de monétisation, utilisez un événement in-app différent pour chaque réseau et suivez la procédure suivante :
1. Dans le dashboard général, rendez-vous dans tableau de rapports des performances agrégées.
2. Sélectionnez jusqu'à quatre événements monétisés représentant les plate-formes que vous souhaitez interroger.
3. Téléchargez le rapport en cliquant sur Exporter le CSV.
4. Additionnez les chiffres de la colonne Revenue correspondant à l'événement monétisé de la plateforme demandée.

Remarque : ce revenu publicitaire total est composé de données LTV, c'est-à-dire l'entièreté des revenus générés par un réseau monétisé sur votre app, et ce pour les utilisateurs qui ont installé l'app pendant la période spécifiée.

Les revenus publicitaires sont-ils disponibles sur la page d'activité ?

Oui. La page Activité indique l'ensemble des revenus issus des achats in-app et des revenus publicitaires. Remarque : les données de revenus publicitaires sont envoyées à AppsFlyer sur une base quotidienne, le lendemain de l'événement.

Dois-je activer le partenaire dans l'onglet Intégration ?

Si vous collaborez avec le partenaire uniquement en ce qui concerne la monétisation publicitaire (revenus publicitaires), ne choisissez pas l'option Activer le partenaire dans l'onglet intégration. Activez uniquement Obtenir les revenus publicitaires dans l'onglet des revenus publicitaires.

Comment les revenus publicitaires au niveau de l'appareil sont-ils attribués si un utilisateur a une version de l'app sans le SDK AppsFlyer ?

Les revenus publicitaires sont attribués comme étant organiques.

Y a-t-il des différences de données de revenus publicitaires d'un tableau de bord ou d'un rapport à l'autre ?

Il peut y avoir des écarts entre les données de revenus publicitaires affichées dans le tableau de bord général, dans les rapports de données brut et dans les tableaux de bord Activité ou Cohorte. Explications :

Les données de revenus publicitaires des tableaux de bord Cohorte et Activité, ainsi que les données issues des API principales et API de cohorte, sont mises à jour rétroactivement. Ce qui n'est pas le cas dans le tableau de bord Général, ni dans l'exportation de données brutes ou l'API Pull.
Les données s'affichent parfois dans les tableaux de bord Activité et Cohorte avant d'apparaitre dans le tableau de bord général.
Les tableaux de bord incluent les événements marqués comme af_ad_revenue et _monetized, alors que les données brutes ne comprennent que les événements af_ad_revenue.

Particularités et limites

Particularité	Remarques
Limites	Les événements de revenus publicitaires ne sont pas disponibles pour : API push Tableau de bord de retargeting Limitations de granularité au niveau de l'appareil : L'événement af_ad_revenue n'est pas disponible pour les cohortes dans Pivot et Master API. L'événement est disponible dans l'analyse de cohorte. Des divergences peuvent se produire lors de l'implémentation des revenus d'enchères in-app de Meta ads. Le nombre d'utilisateurs uniques qui ont déclenché un événement af_ad_revenue n'est pas disponible dans les tableaux de bord AppsFlyer.
Accès du réseau publicitaire	Impossible d'accéder aux rapports de cohorte
Autorisations de l'agence	Agences : Impossible d'accéder aux configurations des revenus publicitaires. Peut consulter tous les dashboards et les données qui y sont liées.
Transparence de l'agence	Non pris en charge
Fuseau horaire	Les revenus publicitaires s’affichent dans les tableaux de bord et les rapports AppsFlyer uniquement dans le fuseau horaire UTC. En d'autres termes, si les données sont rapportées à 14 h UTC+2, dans AppsFlyer elles s'affichent à 14 h UTC. Traitement quotidien. AppsFlyer doit en effet standardiser les données issues de multiples sources et partenaires, or la plupart rapportent leurs données en UTC.
Devise	Dans AppsFlyer : Le dashboard affiche la devise spécifique à l'app de l'annonceur. Les rapports sur les données brutes affichent la devise d'origine, qu'elles convertissent en plus dans la devise spécifique à l'app de l'annonceur.
Type de données	Les données organiques et non organiques sont toutes prises en charge
Actualisation des données	Revenus publicitaires
Données historiques/rétroactives	Les données sont extraites et disponibles à compter du jour de l'intégration. Les données historiques ne sont donc pas disponibles avant le jour de l'intégration (jour 0). Les données de revenus publicitaires reçues via API S2S un certain jour sont mises à jour les jours 1, 2 et 3. Les données de revenus publicitaires des tableaux de bord Cohorte et Activité, ainsi que les données issues des API principales et API de cohorte, sont mises à jour rétroactivement. Ceci n'est pas le cas dans le tableau de bord Général, ni dans l'exportation de données brutes ou l'API Pull. Si vous disposez du package revenus avancés, les données sont également mises à jour dans Data Locker.
Accès utilisateur du compte	Prise en charge
SKAN	Pris en charge par des connecteurs SDK de revenus publicitaires au niveau de l’impression.
Géo/pays	Dans le tableau de bord de cohorte, lorsque les données géo sont inconnues (N/A), les données N/A ne s'affichent pas lors de l'agrégation par géo.
Postback d'évènements in-app	Les postbacks envoyés aux partenaires sont ceux qui concernent les données des événements in-app attribués à ces mêmes partenaires ; ils n'incluent pas les données relatives aux autres sources média.
Applications CTV, PC et consoles	Pas de prise en charge. Seules les applications Android et iOS sont prises en charge.

Liste des partenaires intégrés de revenus publicitaires

Partenaire	Paramètres d'identification requis	Granularité des données
AdColony	Clé API ID d'app	Niveau agrégé avec géo
Admost	ID de l'app réseau Jeton	Au niveau appareil avec géolocalisation
AppLovin	Clé du rapport Nom du package de l'app	Niveau agrégé avec géo
AppLovin MAX	Clé du rapport Nom du package de l'app	Niveau appareil avec géolocalisation Niveau impression (via le SDK)
Appodeal	Clé d'application Clé API ID utilisateur	Niveau agrégé avec géo Niveau appareil
Bytedance Ads - Trafic en Chine	Clé sécurisée ID d'app ID de compte	Niveau agrégé avec géo
Chartboost	ID utilisateur Signature de l'utilisateur ID d'app	Niveau agrégé avec géo
Meta Ads	Se connecter à Meta ads	Niveau agrégé avec géo
Fyber	Code secret client ID D'API ID du client	Niveau appareil avec géolocalisation Niveau impression (via le SDK)
Google marketing platform - DV360/CM (DoubleClick)	Connexion à Google Marketing Platform - DV360/CM	Niveau agrégé avec géo
Google Admob	ID d'app AdMob	Niveau agrégé avec géo Niveau impression (via le SDK)
Google Ads	Authentification API par OAuth	Niveau agrégé avec géo
IronSource	Clé secrète Nom d'utilisateur ID d'app	Niveau agrégé avec géo Niveau appareil Niveau impression (via le SDK)
Mintegral	ID d'app Clé secrète Clé API	Niveau agrégé avec géo
Tapjoy	ID d'app Clé API marketing	Au niveau appareil avec géolocalisation
TikTok pour les entreprises	Clé sécurisée ID d'app ID de compte	Niveau agrégé avec géo
TopOn	ID de l'app réseau Clé de l'éditeur	Au niveau appareil avec géolocalisation
Médiation Tradplus	Clé API ID de l'app réseau	Au niveau appareil avec géolocalisation
Unity Ads	Clé API ID d'app	Niveau agrégé avec géo Niveau impression (via le SDK)
Voodoo Ads	ID de groupe Jeton d'accès	Niveau agrégé avec géo
Vungle	Clé API ID d'app	Niveau agrégé avec géo
Yandex	S/O	Niveau impression (via le SDK)