En bref : AppsFlyer fournit aux partenaires UA des données détaillées sur les publicités, achats in-app et abonnements auto-renouvelables via des rapports et postbacks. Les partenaires peuvent utiliser ces informations pour optimiser les campagnes UA.
Introduction
AppsFlyer reçoit des informations sur les revenus à la fois de ses partenaires et des app stores (Apple App Store et Google Play Store). Une fois reçues, les données sont traitées via différentes étapes : validation, normalisation, attribution et enrichissement avec des propriétés et dimensions supplémentaires. AppsFlyer peut envoyer les informations au partenaire UA. À l'issue du processus, AppsFlyer transmet les données enrichies et attribuées au partenaire UA. Le partenaire UA peut alors utiliser ces éléments pour optimiser ses campagnes UA et améliorer le service qu'il propose aux annonceurs.
Quels sont les types de revenus transmis aux partenaires ?
Les applications créent deux types de revenus :
- Revenus publicitaires : les revenus publicitaires sont générés chaque fois qu'une publicité s'affiche dans l'application, comme une bannière, publicité interstitielle ou autre format publicitaire. Ils peuvent être calculés quelle que soit la méthode de campagne facturée à un annonceur.
- Achat in-app et abonnement à renouvellement automatique : les revenus du store sont générés chaque fois qu'un achat in-app ou une transaction liée à un abonnement a lieu.
Comment AppsFlyer fournit les infos liées aux revenus aux partenaires UA ?
AppsFlyer fournit à ses partenaires des infos sur les publicités in-app, les achats in-app et les revenus d'abonnement par les moyens suivants :
- Rapport sur les infos UA des revenus publicitaires (Revenue UA Signals) : ce rapport contient les événements liés aux revenus publicitaires agrégés au niveau de l'appareil. Le rapport est disponible quotidiennement dans Data Locker, il contient les données de la veille.
- Postbacks de revenus publicitaires : chaque fois qu'une impression publicitaire a lieu sur l'appareil d'un client, un postback est envoyé par AppsFlyer au partenaire, avec les détails de l'événement de revenu publicitaire.
- Postbacks de revenus du store : chaque fois qu'un achat ou un abonnement a lieu, un postback est envoyé par AppsFlyer au partenaire, avec les détails de l'événement de revenu.
Mettre en place ROI360 pour les partenaires
Quelles actions doivent effectuer les partenaires pour recevoir le rapport sur les infos UA et les postbacks de revenus du store ?
Abonnement au rapport ROI360 UA Signals
Pour permettre au partenaire d'obtenir le rapport via Data Locker :
- Le partenaire doit compléter les étapes suivantes dans Data Locker :
- Configurer Data Locker dans le compte du partenaire, ce qui inclut la connexion au fournisseur de services sur le cloud, ainsi que le format et le contenu des rapports.
- Activer le rapport ROI360 UA Signals.
- L'annonceur doit donner au partenaire l'autorisation de publier le rapport.
Recevoir les postbacks ROI360 envoyés par AppsFlyer
Pour recevoir les postbacks AppsFlyer, les partenaires doivent contacter l'équipe intégration des partenaires AppsFlyer. Par la suite, l'équipe configurera les valeurs de postback du revenu in-app du ROI au sein de la plateforme AppsFlyer.
Pour contacter l'assistance des partenaires AppsFlyer, ouvrez le menu Assistance de votre tableau de bord et sélectionnez Contacter notre équipe.
Rapport ROI360 UA Signals pour les réseaux UA
Le rapport envoie quotidiennement des données CSV/parquet détaillées sur les revenus au jour x+1 au compartiment S3 du partenaire UA.Chaque enregistrement est une agrégation des événements de revenus publicitaires au niveau de l'appareil.
Le rapport UA Signals ne fournit pas de données en temps réel comme le font les rapports sur les revenus publicitaires. Cependant, il est plus précis et plus complet. En effet, la valeur d'une impression peut varier dans le temps. Cela est particulièrement vrai lorsque les données de revenus au niveau de l'impression concernent une impression publicitaire qui a été vendue via une enchère CPM standard, et non une enchère en temps réel.
Quelles sont les sources de données du rapport ?
Selon le type d'intégration de l'annonceur, les données du rapport peuvent provenir de l'une des sources suivantes :
- Intégration des connecteurs SDK AdRevenue : les clients peuvent partager les données de revenus de niveau impression chargées par le partenaire sur les appareils clients, qui sont ensuite transmises à AppsFlyer en temps quasi réel.
- Intégrations de niveau appareil basées sur API S2S : les clients peuvent configurer leurs identifiants partenaires dans l'interface utilisateur AppsFlyer (section partenaires intégrés) et permettre à ROI360 ad revenue de collecter les données de revenus publicitaires de niveau appareil en leur nom.
- Un ensemble des deux (actualisation et précision).
Remarque : le transfert des données entre l'annonceur et AppsFlyer dépend des autorisations de l'annonceur et du fait que l'annonceur est un client avancé de ROI360 ou non.
Comment sont traitées les données du rapport ?
AppsFlyer ROI360 Ad Revenue effectue les opérations suivantes :
- Normalisation des données
- Attribution de la source média d'installation et enrichissement des données
- Génération des événements de revenus publicitaires
- Les événements sont agrégés au niveau de l'appareil
Comment les données du rapport sont-elles transmises ?
Les données de niveau appareil sont inscrites quotidiennement dans le rapport de Data Locker.
Comment sont actualisées les données du rapport ?
Les données sont inscrites quotidiennement dans le dossier h=23 de votre compartiment Data Locker à 21:00 UTC.
Quels champs contient le rapport ?
| Champ | Remarques |
|---|---|
| Version | Horodatage Unix en secondes. Exemple : 1661315124 |
| app_id | ID de l'app sur la plateforme AppsFlyer |
| install_time | - Horodatage de l'installation : AAAA-MM-JJ HH:MM:SS Exemple : 2020-08-16 11:22:33 - Pour les appareils iOS 14+ et les utilisateurs qui n'ont ps donné leur consentement, ou si l'annonceur a activé la fonction Confidentialité avancée, l'heure de l'installation est arrondie à l'heure la plus proche. |
| campaign, campaign_id, adset_name, adset_id, ad_name, ad_name, ad_id, site_id | Uniquement renseigné si l'UA est attribuée au partenaire qui reçoit les données. |
| idfa, idfv, advertising_id | • Le même ID d'appareil, comme IDFA, IDFV ou advertiser_id, peut s'afficher sur plusieurs lignes s'il y a plusieurs événements de monétisation des revenus publicitaires. • Pour les appareils iOS 14+ et les utilisateurs non consentants, ou si l'annonceur a activé la fonction Confidentialité avancée, ce message ne s'affiche pas. |
| platform | Plate-forme de l'appareil : iOS, Android ou Windows Mobile |
| country | Code pays utilisant la norme ISO 3166 (alpha-2) Exemple : US, CN. |
| original_url | • Pour les appareils iOS 14+ et les utilisateurs non consentants, ou si l'annonceur a activé la fonction Confidentialité avancée, ce message ne s'affiche pas.• Renseigné uniquement si l'UA est attribuée au partenaire qui reçoit les données. |
| mediation_network | Le réseau de médiation associé à l'impression ou aux impressions. Voir la liste des réseaux possibles |
| ad_unit | Disponible au troisième trimestre 2023 : le ad_unit de monétisation associé à l'impression ou aux impressions |
| placement | Disponible au troisième trimestre 2023 : le placement de monétisation associé à l'impression ou aux impressions |
Télécharger l'exemple de données de rapport
Postbacks de revenus publicitaires in-app (IAA)
Les postbacks IAA représentent la deuxième méthode utilisée par AppsFlyer pour envoyer des informations sur les revenus à ses partenaires. Leur principal avantage comparé aux rapports Ad Revenue Signals UA est leur degré d'actualisation, en effet les postbacks offrent un partage des données sur les revenus des AAI en temps quasi réel. Cela contraste avec l'actualisation X+1 (un jour après la date de l'événement) offerte par les rapports ad revenue UA signals.
Cependant, l'actualisation en temps réel est moins précise qu'avec X+1 :
- Les données en temps réel des postbacks IAA sont en moyenne moins précises de ±5 % que les données du rapport X+1 des UA Signals.
- Les données en temps réel des postbacks IAA sont en moyenne moins détaillées de ±7 % comparées aux données du rapport X+1 des UA Signals.
Quelles sont les sources de données des postback IAA?
Les données des postbacks IAA proviennent des données de niveau impression que les partenaires chargent sur les appareils des clients. Ces données sont ensuite partagées avec AppsFlyer par le biais du connecteur ROI360 Ad Revenue SDK, qui est installé sur l'appareil par l'annonceur. Le connecteur permet au développeur de l'app de signaler un événement d'impression qui comprend certains paramètres, comme l'ILRD, la devise, la plateforme de médiation et la source de monétisation.
Le transfert des données entre les appareils du client annonceur et AppsFlyer dépend des autorisations de l'annonceur et du fait que l'annonceur est un client avancé de ROI360 ou non.
Comment sont traitées les données des postbacks IAA ?
AppsFlyer ROI360 suit les étapes ci-dessous pour chaque donnée reçue au niveau de l'impression :
- Normalisation des données.
- Attribution de la source média d'installation et enrichissement des données.
- Génération d'un événement af_ad_revenue.
Comment les données du postback sont-elles transmises ?
L'événement est envoyé au partenaire via la configuration de postback définie entre le partenaire et AppsFlyer par le biais d'un paramètre supplémentaire.
Postbacks des achats in-app (IAP)
Les postbacks ROI360 des achats in-app offrent différents niveaux d'informations en validant d'abord chaque transaction, en supprimant les doublons, puis en déduisant les frais du store et la taxe commerciale.
Quelles sont les sources de données des postback IAA?
Les données des postbacks IAP proviennent :
- Des données de niveau transaction lues par le connecteur ROI360 Purchase SDK à chaque fois qu'un achat in-app ou un abonnement auto-renouvelable se produit sur l'appareil.
- Toutes les notifications entrantes du serveur App Store et Google Play (RTDN) sont traitées par le même processus que celui des achats et revenus d'abonnement d'AppsFlyer.
- Les notifications concernant les transactions déjà rapportées par le connecteur SDK sont validées et traitées.
- Les notifications concernant des transactions inconnues ne sont pas indiquées dans AppsFlyer.
Remarque : le transfert des données entre l'annonceur et AppsFlyer dépend des autorisations de l'annonceur et du fait que l'annonceur est un client avancé de ROI360 ou non.
Comment sont traitées les données des postbacks IAP ?
AppsFlyer ROI360 suit les étapes ci-dessous pour chaque donnée reçue au niveau de la transaction :
- AppsFlyer valide l'achat ou l'abonnement auprès du store concerné pour confirmer qu'il n'est pas frauduleux.
- Lorsque la vérification est validée, AppsFlyer enregistre l'achat ou l'abonnement.
- Si la vérification échoue, l'événement s'affiche dans le rapport de données brutes des événements in-app bloqués (option disponible pour les abonnés Protect360).
- AppsFlyer veille à ce que les transactions ne soient pas dupliquées, y compris celles liées au partage familial sur iOS.
- AppsFlyer calcule les données de revenu net en tenant compte des frais du store et des taxes(Revenu réel).
- AppsFlyer génère un achat en interne ou un événement de cycle de vie pour la transaction validée et traitée.
Comment est transmis le postback ?
L'événement IAP est envoyé au partenaire via une intégration de postbacks définie entre le partenaire et AppsFlyer.
Quels sont les événements IAP ?
Les clients ROI360 peuvent partager les noms d'événements générateurs de revenus suivants :
Noms d'événement
| Nom de l'événement | Description |
|---|---|
| af_purchase | Enregistré lorsqu'un utilisateur effectue un achat |
| af_purchase_refund | Enregistré lorsqu'un achat est remboursé |
| af_ars_trial_converted | Enregistré lorsqu'un renouvellement au tarif plein commence, après une période d'essai |
| af_ars_subscription_started | Enregistré lorsqu'un abonnement à tarif réduit ou plein commence |
| af_ars_subscription_resumed | Enregistré lorsqu'un abonnement à tarif plein est relancé après un abandon ou une demande de remboursement d'abonnement |
| af_ars_subscription_refunded | Enregistré lorsqu'un abonné perçoit un remboursement |
| af_ars_subscription_renewed | Enregistré lors d'un renouvellement automatique de l'abonnement |
| af_ars_subscription_xgraded | Enregistré lorsqu'un abonné passe à un abonnement supérieur ou inférieur, ou qu'il change d'abonnement |