Cette page a été traduite par l'API Cloud Translation.

API Protected Audience (anciennement FLEDGE)

Dans le cadre de la Privacy Sandbox, Chrome a proposé l'API Protected Audience, une API intégrée au navigateur qui permet aux annonceurs et aux entreprises de technologie publicitaire de diffuser des annonces ciblées par groupes de centres d'intérêt sans utiliser de cookies tiers, tout en protégeant les utilisateurs contre le suivi intersites.

Chrome exécute une phase d'évaluation 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. Les enchérisseurs peuvent réaliser les actions suivantes en testant l'API Protected Audience:

Itérez et analysez l'efficacité des flux de l'API Protected Audience.
Générer des commentaires sur les améliorations potentielles des API dans les forums publics tels que GitHub.
Préparez-vous à accepter la publicité personnalisée via l'API sans dépendre de cookies tiers.

Les acheteurs Authorized Buyers qui souhaitent effectuer des tests doivent consulter la section Intégration pour en savoir plus.

Résumé du flux de diffusion

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

Schéma de flux

Un enchérisseur collabore avec ses annonceurs pour gérer les groupes de centres d'intérêt de chacun d'eux. Souvent, les annonceurs ajoutent la balise d'un enchérisseur à sa page pour ajouter un navigateur aux groupes de centres d'intérêt.
Un utilisateur final consulte la page d'un annonceur. La page peut contenir le tag de l'enchérisseur.
Le tag de l'enchérisseur appelle l'API Protected Audience joinAdInterestGroup(). Cet appel demande au navigateur d'ajouter l'utilisateur à un groupe de centres d'intérêt.
L'utilisateur final consulte une page Web de l'éditeur. Le navigateur de l'utilisateur demande le tag d'emplacement publicitaire éditeur de Google.
Le tag d'emplacement publicitaire de l'éditeur Google envoie une demande d'annonce contextuelle à un serveur Google.
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.
Le système d'enchères renvoie un code BidResponse avec le champ interest_group_bidding. Si l'enchérisseur ne spécifie pas interest_group_bidding, Google n'inclut pas son origine dans le fichier interestGroupBuyers dans la configuration des enchères. La réponse à l'enchère peut également contenir le ou les éléments suivants : interest_group_bidding.per_buyer_signals. per_buyer_signals sera transmis à la fonction d'enchères de l'enchérisseur lors de la mise aux enchères dans le navigateur. Pour en savoir plus, consultez la section Modifications apportées aux réponses aux enchères.
Google exécute les 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 traditionnelles côté serveur. La réponse à l'enchère peut contenir des informations sur une enchère contextuelle gagnante (le cas échéant).
La réponse à l'enchère contient une configuration d'enchère pour l'enchère dans le navigateur. Il peut s'agir de signaux contextuels de chaque acheteur participant (envoyés via interest_group_bidding.per_buyer_signals), d'informations contextuelles sur les gagnants et de paramètres d'éligibilité aux enchères.
Le tag éditeur de Google appelle l'API Protected Audience runAdAuction() pour lancer l'enchère sur l'appareil associée à un groupe de centres d'intérêt. Google n'inclut que les acheteurs qui ont précédemment renvoyé interest_group_bidding comme interestGroupBuyers dans la configuration de l'enchère.
Google transmet l'per_buyer_signals de chaque enchérisseur éligible à la configuration de la mise aux enchères Protected Audience.
Si les groupes de centres d'intérêt d'un enchérisseur donné ont spécifié l'trustedBiddingSignalsUrl, le navigateur envoie une requête au trustedBiddingSignalsUrl de chaque groupe afin de récupérer des signaux en temps réel pour chaque groupe. Pour en savoir plus, consultez les spécifications de l'API Protected Audience.
Le navigateur appelle le generateBid() de l'enchérisseur pour chaque groupe de centres d'intérêt qui s'est inscrit et est éligible à la mise aux enchères dans le navigateur. Cette étape calcule l'enchère et sélectionne une création. generateBid() a accès au per_buyer_signals fourni par l'enchérisseur et aux signaux d'enchères de confiance pour le groupe de centres d'intérêt donné.
Le navigateur appelle le scoreAd() du vendeur (dans ce cas, celui de Google) pour attribuer un classement à chaque offre dans les enchères publicitaires liées aux groupes de centres d'intérêt. Les enchères sont classées et filtrées en fonction des protections pour les éditeurs, des règles relatives aux annonces et d'autres contraintes.
Le navigateur lance une mise aux enchères avec les enchères de groupes de centres d'intérêt éligibles. L'enchère contextuelle la mieux classée participe à la mise aux enchères dans un navigateur.
Après l'enchère, si un groupe de centres d'intérêt a remporté l'enchère, le navigateur appelle l'reportResult() du vendeur et le reportWin() de l'enchérisseur pour informer chaque partie du gagnant de la mise aux enchères dans le navigateur.
Si une annonce associée à un groupe de centres d'intérêt remporte l'enchère, le tag d'éditeur de Google affiche l'annonce dans un iFrame.

Détails du flux de diffusion

Avant la diffusion des annonces

Vérification des créations

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

Conditions requises pour renderUrls:

L'renderUrl envoyé via l'API doit correspondre à l'renderUrl utilisé lors des enchères publicitaires liées aux groupes de centres d'intérêt.
Chaque renderUrl ne peut représenter qu'un seul annonceur ou qu'une seule campagne publicitaire. Un renderUrl donné ne peut pas être utilisé pour afficher des annonces pour le compte de plusieurs annonceurs. Chaque élément renderUrl doit correspondre à une seule création.
Le renderUrl doit être accessible et extrait par les systèmes hors connexion de Google de vérification des créations pendant un maximum de sept jours après la dernière enchère avec laquelle l'annonce a été définie.

Real-time Bidding API

Les enchérisseurs peuvent utiliser l'API Real-time Bidding afin d'importer des créations pour les enchères de groupes de centres 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 détecte les créations dans les enchères intégrées au navigateur et les analyse automatiquement afin qu'elles soient éligibles aux futures enchères.

Pour activer l'analyse automatique des créations, procédez comme suit:

Ajoutez toutes les origines renderUrl de la création associée à un groupe de centres 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 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 conformément à 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 de la création

Les créations sont approuvées pour une durée de 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 utilisez l'analyse automatique des créations, le processus procède automatiquement à une nouvelle analyse.

ID de reporting de l'acheteur

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

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

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

L'buyer_reporting_id apparaît sous la forme d'une nouvelle dimension dans l'outil de création de rapports d'Authorized Buyers, sous le nom de dimension "ID de rapport de l'acheteur".

Enchères côté serveur

Modifications apportées aux demandes d'enchères

Voici les premières versions des protocoles compatibles avec l'expérience:

Lien anticipé pour le protocole RTB de Google
Lien anticipé OpenRTB

Indiquer la compatibilité avec les enchères associées à des groupes de centres d'intérêt

Les demandes d'enchères disposent d'un nouveau champ : auction_environment.

Protocole Google d'enchères en temps réel: BidRequest.adslot.auction_environment
OpenRTB: BidRequest.imp.ext.auction_environment

Vous pouvez utiliser ce champ pour différencier les opportunités d'impressions qui prennent en charge les enchères de groupes de centres d'intérêt de l'API Protected Audience dans les navigateurs et celles qui ne sont compatibles qu'avec les enchères sur une place de marché côté serveur traditionnelles. L'énumération auction_environment peut avoir les valeurs suivantes:

SERVER_SIDE_AUCTION (OpenRTB JSON: 0): enchères traditionnelles côté serveur
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 les enchères liées aux groupes de centres d'intérêt, et l'enchère finale s'exécute dans le navigateur.

Indiquer la taille de l'espace publicitaire Protected Audience

La demande d'enchère inclut les champs suivants pour vous indiquer la taille de l'espace publicitaire Protected Audience:

Protocole Google RTB :
- BidRequest.adslot.interest_group_auction.width
- BidRequest.adslot.interest_group_auction.height
OpenRTB:
- BidRequest.imp.ext.interest_group_auction.width
- BidRequest.imp.ext.interest_group_auction.height

Ces champs indiquent la taille en pixels de l'espace publicitaire pour la mise aux enchères Protected Audience.

Cette taille peut être différente de celle utilisée pour la requête contextuelle (Adslot.width et Adslot.height, ou dans OpenRTB : BidRequest.imp.banner.format).

La demande contextuelle peut avoir plusieurs tailles. L'annonce gagnante aux enchères sur l'appareil ne doit remplir qu'une seule taille d'emplacement fixe.

Indiquer l'affichage des annonces Protected Audience

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

Protocole Google d'enchères en temps réel : BidRequest.adslot.interest_group_auction.render_interest_group_ads
OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads

Limiter le recours aux identifiants utilisateur

Les demandes d'enchères contextuelles concernées par les tests de l'API Protected Audience peuvent continuer à transmettre des identifiants traditionnels basés sur les cookies lorsqu'ils sont disponibles dans le navigateur, tels que les champs google_user_id (BidRequest.user.id dans OpenRTB) et hosted_match_data (BidRequest.user.buyerid dans OpenRTB). La présence de ces identifiants dans les demandes d'enchères restera soumise aux règles de confidentialité existantes. Nous vous recommandons de ne pas utiliser d'identifiants basés sur les cookies pour le ciblage et les enchères lors des tests. Vous pourrez ainsi mieux vous préparer à un achat efficace 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 dans le cadre des tests de l'API Protected Audience. Cela permet d'évaluer l'impact potentiel de l'abandon des cookies tiers.

Tests d'abandon des cookies tiers gérés par Chrome

Pour se préparer à l'abandon 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 gérés par Chrome pour tester leurs systèmes selon un système 3PCD. Lors du test, les navigateurs Chrome sont affectés à un groupe de test 3PCD : Mode A ou 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 à la demande d'enchère RTB. En raison des petits segments de trafic d'un libellé individuel, Google ne l'inclut pas toujours dans les contextes où la confidentialité est limitée.

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

Protocole Google d'enchères en temps réel : BidRequest.device.cookie_deprecation_label
OpenRTB: BidRequest.device.ext.cdep

Modifications apportées aux réponses aux enchères

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

Vous devez indiquer explicitement votre intention de participer à la mise aux enchères dans un navigateur en renvoyant l'objet InterestGroupBidding dans la réponse à l'enchère contextuelle:

Protocole Google d'enchères en temps réel: BidResponse.interest_group_bidding
OpenRTB: BidResponse.ext.igbid

Vous devez fournir une réponse à l'enchère contextuelle. La réponse n'est pas nécessaire pour inclure une enchère contextuelle. L'objet InterestGroupBidding doit contenir l'identifiant origin du propriétaire du groupe de centres d'intérêt, lequel doit correspondre à l'une des origines configurées par l'enchérisseur pour son compte. Le origin est ajouté au interestGroupBuyers de la configuration de l'enchère lorsque Google Publisher Tag appelle runAdAuction().

Propager les signaux de contexte de l'acheteur (perBuyerSignals)

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

RTB Google: BidResponse.interest_group_bidding.per_buyer_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata

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

Dans la proposition de l'API Protected Audience, le calcul des enchères et l'enchère finale doivent être exécutés localement sur l'appareil. Cela peut créer des vecteurs d'abus potentiels pouvant affecter l'intégrité des résultats finaux de la mise aux enchères, tels que le prix de l'enchère gagnante.

Afin de réduire les risques liés aux 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 à l'enchère contextuelle. L'enchère maximale attendue correspond au prix maximal que votre fonction d'enchères est censée renvoyer. Si l'enchère gagnante indiquée lors de la mise aux enchères dans le navigateur dépasse ce montant, l'enchère gagnante n'est pas comptabilisée comme un événement facturable. Cette approche est susceptible d'évoluer.

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

Protocole RTB de Google : BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (exprimé en microCPM)
OpenRTB: BidResponse.igbid.igbuyer.maxbid(exprimé en unités de devise CPM)

Attribuer des impressions à plusieurs comptes

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

Protocole RTB de Google : BidResponse.interest_group_bidding.interest_group_buyers.billing_id
OpenRTB: BidResponse.igbid.igbuyer.billing_id

Le n° compte facturation sélectionné doit être un n° compte facturation éligible provenant de la demande d'enchère:

Protocole RTB de Google : BidRequest.adslot.matching_ad_data.billing_id
OpenRTB: BidRequest.imp.ext.billing_id

Si le n° compte facturation auquel attribuer les impressions d'enchères liées à des groupes de centres d'intérêt n'est pas fourni, l'enchérisseur ne participera pas à la mise aux enchères Protected Audience.

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

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

Les ID de compte de facturation de tous les comptes enfants disposant d'un budget disponible susceptible de définir une enchère 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 associé à un n° de compte de facturation associé à un groupe de centres d'intérêt.

Pendant les enchères dans le navigateur

Générer des enchères intégrées au navigateur

Utilisez generateBid() pour générer des enchères intégrées au navigateur.

Google fournit les paramètres suivants:

auctionSignals: vide
perBuyerSignals: objet JavaScript des mêmes signaux 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 qui participe à la mise aux enchères. Elles doivent être exprimées en unités au CPM (et non en micros).
render: URL affichée pour afficher la création si l'enchère remporte la mise aux enchères. Google doit examiner et approuver cette URL, sans quoi elle sera exclue de la mise aux enchères.
allowComponentAuction: la valeur doit être true. Google permet actuellement de tester les enchères multivendeurs.

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 intégrées au navigateur sont exprimées en unités de CPM dans la devise choisie.

La devise de l'enchère doit être indiquée à la fois dans la réponse contextuelle à l'enchère et dans la valeur renvoyée pour generateBid. Elle doit correspondre à 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 Google RTB, 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 les enchères dans la même devise que celle indiquée dans la réponse d'enchère contextuelle. Renseignez la nouvelle propriété bidCurrency dans la valeur renvoyée par generateBid:

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

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

Contrôles de la qualité des annonces

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

Compatibilité avec la loi sur les services numériques

Conformément à l'article 26 de la loi sur les services numériques, les éditeurs peuvent exiger des acheteurs qu'ils affichent des informations concernant la transparence dans les annonces. Lorsque l'option "Demander aux acheteurs de ne diffuser que des annonces comportant des informations de transparence DSA sur mon site ou dans mon application dans l'EEE" est activée par un éditeur, les acheteurs de groupes de centres d'intérêt peuvent déterminer les opportunités pour lesquelles ils devront assurer la transparence auprès des acheteurs en indiquant les champs suivants dans les demandes d'enchères reçues : BidRequest.dsa.dsa_support et BidRequest.dsa.publisher_rendering_support pour le protocole Google Authorized Buyers, et BidRequest.regs.dsa.required et BidRequest.dsa.pubrender pour le protocole OpenRTB.

Lorsqu'un enchérisseur qui souhaite participer aux enchères de l'API Protected Audience reçoit dans la demande d'enchère le signal indiquant que la transparence des ADR doit s'afficher pour les annonces diffusées via l'API Protected Audience, il doit évaluer s'il peut afficher correctement les informations requises et spécifier BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render pour le protocole Google Authorized Buyers ou BidResponse.ext.igbid.igbuyer.dsaadrender pour le protocole OpenRTB. Sinon, l'acheteur ne sera pas inclus dans la mise aux enchères de l'API Protected Audience.

Pour en savoir plus sur la transparence publicitaire de la loi sur les services numériques, consultez cet article du centre d'aide: Soutenir la loi sur les services numériques.

Filtrage des enchères

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

Après la mise aux enchères dans le navigateur

Signaler le résultat de la mise aux enchères à l'acheteur: reportWin()

Google ne renseigne pas les arguments suivants:

auctionSignals
sellerSignals

Utilisez reportWin() pour transmettre le résultat de la mise aux enchères à l'acheteur.

Pour en savoir plus, consultez la section Créer des rapports sur l'affichage et les événements publicitaires de la vidéo d'explication de l'API Protected Audience.

Macros

L'élément 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 associée à un groupe de centres d'intérêt terminée, mais avant l'affichage, les macros sont remplacées par les valeurs correspondantes. renderUrl utilisé dans les enchères sur l'appareil peut inclure les macros suivantes:

`${GDPR}`	Passe à 0 si le RGPD ne s'applique pas ou à 1 si le RGPD s'applique. Consultez la documentation.
`${GDPR_CONSENT_XXXX}`	Cette macro est remplacée par la chaîne Transparency & Consent (TC) associée à la demande. Si la chaîne TC est vide ou non valide, cette macro n'est pas remplacée. Utilisez cette macro pour transmettre la chaîne TC à un fournisseur inscrit sur la LGF de l'IAB dans une URL. Remplacez `XXXX` par l'ID GVL de l'IAB du fournisseur enregistré sur la LGF de l'IAB. Si la chaîne TC est vide ou non valide, cette macro n'est pas développée. Les créations contenant 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é ne dispose pas du consentement de l'utilisateur. La macro `${GDPR_CONSENT_XXXX}` ne doit apparaître qu'une seule fois dans `renderUrl`.
`${ADDL_CONSENT}`	Cette macro est remplacée par la chaîne de consentement supplémentaire (AC) associée à la requête.
`${AD_WIDTH}, ${AD_HEIGHT)`	Ces macros permettent d'insérer la largeur et la hauteur de l'espace publicitaire.

Comptabilisation des impressions

Lors des tests de l'API Protected Audience avec les partenaires RTB, Google comptabilise les impressions lorsque le navigateur appelle sa fonction reportResult(), puis récupère l'URL de reporting 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 les navigateurs peut être différent de celui utilisé pour comptabiliser les impressions par ses partenaires acheteurs RTB, le nombre d'impressions peut être différent.

L'un des objectifs de Google pour tester 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 issues des enchères Protected Audience dans un navigateur sont attribuées à un seul compte d'enchérisseur, en fonction de la mise en correspondance des origines du propriétaire du groupe de centres d'intérêt configurées pour l'enchérisseur. Il n'est pas possible d'attribuer les dépenses à différents comptes enfants d'un enchérisseur.

Limite de budget quotidien

Pendant les tests de l'API Protected Audience, chaque compte dispose d'une limite budgétaire quotidienne au niveau du compte. Cette limite limite le risque dans l'environnement d'enchères intégré au navigateur. Une fois la limite budgétaire quotidienne atteinte, le compte ne reçoit plus de demandes d'enchères éligibles pour 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 d'enchérisseur qui atteint la limite Protected Audience peut recevoir une demande d'enchère avec auction_environment = SERVER_SIDE_AUCTION (OpenRTB: 0), même si la demande d'enchère est éligible à une mise aux enchères Protected Audience.

Commentaires en temps réel et enchère minimale pour remporter l'enchère

Les enchérisseurs qui ont accepté de recevoir des commentaires en temps réel recevront des commentaires pour les acheteurs de groupes de centres d'intérêt qui souhaitent être inclus dans une mise aux enchères Protected Audience sur l'appareil. Chaque acheteur associé à un groupe de centres d'intérêt qu'un enchérisseur spécifie dans une réponse à l'enchère reçoit un objet de commentaire, quel que soit le nombre d'enchères qu'il place dans la mise aux enchères Protected Audience. Les informations suivantes seront disponibles dans l'objet de commentaires de l'acheteur du groupe de centres d'intérêt:

Le type de commentaire de l'objet "feedback" sera INTEREST_GROUP_BUYER_FEEDBACK.
Origine de l'acheteur associé à un groupe de centres d'intérêt.
Offre minimale à remporter pour l'acheteur associé à un groupe de centres d'intérêt afin de remporter l'enchère globale.
Offre minimale à remporter pour l'acheteur du groupe de centres d'intérêt afin de battre l'enchère la plus élevée du composant côté serveur de l'enchère globale.
Code d'état de l'acheteur associé au groupe de centres d'intérêt. Les codes d'état possibles sont définis dans le fichier interest-group-buyer-status-codes.txt.

Reportez-vous à la documentation du protocole pour le RTB Authorized Buyers et les extensions OpenRTB pour connaître les noms de champs spécifiques.

Notification sur les commentaires sur les enchères

Chrome fournit une API de débogage temporaire pour l'API Protected Audience, qui permet à Ad Manager d'envoyer en temps réel des notifications de débogage de serveur à serveur contenant des commentaires sur une enchère Protected Audience. Cette notification indique les raisons pour lesquelles les enchères ont pu être filtrées dans la mise aux enchères Protected Audience dans un 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 de l'API Protected Audience. Cette URL statique sera extraite des serveurs Google en remplaçant les macros sélectionné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 (BidRequest.google_query_id dans le protocole Authorized Buyers et BidRequest.ext.google_query_id dans le protocole OpenRTB) envoyé dans la demande d'enchère contextuelle pour l'API Protected Audience activée.
%%INTEREST_GROUP_OWNER%%: origine du propriétaire du groupe de centres 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 les scoreAd(). Les valeurs sont des codes d'état de 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.

Nombre de clics

Les enchérisseurs peuvent signaler à Google les événements de clic sur les annonces Protected Audience à l'aide de l'API Fenced Frame Reporting. Les enchérisseurs doivent utiliser le type d'événement click pour informer Google des clics. Exemple :

window.fence.reportEvent({
    'eventType': 'click',
    // Google does not require bidders to send data to Google in 'eventData'.
    // However, 'eventData' must be a non-null value, such as an empty string.
    'eventData': '',
    'destinations': ['direct-seller']
});

TURTLEDOVE au niveau du produit

Les annonces composées de plusieurs pièces ou les annonces TURTLEDOVE au niveau du 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, informez-en votre responsable de compte lors de l'intégration, car des ressources et une configuration supplémentaires sont requises.

Intégration

Voici comment tester l'API Protected Audience:

Étapes

Remplissez le formulaire de demande pour participer au test de l'API Protected Audience.
Une fois le formulaire de demande envoyé, contactez votre responsable de compte ou envoyez une demande via le Centre d'aide Authorized Buyers.
Une fois le compte configuré, Google et le partenaire peuvent vérifier l'intégration en suivant les étapes des étapes de test.

Vérification des créations

Pour définir une enchère avec des annonces au niveau du 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 pour le conteneur de l'annonce composante (également appelé renderUrl de premier niveau) afin de distinguer l'renderUrls de premier niveau lors de la vérification de la création.
Affichez une création représentative lorsque le conteneur de l'annonce composante est extrait pour être examiné par Google. Pour savoir quand un rendu d'annonce représentatif doit être renvoyé, vous pouvez consulter le paramètre de requête validation=True défini par le système de vérification des créations de Google.

Checklist pour l'intégration

Configurez un point de terminaison de demande d'enchère qui remplira les champs liés à l'API Protected Audience dans la réponse à l'enchère contextuelle (par exemple, interest_group_bidding).
Implémentez le taggage sur les pages de l'annonceur pour joindre le navigateur de l'utilisateur au groupe de centres d'intérêt.
Implémentez generateBid() et reportWin().
Sélectionnez les origines du propriétaire des groupes de centres d'intérêt et ajoutez-les au compte Authorized Buyers.
- Les origines des propriétaires de groupes de centres d'intérêt doivent correspondre à celles où les fonctions generateBid() sont hébergées.
- Contactez le responsable de compte ou déposez une demande via le Centre d'aide Authorized Buyers pour effectuer cette étape.
Configurez le préciblage pour l'inventaire pertinent pour les tests de l'API Protected Audience.
Envoyez vos créations pour examen et approbation via l'API.
(Facultatif) Configurez les points de terminaison des signaux d'enchères de confiance.
(Facultatif) Configurez une page d'annonceur test permettant aux ingénieurs Google d'ajouter leur navigateur aux groupes de centres d'intérêt appartenant à l'origine de l'acheteur du groupe de centres d'intérêt. Cela nous permet de déclencher manuellement des enchères Protected Audience.
(Facultatif) Activez les commentaires en temps réel sur votre compte afin de recevoir des commentaires pour les acheteurs de groupes de centres d'intérêt qui souhaitent participer à une mise aux enchères 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 Protected Audience sur l'appareil afin de vous aider à 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 mise aux enchères Protected Audience, s'assurer que l'annonce peut être affichée et enregistrer l'impression:

Utilisez Chrome 101 ou une version ultérieure.
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.
Envoyez une création pour approbation à l'aide de l'API Real-time Bidding.
Utilisez la page de l'annonceur fournie par l'enchérisseur pour ajouter un navigateur au groupe de centres d'intérêt appartenant à l'enchérisseur.
Utilisez la page de l'éditeur test fournie par Google ci-dessous pour déclencher une mise aux enchères Protected Audience:

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

Le groupe de centres d'intérêt dans le navigateur doit définir une enchère suffisamment élevée pour remporter l'enchère, car il pourrait entrer en concurrence avec les enchères conventionnelles côté serveur. Google fournit également une page dédiée aux éditeurs de test pour chaque partenaire, où seul le partenaire donné peut participer à la mise aux enchères. Il peut être plus facile de remporter de manière fiable des enchères intégrées au navigateur sur une page spécifique d'un partenaire.
Effectuez les vérifications suivantes:
1. L'annonce gagnante attendue est affichée.
2. Le résultat de la mise aux enchères est envoyé côté serveur, ce qui signifie qu'un enchérisseur gagnant reçoit un ping de reportWin().
3. La console de la page é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 de centres d'intérêt associé à l'enchère.
  - accepted: ce champ indique true si l'enchère a été acceptée et false si elle a été refusée par scoreAd().
  - externalBidStatus: code d'état si l'enchère a été refusée dans les scoreAd(). Les valeurs sont des codes d'état de création.

Étape 2: (Facultatif) Test sans affichage

Une fois que Google et le partenaire ont vérifié manuellement qu'il peut participer à la mise aux enchères Protected Audience, Google active le partenaire pour l'étape de test suivante.

Google alloue une petite quantité de trafic en direct aux enchères Protected Audience. Ainsi, Google et le partenaire n'ont plus besoin de déclencher manuellement une mise aux enchères Protected Audience. Le résultat de la mise aux enchères Protected Audience ne s'affiche pas. Cela nous permet de tester l'intégration à grande échelle.

Lorsque vous êtes prêt, contactez votre responsable de compte ou déposez 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 validé les enchères Protected Audience à grande échelle sans affichage, Google peut permettre au partenaire d'afficher l'annonce Protected Audience gagnante. Sur Google, il y a une petite quantité de trafic dans laquelle les enchères Protected Audience peuvent être lancées, et les annonces gagnantes associées à des groupes de centres d'intérêt s'affichent. Les enchères dans les navigateurs des enchérisseurs participants entrent en concurrence avec les enchères traditionnelles.

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