Améliorer la latence des enchères de l'API Protected Audience

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 élaborer efficacement avec l'API Protected Audience afin de ne pas surutiliser des ressources limitées de l'appareil, telles que les ressources de calcul ou de réseau, qui sont nécessaires pour charger des sites et leurs annonces intégrées.
• Les éditeurs souhaitent que leurs sites se chargent rapidement, offrant ainsi aux utilisateurs une expérience efficace et réactive. Les éditeurs veulent aussi une publicité efficace pour maximiser leurs revenus.
• Les annonceurs et les technologies publicitaires souhaitent que leurs annonces s'affichent rapidement pour offrir une utilité optimale.

Ce document présente quelques bonnes pratiques à suivre pour implémenter l'API Protected Audience afin de vous 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 de centres 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 différentes origines sur le Web à l'aide de l'isolation de sites, le navigateur utilise des ressources coûteuses (telles que les processus du système d'exploitation) pour protéger les propriétaires de groupes de centres d'intérêt individuels.

Pour réduire les dépenses liées à ces ressources très coûteuses, il est essentiel d'avoir le moins de propriétaires de groupes de centres d'intérêt. Évitez d'avoir différents groupes de centres d'intérêt appartenant à différents sous-domaines. Par exemple, si adtech.example comporte des groupes de centres d'intérêt appartenant à cats.adtech.example et dogs.adtech.example, le navigateur utilisera probablement deux processus distincts pour exécuter ses scripts d'enchères.

Moins d'enchères liées aux groupes de centres d'intérêt

Le navigateur doit procéder à une configuration et une préparation importantes avant d'appeler le script generateBid() d'un acheteur. Par exemple, il doit configurer un nouvel environnement d'exécution JavaScript propre, et analyser et charger le code generateBid().

• Les groupes de centres d'intérêt représentant des utilisateurs qui ne sont pas la cible actuelle d'une campagne publicitaire active doivent comporter des listes de créations publicitaires vides. Cela empêche l'API Protected Audience d'exécuter generateBid() pour les groupes de centres d'intérêt sans annonces pertinentes.
• Combiner des groupes de centres d'intérêt similaires réduit le nombre d'exécutions de generateBid(). La propriété userBiddingSignals d'un groupe de centres d'intérêt peut être utilisée pour stocker des métadonnées supplémentaires sur l'utilisateur. Ainsi, moins de groupes de centres d'intérêt ne doivent pas signifier un ciblage moins efficace.
• L'API Protected Audience prend en charge les limites spécifiées par le vendeur concernant le nombre de groupes de centres d'intérêt et une API permettant aux acheteurs de spécifier la priorité relative de leurs groupes de centres d'intérêt. Ces limites peuvent être utilisées pour réduire considérablement le nombre de scripts d'enchères à exécuter.

Exclure des groupes de centres d'intérêt des enchères dans votre service de clés-valeurs

Si un acheteur peut déterminer, sur son serveur de signaux d'enchères de confiance en temps réel, que certains groupes de centres d'intérêt ne doivent pas enchérir (par exemple, si la campagne est désactivée, mise en veille, hors du budget ou ne doit pas enchérir sur cet éditeur), il peut l'indiquer au navigateur avec la réponse priorityVector à l'extraction des signaux d'enchères de confiance. Si le produit scalaire creux obtenu pour priorityVector et prioritySignals est négatif, le navigateur ignore l'appel de generateBid() pour ce groupe de centres d'intérêt. Pour en savoir plus sur ce mécanisme, consultez la section Filtrer et hiérarchiser les groupes de centres d'intérêt de la présentation.

Réutiliser l'environnement d'exécution JavaScript

Pour que le navigateur puisse exécuter generateBid(), il doit initialiser un nouvel environnement d'exécution JavaScript. Cela peut prendre un temps considérable, au même titre que le temps nécessaire à l'exécution d'une generateBid() minimale. Vous pouvez gagner ce temps en utilisant les modes d'exécution "Grouper par origine" ou "Contexte figé".

Le mode group-by-origin peut réutiliser les environnements d'exécution dans les cas où des groupes de centres d'intérêt sont regroupés sur la même origine et ne nécessitera probablement pas de modifier votre script d'enchères. Pour en savoir plus, consultez la description de group-by-origin dans l'explication. Le mode Contexte figé peut réutiliser potentiellement tous les environnements d'exécution, mais il peut être nécessaire de modifier 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 de centres 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 de centres d'intérêt (par exemple, name ou userBiddingSignals) tout en utilisant le même script.

Réutiliser trustedBiddingSignalsUrls

La latence du réseau et l'utilisation des ressources peuvent être très importantes. La récupération moins importante des signaux d'enchères de confiance en temps réel peut contribuer à réduire cette latence.

Les récupérations de signaux d'enchères de confiance peuvent être combinées lorsque trustedBiddingSignalsUrl est réutilisé avec plusieurs groupes de centres d'intérêt. Dans la mesure du possible, utilisez le même trustedBiddingSignalsUrl pour tous les groupes de centres d'intérêt.

Spécifiez des en-têtes de contrôle du cache HTTP appropriés pour vous assurer que les récupérations de signaux d'enchères de confiance sont mises en cache dans tous les espaces 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 espaces publicitaires lorsque les tailles des espaces diffèrent, car l'URL demandée sera différente.

Récupération de signaux d'enchères de confiance en temps réel plus petits

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 en temps réel des signaux d'enchères de confiance.

Il est préférable de stocker des données spécifiques à une annonce ou à un groupe de centres d'intérêt dans le groupe de centres d'intérêt plutôt que dans le service de signaux d'enchères de confiance en temps réel. Réservez des données de signaux d'enchères de confiance en temps réel uniquement pour les signaux en temps réel, tels que les budgets de campagne ou les interrupteurs à bascule.

Tout signal pouvant être mis à jour quotidiennement ou plus doit être stocké dans le groupe de centres d'intérêt et mis à jour à l'aide des mises à jour quotidiennes.

Ne renvoyez pas de signaux d'enchères de confiance pour des groupes de centres d'intérêt filtrés comme indiqué dans la section Exclure des groupes de centres d'intérêt des enchères dans votre service de clés-valeurs.

Donner la priorité aux groupes de centres d'intérêt

Les vendeurs utilisent des délais avant expiration pour limiter l'utilisation des ressources du navigateur sur les pages des éditeurs. Lorsque les perBuyerCumulativeTimeouts permettent de limiter le temps dont disposent les acheteurs pour extraire leurs signaux d'enchères de confiance et exécuter leurs scripts d'enchères, il est essentiel qu'ils donnent la priorité à leurs groupes de centres d'intérêt afin que ceux qui ont le plus de chances de remporter l'enchère soient exécutés en premier. Par exemple, si perBuyerCumulativeTimeouts est défini sur 100 ms, que la récupération des signaux d'enchères de confiance d'un enchérisseur prend 50 ms, que chaque appel generateBid() prend 10 ms et que 10 groupes de centres d'intérêt sont présents sur un appareil, seule la moitié de ses groupes de centres d'intérêt pourra calculer les enchères. Dans cet exemple, l'acheteur doit prioriser ses groupes de centres d'intérêt, du plus susceptible de gagner à celui qui a le moins de chances de gagner.

Les groupes de centres d'intérêt peuvent contenir des priorités statiques définies avec leur champ priority. Les groupes de centres d'intérêt peuvent également utiliser des priorités dynamiques qui peuvent être calculées sur leur service de signaux d'enchères de confiance et renvoyées au navigateur avec la réponse priorityVector aux signaux d'enchères de confiance.

Notez que lorsque le navigateur exécute des groupes de centres d'intérêt de la priorité la plus élevée à la plus basse, cela peut interférer avec les groupes de centres d'intérêt provenant de différentes origines de jointure, ce qui peut aller à l'encontre de l'optimisation de group-by-origin.

Bonnes pratiques pour les vendeurs

Veillez à surveiller et optimiser l'efficacité des enchères de l'API Protected Audience.

Charger les mises aux enchères en parallèle

Les connexions réseau modernes et les processeurs multicœurs sont très efficaces pour effectuer plusieurs activités simultanément. Le navigateur peut lancer une mise aux enchères Protected Audience en parallèle d'autres activités. Pour faciliter ce processus, appelez runAdAuction() le plus tôt possible. Sachant que certaines entrées de runAdAuction() peuvent ne pas être disponibles dès le début, par exemple celles qui sont renvoyées au navigateur dans la réponse contextuelle, le navigateur autorise l'appel de runAdAution() avant qu'elles ne soient disponibles, et la fourniture de 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. Ainsi, de nombreuses parties de la mise aux enchères peuvent démarrer immédiatement, y compris la récupération des signaux des 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 fournir des métriques de latence per-buyer aux vendeurs, qui fournissent des informations détaillées sur le temps consacré aux enchères. Les vendeurs peuvent utiliser ces métriques pour chercher des moyens d'optimiser leurs enchères, y compris pour savoir comment définir des délais avant expiration le plus efficacement possible. Les vendeurs peuvent partager avec eux les métriques de latence d'un acheteur spécifique afin de les aider à optimiser davantage leurs campagnes.

Les enchérisseurs peuvent obtenir des insights sur les performances des enchères de leurs propres groupes de centres d'intérêt, mais ils ne pourront peut-être pas les comparer à celles d'autres enchérisseurs. Comparer les taux de réussite relatifs et les taux de refus des enchères pour différents enchérisseurs peut vous aider à identifier les cas où les ressources de calcul des enchères ont été gaspillées, car les groupes de centres d'intérêt n'ont jamais produit d'enchères viables ou des 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 personnes concernées. L'utilisation de délais d'inactivité peut éviter les enchères lentes tout en permettant de récupérer des revenus lorsque la mise aux enchères est lente.

Les vendeurs doivent utiliser perBuyerCumulativeTimeouts pour éviter que les enchères soient lentes, mais aussi pour continuer à accepter les enchères lorsque celles-ci sont lentes et qu'elles atteignent le délai d'inactivité. 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 de centres d'intérêt ou la vitesse de generateBid() (par exemple, de nombreux groupes de centres d'intérêt qui enchérissent rapidement et peu de groupes de centres d'intérêt qui enchérissent lentement peuvent tous les deux terminer avant la fin du délai d'expiration).

L'utilisation du champ signal de la configuration des enchères pour implémenter un délai d'expiration global des enchères est également utile pour éviter des enchères trop longues dans les cas où la récupération du signal d'évaluation de confiance et l'exécution de scoreAd() prennent trop de temps.

Important :Remarque sur la chronologie des enchères. Les utilisateurs se demandent souvent "combien de temps prend une mise aux enchères Protected Audience ?", "Sur quelle période le vendeur doit-il définir les délais d'inactivité ?" ou "Quelle est la latence pour laquelle un acheteur doit optimiser son utilisation ?". La réponse à ces questions dépend du résultat pour lequel les participants optimisent les enchères. Les vendeurs souhaitent peut-être maximiser les revenus publicitaires générés par leurs sites Web. Dans ce cas, ils doivent tester différents délais avant expiration afin de trouver le paramètre qui optimise les revenus. Il peut être utile d'avoir des délais d'inactivité différents pour les ordinateurs et les mobiles. L'utilisation de l'API Protected Audience peut changer au fil du temps à mesure que l'adoption augmente, que les participants aux enchères optimisent leur logique ou que les ordinateurs évoluent. Il peut donc être bénéfique d'effectuer des tests continus. Si les acheteurs optimisent la plupart des mises aux enchères, ils doivent surveiller et optimiser la latence de leurs signaux d'enchères de confiance et la latence de generateBid(). Envisagez aussi de donner la priorité à leurs groupes de centres d'intérêt afin que, lorsque les vendeurs définissent des délais d'expiration stricts, ils doivent générer leurs meilleures enchères en premier.

É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.