Présentation de l'API Protected Audience

Enchères sur l'appareil utilisées pour le remarketing et les audiences personnalisées, sans suivi intersites tiers

À 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 il n'entre pas dans les détails techniques.

• Si vous travaillez dans la publicité ou les technologies publicitaires, vous aurez une vue d'ensemble comment fonctionne Protected Audience.
• Si vous êtes développeur ou ingénieur logiciel, les Le guide du développeur de l'API Protected Audience fournit plus des détails techniques détaillés sur l'API. Consultez les le dernier état des fonctionnalités Protected Audience en attente.

Consultez le glossaire pour connaître les termes utilisés dans Documentation Protected Audience. À la fin de cet article, vous découvrirez comment susciter l'intérêt des utilisateurs et partager leurs commentaires.

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

L'API Protected Audience est une Privacy Sandbox adaptée aux cas d'utilisation du remarketing et des audiences personnalisées, conçue pour les tiers ne peuvent 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 sélectionner des annonces pertinentes parmi sites web que l'utilisateur a déjà consultés.

L'API Protected Audience est le premier test à être implémenté dans Chromium dans le TURTLEDOVE. La entre Protected Audience et TURTLEDOVE sont principalement liés à la séparation le rôle de l'acheteur et du vendeur d'annonces sur l'appareil. Les sections suivantes expliquent comment 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.

</ph> <ph type="x-smartling-placeholder"></ph>

L'API Protected Audience utilise des groupes de centres d'intérêt pour permettre aux sites de : de diffuser des annonces pertinentes pour les 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 la plate-forme côté demande (DSP, Demand-Side Platform)) peut demander au navigateur de l'utilisateur d'ajouter l'abonnement 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").
• Informations de configuration sur les groupes de centres d'intérêt auxquels le navigateur peut accéder code d'enchères, code d'annonce et données en temps réel, si le propriétaire du groupe est invité à lors des enchères publicitaires.

Plus tard, lorsque l'utilisateur visite un site pour lequel un espace publicitaire est disponible, le vendeur de l'espace publicitaire (un fournisseur côté vente (SSP) ou le site elle-même) peut utiliser 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 méthode navigator.runAdAuction(). , qui fournit une liste des propriétaires de groupes de centres d'intérêt 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 à enchérir.

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

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

Lorsque le navigateur appelle la fonction pour lancer la mise en concurrence des annonces, 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 les données en temps réel appartenant au vendeur et évalue chacun d'eux enchère. L'enchère avec le score le plus élevé remporte l'enchère.

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

Le vendeur peut signaler le résultat de l'enchère (reportResult()), et les acheteurs peuvent communiquent leurs réussites (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 que le simple choix annonces basées sur le contenu du site (ciblage contextuel) ou utilisant des informations fournies par un utilisateur au site sur lequel l'annonce est diffusée (ciblage de données first party).

Traditionnellement, les plates-formes publicitaires s'approprient les centres d'intérêt des utilisateurs en suivant leurs sur les différents sites. Les navigateurs doivent permettre aux plates-formes publicitaires de sélectionner des annonces pertinentes, afin que les éditeurs de contenu puissent générer des revenus publicitaires sans avoir le suivi.

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

Comment puis-je essayer l'API Protected Audience ?

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

• protected-audience-demo.web.app fournit Tutoriel de déploiement de base de l'API Protected Audience pour un annonceur et un éditeur de votre site Web. La vidéo de démonstration de l'API Protected Audience explique le fonctionnement et les aperçus de ce code comment utiliser les outils pour les développeurs Chrome pour le débogage.

Quelle est la configuration de navigateur disponible ?

Les utilisateurs peuvent modifier leur participation aux essais de la Privacy Sandbox dans Chrome en procédant comme suit : l'activation ou la désactivation du paramètre de premier niveau chrome://settings/adPrivacy Lors des tests initiaux, les utilisateurs peuvent désactiver l'API Protected Audience à l'aide de l'API Protect Paramètres Privacy Sandbox.

Chrome prévoit de permettre aux utilisateurs de consulter 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 le règlement technologies sandbox, les paramètres utilisateur peuvent évoluer en fonction des commentaires des utilisateurs, d'organismes de réglementation, entre autres.

Nous mettrons à jour les paramètres disponibles dans Chrome au fur et à mesure de la progression de l'API Protected Audience, sur la base de tests et de 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. et l'abonnement est supprimé 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. que ce soit 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 ayant 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. Les différents types de propriétaires vont créer différents types de groupes d'intérêt avec différents cas d'utilisation.

Le propriétaire demande au navigateur de l’utilisateur d’ajouter l’adhésion à son groupe d’intérêt en 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é dans les enchères. Les données des groupes de centres d'intérêt (les annonces, par exemple) mis à jour, et un groupe de centres d'intérêt peut être activé 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.

Chrome autorise jusqu'à 1 000 groupes de centres d'intérêt par propriétaire et jusqu'à 1 000 groupes de centres d'intérêt propriétaires. Ces limites sont conçues comme 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 d'une mise aux enchères.

Exemple :

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

Les acheteurs ont trois tâches:

• Indiquez si vous souhaitez participer à une mise aux enchères.
• Choisissez des annonces et calculez une enchère.
• Signalez 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 exécuté lors d'enchères publicitaires de l'API Protected Audience.

Lorsqu'un acheteur demande au navigateur d'un utilisateur d'ajouter un groupe d'intérêt aux groupes dont il est membre (en appelant la méthode fonction JavaScript navigator.joinAdInterestGroup()), l'acheteur fournit au navigateur les éléments suivants:

• URL pour le code d'enchère qui sera utilisée lorsque le vendeur lancera une enchère publicitaire.
• éventuellement les URL des créations correspondant au groupe de centres d'intérêt. Notez que des URL d'annonces peuvent être ajoutées ultérieurement avec 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 générer un rapport sur le résultat de la mise aux enchères.

Qui procède aux enchères publicitaires ?

Plusieurs parties peuvent participer à des enchères pour vendre de l'espace publicitaire.

Exemple :

• Éditeur de contenu: hébergeant le contenu des annonces sur son site Web.
• Plate-forme côté offre (SSP, Supply-Side Platform): collaboration avec l'éditeur et fourniture d'autres services
• Script tiers: il agit pour le compte d'un éditeur afin de permettre la participation aux enchères publicitaires.

Avec l'API Protected Audience, un vendeur d'espaces publicitaires a trois tâches:

• faire respecter les règles des éditeurs, en indiquant quels acheteurs et quelles enchères sont éligibles ;
• Exécuter la logique d'enchères: JavaScript exécuté dans worklets pour calculer une de désirabilité pour chaque enchère.
• Signalez le résultat de la mise aux enchères.

Ces tâches sont effectuées de façon programmatique, dans le code fourni par le vendeur lorsqu'il lance une annonce. en appelant la fonction JavaScript navigator.runAdAuction().

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

Le schéma suivant décrit chaque étape d'une enchère publicitaire de l'API Protected Audience:

</ph> <ph type="x-smartling-placeholder"></ph>

Dans l'API Protected Audience, les enchères publicitaires sont un ensemble de petits programmes JavaScript exécutés par le navigateur pour choisir une annonce. Pour des raisons de confidentialité, l'intégralité du code des enchères publicitaires 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 des espaces publicitaires (comme un site d'actualités ). Le vendeur choisit les acheteurs qui participent à l'enchère. indique l'espace à vendre et fournit des critères supplémentaires pour l'annonce. Chaque acheteur est propriétaire d'un groupe de centres d'intérêt.

Le vendeur fournit au navigateur un code permettant d'évaluer les enchères, qui inclut la valeur de chaque enchère, le création publicitaire et d'autres données renvoyées par chaque acheteur. Pendant la mise aux enchères, des acheteurs, et le code d'évaluation des enchères du vendeur peut recevoir des données Services clé-valeur : Une fois qu'une annonce est choisie et affiché (dans un cadre cloisonné) pour préserver confidentialité), le vendeur et l'acheteur ayant remporté l'enchère peuvent indiquer le résultat de l'enchère.

1. Un utilisateur visite un site où sont diffusées des annonces.
2. Le code du vendeur lance une mise aux enchères. Le vendeur indique quel espace publicitaire et qui peut enchérir, ainsi qu'une méthode pour évaluer les performances de ces enchères.
3. Le code de l'acheteur invité s'exécute pour générer une enchère, l'URL d'une annonce pertinente création et autres données. Le script d'enchères peut interroger des données en temps réel, comme le budget restant de la campagne, à partir de la clé-valeur service.
4. Le code du vendeur évalue chaque enchère et sélectionne une annonce gagnante. Cette logique utilise la valeur d'enchère et d'autres données pour afficher l'envie d'une enchère et refuser une annonce l'annonce contextuelle la plus performante. Le vendeur peut utiliser ses propres Service clé-valeur pour les données en temps réel. Avant une enchère commence, le vendeur trouve l'annonce contextuelle la plus adaptée dans l'espace publicitaire.
5. L'annonce gagnante est renvoyée en tant qu'objet de configuration de frame cloisonné lorsque l'indicateur resolveToConfig est défini dans la configuration de l'enchère. La configuration permet de naviguer dans le cadre cloisonné jusqu'à la création publicitaire, et 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'un URN opaque qui peut être utilisé 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 signalement des pertes d'acheteurs est en cours de discussion.

Qu'est-ce qu'un service clé-valeur 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, consultez les 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 envoyée à un service clé-valeur ne peut pas entraîner 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 dans le service clé-valeur.

Un acheteur ou un vendeur fournit une liste de "clés" pour spécifier les données dont ils ont besoin d'un service clé-valeur de l'API Protected Audience. Le service Clé-valeur répond par 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 le Explication de l'API et la présentation 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 le vendeur peuvent avoir besoin d'accéder aux données en temps réel. données. Par exemple, les acheteurs peuvent calculer le budget restant d'une campagne publicitaire le vendeur peut être tenu de vérifier que les créations publicitaires respectent le règlement pour les é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. Lorsqu'un acheteur appelle la méthode navigator.joinAdInterestGroup(), il spécifie une URL de service clé-valeur et les clés à interroger au cours d'une enchère. De même, lorsque le vendeur lance des enchères publicitaires 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 clé-valeur Open Source de l'API Protected Audience qui s'exécutent dans des environnements d'exécution approuvés pour récupérer des données en temps réel.

Afin de nous assurer que l'écosystème dispose de suffisamment de temps pour effectuer des tests, nous ne prévoyons pas d'exiger l'utilisation des services clé-valeur Open Source ni d'environnements d'exécution sécurisés avant l'abandon des cookies tiers. Nous informerons bien les développeurs qu'ils doivent commencer les tests et l'adoption avant cette transition.

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 une donnée propriétaire.

Dans une mise aux enchères Protected Audience, l'annonceur peut utiliser ses données first party pour déterminer l'appartenance au groupe de centres d'intérêt des annonces. 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 sont disponibles que pour les acheteurs lors de l'étape de génération d'enchères. Elles ne sont pas disponibles pour les vendeurs.

Par exemple, si l'annonceur connaît la couleur préférée de l'utilisateur, cette 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, et 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 manière dont elles doivent être formatées.

L'exemple suivant explique comment l'éditeur peut transmettre les données first party aux 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, consultez la page testez et participez.

Nous avons rédigé un guide du développeur d'API et créé une démonstration de l'API Protected Audience, qui propose un tutoriel de base sur le déploiement 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 montre comment utiliser les outils pour les développeurs Chrome pour déboguer l'API Protected Audience.

Interagir et partager des commentaires

• GitHub: lisez l'explication. poser des questions et suivre la discussion.
• Annonces: rejoignez ou consultez les annonces précédentes sur la liste de diffusion de l'API Protected Audience.
• W3C: discuter de cas d'utilisation sectoriels dans le document Améliorer les activités publicitaires sur le Web Groupe.
• 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 pour les développeurs Privacy Sandbox.
• Implémentation actuelle : si vous avez des questions sur l'implémentation de Protected Audience dans Chrome, signalez un bug Chromium.