Cette page a été traduite par l'API Cloud Translation.

Services d'enchères et de mise aux enchères

Dans la proposition initiale d'audience protégée, les enchères et la mise aux enchères des annonces de remarketing sont exécutées localement sur l'appareil. Cette exigence peut nécessiter des exigences de calcul qui peuvent s'avérer difficiles à exécuter sur des appareils dotés d'une puissance de traitement limitée, ou être trop lentes pour sélectionner et afficher les annonces en raison d'une latence du réseau.

La proposition de services d'enchères et de mise aux enchères (B&A) offre un moyen d'autoriser le calcul d'audiences protégées sur des serveurs cloud dans un environnement d'exécution sécurisé (TEE), plutôt que de l'exécuter localement sur l'appareil d'un utilisateur. Cette proposition vise à permettre un flux unifié pour prendre en compte la demande d'annonces contextuelles et de remarketing. Déplacer des calculs vers des serveurs peut contribuer à optimiser l'enchère d'audiences protégées en libérant des cycles de calcul et une bande passante réseau pour un appareil.

Google fournira les composants des enchères et de mises aux enchères, qui seront mis à disposition en Open Source. Les technologies publicitaires intéressées peuvent héberger leurs propres instances avec des fournisseurs publics de services cloud compatibles. Pour en savoir plus sur cette proposition, consultez GitHub. Notez que les dates indiquées dans ce document reflètent l'implémentation à Chrome. Nous publierons d'autres informations sur l'intégration à Android à l'avenir. Ce document est une introduction aux enchères et aux mises aux enchères. Les nouvelles API Android permettront d'interagir avec ces services. Nous publierons plus d'informations techniques sur l'utilisation de ces nouvelles API dans de futures mises à jour.

Où les services d'enchères et de mise aux enchères se trouvent-ils ?

Les enchères et les mises aux enchères offrent une option supplémentaire pour lancer une mise aux enchères sur des serveurs de confiance appartenant à des technologies publicitaires et exécutant un binaire Open Source fourni par Google. Les données utilisateur sont toujours stockées sur l'appareil et Google fournira des API permettant de déplacer ces données vers le TEE de manière sécurisée. Vous trouverez plus d'informations sur notre stratégie de chiffrement ci-dessous.

Cela signifie que certaines parties du processus d'enchères se déroulent sur l'appareil et d'autres dans le cloud. Du point de vue d'un DSP, les audiences personnalisées (y compris les annonces candidates pour les campagnes de remarketing) sont toujours gérées sur l'appareil à l'aide des mêmes API de gestion des audiences personnalisées que lorsque l'enchère est exécutée sur l'appareil. Du point de vue des SSP, les requêtes sont toujours déclenchées sur l'appareil. Ce document décrit les nouvelles API qui seront utilisées. Pour toutes les parties, le rapport des résultats d'une mise aux enchères commence toujours à partir de l'appareil, une fois l'appel d'enchères et de mise aux enchères terminé.

La principale différence réside dans l'exécution de la logique de génération d'URL d'enchères, d'évaluation et de génération de rapports. Au lieu d'exécuter la logique d'enchères, de mise aux enchères et de création de rapports sur l'appareil, generateBid(), scoreAd(), reportResult() et la logique reportWin() est exécutée dans le TEE. La logique d'enchères de l'acheteur et celle d'évaluation du vendeur sont exécutées dans leur propre environnement d'enchères et de mise aux enchères, au milieu du flux d'enchères Protected Audience :

Illustration montrant le flux d'enchères Protected Audience, et où se situent les enchères et les enchères. — Flux d'enchères Protected Audience

Chiffrement des données

Avec les enchères et la mise aux enchères, les informations de Protected Audience telles que les audiences personnalisées et les montants des enchères sont envoyées depuis l'appareil vers les serveurs de technologie publicitaire du vendeur et de l'acheteur avant de revenir sur l'appareil. De ce fait, la plate-forme chiffre les données envoyées aux services Protected Audience, qui ne peuvent être déchiffrées que par les services certifiés. En savoir plus sur les stratégies de chiffrement sur GitHub.

Architecture et flux d'enchères

Cette proposition nécessite d'avoir plusieurs nouveaux composants détaillés sur GitHub, y compris le flux de données de l'appareil vers les enchères et mises aux enchères.

Illustration représentant le flux unifié d'enchères Protected Audience et contextuelles, décrit ci-dessous. — Ciblage contextuel et unifié Flux d'enchères Protected Audience, avec des services d'enchères et de mise aux enchères

De manière générale, le flux de données est décrit comme suit :

Sur l'appareil, les vendeurs collectent des informations auprès de Protected Audience à l'aide de l'API getAdSelectionData.
Le SDK sur l'appareil envoie une requête aux services publicitaires du vendeur. Cette requête inclut la charge utile contextuelle et le ProtectedAudienceInput chiffré.
Les services publicitaires du vendeur envoient une demande au service d'enchères en temps réel (RTB) des acheteurs, qui ne s'exécute pas dans un TEE, afin d'obtenir des annonces contextuelles candidates, puis d'évaluer et de sélectionner une annonce contextuelle gagnante.
Les services publicitaires du vendeur envoient une requête à leurservice SellerFrontEnd qui s'exécute dans un TEE.
Le service SellerFrontEnd envoie des requêtes contenant des données spécifiques à l'acheteur aux services BuyerFrontEnd.
Les acheteurs utilisent leurs propres service clé-valeur et services d'enchères, qui génèrent des enchères pour les annonces candidates provenant de l'appareil pour toutes les audiences personnalisées envisagées pour le remarketing.
Le service SellerFrontEnd lit les données à partir de son service clé-valeur et attribue un score aux annonces candidates. Le résultat est chiffré et renvoyé aux services publicitaires du vendeur.
Les services publicitaires du vendeur renvoient le résultat chiffré gagnant, et éventuellement un résultat contextuel, au SDK sur l'appareil.
Sur l'appareil, les vendeurs récupèrent l'annonce gagnante à l'aide de l'API processAdSelectionResult, qui déchiffre la réponse des services publicitaires du vendeur.

Une description détaillée de chaque étape et du chiffrement des données est disponible sur GitHub. Le code de ces composants sera mis à disposition en Open Source. Le code fourni pourra gérer la fédération des requêtes du service SellerFrontEnd vers les services BuyerFrontEnd.

Déploiement dans le cloud

Les technologies publicitaires déploieront les services d'enchères et de mise aux enchères sur une plate-forme de cloud public compatible. Ces déploiements doivent être gérés par les technologies publicitaires chargées de définir un objectif de niveau de service de disponibilité.

Mise aux enchères

La première étape des enchères et des mises aux enchères consiste à collecter les données provenant des audiences personnalisées sur l'appareil et à les chiffrer pour les envoyer aux enchères côté serveur. Pour ce faire, utilisez l'API getAdSelectionData.

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

La méthode getAdSelectionData génère les entrées requises pour les composants d'enchères et de mise aux enchères, tels que BuyerInput et ProtectedAudienceInput, puis chiffre les données avant de rendre le résultat accessible à l'appelant. Pour éviter toute fuite de données entre les applis, ces données contiennent les informations de tous les acheteurs présents sur l'appareil. Pour en savoir plus sur cette décision, consultez la section Considérations liées à la confidentialité.

Cette API renvoie un objet AdSelectionData :

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

À l'aide des AdSelectionData, le SDK sur l'appareil peut envoyer une requête aux services publicitaires de son vendeur en incluant les données dans une requête POST ou PUT :

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

Le SDK sur l'appareil est responsable de l'encodage de ces données. Nous vous recommandons d'utiliser une solution légère, telle que l'envoi de la requête aux services publicitaires du vendeur en tant que multipart/form-data.

Une fois la requête envoyée, les services publicitaires du vendeur la transmettent au service SellerFrontEnd exécuté dans un TEE. Lors de la configuration d'un service SellerFrontEnd, les vendeurs fournissent une liste d'adresses de domaine correspondant aux services BuyerFrontEnd gérés par les acheteurs avec lesquels le vendeur est associé. Les requêtes seront fédérées aux différents services BuyerFrontEnd fournis par le vendeur, afin que les acheteurs puissent générer des enchères pour leurs annonces candidates sélectionnées. Pour un acheteur spécifique, les enchères et mises aux enchères n'enverront que des informations sur les audiences personnalisées appartenant à l'acheteur afin qu'il n'y ait pas de fuite des données entre les acheteurs. Une fois les enchères générées, la liste des annonces candidates est renvoyée au service SellerFrontEnd, où un gagnant est sélectionné. Enfin, le service SellerFrontEnd renvoie l'annonce gagnante chiffrée à l'appareil.

Avec la réponse de la requête aux services publicitaires du vendeur à nouveau sur l'appareil, la plate-forme propose une deuxième API pour déchiffrer le résultat et fournir un AdSelectionOutcome, le même objet renvoyé par un une mise aux enchères le même jour.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

Rapports

Les URL de rapport seront générées dans les services d'enchères et de mise aux enchères. Les pings vers ces URL de rapport sur les impressions et les interactions pour les enchères devront toujours être déclenchés sur l'appareil. Le SDK sur l'appareil devra toujours appeler les API reportImpression() et reportInteraction() à l'aide d'AdSelectionId généré pendant le flux d'enchères et de mise aux enchères. Les balises générées pour les rapports sur les interactions et les URL correspondantes sont contenues dans la réponse chiffrée. Par conséquent, lors du déchiffrement de la réponse, les événements et les mappages d'URL sont stockés sur l'appareil.

Considérations liées à la confidentialité

La proposition de l'API Browser Bidding & Auction sur GitHub décrit la façon dont la confidentialité est prise en compte. Cette proposition utilise la nomenclature de Chrome, mais les mêmes principes s'appliquent à Android.

adSelectionData est chiffré pour que les données en transit ne soient accessibles qu'aux API protégeant la confidentialité et aux serveurs de confiance. Pour réduire le risque de fuite de données liées à des changements de taille de adSelectionData, nous prévoyons de générer les mêmes adSelectionData pour tous les appels à l'API getAdSelectionData. Cela implique que toutes les CustomAudience de l'appareil soient utilisées pour créer adSelectionData. Nous prévoyons également de limiter l'influence des paramètres d'entrée GetAdSelectionData sur les adSelectionData générées.

La génération des mêmes adSelectionData pour toutes les technologies publicitaires à l'aide de toutes les données d'enchères sur l'appareil entraîne une charge utile plus élevée qui doit être transférée à chaque appel au serveur de technologie publicitaire, tout en ouvrant potentiellement aux abus de la part d'entités malveillantes. Ces problèmes sont abordés dans les sections Considérations liées à la taille et Considérations contre les abus ci-dessous.

Considérations liées à la taille

Le SDK du client de technologie publicitaire doit empaqueter les octets chiffrés d'adSelectionData dans un appel pour les annonces contextuelles effectuées sur le serveur du vendeur. Pour des performances optimales, il est important d'optimiser la taille d'adSelectionData sans compromettre les fonctionnalités. Nous prévoyons d'introduire des optimisations, comme indiqué dans l'explication sur l'optimisation de la charge utile, afin de réduire la taille de adSelectionData. Ces optimisations incluent les éléments suivants :

Ajout d'ad_render_id dans CustomAudience pour qu'il soit envoyé à l'aide d'adSelectionData au lieu d'utiliser l'URI et les métadonnées de rendu d'annonce. Les technologies publicitaires peuvent optimiser ce processus en n'envoyant pas de données publicitaires dans adSelectionData. Cette option sera compatible avec CustomAudience API dans les futures versions.
Assurez-vous que les user_bidding_signals ne sont pas envoyés dans adSelectionData. À la place, les technologies publicitaires peuvent récupérer user_bidding_signals depuis leur serveur clé-valeur.
Autorisez les acheteurs à donner la priorité à CustomAudience.
Autorisez l'acheteur à spécifier la priorité du vendeur.
Générez adSelectionData dans quelques buckets fixes pour limiter les fuites de bits tout en réduisant la taille de la charge utile.

Des optimisations de la taille seront effectuées tout en respectant les préoccupations liées à la confidentialité.

Considérations contre les abus

Comme indiqué dans les considérations liées à la confidentialité, adSelectionData est généré à l'aide de toutes les données de l'acheteur sur l'appareil.

Cela ouvre l'écosystème à de potentielles entités malveillantes susceptibles d'ajouter des données frauduleuses d'acheteurs qui pourraient dégrader les performances, surcharger les charges utiles afin d'augmenter les coûts, etc.

Pour lutter contre les utilisations abusives d'adSelectionData, les mesures suivantes seront prises :

Autorisez CustomAudience à spécifier explicitement les vendeurs approuvés et leur priorité.
Autorisez les SSP à spécifier explicitement l'acheteur, la priorité de l'acheteur et le quota par acheteur dans la charge utile générée.
Fournissez aux SSP un mécanisme définissant un nombre maximal d'acheteurs par appel ou une taille maximale par acheteur.

Ces mesures sont conçues pour permettre aux technologies publicitaires de définir les autres technologies publicitaires avec lesquelles elles collaborent et de définir des limites acceptables pour la charge utile adSelectionData à traiter. Nous proposons au vendeur de spécifier la liste des acheteurs et la priorité dans un appel distinct. Cette spécification est constante pendant un certain temps pour éviter d'exposer des données supplémentaires sur l'utilisateur via des appels répétés.

Les mesures d'atténuation mentionnées ci-dessus sont en cours de discussion et peuvent évoluer au fil du temps. Comme indiqué précédemment, toutes les mesures d'atténuation mises en place pour lutter contre les abus, ainsi que les restrictions de taille, doivent respecter les considérations liées à la confidentialité.