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 :
- 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.
- 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é.
- 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 :
- 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.
- 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.
- 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 un AdSelectionId, un entier opaque qui identifie la création de l'élément de campagne gagnant.
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 d'étendre selectAds() pour prendre en compte les résultats des précédentes exécutions de sélection d'annonces afin de sélectionner une annonce gagnante à l'aide de l'objet AdSelectionOutcome.
Cela permet aux réseaux publicitaires d'exécuter une médiation qui prend en compte les annonces contextuelles et les annonces de remarketing de plusieurs réseaux publicitaires.
ChainedAdSelections est ajouté en tant que paramètre facultatif à AdSelectionConfig.
ChainedAdSelections. Il peut contenir une liste des résultats de la sélection d'annonces provenant d'appels précédents de la méthode selectAds() dans la chaîne de médiation. Dans l'exemple suivant, un SDK exécute AdSelection à l'aide des résultats des SDK A et B de l'appareil. Les SDK A et B partagent tous deux explicitement l'AdSelectionOutcome à partir de leurs appels selectAds() respectifs au SDK qui exécute la sélection d'annonces enchaînées.
AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
Seller = "example-ssp1.com",
DecisionLogicURL = Uri.parse("https://..."),
CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","example-dsp2.com"),
AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
PerBuyerSignals = "{"example-dsp1.com": {"key1" : "value1"},
"example-dsp2.com": {"key1" : "value1", "key2" : "value2"}"
ChainedAdSelections = {network_a_selection_outcome, network_b_selection_outcome}
};
// Invoke ad services API to initiate ad selection workflow.
AdSelectionOutcome winningAd = selectAds(myAdSelectionConfig);
Figure 4 : sélection d'annonces en chaîne avec selectAds()
Notez que la valeur renvoyée par cet appel selectAds() est un autre objet AdSelectionOutcome.
- Une valeur
nullest renvoyée si aucune annonce n'est sélectionnée. - Un nouvel objet
AdSelectionOutcomeest renvoyé si l'une des annonces désignées parChainedAdSelectionsn'est pas l'annonce gagnante. - L'un des résultats transmis dans
AdSelectionest renvoyé s'il s'agit de l'annonce sélectionnée.
Rapporter les impressions gagnantes
En l'absence de gagnant lors de la sélection d'annonces en chaîne, aucune impression gagnante ne doit être rapportée.
Si l'un des objets AdSelectionOutcome transmis dans AdSelectionConfig est sélectionné, le SDK qui exécute la sélection d'annonces en chaîne doit communiquer avec le SDK publicitaire gagnant au sujet du résultat. Le SDK publicitaire gagnant peut ensuite appeler le rapport sur les impressions gagnantes comme il le ferait après avoir exécuté sa propre AdSelection. Cela garantit que le JavaScript de la décision du SDK de l'annonce gagnante est utilisé pour rapporter le résultat. Dans ce scénario, le SDK qui exécute la sélection d'annonces en chaîne peut indiquer quel SDK publicitaire a remporté l'impression.
Si aucun des résultats AdSelectionOutcome n'est sélectionné, le SDK qui exécute la sélection d'annonces en chaîne appelle son rapport sur les impressions gagnantes.
Exécuter une médiation en cascade
Comme il est possible de lier des instances d'AdSelectionOutcome, comme décrit précédemment sur cette page, un SDK de médiation peut exécuter une médiation en cascade, tout en permettant à un réseau publicitaire propriétaire de l'optimiser. Ce processus est résumé ci-dessous :
- Le SDK de médiation obtient une chaîne de médiation auprès du serveur de médiation à l'aide d'une demande d'annonce contextuelle.
- Le SDK de médiation exécute une sélection d'annonces qui prend en compte à la fois les annonces de remarketing et les annonces contextuelles.
Le SDK de médiation exécute un système d'enchères qui tient compte du résultat de la sélection d'annonces propriétaires et de l'eCPM historique du premier élément éligible de la chaîne de médiation.
Si une annonce est sélectionnée, l'annonce qui l'emporte est déterminée et le processus se termine.
Si aucune annonce n'est sélectionnée, le SDK de médiation sélectionne le premier élément éligible de la chaîne de médiation, puis appelle le SDK correspondant pour exécuter une sélection d'annonces contextuelle et de remarketing.
Si une annonce est sélectionnée, elle s'affiche et le processus se termine.
Si aucune annonce n'est sélectionnée, alors l'élément suivant de la chaîne est pris en compte, et l'étape 3 est exécutée.
S'il n'y a plus d'éléments dans la chaîne, le SDK de médiation diffuse une annonce propriétaire en exécutant la sélection d'annonces Protected Audience qui prend à la fois en compte les annonces de remarketing et les annonces contextuelles, comme lors de l'étape 2.
Figure 5 : Processus de médiation en cascade avec l'API Protected Audience.
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
Cette proposition de médiation Protected Audience est en cours de développement. Vos commentaires sont les bienvenus.
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.
Recommandations personnalisées
- Remarque : Le texte du lien s'affiche lorsque JavaScript est désactivé
- Guide du développeur de l'API Protected Audience sur Android
- Permettre le ciblage d'audience personnalisée avec l'API Protected Audience
- API Protected Audience : guide d'intégration