Dans le cadre de la Privacy Sandbox, Chrome proposait Protected Audience , une API intégrée au navigateur permettant aux annonceurs et aux entreprises de technologie publicitaire d'organiser et de cibler des groupes d'intérêt (listes d'audience) sans utiliser de cookies tiers, tout en protégeant les utilisateurs grâce au suivi intersites. Développeur ce guide
Les SSP peuvent tester l'API Protected Audience avec Display & Video 360 et Google Ads pour:
- Itérez les flux de l'API Protected Audience et découvrez leur efficacité.
- Proposer des améliorations potentielles aux API et générer des commentaires à leur sujet (par exemple, GitHub).
- Se préparer à la publicité personnalisée avec l'API Protected Audience sans utiliser de cookies tiers.
Le guide suivant décrit les détails de l'intégration entre une SSP et Display & Video 360 et Google Ads. Les SSP qui souhaitent coordonner un test doivent avec leur Réseau Display et Représentant de partenariat Video 360.
Inscription
Les SSP doivent enregistrer eux-mêmes à utilisez l'API Protected Audience.
Résumé du flux de diffusion
Le schéma suivant illustre la procédure générique décrivant les principaux points d'interaction entre Chrome, SSP, Display et Video 360 et Google Ads.
Options d'intégration
Option 1: Vendeur direct / vendeur individuel
Étapes :
- Le tag d'emplacement publicitaire de la SSP envoie une demande d'annonce au serveur SSP pour indiquer que le navigateur est compatible avec l'API Protected Audience.
- Le serveur de la SSP envoie une demande d'enchère OpenRTB contextuelle à la DSP, indiquant que navigateur est compatible avec l'API Protected Audience
- La DSP répond par une réponse à l'enchère OpenRTB contenant des signaux pour enchères sur l'appareil.
- Le serveur SSP envoie une réponse d'annonce avec la configuration des enchères au tag d'emplacement publicitaire de la SSP.
- Le tag d'emplacement publicitaire SSP lance l'enchère sur l'appareil en appelant
runAdAuction()
, en transmettant les signaux de la réponse à l'enchère OpenRTB de la DSPperBuyerSignals
- Chrome appelle le serveur d'enchères DSP de confiance pour les clés-valeurs pour récupérer des signaux d'enchères en temps réel.
- Chrome appelle
generateBid()
Fonction JavaScript DSP pour chaque groupe d'intérêt participant. - Chrome appelle le serveur d'évaluation SSP de confiance pour les clés-valeurs pour récupérer des signaux d'évaluation en temps réel.
- Chrome appelle
scoreAd()
Fonction JavaScript SSP pour chaque groupe d'intérêt participant. - Chrome appelle
reportWin()
Fonction JavaScript DSP pour indiquer le gagnant à la DSP. - Chrome appelle
reportResult()
Fonction JavaScript de la SSP pour indiquer le gagnant à la SSP.
Modifications minimales côté SSP
Le tag d'emplacement publicitaire de la SSP doit être mis à jour
- détecter si le navigateur est compatible avec l'API Protected Audience
- envoyer ces informations dans la demande d'annonce au serveur SSP
[1]
- lancer une enchère sur l'appareil en appelant
runAdAuction()
et en transmettant provenant de la réponse à l'enchère OpenRTB du DSP[5]
(consultez le champ "buyerdata" dans structure de demande d'enchère et de réponse ci-dessous).
le serveur SSP doit
- propager des informations sur la compatibilité de l'API Protected Audience vers la DSP
via le champ de la demande d'enchère OpenRTB
[2]
(voir la section sur les enchères structure de requête et de réponse ci-dessous). - propager les signaux de l'acheteur DSP dans la réponse à l'enchère OpenRTB à l'annonce SSP
(voir la section sur la structure des demandes d'enchères et des réponses aux enchères ci-dessous)
[4]
- propager des informations sur la compatibilité de l'API Protected Audience vers la DSP
via le champ de la demande d'enchère OpenRTB
La SSP
[Optional]
doit implémenter le serveur SSP de confiance pour récupérer les données en temps réel les signaux d'évaluation pour permettre les contrôles de la qualité des annonces, l'application des paramètres de l'éditeur[8]
La SSP doit implémenter JavaScript avec
"scoreAd(...)"
et"reportResult(...)"
. fonctions[9]
,[11]
Option 2: Multivendeur
Étapes :
- L'adaptateur SSP envoie une demande d'annonce au serveur SSP pour indiquer que le navigateur est compatible avec l'API Protected Audience.
- Le serveur de la SSP envoie une demande d'enchère OpenRTB contextuelle à la DSP, indiquant que est compatible avec l'API Protected Audience,
- Le serveur DSP renvoie une réponse à l'enchère openRTB contenant des signaux pour enchères sur l'appareil.
- Le serveur SSP envoie une réponse d'annonce avec la configuration des enchères au tag d'emplacement publicitaire de la SSP.
- L'adaptateur SSP Prebid fournit la configuration des enchères du composant à l'ad server de l'éditeur .
- Le tag du serveur publicitaire de l'éditeur envoie une demande d'annonce à ce serveur.
- Le tag de l'ad server de l'éditeur lance les enchères sur l'appareil en appelant
runAdAuction(...)
API. - Chrome appelle le serveur d'enchères DSP de confiance pour les clés-valeurs pour récupérer des signaux d'enchères en temps réel.
- Chrome appelle
generateBid()
Fonction JavaScript de la DSP pour chaque groupe de centres d'intérêt participant. - Chrome appelle le serveur d'évaluation SSP de confiance pour les clés-valeurs pour récupérer des signaux d'évaluation en temps réel.
- Chrome appelle
scoreAd()
Fonction JavaScript SSP pour chaque groupe d'intérêt participant. - Chrome appelle
reportWin()
Fonction JavaScript DSP pour indiquer le gagnant à la DSP. - Chrome appelle
reportResult()
Fonction JavaScript de la SSP pour indiquer le gagnant à la SSP.
Modifications minimales côté SSP
L'adaptateur SSP doit être mis à jour vers
- détecter si le navigateur est compatible avec Protected Audience
- envoyer ces informations dans la demande d'annonce au serveur SSP
[1]
- Fournissez la configuration des enchères du composant au tag d'emplacement publicitaire
[5]
de l'ad server de l'éditeur. - Si Google Ad Manager est l'ad server de l'éditeur, la SSP peut :
* Utilisez Protected Audience avant enchère
ce module
* Appelez le tag d'emplacement publicitaire
setConfig()
Google Ad Manager API avec plusieurs vendeurs
le serveur SSP doit
- propager des informations sur la compatibilité de Protected Audience avec la DSP via
champ de la demande d'enchère OpenRTB
[2]
(voir la section sur les enchères structure de requête et de réponse ci-dessous). - propager les signaux de l'acheteur DSP dans la réponse à l'enchère OpenRTB à l'annonce SSP
(voir la section sur la structure des demandes d'enchères et des réponses aux enchères ci-dessous)
[4]
- propager des informations sur la compatibilité de Protected Audience avec la DSP via
champ de la demande d'enchère OpenRTB
La SSP
[Optional]
doit implémenter le serveur SSP de confiance pour récupérer les données en temps réel les signaux d'évaluation pour permettre les contrôles de la qualité des annonces, l'application des paramètres de l'éditeur[10]
La SSP doit exposer JavaScript avec
scoreAd()
etreportResult()
. fonctions[11]
et[14]
.
Services d'enchères et de mise aux enchères
Nous évaluons de près le système d'enchères Services d'enchères
proposal
Lorsque l'écran affiche et Video 360 est prêt à tester l'API Protected Audience avec les enchères et mises aux enchères. nous vous communiquerons plus d'informations.
Protocole OpenRTB
Demande d'enchère
Pour différencier les opportunités d'impression compatibles avec la protection
enchères sur l'appareil générées par l'API Audience et n'acceptant que les audiences standards
enchères sur une place de marché côté serveur, un nouveau champ d'énumération appelé ae
pour "mise aux enchères".
environnement" doit être ajouté en tant qu'extension de l'objet Imp
dans le système OpenRTB
afin de spécifier l'environnement d'enchères compatible avec
l'emplacement d'impression. L'énumération ae
peut avoir les valeurs suivantes:
0
: enchères standards côté serveur1
: requêtes compatibles avec l'API Protected Audience, dans lesquelles un contexte sur les serveurs de la place de marché. Les enchères du groupe de centres d'intérêt L'enchère finale a lieu dans le navigateur.
{
"id": …
"imp": [{
"id": "1"
"video": {...}
"ext": {
"ae": 1
}]
}
Réponse à l'enchère
Outre les enchères contextuelles, une réponse à l'enchère permet de transmettre d'informations pertinentes pour le Réseau Display Participation à Video 360 et Google Ads Enchères de groupes de centres d'intérêt de l'API Protected Audience. La réponse à l'enchère est remplacée par sont compatibles avec les enchères de groupes d'intérêt comme suit:
{
"seatbid": [{
"bid": [{
… // Traditional contextual bids
}]
}],
"ext": {
// InterestGroupBidding object which holds information for running an
// in-browser interest group auction.
"igbid": [{
// ID of the Imp object of the impression to which
// these interest group bidding signals apply to.
"impid": "1",
// InterestGroupBuyer object which holds DSP information for the in-browser
// auction.
"igbuyer": [{
// Origin of Display & Video 360 and Google Ads to participate in the
// interest group auction. For more info regarding the origin see:
// https://developer.mozilla.org/en-US/docs/Glossary/Origin
"origin": "https://td.doubleclick.net",
// Buyer-specific signals to use in auctionConfig as perBuyerSignals.
// Used by the buyer's interest group bidding function. Can be left empty
"buyerdata": ...,
// Buyer experiment group id to support coordinated experiments with
// buyers' trusted servers. This experiment id should be added to the
// `perBuyerExperimentGroupIds` map in auctionConfig.
"buyer_experiment_group_id": 12345
}]
}]
}
}
Les scénarios suivants sont acceptés.
SCÉNARIO 1: Display & Video 360 et Google Ads souhaitent uniquement participer lors d'enchères contextuelles. Dans ce scénario, aucun champ igbid n'est présent.
SCÉNARIO 2: Réseau Display et Video 360 et Google Ads souhaitent uniquement participer lors d'enchères basées sur des groupes d'intérêt. Dans ce scénario, les campagnes display et Video 360 et Google Ads supprimera le champ "seatbid" dans la réponse à l'enchère et ne renvoie des informations igbid. En d'autres termes, la présence du champ igbid indique le fait que Display & Video 360 et Google Ads veulent ses groupes de centres d'intérêt pour participer à l'enchère sur l'appareil.
SCÉNARIO 3: Réseau Display et Video 360 et Google Ads souhaitent participer à les enchères contextuelles et celles par groupes d'intérêt. Dans ce scénario, les campagnes display et Video 360 et Google Ads renverront les deux champs "seatbid" dans la réponse à l'enchère. et les informations igbid.
Métadonnées avec enchère d'annonce
L'API Protected Audience autorise passing arbitrary
metadata
à propos de l'annonce grâce à la fonction generateBid()
.
Display & Video 360 prévoit de s'appuyer sur les éléments suivants
specification
pour les métadonnées de l'annonce: API Protected Audience et OpenRTB.
à savoir Display & Video 360 renvoie les champs suivants dans l'annonce objet:
Attribut PA | Type | Description OpenRTB |
---|---|---|
ad.seat | String; obligatoire | Identifiant du siège acheteur (annonceur ou agence, par exemple) au nom duquel cette enchère est effectuée. |
ad.adomain | String[] | Domaine de l'annonceur pour la vérification de la liste de blocage (par exemple, "ford.com"). Pour les créations diffusées en alternance, il peut s'agir d'un tableau. Les échanges peuvent exiger qu'un seul domaine soit autorisé. |
ad.cid | chaîne | ID de campagne pour faciliter le contrôle de la qualité des annonces. |
ad.crid | chaîne | ID de la création pour faciliter le contrôle de la qualité des annonces. |
ad.language | chaîne | Langue de la création utilisant la norme ISO-639-1-alpha-2. Code non standard "xx" peuvent également être utilisées si la création n'a pas de contenu linguistique (par exemple, une bannière contenant uniquement le logo d'une entreprise). Une seule langue ou un seul langb doit être présent. |
ad.w | entier | Largeur de la création en pixels indépendants de l'appareil (DIPS). |
ad.h | entier | Hauteur de la création en pixels indépendants de l'appareil (DIPS). |
Exemple
{
"seat": "123"
"adomain": ["example.com"]
"cid": "12345"
"crid": "12345"
"language": "en"
"w": 300
"h": 250
}
Rapports sur les événements
L'API Protected Audience fournit une API de création de rapports au niveau des événements décrite dans cet article
Post GitHub: Fenced Frame Ads
Reporting
.
Même si son nom indique "Fenced Frame Ads Reporting", l'API est disponible dans
à la fois des cadres cloisonnés et des cadres iFrame (voir les détails
here
).
La SSP peut enregistrer une URL auprès du navigateur dans sa fonction reportResult en
appel de registerAdBeacon()
en cours
API.
Display & Video 360 appellera reportEvent()
API avec la destination "component-seller" à partir de la création pour générer un rapport
les impressions et les événements de clic. Cela entraînera l'envoi d'une balise au
URL enregistrée.
Notez que les campagnes display et Video 360 appellera l'API reportEvent()
pour les impressions et
sans données sur les posts.
Exemple
registerAdBeacon({
'impression': 'https://ssp.example/impression?ssp_event_id=abc',
});
registerAdBeacon({
'click': 'https://ssp.example/click?ssp_event_id=abc',
});
Libellé de test d'abandon des cookies
Display & Video 360 participera à Chrome-facilitated
testing
des
l'abandon des cookies tiers. Pour pouvoir effectuer les tests, nous demandons à nos partenaires de
transmettez-nous les libellés Chrome dans la demande d'enchère OpenRTB :
specification
:
Objet: Device.ext
Attribut | Type | Description |
---|---|---|
CPE | Chaîne | le libellé tel qu'il a été reçu de Chrome ou d'un partenaire en amont. |