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

Les éditeurs diversifient généralement leurs sources de demande d'annonces afin d'optimiser leurs revenus et appellent plusieurs entreprises (par exemple, les serveurs publicitaires des éditeurs, les plates-formes côté offre et les plates-formes côté demande) pour déterminer la meilleure annonce pour un espace publicitaire donné sur la page. Les enchères d'en-tête permettent aux éditeurs de collecter des enchères pour un emplacement publicitaire auprès de diverses sources de demande. Dans une configuration d'enchères séquentielles, la bibliothèque d'enchères par en-tête peut être utilisée pour lancer une mise aux enchères avec des données contextuelles, et l'API Protected Audience pour lancer 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 sur le bidding par en-tête dans la documentation Prebid.js.

Définitions

Enchères

Enchères	Définition
Enchères contextuelles	Enchère sur les annonces qui utilise les données disponibles dans le contexte de l'exécution de l'enchère. Il peut y avoir plusieurs enchères dans une enchère contextuelle, comme les enchères par en-tête et les enchères côté serveur.
enchère Protected Audience	Enchère sur une annonce impliquant des enchères sur un groupe de centres d'intérêt créé sur un autre site.
Enchères multivendeurs Protected Audience	Enchères Protected Audience à deux niveaux qui impliquent d'abord plusieurs enchères de composants parallèles, qui soumettent ensuite leur annonce la mieux notée à l'enchère de niveau supérieur finale.
Enchères de premier niveau	Enchère publicitaire finale dans une mise aux enchères multivendeur Protected Audience qui fournit le score des gagnants des enchères de composants.
Enchères de composants	Enchère imbriquée dans une mise aux enchères multivendeur Protected Audience, où chaque vendeur de composants exécute ses enchères de composants en parallèle. Les annonces les plus performantes de chaque mise aux enchères de composant sont transmises à la mise aux enchères de premier niveau.
Configuration des enchères séquentielles	Configuration d'enchères publicitaires qui intègre les enchères contextuelles à une enchère Protected Audience et détermine un gagnant entre les deux enchères.

Participants

Participant	Définition
Annonceur	Personne qui souhaite diffuser une annonce et qui crée la création publicitaire.
Éditeur	Partie qui fournit l'inventaire publicitaire aux enchères.
Revendeur	Partie qui définit une enchère 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 à afficher sur le site. Un serveur publicitaire d'é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., pour déterminer l'annonce qui générera le plus de revenus pour un éditeur. Un ad server d'éditeur peut fournir une bibliothèque côté client pour interagir avec le serveur.
Vendeur de premier niveau	Partie qui appelle (c'est-à-dire crée) les enchères multivendeurs Protected Audience et participe aux enchères de niveau supérieur.
Vendeur du composant	Partie qui exécute une mise aux enchères de composants dans la mise aux enchères 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 des enchères séquentielles

Dans une configuration d'enchères séquentielles, les enchères contextuelles sont exécutées en premier, puis l'enchère Protected Audience. Cette configuration permet aux éditeurs de maximiser leur potentiel de revenus en exécutant une mise aux enchères avec les données contextuelles disponibles sur la page, et en exécutant également une mise aux enchères 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 pour collecter les enchères pour les enchères contextuelles du serveur publicitaire de l'éditeur. Vous pouvez ensuite saisir le prix de l'enchère gagnante ajustée de l'enchère contextuelle dans l'enchère Protected Audience en tant que prix plancher. Lors de l'étape d'attribution des scores, le vendeur de premier niveau peut baisser le prix des enchères des composants en dessous du prix plancher en leur attribuant un score nul lorsque le score de désirabilité est calculé. Si aucune enchère d'enchères de composants Protected Audience n'est supérieure au prix plancher, l'annonce gagnante de l'enchère contextuelle est diffusée auprès de l'utilisateur. Si l'enchère Protected Audience renvoie un gagnant, cela signifie qu'elle est supérieure au prix plancher, et l'annonce gagnante Protected Audience est diffusée auprès de l'utilisateur.

Remarque:La configuration décrite dans ce document décrit une approche possible pour intégrer Protected Audience aux mécanismes de diffusion d'annonces existants, mais ce n'est pas la seule. Ce document explique comment l'une des bibliothèques d'enchères par en-tête, Prebid.js, 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 suivant: 1) enchères contextuelles par la bibliothèque d'enchères par en-tête, 2) enchères contextuelles par l'ad server de l'éditeur et 3) enchères Protected Audience.

Présentation des enchères multivendeurs Protected Audience avec enchères contextuelles header bidding.

Description détaillée du schéma de présentation:

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 accède à la page de l'éditeur ultérieurement, Prebid.js exécute une mise aux enchères contextuelle pour collecter les réponses aux enchères 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 dans l'enchère Protected Audience suivante. Prebid.js fournit un module permettant de propager ces signaux et configurations aux 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 mise aux enchères 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., pour 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 de l'ad server de l'éditeur.
5. Le prix d'enchère ajusté du gagnant de l'enchère contextuelle, ainsi que les signaux de l'acheteur (perBuyerSignals) et les configurations d'enchères des composants du vendeur collectées par Prebid.js peuvent être transmis à l'enchère Protected Audience par la bibliothèque côté client de l'ad server de l'éditeur.
6. La mise aux enchères multivendeur Protected Audience est exécutée par le vendeur de premier niveau. Lors de l'étape d'attribution des scores au vendeur de premier niveau, celui-ci peut comparer le prix de l'enchère gagnante de chaque composant aux enchères au prix ajusté de l'enchère contextuelle. Si le prix de l'enchère du composant est inférieur au prix de l'enchère contextuelle, le vendeur de premier niveau renvoie le score de désirabilité 0. Si toutes les enchères sont évaluées à 0, l'appel runAdAuction() renvoie null, ce qui signifie que l'annonce gagnante de l'enchère contextuelle doit être affiché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 s'affiche auprès de l'utilisateur.

Avant la mise aux enchères

Séquence temporelle des groupes de centres d'intérêt sur la page d'un annonceur.

Avant l'enchère, lorsque l'utilisateur consulte la page d'un annonceur, l'acheteur et l'annonceur peuvent définir le groupe d'intérêt du site auquel l'utilisateur appartient, et ajouter des données contextuelles provenant du site de l'annonceur et des données first party à utiliser comme signaux pour l'enchère plus tard.

1. L'utilisateur accède au site de l'annonceur.
2. Le site de l'annonceur charge le script de chaque acheteur participant à la mise aux enchères à un stade ultérieur.
3. Le script de l'acheteur contient l'appel joinAdInterestGroup() pour 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 temporelle des enchères contextuelles 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'exécution de l'enchère Protected Audience. Dans la configuration décrite dans ce document, nous exécutons une mise aux enchères contextuelles par Prebid.js dans le cadre des enchères d'en-tête, qui alimente une mise aux enchères côté serveur par l'ad server de l'éditeur.

L'éditeur lance d'abord une enchère contextuelle d'en-tête en appelant Prebid.js avec un indicateur pour indiquer qu'une enchère Protected Audience sera exécutée par la suite. Prebid.js collecte ensuite les réponses aux enchères et les envoie à l'ad server de l'éditeur pour une mise aux enchères contextuelle côté serveur. Lors de la 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 des acheteurs (perBuyerSignals) à utiliser pour l'enchère Protected Audience suivante, s'ils souhaitent y participer. Cette configuration d'enchères de composants sera finalement transmise à l'enchère 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 côté client de l'ad server de l'éditeur et définit les espaces publicitaires.
3. La page de l'éditeur charge Prebid et lance l'enchère contextuelle d'enchères d'en-tête.
4. Enchères contextuelles du vendeur A
   (exécutées en parallèle des enchères contextuelles 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 perBuyerSignals auprès des acheteurs.
6. Le vendeur A exécute une mise aux enchères contextuelle.
7. Le vendeur A crée la configuration de l'enchère du composant avec perBuyerSignals inclus.
8. Le vendeur A répond à Prebid.js avec l'enchère gagnante et la configuration de l'enchère de ses composants.
9. Enchères contextuelles du vendeur B
   (s'exécutent en parallèle des enchères contextuelles 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 des acheteurs.
11. Le vendeur B exécute une enchère contextuelle.
12. Le vendeur B élabore la configuration de l'enchère du composant avec perBuyerSignals inclus.
13. Le vendeur B répond à Prebid.js avec l'enchère gagnante et la configuration de l'enchère de ses composants.
14. Enchères contextuelles 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 les enchères contextuelles.
15. Les configurations d'enchères des composants avec les signaux des acheteurs sont partagées avec la bibliothèque côté client du serveur publicitaire de l'éditeur.
16. L'ad server de l'éditeur lance une mise aux enchères contextuelle pour déterminer la meilleure annonce parmi les campagnes vendues directement, les enchères programmatiques, les enchères contextuelles de Prebid et l'autre inventaire.
17. L'ad server de l'éditeur renvoie l'enchère gagnante ajustée.

Enchères multivendeurs Protected Audience

Séquence temporelle 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 niveau supérieur le prix d'enchère ajusté de l'enchère contextuelle gagnante, les configurations d'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 prix plancher peut être transmis à la configuration des enchères en tant que signal d'évaluation lors de l'enchère de premier niveau.

Les enchères des composants sont exécutées en parallèle. Dans chaque enchère de composant, le navigateur génère des enchères à partir de la logique d'enchères de chaque acheteur participant à cette enchère de composant, attribue un score à chaque enchère à l'aide de la logique de calcul du score du vendeur du composant, puis renvoie l'annonce ayant le score le plus élevé à l'enchère de niveau supérieur.

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 des enchères contextuelles, les configurations d'enchères des composants avec des signaux des acheteurs au vendeur de premier niveau. Le prix de l'enchère gagnante de l'annonce dans les enchères contextuelles peut être transmis à la configuration des enchères en tant que signaux du vendeur (ce prix d'enchère devient disponible dans la fonction scoreAd() du vendeur de niveau supérieur).
3. Le vendeur de premier niveau lance les enchères Protected Audience en appelant runAdAuction().
4. Enchères sur les composants du vendeur A
   (exécutées en parallèle des enchères sur les composants du vendeur B)
   Le navigateur lit les groupes d'intérêt de l'utilisateur pour tous les acheteurs participant aux enchères sur les composants du vendeur A.
5. Le navigateur récupère les scripts d'enchères et les signaux d'enchères de confiance à partir des emplacements spécifiés 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 de calcul du score et les signaux de calcul du score fiables de chaque annonce 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 avec le score le plus élevé envoyé par la logique de notation du vendeur A.
10. Enchères sur les composants du vendeur B
    (exécutées en parallèle des enchères sur les composants 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 sur les composants du vendeur B.
11. Le navigateur récupère les scripts d'enchères et les signaux d'enchères de confiance à partir des emplacements spécifiés 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 de notation et les signaux de notation fiables 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 avec le score le plus élevé envoyé par la logique de notation du vendeur B.

Score et affichage des annonces au niveau des enchères de premier niveau

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

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

Si le prix de l'enchère gagnante de l'enchère contextuelle est supérieur au prix de l'enchère gagnante de l'enchère de composant, la fonction scoreAd() peut renvoyer un score de désirabilité de 0. Si aucune annonce n'a un score de désirabilité supérieur à 0, cela signifie que l'annonce gagnante de l'enchère contextuelle est plus intéressante que n'importe quelle annonce gagnante de l'enchère de composant, et la fonction runAdAuction() renvoie null.

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

1. Évaluation des annonces aux enchères de premier niveau
   Le navigateur récupère le script d'évaluation du vendeur de premier niveau, ainsi que les signaux d'évaluation fiables de chaque annonce.
2. Le navigateur exécute la logique de calcul du score du vendeur de niveau supérieur pour chaque enchère gagnante de toutes les enchères de composants. Dans le script scoreAd() du vendeur de premier niveau, la logique a accès au prix de l'enchère gagnante ajustée par les enchères contextuelles qui peut avoir été transmis en tant que sellerSignals dans la configuration des enchères. 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 en fonction du prix de l'enchère Protected Audience du composant.
3. Le navigateur choisit l'annonce dont le score de désirabilité est le plus élevé, tel que défini par la logique de notation du vendeur de premier niveau.
4. Si l'enchère Protected Audience est gagnante
   L'enchère Protected Audience renvoie un objet FencedFrameConfig ou un URN opaque à la bibliothèque côté client du serveur d'annonces de l'éditeur.
5. La bibliothèque côté client définit l'attribut config du frame clôturé sur l'objet FencedFrameConfig ou l'attribut src de l'iframe sur l'URN opaque de l'annonce Protected Audience gagnante.
6. Le navigateur récupère l'annonce gagnante de l'enchère Protected Audience auprès de l'acheteur.
7. Le navigateur affiche l'annonce à l'utilisateur.
8. Si l'enchère contextuelle est remportée
   L'enchère Protected Audience renvoie null.
9. Le navigateur définit l'attribut src de l'iFrame sur l'annonce contextuelle gagnante.
10. Le navigateur récupère l'annonce gagnante de l'enchère contextuelle auprès de l'acheteur.
11. Le navigateur affiche l'annonce à l'utilisateur.

Interagir et envoyer des commentaires

É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.