Enchères publicitaires sur l'appareil pour diffuser des audiences de remarketing et personnalisées, sans suivi tiers sur plusieurs sites.
À qui s'adresse cet article ?
Cet article présente les principes de base de l'API Protected Audience et explique certains concepts sous-jacents, mais n'entre pas dans les détails techniques.
- Si vous travaillez dans la publicité ou les technologies publicitaires, vous découvrirez le fonctionnement de Protected Audience.
- Si vous êtes développeur ou ingénieur logiciel, le guide du développeur de l'API Protected Audience fournit des informations techniques plus détaillées sur l'API. Consultez le dernier état des fonctionnalités Protected Audience en attente.
Reportez-vous au glossaire pour connaître les termes utilisés dans la documentation de l'API Protected Audience. À la fin de cet article, découvrez comment répondre aux commentaires et les partager.
Qu'est-ce que l'API Protected Audience ?
L'API Protected Audience est une technologie de la Privacy Sandbox destinée aux cas d'utilisation des audiences personnalisées et du remarketing. Elle est conçue pour empêcher les tiers de 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 mise en œuvre dans Chromium dans la famille de propositions TURTLEDOVE. La différence entre Protected Audience et TURTLEDOVE est principalement liée à la séparation du rôle sur l'appareil entre l'acheteur et le vendeur d'annonces. Les sections suivantes expliquent le fonctionnement de l'API Protected Audience.
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](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/protected-audience-overview.png?authuser=3&hl=fr)
L'API Protected Audience utilise les groupes de centres d'intérêt pour permettre aux sites d'afficher des annonces pertinentes pour leurs utilisateurs.
Par exemple, lorsqu'un utilisateur visite un site qui souhaite promouvoir ses produits, le 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 à ce groupe. 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 pour 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 mise aux enchères.
Par la suite, 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 à présenter à 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 à enchérir.
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 à le faire.
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 dans le navigateur.
Chaque groupe de centres d'intérêt qui propose une enchère est appelé "acheteur".
Lorsque le navigateur appelle la fonction pour lancer les enchères publicitaires, 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. Ensuite, le vendeur reçoit ces enchères, ainsi que des données en temps réel appartenant au vendeur, et lui attribue un score. L'enchère avec le score le plus élevé remporte la mise aux enchères.
L'annonce gagnante est diffusée dans un frame cloisonné. L'URL de la création est spécifiée dans l'enchère, et l'origine doit correspondre à l'une des URL figurant dans la liste fournie par la configuration du groupe de centres d'intérêt.
Le vendeur peut indiquer le résultat de l'enchère (reportResult()
), et les acheteurs peuvent indiquer leurs victoires (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'obtenir des annonces plus pertinentes au lieu de se contenter de choisir des annonces basées sur le contenu du site (ciblage contextuel) ou d'utiliser les informations fournies par un utilisateur sur le site sur lequel elles sont diffusées (ciblage des données first party).
Traditionnellement, les plates-formes publicitaires ont appris à connaître les centres d'intérêt des utilisateurs en suivant leur comportement sur l'ensemble des sites. Les navigateurs doivent pouvoir permettre aux plates-formes publicitaires de sélectionner les annonces pertinentes, afin 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 les plates-formes 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.
Protected-audience-demo.web.app fournit une présentation d'un déploiement de base de l'API Protected Audience sur des sites d'annonceurs et d'éditeurs. La vidéo de démonstration de l'API Protected Audience explique le fonctionnement de ce code et explique comment utiliser les outils pour les développeurs Chrome pour le débogage.
Quelle est la configuration de navigateur disponible ?
Les utilisateurs peuvent ajuster leur participation aux essais de la Privacy Sandbox dans Chrome en activant ou en désactivant le paramètre de premier niveau dans chrome://settings/adPrivacy
. Lors des tests initiaux, les utilisateurs peuvent désactiver l'API Protected Audience à l'aide des paramètres de la Privacy Sandbox.
Chrome prévoit de permettre aux utilisateurs de voir et de 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 de la 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 d'un site ou en tant qu'utilisateur individuel.
Concepts clés
Vous voulez en savoir plus sur la terminologie de l'API Protected Audience ? Consultez le glossaire de la Privacy Sandbox.
Qu'est-ce qu'un groupe d'intérêt ?
Un groupe de centres d'intérêt de l'API Protected Audience représente un groupe de personnes ayant un centre d'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 des cas d'utilisation différents.
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()
et en fournissant des informations telles que des données sur les annonces pertinentes pour ce groupe et une URL pour JavaScript utilisée dans les enchères. Vous pouvez mettre à jour les données d'un groupe de centres d'intérêt (comme les annonces), et l'activer pendant 30 jours maximum.
Types de groupes de centres d'intérêt
Le tableau suivant fournit 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 produit pour une catégorie spécifique de vélo. | Remarketing auprès des utilisateurs qui ont déjà interagi avec la marque |
Diffuseur | Site Web d'actualités | Contenus | 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 aux éditeurs d'en 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, recherchent une catégorie d'articles. 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 l'entreprise 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 définit une enchère lors des enchères publicitaires.
Exemple :
- Annonceur: agit en son nom.
- Plate-forme côté demande (DSP): pour le compte des annonceurs.
- Propriétaire du groupe de centres d'intérêt: vous travaillez 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 de la mise aux enchères.
Ces tâches sont effectuées de manière automatisée, dans le code fourni par l'acheteur, qui est exécuté lors d'une enchère publicitaire 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:
- URL de code d'enchère, utilisée lorsque le vendeur lance une enchère publicitaire.
- Les URL des créations éventuellement associées au groupe de centres d'intérêt. Les URL des annonces pourront être ajoutées ultérieurement lors d'une mise à jour.
- Une liste des clés de données à interroger et l'URL du service clé-valeur de l'acheteur pour permettre 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 gère les enchères publicitaires ?
Plusieurs parties peuvent participer à une mise aux enchères pour vendre des espaces publicitaires.
Exemple :
- Éditeur de contenu: il agit en son nom pour héberger le contenu publicitaire sur son site Web.
- Plate-forme côté offre (SSP): collaboration avec l'éditeur et fourniture d'autres services
- Script tiers: agir pour le compte d'un éditeur, afin de permettre la participation aux enchères publicitaires.
Avec l'API Protected Audience, un vendeur d'espace publicitaire assume 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 s'exécute dans des worklets pour calculer le score de désirabilité pour chaque enchère.
- Générez un rapport sur le résultat de la mise aux enchères.
Ces tâches sont effectuées par programmation 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 suivant décrit chaque étape d'une enchère publicitaire de l'API Protected Audience:
![Six étapes d'une enchère publicitaire de l'API Protected Audience](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/protected-audience-steps.png?authuser=3&hl=fr)
Dans l'API Protected Audience, une enchère publicitaire est 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 du code permettant d'évaluer les enchères, ce qui inclut la valeur de chaque enchère, l'URL de la création publicitaire et d'autres données renvoyées par chaque acheteur. Lors de 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 de clés-valeurs. Une fois qu'une annonce est sélectionnée et affichée (dans un cadre cloisonné pour préserver la confidentialité), le vendeur et l'acheteur gagnant peuvent signaler le résultat de l'enchère.
- Un utilisateur visite un site qui affiche des annonces.
- Le code du vendeur lance une enchère. Le vendeur spécifie quel espace publicitaire est à vendre et qui peut enchérir, ainsi qu'une méthode pour évaluer ces enchères.
- 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.
- Le code du vendeur attribue un score à chaque enchère et sélectionne un gagnant. Cette logique s'appuie sur la valeur de l'enchère et d'autres données pour déterminer si une enchère est souhaitable, 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 enchère, le vendeur trouve la meilleure annonce contextuelle pour l'espace publicitaire disponible.
- 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é jusqu'à la création publicitaire, et l'URL de la création n'est pas visible par le vendeur ni par l'éditeur. Si l'indicateurresolveToConfig
est défini surfalse
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. - L'enchère est signalée au vendeur et aux acheteurs gagnants.
Un mécanisme de signalement pour les acheteurs perdants 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 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. Il s'exécute dans un environnement d'exécution sécurisé. Une requête adressée à un service de valeur-clé ne peut pas aboutir à une journalisation au niveau des événements ni avoir d'autres effets secondaires. Le service clé-valeur prend également en charge 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 clé-valeur.
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 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 la présentation de l'API et celle du modèle de confiance.
Comment les données en temps réel sont-elles intégrées aux enchères ?
Lors des enchères publicitaires, les acheteurs ou les vendeurs peuvent avoir besoin d'accéder à des données en temps réel. Par exemple, les acheteurs peuvent vouloir calculer le budget restant dans une campagne publicitaire, ou le vendeur peut être amené à vérifier que les créations respectent le règlement des é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 des données en temps réel.
Afin de s'assurer que l'écosystème dispose d'un temps de test suffisant, nous ne prévoyons pas d'exiger l'utilisation des services de clés-valeurs Open Source ou d'environnements d'exécution approuvés avant l'abandon des cookies tiers. Nous informerons les développeurs dans les grandes lignes pour commencer les tests et l'adoption avant que cette transition n'ait lieu.
Comment les données first party sont-elles utilisées dans les enchères Protected Audience ?
Les données first party sont les données appartenant au site sur 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 des données first party.
Dans une mise aux enchères Protected Audience, l'annonceur peut utiliser ses données first party pour déterminer l'appartenance à un groupe de centres d'intérêt de l'annonce. Il peut également 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 des enchères, et non pour les vendeurs.
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 de 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 mise en forme des données.
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 à commencer à utiliser l'API Protected Audience, consultez la page Tester 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 de 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 donner votre avis
- GitHub: consultez l'explication, soulevez des questions et suivez la discussion.
- Annonces: rejoignez ou consultez les annonces précédentes dans la liste de diffusion de l'API Protected Audience.
- W3C: discutez de cas d'utilisation par secteur dans le groupe Améliorer la publicité sur le Web.
- Assistance aux développeurs: posez des questions sur l'implémentation et les bonnes pratiques, ou participez à des discussions sur le dépôt de l'assistance aux développeurs Privacy Sandbox.
- Implémentation actuelle : pour toute question concernant l'implémentation de l'API Protected Audience dans Chrome, signalez un bug Chromium.