Prise en charge des enchères multivendeurs avec l'API Protected Audience

Les plates-formes publicitaires côté vente diversifient généralement leurs sources de demande d'annonces afin d'optimiser les revenus publicitaires. Avec la médiation publicitaire, un réseau ou service publicitaire appelle plusieurs réseaux publicitaires pour déterminer la meilleure annonce pour un espace publicitaire donné. Cette proposition explique comment l'API Protected Audience sur Android peut être étendue pour implémenter une fonctionnalité de médiation en cascade tout en préservant la confidentialité. Aujourd'hui, les réseaux publicitaires offrent aux développeurs d'applications différents moyens d'arbitrer les enchères publicitaires à partir de plusieurs vendeurs publicitaires :

1. Médiation en cascade : les développeurs d'applications définissent une liste numérotée de réseaux publicitaires, souvent classés en fonction de l'eCPM historique pour le réseau donné. Cette liste est appelée chaîne de médiation. La plate-forme de médiation du développeur de l'application utilise cette liste pour appeler les réseaux publicitaires dans l'ordre dans lequel ils apparaissent afin de déterminer les sources de demande d'annonces pertinentes.
2. Médiation programmatique : le développeur d'application configure plusieurs réseaux publicitaires pour prendre part aux enchères sur les opportunités d'annonces. Ces réseaux sont autorisés à enchérir en temps réel en fonction de la valeur de l'opportunité.
3. Médiation hybride : combinaison des techniques de cascade d'annonces et de médiation programmatique.

Médiation en cascade

Dans la médiation en cascade, lorsqu'une opportunité publicitaire se présente, un SDK publicitaire envoie une demande à son serveur backend. Au lieu de répondre à la demande avec une création d'annonces gagnantes, le serveur répond avec une chaîne de médiation contenant une liste de réseaux publicitaires classés en fonction de l'historique de l'eCPM.

Figure 1 : modèle de médiation en cascade

Dans le modèle traditionnel de médiation en cascade, un SDK publicitaire appelle chaque réseau publicitaire (ou son propre SDK d'enchères) dans l'ordre spécifié par la chaîne de médiation. Si un réseau publicitaire peut répondre à la demande d'annonce, il affiche l'annonce. Sinon, la requête est envoyée au prochain réseau de la chaîne. Ce processus est répété jusqu'à ce que la requête soit traitée ou que la chaîne soit épuisée.

La médiation en cascade est souvent optimisée en réorganisant régulièrement la chaîne de médiation en fonction de la réévaluation de l'eCPM à partir des sources de demande d'annonce propriétaires.

Médiation programmatique

La médiation programmatique (également appelée "enchères d'en-tête" (header bidding)) constitue une alternative à l'utilisation de l'eCPM historique pour déterminer quel réseau publicitaire peut diffuser une demande d'annonce. Avec la médiation programmatique, les fournisseurs utilisent les valeurs d'enchères en temps réel pour identifier l'annonce gagnante.

Figure 2 : modèle de médiation programmatique.

Médiation hybride

Certaines solutions de médiation programmatique combinent des réseaux publicitaires en un mode hybride de cascade d'annonces et d'enchères pour fournir plus de contrôle sur l'annonce tout en profitant de l'avantage d'utiliser des eCPM en direct pour maximiser les revenus des réseaux publicitaires participants.

Dans les modèles de médiation hybride, les réseaux publicitaires et les fournisseurs de médiation peuvent offrir une plus grande flexibilité aux développeurs d'applications en combinant des éléments de cascade d'annonces et des enchères en temps réel. Les modèles hybrides permettent aux développeurs d'applications de configurer des réseaux publicitaires en fonction des eCPM historiques. Ils peuvent ainsi diffuser une annonce avant d'exécuter des enchères en temps réel sur les réseaux participants pour remplir les opportunités d'annonces.

Médiation en cascade avec l'API Protected Audience

L'API Protected Audience sur Android prend en charge la médiation en cascade en disposant de plusieurs enchères, chacune pour un nœud individuel dans le graphique de médiation. S'il n'y a pas de mise en concurrence, le prochain nœud de mise aux enchères du réseau est appelé jusqu'à ce que la chaîne soit épuisée. Le processus de médiation en cascade se déroule comme suit :

1. Le SDK de médiation récupère la chaîne de médiation à partir du point de terminaison de l'ad server contextuel, qui peut renvoyer des annonces contextuelles ou des chaînes de médiation.
2. Si le point de terminaison de l'ad server renvoie une chaîne de médiation, le SDK de médiation parcourt chaque élément de la chaîne dans l'ordre, en appelant le SDK du réseau publicitaire participant pour qu'il sélectionne une annonce contextuelle et une annonce de remarketing. Chaque élément de la chaîne représente une requête de réseau publicitaire pour l'achat d'espace publicitaire à un prix spécifique pour un nombre spécifique d'impressions, de clics ou pour une durée d'annonce déterminée.
3. Si aucun élément de campagne de la chaîne ne sélectionne une annonce gagnante, le SDK de médiation peut diffuser une annonce de son propre réseau publicitaire en exécutant une sélection d'annonces de l'API Protected Audience, qui prend en compte les annonces de remarketing et contextuelles.

Figure 3 : Médiation en cascade avec l'API Protected Audience

Le diagramme précédent représente un exemple d'algorithme de médiation en cascade qu'un SDK de médiation peut implémenter, mais sans que le réseau publicitaire propriétaire ne puisse l'optimiser. L'API Protected Audience prend en charge l'optimisation des réseaux publicitaires propriétaires en autorisant l'enchaînement de workflows de sélection des annonces et en créant des rapports sur les impressions gagnantes.

Résultat AdSelection

Le type renvoyé pour selectAds() est un objet AdSelectionOutcome. AdSelectionOutcome contient l'URI de rendu de l'annonce gagnante et une AdSelectionId, qui est un entier opaque identifiant le gagnant la création de l'élément de campagne.

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

AdSelectionId agit comme un pointeur vers AdSelectionOutcome. Aujourd'hui, AdSelectionId est transmis à la méthode reportResult() en tant que paramètre ReportImpressionInput pour faciliter l'identification des annonces correctes à partir desquelles les méthodes reportWin() et reportResult() sont appelées.

Proposition de sélection des annonces en chaîne

Nous proposons de surcharger selectAds() avec AdSelectionFromOutcomesConfig.

val config = AdSelectionFromOutcomesConfig.Builder()
        .setSeller(seller)
        .setAdSelectionIds(listOf(outcome1pAdSelectionId))
        .setSelectionSignals({"bid_floor": bidFloorOfNextNetworkInline})
        .setSelectionLogicUri(selectionLogicUri)
        .build()
adSelectionClient.selectAds(config)

Cela permet au SDK de médiation de comparer l'enchère de son annonce gagnante au plancher d'enchères du réseau suivant.

Exemple 1 :

Exemple 2 :

Rapporter les impressions gagnantes

S'il y a une annonce gagnante dans selectAds(AdSelectionFromOutcomes), cette annonce remporte la médiation. Ensuite, reportImpression est appelé avec l'ID de sélection de l'annonce gagnante depuis selectAds(AdSelectionFromOutcomes) et l'AdSelectionConfig correspondante.

Si l'annonce gagnante est renvoyée depuis selectAds(AdSelectionConfig) pour l'un des réseaux, reportImpression est appelé avec l'ID de sélection d'annonces et la configuration de cet appel.

Exécuter une médiation en cascade

Voici l'ordre des opérations à exécuter lors du processus de médiation en cascade.

1. Lancez une sélection d'annonces propriétaires.
2. Itérez la chaîne de médiation. Pour chaque réseau tiers, procédez comme suit :
   1. Créez AdSelectionFromOutcomeConfig, y compris le outcomeId propriétaire et le plancher d'enchères du SDK tiers.
   2. Appelez selectAds() avec la config de l'étape précédente.
   3. Si le résultat n'est pas vide, renvoyez l'annonce.
   4. Appelez la méthode selectAds() de l'adaptateur réseau actuel du SDK. Si le résultat n'est pas vide, renvoyez l'annonce.
3. Si aucun gagnant n'apparaît dans la chaîne, renvoyez l'annonce propriétaire.

Bonnes pratiques

Effectuer des enchères contextuelles avant l'optimisation propriétaire

La demande de remarketing peut engendrer des enchères élevées qui peuvent générer des résultats gagnants dans une chaîne de médiation. La troncation est le processus souvent utilisé pour optimiser les données propriétaires en affinant la liste d'audience de remarketing.

La demande de remarketing de l'API Protected Audience n'est disponible que côté client avec les enchères Protected Audience. Il peut donc être difficile d'activer l'optimisation propriétaire côté serveur. Pour limiter les problèmes liés à l'optimisation propriétaire, commencez par exécuter les enchères contextuelles, puis effectuez l'optimisation propriétaire en fonction du résultat de la mise aux enchères, comme décrit précédemment sur cette page.

Limiter la taille de vos chaînes de médiation sur l'appareil

Pour des performances optimales, les chaînes de médiation sur l'appareil doivent rester petites. Le coût de calcul pour l'exécution sur l'appareil peut être linéaire pour le nombre d'enchères évaluées dans le cadre de la chaîne de médiation. En d'autres termes, plus de nœuds entraînent des exigences de cycle de calcul plus élevées et une latence accrue. Tenez compte de l'impact de la latence sur les revenus lorsque vous transmettez des nœuds à l'évaluation de la médiation sur l'appareil.

Facteurs supplémentaires

L'API Protected Audience n'offre pas de solution complète pour la médiation de plusieurs espaces publicitaires. Chaque espace publicitaire doit être traité indépendamment.

L'API Protected Audience Mediation est compatible avec la médiation en cascade et la médiation programmatique limitée. Nous vous communiquerons bientôt plus d'informations sur la prise en charge d'autres cas d'utilisation de la médiation programmatique.

Étant donné que la sélection d'annonces Protected Audience s'exécute après la récupération des annonces contextuelles, appeler l'API Protected Audience peut avoir un impact sur la latence de bout en bout des demandes d'annonces.