Questions fréquentes sur les tests de la Privacy Sandbox

Réponses aux questions fréquentes sur les tests de la Privacy Sandbox.

Quels sont les principaux domaines de coordination entre les DSP et les SSP pour l'API Protected Audience ?

Voici les principaux aspects qui doivent être alignés:

  • Audit des créations: la SSP dispose-t-elle d'un point de terminaison permettant la préinscription des créations et est-elle compatible avec ce flux de travail ? Si ce n'est pas le cas, discutez avec la SSP des exigences de la DSP concernant la mise en œuvre d'un audit des créations pour les commandes de l'éditeur.
  • Méthodologie renderURL de la DSP. Certaines SSP peuvent exiger que renderURL inclue des métadonnées telles que seatID pour permettre l'attribution de scores et la facturation. Comment la DSP structure renderURL a des implications pour les cas d'utilisation critiques des SSP
  • ORTB
    • Demande d'enchère ORTB 2.X: indique comment la SSP signalera une mise aux enchères éligible à l'enchère au partenaire à la DSP.
    • Réponse à l'enchère ORTB 2.X: réponse de la DSP à la SSP pour l'enchère PA.
  • Données d'enchères sur l'appareil des enchères pour les annonces: de la SSP vers la DSP
    • auctionSignals: données que la SSP inclut dans les auctionConfig qui sont mises à la disposition de toutes les fonctions d'enchères des DSP.
  • Données d'évaluation des performances sur l'appareil: DSP vers SSP
    • Enchère: découvrez comment gérer les devises multiples. Chaque SSP peut avoir des exigences différentes.
    • Objet d'annonce (renvoyé par generateBid()): la SSP peut utiliser cet objet pour l'évaluation et les contrôles de l'éditeur. Les DSP et les SSP doivent s'aligner sur les données incluses et sur la structure des données.
  • Rapports d'enchères gagnantes: SSP vers DSP
    • Quel reportResult() de la SSP mettra à la disposition du reportWin() de la DSP.
  • Rapports post-enchères: DSP vers SSP. Contexte: la DSP doit recueillir les rapports post-enchères et les déléguer à la SSP. Si la SSP a besoin de métriques de clics, de vues et de visibilité, la DSP doit lui permettre de recevoir ces événements.
    • De quels rapports la SSP a-t-elle besoin ?
    • La méthodologie de mesure de cet événement (par exemple, la définition de la visibilité)
    • Implémentation DSP de l'appel reportEvent() pour répondre aux exigences des SSP
    • Implémentation SSP du registerAdBeacon() en alignant le nom de l'événement avec ce que la DSP déclenchera dans la création.

L'API Attribution Reporting est-elle prête et disponible pour les tests ?

L'API Attribution Reporting sera disponible pour tous les utilisateurs, et son activation est déjà en cours. Vous pourrez ainsi bientôt utiliser Attribution Reporting pour 100% du trafic. Notez qu'Attribution Reporting peut être utilisé avec toutes les annonces, pas seulement celles diffusées par Protected Audience.

Existe-t-il des exigences géographiques pour les tests ?

Il n'existe aucune exigence géographique. Il appartient à chaque testeur de déterminer les éléments géographiques à prendre en compte.

En quoi les recommandations de la CMA s'alignent-elles sur les tests gérés par Chrome ?

Les modes de test facilités par Chrome sont conformes aux directives de la CMA concernant les tests quantitatifs de la Privacy Sandbox. Dans les directives de la CMA, le groupe de traitement s'appuie sur les technologies de la Privacy Sandbox sans cookies tiers. Le groupe de contrôle 1 utilise des cookies tiers, et non la Privacy Sandbox. Le groupe de contrôle 2 n'utilise ni la Privacy Sandbox, ni les cookies tiers. Après la disponibilité générale, les technologies de la Privacy Sandbox seront disponibles pour l'ensemble du trafic Chrome, et la technologie publicitaire pourra choisir d'utiliser les technologies de la Privacy Sandbox pour certains groupes de population et pas pour d'autres. De plus, les technologies publicitaires peuvent exploiter le trafic de test géré par Chrome en mode A pour coordonner ces groupes de population entre plusieurs parties.

À partir du 4 janvier 2024, Chrome abandonnera les cookies tiers sur 1% du trafic. C'est ce que l'on appelle le trafic de test géré par Chrome pour le mode B dans la documentation pour les développeurs Chrome. Dans une petite partie du trafic des tests gérés par Chrome pour le mode B, les technologies de la Privacy Sandbox ne seront plus disponibles et les cookies tiers seront abandonnés. En combinant tous les modes de test gérés par Chrome ci-dessus, les technologies publicitaires pourront adapter leurs configurations de test aux consignes de test publiées par la CMA. Reportez-vous aux tests gérés par Chrome, qui définissent les modes A et B, et les consignes sur la CMA définissent les sections Contrôle 1, Contrôle 2 et Groupes de traitement (au point 11).

Y a-t-il un contact au sein de la CMA avec qui je pourrais m'adresser pour mieux comprendre les éléments requis pour l'envoi du rapport final ?

Vous pouvez envoyer un e-mail à l'équipe chargée des cas de la CMA à l'adresse [email protected] et en savoir plus sur ses conseils sur les propositions de test. Pour information, la CMA répertorie tous ses contacts en bas de la page Privacy Sandbox.

Pouvez-vous clarifier les métriques de réussite des tests quantitatifs ?

Les entreprises qui testent les API peuvent définir et partager autant de KPI supplémentaires qu'elles le souhaitent. Les résultats minimaux à partager sont indiqués dans les conseils sur la CMA.

Existe-t-il un seuil de volume pour les tests (par exemple, les ratios du groupe de contrôle par rapport aux ratios de modes ? Au-delà des conseils de la CMA concernant les tests, avez-vous d'autres conseils sur les KPI à tester ?

Les testeurs peuvent définir les exigences de volume / d'évolutivité. Nous vous recommandons de déterminer l'échelle en fonction de votre modèle économique et de vos objectifs. Votre approche des tests doit tenir compte des métriques pertinentes, ainsi que des modes A et B des tests gérés dans Chrome.

Quels types d'intégrations d'inventaires d'éditeurs sont compatibles avec les tests Protected Audience et TOPICS ?

La Privacy Sandbox ne limite pas les mécanismes d'intégration spécifiques. Pour obtenir les insights les plus pertinents, les tests de bout en bout de l'API Protected Audience doivent être coordonnés avec d'autres parties intégrées à la Privacy Sandbox afin de générer des impressions facturables.

Nous sommes conscients que les décisions d'intégration d'autres entreprises peuvent avoir un impact sur les types d'inventaires dans lesquels les produits Protected Audience et Topics peuvent être testés. La Privacy Sandbox recommande de se coordonner avec les partenaires de test sur les objectifs.

Comment Google facilitera-t-il la connexion entre les DSP et les SSP de test ?

Les entreprises qui effectuent des tests sont publiques sur GitHub avec leurs coordonnées pour la coordination. La Privacy Sandbox encourage aussi les testeurs à contacter directement les équipes existantes pour coordonner les tests.