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. Ils font appel à plusieurs entreprises (par exemple, des plates-formes côté offre et côté demande, ainsi que des serveurs publicitaires d'éditeurs) pour déterminer la meilleure annonce pour un emplacement publicitaire donné sur la page. Les enchères d'en-tête permettent aux éditeurs de recueillir des enchères pour un emplacement publicitaire auprès 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 exécuter une enchère avec des données contextuelles, et Protected Audience est utilisé pour exécuter une enchère avec des données multisites.

Avant de commencer, découvrez les principes de base de l'API sur la page Protected Audience et le header bidding dans la documentation Prebid.js.

Définitions

Enchères

Participants

Configurer les enchères séquentielles

Dans une configuration d'enchères séquentielles, les enchères contextuelles sont exécutées en premier, puis les enchères Protected Audience. Cette configuration permet aux éditeurs de maximiser leur potentiel de revenus en organisant une enchère avec les données contextuelles disponibles sur la page, ainsi qu'une enchère avec des données multisites dans un environnement sécurisé pour 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 l'enchère contextuelle de l'ad server de l'éditeur. Le prix de l'enchère gagnante ajusté de l'enchère contextuelle peut ensuite être saisi dans l'enchère Protected Audience en tant que prix plancher. Lors de l'étape de notation, le vendeur de premier niveau peut faire passer les prix des offres d'enchères des composants en dessous du prix plancher en leur attribuant un score nul lors du calcul du score de désirabilité. Si aucune enchère de composant Protected Audience n'est supérieure au prix plancher, l'annonce gagnante de l'enchère contextuelle est diffusée à l'utilisateur. Si l'enchère Protected Audience est remportée, cela signifie que l'enchère est supérieure au prix plancher et que l'annonce gagnante Protected Audience est affichée à l'utilisateur.

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

Description détaillée du diagramme :

1. Avant l'enchère, l'utilisateur est ajouté à un groupe d'intérêt sur le site d'un annonceur.
2. Lorsque l'utilisateur consulte la page de l'éditeur ultérieurement, Prebid.js exécute une enchère 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 les 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 à l'enchère 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 et plus encore, 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 de l'ad server de l'éditeur.
5. Le prix de l'enchère ajusté du gagnant de l'enchère contextuelle, ainsi que les signaux de l'acheteur (perBuyerSignals) et les configurations d'enchères de composants du vendeur collectés 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 multivendeurs Protected Audience est exécutée par le vendeur de premier niveau. Lors de l'étape de notation du vendeur de premier niveau, il peut comparer le prix de l'enchère gagnante de chaque composant au prix de l'enchère gagnante ajusté du contexte. Si le prix de l'enchère du composant est inférieur à celui de l'enchère de l'enchère contextuelle, le vendeur de premier niveau renvoie le score d'attractivité 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 est affichée à l'utilisateur.

Avant la mise aux enchères

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 appartient l'utilisateur, et ajouter des données contextuelles provenant du site de l'annonceur et des données first party à utiliser ultérieurement comme signaux pour l'enchère.

1. L'utilisateur accède au site de l'annonceur.
2. Le site de l'annonceur charge le script de chaque acheteur participant aux enchères à un moment ultérieur.
3. Le script de l'acheteur contient l'appel joinAdInterestGroup() pour ajouter l'utilisateur au groupe d'intérêt de l'acheteur.

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

Dans une configuration d'enchères séquentielles, toutes les enchères contextuelles sont exécutées avant le lancement de l'enchère Protected Audience. Dans la configuration expliquée 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 lance d'abord une enchère contextuelle d'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 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 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 l'enchère Protected Audience suivante, s'ils souhaitent y participer. Cette configuration d'enchères de composants sera ensuite 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 du serveur publicitaire 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 des acheteurs.
6. Le vendeur A exécute une enchère contextuelle.
7. Le vendeur A crée la configuration des enchères de composants 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
   (exécutées 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 perBuyerSignals des acheteurs.
11. Le vendeur B exécute une enchère contextuelle.
12. Le vendeur B crée la configuration des enchères de composants avec perBuyerSignals inclus.
13. Le vendeur B répond à Prebid.js avec l'enchère gagnante et la configuration de l'enchère de composant.
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 de 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 organise une mise aux enchères contextuelle pour déterminer la meilleure annonce parmi les campagnes vendues en direct, les enchères programmatiques, les enchères contextuelles de Prebid et les autres inventaires.
17. L'ad server de l'éditeur renvoie l'enchère gagnante ajustée.

Enchères multivendeurs Protected Audience

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

Les enchères de composants sont exécutées en parallèle. Dans chaque enchère de composants, le navigateur génère des enchères à partir de la logique d'enchères de chaque acheteur participant à cette enchère de composants, attribue un score à chaque enchère à l'aide de la logique de scoring du vendeur de composants, puis renvoie l'annonce ayant obtenu le score le plus élevé à 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 d'enchère de l'enchère contextuelle, les configurations d'enchères de composants avec les signaux des acheteurs au vendeur de premier niveau. Le prix de l'enchère gagnante pour l'annonce contextuelle 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 premier niveau).
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 fiables à partir des emplacements spécifiés dans les groupes d'intérêt des acheteurs participant aux enchères de 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 notation et les signaux de notation fiables de chaque annonce du vendeur A.
8. Le navigateur exécute la logique de scoring du vendeur A pour chaque enchère.
9. Le navigateur choisit l'annonce ayant obtenu le score le plus élevé selon la logique de notation du marchand A.
10. Enchères de composants du vendeur B
    (exécutées en parallèle des enchères de composants du vendeur A)
    Le navigateur lit les groupes d'intérêt de l'utilisateur pour tous les acheteurs participant aux enchères de composants du vendeur B.
11. Le navigateur récupère les scripts d'enchères et les signaux d'enchères fiables à partir des emplacements spécifiés dans les groupes d'intérêt des acheteurs participant aux enchères de 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 scoring et les signaux de scoring fiables de chaque annonce du vendeur B.
14. Le navigateur exécute la logique de scoring du vendeur B pour chaque enchère.
15. Le navigateur choisit l'annonce ayant obtenu le score le plus élevé selon la logique de notation du vendeur B.

Évaluation des enchères et rendu des annonces de premier niveau

Une fois les enchères de composants de la section précédente exécutées, le navigateur exécute la logique de scoring 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 de l'enchère ajusté en fonction du contexte peut être disponible sous la forme sellerSignals. La logique de scoring peut comparer ce prix de l'enchère contextuelle au prix de l'enchère gagnante de l'enchère de composants Protected Audience.

Si le prix de l'enchère gagnante de l'enchère contextuelle est supérieur à celui de l'enchère de composant, 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 est plus intéressante que les annonces gagnantes des enchères de composants. La fonction runAdAuction() renvoie alors null.

Si les enchères Protected Audience n'ont aucun gagnant et renvoient null, la bibliothèque côté client de l'ad server de l'éditeur peut afficher le gagnant des enchères contextuelles dans un iFrame. Si l'enchère Protected Audience remporte la mise face à l'enchère contextuelle et renvoie un objet FencedFrameConfig ou un URN opaque, l'annonce gagnante de l'enchère Protected Audience peut être affichée dans un cadre clôturé ou un iFrame.

1. Évaluation des annonces aux enchères de premier niveau
   Le navigateur récupère le script d'évaluation auprès du vendeur de premier niveau, ainsi que les signaux d'évaluation fiables de chaque annonce.
2. Le navigateur exécute la logique de scoring du vendeur de premier niveau 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é en fonction du contexte, 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 avec le prix de l'enchère Protected Audience du composant 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 d'enchère du composant Protected Audience.
3. Le navigateur choisit l'annonce ayant le score de désirabilité le plus élevé parmi celles envoyées par la logique de scoring du vendeur de premier niveau.
4. Si l'enchère Protected Audience est remportée
   L'enchère Protected Audience renvoie un objet FencedFrameConfig ou un URN opaque à la bibliothèque côté client du serveur publicitaire de l'éditeur.
5. La bibliothèque côté client définit l'attribut config du frame clôturé sur l'objet FencedFrameConfig ou définit 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 des enchères 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.