Guide d'intégration et de test de l'API Protected Audience (anciennement FLEDGE) pour les SSP

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.

Schéma séquentiel illustrant les requêtes entre Chrome, SSP et
DSP

Options d'intégration

Option 1: Vendeur direct / vendeur individuel

Flux de demandes détaillé pour un vendeur individuel
enchères

Étapes :

  1. 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.
  2. 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
  3. La DSP répond par une réponse à l'enchère OpenRTB contenant des signaux pour enchères sur l'appareil.
  4. Le serveur SSP envoie une réponse d'annonce avec la configuration des enchères au tag d'emplacement publicitaire de la SSP.
  5. 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 DSP perBuyerSignals
  6. 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.
  7. Chrome appelle generateBid() Fonction JavaScript DSP pour chaque groupe d'intérêt participant.
  8. 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.
  9. Chrome appelle scoreAd() Fonction JavaScript SSP pour chaque groupe d'intérêt participant.
  10. Chrome appelle reportWin() Fonction JavaScript DSP pour indiquer le gagnant à la DSP.
  11. 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]
  • 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

Flux de demandes détaillé pour les enchères multivendeurs

Étapes :

  1. L'adaptateur SSP envoie une demande d'annonce au serveur SSP pour indiquer que le navigateur est compatible avec l'API Protected Audience.
  2. Le serveur de la SSP envoie une demande d'enchère OpenRTB contextuelle à la DSP, indiquant que est compatible avec l'API Protected Audience,
  3. Le serveur DSP renvoie une réponse à l'enchère openRTB contenant des signaux pour enchères sur l'appareil.
  4. Le serveur SSP envoie une réponse d'annonce avec la configuration des enchères au tag d'emplacement publicitaire de la SSP.
  5. L'adaptateur SSP Prebid fournit la configuration des enchères du composant à l'ad server de l'éditeur .
  6. Le tag du serveur publicitaire de l'éditeur envoie une demande d'annonce à ce serveur.
  7. Le tag de l'ad server de l'éditeur lance les enchères sur l'appareil en appelant runAdAuction(...) API.
  8. 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.
  9. Chrome appelle generateBid() Fonction JavaScript de la DSP pour chaque groupe de centres d'intérêt participant.
  10. 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.
  11. Chrome appelle scoreAd() Fonction JavaScript SSP pour chaque groupe d'intérêt participant.
  12. Chrome appelle reportWin() Fonction JavaScript DSP pour indiquer le gagnant à la DSP.
  13. 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

  • 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]
  • 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() et reportResult(). 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é serveur
  • 1: 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',
});

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.