Configuration d'enchères séquentielles avec des enchères d'en-tête et des enchères Protected Audience multivendeurs

En général, les éditeurs diversifient leurs sources de demande d'annonces pour optimiser les revenus et font appel à plusieurs entreprises (par exemple, des ad servers d'éditeurs, des plates-formes côté offre et des plates-formes côté demande) afin de déterminer la meilleure annonce pour un espace publicitaire donné sur la page. Les enchères d'en-tête permettent aux éditeurs de capturer des enchères pour un espace publicitaire à partir de différentes sources de demande. Dans une configuration d'enchères séquentielles, la bibliothèque d'enchères d'en-tête peut être utilisée pour lancer une mise aux enchères avec des données contextuelles et Protected Audience pour une mise aux enchères avec des données intersites.

Avant de commencer, découvrez les principes de base de l'API sur la page Protected Audience et les enchères d'en-tête dans la documentation Prebid.js.

Définitions

Ventes aux enchères

Enchères	Définition
Enchères contextuelles	Enchères publicitaires qui utilisent les données disponibles dans le contexte de l'emplacement de l'enchère. Il peut y avoir plusieurs enchères au sein d'une enchère contextuelle, telles que les enchères d'en-tête et les enchères côté serveur.
Mise aux enchères Protected Audience	Il s'agit d'enchères publicitaires qui impliquent une enchère sur un groupe de centres d'intérêt créé sur un autre site.
Enchères multivendeurs Protected Audience	Mise aux enchères Protected Audience à deux niveaux qui implique d'abord plusieurs enchères de composants parallèles, qui soumettent ensuite l'annonce la mieux notée à la dernière enchère de premier niveau.
Enchère de premier niveau	Enchère publicitaire finale dans le cadre d'une mise aux enchères multivendeur Protected Audience, qui indique le score des gagnants de la mise aux enchères des composants à partir des composants.
Enchères pour composants	Enchère imbriquée dans une enchère multivendeur Protected Audience, où chaque vendeur de composants lance ses enchères de composants en parallèle. Les annonces les mieux notées lors de chaque enchère individuelle sont transmises à l'enchère de premier niveau.
Configuration séquentielle des enchères	Configuration d'enchères publicitaires qui intègre des enchères contextuelles à une enchère Protected Audience et qui détermine l'enchère gagnante entre les deux.

Participants

Participant	Définition
Annonceur	Partie qui souhaite un emplacement d'annonce et qui crée l'annonce.
Diffuseur	Partie qui fournit un inventaire publicitaire pour les enchères.
Revendeur	Partie qui enchérit dans une mise aux enchères pour acheter l'espace publicitaire auprès d'un vendeur. Il s'agit généralement d'une plate-forme côté demande (DSP).
Ad server d'éditeur	Service utilisé par les éditeurs pour gérer et choisir les annonces à diffuser sur leur site. Un serveur publicitaire éditeur peut combiner ses propres résultats d'enchères, les réponses des enchérisseurs d'en-tête, l'inventaire vendu directement, etc. afin de déterminer l'annonce qui générera le plus de revenus pour un éditeur. Un serveur publicitaire éditeur peut fournir une bibliothèque côté client pour interagir avec le serveur.
Marchand de premier niveau	La partie qui appelle (c'est-à-dire qui crée) l'enchère multivendeur Protected Audience et participe à l'enchère de premier niveau.
Vendeur de composants	Partie qui exécute une mise aux enchères de composants dans l'enchère multivendeur Protected Audience pour vendre l'espace publicitaire de l'éditeur aux acheteurs. Il s'agit généralement d'une plate-forme côté offre (SSP).

Configuration séquentielle des enchères

Dans une configuration d'enchères séquentielles, les enchères contextuelles sont exécutées en premier, puis l'enchère Protected Audience est exécutée. Cette configuration permet aux éditeurs de maximiser leurs revenus potentiels en effectuant une mise aux enchères avec les données contextuelles disponibles sur la page, ainsi qu'avec des données intersites dans un environnement sécurisé afin de protéger la confidentialité des utilisateurs.

Une bibliothèque d'enchères d'en-tête peut être exécutée en premier sur la page afin de collecter des enchères pour l'enchère contextuelle de l'ad server de l'éditeur. Ensuite, le prix ajusté de l'enchère gagnante de la mise aux enchères contextuelle peut être inclus dans la mise aux enchères Protected Audience en tant que prix plancher. Au cours de l'étape d'évaluation, le vendeur de premier niveau peut baisser le prix des enchères des composants en dessous du prix plancher de l'enchère en lui attribuant un score de zéro lors du calcul du score de désirabilité. Si aucune enchère du composant Protected Audience n'est supérieure au prix plancher de l'enchère, l'annonce gagnante de l'enchère contextuelle est diffusée auprès de l'utilisateur. Si la mise aux enchères Protected Audience renvoie une annonce gagnante, cela signifie que celle-ci est supérieure au prix plancher et que l'annonce gagnante est diffusée auprès de l'utilisateur.

Remarque:La configuration de ce document décrit une approche potentielle pour intégrer l'API Protected Audience aux mécanismes de diffusion d'annonces existants, mais il ne s'agit pas de la seule méthode. Ce document explique comment Prebid.js, l'une des bibliothèques d'enchères d'en-tête, a été intégrée à Protected Audience.

Dans cet exemple de configuration d'enchères séquentielles, trois enchères principales peuvent être exécutées sur la page dans l'ordre: 1) enchère contextuelle par bibliothèque d'enchères d'en-tête, 2) enchère contextuelle par l'ad server de l'éditeur et 3) enchère Protected Audience.

Présentation de la mise aux enchères multivendeurs Protected Audience avec enchère contextuelle d'en-tête

Description détaillée du diagramme de la vue d'ensemble:

1. Avant l'enchère, l'utilisateur est ajouté à un groupe de centres d'intérêt sur le site d'un annonceur.
2. Lorsque l'utilisateur consulte ultérieurement la page de l'éditeur, Prebid.js lance une enchère contextuelle afin de collecter les réponses à l'enchère des enchérisseurs d'en-tête. Au cours de cette étape, les acheteurs peuvent fournir les signaux, et les vendeurs peuvent fournir des configurations d'enchères de composants à utiliser lors de la mise aux enchères Protected Audience ultérieure. Prebid.js fournit un module permettant de propager ces signaux et configurations au système d'enchères Protected Audience.
3. Les réponses aux enchères collectées par Prebid.js sont envoyées à l'ad server de l'éditeur pour une enchère contextuelle côté serveur.
4. Le serveur publicitaire de l'éditeur peut combiner ses propres résultats d'enchères, les résultats des enchères d'en-tête, l'inventaire vendu directement, etc. afin de déterminer l'annonce qui générera le plus de revenus pour un éditeur. L'annonce gagnante est renvoyée à la bibliothèque côté client du serveur publicitaire de l'éditeur.
5. Le prix ajusté de l'enchère issu du gagnant de l'enchère contextuelle, ainsi que les signaux de l'acheteur (perBuyerSignals) et les configurations des enchères des composants du vendeur rassemblées par Prebid.js, peuvent être intégrés à la mise aux enchères Protected Audience par la bibliothèque côté client de l'ad server de l'éditeur.
6. La mise aux enchères multivendeurs Protected Audience est exécutée par le vendeur de premier niveau. Au cours de l'étape d'évaluation du vendeur de premier niveau, ce dernier peut comparer le prix de l'enchère gagnante pour chaque composant au prix de l'enchère gagnante ajustée en fonction du contexte. Si le prix de l'enchère du composant est inférieur à celui de l'enchère contextuelle, le vendeur de premier niveau renvoie le score de désirabilité de 0. Si toutes les enchères obtiennent un score de 0, l'appel runAdAuction() renvoie null, ce qui signifie que l'annonce gagnante de l'enchère contextuelle doit être diffusée.
7. La bibliothèque côté client de l'ad server de l'éditeur affiche l'annonce Protected Audience ou l'annonce contextuelle gagnante, en fonction de ce qui a été renvoyé par l'appel runAdAuction().
8. L'annonce gagnante est présentée à l'utilisateur.

Avant les enchères

Séquence temporelle d'un groupe de centres d'intérêt sur une page d'annonceur

Avant la mise aux enchères, lorsque l'utilisateur consulte la page d'un annonceur, l'acheteur et l'annonceur peuvent définir le groupe de centres d'intérêt du site auquel appartient l'utilisateur. Ils peuvent également ajouter des données contextuelles provenant du site de l'annonceur, ainsi que des données first party qui serviront de signaux pour la mise aux enchères ultérieurement.

1. L'utilisateur accède au site de l'annonceur.
2. Le site de l'annonceur charge ultérieurement le script de chaque acheteur participant à l'enchère.
3. Le script de l'acheteur contient l'appel joinAdInterestGroup() permettant d'ajouter l'utilisateur au groupe de centres d'intérêt de l'acheteur.

Enchères contextuelles avec Prebid.js et l'ad server de l'éditeur

Séquence contextuelle des enchères sur la page de l'éditeur

Dans une configuration d'enchères séquentielles, toutes les enchères contextuelles sont exécutées avant l'enchère Protected Audience. Dans la configuration décrite dans ce document, nous exécutons une enchère contextuelle d'enchères d'en-tête par Prebid.js qui alimente une enchère côté serveur par l'ad server de l'éditeur.

L'éditeur initie d'abord une enchère contextuelle pour les enchères d'en-tête en appelant Prebid.js avec un indicateur pour indiquer qu'une enchère Protected Audience sera exécutée ensuite. Ensuite, Prebid.js collecte les réponses aux enchères et les envoie à l'ad server de l'éditeur pour une enchère contextuelle côté serveur. Au cours de l'étape de collecte des réponses aux enchères, les acheteurs et les vendeurs ont la possibilité de fournir des configurations d'enchères de composants et des signaux d'acheteurs (perBuyerSignals) à utiliser pour la mise aux enchères Protected Audience suivante, s'ils souhaitent participer. Cette configuration d'enchères des composants finira par être prise en compte dans la mise aux enchères Protected Audience suivante.

1. Initialisation des enchères contextuelles
   L'utilisateur accède à la page de l'éditeur.
2. La page de l'éditeur charge la bibliothèque de l'ad server de l'éditeur côté client et définit les espaces publicitaires.
3. La page de l'éditeur charge le wrapper avant enchère et lance l'enchère contextuelle des enchères d'en-tête.
4. Enchère contextuelle du vendeur A
   (exécutée parallèlement à l'enchère contextuelle du vendeur B)
   Prebid.js envoie une demande d'enchère au vendeur A.
5. Le vendeur A récupère les réponses aux enchères et les perBuyerSignals auprès des acheteurs.
6. Le vendeur A lance une enchère contextuelle.
7. Le vendeur A crée la configuration de la mise aux enchères des composants en incluant perBuyerSignals.
8. Le vendeur A répond à Prebid.js avec l'enchère gagnante et la configuration d'enchère qui lui correspond.
9. Enchère contextuelle du vendeur B
   (exécutée parallèlement à l'enchère contextuelle du vendeur A)
   Prebid.js envoie une demande d'enchère au vendeur B.
10. Le vendeur B récupère les réponses aux enchères et les perBuyerSignals auprès des acheteurs.
11. Le vendeur B lance une enchère contextuelle.
12. Le vendeur B crée la configuration de la mise aux enchères des composants en incluant perBuyerSignals.
13. Le vendeur B répond à Prebid.js avec l'enchère gagnante et la configuration d'enchère qui lui correspond.
14. Enchère contextuelle de l'ad server de l'éditeur
    Les réponses aux enchères collectées par Prebid.js sont envoyées à l'ad server de l'éditeur pour l'enchère contextuelle.
15. Les configurations d'enchères des composants avec les signaux des acheteurs sont partagées avec la bibliothèque côté client de l'ad server de l'éditeur
16. L'ad server de l'éditeur lance une enchère contextuelle pour déterminer la meilleure annonce parmi les campagnes vendues directement, les enchères programmatiques, les enchères contextuelles avant enchère et d'autres inventaires.
17. L'ad server de l'éditeur renvoie l'enchère gagnante ajustée.

Enchères multivendeurs Protected Audience

Séquence des dates des enchères Protected Audience sur la page de l'éditeur

À ce stade, les enchères contextuelles sont terminées, et la bibliothèque côté client de l'ad server de l'éditeur peut transmettre au vendeur de premier niveau le prix de l'enchère ajustée de l'enchère contextuelle gagnante, les configurations des enchères des composants et les signaux des acheteurs participant à l'enchère Protected Audience. Le prix de l'enchère contextuelle en tant que plancher peut être transmis à la configuration de la mise aux enchères afin d'obtenir un score pour l'enchère de premier niveau.

Les enchères des composants sont exécutées en parallèle. Pour chaque composant, le navigateur génère des enchères à partir de la logique d'enchères de chaque acheteur participant à cette mise aux enchères, attribue un score à chaque enchère selon la logique d'évaluation du vendeur de composants, puis renvoie l'annonce la mieux notée à l'enchère de premier niveau.

1. Le site de l'éditeur charge le script du vendeur de premier niveau.
2. La bibliothèque côté client de l'ad server de l'éditeur fournit le prix de l'enchère contextuelle, les configurations des enchères des composants avec des signaux provenant des acheteurs au vendeur de premier niveau. Le prix de l'enchère contextuelle gagnante peut être transmis à la configuration de la mise aux enchères en tant que signaux du vendeur (ce prix de l'enchère devient disponible dans la fonction scoreAd() du vendeur de premier niveau).
3. Le vendeur de premier niveau démarre la mise aux enchères Protected Audience en appelant runAdAuction().
4. Enchères de composants du vendeur A
   (en parallèle à l'enchère de composants du vendeur B)
   Le navigateur lit les groupes de centres d'intérêt de l'utilisateur pour tous les acheteurs participant à la mise aux enchères des composants du vendeur A.
5. Le navigateur extrait les scripts d'enchères et les signaux d'enchères de confiance à partir des zones géographiques spécifiées dans les groupes de centres d'intérêt des acheteurs participant à la mise aux enchères des composants.
6. Le navigateur génère les enchères en exécutant la logique de génération d'enchères de chaque acheteur.
7. Le navigateur récupère le script d'évaluation et les signaux d'évaluation de confiance de chaque annonce auprès du vendeur A.
8. Le navigateur exécute la logique d'évaluation du vendeur A pour chaque enchère.
9. Le navigateur choisit l'annonce ayant obtenu le score le plus élevé selon la logique d'évaluation du vendeur A.
10. Enchères de composants du vendeur B
    (exécution en parallèle de l'enchère du vendeur A)
    Le navigateur lit les groupes de centres d'intérêt de l'utilisateur pour tous les acheteurs participant aux enchères des composants du vendeur B.
11. Le navigateur extrait les scripts d'enchères et les signaux d'enchères de confiance à partir des zones géographiques spécifiées dans les groupes de centres d'intérêt des acheteurs participant à la mise aux enchères des composants.
12. Le navigateur génère les enchères en exécutant la logique de génération d'enchères de chaque acheteur.
13. Le navigateur récupère le script d'évaluation et les signaux d'évaluation de confiance de chaque annonce auprès du vendeur B.
14. Le navigateur exécute la logique d'évaluation du vendeur B pour chaque enchère.
15. Le navigateur choisit l'annonce ayant obtenu le score le plus élevé selon la logique d'évaluation du vendeur B.

Meilleur niveau d'évaluation des enchères et affichage des annonces

Séquence d'affichage des annonces sur la page de l'éditeur

Une fois les enchères de composants de la section précédente exécutées, le navigateur exécute la logique d'évaluation du vendeur de premier niveau sur l'annonce gagnante de chaque enchère de composants. Dans la fonction scoreAd() du vendeur de premier niveau, le prix ajusté de l'enchère contextuelle peut être défini sur sellerSignals. La logique d'évaluation peut comparer ce prix de l'enchère contextuelle au prix de l'enchère gagnante du composant Protected Audience.

Si le prix de l'enchère gagnante lors de la mise aux enchères contextuelle est supérieur à celui de la mise aux enchères des composants, la fonction scoreAd() peut renvoyer un score de désirabilité de 0. S'il n'existe aucune annonce dont le score de désirabilité est supérieur à 0, cela signifie que l'annonce gagnante de l'enchère contextuelle a plus de valeur que n'importe quelle annonce gagnante lors de la mise aux enchères des composants, et la fonction runAdAuction() renvoie null.

Si la mise aux enchères Protected Audience n'a pas d'enchère gagnante et qu'elle renvoie null, la bibliothèque côté client de l'ad server de l'éditeur peut afficher l'enchère contextuelle gagnante dans un iFrame. Si la mise aux enchères Protected Audience l'emporte sur l'enchère contextuelle et renvoie un objet FencedFrameConfig ou un URN opaque, l'annonce participant aux enchères Protected Audience gagnante peut être affichée dans un frame cloisonné ou un iFrame.

1. Évaluation de premier niveau des annonces participant aux enchères
   Le navigateur récupère le script d'évaluation auprès du vendeur de premier niveau, ainsi que des signaux d'évaluation de confiance pour chaque annonce.
2. Le navigateur exécute la logique d'évaluation du vendeur de premier niveau pour chaque enchère gagnante dans l'ensemble des enchères individuelles. Dans le script scoreAd() du vendeur de premier niveau, la logique a accès au prix de l'enchère gagnante ajustée en contexte qui peut avoir été transmis en tant que sellerSignals dans la configuration de l'enchère. Le script peut comparer le prix de l'enchère contextuelle gagnante au prix de l'enchère du composant Protected Audience et renvoyer un score de désirabilité de 0 si le prix contextuel est plus élevé. Sinon, le script calcule le score de désirabilité, probablement à partir du prix de l'enchère du composant Protected Audience.
3. Le navigateur choisit l'annonce associée au score de désirabilité le plus élevé, selon la logique d'évaluation du vendeur de premier niveau.
4. Si la mise aux enchères Protected Audience l'emporte
   La mise aux enchères Protected Audience renvoie un objet FencedFrameConfig ou un URN opaque à la bibliothèque côté client de l'ad server de l'éditeur.
5. La bibliothèque côté client définit l'attribut config du cadre cloisonné sur l'objet FencedFrameConfig ou l'attribut src de l'iFrame sur l'URI opaque de l'annonce Protected Audience gagnante.
6. Le navigateur récupère auprès de l'acheteur l'annonce gagnante de l'enchère Protected Audience.
7. Le navigateur affiche l'annonce à l'utilisateur.
8. Si l'enchère contextuelle l'emporte
   La mise aux enchères Protected Audience renvoie null.
9. Le navigateur définit l'attribut src du cadre iFrame sur l'annonce contextuelle gagnante.
10. Le navigateur récupère auprès de l'acheteur l'annonce qui remporte l'enchère contextuelle.
11. Le navigateur affiche l'annonce à l'utilisateur.

Interagir et donner votre avis

Étape suivante

Nous souhaitons discuter avec vous d'une API adaptée à tous les utilisateurs.

Discuter de l'API

Comme d'autres API de la Privacy Sandbox, cette API est documentée et consultée publiquement.

Tester l'API

Vous pouvez tester l'API Protected Audience et y participer.