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 qui naviguent sur le Web 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 surexploiter les ressources limitées de l'appareil, comme 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, afin de proposer 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 veulent que leurs annonces s'affichent rapidement pour offrir une utilité maximale.

Ce document présente quelques bonnes pratiques pour l'implémentation de l'API Protected Audience afin de garantir le fonctionnement optimal de votre site.

Bonnes pratiques pour les acheteurs (enchères)

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êts

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'isolation de site, le navigateur utilise des ressources coûteuses (comme les processus du système d'exploitation) pour protéger les propriétaires individuels de groupes de centres d'intérêt.

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

Moins d'enchères pour les groupes de centres d'intérêt

Le navigateur doit effectuer une configuration et une préparation importantes avant d'appeler le script generateBid() d'un acheteur, par exemple en configurant un nouvel environnement d'exécution JavaScript propre, et en analysant et en chargeant le code generateBid().

  • Les groupes de centres d'intérêt qui représentent des utilisateurs qui ne sont pas actuellement la cible 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êts 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. Par conséquent, un nombre moins élevé de groupes de centres d'intérêt ne signifie pas nécessairement un ciblage moins efficace.
  • L'API Protected Audience accepte les limites spécifiées par le vendeur sur 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.

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

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êts ne doivent pas définir d'enchères (par exemple, si la campagne est désactivée, mise en veille ou si elle a dépassé son budget, ou si elle ne doit pas définir d'enchères pour 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 sporadique résultant de priorityVector et prioritySignals est négatif, le navigateur ignore l'appel de generateBid() pour ce groupe d'intérêts. 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 vidéo explicative.

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. Cette opération peut prendre un certain temps, à peu près autant qu'une generateBid() minimale peut prendre pour s'exécuter. Vous pouvez gagner du temps en utilisant les modes d'exécution "grouper par origine" ou "contexte figé".

Le mode group-by-origin peut réutiliser des environnements d'exécution lorsque des groupes de centres d'intérêt sont joints 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 la vidéo explicative. Le mode de contexte congelé peut potentiellement réutiliser tous les environnements d'exécution, mais il peut nécessiter des modifications de votre script d'enchères. Pour en savoir plus, consultez la description de frozen-context dans la vidéo explicative.

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 de devoir 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.

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 extrait 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 s'exécutent 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 au moment de l'enchère (pour generateBid()) et également au moment de la création des rapports (pour reportWin()). Si les en-têtes de contrôle de la mise en cache ne sont pas définis, le navigateur extrait le même script deux fois, une fois pour chaque période.

Par conséquent, nous vous recommandons de définir des en-têtes de contrôle du cache sur tous vos scripts.

Réutiliser trustedBiddingSignalsUrls

La latence réseau et l'utilisation des ressources peuvent être très importantes. Réduire le nombre de récupérations de signaux d'enchères fiables en temps réel peut aider à réduire cette latence.

Les récupérés de signaux d'enchères fiables peuvent être combinés lorsque le trustedBiddingSignalsUrl est réutilisé dans 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 les en-têtes de contrôle de 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êcherait le cache sur les emplacements d'annonces lorsque les tailles des emplacements diffèrent, car l'URL demandée sera différente.

Récupérer des signaux d'enchères fiables en temps réel plus petits

La latence réseau peut être très importante, et cela est directement affecté 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.

Nous vous recommandons de stocker les données spécifiques aux annonces ou aux groupes 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 les données de signaux d'enchères approuvés en temps réel uniquement pour les signaux en temps réel, comme le budget de la campagne ou les boutons d'arrêt.

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

Ne renvoyez pas de signaux d'enchères approuvés pour les groupes de centres d'intérêt filtrés, comme décrit dans la section "Filtrer les groupes de centres d'intérêt des enchères dans votre service clé-valeur".

Prioriser les groupes 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 sont utilisés pour limiter le temps que les acheteurs doivent mettre à extraire leurs signaux d'enchères fiables et à exécuter leurs scripts d'enchères, il est essentiel qu'ils hiérarchisent leurs groupes d'intérêts afin que ceux qui ont le plus de chances de remporter l'enchère s'exécutent en premier. Par exemple, si perBuyerCumulativeTimeouts est défini sur 100 ms, que l'extraction des signaux d'enchères fiables d'un enchérisseur prend 50 ms, que chaque appel generateBid() prend 10 ms et qu'il dispose de 10 groupes d'intérêt 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 hiérarchiser ses groupes de centres d'intérêt de la manière suivante : de ceux qui ont le plus de chances de gagner à ceux qui en ont le moins.

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 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êts de la priorité la plus élevée à la plus faible, il peut intercaler des groupes d'intérêts provenant de différentes origines de jointure, ce qui peut empêcher 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 mise aux enchères Protected Audience en parallèle avec d'autres activités. Pour ce faire, appelez runAdAuction() dès que possible. Conscient que certaines entrées de runAdAuction() peuvent ne pas être disponibles dès le départ (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 transmettre aux vendeurs des métriques de latence per-buyer qui fournissent de nombreux insights sur le temps passé dans les enchères d'un vendeur. Les vendeurs peuvent utiliser ces métriques pour trouver des moyens d'optimiser leurs enchères, y compris pour savoir comment définir des délais avant expiration de la manière la plus efficace. Les vendeurs peuvent partager les métriques de latence d'un acheteur spécifique avec celui-ci pour l'aider à optimiser davantage ses campagnes.

Les enchérisseurs peuvent avoir des insights sur les performances des enchères de leurs propres groupes de centres d'intérêt, mais ils ne peuvent pas les comparer à celles d'autres enchérisseurs. Comparer les taux de gain et de refus d'enchères relatifs pour différents enchérisseurs peut aider à identifier les cas où des ressources de calcul d'enchères ont été gaspillées en raison de groupes d'intérêts qui n'ont jamais généré d'enchères viables ou d'enchères excessives avec des créations non approuvées.

Protection contre les scripts d'enchères lents

Les scripts d'enchères qui prennent trop de temps peuvent ralentir les enchères de l'API Protected Audience pour tous les acteurs impliqués. L'utilisation de délais d'inactivité permet d'éviter les enchères lentes tout en récupérant les revenus lorsque les enchères sont lentes.

Les vendeurs doivent utiliser perBuyerCumulativeTimeouts pour éviter les enchères lentes et continuer à accepter les enchères lorsque l'enchère est lente et atteint le délai avant 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êts ni sur la vitesse de generateBid() (par exemple, de nombreux groupes d'intérêts qui définissent des enchères rapidement et quelques groupes d'intérêts qui définissent des enchères lentement peuvent tous être traités avant le délai avant expiration).

Il est également recommandé d'utiliser le champ signal de la configuration des enchères pour implémenter un délai avant expiration global des enchères afin d'éviter les enchères trop longues lorsque l'extraction du signal de notation fiable 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.