API Protected Audience : guide d'intégratione

L'API Protected Audience (anciennement FLEDGE) sur Android implique généralement l'intégration entre les applications des annonceurs, les applications de l'éditeur, les vendeurs et les acheteurs. Ce guide est destiné aux partenaires qui envisagent de gérer des audiences personnalisées et de lancer des enchères, y compris les réseaux ad tech qui fonctionnent à la fois comme acheteurs et comme vendeurs. Les campagnes publicitaires peuvent avoir des objectifs différents. De plus, les fonctionnalités de l'API Protected Audience ne sont pas toutes utilisées dans tous les cas d'utilisation. Dans ce guide, nous essayons de souligner les étapes nécessaires pour prendre en charge des cas plus particuliers dans la mesure du possible.

Pour se préparer au déploiement à grande échelle de l'API Protected Audience, les partenaires peuvent commencer les tests par une simulation des points d'intégration avec d'autres parties. Pour vous aider à planifier l'intégration, ce guide vous explique en détail comment intégrer l'API Protected Audience à vos applications Android. Il peut y être question de fonctionnalités qui ne sont pas encore implémentées au stade actuel de la Privacy Sandbox dans la preview développeur d'Android. Dans ce cas, une estimation de leur disponibilité est donnée.

Le workflow d'intégration de l'API Protected Audience se compose de quatre étapes clés, gérées par différents types de partenaires ad tech :

  1. L'acheteur crée des audiences personnalisées.
  2. Le processus de sélection des annonces choisit l'annonce gagnante.
    1. L'application du vendeur lance la sélection des annonces.
    2. Les services publicitaires appliquent un code d'enchères et de filtrage côté achat.
    3. Les services publicitaires exécutent un code de décision côté vente.
  3. L'annonce gagnante s'affiche dans l'application du vendeur.
  4. Les rapports sur les impressions d'annonce sont mis à la disposition de l'acheteur et du vendeur.

Le schéma suivant illustre ces étapes :

Schéma du workflow de sélection des annonces.
Workflow de sélection des annonces et de gestion des audiences personnalisées de l'API Protected Audience

Terminologie

  • Annonceur : entreprise qui interagit avec les utilisateurs via l'achat d'un inventaire publicitaire.
  • Éditeur : entreprise qui vend un inventaire publicitaire disponible, avec son contenu.
  • Acheteur : société ad tech qui aide les annonceurs à acheter des inventaires publicitaires.
  • Vendeur : société ad tech qui aide les éditeurs à vendre des inventaires publicitaires.
  • Réseau : société ad tech agissant à la fois en tant qu'acheteur et que vendeur.
  • Détenue et gérée : entreprise agissant en tant qu'éditeur, vendeur et acheteur.
  • Partenaires d'intégration : toute entreprise avec laquelle vous devez collaborer pour réussir l'intégration de l'l'API Protected Audience.

Conditions préalables, engagement des partenaires d'intégration et configuration

Cette section décrit un ensemble d'activités initiales afin que vous compreniez mieux comment fonctionne l'API Protected Audience, comment faire vos premiers pas avec son intégration et comment interagir avec vos partenaires d'intégration concernant son implémentation. Ces activités peuvent se dérouler en parallèle.

Schéma illustrant le guide de déploiement des fonctionnalités de l'API Protected Audience
Guide de déploiement des fonctionnalités de l'API Protected Audience

Se familiariser avec Protected Audience

La première étape consiste à vous familiariser avec les API et les services Protected Audience.

  1. Commencez par lire la proposition de conception pour vous familiariser avec l'API Protected Audience et ses fonctionnalités.
  2. Consultez le guide du développeur pour découvrir comment intégrer le code et les appels d'API dont vous avez besoin pour vos cas d'utilisation, ainsi que les services requis pour l'intégration à l'API Protected Audience.
  3. Envoyez vos commentaires sur la conception et l'implémentation des API, des services et de la documentation de l'API Protected Audience
  4. Inscrivez-vous pour être informé des dernières fonctionnalités de la Privacy Sandbox.

Configurer et tester des applications exemples

Une fois que vous vous êtes familiarisé avec les principes de base de l'API Protected Audience indiqués précédemment, vous devez configurer et tester les applications exemples.

  1. Lorsque vous êtes prêt à commencer l'intégration, configurez votre environnement de développement avec la dernière version de Privacy Sandbox (preview développeur).
  2. Configurez les points de terminaison de serveur requis. Utilisez les exemples de simulation avec la solution de test d'API de votre choix pour amorcer ce processus.
  3. Dupliquez et exécutez le code de notre exemple d'application pour vous familiariser avec la gestion d'audience personnalisée, le workflow de sélection des annonces et la création de rapports sur les impressions.

Engagement des partenaires d'intégration

Planifiez des discussions avec vos partenaires d'intégration pour parler des tests et de l'adoption de l'API Protected Audience sur Android, y compris la forme des signaux transmis entre les parties. Pour les acheteurs, les discussions doivent entre autres porter sur les stratégies permettant de créer et de rejoindre des audiences personnalisées, ainsi que sur la définition des audiences éventuellement. Définissez avec vos partenaires d'intégration les délais d'intégration, depuis les premiers tests jusqu'à l'adoption, et identifiez ensemble les domaines de la conception dont chaque partie sera responsable.

Configuration bêta (disponible au 4e trimestre)

Inscrivez votre organisation auprès de la Privacy Sandbox sur Android. L'inscription est nécessaire pour s'assurer que les développeurs ad tech respectent les règles de la Privacy Sandbox et puissent définir leur identité dans plusieurs SDK et domaines.

Considérations relatives à l'architecture

Pour les acheteurs comme pour les vendeurs, l'API Protected Audience permet de lancer des enchères publicitaires sur l'appareil. Vous et vos partenaires d'intégration devez tenir compte de plusieurs éléments critiques dans vos conceptions :

Les audiences et les annonces de remarketing sont stockées sur l'appareil

Contrairement aux annonces qui sont aujourd'hui entièrement stockées sur des serveurs, les informations sur l'audience et les annonces de remarketing sont stockées sur l'appareil. Les annonces contextuelles qui ne s'appuient pas sur les données stockées sur l'appareil pour le ciblage doivent rester sur les serveurs. Les plates-formes de technologie publicitaire doivent évoluer pour tenir compte de la répartition de la demande d'annonces entre les serveurs et les appareils.

Les processus d'enchères ont lieu sur l'appareil

Outre la mise aux enchères sur les serveurs, les plates-formes de technologie publicitaire ont désormais la possibilité de fixer un prix à la demande d'annonce stockée sur l'appareil et de la noter.

Une approche courante consiste pour les sociétés ad tech à mettre aux enchères les annonces contextuelles comme elles le font aujourd'hui. Une fois l'enchère terminée, le vendeur peut choisir de lancer une mise aux enchères sur l'appareil afin d'évaluer la demande de remarketing stockée sur l'appareil. Étant donné que ces processus s'exécutent désormais sur l'appareil, il est important de garder en tête les limites existantes pour s'assurer que la mise aux enchères se déroule intégralement, tel que prévu par les différents partenaires d'intégration, dans divers cas de remarketing.

Stratégie de données

Les plates-formes de technologie publicitaire doivent tenir compte des types de données utilisés lors des enchères. Aujourd'hui, ces informations sont recueillies à partir de diverses sources, puis centralisées sur un serveur. Les enchères de l'API Protected Audience offrent plusieurs méthodes pour transmettre ces données. Par exemple, les signaux en temps réel tels que le budget restant proviennent d'un service clés-valeurs et sont utilisés comme signaux de confiance, tandis que les signaux de contexte tels que l'heure de la journée sont envoyés par les vendeurs lors de la mise aux enchères. Ces signaux sont expliqués en détail dans les sections correspondantes de ce guide.

Créer votre solution

Une mise aux enchères avec l'API Protected Audience comporte plusieurs étapes clés. Les acheteurs doivent créer une audience, fournir des données d'enchères, cibler des audiences avec les annonces et configurer les enchères. Le vendeur doit configurer et déclencher la mise aux enchères, évaluer les annonces candidates, et sélectionner une annonce gagnante. Certaines de ces étapes nécessitent une collaboration entre les deux parties pour garantir le bon déroulement de l'enchère. Les sections suivantes décrivent chaque étape en détail et indiquent explicitement la partie responsable de l'implémentation.

Acheteurs : créer une audience

Les acheteurs gèrent généralement des audiences personnalisées. Comme celles-ci sont gérées sur l'appareil, l'API permettant de les gérer est conçue pour être appelée sur l'appareil.

Si votre propre SDK est présent dans l'application des annonceurs, vous pouvez implémenter ce code directement via joinCustomAudience().

Si vous n'avez pas votre propre code SDK sur les appareils, vous pouvez envisager de collaborer avec un partenaire d'intégration existant qui est également fournisseur de SDK. Identifiez avec ce partenaire et collaborez avec lui pour établir un contrat et convenir d'un flux de définition et de gestion des audiences personnalisées Ce guide utilise le terme "acheteur" quelle que soit l'approche choisie. Voici quelques exemples d'approches :

  • En tant qu'acheteur, demandez à l'annonceur de définir l'audience. Un SDK de partenaire d'intégration sur l'appareil peut envoyer des événements d'application à l'acheteur. Lorsque les critères prédéfinis sont remplis, l'acheteur envoie un message au SDK afin de rejoindre l'audience personnalisée sur le client pour le compte de l'acheteur.
  • Le SDK peut détenir directement l'audience. Les annonceurs font appel à un fournisseur de SDK pour définir l'audience. Le SDK surveille les événements d'application, rejoint l'audience au moment opportun et informe l'acheteur qu'un utilisateur a rejoint l'audience.

Prototypage de campagne de remarketing : créer une audience personnalisée

Une audience personnalisée est un groupe d'utilisateurs ayant des centres d'intérêt similaires qui peuvent voir des annonces personnalisées. Les acheteurs peuvent aider les annonceurs à créer des audiences personnalisées dans leurs applications en fonction de l'activité des utilisateurs.

L'API Protected Audience établit un conteneur pour l'audience personnalisée correspondant à un engagement utilisateur personnalisé défini par l'annonceur. Cela inclut un ensemble d'annonces candidates qui peuvent être diffusées auprès de cette audience, ainsi qu'un ensemble de données et de logiques d'enchères personnalisées qui peuvent être utilisées lors d'une mise aux enchères pour filtrer les annonces et en fixer le prix.

Configuration et prototypage

  • Utilisez l'API d'audience personnalisée pour créer et stocker une audience sur l'appareil, que vous pourrez ensuite utiliser lors d'une enchère.
  • Consultez le guide du développeur pour en savoir plus sur l'implémentation et l'utilisation de l'API.

Considérations de conception

Les acheteurs peuvent configurer des audiences personnalisées pour prendre en charge divers cas d'utilisation. Cela implique de définir la logique d'enchères pour le type d'annonce ou de campagne qui cible cette audience, de définir la liste des annonces candidates et d'autres considérations similaires. Cette section présente les éléments à prendre en compte pour le remplissage et l'utilisation de certains champs clés dans une audience personnalisée.

URL de logique d'enchères

Étant donné que les enchères sont exécutées sur l'appareil, les acheteurs doivent déployer un point de terminaison pouvant renvoyer une logique d'enchères au format JavaScript. Notre guide du développeur décrit les signatures de méthode requises. La logique d'enchères a accès à certains signaux concernant l'utilisateur lors de l'enchère, comme décrit dans les sections suivantes. La configuration de la logique d'enchères et des signaux utilisateur est expliquée plus loin dans cet article.

Signaux d'enchères de l'utilisateur

Les acheteurs peuvent utiliser UserBiddingSignals pour transmettre les informations que l'annonceur ou l'acheteur lui-même possèdent au sujet de l'utilisateur lors des futures enchères sur l'appareil. Exemples d'informations incluses :

  • Autres audiences auxquelles l'utilisateur a été ajouté
  • Informations propriétaires que l'annonceur possède sur l'utilisateur

Étant donné que ces signaux sont disponibles pendant l'enchère, les acheteurs peuvent effectuer des opérations d'enchères personnalisées pendant l'enchère, par exemple :

  • Augmenter ou diminuer les enchères en fonction de signaux d'enchères
  • Exclure certaines annonces de l'enchère

Données d'enchères de confiance

Dans le cadre de l'implémentation de l'API Protected Audience, les acheteurs peuvent accéder à des informations en temps réel pendant l'enchère depuis un service clés-valeurs. Comme mécanisme temporaire, l'acheteur et le vendeur peuvent récupérer ces signaux d'enchères à partir de n'importe quel service, y compris celui qu'ils exploitent eux-mêmes. L'exemple le plus courant consiste à rechercher le budget restant pour les annonces. Pendant le développement, il est possible de simuler ce service, puis vous de servir de cette simulation de point de terminaison dans votre développement. Pour les instructions de configuration, consultez le répertoire FledgeServerSpec dans notre dépôt d'applications exemples sur GitHub.

Le champ TrustedBiddingData se compose d'une URL et d'un ensemble de clés. Voici quelques éléments à prendre en compte lorsque vous concevez le type de structure de clés à utiliser :

  • Une approche simple consiste à inclure une clé qui se mappe un à un à l'audience que vous créez. Le service clés-valeurs peut alors contenir toutes les informations pertinentes associées à l'audience.
  • Il est important de tenir compte en temps réel du budget et de l'état des annonces.
  • Vous pouvez utiliser le montant maximal de l'enchère ou d'autres signaux pour définir le prix d'une annonce lors d'une enchère. Vous pouvez inclure ces informations avec l'annonce dans une liste AdData, mais les stocker dans un service clés-valeurs permet de les mettre à jour plus facilement si nécessaire.

Liste AdData

Lorsqu'ils créent une campagne de remarketing, les annonceurs envisagent généralement de nombreux types d'annonces à diffuser auprès d'un utilisateur d'une audience, par exemple des remises différentes en fonction de l'engagement antérieur des utilisateurs avec l'application. Une audience personnalisée inclut une liste AdData qui contient les annonces candidates.

L'acheteur est libre de décider de la quantité d'informations à inclure pour chaque annonce. Vous devez prendre certains points en compte :

  • Vous pouvez mettre à jour la liste AdData de deux manières :
    • Lorsque l'application présente une activité visible au premier plan, elle peut lancer la liste lorsqu'elle ajoute un utilisateur à une audience personnalisée.
    • Lors d'une mise à jour quotidienne, la récupération s'effectue en arrière-plan. L'appareil envoie une requête au daily_update_url inclus dans l'appel joinCustomAudience et attend une réponse incluant la liste AdData mise à jour.
  • Vous pouvez demander des informations supplémentaires sur les annonces à tout moment de l'enchère. Avant l'enchère, l'appareil envoie une requête au service clés-valeurs de l'acheteur indiqué dans le champ trustedBiddingData de joinCustomAudience. Le service clés-valeurs est un nouveau service qui fait partie de l'implémentation de l'API Protected Audience pour les acheteurs. Vous trouverez plus d'informations sur ce service plus loin dans ce document.
  • L'ajout d'un ID de création à votre annonce peut vous aider à effectuer certaines actions sur des créations spécifiques. Par exemple, les annonceurs peuvent mettre en pause des créations spécifiques, et vous pouvez extraire ces ID de création du service clés-valeurs en temps réel, puis les associer aux annonces de la liste AdData.

AdData doit inclure un render_url. L'URL de rendu de l'annonce de remarketing gagnante permet d'afficher l'annonce. Points à prendre en compte :

  • L'URL de rendu présente un seuil de k-anonymat. Par conséquent, évitez d'inclure des paramètres restreints. Des informations supplémentaires sur ce seuil de k-anonymat seront publiées ultérieurement.
  • Cette URL doit contenir toutes les informations nécessaires pour afficher l'annonce. Par exemple, si vous souhaitez afficher des produits spécifiques, intégrez les ID produit en tant que paramètres dans l'URL.

Lors du prototypage, le seul champ obligatoire est le champ renderUri, qui pointe vers les éléments de rendu de l'annonce. Le champ de métadonnées dans AdData peut être ignoré lorsque vous créez votre solution. Lorsque vous passez votre solution en production, vous devez réfléchir aux métadonnées pertinentes dans votre cas, car elles peuvent être utilisées lors de la génération des enchères pour ajuster le prix de vos enchères.

Heure d'activation et d'expiration

Vous pouvez utiliser les champs d'heure d'activation et d'expiration si une audience personnalisée ne doit être éligible à une enchère que pendant une période prédéfinie. Sachez qu'il existe certaines limites au report de l'heure d'activation et au delta entre l'heure d'activation et l'heure d'expiration. Voici quelques exemples de cas d'utilisation :

  • Ancien utilisateur (par exemple, un utilisateur qui n'a pas interagi avec l'application de l'annonceur au cours des sept derniers jours)
    • Chaque fois que l'utilisateur ouvre l'application, l'acheteur peut appeler joinCustomAudience et configurer activation_time de sorte qu'il corresponde à un horodatage sept jours plus tard.
    • L'audience est éligible aux enchères si l'utilisateur n'a pas ouvert l'application depuis sept jours.
  • Audience saisonnière (audience valide uniquement dans un intervalle de temps spécifique, dans un avenir proche)
    • Un acheteur peut définir à l'avance des audiences personnalisées qui ne seront éligibles à des enchères que pendant une période prédéterminée dans un avenir proche.
    • Par exemple, si un annonceur organise une campagne de fin d'été aux États-Unis en 2022, son acheteur peut appeler joinCustomAudience et définir activation_time sur le samedi 20 août 2022. Si la campagne n'est diffusée que pendant une semaine, l'acheteur peut définir la date d'expiration au 27 août 2022. Passée cette date, l'audience personnalisée sera exclue par la plate-forme lors de la sélection des annonces, puis la mémoire occupée par l'audience sera récupérée.

Acheteurs et vendeurs : sélection des annonces

La sélection des annonces nécessite une collaboration entre les acheteurs et les vendeurs. Ce processus comporte quatre étapes :

  1. Les vendeurs définissent une stratégie de médiation.
  2. Les vendeurs configurent l'enchère et lancent la sélection des annonces.
  3. Les acheteurs sont invités à participer à l'enchère via la configuration définie par le vendeur. La logique d'enchères de l'acheteur s'exécute pour sélectionner une annonce candidate et une enchère.
  4. La logique de décision des vendeurs est exécutée pour noter les candidats et sélectionner une annonce gagnante.

Pour faciliter le développement, il est possible de simuler les réponses du service pour les acheteurs et les vendeurs, y compris la logique d'enchères et de notation. Vous pouvez ainsi vous concentrer sur le développement de ce qui est pertinent pour votre cas d'utilisation. Consultez le répertoire FledgeServerSpec sur GitHub pour savoir comment configurer la simulation de points de terminaison, ou le guide du développeur pour savoir comment contourner la récupération JavaScript à distance.

Vendeurs : définir une stratégie de médiation

L'API Protected Audience est compatible avec la médiation en cascade. Cette section est en cours de développement, et d'autres informations vous seront fournies lorsqu'elles seront disponibles. Pour l'instant, reportez-vous à la proposition de conception spécifique à la médiation en cascade dans l'API Protected Audience.

Vendeurs : configurer l'enchère

Les vendeurs sont chargés de configurer l'enchère et de fournir des informations au processus de sélection d'annonces. Les vendeurs peuvent choisir de rendre les informations accessibles à toutes les parties, ou seulement à certaines d'entre elles. Cela peut inclure les informations que vous possédez ou que vous incluez pour le compte d'acheteurs.

Configuration et prototypage

  • Un vendeur peut configurer et lancer une mise aux enchères en configurant un objet AdSelectionConfig et en utilisant l'API AdSelection. Déclenchez la mise aux enchères en appelant selectAds().
  • Consultez le guide du développeur pour en savoir plus sur l'implémentation et l'utilisation de l'API.

Considérations de conception

Cette section présente les éléments à prendre en compte pour le remplissage et l'utilisation de certains champs clés dans une configuration de sélection d'annonces.

  • L'environnement d'exécution privé n'inclut que des annonces d'audience personnalisée sur l'appareil. L'émission préalable d'une demande d'annonce contextuelle vous permet donc d'envisager une demande supplémentaire.

  • Avant de lancer le workflow de sélection d'annonces, exécutez une demande d'annonce pour recueillir des informations auprès des acheteurs. Utilisez ensuite ces informations pour configurer la sélection des annonces.

  • Étant donné que de nombreux acheteurs peuvent avoir créé des audiences personnalisées sur l'appareil, les vendeurs doivent utiliser le champ Acheteurs d'audiences personnalisées pour indiquer les acheteurs spécifiques à inclure dans le processus. Il existe de nombreuses façons de créer cette liste. Voici quelques exemples :

    • Liste statique d'acheteurs que le vendeur souhaite inclure systématiquement dans le processus.
    • Liste d'acheteurs indiquant vouloir participer à leur réponse d'annonce. Cette option est utile si le vendeur travaille avec des places de marché et ne connaît peut-être pas tous les acheteurs.

  • Le vendeur peut transmettre des informations au processus de différentes manières :

    • Le champ Signaux de sélection d'annonces est disponible pour tous les acheteurs et le vendeur qui participent à l'enchère dans l'environnement d'exécution privé. Utilisez-le pour fournir des informations sur l'opportunité d'annonce, comme la taille et le format de l'annonce.
    • Le champ Signaux de l'acheteur est transmis à un acheteur spécifique pour être utilisé dans son processus d'enchères. Ces informations sont fournies par l'acheteur, et vous devez, en tant que vendeur, déterminer comment les obtenir sur votre appareil afin de les utiliser lors de la sélection des annonces.
    • Le champ Signaux du vendeur est le dernier moyen pour le vendeur de transmettre des informations au processus. En tant que vendeur, utilisez ces signaux pour évaluer et filtrer les annonces, par exemple pour activer un contrôle de brand safety.

Acheteurs : enchères pour un espace publicitaire

Configuration et prototypage

  • Un acheteur peut ajouter sa logique d'enchères à la fonction JavaScript generateBid() qui est diffusée à partir du jeu de paramètres biddingLogicUrl lors de la création d'une CustomAudience. Vous pouvez configurer un service fictif en suivant la spécification fournie ou implémenter ce point de terminaison sur un serveur réel.
  • Consultez le guide du développeur pour en savoir plus sur l'implémentation et l'utilisation de l'API.

Considérations de conception

  • La logique d'enchères s'exécute sur l'appareil, et certains signaux utilisés lors de l'enchère sont interrogés en temps réel. Pour connaître les contraintes, consultez la liste des limitations.
  • Pour certains cas d'utilisation d'annonces, il est important de collaborer avec le vendeur pour vous assurer que plusieurs annonces, avec leurs enchères, sont prises en compte sur l'appareil.

Concevoir la logique d'enchères

La logique d'enchères des acheteurs doit être implémentée via JavaScript et exécutée sur l'appareil. Le guide du développeur contient des informations sur la signature requise ainsi que sur les différents paramètres transmis lors de l'enchère. Votre logique d'enchères sur l'appareil a accès à des informations supplémentaires, transmises en tant que paramètres à votre fonction generateBid().

Fournir les données d'enchères

Signaux d'enchères en temps réel avec des services clés-valeurs

En tant qu'acheteur, vous pouvez récupérer des signaux en temps réel lors d'une enchère à partir d'un service clés-valeurs que vous possédez. Vous trouverez une implémentation initiale de ce service dans le dépôt Privacy Sandbox public. Vous pouvez également créer le vôtre. L'URL de ce service est spécifiée en tant que trustedBiddingUrl dans une audience personnalisée. La plate-forme tente de récupérer les données et de les rendre accessibles à votre fonction generateBid à l'aide de trusted_bidding_signals parameter. Vous devez établir votre propre structure de clés.

Signaux utilisateur et de contexte

Votre fonction generateBid a accès à des signaux utilisateur supplémentaires lors d'une enchère sur l'appareil. Ces signaux sont transmis avec les champs contextual_signals et per_buyer_signals. Ces champs sont tous des objets JSON dont le format doit être défini par les acheteurs et les vendeurs.

Le champ contextual_signals inclut des informations sur l'utilisateur qui peuvent être pertinentes. L'objet contenant ces signaux est créé par l'API Protected Audience elle-même et transmis à votre logique d'évaluation. Ce champ est actuellement transmis en tant qu'objet vide. Si vous pensez qu'un signal de contexte concernant l'utilisateur pourrait être pertinent pour votre cas d'utilisation, envoyez un commentaire.

Vous pouvez utiliser le champ per_buyer_signals pour votre logique d'enchères. Un vendeur définit ces valeurs lorsqu'il configure la mise aux enchères. Les acheteurs et les vendeurs doivent collaborer pour s'assurer que ces données se trouvent sur l'appareil et transmises à votre logique d'enchères. Voici quelques exemples d'utilisation de ce champ :

  • Filtrage pour la brand safety. Le vendeur peut fournir à l'acheteur certaines informations de classification concernant l'application qui demande une annonce. L'acheteur peut utiliser ces informations pour filtrer certaines annonces.
  • Envoi d'une représentation vectorielle continue pour un modèle de ML qui prend en compte les informations contextuelles

Vendeurs : noter les annonces et sélectionner l'annonce gagnante

Configuration et prototypage

  • Un vendeur peut ajouter sa logique d'évaluation à la fonction JavaScript scoreAd() diffusée à partir du jeu de paramètres scoringLogicUrl lors de la création de AdSelectionConfig. Vous pouvez configurer un service fictif en suivant la spécification fournie ou implémenter ce point de terminaison sur un serveur réel.
  • Consultez le guide du développeur pour en savoir plus sur l'implémentation et l'utilisation de l'API.

Concevoir la logique d'évaluation

Les vendeurs implémentent une logique d'évaluation en JavaScript, qui est exécutée sur l'appareil. Le guide du développeur contient des informations sur la signature requise ainsi que sur les différents paramètres transmis lors de l'enchère. De plus, votre logique d'évaluation sur l'appareil a accès à des informations supplémentaires, transmises en tant que paramètres à votre fonction scoreAd.

Fournir les données d'évaluation

Signaux d'évaluation en temps réel avec des services clés-valeurs

En tant que vendeur, vous pouvez récupérer des signaux en temps réel lors d'une enchère à partir d'un service clés-valeurs que vous possédez. Vous trouverez une implémentation initiale de ce service dans le dépôt Privacy Sandbox public. L'URL de ce service est spécifiée en tant que trustedScoringUri dans la configuration de l'enchère. La plate-forme tente de récupérer les données et de les rendre accessibles à votre fonction scoreAd à l'aide de trusted_scoring_signals. Vous devez établir votre propre structure de clés.

Signaux utilisateur et de contexte

Votre fonction scoreAd a accès à des signaux utilisateur supplémentaires lors d'une enchère sur l'appareil. Ces signaux sont transmis à votre fonction d'évaluation via le champ contextual_signal. Ce champ contient des objets JSON dont le format est défini par les acheteurs et les vendeurs.

Le champ contextual_signal inclut des informations contextuelles sur l'utilisateur qui peuvent être pertinentes. L'objet contenant ces signaux est créé par l'API Protected Audience elle-même et transmis à votre logique d'évaluation. Ce champ est actuellement transmis en tant qu'objet vide. Si vous pensez qu'un signal concernant l'utilisateur pourrait être pertinent pour votre cas d'utilisation, envoyez un commentaire.

Vendeurs : afficher une annonce

Les vendeurs doivent afficher l'annonce gagnante. Reportez-vous à la proposition de conception pour plus d'informations sur la façon dont les annonces gagnantes sont affichées. Cette section est toujours en cours de conception.

Résultats du rapport sur les impressions

Configuration et prototypage

  • Les acheteurs et les vendeurs peuvent ajouter une logique de création de rapports à la fonction JavaScript reportWin() qui est diffusée à partir du paramètre biddingLogicUrl ou scoringLogicUrl, respectivement. Vous pouvez configurer un service fictif en suivant la spécification fournie ou implémenter ce point de terminaison sur un serveur réel.
  • Consultez le guide du développeur pour en savoir plus sur l'implémentation et l'utilisation de l'API.

Considérations de conception

Les acheteurs et les vendeurs doivent implémenter une fonction reportWin dans leur code JavaScript renvoyé par leurs points de terminaison configurés. Cette méthode vous permet de renvoyer des données à vos serveurs.

Privacy Sandbox propose également une API Attribution Reporting pour gérer les rapports au niveau des événements et les rapports globaux. Pour en savoir plus, consultez le guide d'intégration.