API Protected Audience (anciennement FLEDGE)

Dans le cadre de la Privacy Sandbox, Chrome a proposé l'API Protected Audience, une API dans le navigateur qui permet aux annonceurs et aux entreprises d'ad tech de diffuser des annonces ciblées par groupe d'intérêt sans s'appuyer sur des cookies tiers, tout en protégeant les utilisateurs contre le suivi multisite.

Chrome exécute une phase d'évaluation de l'origine pour l'API Protected Audience. Les acheteurs Authorized Buyers peuvent participer aux tests de l'API Protected Audience sur l'inventaire des éditeurs Ad Manager. En testant l'API Protected Audience, les enchérisseurs peuvent :

  • Itérez sur les flux de l'API Protected Audience et découvrez leur efficacité.
  • Faites part de vos commentaires sur les améliorations potentielles de l'API dans les forums publics, par exemple sur GitHub.
  • Préparez-vous à prendre en charge la publicité personnalisée via l'API sans dépendre des cookies tiers.

Les acheteurs Authorized Buyers intéressés par les tests peuvent consulter la section sur l'intégration pour en savoir plus.

Résumé du flux de diffusion

Voici un résumé du flux de diffusion d'annonces Protected Audience pour les partenaires Authorized Buyers :

Schéma de flux

  1. Un enchérisseur travaille avec ses annonceurs pour maintenir des groupes d'intérêt pour chacun d'eux. Souvent, les annonceurs ajoutent le tag d'un enchérisseur à leur page pour ajouter un navigateur à des groupes d'intérêt.
  2. Un utilisateur final consulte la page d'un annonceur. La page peut contenir le tag de l'enchérisseur.
  3. La balise de l'enchérisseur appelle l'API Protected Audience joinAdInterestGroup(). Cet appel demande au navigateur d'ajouter l'utilisateur à un groupe d'intérêt.
  4. L'utilisateur final consulte une page Web d'un éditeur. Le navigateur de l'utilisateur demande le tag d'emplacement publicitaire de l'éditeur Google.
  5. Le tag d'emplacement publicitaire Google Publisher Tag envoie une demande d'annonce contextuelle à un serveur Google.
  6. Google envoie des demandes d'enchères contextuelles aux enchérisseurs participants. Pour en savoir plus, consultez la section Modifications apportées aux demandes d'enchères.
  7. L'enchérisseur renvoie une réponse d'enchère incluant le message InterestGroupBidding, qui est nécessaire pour participer aux enchères du groupe d'intérêt. Dans OpenRTB, cela est spécifié avec le champ BidResponse.ext.igbid, et dans le protocole RTB de Google obsolète, cela est spécifié avec le champ BidResponse.interest_group_bidding. Si l'enchérisseur ne spécifie pas ces informations, Google n'inclut pas son origine dans interestGroupBuyers dans la configuration de l'enchère. InterestGroupBidding peut également contenir des signaux spécifiques à l'acheteur facultatifs qui seront transmis à la fonction d'enchères de l'enchérisseur lors de l'enchère dans le navigateur. Dans OpenRTB, cela est spécifié avec le champ BidResponse.ext.igbid.igbuyer.buyerdata, et dans le protocole RTB Google obsolète, cela est spécifié avec le champ BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals. Pour en savoir plus, consultez la section Modifications apportées aux réponses aux enchères.
  8. Google exécute la mise aux enchères côté serveur et renvoie une réponse à l'enchère au navigateur. Les enchères côté serveur prennent en compte les enchères côté serveur traditionnelles. La réponse à l'enchère peut contenir des informations sur une enchère gagnante contextuelle (le cas échéant).
  9. La réponse à l'enchère contient une configuration d'enchères pour les enchères dans le navigateur. Cela peut inclure des signaux contextuels de chaque acheteur participant (qui ont été envoyés précédemment via buyerdata d'OpenRTB ou per_buyer_signals du protocole RTB Google obsolète), des informations sur le gagnant contextuel et des paramètres d'éligibilité des enchères.
  10. Le tag d'éditeur Google appelle l'API Protected Audience runAdAuction() pour lancer l'enchère de groupe d'intérêt sur l'appareil. Google n'inclut que les acheteurs qui ont été inclus en tant que InterestGroupBuyer dans InterestGroupBidding lors de la configuration des enchères.
  11. Google transmet les signaux spécifiques à l'acheteur facultatifs de chaque enchérisseur éligible à la configuration des enchères Protected Audience.
  12. Si les groupes d'intérêt d'un enchérisseur donné ont spécifié trustedBiddingSignalsUrl, le navigateur envoie une requête à trustedBiddingSignalsUrl de chaque groupe pour récupérer les signaux en temps réel pour chaque groupe. Pour en savoir plus, consultez les spécifications de l'API Protected Audience.
  13. Le navigateur appelle la fonction generateBid() de l'enchérisseur pour chaque groupe d'intérêt qui a activé la fonctionnalité et qui est éligible à participer aux enchères dans le navigateur. Cette étape calcule l'enchère et sélectionne une création. generateBid() a accès aux signaux d'acheteur facultatifs fournis par l'enchérisseur et aux signaux d'enchères fiables pour le groupe d'intérêt donné.
  14. Le navigateur appelle la fonction scoreAd() du vendeur (Google, dans ce cas) pour attribuer un classement à chaque enchère dans les enchères publicitaires du groupe d'intérêt. Les enchères sont classées et filtrées en fonction des protections de l'éditeur, des règles relatives aux annonces et d'autres contraintes.
  15. Le navigateur lance une enchère avec les enchères de groupes d'intérêt éligibles. L'enchère contextuelle la mieux classée participe à la mise aux enchères dans le navigateur.
  16. Après les enchères, si un groupe d'intérêt l'emporte, le navigateur appelle les fonctions reportResult() du vendeur et reportWin() de l'enchérisseur pour informer chaque partie du gagnant des enchères dans le navigateur.
  17. Si une annonce de groupe d'intérêt est gagnante, le tag d'éditeur Google affiche l'annonce dans un iframe.

Détails du flux de diffusion

Avant la diffusion d'annonces

Examen des créations

Les créations doivent être examinées et approuvées par Google avant de pouvoir être diffusées à partir des enchères Protected Audience dans le navigateur. Vous pouvez envoyer des créations pour examen via l'API Real-time Bidding ou l'analyse automatique des créations. Les créations pour les enchères d'annonces de groupes d'intérêt Protected Audience dans le navigateur doivent inclure renderUrls pour examen.

Exigences concernant renderUrls :

  • Le renderUrl envoyé via l'API doit correspondre au renderUrl utilisé dans l'enchère d'annonces du groupe d'intérêt.
  • Chaque renderUrl ne peut représenter qu'un seul annonceur ou une seule campagne publicitaire. Un renderUrl donné ne peut pas être utilisé pour diffuser des annonces au nom de plusieurs annonceurs. Chaque renderUrl doit correspondre à une seule création.
  • Le renderUrl doit être accessible et récupérable par les systèmes d'examen des créations hors connexion de Google pendant sept jours maximum après la dernière enchère sur l'annonce.
Real-time Bidding API

Les enchérisseurs peuvent utiliser l'API Real-Time Bidding pour importer des créations pour les enchères par groupe d'intérêt.

Analyse automatique des créations

Les enchérisseurs peuvent configurer l'analyse automatique des créations qui ne sont pas importées via l'API Real-time Bidding.

Si vous configurez l'analyse automatique des créations, Google les recherche dans les enchères du navigateur et les analyse automatiquement afin qu'elles puissent être utilisées dans de futures enchères.

Pour activer l'analyse automatique des créations :

  • Ajoutez toutes les origines renderUrl de la création du groupe d'intérêt au compte Authorized Buyers.

  • Ajoutez les en-têtes HTTP personnalisés suivants à la réponse HTTP de la création :

    Authorized-Buyers-Creative-ID

    chaîne

    ID de la création spécifique à l'acheteur. La longueur maximale de l'ID de création est de 128 octets.
    Authorized-Buyers-Click-Through-URLs

    chaîne

    Ensemble des URL de destination déclarées pour la création, encodées selon la norme RFC2396.

Exemple :

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
Expiration des créations

Les créations sont approuvées pendant 15 jours. Si vous envoyez des créations avec l'API Real-time Bidding, vous devrez les renvoyer au bout de 15 jours. Si vous vous appuyez sur l'analyse automatique des créations, le processus d'analyse les analysera à nouveau automatiquement.

ID de rapport d'acheteur

Vous pouvez répartir les métriques de reporting (comme les impressions) à l'aide des dimensions fournies par l'acheteur (par exemple, l'ID de campagne ou l'ID d'annonceur). Pour ajouter une dimension aux dépenses du groupe d'intérêt, spécifiez un buyerAndSellerReportingId pour votre annonce lorsque vous ajoutez l'appareil de l'utilisateur au groupe d'intérêt. Pour en savoir plus, consultez la documentation Protected Audience.

Voici un exemple d'ajout de buyerAndSellerReportingId à la configuration du groupe d'intérêt :

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

buyer_reporting_id apparaîtra comme une nouvelle dimension dans l'outil de création de rapports pour les acheteurs autorisés, sous le nom Dimension "ID de rapport de l'acheteur".

Enchères côté serveur

Modifications des demandes d'enchères

Voici les premières versions des protocoles compatibles à utiliser dans le test :

Indiquer la prise en charge des enchères de groupes d'intérêt

Les demandes d'enchères comportent de nouveaux champs pour indiquer la compatibilité avec les enchères de groupes d'intérêt :

  • OpenRTB :
    • BidRequest.imp.ext.ae
    • BidRequest.imp.ext.igbid
  • Protocole RTB Google (obsolète) :
    • BidRequest.adslot.supported_auction_environment
    • BidRequest.adslot.interest_group_bidding_allowed

Vous pouvez utiliser ce champ pour faire la différence entre les opportunités d'impression qui acceptent les enchères de groupe d'intérêt Protected Audience dans le navigateur et celles qui n'acceptent que les enchères d'échange traditionnelles côté serveur. L'énumération AuctionEnvironment peut avoir les valeurs suivantes :

  • SERVER_SIDE_AUCTION (JSON OpenRTB : 0) : l'enchère qui détermine l'annonce gagnante s'exécute sur les serveurs de la place de marché.
  • ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON : 1) : requêtes compatibles avec Protected Audience, dans lesquelles une enchère contextuelle est exécutée sur les serveurs de la place de marché, et l'enchère du groupe d'intérêt et l'enchère finale sont exécutées dans le navigateur.
  • SERVER_SIDE_INTEREST_GROUP_AUCTION (JSON OpenRTB : 3) : l'enchère contextuelle s'exécute sur les serveurs de la place de marché. La logique d'enchères pour les enchères de groupes d'intérêt et la logique de scoring pour déterminer l'annonce gagnante finale s'exécutent dans les serveurs d'enchères et de mise aux enchères.
Indiquer la taille de l'emplacement publicitaire Protected Audience

La demande d'enchère inclut les champs suivants pour vous fournir la taille de l'emplacement publicitaire d'audience protégée :

  • OpenRTB :
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height
  • Protocole RTB Google (obsolète) :
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height

Ces champs indiquent la taille de l'emplacement publicitaire pour l'enchère Protected Audience en pixels.

Cette taille peut différer de celles de la demande contextuelle, comme celles indiquées dans les champs BidRequest.imp.banner.format.w et BidRequest.imp.banner.format.h d'OpenRTB, ou dans les champs BidRequest.adslot.width et BidRequest.adslot.height du protocole Google RTB obsolète.

La demande contextuelle peut avoir plusieurs tailles. L'annonce gagnante de l'enchère sur l'appareil ne doit remplir qu'un seul emplacement de taille fixe.

Indiquer la capacité de rendu des annonces Protected Audience

Les annonces Protected Audience peuvent s'afficher ou non en fonction de l'étape d'intégration actuelle (voir l'expérience de non-affichage). Le champ render_interest_group_ads de la demande d'enchère indique si l'annonce Audience protégée gagnante sera affichée.

  • OpenRTB : BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
  • Protocole RTB Google (obsolète) : BidRequest.adslot.interest_group_auction.render_interest_group_ads
Minimiser la dépendance aux identifiants utilisateur

Les demandes d'enchères contextuelles incluses dans les tests de l'API Protected Audience peuvent continuer à comporter des identifiants traditionnels basés sur les cookies lorsqu'ils sont disponibles dans le navigateur, tels que les champs BidRequest.user.id et BidRequest.user.buyerid, ou BidRequest.google_user_id et BidRequest.hosted_match_data dans le protocole RTB Google obsolète. La présence de tels identifiants dans les demandes d'enchères est soumise aux règles de confidentialité existantes. Nous vous recommandons de ne pas vous fier aux identifiants basés sur les cookies pour le ciblage et les enchères pendant les tests. Vous serez ainsi mieux préparé à acheter efficacement lorsque les cookies tiers ne seront plus disponibles.

Google peut également effectuer des tests à petite échelle dans lesquels les identifiants basés sur les cookies sont masqués dans les demandes d'enchères incluses dans les tests de l'API Protected Audience. Cela permet d'évaluer l'impact potentiel de l'abandon des cookies tiers.

Pour vous préparer à l'arrêt des cookies tiers (3PCD) en 2024, Chrome propose désormais des tests gérés par Chrome.

Les sites et les fournisseurs peuvent utiliser les tests facilités par Chrome pour tester leurs systèmes dans le cadre de la 3PCD. Dans le test, les navigateurs Chrome sont attribués à un groupe de test 3PCD, en mode A ou en mode B. Chaque navigateur se voit attribuer un libellé cohérent correspondant à un groupe de test 3PCD spécifique auquel vous pouvez accéder via l'API Chrome intégrée au navigateur.

Google transmet le libellé non modifié de l'API Chrome dans la demande d'enchère RTB. En raison des petites parts de trafic d'un libellé individuel, Google n'inclut pas toujours le libellé dans les contextes où la confidentialité est limitée.

Voici les champs dans lesquels vous pouvez voir le libellé :

  • OpenRTB : BidRequest.device.ext.cdep
  • Protocole RTB Google (obsolète) : BidRequest.device.cookie_deprecation_label

Modifications des réponses aux enchères

Indiquer la participation aux enchères des groupes d'intérêt

Vous êtes responsable d'indiquer explicitement votre intention de participer à l'enchère dans le navigateur en renvoyant l'objet InterestGroupBidding dans la réponse aux enchères contextuelles :

  • OpenRTB : BidResponse.ext.igbid
  • Protocole RTB Google (obsolète) : BidResponse.interest_group_bidding

Vous devez fournir une réponse d'enchère contextuelle. La réponse n'est pas tenue d'inclure une enchère contextuelle. L'objet InterestGroupBidding doit contenir le origin pour chaque InterestGroupBuyer, qui doit correspondre à l'une des origines configurées par l'enchérisseur pour son compte. Le origin est ajouté au interestGroupBuyers de la configuration d'enchères lorsque le tag Google Publisher Tag appelle runAdAuction().

Propager les signaux contextuels de l'acheteur

Vous pouvez inclure les signaux d'un acheteur dans la réponse aux enchères contextuelles. Google les propage en tant qu'objet JSON à sa fonction d'enchères sur l'appareil via l'argument perBuyerSignals. Ces informations peuvent être incluses dans la réponse à l'enchère avec les champs suivants, en fonction du protocole :

  • OpenRTB : BidResponse.ext.igbid.igbuyer.buyerdata
  • Google RTB (obsolète) : BidResponse.interest_group_bidding.per_buyer_signals
Propager les signaux de rendu contextuel de l'acheteur

Les créations de groupes d'intérêt peuvent utiliser des signaux contextuels limités lors du rendu en envoyant ces signaux via la réponse aux enchères contextuelles et en les recevant sur la requête d'URL de rendu à l'aide de l'expansion de macros. Par exemple, les signaux de rendu pourraient être utilisés pour personnaliser l'apparence d'une création afin d'améliorer ses performances dans le contexte d'un emplacement publicitaire ou d'une page d'éditeur donnés.

Vous pouvez inclure les signaux de rendu d'un acheteur sérialisés sous forme de chaîne compatible avec les URL dans la réponse aux enchères contextuelles. Google les remplacera dans l'URL de rendu du groupe d'intérêt gagnant en construisant la macro ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}.

Les signaux de rendu peuvent être spécifiés dans la réponse à l'enchère avec les champs suivants, selon le protocole :

  • OpenRTB : BidResponse.ext.igbid.igbuyer.rsig
  • Google RTB (obsolète) : BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

La réponse à l'enchère peut inclure jusqu'à trois ensembles de signaux de rendu avec différents suffixes de macro pour distinguer les différents signaux. Par exemple, un suffixe peut être utilisé pour faire correspondre un ensemble spécifique de signaux applicables uniquement aux créations avec la macro correspondante dans leur URL de rendu, ce qui réduit la taille du transfert de données.

L'acheteur du groupe d'intérêt ne sera pas autorisé à participer à l'enchère Protected Audience si les signaux ne sont pas compatibles avec les URL, si les suffixes de macros ne sont pas uniques ou si plus de trois ensembles de signaux sont fournis.

Spécifier le prix d'enchère maximal dans le navigateur

Dans la proposition Protected Audience, le calcul des enchères et les enchères finales devraient s'exécuter localement sur l'appareil. Cela peut créer des vecteurs d'utilisation abusive potentiels qui peuvent affecter l'intégrité des résultats finaux des enchères, comme le prix de l'enchère gagnante.

En tant que mesure d'atténuation prise en charge lors des tests de l'API Protected Audience par Google pour ses partenaires RTB, vous pouvez spécifier une valeur d'enchère maximale attendue dans chaque réponse aux enchères contextuelles. L'enchère maximale attendue correspond au prix d'enchère maximal que votre fonction d'enchères est censée renvoyer. Si l'enchère gagnante signalée par l'enchère dans le navigateur dépasse ce montant, elle n'est pas comptabilisée comme événement facturable. Cette approche est susceptible d'être modifiée.

Dans la réponse à l'enchère, vous pouvez spécifier la valeur d'enchère maximale attendue dans les champs suivants :

  • OpenRTB : BidResponse.igbid.igbuyer.maxbid(exprimé en unités monétaires CPM)
  • Protocole Google RTB (obsolète) : BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (exprimé en microCPM)
Attribuer des impressions à plusieurs comptes

Un enchérisseur doit sélectionner un ID de facturation pour attribuer les impressions de son enchère de groupe d'intérêt à l'aide des champs suivants :

  • OpenRTB : BidResponse.igbid.igbuyer.billing_id
  • Protocole Google RTB (obsolète) : BidResponse.interest_group_bidding.interest_group_buyers.billing_id

L'ID de facturation sélectionné doit être un ID de facturation éligible de la demande d'enchère :

  • OpenRTB : BidRequest.imp.ext.billing_id
  • Protocole Google RTB (obsolète) : BidRequest.adslot.matching_ad_data.billing_id

Si l'ID de facturation auquel attribuer les impressions d'enchères de groupes d'intérêt n'est pas fourni, l'enchérisseur ne participera pas aux enchères Protected Audience.

Les comptes enfants peuvent comporter jusqu'à deux ID de facturation. L'acheteur peut utiliser un ID de facturation pour les dépenses contextuelles et l'autre pour les dépenses liées aux groupes d'intérêt. Contactez votre responsable de compte si vous souhaitez configurer deux ID de facturation pour un compte enfant.

Il est possible de définir un budget quotidien pour chaque ID de facturation. Contactez votre responsable de compte pour définir le budget quotidien des ID de facturation des comptes enfants.

Les ID de facturation de tous les comptes enfants disposant d'un budget disponible et pouvant enchérir sur l'impression apparaissent dans la demande d'enchère pour la sélection de l'attribution des dépenses. Contactez votre responsable de compte pour modifier le budget d'un ID de facturation de groupe d'intérêt.

Pendant les enchères dans le navigateur

Générer des enchères dans le navigateur

Utilisez generateBid() pour générer des enchères dans le navigateur.

Google fournit les paramètres suivants :

  • auctionSignals : vide
  • perBuyerSignals : objet JavaScript contenant les mêmes signaux que ceux fournis par l'enchérisseur dans la réponse contextuelle

Les paramètres suivants sont renvoyés :

  • ad : Google ignore ce champ.
  • bid : enchère numérique participant à la mise aux enchères. Doit être exprimé en CPM (et non en micros).
  • render : URL affichée pour présenter la création si l'enchère remporte l'enchère. Google doit examiner et approuver cette URL, sinon elle sera filtrée de l'enchère.
  • allowComponentAuction : doit être true. Google permet actuellement de tester les enchères multiseller.

Exemple :

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

Pour en savoir plus sur la fonction generateBid(), consultez la section Enchères sur l'appareil de la spécification Protected Audience.

Devise de l'enchère

Les enchères dans le navigateur sont placées en unités de CPM de la devise d'enchère choisie.

La devise de l'enchère doit être indiquée à la fois dans la réponse contextuelle de l'enchère et dans la valeur renvoyée de generateBid. Elle doit être un code alpha ISO 4217 valide, tel que "USD", "EUR" ou "JPY".

Dans OpenRTB, utilisez le nouveau champ cur dans l'objet InterestGroupBuyer de l'extension de réponse aux enchères de Google.

Exemple :

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

Dans le protocole RTB Google, utilisez le nouveau champ currency dans le message InterestGroupBuyer de la réponse à l'enchère.

Exemple :

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

Les fonctions generateBid des enchérisseurs doivent renvoyer des enchères dans la même devise que celle indiquée dans la réponse aux enchères contextuelles. Renseignez la nouvelle propriété bidCurrency dans la valeur renvoyée de generateBid :

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

Si la devise de la réponse aux enchères contextuelles est différente de celle renvoyée par generateBid, ou si l'une d'elles renvoie une devise non valide, l'enchère sera filtrée avant la mise aux enchères.

Contrôles de la qualité des annonces

L'application du règlement sur les créations et des commandes de l'éditeur peut être plus restrictive pour les enchères de groupes d'intérêt dans le navigateur pendant les tests de l'API Protected Audience pour les partenaires RTB.

Assistance concernant la loi sur les services numériques

En vertu de l'article 26 du règlement sur les services numériques, les éditeurs peuvent exiger des acheteurs qu'ils affichent des informations sur la transparence dans les annonces. Lorsque le paramètre "Demander aux acheteurs de ne diffuser que des annonces comportant des informations sur la transparence DSA sur mon site ou dans mon application dans l'EEE" est activé par un éditeur, les acheteurs de groupes d'intérêt peuvent déterminer pour quelles opportunités ils devront afficher la transparence de l'acheteur en notant les valeurs de BidRequest.regs.dsa.required et BidRequest.dsa.pubrender dans la demande d'enchère (BidRequest.dsa.dsa_support et BidRequest.dsa.publisher_rendering_support respectivement dans l'ancien protocole Google RTB).

Lorsqu'un enchérisseur qui souhaite participer aux enchères de l'API Protected Audience reçoit dans la demande d'enchère un signal indiquant que la transparence DSA doit apparaître pour les annonces diffusées via l'API Protected Audience, il doit évaluer s'il peut afficher correctement les informations requises et le spécifier en définissant BidResponse.ext.igbid.igbuyer.dsaadrender (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render dans le protocole Google RTB obsolète). Sinon, l'acheteur ne sera pas inclus dans l'enchère de l'API Protected Audience.

Pour en savoir plus sur la transparence des annonces en vertu du règlement sur les services numériques, consultez l'article du Centre d'aide sur l'application du règlement sur les services numériques.

Filtrage des enchères

Google applique les paramètres de l'éditeur et les Règles relatives aux annonces lors des enchères sur l'appareil.

Après une enchère dans le navigateur

Signaler le résultat de l'enchère à l'acheteur : reportWin()

Google ne renseigne pas les arguments suivants :

  • auctionSignals
  • sellerSignals

Utilisez reportWin() pour communiquer le résultat de l'enchère à l'acheteur.

Pour en savoir plus, consultez la section Rapports des acheteurs sur les événements de rendu et d'annonce de la présentation de l'API Protected Audience.

Macros

Le renderUrl qui fait référence à la création de l'API Protected Audience peut inclure un ou plusieurs espaces réservés, appelés macros. Une fois l'enchère du groupe d'intérêt terminée, mais avant le rendu, les macros sont remplacées par les valeurs correspondantes. renderUrl utilisé dans l'enchère sur l'appareil peut inclure les macros suivantes :

${GDPR} La valeur est 0 si le RGPD ne s'applique pas et 1 s'il s'applique. Consultez la documentation.
${GDPR_CONSENT_XXXX} Cette macro est remplacée par la chaîne TC (Transparency & Consent) associée à la demande d'annonce. Si la chaîne TC est vide ou incorrecte, cette macro ne sera pas remplacée.

Utilisez cette macro pour transmettre la chaîne TC à un fournisseur enregistré sur la LGF de l'IAB dans une URL. Remplacez XXXX par l'ID du fournisseur enregistré sur la LGF de l'IAB. Si la chaîne TC est vide ou incorrecte, cette macro ne sera pas remplacée.

Les créations qui incluent la macro ${GDPR_CONSENT_XXXX} peuvent être bloquées si le fournisseur enregistré sur la LGF de l'IAB associé à l'ID LGF de l'IAB que vous avez inséré n'a pas obtenu le consentement des utilisateurs.

La macro ${GDPR_CONSENT_XXXX} ne doit apparaître qu'une seule fois dans le renderUrl.
${ADDL_CONSENT} Cette macro est remplacée par la chaîne de consentement supplémentaire associée à la demande d'annonces.
${AD_WIDTH}, ${AD_HEIGHT) Ces macros permettent d'insérer la largeur et la hauteur de l'emplacement publicitaire.
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

Macro contenant les signaux de l'acheteur au moment du rendu spécifiés dans la réponse à l'enchère.

Remplacez l'espace réservé buyer.origin.example par l'origine de l'acheteur du groupe d'intérêt, qui doit correspondre à interest_group_buyers.origin dans la réponse à l'enchère. Vous pouvez inclure un _OPTIONAL_SUFFIX pour fournir jusqu'à trois valeurs de signal de rendu différentes.

Comptabilisation des impressions

Lors des tests de l'API Protected Audience avec les partenaires RTB, Google comptabilisera les impressions lorsque le navigateur appellera sa fonction reportResult() et récupérera ensuite l'URL de rapport de Google dans un appel à sendReportTo().

Étant donné que l'événement utilisé par Google pour comptabiliser les impressions dans les enchères Protected Audience dans le navigateur peut être différent de celui utilisé pour comptabiliser les impressions par ses partenaires acheteurs RTB, le nombre d'impressions peut varier.

L'un des objectifs de Google lors des tests de l'API Protected Audience est d'identifier et de réduire ces écarts.

Attribution des impressions facturables

Toutes les dépenses d'un enchérisseur provenant des enchères Protected Audience dans le navigateur sont attribuées à un seul compte d'enchérisseur en fonction du mappage des origines des propriétaires de groupes d'intérêt configurées pour l'enchérisseur. Il n'est pas possible d'attribuer des dépenses à différents comptes enfant d'un enchérisseur.

Limite de budget quotidien

Pendant les tests de l'API Protected Audience, chaque compte dispose d'une limite de budget quotidien pour les dépenses Protected Audience au niveau du compte. Cette limite permet de réduire les risques dans l'environnement d'enchères dans le navigateur. Une fois la limite de budget quotidien atteinte, le compte ne reçoit plus de demandes d'enchères éligibles à Protected Audience.

Le compte peut continuer à participer aux enchères contextuelles côté serveur après avoir atteint la limite Protected Audience. Par exemple, un compte enchérisseur qui atteint la limite Protected Audience peut recevoir une demande d'enchère avec auction_environment = SERVER_SIDE_AUCTION (JSON OpenRTB : 0), même si la demande d'enchère est éligible à une enchère Protected Audience.

Commentaires en temps réel et enchère gagnante minimale

Les enchérisseurs qui ont activé les informations en temps réel recevront des informations sur les acheteurs de groupes d'intérêt dont l'inclusion dans une enchère Protected Audience sur l'appareil a été demandée. Chaque acheteur de groupe d'intérêt spécifié par un enchérisseur dans une réponse aux enchères recevra un objet de commentaires, quel que soit le nombre d'enchères qu'il place dans l'enchère Protected Audience. Les informations suivantes seront disponibles dans l'objet de commentaires des acheteurs sur le groupe d'intérêt :

  • Le type de commentaire de l'objet de commentaire sera INTEREST_GROUP_BUYER_FEEDBACK.
  • Origine de l'acheteur du groupe d'intérêt.
  • Enchère gagnante minimale pour l'acheteur du groupe d'intérêt afin de remporter l'enchère globale.
  • Enchère gagnante minimale pour l'acheteur du groupe d'intérêt afin de battre l'enchère la mieux classée du composant côté serveur de la mise aux enchères globale.
  • Code d'état de l'acheteur de groupes d'intérêt. Les codes d'état possibles sont définis dans interest-group-buyer-status-codes.txt.

Pour connaître les noms de champs spécifiques, consultez la documentation du protocole RTB Authorized Buyers et des extensions OpenRTB.

Notification de commentaires sur les enchères

Chrome fournit une API de débogage temporaire pour l'API Protected Audience. Elle permet à Ad Manager d'envoyer des notifications de débogage de serveur à serveur en temps réel, qui contiennent des commentaires sur une enchère Protected Audience. Cette notification indiquera les raisons pour lesquelles des enchères ont pu être filtrées lors des enchères Protected Audience dans le navigateur, ainsi que d'autres informations sur une enchère décrites ci-dessous.

Les enchérisseurs peuvent contacter leur responsable de compte pour configurer une URL statique qui sera utilisée pour envoyer des notifications de commentaires sur les enchères de débogage Protected Audience. Cette URL statique sera récupérée à partir des serveurs Google, et les macros sélectionnées seront remplacées une fois l'enchère Protected Audience terminée. Les macros suivantes sont acceptées :

  • %%GOOGLE_QUERY_ID%% : cette macro est remplacée par l'ID de requête Google envoyé dans la demande d'enchère contextuelle compatible avec Protected Audience. Dans le protocole OpenRTB, cela est spécifié avec BidRequest.ext.google_query_id, tandis que le protocole Google RTB obsolète utilise BidRequest.google_query_id.
  • %%INTEREST_GROUP_OWNER%% : origine du propriétaire du groupe d'intérêt.
  • %%BID_CPM%% : prix de l'enchère au CPM spécifié par l'acheteur dans la fonction generateBid().
  • %%RENDER_URL%% : URL de rendu de la création.
  • %%STATUS%% : code d'état si l'enchère a été refusée dans scoreAd(). Les valeurs sont des codes d'état de la création.

Voici un exemple d'URL statique qu'un enchérisseur peut fournir à son responsable de compte :

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

La notification de commentaires sur les enchères est une fonctionnalité temporaire qui dépend de l'API ForDebuggingOnly temporaire de Chrome.

TURTLEDOVE au niveau des produits

Les annonces composées de plusieurs éléments ou TURTLEDOVE au niveau produit (PLTD) sont acceptées pour les partenaires RTB Google lors des tests de l'API Protected Audience. Si vous prévoyez de tester PLTD lors de l'intégration, informez-en votre responsable de compte, car des ressources et une configuration supplémentaires sont nécessaires.

Intégration

Voici comment tester l'API Protected Audience :

Étapes

  1. Remplissez le formulaire de demande pour participer à la phase de test de l'API Protected Audience.
  2. Une fois le formulaire de demande envoyé, contactez votre responsable de compte ou envoyez une demande à l'aide du Centre d'aide Authorized Buyers.
  3. Une fois le compte configuré, Google et le partenaire peuvent vérifier l'intégration en suivant les étapes décrites dans Étapes de test.

Vérification des créations

Pour enchérir avec des annonces au niveau produit (annonces composées de plusieurs éléments) dans les enchères de l'API Protected Audience, respectez les exigences suivantes :

  • Incluez le paramètre de requête &pltd=True dans le renderUrl du conteneur du composant d'annonce (également appelé renderUrl de premier niveau) pour distinguer les renderUrls de premier niveau lors de l'examen des créations.
  • Affichez une création représentative lorsque le conteneur de l'annonce du composant est récupéré pour un examen de la création par Google. Pour savoir quand un rendu d'annonce représentatif doit être renvoyé, vous pouvez vous référer au paramètre de requête validation=True défini par le système d'examen des créations de Google.

Checklist d'intégration

  • Configurez un point de terminaison de demande d'enchère qui remplira les champs associés à l'API Protected Audience dans la réponse aux enchères contextuelles (par exemple, interest_group_bidding).
  • Implémentez le taggage sur les pages de l'annonceur pour associer le navigateur de l'utilisateur au groupe d'intérêt.
  • Implémentez generateBid() et reportWin().
  • Sélectionnez les origines des propriétaires de groupes d'intérêt et ajoutez-les au compte Authorized Buyers.
    • Les origines des propriétaires de groupes d'intérêt doivent correspondre aux origines où les fonctions generateBid() sont hébergées.
    • Contactez le responsable de compte ou envoyez une demande à l'aide du Centre d'aide pour les acheteurs autorisés pour effectuer cette étape.
  • Configurez le préciblage pour l'inventaire pertinent pour les tests de l'API Protected Audience.
  • Envoyez les créations pour examen et approbation via l'API Creatives.
  • (Facultatif) Configurez les points de terminaison des signaux d'enchères de confiance.
  • (Facultatif) Configurez une page de test pour les annonceurs qui permet aux ingénieurs Google d'ajouter leur navigateur aux groupes d'intérêt appartenant à l'origine de votre acheteur de groupes d'intérêt. Cela nous permet de déclencher manuellement les enchères Protected Audience.
  • (Facultatif) Activez les commentaires en temps réel dans votre compte pour recevoir des commentaires sur les acheteurs de groupes d'intérêt qui ont demandé à être inclus dans une enchère Protected Audience.
  • (Facultatif) Contactez votre responsable de compte pour configurer une URL statique afin de recevoir une notification de serveur à serveur qui fournit des commentaires sur les enchères Protected Audience concernant l'état d'une enchère d'une enchère Protected Audience sur l'appareil. Cela vous aidera à déboguer les problèmes inattendus. Pour en savoir plus, consultez la notification de commentaires sur les enchères.

Étapes de test

Étape 1 : Test manuel

Voici comment déclencher manuellement une enchère Protected Audience, s'assurer que l'annonce peut être affichée et enregistrer l'impression :

  1. Utilisez Chrome 101 ou version ultérieure.
  2. Activez l'API Privacy Sandbox et Fenced Frame à l'aide de chrome://flags/#privacy-sandbox-ads-apis et chrome://flags/#enable-fenced-frames. Pour en savoir plus, consultez Tester la Privacy Sandbox.
  3. Envoyez une création pour approbation à l'aide de l'API Real-time Bidding.
  4. Utilisez la page de l'annonceur fournie par l'enchérisseur pour ajouter un navigateur au groupe d'intérêt appartenant à l'enchérisseur.

  5. Utilisez la page de test pour les éditeurs fournie par Google afin de déclencher une enchère Protected Audience :

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

    Le groupe d'intérêt dans le navigateur doit définir une enchère suffisamment élevée pour remporter les enchères, car il peut être en concurrence avec des enchères côté serveur classiques. Google fournit également une page de test dédiée pour chaque éditeur partenaire, où seul le partenaire concerné peut participer aux enchères. Il peut être plus facile de remporter de manière fiable des enchères dans le navigateur sur une page spécifique à un partenaire.

  6. Effectuez les vérifications suivantes :

    1. L'annonce gagnante attendue est affichée.
    2. Le résultat des enchères est envoyé côté serveur, ce qui signifie que l'enchérisseur gagnant reçoit un ping de reportWin().
    3. La console de la page de l'éditeur de test enregistre un message de débogage pour chaque enchère avec les informations suivantes :
      • renderUrl : URL de rendu de l'enchère.
      • interestGroupOwner : propriétaire du groupe d'intérêt de l'enchère.
      • accepted : ce champ est défini sur true si l'enchère a été acceptée et sur false si elle a été refusée par scoreAd().
      • externalBidStatus : code d'état si l'enchère a été refusée dans scoreAd(). Les valeurs sont des codes d'état de la création.

Étape 2 : (Facultatif) Test sans rendu

Une fois que Google et le partenaire ont vérifié manuellement que le partenaire peut participer à l'enchère Protected Audience, Google l'autorise à passer à la phase de test suivante.

Google alloue une petite quantité de trafic en direct pour exécuter les enchères Protected Audience. Google et le partenaire n'ont alors plus besoin de déclencher manuellement une enchère Protected Audience. Le résultat de l'enchère Protected Audience n'est pas affiché. Cela nous permet de tester l'intégration à grande échelle.

Lorsque vous serez prêt, contactez votre responsable de compte ou envoyez une demande via le Centre d'aide Authorized Buyers. Google activera le compte pour cette étape.

Étape 3 : Test d'affichage

Une fois que Google et le partenaire ont vérifié les enchères Protected Audience à grande échelle sans rendu, Google peut autoriser le partenaire à afficher l'annonce gagnante Protected Audience. Google dispose d'un faible volume de trafic pour lequel les enchères Protected Audience peuvent être diffusées et les annonces de groupes d'intérêt gagnantes sont affichées. Les enchères dans le navigateur des enchérisseurs participants sont en concurrence avec les enchères traditionnelles.

Lorsque vous serez prêt, contactez votre responsable de compte ou envoyez une demande via le Centre d'aide Authorized Buyers. Google activera le compte pour cette étape.

Fonctionnalités supplémentaires

Les fonctionnalités suivantes sont des extensions du protocole de base.

Parallélisation

La parallélisation est une optimisation qui réduit la latence de bout en bout des enchères en lançant la demande d'annonce contextuelle en parallèle des demandes aux serveurs approuvés de l'acheteur spécifiés dans trustedBiddingSignalsUrl.

La parallélisation réduit la latence, mais affecte l'éligibilité des acheteurs de groupes d'intérêt et la compatibilité avec les tests coordonnés. La parallélisation s'applique à tous les enchérisseurs qui participent aux enchères de groupes d'intérêt sur l'appareil. Les enchérisseurs n'ont pas besoin d'effectuer d'action pour participer aux enchères parallèles, mais ils doivent se familiariser avec la façon dont la parallélisation peut affecter leur éligibilité aux enchères sur l'appareil. Les ID de groupes de test pour les tests coordonnés ne sont pas encore compatibles avec les enchères parallèles.

Résumé du flux de diffusion

Voici un résumé du processus d'enchères parallèles : Schéma de flux

Éligibilité des acheteurs aux groupes d'intérêt sur l'appareil

Pour les enchères parallèles, l'appel de navigator.runAdAuction a lieu avant que la réponse de l'annonce contextuelle ne soit renvoyée. Pour lancer des appels de serveur approuvés par l'acheteur, navigator.runAdAuction exige que le paramètre interestGroupBuyers soit transmis en tant que valeur, tandis que les paramètres d'enchères restants acceptent les promesses JavaScript qui peuvent être résolues après la réponse de l'annonce contextuelle. Étant donné que interestGroupBuyers est transmis avant la réponse d'annonce contextuelle, cette dernière (y compris les réponses aux enchères) ne peut pas être utilisée pour choisir les acheteurs qui participent à la mise aux enchères parallélisée pour la demande donnée. Au lieu de cela, les balises d'éditeur Google mettent en cache, dans le navigateur de l'utilisateur, le paramètre interestGroupBuyers des précédentes exécutions navigator.runAdAuction sur le même domaine.

La parallélisation présente plusieurs aspects importants :

  1. Les signaux d'enchères qui ne sont pas nécessaires pour les demandes de serveur de confiance des acheteurs, comme perBuyerSignals, peuvent continuer à être spécifiés dans les réponses aux enchères RTB de la même manière que pour les enchères non parallélisées. Une fois les promesses pour ces signaux résolues, les étapes restantes de l'enchère sur l'appareil se déroulent de la même manière que pour le flux d'enchères non parallèles.

  2. Étant donné que la parallélisation repose sur la mise en cache de la liste des acheteurs de groupes d'intérêt, Google n'exécute pas toujours une enchère parallèle, car le cache de parallélisation peut être vide ou expiré. Si le cache est vide ou expiré, Google exécute une enchère standard non parallèle de l'API Protected Audience et utilise l'intention de l'acheteur pour participer à l'enchère non parallèle afin de créer le cache d'acheteurs du groupe d'intérêt.

  3. Si au moins un acheteur pour un enchérisseur donné est mis en cache pour le domaine d'éditeur actuel, Google exécutera une enchère parallèle, qui sera indiquée dans la demande d'enchère :

    • Protocole Google RTB : BidRequest.adslot.interest_group_auction.parallelized
    • OpenRTB : BidRequest.imp.ext.interest_group_auction.parallelized

  4. Chaque origine d'acheteur de groupe d'intérêt enregistrée pour un enchérisseur donné incluse dans l'enchère parallèle aura une entrée ParallelAuctionBuyer correspondante :

    • Protocole Google RTB : BidRequest.adslot.interest_group_auction.parallel_auction_buyer
    • OpenRTB : BidRequest.imp.ext.interest_group_auction.pbuyer

  5. Si une enchère parallèle est exécutée, mais qu'une origine d'acheteur spécifique n'est pas présente dans le cache, cet acheteur ne peut pas être ajouté à l'enchère sur l'appareil en cours. Cela est indiqué par une requête avec parallelized=True qui ne comporte pas d'entrée ParallelAuctionBuyer pour une origine d'acheteur de groupe d'intérêt donnée. Toutefois, les enchérisseurs qui indiquent un intérêt en incluant des InterestGroupBuyer valides et éligibles dans leur réponse aux enchères verront les origines d'acheteur de groupe d'intérêt correspondantes ajoutées au cache. Ces origines seront éligibles aux futures requêtes parallélisées du même navigateur et du même domaine. L'intention de participer aux enchères de groupes d'intérêt peut être indiquée dans les champs suivants :

    • Protocole Google RTB : BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB : BidResponse.ext.igbid.igbuyer

  6. Les origines d'acheteur mises en cache (qui sont incluses dans le paramètre interestGroupBuyers de l'enchère parallèle) pour lesquelles un enchérisseur n'indique pas son intention de participer dans sa réponse d'enchère peuvent recevoir un appel de serveur approuvé par l'acheteur, mais ne participeront pas à l'enchère parallèle.