API Protected Audience

Enchères publicitaires sur l'appareil pour diffuser des audiences de remarketing et personnalisées, sans suivi tiers intersite

À qui s'adresse cet article ?

Cet article présente les principes de base de l'API Protected Audience et explique certains concepts sous-jacents, sans entrer dans les détails techniques.

Reportez-vous au glossaire pour connaître les termes utilisés dans la documentation de l'API Protected Audience. À la fin de cet article, vous découvrirez comment susciter l'intérêt et partager vos commentaires.

Qu'est-ce que l'API Protected Audience ?

L'API Protected Audience est une technologie de Privacy Sandbox qui répond à des cas d'utilisation de remarketing et d'audiences personnalisées. Elle est conçue pour que les tiers ne puissent pas suivre le comportement de navigation des utilisateurs sur les sites.

L'API Protected Audience permet aux enchères sur l'appareil par le navigateur de choisir des annonces pertinentes à partir de sites Web que l'utilisateur a déjà visités.

L'API Protected Audience est la première expérience à avoir été implémentée dans Chromium dans la famille de propositions TURTLEDOVE. La différence entre Protected Audience et TURTLEDOVE est principalement liée à la séparation des rôles sur l'appareil de l'acheteur et du vendeur d'annonces. Les sections ci-dessous expliquent le fonctionnement de l'API Protected Audience.

L'API Protected Audience en une minute

Pour une présentation plus détaillée de l'API Protected Audience, consultez le guide du développeur de l'API Protected Audience.

Présentation de chaque étape du cycle de vie de l'API Protected Audience
Cycle de vie de l'API Protected Audience: affichez une version plus grande.

L'API Protected Audience utilise des groupes de centres d'intérêt pour permettre aux sites de diffuser des annonces pertinentes pour leurs utilisateurs.

Par exemple, lorsqu'un utilisateur consulte un site qui souhaite promouvoir ses produits, un propriétaire d'un groupe de centres d'intérêt (comme une plate-forme côté demande (DSP)) peut demander au navigateur de l'utilisateur d'ajouter l'adhésion au groupe de centres d'intérêt. Si la requête aboutit, le navigateur enregistre:

  • Nom du groupe de centres d'intérêt (par exemple, "vélos personnalisés").
  • Propriétaire du groupe de centres d'intérêt (par exemple, "https://dsp.example").
  • Les informations de configuration du groupe de centres d'intérêt, afin de permettre au navigateur d'accéder au code d'enchère, au code d'annonce et aux données en temps réel, si le propriétaire du groupe est invité à enchérir dans une enchère publicitaire.

Plus tard, lorsque l'utilisateur visite un site disposant d'un espace publicitaire disponible, le vendeur d'espace publicitaire (un fournisseur côté vente (SSP), ou le site lui-même) peut utiliser l'API Protected Audience pour lancer des enchères publicitaires afin de sélectionner les annonces les plus appropriées à diffuser auprès de l'utilisateur. Le vendeur appelle la fonction navigator.runAdAuction(), qui fournit une liste des propriétaires de groupes de centres d'intérêt qui sont invités à définir une enchère.

Les enchères ne peuvent être fournies que par des groupes de centres d'intérêt dont le navigateur est membre et dont les propriétaires ont été invités à enchérir.

Le code d'enchère est extrait à partir d'une URL fournie dans la configuration du groupe de centres d'intérêt. Ce code fournit des données sur le groupe de centres d'intérêt et des informations sur le vendeur, ainsi que des données contextuelles sur la page et à partir du navigateur.

Chaque groupe de centres d'intérêt qui fournit une enchère est appelé "acheteur".

Lorsque le navigateur appelle la fonction permettant de lancer une enchère publicitaire, le code de chaque acheteur génère une enchère à l'aide des données en temps réel fournies par son service clé-valeur Protected Audience. Le vendeur reçoit ensuite ces enchères, ainsi que des données en temps réel qu'il détient et attribue un score à chaque enchère. L'enchère avec le score le plus élevé remporte la mise aux enchères.

L'annonce gagnante est affichée dans un frame cloisonné. L'URL de la création est spécifiée dans l'enchère, et l'origine doit correspondre à une URL figurant dans la liste fournie par la configuration du groupe de centres d'intérêt.

Le vendeur peut signaler le résultat de la mise aux enchères (reportResult()), et les acheteurs peuvent indiquer leurs gains (reportWin()).

En savoir plus sur les rapports sur les enchères Protected Audience

Pourquoi avons-nous besoin de l'API Protected Audience ?

Comprendre les centres d'intérêt des utilisateurs permet d'afficher des annonces plus pertinentes en plus d'être basées sur le contenu du site (ciblage contextuel) ou d'utiliser les informations fournies par un utilisateur sur le site sur lequel l'annonce est diffusée (ciblage par données first party).

Traditionnellement, les plates-formes publicitaires s'informent sur les centres d'intérêt des utilisateurs en suivant leur comportement sur les sites. Les navigateurs doivent permettre aux plates-formes publicitaires de sélectionner les annonces pertinentes pour que les éditeurs de contenu puissent générer des revenus publicitaires sans suivi intersites.

L'API Protected Audience vise à rapprocher la plate-forme Web d'un état où le navigateur de l'utilisateur sur son appareil (et non l'annonceur ou la plate-forme de technologie publicitaire) contient des informations sur ce qui intéresse cette personne.

Comment essayer l'API Protected Audience ?

  • Le guide du développeur de l'API Protected Audience explique comment utiliser l'API et effectuer des tests en local.

  • Protect-audience-demo.web.app fournit une présentation du déploiement de base de l'API Protected Audience sur les sites d'annonceurs et d'éditeurs. La vidéo de démonstration de l'API Protected Audience explique le fonctionnement de ce code et donne un aperçu de l'utilisation des outils pour les développeurs Chrome à des fins de débogage.

Quelle est la configuration de navigateur disponible ?

Les utilisateurs peuvent ajuster leur participation aux essais Privacy Sandbox dans Chrome en activant ou en désactivant le paramètre de premier niveau dans chrome://settings/adPrivacy. Lors des premiers tests, les utilisateurs peuvent désactiver l'API Protected Audience à l'aide des paramètres Privacy Sandbox.

Chrome prévoit d'autoriser les utilisateurs à consulter et à gérer la liste des groupes de centres d'intérêt auxquels ils ont été ajoutés sur les sites qu'ils ont visités. Comme pour les technologies Privacy Sandbox, les paramètres utilisateur peuvent évoluer en fonction des commentaires des utilisateurs, des organismes de réglementation et d'autres personnes.

Nous mettrons à jour les paramètres disponibles dans Chrome au fur et à mesure de la progression de l'API Protected Audience, en fonction des tests et des commentaires. À l'avenir, nous proposerons des paramètres plus précis pour gérer Protected Audience et les données associées.

Les appelants de l'API ne peuvent pas accéder à l'appartenance à un groupe lorsque les utilisateurs naviguent en mode navigation privée. L'adhésion est supprimée lorsque les utilisateurs effacent les données de leur site.

Puis-je désactiver l'API Protected Audience ?

Découvrez comment bloquer l'accès à l'API Protected Audience en tant que propriétaire du site ou en tant qu'utilisateur individuel.

Concepts clés

Vous souhaitez en savoir plus sur la terminologie de l'API Protected Audience ? Consultez le glossaire de la Privacy Sandbox.

Qu'est-ce qu'un groupe de centres d'intérêt ?

Un groupe de centres d'intérêt de l'API Protected Audience représente un groupe de personnes partageant un intérêt commun, correspondant à une liste de remarketing.

Chaque groupe de centres d'intérêt de l'API Protected Audience a un propriétaire. Différents types de propriétaires créent différents types de groupes de centres d'intérêt avec différents cas d'utilisation.

Le propriétaire demande au navigateur de l'utilisateur d'ajouter l'appartenance à son groupe de centres d'intérêt en appelant la fonction JavaScript navigator.joinAdInterestGroup(), en fournissant des informations telles que des données sur les annonces pertinentes pour le groupe de centres d'intérêt et une URL pour JavaScript utilisée dans les enchères. Les données des groupes de centres d'intérêt (comme les annonces) peuvent être mises à jour, et un groupe de centres d'intérêt peut être activé pendant 30 jours maximum.

Le tableau ci-dessous présente des exemples de différents types de groupes de centres d'intérêt et de propriétaires de l'API Protected Audience.

Propriétaire Exemple Intérêt Exemple Cas d'utilisation
Annonceur Fabricant de vélos Produits Personnes ayant consulté des pages de produits pour une catégorie spécifique de vélo. Remarketing auprès des personnes qui ont déjà interagi avec la marque
Éditeur Site Web d'actualités Contenu Personnes qui lisent des contenus sur le cyclisme. Les éditeurs peuvent utiliser les données first party pour permettre aux annonceurs d'acheter des annonces pertinentes pour les lecteurs sur leur site. Un groupe de centres d'intérêt détenu par un éditeur peut permettre à ces derniers de faire de même, même lorsque ces personnes parcourent d'autres sites. Les éditeurs peuvent facturer la diffusion d'annonces auprès de segments spécifiques de leur audience.
AdTech DSP Catégorie de produits Personnes ayant manifesté de l'intérêt pour le matériel de cyclisme. Une entreprise de technologie publicitaire peut créer et gérer un groupe de centres d'intérêt composé de personnes qui, selon elle, sont à la recherche d'une catégorie d'articles spécifique. Ce groupe de centres d'intérêt peut ensuite être utilisé pour promouvoir des produits sur des sites qui vendent des articles de cette catégorie (et qui travaillent avec la société de technologie publicitaire).

Chrome autorise jusqu'à 1 000 groupes de centres d'intérêt par propriétaire et jusqu'à 1 000 propriétaires de groupes de centres d'intérêt. Ces limites sont des garde-fous et ne doivent pas être atteintes en fonctionnement normal.

Qu'est-ce qu'un acheteur ?

Dans l'API Protected Audience, un acheteur est une partie qui possède un groupe de centres d'intérêt et enchérit dans des enchères publicitaires.

Exemple :

  • Annonceur: agir pour son propre compte.
  • Plate-forme côté demande (DSP): agir pour le compte des annonceurs.
  • Propriétaire du groupe de centres d'intérêt: travailler pour plusieurs annonceurs.

Les acheteurs ont trois tâches:

  • Choisissez de participer ou non à une mise aux enchères.
  • Sélectionnez des annonces et calculez une enchère.
  • Générez un rapport sur le résultat des enchères.

Ces tâches sont effectuées de manière programmatique, dans le code fourni par l'acheteur, qui est exécuté lors des enchères publicitaires de l'API Protected Audience.

Lorsqu'un acheteur demande au navigateur d'un utilisateur d'ajouter un groupe de centres d'intérêt aux groupes dont il fait partie (en appelant la fonction JavaScript navigator.joinAdInterestGroup()), il fournit au navigateur les éléments suivants : * Une URL pour le code d'enchère, qui sera utilisée lorsque le vendeur lancera des enchères publicitaires. * Le cas échéant, les URL des créations associées au groupe de centres d'intérêt. Les URL des annonces pourront être ajoutées ultérieurement via une mise à jour. * Une liste des clés de données à interroger et l'URL du service clé-valeur de l'acheteur, permettant au code d'enchères d'obtenir des données en temps réel lors d'une enchère

Le code de l'acheteur peut également inclure une fonction reportWin() pour indiquer le résultat de la mise aux enchères.

Qui met en concurrence les annonces ?

Plusieurs parties peuvent mettre en concurrence des annonces pour vendre un espace publicitaire.

Exemple :

  • Éditeur de contenu: agit pour son propre compte afin d'héberger le contenu publicitaire sur son site Web.
  • Plate-forme côté offre (SSP): collaboration avec l'éditeur et autres services proposés
  • Script tiers: agir pour le compte d'un éditeur, pour permettre la participation aux enchères publicitaires.

Avec l'API Protected Audience, un vendeur d'espace publicitaire remplit trois tâches:

  • Appliquez les règles de l'éditeur, en indiquant quels acheteurs et quelles enchères sont éligibles.
  • Exécution de la logique d'enchères: JavaScript exécute des workflows pour calculer un score de désirabilité pour chaque offre.
  • Générez un rapport sur le résultat des enchères.

Ces tâches sont effectuées de manière programmatique, dans le code fourni par le vendeur lorsqu'il lance une enchère publicitaire en appelant la fonction JavaScript navigator.runAdAuction().

Comment fonctionnent les enchères publicitaires de l'API Protected Audience ?

Le diagramme ci-dessous décrit chaque étape des enchères publicitaires de l'API Protected Audience: découvrez une version plus grande.

Six étapes d'une enchère publicitaire de l'API Protected Audience


Dans l'API Protected Audience, les enchères publicitaires sont un ensemble de petits programmes JavaScript que le navigateur exécute sur l'appareil de l'utilisateur pour choisir une annonce. Pour des raisons de confidentialité, l'ensemble du code d'enchère publicitaire du vendeur et des acheteurs est exécuté dans des worklets JavaScript isolés qui ne peuvent pas communiquer avec le monde extérieur.

Un vendeur (un éditeur ou une plate-forme côté offre) lance une enchère publicitaire Protected Audience sur un site qui vend de l'espace publicitaire (un site d'actualités, par exemple). Le vendeur choisit des acheteurs pour participer à l'enchère, indique l'espace à vendre et fournit des critères supplémentaires pour l'annonce. Chaque acheteur est le propriétaire d'un groupe de centres d'intérêt.

Le vendeur fournit au navigateur le code permettant d'évaluer les enchères, en incluant la valeur de chaque enchère, l'URL de la création d'annonce et d'autres données renvoyées par chaque acheteur. Pendant l'enchère, le code d'enchère des acheteurs et le code d'évaluation des enchères du vendeur peuvent recevoir des données de leurs services clé-valeur. Une fois qu'une annonce est choisie et affichée (dans un frame cloisonné pour préserver la confidentialité), le vendeur et l'acheteur gagnant peuvent rapporter le résultat de l'enchère.

  1. Un utilisateur visite un site qui affiche des annonces.
  2. Le code du vendeur lance une mise aux enchères. Le vendeur spécifie l'espace publicitaire à vendre et qui peut enchérir, ainsi qu'une méthode pour évaluer ces enchères.
  3. Le code de l'acheteur invité s'exécute pour générer une enchère, l'URL d'une création publicitaire pertinente et d'autres données. Le script d'enchères peut interroger des données en temps réel, telles que le budget restant de la campagne publicitaire, à partir du service clé-valeur de l'acheteur.
  4. Le code du vendeur attribue un score à chaque enchère et sélectionne un gagnant. Cette logique utilise la valeur de l'enchère et d'autres données pour renvoyer la désirabilité d'une enchère et refuser une annonce qui ne peut pas battre l'annonce contextuelle gagnante. Le vendeur peut utiliser son propre service clé-valeur pour les données en temps réel. Avant le début d'une mise aux enchères, le vendeur trouve la meilleure annonce contextuelle pour l'espace publicitaire disponible.
  5. L'annonce gagnante est renvoyée en tant qu'objet de configuration de frame cloisonné lorsque l'option resolveToConfig est définie dans la configuration de l'enchère. La configuration permet d'accéder au frame cloisonné à la création publicitaire. L'URL de la création est masquée pour le vendeur et l'éditeur. Si l'indicateur resolveToConfig est défini sur false ou n'est pas transmis, l'annonce gagnante est renvoyée sous la forme d'une URN opaque pouvant être utilisée pour afficher l'annonce dans un iFrame. L'objet de configuration de frame cloisonné est disponible à partir de M114.
  6. L'enchère est signalée au vendeur et aux acheteurs gagnants.

Un mécanisme de reporting pour les acheteurs perdus est en cours de discussion.

Qu'est-ce qu'un service de clés-valeurs de l'API Protected Audience ?

Le service clé-valeur de l'API Protected Audience permet aux technologies publicitaires d'interroger des données en temps réel lorsqu'une enchère est effectuée par l'acheteur, et aux vendeurs d'évaluer les annonces tout en préservant la confidentialité. Pour en savoir plus sur le service Clé-valeur de l'API Protected Audience et sur d'autres produits, consultez la page Services de l'API Protected Audience.

Le service clé-valeur est déployé sur la propre infrastructure cloud de la technologie publicitaire, et s'exécute dans un environnement d'exécution sécurisé. Une requête adressée à un service de clé-valeur ne peut pas aboutir à une journalisation au niveau des événements ni avoir d'autres effets secondaires. Le service clé-valeur est également compatible avec les fonctions définies par l'utilisateur (UDF), qui permettent aux technologies publicitaires d'exécuter leur propre logique personnalisée au sein du service.

Un acheteur ou un vendeur fournit une liste de "clés" pour spécifier les données dont il a besoin d'un service de clés-valeurs de l'API Protected Audience. Le service clé-valeur répond avec une valeur pour chaque clé.

Le code du service clé-valeur de l'API Protected Audience est désormais disponible dans un dépôt GitHub de la Privacy Sandbox. Ce service peut être utilisé par les développeurs Chrome et Android.

Pour en savoir plus sur le service clé-valeur de l'API Protected Audience, consultez les pages d'explication de l'API et celles d'explication du modèle de confiance.

Comment les données en temps réel sont-elles intégrées aux enchères ?

Les acheteurs ou les vendeurs participant aux enchères publicitaires peuvent avoir besoin d'accéder à des données en temps réel. Par exemple, les acheteurs peuvent souhaiter calculer le budget restant d'une campagne publicitaire, ou le vendeur peut être amené à vérifier que les créations respectent le règlement applicable aux éditeurs.

Pour répondre aux exigences de confidentialité de l'API Protected Audience, les données en temps réel requises lors d'une enchère publicitaire sont fournies par le service clé-valeur. Lorsque chaque acheteur appelle navigator.joinAdInterestGroup(), il spécifie une URL du service clé-valeur et les clés à interroger au service lors d'une enchère. De même, lorsque le vendeur lance une enchère publicitaire en appelant navigator.runAdAuction(), il fournit une URL pour son service clé-valeur. Le service clé-valeur du vendeur sera interrogé avec l'URL de rendu de la création.

Pour les tests initiaux, le modèle Bring Your Own Server est utilisé. À long terme, les technologies publicitaires devront utiliser les services Open Source de clés-valeurs de l'API Protected Audience s'exécutant dans des environnements d'exécution approuvés pour récupérer les données en temps réel.

Pour que l'écosystème dispose de suffisamment de temps pour effectuer des tests, nous ne nous attendons pas à devoir utiliser des services de clés-valeurs Open Source ni des environnements d'exécution sécurisés avant l'abandon des cookies tiers. Nous informerons les développeurs dans les grandes lignes afin qu'ils puissent commencer les tests et l'adoption avant que cette transition n'ait lieu.

Comment les données first party sont-elles utilisées dans une mise aux enchères Protected Audience ?

Les données first party sont les données appartenant au site et à ses utilisateurs. Par exemple, si un utilisateur a spécifié sa couleur préférée sur le site de l'annonceur ou de l'éditeur, cette couleur est considérée comme une donnée first party.

Dans une mise aux enchères Protected Audience, l'annonceur peut utiliser ses données first party pour déterminer l'appartenance aux groupes de centres d'intérêt de l'annonce et transmettre des données au groupe de centres d'intérêt en tant que userBiddingSignals. Les données first party de l'annonceur ne seront disponibles que pour les acheteurs lors de l'étape de génération d'enchères. Les vendeurs ne pourront pas y accéder.

Par exemple, si l'annonceur connaît la couleur préférée de l'utilisateur, la valeur peut être définie sur userBiddingSignals dans la configuration du groupe de centres d'intérêt lorsque l'utilisateur est ajouté à un groupe de centres d'intérêt: 

const interestGroup = {
  owner: 'https://example-buyer.com',
  name: 'running-shoes',
  userBiddingSignals: {
    favoriteColor: 'blue' // First-party data
  },
  // ...other interest group settings
};

navigator.joinAdInterestGroup(interestGroup, 3600);

L'éditeur peut également transmettre ses données first party en définissant les signaux dans la configuration des enchères lorsqu'il lance l'enchère. Il peut également contrôler qui reçoit les données first party. Lorsqu'un éditeur transmet les données first party en tant que auctionSignals, elles sont disponibles pour les acheteurs et les vendeurs. Lorsque les données sont transmises en tant que sellerSignals, elles ne sont disponibles que pour le vendeur. Lorsqu'elles sont transmises en tant que perBuyerSignals, elles ne sont disponibles que pour les acheteurs spécifiés. L'éditeur peut également transmettre des données first party aux enchères des composants. L'éditeur et les participants aux enchères doivent se mettre d'accord au préalable sur les données first party à partager et sur la manière dont elles doivent être mises en forme.

L'exemple suivant montre comment l'éditeur peut transmettre les données first party à différents participants aux enchères: 

const auctionConfig = {
  seller: 'https://example-seller.com',
  auctionSignals: {
    favoriteColor: 'blue', // Both buyer and seller will receive this signal
  },
  sellerSignals: {
    favoriteIceCreamFlavor: 'chocolate', // Only the seller will receive this signal
  },
  perBuyerSignals: {
    'https://example-buyer.com': {
      favoriteDrink: 'tea', // Only a specific buyer will receive this signal
    },
  },
  // The same pattern applies to the component auction
  componentAuctions: [{
    seller: 'https://example-component-seller.com',
    auctionSignals: { ... },
    sellerSignals: { ... },
    perBuyerSignals { ... }
  }],
  // ...other auction settings
};

navigator.runAdAuction(auctionConfig);

En savoir plus

Pour une présentation plus détaillée de l'API Protected Audience, consultez le guide du développeur de l'API Protected Audience.

Développeurs

Si vous êtes prêt à utiliser l'API Protected Audience, découvrez comment effectuer des tests et participer.

Nous avons rédigé un guide du développeur de l'API et créé une démonstration de l'API Protected Audience, qui propose un tutoriel sur le déploiement de base de l'API Protected Audience. La vidéo de démonstration de l'API Protected Audience explique le fonctionnement du code de démonstration et explique comment utiliser les outils pour les développeurs Chrome pour déboguer l'API Protected Audience.

Interagir et partager des commentaires