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 dans le navigateur qui permet aux annonceurs et aux entreprises d'ad tech de diffuser des annonces ciblées par centres d'intérêt sans s'appuyer sur des cookies tiers, tout en protégeant les utilisateurs du suivi intersites.

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

Itérer et découvrir l'efficacité des flux de l'API Protected Audience
Générer des commentaires sur les améliorations potentielles de l'API dans les forums publics, pour exemple : GitHub.
Préparez-vous à la prise en charge de la publicité personnalisée via l'API sans en s'appuyant sur des cookies tiers.

Les acheteurs Authorized Buyers qui souhaitent effectuer des tests peuvent consulter le Guide d'intégration .

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

Un enchérisseur collabore avec ses annonceurs pour gérer les groupes de centres d'intérêt de chacun d'eux. Les annonceurs ajoutent souvent la balise d'un enchérisseur à leur 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 la balise de l'enchérisseur.
La balise 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 la page Web d'un éditeur. Le navigateur de l'utilisateur demande le tag d'emplacement publicitaire d'éditeur de Google.
Le tag d'emplacement publicitaire de Google envoie une demande d'annonce contextuelle à un serveur Google.
Google envoie des demandes d'enchères contextuelles aux enchérisseurs participants. Consultez le Modifications apportées aux demandes d'enchères.
L'enchérisseur renvoie une réponse d'enchère incluant le message InterestGroupBidding, qui est nécessaire pour participer à la mise aux enchères du groupe de centres d'intérêt. Dans OpenRTB est spécifié à l'aide du champ BidResponse.ext.igbid. Dans le protocole obsolète Google RTB spécifié BidResponse.interest_group_bidding. Si l'enchérisseur ne spécifie pas ces informations, Google n'inclut pas l'origine de l'enchérisseur interestGroupBuyers dans la la configuration des enchères. InterestGroupBidding peut aussi contenir des signaux facultatifs spécifiques à l'acheteur qui sont transmises à la fonction d'enchères de l'enchérisseur mise aux enchères. Dans OpenRTB, cela est spécifié avec le paramètre dans le champ BidResponse.ext.igbid.igbuyer.buyerdata, et dans la version obsolète protocole du système d'enchères en temps réel Google, spécifié à l'aide de la méthode BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals . Consultez la section Modifications apportées aux réponses aux enchères pour en savoir plus plus d'informations.
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 tiennent compte des enchères traditionnelles côté serveur. La réponse d'enchère peut contenir des informations sur une enchère gagnante contextuelle (le cas échéant).
La réponse à l'enchère contient une configuration d'enchères pour l'enchère dans le navigateur. Cela peut inclure des signaux de contexte de chaque acheteur participant (envoyés via le système buyerdata d'OpenRTB ou du système d'enchères en temps réel Google, désormais obsolète) per_buyer_signals du protocole précédemment), des informations contextuelles sur le gagnant et les paramètres d'éligibilité des enchères.
Le tag d'éditeur de Google appelle l'API Protected Audience runAdAuction() pour lancer la mise aux enchères sur l'appareil ciblant des groupes de centres d'intérêt. Google n'inclut qui étaient inclus en tant que InterestGroupBuyer dans InterestGroupBidding lors de la configuration des enchères.
Google transmet les signaux facultatifs spécifiques à l'acheteur de chaque enchérisseur éligible à la configuration des enchères Protected Audience.
Si les groupes de centres d'intérêt d'un enchérisseur donné trustedBiddingSignalsUrl, le navigateur envoie une requête à chaque groupe trustedBiddingSignalsUrl afin d'extraire des signaux en temps réel pour chaque groupe. Pour en savoir plus, consultez la spécification de l'API Protected Audience.
Le navigateur appelle l'generateBid() de l'enchérisseur pour chaque groupe de centres d'intérêt. qui ont activé cette fonctionnalité et qui sont éligibles à 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 de confiance pour le groupe d'intérêts donné.
Le navigateur appelle la fonction scoreAd() du vendeur (dans ce cas, Google) pour attribuer un classement à chaque enchère lors de la mise aux enchères des annonces du groupe d'intérêts. 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.
Le navigateur lance une enchère avec les enchères de groupe d'intérêt éligibles. L'enchère contextuelle la mieux classée participe à la mise aux enchères dans le navigateur.
Après l'enchère, si un groupe d'intérêt gagnant est sélectionné, le navigateur appelle le reportResult() du vendeur et le reportWin() de l'enchérisseur afin d'en informer chacun sur le vainqueur de l'enchère dans le navigateur.
Si une annonce associée à un groupe d'intérêt remporte l'enchère, le tag d'éditeur Google affiche l'annonce dans une iFrame.

Détails du flux de diffusion

Avant la diffusion d'annonces

Vérification 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 dans le navigateur Protected Audience. Vous pouvez envoyer des créations pour examen via l'API Real-time Bidding ou via l'analyse automatique des créations. Créations pour Les enchères d'annonces de groupes de centres d'intérêt dans le navigateur Protected Audience doivent inclure renderUrls pour examen.

Conditions requises pour renderUrls:

Le renderUrl envoyé via l'API doit correspondre à l'renderUrl utilisé. dans le système d'enchères des groupes de centres 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 afficher des annonces pour le compte 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 de l'annonce.

Real-time Bidding API

Les enchérisseurs peuvent utiliser le système d'enchères en temps réel API pour importer des créations 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 recherche les créations dans l'enchère dans le 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 ciblant un groupe de centres d'intérêt au 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 128 octets.

Authorized-Buyers-Click-Through-URLs

chaîne

Ensemble des URL de destination déclarées pour la création encodée 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 de la création

Les créations sont approuvées pendant 15 jours. Si vous envoyez des créations avec l'API d'enchères en temps réel, vous devrez les renvoyer au bout de 15 jours. Si vous comptez sur des créations, le processus d'analyse les ré-analyse automatiquement.

ID de rapport de l'acheteur

Vous pouvez ventiler les métriques des rapports (telles que les impressions) à l'aide de dimensions fournies par l'acheteur (par exemple, l'ID de la campagne ou la référence annonceur). Pour ajouter un pour les dépenses liées aux 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 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 s'affichera sous la forme d'une nouvelle dimension dans la colonne Outil de création de rapports de l'acheteur, en tant que dimension d'ID de reporting d'acheteur

Enchères côté serveur

Modifications apportées aux demandes d'enchères

Vous trouverez ci-dessous les versions préliminaires des protocoles compatibles à utiliser dans le test :

Lien anticipé OpenRTB
Lien précoce du protocole Google RTB (obsolète)

Indiquer la compatibilité avec les enchères des groupes d'intérêt

Les demandes d'enchères comportent de nouveaux champs indiquant qu'ils acceptent les enchères liées à des groupes de centres d'intérêt:

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

Ce champ vous permet de différencier les opportunités d'impression sont compatibles avec les enchères de groupes de centres d'intérêt Protected Audience dans les navigateurs et celles qui n'est compatible qu'avec les enchères traditionnelles sur une place de marché côté serveur. L'énumération AuctionEnvironment peut avoir les valeurs suivantes :

SERVER_SIDE_AUCTION (OpenRTB JSON: 0): enchère déterminant le l'annonce gagnante est exécutée 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 mise aux enchères contextuelle s'exécute sur les serveurs de la place de marché, et les enchères des groupes de centres d'intérêt et les enchères finales s'exécutent dans le navigateur.
SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON : 3) : les enchères contextuelles s'exécutent sur les serveurs de la place de marché, et la logique d'enchères pour les enchères de groupe d'intérêts et la logique de notation pour déterminer l'annonce gagnante finale sont exécutées dans les serveurs d'enchères et de mise aux enchères.

Indiquer la taille de l'espace publicitaire Protected Audience

La demande d'enchère inclut les champs suivants pour vous fournir l'état Taille de l'espace publicitaire de l'audience:

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'espace publicitaire pour la mise aux enchères Protected Audience en pixels.

Cette taille peut différer de celles de la requête contextuelle, comme celles observées dans le champ BidRequest.imp.banner.format.w d'OpenRTB Champs BidRequest.imp.banner.format.h ou le protocole obsolète du système d'enchères en temps réel de Google BidRequest.adslot.width et BidRequest.adslot.height.

La requête contextuelle peut avoir plusieurs tailles. L'annonce gagnante de l'enchère sur l'appareil ne devrait occuper qu'une seule taille d'emplacement fixe.

Indiquer la capacité d'affichage des annonces Protected Audience

Les annonces Protected Audience peuvent ou non s'afficher en fonction de l'état actuel l'étape d'intégration (consultez la section Non-affichage test). render_interest_group_ads de la demande d'enchère indique si l'annonce Protected Audience gagnante s'affiche.

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

Limiter l'utilisation des identifiants utilisateur

Les requêtes d'enchères contextuelles entrant dans le champ d'application des 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 ces identifiants dans l'enchère sont soumises aux règles de confidentialité existantes. Nous vous recommandons ne pas utiliser d'identifiants basés sur les cookies pour le ciblage et les enchères pour mieux vous préparer à un achat efficace lorsque les cookies tiers ne sont pas n'est plus disponible.

Google peut également effectuer des tests à petite échelle dans lesquels les identifiants basés sur les cookies sont masqués dans les requêtes d'enchères concernées par les tests de l'API Protected Audience. Le but est d'évaluer l'impact potentiel de l'abandon des cookies tiers.

Tests de l'abandon des cookies tiers facilités par Chrome

Pour vous préparer au abandon des cookies tiers (3PCD) en 2024, Chrome propose désormais 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 du 3PCD. Pendant le test, les navigateurs Chrome sont affectés à un groupe de test "3PCD", le Mode A ou le Mode B. Chaque navigateur se voit attribuer un libellé cohérent correspondant à un groupe de test 3PCD spécifique auquel vous pouvez accéder l'API Chrome intégrée au navigateur.

Google transmet le libellé non modifié de l'API Chrome dans la requête d'enchère RTB. En raison des petits segments de trafic d'un libellé individuel, Google n'inclut pas toujours le libellé dans les contextes limités en termes de confidentialité.

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

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

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

Indiquer la participation aux enchères d'un groupe 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 d'enchère contextuelle :

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

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

Propager des signaux de contexte de l'acheteur

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

OpenRTB : BidResponse.ext.igbid.igbuyer.buyerdata
RTB Google (obsolète): BidResponse.interest_group_bidding.per_buyer_signals

Propager les signaux d'affichage contextuel de l'acheteur

Les créations de groupes de centres d'intérêt peuvent utiliser des signaux contextuels limités lors de l'affichage 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 macro. Par exemple, le rendu vous pouvez utiliser ces signaux pour personnaliser l'apparence d'une création les performances dans le contexte d'un espace publicitaire donné ou d'une page d'éditeur donnée.

Vous pouvez inclure les signaux de rendu d'un acheteur sérialisés en tant que chaîne sécurisée pour les URL dans la réponse à l'enchère contextuelle, que Google remplacera dans l'URL de rendu du groupe en créant la Macro ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}.

Vous pouvez spécifier des signaux de rendu dans la réponse à l'enchère à l'aide des éléments suivants : en fonction du protocole:

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

Jusqu'à trois ensembles de signaux de rendu avec différents suffixes de macros peuvent être inclus dans la réponse à l'enchère pour distinguer différents signaux. Par exemple, un suffixe peuvent être utilisées pour faire correspondre un ensemble spécifique de signaux qui ne s'appliquent qu'aux créations ; avec la macro correspondante dans l'URL de rendu, réduisant ainsi le transfert de données la taille de l'image.

L'acheteur du groupe de centres d'intérêt ne pourra pas participer au programme Enchères par type d'audience si les signaux ne sont pas adaptés aux URL, 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 l'API Protected Audience d'une proposition, le calcul de l'enchère et les enchères finales devraient se dérouler localement sur l'appareil. Cela peut créer les vecteurs d'abus potentiels susceptibles d'affecter l'intégrité de la mise aux enchères finale résultats, tels que le prix de l'enchère gagnante.

Google a testé l'API Protected Audience pour ses partenaires RTB. Vous pouvez spécifier une valeur d'enchère maximale attendue dans chaque réponse d'enchère contextuelle. L'enchère maximale attendue correspond au prix d'enchère maximale que votre fonction d'enchères doit 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 un é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 le champ les champs suivants:

OpenRTB : BidResponse.igbid.igbuyer.maxbid (exprimée en unités de devise du 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 n° compte facturation pour attribuer son intérêt pour regrouper les impressions d'enchères à l'aide des champs suivants:

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

Le n° compte facturation sélectionné doit être un n° compte facturation éligible dans 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 des enchères de groupe 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 ID de facturation. L'acheteur peut utiliser un ID 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 n° compte facturation. pour un compte enfant.

Vous pouvez définir un budget quotidien pour chaque ID de facturation. Contactez votre au responsable de compte de définir le budget quotidien pour les n° compte facturation des comptes enfants.

Les ID de facturation de tous les comptes enfants disposant d'un budget disponible pouvant 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-nous à votre responsable de compte pour modifier le budget d'un n° compte facturation de groupe de centres 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 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. Seules les unités CPM sont acceptées. (et non en micros).
render : URL affichée pour afficher 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 d'effectuer des tests des 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 des spécifications de Protected Audience.

Devise de l'enchère

Les enchères dans les navigateurs sont définies en unités de CPM dans la devise choisie pour l'enchère.

La devise de l'enchère doit être indiquée à la fois dans la réponse d'enchère contextuelle et dans la valeur renvoyée par 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 Google RTB, utilisez le nouveau champ currency dans le message InterestGroupBuyer de la réponse aux enchères.

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 à l'enchère contextuelle. Remplissez la nouvelle propriété bidCurrency 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 la devise renvoyé par generateBid. Si l'un d'eux renvoie une devise non valide, est filtrée avant la mise aux enchères.

Contrôles de la qualité des annonces

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

Assistance concernant le règlement sur les services numériques

Conformément à l'article 26 du règlement européen sur les services numériques, les éditeurs peuvent exiger des acheteurs qu'ils affichent des informations sur la transparence dans les annonces. Lorsque l'option "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ée par un éditeur, les acheteurs de groupes d'intérêt peuvent déterminer les opportunités pour lesquelles 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 le protocole Google RTB obsolète).

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. lors des enchères de l'API Protected Audience.

Pour en savoir plus sur le règlement sur les services numériques, consultez le Article du centre d'aide: Respecter la loi sur les services numériques

Filtrage des enchères

Google applique les commandes des éditeurs 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 l'enchère à l'acheteur : reportWin()

Google ne renseigne pas les arguments suivants:

auctionSignals
sellerSignals

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

Pour en savoir plus, consultez la section Rapports de l'acheteur 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êts terminée, mais avant l'affichage, les macros sont remplacées par les valeurs correspondantes. renderUrl utilisés dans les enchères sur l'appareil peuvent inclure les éléments suivants : :

`${GDPR}`	Cette valeur est remplacée par 0 si le RGPD ne s'applique pas ou par 1 si le RGPD s'applique. Consultez la documentation.
`${GDPR_CONSENT_XXXX}`	Développe la transparence & Chaîne TC (consentement) associée à la demande. Si le rapport "Transparence des informations La chaîne de consentement (TC) est vide ou non valide, cette macro n'est pas développée. Utilisez-la pour transmettre la chaîne TC à un fournisseur enregistré dans la LGF de l'IAB dans une URL. Remplacez `XXXX` par l'ID LGF de l'IAB de la LGF enregistrée par l'IAB fournisseur. Si la chaîne TC est vide ou incorrecte, cette macro n'est pas remplacée. Les créations qui incluent la macro `${GDPR_CONSENT_XXXX}` peuvent être bloquées si le fournisseur enregistré dans la LGF de l'IAB associé à l'ID repris dans la 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 au cours la `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 insèrent la largeur et la hauteur de l'espace publicitaire.
`${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}`	Macro contenant des signaux de l'acheteur au moment de l'affichage dans la réponse à l'enchère. Remplacez l'espace réservé `buyer.origin.example` par l'origine de l'acheteur du groupe de centres d'intérêt, qui doit correspondre à `interest_group_buyers.origin` dans la réponse aux enchères. Vous pouvez inclure un `_OPTIONAL_SUFFIX` pour fournir jusqu'à trois valeurs de signal de rendu différentes.

Comptabilisation des impressions

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

Puisque l'événement utilisé par Google pour comptabiliser les impressions dans Protected Audience les enchères dans les navigateurs peuvent être différentes de l'événement utilisé pour comptabiliser d'impressions par ses partenaires acheteurs utilisant le système d'enchères en temps réel, le nombre d'impressions peut différer.

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 provenant des enchères dans le navigateur Protected Audience sont attribuées à un seul compte d'enchérisseur en fonction du mappage des origines des propriétaires de groupes d'intérêts configurées pour l'enchérisseur. L'attribution des dépenses à différents comptes enfant d'un enchérisseur n'est pas possible.

Plafond budgétaire quotidien

Pendant les tests de l'API Protected Audience, chaque compte possède un niveau de compte Plafond budgétaire quotidien de l'API Protected Audience. La limite du budget quotidien limite le risque dans l'environnement d'enchères intégrées aux navigateurs. Une fois le plafond budgétaire quotidien atteint, le 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 d'atteindre le plafond Protected Audience. Par exemple, un compte d'enchérisseurs la limite Protected Audience peut recevoir une demande d'enchère avec auction_environment = SERVER_SIDE_AUCTION (OpenRTB JSON: 0), même si la demande d'enchère est éligible pour une mise aux enchères 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êts demandés à être inclus dans une enchère Protected Audience sur l'appareil. Chaque acheteur de groupes d'intérêt pour lequel un enchérisseur dans une réponse à l'enchère recevront un objet feedback, quelle que soit la manière d'enchères que l'acheteur du groupe d'intérêt place dans la mise aux enchères Protected Audience. Les informations suivantes seront disponibles dans l'objet "Commentaires des acheteurs sur les groupes d'intérêt" :

Le type de commentaires de l'objet "commentaires" est INTEREST_GROUP_BUYER_FEEDBACK.
Origine de l'acheteur du groupe de centres d'intérêt.
L'enchère minimale gagnante pour l'acheteur du groupe d'intérêt afin de remporter le lors de l'enchère globale.
Enchère minimale à remporter pour l'acheteur du groupe d'intérêt afin de battre le l'enchère la mieux classée par rapport au composant côté serveur de l'enchère globale.
Code d'état de l'acheteur du groupe de centres d'intérêt. Les codes d'état possibles sont les suivants : défini dans interest-group-buyer-status-codes.txt.

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

Notification de commentaires sur les enchères

Chrome propose un débogage temporaire API pour l'API Protected Audience, qui permet à Ad Manager d'envoyer des e-mails en temps réel des notifications de débogage de serveur à serveur qui contiennent des commentaires sur une protection Enchère d'audience. Cette notification inclura les raisons pour lesquelles les enchères peuvent avoir été filtrées dans l'enchère dans le navigateur Protected Audience, ainsi que d'autres informations sur l'enchère décrites ci-dessous.

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

%%GOOGLE_QUERY_ID%%: cette macro est remplacée par l'ID de requête Google. envoyé lors de 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 RTB Google obsolète utilise BidRequest.google_query_id.
%%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 un délai de scoreAd(). Les valeurs correspondent à l'état de la création codes.

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 la l'API ForDebuggingOnly temporaire.

TURTLEDOVE au niveau du produit

Les annonces composées de plusieurs éléments ou TURTLEDOVE au niveau du produit (PLTD) sont compatibles avec les partenaires Google RTB lors des tests de l'API Protected Audience. Informez votre responsable de compte lors de l'intégration si vous prévoyez de tester PLTD, 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.
Après avoir envoyé le formulaire de demande, contactez votre responsable de compte ou envoyez une demande à l'aide du Centre d'aide pour les acheteurs autorisés.
Une fois le compte configuré, Google et le partenaire peuvent vérifier l'intégration en suivant les étapes de la section Étapes de test.

Vérification des créations

Pour définir des enchères avec des annonces au niveau du produit (annonces composées de plusieurs éléments) dans les enchères de l'API Protected Audience, suivez ces exigences :

Incluez le paramètre de requête &pltd=True dans renderUrl pour le paramètre conteneur de l'annonce du composant (également appelé renderUrl de niveau supérieur) vers distinguer les renderUrls de premier niveau lors de l'examen des créations.
Afficher une création représentative lorsque le conteneur de l'annonce du composant est extrait pour un examen de la création par Google. Afin de comprendre quand un un rendu représentatif de l'annonce doit être renvoyé. Pour ce faire, reportez-vous à la Paramètre de requête validation=True défini par le système de vérification des créations de Google.

Checklist d'intégration

Configurez un point de terminaison de demande d'enchère qui renseignera 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 associer le navigateur de l'utilisateur au groupe de centres d'intérêt.
Implémentez generateBid() et reportWin().
Sélectionnez les origines des propriétaires de groupes de centres d'intérêt, puis ajoutez-les au compte d'acheteur autorisé.
- Les origines du propriétaire du groupe de centres d'intérêt doivent correspondre aux origines où les fonctions generateBid() sont hébergées.
- Contactez le responsable de compte ou déposez une demande d'assistance à l'aide de la Centre d'aide pour les acheteurs afin de effectuez cette étape.
Configurez le préciblage pour l'inventaire pertinent pour l'API Protected Audience tests.
Envoyez vos créations pour examen et approbation via la page Créations API.
(Facultatif) Configurez les points de terminaison des signaux d'enchères de confiance.
(Facultatif) Configurez une page d'annonceur de test qui permet aux ingénieurs Google d'ajouter leur navigateur aux groupes de centres d'intérêt appartenant à l'origine de l'acheteur de votre 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 concernant d'acheteurs de groupes de centres d'intérêt ont demandé à être inclus dans une audience Protected Audience mise aux enchères.
(Facultatif) Contactez votre responsable de compte pour configurer une URL statique vers recevoir une notification de serveur à serveur indiquant une enchère Protected Audience des commentaires sur l'état d'une enchère provenant d'une solution Protected Audience sur l'appareil ; pour résoudre les problèmes inattendus. Pour en savoir plus, consultez la notification sur les commentaires sur les enchères.

Étapes de test

Étape 1 : Test manuel

Pour déclencher manuellement une enchère Protected Audience, vous devez procéder comme suit :

Utilisez Chrome 101 ou une version ultérieure.
Activez l'API Privacy Sandbox et le cadre clôturé à l'aide de chrome://flags/#privacy-sandbox-ads-apis et chrome://flags/#enable-fenced-frames. Pour en savoir plus, consultez Tester la confidentialité Sandbox.
Envoyez une création pour approbation à l'aide de l'API d'enchères en temps réel.
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 suivante de l'éditeur de test fournie par Google pour déclencher une protection Enchères par type d'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 les enchères, car il peut être en concurrence avec les enchères côté serveur classiques. Google propose également page de l'éditeur de test dédiée à chaque partenaire, où seul le partenaire donné peuvent participer à l'enchère. Il pourrait être plus facile de gagner de manière fiable des enchères intégrées au navigateur sur la page 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'il s'agit d'un enchérisseur gagnant reçoit un ping en réponse de reportWin().
3. La console de la page de l'éditeur 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 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 les scoreAd() Les valeurs correspondent à l'état de la création codes.

Étape 2 : Test sans affichage (facultatif)

Une fois que Google et le partenaire ont vérifié manuellement que le partenaire peut participer aux enchères Protected Audience, Google active le partenaire pour la prochaine étape de test.

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

Contactez votre responsable de compte ou envoyez une demande via le Centre d'aide des acheteurs autorisés lorsque vous serez prêt. 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 aucun rendu, Google peut autoriser le partenaire à afficher Annonce qui a gagné en audience. Google enregistre un faible volume de trafic pour lequel les enchères Protected Audience peuvent être diffusées, et les annonces gagnantes des groupes d'intérêt sont affichées. Nombre d'enchérisseurs participants dans le navigateur sont mises en concurrence enchères.

Contactez votre responsable de compte ou envoyez une demande via le Centre d'aide des acheteurs autorisés lorsque vous serez prêt. Google activera le compte pour cette étape.

Autres fonctionnalités

Les fonctionnalités suivantes sont des extensions du protocole principal.

Parallélisation

La parallélisation est une optimisation qui réduit la latence des enchères de bout en bout la demande d'annonce contextuelle parallèlement aux demandes adressées à serveurs de confiance des acheteurs spécifié dans trustedBiddingSignalsUrl.

La parallélisation réduit la latence, mais affecte le groupe d'intérêt l'éligibilité des acheteurs et l'assistance tests coordonnés. La parallélisation s'applique à tous les enchérisseurs qui participent la mise aux enchères des groupes d'intérêt sur l'appareil. Aucune action n'est requise de la part des enchérisseurs participent à des enchères parallèles, mais ils doivent se familiariser avec l'impact de la parallélisation sur leur éligibilité aux enchères sur l'appareil. Les ID de groupe de test pour les tests coordonnés ne sont pas encore acceptés. dans le cadre d'enchères parallèles.

Résumé du flux de diffusion

Voici un récapitulatif du flux 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 se produit avant la réponse d'annonce contextuelle est renvoyée. Pour initier l'acheteur digne de confiance de serveur, navigator.runAdAuction exige que le Le paramètre interestGroupBuyers doit être transmis en tant que valeur, tandis que les paramètres d'enchères restants acceptent le code JavaScript Promesses qui peuvent être résolues après la réponse d'annonce contextuelle. Depuis interestGroupBuyers est transmis avant la réponse d'annonce contextuelle. La réponse d'annonce contextuelle (y compris les réponses aux enchères) ne peuvent pas servir à choisir les acheteurs qui participent à l'enchère parallélisée. pour la requête donnée. À la place, la balise d'éditeur de Google met en cache, dans le navigateur de l'utilisateur, le paramètre interestGroupBuyers des exécutions navigator.runAdAuction précédentes sur le même domaine.

Plusieurs points importants sont à prendre en compte pour la parallélisation:

Les signaux d'enchères qui ne sont pas nécessaires pour les requêtes de serveur approuvées par l'acheteur, 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 de ces signaux résolues, les étapes restantes du des enchères sur l'appareil se dérouleront de la même manière que pour les enchères le flux des enchères.
Étant donné que la parallélisation repose sur la mise en cache de la liste d'acheteurs de groupes d'intérêt, Google n'exécute pas toujours des enchères parallèles, car le cache de parallélisation sont peut-être vides ou ont expiré. Si le cache est vide ou expiré, Google exécute une mise aux enchères standard non parallèle de l'API Protected Audience et utilise l'intention d'achat pour participer à la mise aux enchères non parallèle afin de créer le cache des acheteurs de l'API de groupe d'intérêt.
Si au moins un acheteur pour un enchérisseur est mis en cache pour l'éditeur actuel Google exécute une requête parallèle lors de l'enchère, comme indiqué dans la demande d'enchère:
- Protocole RTB Google : BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB : BidRequest.imp.ext.interest_group_auction.parallelized
Chaque origine d'acheteur de groupe d'intérêts enregistré pour un enchérisseur donné qui a été incluse dans l'enchère parallèle est associée à une entrée ParallelAuctionBuyer correspondante :
- Protocole Google RTB: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
- OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer
Si une mise aux enchères 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é à la mise aux enchères actuelle sur l'appareil. 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êts donnée. Toutefois, les enchérisseurs qui indiquent un intérêt en incluant un ou plusieurs InterestGroupBuyer valides et éligibles dans leur réponse aux enchères verront les origines des acheteurs du groupe d'intérêts correspondants ajoutées au cache. Ces origines seront éligibles aux futures requêtes parallélisées du même navigateur et du même domaine. Vous pouvez indiquer votre intention de participer aux enchères de groupes de centres d'intérêt dans les champs suivants :
- Protocole Google RTB: BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB : BidResponse.ext.igbid.igbuyer
Les origines d'acheteurs 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 aux enchères peuvent recevoir un appel de serveur approuvé par l'acheteur, mais ne participeront pas à l'enchère parallèle.