Il est dans l'intérêt de tous de s'assurer que l'API Protected Audience fonctionne efficacement :
- Les internautes veulent que les sites se chargent rapidement. Cela signifie que les développeurs doivent créer des applications avec l'API Protected Audience de manière efficace afin de ne pas surutiliser les ressources limitées de l'appareil, telles que les ressources de calcul ou de réseau, qui sont nécessaires pour charger les sites et leurs annonces intégrées.
- Les éditeurs souhaitent que leurs sites se chargent rapidement pour offrir aux utilisateurs une expérience efficace et réactive. Les éditeurs souhaitent également diffuser des annonces efficaces pour maximiser leurs revenus.
- Les annonceurs et les technologies publicitaires souhaitent que leurs annonces s'affichent rapidement pour être les plus utiles possible.
Ce document présente quelques bonnes pratiques pour implémenter l'API Protected Audience et s'assurer que votre site fonctionne de manière optimale.
Bonnes pratiques pour les acheteurs (enchérisseurs)
Pour vous assurer d'optimiser l'efficacité des enchères de l'API Protected Audience, suivez ces bonnes pratiques.
Moins de propriétaires de groupes d'intérêt
Pour protéger les enchérisseurs de l'API Protected Audience de la même manière que le navigateur protège les différentes origines sur le Web à l'aide de l'l'isolation de sites, le navigateur utilise des ressources coûteuses (comme les processus du système d'exploitation) pour protéger les propriétaires de groupes d'intérêt individuels.
Pour minimiser les dépenses de ces ressources très coûteuses, il est essentiel de limiter le nombre de propriétaires de groupes d'intérêt. Évitez d'avoir différents groupes d'intérêt appartenant à différents sous-domaines. Par exemple, si adtech.example possède des groupes d'intérêt appartenant à cats.adtech.example et dogs.adtech.example, le navigateur utilisera probablement deux processus distincts pour exécuter leurs scripts d'enchères.
Moins de groupes d'intérêt enchérissent
Le navigateur doit effectuer une configuration et une préparation importantes avant d'appeler un script generateBid() d'acheteur, comme la configuration d'un nouvel environnement d'exécution JavaScript propre, ainsi que l'analyse et le chargement du code generateBid().
- Les groupes d'intérêt qui représentent des utilisateurs qui ne sont pas la cible actuelle d'une campagne publicitaire active doivent avoir des listes de créations publicitaires vides. Cela empêche l'API Protected Audience d'exécuter
generateBid()pour les groupes d'intérêt sans annonces pertinentes. - Combiner des groupes d'intérêt similaires réduira le nombre de fois où
generateBid()doit être exécuté. La propriétéuserBiddingSignalsd'un groupe d'intérêt peut être utilisée pour stocker des métadonnées supplémentaires sur l'utilisateur. Par conséquent, moins de groupes d'intérêt ne signifie pas nécessairement un ciblage moins efficace. - L'API Protected Audience prend en charge les limites spécifiées par les vendeurs sur le nombre de groupes d'intérêt, ainsi qu'une API permettant aux acheteurs de spécifier la priorité relative de leurs groupes d'intérêt. Ces limites peuvent être utilisées pour réduire considérablement le nombre de scripts d'enchères à exécuter.
Filtrer les groupes d'intérêt des enchères dans votre service de clé/valeur
Si un acheteur peut déterminer dans son serveur de signaux d'enchères fiables en temps réel que certains groupes d'intérêt ne doivent pas enchérir (par exemple, si la campagne est désactivée, mise en veille ou hors budget, ou si elle ne doit pas enchérir sur cet éditeur en particulier), il peut l'indiquer au navigateur avec la réponse priorityVector à la récupération des signaux d'enchères fiables. Si le produit scalaire creux résultant de priorityVector et prioritySignals est négatif, le navigateur n'invoquera pas generateBid() pour ce groupe d'intérêt. Pour en savoir plus sur ce mécanisme, consultez la section Filtrer et hiérarchiser les groupes d'intérêt de l'explication.
Réutiliser l'environnement d'exécution JavaScript
Avant que le navigateur puisse exécuter generateBid(), il doit initialiser un nouvel environnement d'exécution JavaScript. Cela peut prendre un temps considérable, comparable à celui nécessaire à l'exécution d'un generateBid() minimal. Vous pouvez gagner du temps en utilisant les modes d'exécution "group-by-origin" ou "frozen-context".
Le mode group-by-origin peut réutiliser les environnements d'exécution dans les cas où des groupes d'intérêt sont rejoints sur la même origine. Il ne nécessitera probablement pas de modifications de votre script d'enchères. Pour en savoir plus, consultez la description de group-by-origin dans l'explication. Le mode de contexte figé peut réutiliser potentiellement tous les environnements d'exécution, mais peut nécessiter des modifications de votre script d'enchères. Pour en savoir plus, consultez la description de frozen-context dans l'explication.
Réutiliser des scripts d'enchères
Si possible, utilisez le même script d'enchères pour les groupes d'intérêt. Cela évite au navigateur d'avoir à télécharger, analyser et compiler plusieurs scripts (ce qui entraîne des requêtes réseau supplémentaires). Les enchérisseurs peuvent toujours différencier les enchères en fonction des informations sur les groupes d'intérêt (par exemple, name ou userBiddingSignals) tout en utilisant le même script.
Sans en-têtes de contrôle du cache HTTP, le script d'enchères n'est pas mis en cache. Spécifiez les en-têtes appropriés pour vous assurer que le script n'est pas récupéré inutilement. Si plusieurs enchères sont exécutées en parallèle sur la page, le script d'enchères du même enchérisseur sera réutilisé s'il est déjà en mémoire, en ignorant la sémantique de mise en cache. Si les enchères se déroulent de manière séquentielle, le navigateur respecte le mécanisme de mise en cache HTTP.
Notez que le navigateur charge le script d'enchères pendant la période d'enchères (pour generateBid()) et pendant la période de reporting (pour reportWin()). Si les en-têtes de contrôle du cache ne sont pas définis, le navigateur récupère le même script deux fois, une fois pour chaque période.
Nous vous recommandons donc de définir des en-têtes de contrôle du cache sur tous vos scripts.
Réutiliser trustedBiddingSignalsUrls
La latence du réseau et l'utilisation des ressources peuvent être très importantes. Moins de récupérations de signaux d'enchères fiables en temps réel peuvent contribuer à réduire cette latence.
Les récupérations de signaux d'enchères fiables peuvent être combinées lorsque le trustedBiddingSignalsUrl est réutilisé dans plusieurs groupes d'intérêt.
Dans la mesure du possible, utilisez le même trustedBiddingSignalsUrl pour tous les groupes d'intérêt.
Spécifiez les en-têtes de contrôle du cache HTTP appropriés pour vous assurer que les récupérations de signaux d'enchères fiables sont mises en cache dans les emplacements publicitaires d'une page Web spécifique. Évitez de définir trustedBiddingSignalsSlotSizeMode sur slot-size, car cela empêchera la mise en cache dans les emplacements publicitaires lorsque leur taille diffère, car l'URL demandée sera différente.
Récupérations de signaux d'enchères fiables en temps réel plus petites
La latence du réseau peut être très importante. Elle est directement affectée par la quantité de données transférées lors de la récupération des signaux d'enchères fiables en temps réel.
Il est préférable de stocker les données spécifiques aux annonces ou aux groupes d'intérêt dans le groupe d'intérêt, plutôt que dans le service de signaux d'enchères fiables en temps réel. Réservez les données de signaux d'enchères fiables en temps réel uniquement pour les signaux réellement en temps réel, comme le budget de la campagne ou les kill switches.
Tout signal pouvant être mis à jour quotidiennement ou plus rarement doit être stocké dans le groupe d'intérêt et mis à jour à l'aide des mises à jour quotidiennes.
Ne renvoyez pas de signaux d'enchères fiables pour les groupes d'intérêt filtrés, comme décrit dans la section Filtrer les groupes d'intérêt des enchères dans votre service de clés/valeurs.
Prioriser les groupes d'intérêt
Les vendeurs utiliseront des délais d'attente pour limiter l'utilisation des ressources du navigateur sur les pages des éditeurs. Lorsque des perBuyerCumulativeTimeouts sont utilisés pour limiter le temps dont disposent les acheteurs pour récupérer leurs signaux d'enchères fiables et exécuter leurs scripts d'enchères, il est essentiel qu'ils s'assurent de hiérarchiser leurs groupes d'intérêt afin que ceux qui sont les plus susceptibles de remporter l'enchère soient exécutés en premier. Par exemple, si perBuyerCumulativeTimeouts est défini sur 100 ms et que la récupération des signaux d'enchères fiables d'un enchérisseur prend 50 ms, et que chaque invocation generateBid() prend 10 ms et qu'il y a 10 groupes d'intérêt présents sur un appareil, seule la moitié de ses groupes d'intérêt aura la possibilité de calculer des enchères. Dans cet exemple, l'acheteur doit classer ses groupes d'intérêt par ordre de probabilité de gain, du plus probable au moins probable.
Les groupes d'intérêt peuvent contenir des priorités statiques définies avec leur champ priority. Les groupes d'intérêt peuvent également utiliser des priorités dynamiques qui peuvent être calculées sur leur service de signaux d'enchères fiables et renvoyées au navigateur avec la réponse priorityVector à la récupération des signaux d'enchères fiables.
Notez que lorsque le navigateur exécute les groupes d'intérêt de la priorité la plus élevée à la plus basse, cela peut intercaler des groupes d'intérêt provenant de différentes origines de jointure, ce qui peut nuire à l'optimisation group-by-origin.
Bonnes pratiques pour les vendeurs
Assurez-vous de surveiller et d'optimiser l'efficacité des enchères de l'API Protected Audience.
Paralléliser les enchères
Les connexions réseau modernes et les processeurs multicœurs sont très efficaces pour effectuer plusieurs activités simultanément. Le navigateur peut exécuter une enchère Protected Audience en parallèle d'autres activités. Pour ce faire, appelez runAdAuction() dès que possible. Étant donné que certaines entrées de runAdAuction() peuvent ne pas être disponibles au début, par exemple celles qui sont renvoyées au navigateur dans la réponse contextuelle, le navigateur permet d'appeler runAdAution() avant qu'elles ne soient disponibles et de fournir ces entrées ultérieurement à l'aide de promesses JavaScript. Pour obtenir la latence d'enchères la plus faible possible, runAdAuction() doit être appelé lorsque l'entrée interestGroupBuyers est connue. Cela permet de lancer immédiatement de nombreuses parties de l'enchère, y compris la récupération des signaux d'enchères en temps réel de l'enchérisseur.
Surveiller vos enchères
Collectez des métriques sur vos enchères. Le navigateur peut signaler des métriques de latence per-buyer aux vendeurs, ce qui leur donne de nombreuses informations sur le temps passé dans leurs enchères. Les vendeurs peuvent utiliser ces métriques pour trouver des moyens d'optimiser leurs enchères, y compris pour déterminer la meilleure façon de définir les délais d'attente. Les vendeurs peuvent partager les métriques de latence d'un acheteur spécifique avec lui pour l'aider à optimiser davantage ses performances.
Les enchérisseurs peuvent avoir des informations sur les performances d'enchères de leurs propres groupes d'intérêt, mais ils ne peuvent pas les comparer à celles d'autres enchérisseurs. La comparaison des taux de victoire et des taux de refus d'enchères relatifs pour différents enchérisseurs peut aider à identifier les cas où les ressources de calcul des enchères ont été gaspillées en raison de groupes d'intérêt n'ayant jamais produit d'enchères viables ou d'enchères excessives avec des créations non approuvées.
Se protéger contre les scripts d'enchères lentes
Les scripts d'enchères qui prennent trop de temps peuvent ralentir les enchères de l'API Protected Audience pour toutes les parties concernées. L'utilisation de délais d'attente peut éviter les enchères lentes tout en récupérant les revenus lorsque l'enchère est lente.
Les vendeurs doivent utiliser perBuyerCumulativeTimeouts pour éviter les enchères lentes et continuer à accepter les offres lorsque les enchères sont lentes et atteignent le délai d'expiration. Il est préférable d'utiliser perBuyerCumulativeTimeouts plutôt que perBuyerTimeouts et perBuyerGroupLimits, car perBuyerCumulativeTimeouts n'a pas d'opinion sur le nombre de groupes d'intérêt ni sur la vitesse de generateBid() (par exemple, de nombreux groupes d'intérêt qui enchérissent rapidement et peu de groupes d'intérêt qui enchérissent lentement peuvent tous deux se terminer avant le délai d'expiration).
Il est également judicieux d'utiliser le champ de configuration des enchères signal pour implémenter un délai d'expiration global des enchères. Cela permet d'éviter les enchères trop longues lorsque la récupération des signaux de score fiables et l'exécution de scoreAd() prennent trop de temps.
Étape suivante
Nous souhaitons discuter avec vous d'une API adaptée à tous les utilisateurs.
Discuter de l'API
Comme d'autres API de la Privacy Sandbox, cette API est documentée et consultée publiquement.
Tester l'API
Vous pouvez tester l'API Protected Audience et y participer.