Guide d'attribution des revenus publicitaires

Recommandé pour
Marketeurs
Dernière mise à jour :

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

mceclip0.png

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.

Types d'intégration pour l'attribution des revenus publicitaires
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 utilisateur 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 utilisateur.
[Bêta] 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.
[Bêta clôturé] Niveau impression (via SDK) avec niveau utilisateur (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 utilisateur transmises par API le Jour 1, et les suivants.
  • Offre le double avantage 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.
[Bêta clôturé] Niveau impression via SDK avec niveau agrégé via API S2S
  • AppsFlyer obtient quotidiennement les revenus répartis par dimensions de monétisation, comme le placement, les unités publicitaires, le type de publicité, etc.
  • 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 les événements de niveau impression avec les dimensions de monétisation transmises via le connecteur SDK. Remarque : le montant des revenus publicitaires n'est pas inclus dans les données de niveau impression, il n'est disponible que lorsque les données de niveau agrégé sont reçues. 
  • Ce type d'attribution est plus précis que le niveau agrégé standard via API S2S.

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

ad_revenue_integration_2.png

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 :

  1. Dans AppsFlyer, allez dans Configuration > Partenaires intégrés.
     La fenêtre Partenaire intégré s'ouvre.
  2. Sélectionnez un partenaire. Conseil : sélectionnez Actif et Revenus publicitaires pour afficher ceux de vos partenaires qui ont des capacités de revenus publicitaires.
    La fenêtre de configuration du partenaire intégré s'ouvre.
  3. Accédez à l'onglet Revenus publicitaires et activez Obtenir les données des revenus publicitaires.
  4. 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 utilisateur via API S2S
        • Remarque : si vous activez l'API de revenus publicitaires de niveau utilisateur 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
      • [Bêta clôturé] Niveau impression via SDK avec niveau agrégé via API S2S.
      • [Bêta clôturé] Niveau impression (via SDK) avec niveau utilisateur (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.
  5. Complétez les identifiants d'API, ou le login, comme l'exige le partenaire intégré. Ne concerne pas les intégrations SDK.
  6. Cliquez sur Enregistrer les revenus publicitaires.
  7. Si le bouton Test de connexion s'affiche (cf image ci-dessus), cliquez sur Test de connexion.
  8. 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.

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

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. mceclip0.png
    • 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  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.
Statut de la connexion de l'API des revenus publicitaires

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 :

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

Après l'installation pendant une période de quatre jours, les utilisateurs voient apparaître des publicités, comme suit :

Utilisateur

Réseau UA

fb_
ad_view

chartboost_
ad_view

admob_
ad_view

applovin_
ad_view

is_ad_view

Total

A

Réseau A

31/12/2017

01/01/2018

1 $

02/01/2018

1 $

03/01/2018

1 $

04/01/2018

1 $

 

 4 $
 B

Réseau B

31/12/2017

02/01/2018

1 $

 

04/01/2018

1 $

 

   2 $
 C

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) :

LTV de l'utilisateur

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

PremiumFeature.jpg

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 utilisateur 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'utilisateur et disponibles dans les rapports de niveau utilisateur.
    • [Bêta clôturé] 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 utilisateur 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  - - [Bêta clôturé]
 

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

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 au niveau agrégé :
    • Les tableaux de bord et les rapports LTV sont Jour X +2, 05:00 UTC
    • Les tableaux de bord et les rapports d'activité sont Jour X+1, 14:00 UTC
  • Pour les intégrations d'API S2S de niveau utilisateur :
    • Les tableaux de bord et les rapports LTV sont Jour X +2, 05:00 UTC
    • Les tableaux de bord et les rapports d'activité sont Jour X+1, 14:00 UTC
    • Les rapports de données brutes sont Jour X+1, 20:00 UTC
  • Pour les intégrations SDK de niveau impression :
    • Les tableaux de bord et les rapports LTV sont Jour X +2, 05:00 UTC
    • [Bêta] Les tableaux de bord et les rapports d’activité sont Jour X à partir de 05:00 UTC, mise à jour toutes les 4 heures
    • Les rapports de données brutes sont Jour X+1, 20:00 UTC
    • [Bêta] Les rapports de données brutes de niveau impression (via Data Locker) sont au Jour X à partir de 01:00 UTC, avec mise à jour toutes les heures.

Dans les rapports, la date de l’événement de revenus publicitaires est toujours le Jour X, c’est-à-dire le jour où l’événement de revenus publicitaires s'est produit (le jour où la publicité s'est affichée). Notez cependant que les données ne peuvent s’afficher que 1 jour ou 2 après l’événement (Jour X+1 ou Jour X+2).

Informations supplémentaires

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

  • 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é au niveau utilisateur ne nécessite pas la définition d'é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é au niveau utilisateur dans AppsFlyer. 

Signaux UA pour les réseaux publicitaires

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 de impression ou de niveau utilisateur.

En savoir plus sur les signaux UA

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
  • ironSource
  • Admost
  • Tradplusad
  • Yandex

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

  • AdAction
  • Adamobi
  • Adjoe
  • Adonco
  • Adshow
  • Apprainbow
  • Aura
  • 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
  • Trademob
  • Truemoney
  • Unity Ads
  • Yandex
  • Yeahmobi
  • Z2A Digital
  • Zoyo

FAQ

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. 

      selecting_monetized_events.png

    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.

      revenue_sum_up.png

    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'utilisateur 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és et limitations des revenus publicitaires
Particularité Remarques 
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.
Limites

Les événements de revenus publicitaires ne sont pas disponibles pour :

  • Postbacks d'événements d'app 
  • API push
  • Tableau de bord de retargeting

Limitations de granularité au niveau de l'utilisateur :
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.

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
 Niveau utilisateur avec géo

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 utilisateur avec geo
  • Niveau impression (via le SDK)

Appodeal
  • Clé d'application
  • Clé API
  • ID utilisateur
  • Niveau agrégé avec géo
  • Niveau utilisateur
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
Facebook
  • Connexion à Facebook
 Niveau agrégé avec géo
Fyber
  • Code secret client
  • ID D'API
  • ID du client
  • Niveau utilisateur avec geo
  • 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 utilisateur
  • 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
 Niveau utilisateur avec géo

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

Niveau utilisateur avec géo

Médiation Tradplus
  • Clé API
  • ID de l'app réseau

Niveau utilisateur avec géo

 

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)