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

API Protected Audience (anciennement FLEDGE)

Dans le cadre de la Privacy Sandbox, Chrome proposait Protected Audience API : une API intégrée à un navigateur permettant aux annonceurs et aux entreprises de technologie publicitaire de diffuser des annonces ciblées par groupes d'intérêt sans utiliser de cookies tiers, tout en protégeant les utilisateurs contre les attaques intersites le suivi.

Chrome exécute une origine essai 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érez les flux de l'API Protected Audience et découvrez leur efficacité.
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 Authorized Buyers partenaires:

Schéma de flux

Un enchérisseur collabore avec ses annonceurs afin de gérer des groupes de centres d'intérêt pour chaque annonceur. Souvent, les annonceurs ajoutent la balise d'un enchérisseur 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 les informations .
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 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 l'éditeur 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 un BidResponse avec le champ interest_group_bidding. Si l'enchérisseur ne spécifie pas interest_group_bidding, Google n'indique pas inclure l'origine de l'enchérisseur (interestGroupBuyers) dans la mise aux enchères ; configuration. La réponse à l'enchère peut également contenir le type d'enchère interest_group_bidding.per_buyer_signals. La valeur per_buyer_signals sera transmise à la fonction d'enchères de l'enchérisseur lors de la enchères intégrées au navigateur. Consultez la section Modifications apportées aux réponses aux enchères .
Google lance des enchères côté serveur et renvoie une réponse à l'enchère navigateur. Les enchères côté serveur tiennent compte des enchères traditionnelles côté serveur. La réponse à l'enchère peut contenir des informations sur une enchère contextuelle gagnante (si n'importe laquelle).
La réponse à l'enchère contient une configuration d'enchères pour le navigateur. mise aux enchères. Cela peut inclure des signaux de contexte de chaque acheteur participant (envoyés via interest_group_bidding.per_buyer_signals), des informations contextuelles sur le gagnant et les paramètres d'éligibilité aux 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 acheteurs qui ont déjà renvoyé interest_group_bidding en tant que interestGroupBuyers dans la configuration de la mise aux enchères.
Google transmet l'per_buyer_signals de chaque enchérisseur éligible à l'API Configuration des enchères d'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. Voir dans l'API Protected Audience caractéristiques.
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. Ce "step" calcule l'enchère et sélectionne une création. generateBid() a accès à La per_buyer_signals fournie par l'enchérisseur et le système 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, Google) pour d'attribuer un classement à chaque enchère dans les enchères publicitaires liées aux groupes de centres d'intérêt. Classement des enchères et filtrées en fonction des protections de l'éditeur, des règles relatives aux annonces de contraintes.
Le navigateur lance une mise aux enchères avec les enchères de groupes de centres d'intérêt éligibles. La l'enchère contextuelle la mieux classée participe 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 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 depuis Enchères dans les navigateurs Protected Audience. Vous pouvez envoyer des créations pour examen via l'API Real-time Bidding ou 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 qu'une seule publicité campagne. 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 fichier renderUrl doit être accessible et récupérable par le service hors connexion de Google systèmes 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 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 la vérification automatique des créations, Google trouve les créations dans des enchères intégrées au navigateur et les analyse automatiquement, afin qu'ils soient éligibles les 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 à l'aide de l'API API Bidding, vous devrez renvoyer la création après 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. Voir plus plus de détails dans Protected Audience documentation.

Voici un exemple d'ajout de buyerAndSellerReportingId dans la configuration du groupe 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 premières versions des protocoles pris en charge pour une utilisation dans le test:

Lien précoce du protocole Google RTB
Lien anticipé OpenRTB

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

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

Protocole Google RTB: BidRequest.adslot.auction_environment
OpenRTB: BidRequest.imp.ext.auction_environment

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. La 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 avec la prise en charge de l'API Protected Audience, dans laquelle une enchère contextuelle s'exécute sur le aux serveurs de la place de marché, et l'enchère du groupe d'intérêt est exécutée. dans le navigateur

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:

Protocole Google RTB: <ph type="x-smartling-placeholder">
- BidRequest.adslot.interest_group_auction.width
- BidRequest.adslot.interest_group_auction.height
OpenRTB: <ph type="x-smartling-placeholder">
- BidRequest.imp.ext.interest_group_auction.width
- BidRequest.imp.ext.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 être différente de celle de la requête contextuelle (Adslot.widthetAdslot.height, ou dans OpenRTB: BidRequest.imp.banner.format).

La requête contextuelle peut avoir plusieurs tailles. Enchères sur l'appareil ayant remporté l'enchère l'annonce ne doit occuper qu'une seule taille d'espace publicitaire 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.

Protocole Google RTB: BidRequest.adslot.interest_group_auction.render_interest_group_ads
OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads

Limiter l'utilisation des identifiants utilisateur

Les demandes d'enchères contextuelles concernées par les tests de l'API Protected Audience peuvent continuent de transférer les identifiants traditionnels basés sur les cookies lorsqu'ils sont disponibles tel que 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 continueront d'être soumis aux règles de confidentialité. Nous vous recommandons de ne pas vous appuyer sur les identifiants basés sur les cookies pour le ciblage et les enchères pendant les tests afin de mieux vous préparer lorsque les cookies tiers ne sont plus disponibles.

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

Tests d'abandon des cookies tiers géré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 gérés par Chrome pour tester leurs systèmes dans 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 l'étiquette non modifiée de l'API Chrome à l'enchère RTB. requête. En raison de la petite portion de trafic associée à un libellé, Google n'inclut pas toujours le libellé dans les contextes où la confidentialité est limitée.

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

Protocole Google RTB: 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 d'un groupe d'intérêt

Il vous appartient d'indiquer explicitement votre intention de participer au enchères intégrées au navigateur en renvoyant l'objet InterestGroupBidding dans réponse à l'enchère contextuelle:

Protocole Google RTB: BidResponse.interest_group_bidding
OpenRTB: BidResponse.ext.igbid

Vous devez fournir une réponse à l'enchère contextuelle. Il n'est pas nécessaire de répondre inclure une enchère contextuelle L'objet InterestGroupBidding doit contenir le origin du propriétaire du groupe d'intérêt, 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 les signaux de contexte de l'acheteur (perBuyerSignals)

Vous pouvez inclure les signaux de l'acheteur dans la réponse à l'enchère contextuelle, se propage en tant qu'objet JSON à leur 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:

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

Propager les signaux d'affichage contextuel de l'acheteur

Les créations liées à des groupes de centres d'intérêt peuvent utiliser des signaux de contexte limités lors de leur diffusion : en envoyant ces signaux via la réponse à l'enchère contextuelle et en les recevant dans la demande d'URL de rendu à l'aide de l'extension 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:

RTB Google: BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.rsig

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 maximal de l'enchère 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.

En guise de mesure d'atténuation 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 la réponse à l'enchère contextuelle. L'enchère maximale attendue est l'enchère maximale qui que votre fonction d'enchères est censée renvoyer. Si l'enchère gagnante indiquée l'enchère dans le navigateur dépasse ce montant, l'enchère gagnante n'est pas comptabilisée. en tant qu'é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:

Protocole Google RTB: 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 son intérêt pour regrouper les impressions d'enchères à l'aide des champs suivants:

Protocole Google RTB: 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 dans la demande d'enchère:

Protocole Google RTB: 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 de groupes de centres d'intérêt n'est pas l'enchérisseur ne participera pas aux enchères Protected Audience.

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

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

N° compte facturation pour tous les comptes enfants dont le budget est disponible et éligibles pour définir des enchères sur le impression apparaîtront sur 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 contenant les mêmes signaux que ceux fournis par le 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. Les unités au CPM doivent être exprimées en unités. (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 filtrée de la mise en concurrence.
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};
}

Consultez la spécification Protected Audience Sur l'appareil Enchères pour obtenir des explications sur la fonction generateBid().

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 à l'enchère contextuelle et dans la valeur renvoyée pour generateBid et doit correspondre à un code alpha ISO 4217 valide, tel que "USD", "EUR" ou "JPY".

Dans OpenRTB, utilisez le nouveau champ cur de l'objet InterestGroupBuyer dans 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 de Google, utilisez le nouveau champ currency dans InterestGroupBuyer dans la réponse à l'enchère.

Exemple :

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

Enchérisseurs Les fonctions generateBid doivent renvoyer des enchères dans la même devise que indiqué 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 enchères de groupes de centres d'intérêt dans le navigateur lors des tests de l'API Protected Audience pour les enchères en temps réel partenaires.

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

Conformément à l'article 26 du règlement sur les services numériques, les éditeurs peuvent demander aux acheteurs les mentions de transparence dans les annonces. Lorsque la case "Demander aux acheteurs de ne diffuser que des annonces avec la transparence sur mon site ou dans mon application dans l'EEE" est activée par un les acheteurs de groupes d'intérêt peuvent déterminer les opportunités pour rendre la transparence auprès des acheteurs en indiquant les champs suivants sur ont reçu des demandes d'enchères: 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 souhaitant participer aux enchères de l'API Protected Audience reçoit le signal dans la demande d'enchère que la transparence DSA doit être affichée pour diffusées via l'API Protected Audience, il doit évaluer si il peut afficher correctement les informations requises et le spécifier en définissant BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render pour le protocole Google Authorized Buyers BidResponse.ext.igbid.igbuyer.dsaadrender pour le protocole OpenRTB. Sinon, l'acheteur ne sera pas inclus dans les 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 fait en sorte que les éditeurs de contrôle et ad règles lors des enchères sur l'appareil.

Après l'enchère dans le navigateur

Signaler le résultat des enchères à 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.

Consultez l'article Créer des rapports d'acheteurs sur l'affichage et les annonces Événements de la vidéo d'explication 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. Après la mise aux enchères des groupes de centres d'intérêt mais avant le rendu, les macros sont remplacées par les macros valeurs. 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 et la chaîne de consentement (TC) 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 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 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 comportant la macro `${GDPR_CONSENT_XXXX}` peuvent devenir bloqué si le fournisseur enregistré sur la LGF de l'IAB et associé à l'ID de cette LGF de l'IAB que vous inséré n'a pas le consentement de l'utilisateur. La macro `${GDPR_CONSENT_XXXX}` ne doit apparaître qu'une seule fois au cours la `renderUrl`.
`${ADDL_CONSENT}`	Développe l'élément Chaîne de consentement (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.
`${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 d'intérêt, ce qui correspond `interest_group_buyers.origin` dans la réponse à l'enchère. Vous pouvez inclure un élément `_OPTIONAL_SUFFIX` pour fournir jusqu'à trois des signaux de rendu.

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 pour réduire ces écarts.

Attribution d'impressions facturables

Toutes les dépenses d'un enchérisseur issues des enchères dans les navigateurs Protected Audience sont à un seul compte d'enchérisseurs en fonction de la mise en correspondance origines du propriétaire du groupe configurées pour l'enchérisseur. Les dépenses sont attribuées les comptes de sous-comptes utilisateur d'un enchérisseur n'est pas accepté.

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 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: 0), même si la demande d'enchère est éligible pour une lors de la mise aux enchères Protected Audience.

Commentaires en temps réel et enchère minimale pour gagner

Enchérisseurs qui ont accepté de recevoir commentaires en temps réel recevront des commentaires concernant les acheteurs de groupes d'intérêt à inclure dans un de l'API Protected Audience sur l'appareil. Chaque acheteur de groupes d'intérêt pour lequel un enchérisseur spécifié 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. La les informations suivantes seront disponibles sur les commentaires des acheteurs du groupe de centres d'intérêt objet:

Le type de commentaire de l'objet feedback 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 la 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.

Reportez-vous à la documentation du protocole Enchères en temps réel Authorized Buyers et les extensions OpenRTB pour les noms de champs spécifiques.

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 précise les raisons pour lesquelles des enchères ont pu être dans la mise aux enchères Protected Audience dans le navigateur, en plus des autres sur une enchère, comme décrit 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. Ce L'URL statique sera extraite des serveurs Google avec les macros sélectionnées remplacées une fois la mise aux enchères 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. (BidRequest.google_query_id dans le protocole Authorized Buyers et BidRequest.ext.google_query_id dans le protocole OpenRTB) qui a été envoyé Demande d'enchère contextuelle compatible avec Protected Audience.
%%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 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

Annonces composées de plusieurs éléments ou Au niveau du produit TURTLEDOVE (PLTD) est disponible pour les partenaires RTB Google avec l'API Protected Audience tests. Si vous prévoyez d'effectuer un test, indiquez-le à votre responsable de compte pendant l'intégration 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 une demande d'assistance via le Centre d'aide d'accessibilité.
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, respectez les exigences suivantes:

Incluez le paramètre de requête &pltd=True dans le renderUrl pour la 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 composant est récupérée pour examen 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 pour l'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 des tags sur les pages de l'annonceur pour joindre le navigateur de l'utilisateur à le groupe d'intérêt.
Implémentez generateBid() et reportWin().
Sélectionnez les origines des propriétaires de groupes de centres d'intérêt et ajoutez-les à Authorized Buyers Google Cloud.
- L'origine du propriétaire du groupe de centres d'intérêt doit correspondre à celle où le 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) Configurer une page d'annonceur test permettant aux ingénieurs Google d'ajouter son navigateur aux groupes de centres d'intérêt appartenant origine. Cela nous permet de déclencher manuellement les 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. Voir les commentaires sur les enchères notification pour en savoir plus.

Étapes de test

Étape 1: Test manuel

Voici comment déclencher manuellement une mise aux enchères Protected Audience, vous assurer que l'annonce peut et enregistrer l'impression:

Utilisez Chrome 101 ou une version ultérieure.
Activer l'API Privacy Sandbox et le frame cloisonné à 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 du système d'enchères en temps réel API.
Utiliser la page de l'annonceur fournie par l'enchérisseur pour ajouter un navigateur à celui appartenant à l'enchérisseur un groupe d'intérêt.
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 l'enchère, peut entrer en concurrence avec les enchères traditionnelles côté serveur. 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 s'affiche.
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: <ph type="x-smartling-placeholder">
  - 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 l'enchère 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 qu'ils peuvent à la mise aux enchères Protected Audience, Google permet au partenaire l'étape suivante des tests.

Google alloue une petite quantité de trafic en direct pour exécuter Protected Audience mises en concurrence. Ainsi, Google et le partenaire n'ont plus besoin de déclencher manuellement lors de la 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 Authorized Buyers Centre d'aide. 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 une petite quantité de trafic pour laquelle Les enchères basées sur l'audience peuvent être diffusées, et les annonces gagnantes pour des groupes de centres d'intérêt sont rendu. Nombre d'enchérisseurs participants dans le navigateur sont mises en concurrence enchères.

Contactez votre responsable de compte ou envoyez une demande via Authorized Buyers Centre d'aide. 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 de groupes de centres 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, le tag d'éditeur de Google dans le navigateur de l'utilisateur, le paramètre interestGroupBuyers utilisé précédemment navigator.runAdAuction exécutions 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 demandes de serveur de confiance de 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 a expiré, Google exécute une aux enchères standards non parallèles de l'API Protected Audience et utilise l'intention de l'acheteur pour participer aux enchères non parallèles pour constituer le cache des acheteurs du 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 Google RTB: BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized
Chaque origine d'acheteur de groupe d'intérêt enregistrée pour un enchérisseur donné qui était inclus dans le système d'enchères parallèles Entrée ParallelAuctionBuyer:
- 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 lancée, mais qu'aucune origine d'acheteur spécifique n'est présente dans dans le cache, l'acheteur ne peut pas être ajouté à l'état actuel mise aux enchères. Cela est indiqué par une requête avec parallelized=True qui ne comporte pas Entrée ParallelAuctionBuyer pour une origine d'acheteur de groupe de centres d'intérêt donnée. Toutefois, les enchérisseurs qui montrent leur intérêt en incluant des mots clés valides et éligibles InterestGroupBuyer sur sa réponse à l'enchère dispose de l'acheteur du groupe de centres d'intérêt correspondant ajoutées au cache et pourront être utilisées de requêtes parallélisées à partir du même navigateur et du même domaine. Intention de participer à des enchères basées sur des groupes d'intérêt peuvent être indiquées dans les champs suivants:
- Protocole Google RTB: BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB: BidResponse.ext.igbid.igbuyer
Origines de l'acheteur en cache (incluses dans les attributs interestGroupBuyers) pour laquelle l'enchérisseur n'indique pas l'intention. à participer à sa réponse à l'enchère peuvent recevoir un appel de l'acheteur à un serveur de confiance mais elles ne participeront pas aux enchères parallèles.