Integrations- und Testleitfaden für Protected Audience (früher FLEDGE) für SSPs

Chrome hat im Rahmen der Privacy Sandbox Geschützte Zielgruppe API, eine browserinterne API mit der Werbetreibende und AdTech-Unternehmen Interessengruppen zusammenstellen und ansprechen können (Zielgruppenlisten), ohne sich auf Drittanbieter-Cookies zu verlassen, während vom websiteübergreifenden Tracking entfernt. Entwickler*in Leitfaden

SSPs können Protected Audience API mit Display- und Mit Video 360 und Google Ads können Sie:

  • In diesem Kurs erfahren Sie mehr über die Wirksamkeit von Protected Audience API-Abläufen.
  • Potenzielle API-Verbesserungen öffentlich vorschlagen und Feedback dazu einholen Foren, z. B. GitHub.
  • Unterstützung von personalisierten Anzeigen mit Protected Audience vorbereiten ohne Drittanbieter-Cookies zu verwenden.

Im folgenden Leitfaden werden die Integrationsdetails zwischen einer SSP und Display- und Video 360 und Google Ads. SSPs, die einen Test koordinieren möchten, sollten Kontakt mit dem Display- und Video 360-Partnerschaftsbeauftragter.

Registrierung

SSPs sollten sich die Protected Audience API verwenden.

Zusammenfassung des Bereitstellungsablaufs

Das folgende Diagramm zeigt den allgemeinen Ablauf, in dem die wichtigsten Interaktionspunkte zwischen Chrome, SSP, Display- und Video 360 und Google Ads.

Sequenzdiagramm, das Anfragen zwischen Chrome, SSP und DSP

Integrationsoptionen

Option 1: Direkt / Einzelkundenkonto

Detaillierter Ablauf bei Anfragen für Einzelkunden Auktionen

Schritte:

  1. Mit dem SSP-Anzeigen-Tag wird eine Anzeigenanfrage an den SSP-Server gesendet. unterstützt die Protected Audience API.
  2. Der SSP-Server sendet eine kontextbezogene OpenRTB-Gebotsanfrage an die DSP, die angibt, Browser unterstützt die Protected Audience API
  3. Die DSP antwortet mit einer OpenRTB-Gebotsantwort, die Signale für den On-Device-Auktion ab.
  4. Der SSP-Server sendet die Anzeigenantwort mit der Auktionskonfiguration an das SSP-Anzeigen-Tag.
  5. SSP-Anzeigen-Tag initiiert On-Device-Auktion durch Aufruf von runAdAuction(), Signale aus der OpenRTB-Gebotsantwort der DSP über perBuyerSignals.
  6. Chrome ruft einen vertrauenswürdigen DSP-Bidding-Server für Schlüssel/Wert-Paare auf. um Signale für Echtzeitgebote abzurufen.
  7. Chrome-Aufrufe generateBid() DSP-JavaScript-Funktion für jede teilnehmende Interessengruppe.
  8. Chrome ruft einen vertrauenswürdigen SSP-Server für Schlüssel/Wert-Paare auf. zum Abrufen von Bewertungssignalen in Echtzeit.
  9. Chrome-Aufrufe scoreAd() SSP-JavaScript-Funktion für jede teilnehmende Interessengruppe
  10. Chrome-Aufrufe reportWin() DSP-JavaScript-Funktion, um den Gewinner an die DSP zu melden.
  11. Chrome-Aufrufe reportResult() SSP-JavaScript-Funktion zur Meldung des Gewinners an die SSP

Mindeständerungen auf der SSP-Seite

  • SSP-Anzeigen-Tag muss aktualisiert werden auf

    • Ermitteln, ob der Browser die Protected Audience API unterstützt
    • Diese Informationen werden im Rahmen der Anzeigenanfrage an den SSP-Server [1] gesendet.
    • eine On-Device-Auktion durch Aufruf von runAdAuction() initiieren Signale aus der OpenRTB-Gebotsantwort der DSP [5] (siehe Feld "buyerdata" auf Gebotsanfrage- und Antwortstruktur weiter unten).

  • muss der SSP-Server

    • Informationen zur Unterstützung der Protected Audience API an die DSP weitergeben in der OpenRTB-Gebotsanfrage [2] (siehe Abschnitt zu Geboten) Anfrage- und Antwortstruktur weiter unten).
    • Käufersignale der DSP in der OpenRTB-Gebotsantwort auf die SSP-Anzeige übertragen Tag (siehe Abschnitt zur Struktur der Gebotsanfragen / Gebotsantworten) [4]

  • [Optional] SSP muss einen vertrauenswürdigen SSP-Server implementieren, um Echtzeitdaten abzurufen Bewertungssignale zur Unterstützung von Anzeigenqualitätsprüfungen, Durchsetzung der Publisher-Einstellungen [8]

  • SSP muss JavaScript mit "scoreAd(...)" und "reportResult(...)" implementieren Funktionen [9], [11]

Option 2: Mehrfachkundenkonto

Detaillierter Ablauf bei Anfragen für Auktionen mit mehreren Verkäufern

Schritte:

  1. Der SSP-Adapter sendet eine Anzeigenanfrage an den SSP-Server und gibt an, dass der Browser unterstützt die Protected Audience API.
  2. Der SSP-Server sendet eine kontextbezogene OpenRTB-Gebotsanfrage an die DSP, die angibt, die Protected Audience API unterstützt,
  3. Der DSP-Server antwortet mit einer OpenRTB-Gebotsantwort, die Signale für On-Device-Auktion ab.
  4. Der SSP-Server sendet die Anzeigenantwort mit der Auktionskonfiguration an das SSP-Anzeigen-Tag.
  5. Der SSP-Prebid-Adapter stellt die Konfiguration der Komponentenauktion für den Publisher-Ad-Server bereit Tag.
  6. Das Ad-Server-Tag des Publishers sendet die Anzeigenanfrage an den Ad-Server-Server des Publishers.
  7. Das Ad-Server-Tag des Publishers initiiert die On-Device-Auktion durch Aufruf von runAdAuction(...) der API erstellen.
  8. Chrome ruft einen vertrauenswürdigen DSP-Bidding-Server für Schlüssel/Wert-Paare auf. um Signale für Echtzeitgebote abzurufen.
  9. Chrome-Aufrufe generateBid() DSP-JavaScript-Funktion für jede teilnehmende Interessengruppe.
  10. Chrome ruft einen vertrauenswürdigen SSP-Server für Schlüssel/Wert-Paare auf. zum Abrufen von Bewertungssignalen in Echtzeit.
  11. Chrome-Aufrufe scoreAd() SSP-JavaScript-Funktion für jede teilnehmende Interessengruppe
  12. Chrome-Aufrufe reportWin() DSP-JavaScript-Funktion, um den Gewinner an die DSP zu melden.
  13. Chrome-Aufrufe reportResult() SSP-JavaScript-Funktion zur Meldung des Gewinners an die SSP

Mindeständerungen auf der SSP-Seite

  • SSP-Adapter muss aktualisiert werden auf

    • Ermitteln, ob der Browser Protected Audience unterstützt
    • Diese Informationen werden im Rahmen der Anzeigenanfrage an den SSP-Server [1] gesendet.
    • Die Auktionskonfiguration der Komponente für das Publisher-Ad-Server-Anzeigen-Tag [5] bereitstellen.
    • Wenn Google Ad Manager der Ad-Server des Publishers ist, kann die SSP entweder * Verwenden Sie prebid Protected Audience. Modul * Google Ad Manager-Anzeigen-Tag setConfig() aufrufen API mit mehreren Verkäufer

  • muss der SSP-Server

    • Informationen zur Protected Audience-Unterstützung über in der OpenRTB-Gebotsanfrage [2] (siehe Abschnitt zu Geboten) Anfrage- und Antwortstruktur weiter unten).
    • Käufersignale der DSP in der OpenRTB-Gebotsantwort auf die SSP-Anzeige übertragen Tag (siehe Abschnitt zur Struktur der Gebotsanfragen / Gebotsantworten) [4]

  • [Optional] SSP muss einen vertrauenswürdigen SSP-Server implementieren, um Echtzeitdaten abzurufen Bewertungssignale zur Unterstützung von Anzeigenqualitätsprüfungen, Durchsetzung der Publisher-Einstellungen [10]

  • SSP muss JavaScript mit scoreAd() und reportResult() verfügbar machen Funktionen [11], [14].

Gebots- und Auktionsdienste

Wir werten die Gebots- und Auktionsdienste (B&A) proposal

Wenn Display- & In Video 360 kann die Protected Audience API mit B&A getestet werden. werden wir uns mit weiteren Details bei Ihnen melden.

OpenRTB-Protokoll

Gebotsanfrage

Um zwischen Optimierungsmöglichkeiten für Impressionen zu unterscheiden, die den geschützten Modus On-Device-Auktionen über die Audience API von Anbietern, die nur standardmäßige serverseitigen Exchange-Auktion ein neues Enum-Feld namens ae für „Auktion“ Umgebung“ als Erweiterung für das Imp-Objekt in OpenRTB hinzugefügt werden. Gebotsanfrage, mit der angegeben wird, welche Auktionsumgebung vom angegebenen Impressionsfläche. Die Aufzählung ae kann die folgenden Werte haben:

  • 0: Serverseitige Standardauktionen
  • 1: Anfragen mit Unterstützung der Protected Audience API, bei der ein kontextbezogener auf den Servern der Anzeigenplattform ausgeführt wird und die Interessengruppen bieten wird die letzte Auktion im Browser
{
  "id": …
  "imp": [{
    "id": "1"
    "video": {...}
    "ext": {
      "ae": 1
    }]
}

Gebotsantwort

Neben den kontextbezogenen Geboten wird auch eine Gebotsantwort verwendet, um relevante Informationen für Display- und Teilnahme von Video 360 und Google Ads am Protected Audience API-Interessengruppenauktionen. Die Gebotsantwort wird in wie folgt die Interessengruppenauktionen unterstützen:

{
  "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
      }]
    }]
  }
}

Die folgenden Szenarien werden unterstützt.

  • SZENARIO 1: Display- und Video 360 und Google Ads möchten nur teilnehmen, in einer kontextbezogenen Auktion. In diesem Szenario ist kein igbid-Feld vorhanden.

  • SZENARIO 2: Display- und Video 360 und Google Ads möchten nur teilnehmen, an einer Interessengruppenauktion teilnehmen. In diesem Szenario Display- und Video 360 und wird das Feld „sadbid“ in der Gebotsantwort verworfen igbid-Informationen zurückgeben. Mit anderen Worten: Das Vorhandensein eines igbid-Felds die Tatsache, dass Display- und Die Interessengruppen in Video 360 und Google Ads sollen um an der On-Device-Auktion teilzunehmen.

  • SZENARIO 3: Display- und Video 360 und Google Ads möchten an kontext- und interessengruppenbezogenen Auktionen. In diesem Szenario Display- und Video 360 und Google Ads geben beide „seatbid“-Felder in der Gebotsantwort zurück und Igbid-Informationen.

Metadaten mit Anzeigengebot

Die Protected Audience API ermöglicht passing arbitrary metadata über die Anzeige aus der generateBid()-Funktion.

Display- und Für Video 360 sind folgende Maßnahmen geplant: specification für die Anzeigenmetadaten: Protected Audience API und OpenRTB.

nämlich Display- und In Video 360 werden die folgenden Felder als Teil der Anzeige zurückgegeben. -Objekt enthält:

PA-Attribut Typ OpenRTB-Beschreibung
ad.seat String; erforderlich ID des Käuferkontos (z.B. Werbetreibender oder Agentur), in dessen Namen dieses Gebot abgegeben wird.
ad.adomain String[] Domain des Werbetreibenden zur Überprüfung der Blockierungsliste (z.B. „ford.com“). Im Fall der Creative-Rotation kann dies ein Array von sein. Auf Anzeigenplattformen kann festgelegt werden, dass nur eine Domain zulässig ist.
ad.cid String Kampagnen-ID zur Unterstützung bei der Überprüfung der Anzeigenqualität.
ad.crid String Creative-ID zur Unterstützung bei der Überprüfung der Anzeigenqualität.
ad.language String Sprache des Creatives gemäß ISO-639-1-alpha-2. Der nicht standardmäßige Code „xx“ kann auch verwendet werden, wenn das Creative keinen linguistischen Inhalt hat (z.B. ein Banner mit nur einem Firmenlogo). Es sollte nur entweder eine Sprache oder eine Sprache vorhanden sein.
ad.w Ganzzahl Breite des Creatives in geräteunabhängigen Pixeln (DIPS)
ad.h Ganzzahl Höhe des Creatives in geräteunabhängigen Pixeln (DIPS)

Beispiel

{
  "seat": "123"
  "adomain": ["example.com"]
  "cid": "12345"
  "crid": "12345"
  "language": "en"
  "w": 300
  "h": 250
}

Ereignisberichte

Die Protected Audience API bietet eine API für Berichte auf Ereignisebene, die in diesem GitHub-Beitrag: Fenced Frame Ads Reporting. Auch wenn der Name „Fenced Frame Ads Reporting“ lautet, ist die API in Fenced Frames und iFrames (siehe Details) here)

So kann eine SSP eine URL beim Browser in der Funktion reportResult registrieren: registerAdBeacon() wird angerufen der API erstellen.

Display- und Video 360 ruft reportEvent() auf API mit dem Ziel „component-seller“ aus dem Creative aus, um Impressionen und Klickereignisse. In diesem Fall wird ein Beacon an das registrierte URL

Beachten Sie, dass Display- und Video 360 ruft die reportEvent() API für Impressionen und Klicks mit leeren Beitragsdaten.

Beispiel

registerAdBeacon({
 'impression': 'https://ssp.example/impression?ssp_event_id=abc',
});
registerAdBeacon({
 'click': 'https://ssp.example/click?ssp_event_id=abc',
});

Display- und Video 360 wird an Chrome-facilitated testing von Einstellung von Drittanbieter-Cookies. Um die Tests durchführen zu können, bitten wir Partner, Chrome-Labels in der OpenRTB-Gebotsanfrage wie folgt übergeben: specification:

Objekt: Device.ext

Attribut Typ Beschreibung
CDEp String das Label, das von Chrome oder einem vorgelagerten Partner empfangen wurde.