Réponses aux questions fréquentes sur les API de pertinence et de mesure de la Privacy Sandbox.
Quelle est la différence entre Topics et les audiences définies par le vendeur ?
Les thèmes Topics et les SDA fournissent des types d'informations complémentaires et sont contrôlés par l'éditeur. Nous ne pensons pas qu'ils sont en concurrence. Ils fonctionnent côte à côte ou dans des contextes différents pour maximiser les opportunités d'achat. Les acheteurs prennent en compte et utilisent de nombreux signaux lors de l'évaluation programmatique des impressions, et Topics devrait être l'un de ces éléments à prendre en compte. Historiquement, les vendeurs n'incluent pas de segments d'audience dans les enchères sur les places de marché ouvertes. Il est donc probable que Topics soit utilisé. Au lieu de cela, les vendeurs ont rendu leurs audiences disponibles pour l'achat programmatique dans le cadre d'accords conclus avec des annonceurs, des agences ou des DSP. Dans ce cas, le vendeur et l'acheteur effectuent délibérément des transactions dans le cadre du SDA. Si Topics est utilisé dans ces cas, cela peut être pour un ou plusieurs des éléments suivants:
- Le vendeur élargit sa définition d'audience avec des thèmes.
- L'acheteur utilise des thèmes comme signal pour déterminer le montant de l'enchère.
- L'acheteur utilise Topics pour valider l'exactitude de l'attribution basée sur les données.
L'API Protected Audience permet-elle à Google de contrôler la création des audiences ?
Non. Les sites peuvent continuer à créer leurs propres audiences dans et en dehors de la Privacy Sandbox. Lorsque des sites créent des audiences dans la Privacy Sandbox, le propriétaire du site ou le proxy choisi détermine qui peut créer ces audiences, quelles sont ces audiences, comment ces audiences sont mises à jour, comment ces audiences seront en concurrence et s'il faut supprimer des utilisateurs d'une audience.
L'API Protected Audience est-elle compatible avec les groupes de centres d'intérêt créés par les éditeurs ?
Oui. Nous comprenons que les éditeurs craignent de mettre leurs audiences aux enchères basées sur OpenRTB aujourd'hui par peur des fuites de données. Aujourd'hui, les éditeurs peuvent créer des audiences dans Protected Audience qui ne donnent pas à l'enchérisseur une vue intersite de cet utilisateur individuel de l'éditeur. Nous sommes ravis de continuer à explorer de nouvelles façons pour les éditeurs de profiter de l'environnement de protection contre les fuites de données de Protected Audience.
Comment les règles de qualité des annonces sont-elles appliquées dans les enchères Protected Audience ?
Les règles de qualité des annonces sont appliquées de plusieurs façons dans les enchères Protected Audience. Chacune de ces méthodes est semblable à la façon dont les règles de qualité des annonces sont appliquées aujourd'hui par les SSP. Vous pouvez, par exemple, laisser une mise aux enchères avec une création inconnue déclencher la mise en file d'attente de la création pour analyse. D'après les commentaires que nous avons reçus, les SSP souhaitent une meilleure prise en charge de ce cas d'utilisation. Nous concevons donc un mécanisme capable de créer un flux de renderUrls que la SSP peut auditer hors bande, puis stocker des informations dans son serveur de clés-valeurs. Vous pouvez également exiger la préinscription des annonces. Comme dans le cas précédent, une fois la création analysée, les résultats peuvent être liés au serveur de valeurs clés. Ensuite, lorsqu'un acheteur définit une enchère avec cette création (comme indiqué par un ID de création susceptible de suivre le même format qu'OpenRTB), la logique d'évaluation du vendeur peut effectuer une recherche sur le serveur clé-valeur et décider du score en conséquence.
L'API Protected Audience est-elle compatible avec les annonces vidéo ?
Oui. Les URL VAST peuvent être transmises vers et depuis Protected Audience. À mesure qu'une URL VAST sort, les équipes techniques côté vente peuvent coordonner la manière dont elles encapsulent l'URL VAST de l'acheteur avant de l'envoyer au lecteur. En prévision de l'obligation de passer aux cadres clos (dès 2026) et de renforcer davantage la protection de la confidentialité des utilisateurs, nous nous attendons à ce que l'écosystème engage des discussions sur la conception qui incluront certainement des vidéos.
Protected Audience est-il compatible avec les annonces natives ?
Oui. Les URL JSON peuvent être transmises vers et depuis Protected Audience. À mesure qu'une URL JSON sort, les technologies côté vente peuvent coordonner la manière dont elles ajoutent les événements souhaités avant que le fichier JSON final ne soit transmis au code de rendu. En prévision de l'obligation de passer à Fenced Frames (pas plus tôt en 2026) pour renforcer davantage la protection de la confidentialité des utilisateurs, nous nous attendons à ce que l'écosystème prenne part à des discussions sur la conception qui incluront probablement les annonces natives.
L'affichage des annonces Protected Audience entrave-t-il l'innovation ?
Non. L'affichage des annonces a toujours été basé sur les technologies des navigateurs. Cela ne change pas. Cette préoccupation est peut-être spécifique aux projets visant à exiger à l'avenir l'utilisation conjointe de cadres cloisonnés avec Protected Audience. Si nous souhaitons que la technologie Fenced Frames soutienne l'innovation et la différenciation de l'écosystème en matière de rendu des annonces, c'est en partie parce que ces plans sont prévus "dans l'avenir". Les développeurs et les entreprises intéressés ont tout le temps d'envisager l'utilisation de Fenced Frames, y compris la façon dont les approches liées aux annonces natives peuvent être prises en charge.
L'API Protected Audience permet-elle les approches sophistiquées concernant le rythme et l'évaluation des enchères qui existent aujourd'hui dans les enchères traditionnelles ?
Protected Audience permet aux acheteurs de comprendre le rythme et les budgets de leurs campagnes en temps réel. Du point de vue de l'inventaire, le vendeur peut fournir à l'acheteur des signaux d'enchères concernant le contexte de la page et toute autre information. Si un vendeur choisit d'envoyer une demande d'enchère contextuelle, l'acheteur peut également se renseigner sur l'inventaire via ce mécanisme, puis se fournir des signaux contextuels (via perBuyerSignals) qui pourraient être utilisés pour générer sa enchère Protected Audience. Les utilisateurs de la première heure associent déjà des systèmes de machine learning à l'API Protected Audience. Nous sommes conscients qu'il faudra du temps pour ajuster ces systèmes aux enchères dans des environnements Protected Audience, mais il est essentiel de noter que ce réglage est possible et est déjà en cours.
La norme OpenRTB fonctionnera-t-elle dans Protected Audience ?
Oui. Ce travail est en cours à l'IAB Tech Lab par le biais d'un groupe très fréquenté de DSP et de SSP représentatives. Il semble que la voie à suivre consiste à utiliser des parties du protocole OpenRTB comme norme de communication dans les enchères Protected Audience. Nous sommes conscients que les utilisateurs de la première heure utilisent déjà cette fonctionnalité.
L'API Protected Audience oblige-t-elle les entreprises à gérer deux architectures distinctes pour la diffusion d'annonces ?
Non. Protected Audience ne nécessite pas de gérer deux architectures distinctes. Vos choix d'architecture vous appartiennent. La publicité en ligne a évolué au fil des années, tout comme la complexité des systèmes sur lesquels elle est alimentée. Rendre Internet plus privé pour les utilisateurs introduit plus de complexité et nécessite du travail. Les entreprises d'ad tech peuvent choisir de gérer deux architectures distinctes ou de intégrer l'API Protected Audience dans une architecture combinée aux enchères traditionnelles.
Qu'adviendra-t-il des enchères traditionnelles une fois que de nouvelles entreprises de technologie publicitaire prendront en charge l'API Protected Audience ?
Les enchères contextuelles devraient rester pertinentes pour de nombreuses raisons, par exemple les accords, les campagnes ciblant une audience non propriétaire et de nombreux autres scénarios contextuels. Elles restent également utiles lorsqu'aucun groupe de centres d'intérêt n'est présent ou que les enchères dans Protected Audience n'atteignent pas les prix planchers ou ne respectent pas les règles de qualité des annonces.
Les enchères Protected Audience vont-elles à l'encontre des efforts d'optimisation du chemin d'approvisionnement (SPO) de l'écosystème visant à réduire le nombre total d'intermédiaires entre un annonceur et un éditeur, et/ou à dupliquer une opportunité publicitaire donnée ?
Non. Une annonce gagnante dans Protected Audience sera transmise par deux entités de vendeur au maximum (par exemple, une plate-forme côté offre (SSP) et un ad server d'éditeur) et pas du tout si l'acheteur crée une intégration directe avec l'éditeur.
La duplication de la même requête via plusieurs intermédiaires reste le choix de l'éditeur. Protected Audience ne devrait pas avoir d'impact dans ce sens.
Les enchères Protected Audience ont lieu en dehors du système en temps réel de serveur à serveur actuel afin d'éviter les fuites de données utilisateur intersites. Certains peuvent dire que cela duplique une demande d'annonce. L'obtention d'une confidentialité techniquement démontable nécessite quelques compromis. Toutefois, il est possible à long terme que l'écosystème décide d'utiliser Protected Audience sans enchères traditionnelles côté serveur. Ce choix pourrait encore améliorer l'optimisation des chemins d'approvisionnement.
L'API Protected Audience réduit-elle la valeur du trafic existant qui façonne l'infrastructure ?
D'après nos informations, ce qui change en ce qui concerne les requêtes par seconde, c'est que de nombreuses SSP utilisent les ID intersites comme fonctionnalité pour déterminer si une demande DSP doit être envoyée ou non. La réduction des ID intersites a donc un impact sur les techniques existantes de lissage du trafic. Cela est vrai que l'éditeur souhaite lancer ou non une mise aux enchères Protected Audience.
Nous avons examiné le lissage du trafic avec de nombreuses SSP et trouvé des solutions telles que la mise en cache et le filtrage basé sur le contexte. Au fil du temps, nous attendons des développeurs qu'ils tirent parti de l'agrégation privée pour mieux comprendre les préférences d'enchères DSP et filtrer en conséquence.
À terme, certaines anciennes infrastructures basées sur des identifiants intersites ne seront plus utiles.
Les nouvelles demandes résultant d'enchères Protected Audience affectent-elles la capacité de la SSP ?
Certaines SSP nous ont indiqué que la capacité n'était ni un problème, ni un élément important de la proposition de valeur des SSP du point de vue de l'intégration. En ce qui concerne les SSP qui s'inquiètent des nouveaux appels dans le processus d'enchères, nous connaissons des entreprises qui les aident déjà à résoudre des problèmes de capacité et cherchent à étendre ces services à l'API Protected Audience. N'hésitez pas à nous contacter si vous souhaitez que nous vous mettions en relation avec l'une de ces entreprises.
Comment la priorité est-elle traitée dans Protected Audience lorsque des ressources concurrentes sont disponibles dans le navigateur ?
Protected Audience a généralement suivi le paradigme standard consistant à créer des contrôles permettant aux vendeurs de décider du temps et des ressources qu'ils peuvent utiliser, et à créer des outils permettant aux acheteurs de décider de la meilleure façon d'utiliser les ressources dont ils disposent. Ces contrôles et outils sont disponibles aujourd'hui, mais ils profiteront pleinement de leurs avantages après leur adoption par les acheteurs et les vendeurs. En outre, Chrome continue de travailler sur diverses améliorations d'infrastructure pour améliorer la vitesse des enchères (par exemple, crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev73/119).
Comment l'API Protected Audience résout-elle les problèmes de latence ?
Auparavant, avant Protected Audience, les vendeurs spécifiaient des délais d'inactivité stricts pour les réponses des acheteurs afin de contrôler la latence lors des enchères en temps réel sur les serveurs. Nous avons ajouté à Protected Audience plusieurs commandes de délai avant expiration très similaires spécifiées par le vendeur (consultez la documentation pour perBuyerCumulativeTimeouts, perBuyerTimeouts et sellerTimeout) afin de maintenir la latence sous contrôle. Ces contrôles encouragent également les participants aux enchères à optimiser leur logique pour s'assurer que les ressources sont utilisées le plus efficacement possible pour soutenir l'écosystème ad tech et offrir une expérience utilisateur de haute qualité.
Chrome continue également de travailler sur diverses améliorations d'infrastructure visant à accélérer les enchères (par exemple, crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Nous vous invitons à envoyer des commentaires concernant les deux parties de cet effort de latence: des outils supplémentaires que les acheteurs et les vendeurs trouveraient utiles, et des rapports sur les goulots d'étranglement observés que les ingénieurs de Chrome doivent examiner.
Dans le cas de services d'enchères et de mise aux enchères, créer l'API Protected Audience sur l'appareil est-il un gaspillage ?
Non. L'appareil sur l'appareil est suffisant pour les cas d'utilisation de technologies publicitaires. Les services d'enchères et de mise aux enchères sont une solution facultative à évolutivité horizontale permettant aux technologies publicitaires d'investir davantage dans les ressources de calcul des enchères que le navigateur ne le permet. Le développement sur l'appareil est un bon investissement, car la majeure partie du travail serait réutilisable, même si les développeurs décident plus tard de participer à des environnements de services d'enchères et de mise aux enchères. La majorité des pipelines et de l'infrastructure construits continueront à fonctionner de la même manière.
Les exigences concernant les environnements d'exécution sécurisé (TEE) basés sur le cloud pour Protected Audience inciteront-elles les entreprises à utiliser Google Cloud ?
La Privacy Sandbox a conçu les API dans un souci de confidentialité et de sécurité robustes. Nous n'avons pris aucune décision de conception au profit de Google Cloud. Notre assistance aux fournisseurs de services cloud a commencé avec AWS, car nous savons combien de fournisseurs de technologie publicitaire choisissent Amazon. Outre AWS et Google Cloud, nous prévoyons de prendre en charge à l'avenir d'autres fournisseurs cloud, et nous sommes ouverts à toute suggestion concernant d'autres fournisseurs de services cloud. Si la latence pose problème, les clouds offrent aux clients des choix d'emplacement qui réduisent les distances à d'autres fournisseurs de services cloud.
La Privacy Sandbox permettra-t-elle aux environnements d'exécution sécurisés (TEE) de s'exécuter dans des centres de données cloud non publics ?
Les environnements d'exécution sécurisés (TEE) auditables font partie de notre modèle de confidentialité et de sécurité. Nous avons commencé avec les TEE proposés par les fournisseurs de cloud public en raison de mesures de sécurité rigoureuses. Pour rappel, les seules API qui nécessiteront à court terme l'utilisation d'environnements d'exécution approuvés sont l'API Attribution Reporting et l'API Private Aggregation. Aucune de ces API ne nécessite d'appeler le TEE en temps réel dans un paramètre de mise aux enchères. Nous continuons à explorer d'autres options qui vont au-delà des solutions basées sur le cloud public.
L'exécution d'environnements d'exécution sécurisés dans des clouds publics ne sera-t-elle pas plus coûteuse que dans des centres de données ad tech sur site ?
Notre modèle de confidentialité TEE actuel bénéficie des pratiques de sécurité des implémentations de cloud public, et nous remettons en question toute hypothèse selon laquelle il serait moins coûteux d'exploiter un environnement d'exécution sécurisé sur site. Voici quelques éléments de coût à prendre en compte pour ces pratiques:
Les fournisseurs de cloud public doivent se conformer à des exigences très strictes en termes de sécurité. Par exemple, AWS est un fournisseur de services cloud réputé qui applique des pratiques de sécurité établies. En particulier, AWS Nitro dispose d'un modèle de sécurité documenté pour s'assurer que Nitro Enclaves empêche les opérateurs d'accéder aux données traitées dans l'enclave, et que les ressources protégées (telles que les clés de déchiffrement) ne sont disponibles que pour le code autorisé exécuté dans l'Enclave. Il y a également un accès physique à prendre en compte. AWS a conçu et mis en œuvre des mesures d'atténuation des risques d'accès physique, y compris de la part des employés Amazon. Les TEE matériels existants ne peuvent pas se défendre contre toutes les attaques physiques, comme le font les clouds publics. En outre, Amazon a récemment fait appel au cabinet de recherche indépendant NCC Group afin d'examiner ses conceptions Nitro, axées sur les affirmations de sécurité liées aux accès des employés internes. Le rapport public indique que les conceptions AWS répondent à leurs revendications.
La mise en place, le soutien et l'amélioration de ces pratiques coûtent de l'argent au fil du temps. Avec les clouds publics distribués à l'échelle mondiale et largement disponibles, ces coûts sont répartis sur un large éventail de clients.
La Privacy Sandbox modifie-t-elle la facturation ?
Non. Les entreprises d'ad tech et les autres appelants d'API peuvent continuer à voir si un élément est affiché sur une page et à quel prix.
La limitation de la fréquence d'exposition est-elle possible dans la Privacy Sandbox ?
Protected Audience est compatible avec la limitation de la fréquence d'exposition sur plusieurs sites au sein d'un même groupe de centres d'intérêt via l'objet prevWinsMs. La fonction generateBid() d'un acheteur dans le système d'enchères Protected Audience peut créer une logique capable d'éclairer la stratégie d'enchères en fonction du résultat d'expositions d'annonces précédentes sur le même navigateur.
Plusieurs solutions peuvent être utilisées pour limiter la fréquence d'exposition en dehors de l'API Protected Audience, mais elles ne correspondent pas entièrement aux techniques intersites utilisées par les technologies publicitaires avec les cookies tiers.
- Cookies propriétaires: les technologies publicitaires peuvent utiliser leurs propres données first party pour limiter la fréquence d'exposition sur leur propre site.
- CHIP: les technologies publicitaires peuvent gérer les limites de la fréquence d'exposition au niveau de chaque site à l'aide d'un cookie partitionné.
- Stockage partagé
SelectURL(): lorsqu'une technologie publicitaire a remporté une enchère et avant d'afficher la création, elle peut appeler le stockage partagé pour accéder aux données intersites et choisir la création appropriée en fonction de la fréquence via la porte de sortie "Sélectionner l'URL".
Une solution de limitation de la fréquence d'exposition non protégée, centrée sur la confidentialité et offrant une utilité de technologie publicitaire pertinente, représente un défi pour les raisons suivantes:
- À l'heure actuelle, les commentaires des technologies publicitaires ne permettent pas de savoir si un signal de fréquence peut tolérer le bruit.
- Nous avons entendu régulièrement des commentaires concernant les technologies publicitaires selon lesquels un signal de fréquence intersites devrait être disponible au moment de la mise aux enchères, ce qui nécessite que des signaux intersites sans bruit soient disponibles pour n'importe quelle enchère publicitaire. Cela peut révéler une grande quantité d'informations sur l'activité d'un utilisateur sur l'ensemble des sites, ce qui compromet les objectifs de confidentialité de la Privacy Sandbox.
- Nous sommes sensibles à l'introduction de la latence. De plus, une solution sur l'appareil qui pourrait fournir ce signal pourrait causer de la latence et perturber l'environnement d'enchères.
- Il faudrait probablement utiliser une nouvelle API, qui serait soumise au processus de proposition W3C.
Par conséquent, la création d'une solution de limitation de la fréquence d'exposition en dehors de Protected Audience ne figure pas dans notre feuille de route immédiate, mais nous sommes ouverts aux commentaires sur les moyens potentiels de résoudre ce cas d'utilisation.
Qu'en est-il des cas d'utilisation qui ne sont pas couverts par la Privacy Sandbox ?
Les API de la Privacy Sandbox fournissent des éléments de base pour la publicité protégeant la confidentialité, où les développeurs ont la possibilité de déterminer comment elles sont conçues. L'approche basée sur les éléments constitutifs permet aux entreprises d'innover et de développer des solutions qui apportent de la valeur à leurs clients. La Privacy Sandbox n'est pas une solution de bout en bout pour tous les cas d'utilisation. Nous pensons que ce serait un mauvais résultat. Au lieu de cela, les développeurs et les entreprises continueront à donner vie à leurs idées grâce à diverses technologies, y compris les API Privacy Sandbox qu'elles intègrent dans leurs solutions.