Protected Audience API (früher FLEDGE)

Im Rahmen der Privacy Sandbox wurde die Protected Audience API vorgeschlagen, eine browserinterne API, mit der Werbetreibende und Anzeigentechnologie-Unternehmen auf Interessengruppen ausgerichtete Anzeigen schalten können, ohne Drittanbieter-Cookies zu verwenden, und gleichzeitig Nutzer vor websiteübergreifendem Tracking schützen.

Chrome führt gerade einen Ursprungstest für die Protected Audience API aus. Authorized Buyers kann an Tests der Protected Audience API in Ad Manager-Publisher-Inventar teilnehmen. Bieter können Folgendes erreichen, wenn sie die Protected Audience API testen:

  • Testen Sie die Protected Audience API-Abläufe und informieren Sie sich über die Wirksamkeit.
  • In öffentlichen Foren wie GitHub können Sie Feedback zu möglichen Verbesserungen der API geben.
  • Bereiten Sie sich auf die Unterstützung von personalisierter Werbung über die API vor, ohne auf Drittanbieter-Cookies zurückgreifen zu müssen.

Für Authorized Buyers, die an Tests interessiert sind, finden Sie weitere Informationen im Bereich zur Einrichtung.

Zusammenfassung des Bereitstellungsablaufs

Hier eine Zusammenfassung des Ablaufs der Protected Audience-Anzeigenbereitstellung für Authorized Buyers-Partner:

Flussdiagramm

  1. Eine Gebotsfunktion arbeitet mit ihren Werbetreibenden zusammen, um die Interessengruppen für jeden Werbetreibenden zu verwalten. Häufig fügen Werbetreibende das Tag eines Bieters auf der Seite des Werbetreibenden ein, um einen Browser zu Interessengruppen hinzuzufügen.
  2. Ein Endnutzer besucht die Seite eines Werbetreibenden. Die Seite enthält möglicherweise das Tag des Bieters.
  3. Das Tag des Bieters ruft die joinAdInterestGroup() der Protected Audience API auf. Bei diesem Aufruf wird der Browser aufgefordert, den Nutzer einer Interessengruppe hinzuzufügen.
  4. Der Endnutzer besucht die Webseite eines Publishers. Der Browser des Nutzers fordert das Publisher-Anzeigen-Tag von Google an.
  5. Das Publisher-Anzeigen-Tag von Google sendet eine kontextbezogene Anzeigenanfrage an einen Google-Server.
  6. Google sendet kontextbezogene Gebotsanfragen an die teilnehmenden Bieter. Weitere Informationen finden Sie im Abschnitt Änderungen bei Gebotsanfragen.
  7. Der Bieter gibt ein BidResponse mit dem Feld interest_group_bidding zurück. Wenn der Bieter interest_group_bidding nicht angibt, nimmt Google den Ursprung des Bieters nicht in interestGroupBuyers der Auktionskonfiguration auf. Die Gebotsantwort kann auch interest_group_bidding.per_buyer_signals enthalten. per_buyer_signals wird während der Auktion im Browser an die Gebotsfunktion des Bieters übergeben. Weitere Informationen finden Sie im Abschnitt Änderungen der Gebotsantwort.
  8. Google führt die serverseitige Auktion durch und gibt eine Gebotsantwort an den Browser zurück. Bei serverseitigen Auktionen werden herkömmliche, serverseitige Gebote berücksichtigt. Die Gebotsantwort kann Informationen zu einem kontextbezogenen erfolgreichen Gebot (falls vorhanden) enthalten.
  9. Die Gebotsantwort enthält eine Auktionskonfiguration für die Auktion im Browser. Dazu können Kontextsignale von jedem teilnehmenden Käufer (die über interest_group_bidding.per_buyer_signals gesendet wurden), kontextbezogene Informationen zum Gewinner und Einstellungen für die Berechtigung zur Gebotsabgabe umfassen.
  10. Das Publisher-Tag von Google ruft die Protected Audience API runAdAuction() auf, um die On-Device-Interessengruppenauktion zu initiieren. Google nimmt nur Käufer auf, die zuvor interest_group_bidding als interestGroupBuyers in der Auktionskonfiguration zurückgegeben haben.
  11. Google übergibt die per_buyer_signals jedes infrage kommenden Bieters an die Auktionskonfiguration der Protected Audience.
  12. Wenn für die Interessengruppen eines bestimmten Bieters trustedBiddingSignalsUrl angegeben wurde, sendet der Browser eine Anfrage an das trustedBiddingSignalsUrl jeder Gruppe, um Echtzeitsignale für jede Gruppe abzurufen. Weitere Informationen finden Sie in der Spezifikation der Protected Audience API.
  13. Der Browser ruft generateBid() des Bieters für jede Interessengruppe auf, die zugestimmt hat und an der Auktion im Browser teilnehmen kann. In diesem Schritt wird das Gebot berechnet und ein Creative ausgewählt. generateBid() hat Zugriff auf die vom Bieter bereitgestellten per_buyer_signals und die vertrauenswürdigen Gebotssignale für die jeweilige Interessengruppe.
  14. Der Browser ruft scoreAd() des Verkäufers (in diesem Fall von Google) auf, um jedem Gebot in der auf einer Interessengruppe basierenden Anzeigenauktion einen Rang zuzuweisen. Gebote werden basierend auf den Schutzmaßnahmen des Publishers, den Werberichtlinien und anderen Einschränkungen eingestuft und gefiltert.
  15. Der Browser führt eine Auktion mit den geeigneten Geboten für Interessengruppen durch. Das kontextbezogene Gebot mit dem höchsten Rang nimmt an der Auktion im Browser teil.
  16. Wenn nach der Auktion ein Interessengruppengewinner ermittelt wird, ruft der Browser die reportResult() des Verkäufers und die reportWin() des Bieters auf, um alle Parteien über den Gewinner der Auktion im Browser zu informieren.
  17. Wenn eine auf einer Interessengruppe basierende Anzeige erfolgreich ist, wird die Anzeige durch das Publisher-Tag von Google in einem iFrame gerendert.

Details zum Bereitstellungsablauf

Vor der Anzeigenbereitstellung

Creative-Überprüfung

Creatives müssen von Google geprüft und genehmigt werden, bevor sie über Protected Audience-Auktionen in Browsern ausgeliefert werden können. Sie können Creatives über die Real-time Bidding API oder die automatische Creative-Überprüfung zur Überprüfung einreichen. Creatives für in-Browser-Anzeigenauktionen auf Interessengruppen von Protected Audiencen müssen renderUrls für die Überprüfung enthalten.

Anforderungen für renderUrls:

  • Der über die API eingereichte renderUrl muss mit dem renderUrl übereinstimmen, der in der auf einer Interessengruppe basierenden Anzeigenauktion verwendet wird.
  • Jedes renderUrl-Element darf nur einen einzelnen Werbetreibenden oder eine einzelne Werbekampagne repräsentieren. Ein(e) renderUrl kann nicht verwendet werden, um Anzeigen im Namen mehrerer Werbetreibender zu rendern. Jedes renderUrl-Element muss genau einem Creative zugeordnet sein.
  • Die renderUrl muss bis zu 7 Tage nach dem letzten Gebot für die Anzeige zugänglich sein und über die Offline-Creative-Überprüfungssysteme von Google abgerufen werden können.
Real-time Bidding API

Bieter können die Real-Time Bidding API verwenden, um Creatives für Gebote auf Interessengruppen hochzuladen.

Automatische Creative-Überprüfung

Bieter können die automatische Creative-Überprüfung für Creatives einrichten, die nicht über die Real-time Bidding API hochgeladen werden.

Wenn Sie die automatische Creative-Überprüfung einrichten, findet Google Creatives in der Auktion im Browser und scannt sie automatisch, damit sie für zukünftige Auktionen infrage kommen.

So aktivieren Sie das automatische Scannen von Creatives:

  • Fügen Sie dem Authorized Buyers-Konto alle renderUrl-Ursprünge des auf einer Interessengruppe basierenden Creatives hinzu.

  • Fügen Sie der HTTP-Antwort des Creatives die folgenden benutzerdefinierten HTTP-Header hinzu:

    Authorized-Buyers-Creative-ID

    String

    Käuferspezifische Creative-ID. Die maximale Länge der Creative-ID beträgt 128 Byte.
    Authorized-Buyers-Click-Through-URLs

    String

    Die deklarierten Ziel-URLs für das Creative, die gemäß RFC2396 codiert sind.

Beispiel:

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>
Creative-Ablauf

Die Creatives bleiben 15 Tage lang freigegeben. Wenn Sie Creatives über die Real-time Bidding API senden, müssen Sie sie nach 15 Tagen noch einmal einreichen. Wenn Sie auf das automatische Scannen von Creatives angewiesen sind, werden sie während des Scanvorgangs automatisch noch einmal gescannt.

Käuferberichts-ID

Sie können Berichtsmesswerte wie Impressionen mithilfe von Dimensionen aufschlüsseln, die vom Käufer bereitgestellt werden (z. B. Kampagnen-ID oder Werbetreibenden-ID). Wenn Sie eine Dimension für die Ausgaben einer Interessengruppe hinzufügen möchten, geben Sie eine buyerAndSellerReportingId für Ihre Anzeige an, wenn Sie das Gerät des Nutzers der Interessengruppe hinzufügen. Weitere Informationen finden Sie in der Protected Audience-Dokumentation.

Das folgende Beispiel zeigt, wie Sie buyerAndSellerReportingId in die Interessengruppenkonfiguration aufnehmen können:

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

Die buyer_reporting_id wird im Berichterstellungstool von Authorized Buyers als neue Dimension als Dimension „Berichts-ID des Käufers“ angezeigt.

Serverseitige Auktion

Änderungen an Gebotsanfragen

Im Folgenden finden Sie frühe Versionen der unterstützten Protokolle, die im Experiment verwendet werden können:

Unterstützung bei der Auktion von Interessengruppen angeben

Gebotsanfragen haben das neue Feld auction_environment.

  • RTB-Protokoll von Google: BidRequest.adslot.auction_environment
  • OpenRTB: BidRequest.imp.ext.auction_environment

Mithilfe dieses Felds können Sie zwischen Impressionsmöglichkeiten unterscheiden, die die Protected Audience-Auktion im Browser auf Interessengruppen unterstützen, und solchen, die nur die herkömmliche serverseitige Auktionsauktion unterstützen. Die Aufzählung auction_environment kann folgende Werte haben:

  • SERVER_SIDE_AUCTION (OpenRTB-JSON: 0): Herkömmliche serverseitige Auktionen
  • ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB-JSON: 1): Anfragen mit Protected Audience-Unterstützung, bei denen eine kontextbezogene Auktion auf den Servern der Anzeigenplattform und die auf einer Interessengruppe basierenden Gebote sowie die abschließende Auktion im Browser ausgeführt werden.
Größe der Protected Audience-Anzeigenfläche angeben

Die Gebotsanfrage enthält die folgenden Felder, um Ihnen die Größe der Anzeigenfläche für die Protected Audience API anzugeben:

  • RTB-Protokoll von Google:
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height
  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height

Diese Felder geben die Größe der Anzeigenfläche für die Protected Audience-Auktion in Pixeln an.

Diese Größe kann von den Größen für die kontextbezogene Anfrage (Adslot.width und Adslot.height oder in OpenRTB: BidRequest.imp.banner.format) abweichen.

Die kontextbezogene Anfrage kann mehrere Größen haben. Die bei einer Auktion gewonnene On-Device-Anzeige füllt voraussichtlich nur eine einzige feste Anzeigenfläche.

Renderbarkeit von Protected Audience-Anzeigen angeben

Protected Audience-Anzeigen können je nach aktueller Integrationsphase gerendert werden (siehe Test ohne Rendering). Mit dem Feld render_interest_group_ads in der Gebotsanfrage wird angegeben, ob die erfolgreiche Protected Audience-Anzeige gerendert wird.

  • RTB-Protokoll von Google: BidRequest.adslot.interest_group_auction.render_interest_group_ads
  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
Nutzung von Nutzerkennungen minimieren

Kontextbezogene Gebotsanfragen, die für Protected Audience API-Tests infrage kommen, können weiterhin herkömmliche cookiebasierte Kennungen enthalten, sofern diese im Browser verfügbar sind, z. B. die Felder google_user_id (BidRequest.user.id in OpenRTB) und hosted_match_data (BidRequest.user.buyerid in OpenRTB). Für das Vorhandensein solcher Kennungen in Gebotsanfragen gelten weiterhin die bestehenden Datenschutzerklärungen. Wir empfehlen Ihnen, sich beim Targeting und bei der Gebotsabgabe nicht auf cookiebasierte Kennungen zu verlassen. So können Sie sich auf einen effizienten Kauf vorbereiten, wenn keine Drittanbieter-Cookies mehr verfügbar sind.

Google kann auch kleine Tests durchführen, bei denen cookiebasierte Kennungen aus Gebotsanfragen im Rahmen von Protected Audience API-Tests entfernt werden. So lassen sich die möglichen Auswirkungen der Einstellung von Drittanbieter-Cookies beurteilen.

Zur Vorbereitung auf die Einstellung von Drittanbieter-Cookies (3PCD) im Jahr 2024 bietet Chrome jetzt von Chrome unterstützte Tests.

Websites und Anbieter können von Chrome unterstützte Tests verwenden, um ihre Systeme unter 3PCD zu testen. Im Test werden Chrome-Browser einer 3PCD-Testgruppe zugewiesen, entweder Modus A oder Modus B. Jedem Browser wird ein einheitliches Label zugewiesen, das einer bestimmten 3PCD-Testgruppe entspricht, auf die Sie über die Chrome API im Browser zugreifen können.

Google übergibt das unveränderte Label aus der Chrome API in der RTB-Gebotsanfrage. Aufgrund der kleinen Traffic-Slices eines einzelnen Labels nimmt Google das Label in datenschutzkonformen Kontexten nicht immer auf.

In den folgenden Feldern wird das Label angezeigt:

  • RTB-Protokoll von Google: BidRequest.device.cookie_deprecation_label
  • OpenRTB: BidRequest.device.ext.cdep

Änderungen der Gebotsantwort

Teilnahme an der Auktion einer Interessengruppe angeben

Es liegt in Ihrer Verantwortung, explizit Ihre Teilnahme an der Browserauktion anzugeben, indem Sie das Objekt InterestGroupBidding in der kontextbezogenen Gebotsantwort zurückgeben:

  • RTB-Protokoll von Google: BidResponse.interest_group_bidding
  • OpenRTB: BidResponse.ext.igbid

Sie müssen eine kontextbezogene Gebotsantwort bereitstellen. Die Antwort muss kein kontextbezogenes Gebot enthalten. Das InterestGroupBidding-Objekt sollte den origin des Interessengruppeninhabers enthalten, der mit einem der Ursprünge übereinstimmen sollte, die vom Bieter für sein Konto konfiguriert wurden. Das origin wird dem interestGroupBuyers der Auktionskonfiguration hinzugefügt, wenn über das Google Publisher-Tag runAdAuction() aufgerufen wird.

Kontextsignale von Käufern weitergeben (proKäufersignal)

Sie können die Signale eines Käufers in die kontextbezogene Gebotsantwort einbeziehen, die Google mit dem Argument perBuyerSignals als JSON-Objekt an die Gebotsfunktion auf dem Gerät weitergibt. Diese kann je nach Protokoll mit den folgenden Feldern in die Gebotsantwort aufgenommen werden:

  • RTB-Konto von Google: BidResponse.interest_group_bidding.per_buyer_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
Maximalen Preis für Gebote im Browser angeben

Im Protected Audience-Angebot wird erwartet, dass die Gebotsberechnung und die endgültige Auktion lokal auf dem Gerät ausgeführt werden. Dies kann zu potenziellen Missbrauchsvektoren führen, die die Integrität der endgültigen Auktionsergebnisse beeinträchtigen können, z. B. den Preis des erfolgreichen Gebots.

Als Abhilfe, die während der Protected Audience API-Tests durch Google für seine RTB-Partner unterstützt wird, können Sie in jeder kontextbezogenen Gebotsantwort einen erwarteten Höchstgebotswert angeben. Das erwartete Höchstgebot ist der Höchstgebot, den Ihre Gebotsfunktion voraussichtlich zurückgibt. Wenn das erfolgreiche Gebot aus der Browserauktion diesen Betrag überschreitet, wird das erfolgreiche Gebot nicht als abrechenbares Ereignis gezählt. Dieser Ansatz kann sich ändern.

In der Gebotsantwort können Sie das erwartete Höchstgebot in die folgenden Felder eingeben:

  • RTB-Protokoll von Google: BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (ausgedrückt in Mikro-CPM)
  • OpenRTB: BidResponse.igbid.igbuyer.maxbid(ausgedrückt in CPM-Währungseinheiten)
Impressionen mehreren Konten zuordnen

Ein Bieter muss mithilfe der folgenden Felder eine Abrechnungs-ID auswählen, um die Impressionen seines Interessengruppengebots zuzuordnen:

  • RTB-Protokoll von Google: BidResponse.interest_group_bidding.interest_group_buyers.billing_id
  • OpenRTB: BidResponse.igbid.igbuyer.billing_id

Die ausgewählte Abrechnungs-ID muss eine gültige Abrechnungs-ID aus der Gebotsanfrage sein:

  • RTB-Protokoll von Google: BidRequest.adslot.matching_ad_data.billing_id
  • OpenRTB: BidRequest.imp.ext.billing_id

Wenn die Abrechnungs-ID, der Impressionen von Interessengruppen zugeordnet werden soll, nicht angegeben ist, nimmt der Bieter nicht an der Protected Audience-Auktion teil.

Untergeordnete Konten können bis zu zwei Abrechnungs-IDs haben. Der Käufer kann eine Abrechnungs-ID für kontextbezogene Ausgaben und die andere für Ausgaben für Interessengruppen verwenden. Wenden Sie sich an Ihren Account Manager, wenn Sie zwei Abrechnungs-IDs für ein untergeordnetes Konto konfigurieren möchten.

Sie können für jede Abrechnungs-ID ein Tagesbudget festlegen. Wenden Sie sich an Ihren Account Manager, um das Tagesbudget für die Abrechnungs-IDs der untergeordneten Konten festzulegen.

Die Abrechnungs-IDs aller untergeordneten Konten mit verfügbarem Budget, das auf die Impression bieten kann, erscheinen in der Gebotsanfrage zur Auswahl der Attribution der Ausgaben. Bitten Sie Ihren Account Manager, das Budget für die Abrechnungs-ID einer Interessengruppe zu ändern.

Während der Auktion im Browser

Browserinterne Gebote generieren

Verwenden Sie generateBid(), um Gebote im Browser zu generieren.

Google stellt die folgenden Parameter bereit:

  • auctionSignals: leer
  • perBuyerSignals: ein JavaScript-Objekt mit denselben Signalen, die vom Bieter in der kontextbezogenen Antwort bereitgestellt werden

Folgende Parameter werden zurückgegeben:

  • ad: Dieses Feld wird von Google ignoriert.
  • bid: Ein numerisches Gebot, das an der Auktion teilnimmt. Muss in CPM-Einheiten (nicht Mikroeinheiten) angegeben werden.
  • render: Die URL, die gerendert wird, um das Creative einzublenden, wenn das Gebot die Auktion gewinnt. Google muss diese URL prüfen und freigeben. Andernfalls wird sie aus der Auktion herausgefiltert.
  • allowComponentAuction: Muss true sein. Google unterstützt derzeit das Testen von Auktionen mit mehreren Verkäufern.

Beispiel:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

Im Abschnitt zu On-Device-Geboten in den Spezifikationen der Protected Audience API finden Sie eine Erläuterung der Funktion generateBid().

Gebotswährung

Auktionsgebote im Browser werden in CPM-Einheiten der ausgewählten Gebotswährung platziert.

Die Gebotswährung muss sowohl in der kontextbezogenen Gebotsantwort als auch im Rückgabewert von generateBid angegeben werden und ein gültiger Alpha-Code gemäß ISO 4217 sein, z. B. „USD“, „EUR“ oder „JPY“.

Verwenden Sie in OpenRTB das neue Feld cur im Objekt InterestGroupBuyer in der Gebotsantworterweiterung von Google.

Beispiel:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

Verwenden Sie im RTB-Protokoll von Google das neue Feld currency in der Nachricht InterestGroupBuyer der Gebotsantwort.

Beispiel:

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

Die generateBid-Funktionen von Bietern müssen Gebote in derselben Währung zurückgeben, die in der kontextbezogenen Gebotsantwort angegeben ist. Geben Sie das neue Attribut bidCurrency in den Rückgabewert von generateBid ein:

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

Wenn sich die Währung aus der kontextbezogenen Gebotsantwort von der von generateBid zurückgegebenen Währung unterscheidet oder eine von beiden eine ungültige Währung zurückgibt, wird das Gebot vor der Auktion herausgefiltert.

Anzeigenqualitätsprüfungen

Die Erzwingung von Creative-Richtlinien und Publisher-Einstellungen kann für Gebote auf Interessengruppen im Browser während der Protected Audience API-Tests für RTB-Partner restriktiver sein.

Unterstützung durch das Gesetz über digitale Dienste

Aufgrund von Artikel 26 des Gesetzes über digitale Dienste können Publisher von Käufern verlangen, Offenlegungen in Anzeigentransparenz zu rendern. Wenn ein Publisher die Option „Käufer auffordern, nur Anzeigen mit DSA-Transparenz auf meiner Website oder in meiner App im EWR zu zeigen“ aktiviert, können Käufer auf Interessengruppen bestimmen, für welche Möglichkeiten sie Käufertransparenz generieren müssen, indem sie die folgenden Felder in eingehenden Gebotsanfragen angeben: BidRequest.dsa.dsa_support und BidRequest.dsa.publisher_rendering_support für das Google Authorized Buyers-Protokoll sowie BidRequest.regs.dsa.required und BidRequest.dsa.pubrender für das OpenRTB-Protokoll.

Wenn ein Bieter, der an Protected Audience API-Auktionen teilnehmen möchte, in der Gebotsanfrage das Signal erhält, dass für Anzeigen, die über die Protected Audience API ausgeliefert werden, Transparenz in DSA angezeigt werden muss, sollte er prüfen, ob er die erforderlichen Informationen angemessen anzeigen und das Protokoll durch BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render für das Google Authorized Buyers-Protokoll oder BidResponse.ext.igbid.igbuyer.dsaadrenderfür das OpenRTB-Protokoll angeben kann. Andernfalls nimmt der Käufer nicht an der Protected Audience API-Auktion teil.

Weitere Informationen zur Anzeigentransparenz im Rahmen des Gesetzes über digitale Dienste finden Sie in diesem Hilfeartikel.

Gebotsfilterung

Google erzwingt Richtlinien für Publisher und Anzeigenrichtlinien während der On-Device-Auktion.

Nach Auktion im Browser

Auktionsergebnis an Käufer melden: reportWin()

Die folgenden Argumente werden von Google nicht ausgefüllt:

  • auctionSignals
  • sellerSignals

Verwenden Sie reportWin(), um dem Käufer das Auktionsergebnis zu melden.

Weitere Informationen finden Sie in der Erläuterung der Protected Audience API im Abschnitt Käuferberichte zu Renderings und Anzeigenereignissen.

Makros

Die renderUrl, die auf das Protected Audience API-Creative verweist, kann einen oder mehrere Platzhalter enthalten, die sogenannten Makros. Nach Abschluss der Interessengruppenauktion, aber vor dem Rendern, werden die Makros durch die entsprechenden Werte ersetzt. renderUrl, der in der On-Device-Auktion verwendet wird, kann die folgenden Makros enthalten:

${GDPR} Wird in 0 erweitert, wenn die DSGVO nicht angewendet wird, oder 1, wenn die DSGVO gilt. Dokumentation ansehen
${GDPR_CONSENT_XXXX} Wird in den Transparency & Consent (TC)-String erweitert, der der Anfrage zugeordnet ist. Wenn der Transparency & Consent (TC)-String leer oder ungültig ist, wird das Makro nicht erweitert.

Verwenden Sie dieses Makro, um den TC-String in einer URL an einen IAB-GVL-registrierten Anbieter zu übergeben. Ersetzen Sie XXXX durch die IAB-GVL-ID des IAB-GVL-registrierten Anbieters. Wenn der TC-String leer oder ungültig ist, wird das Makro nicht erweitert.

Creatives mit dem ${GDPR_CONSENT_XXXX}-Makro können blockiert werden, wenn der GVL-registrierte Anbieter des IAB, der mit der eingefügten IAB-GVL-ID verknüpft ist, keine Nutzereinwilligung hat.

Das Makro ${GDPR_CONSENT_XXXX} darf nur einmal innerhalb von renderUrl vorkommen.
${ADDL_CONSENT} Das Makro wird in den String für zusätzliche Einwilligung erweitert, der der Anfrage zugeordnet ist.
${AD_WIDTH}, ${AD_HEIGHT) Mit diesen Makros werden Breite und Höhe der Anzeigenfläche eingefügt.

Anzahl an Impressionen

Während der Protected Audience API-Tests mit RTB-Partnern zählt Google Impressionen, wenn der Browser die Funktion reportResult() aufruft. Anschließend ruft Google die Berichts-URL von Google in einem Aufruf von sendReportTo() ab.

Da Google zum Zählen von Impressionen in Protected Audience-Auktionen im Browser ein anderes Ereignis verwendet als das Ereignis, das von den RTB-Käuferpartnern zum Zählen von Impressionen verwendet wird, kann die Anzahl der Impressionen abweichen.

Eines der Ziele von Google beim Testen der Protected Audience API besteht darin, diese Abweichungen zu erkennen und zu reduzieren.

Attribution von abrechenbaren Impressionen

Alle Ausgaben eines Bieters aus Protected Audience-Auktionen im Browser werden anhand der Zuordnung der für den Bieter konfigurierten Ursprünge des Inhabers der Interessengruppe einem einzelnen Bieterkonto zugeordnet. Ausgaben verschiedenen untergeordneten Kontokonten eines Bieters können nicht zugeordnet werden.

Tägliche Budgetobergrenze

Während der Protected Audience API-Tests hat jedes Konto eine tägliche Budgetobergrenze für die Protected Audience-Ausgaben auf Kontoebene. Diese beschränkt das Risiko in der Auktionsumgebung im Browser. Sobald die tägliche Budgetobergrenze erreicht ist, erhält das Konto keine Gebotsanfragen mehr, die für Protected Audience infrage kommen.

Das Konto kann weiterhin an serverseitigen kontextbezogenen Auktionen teilnehmen, nachdem die Protected Audience-Obergrenze erreicht wurde. Beispielsweise kann ein Bieterkonto, das die Obergrenze der Protected Audience-Zielgruppe erreicht, eine Gebotsanfrage mit auction_environment = SERVER_SIDE_AUCTION (OpenRTB: 0) erhalten, auch wenn die Gebotsanfrage für eine Protected Audience-Auktion infrage kommt.

Echtzeit-Feedback und Mindestgebot, um zu gewinnen

Bieter, die Feedback in Echtzeit erhalten, erhalten Feedback zu Interessengruppenkäufern, die in eine Protected Audience-Auktion auf dem Gerät aufgenommen werden möchten. Jeder Käufer einer Interessengruppe, den ein Bieter in einer Gebotsantwort angibt, erhält ein Feedbackobjekt, unabhängig davon, wie viele Gebote der Interessengruppenkäufer in der Protected Audience-Auktion abgibt. Die folgenden Informationen sind für das Objekt "Käufer-Feedback-Objekt für Interessengruppen" verfügbar:

  • Der Feedbacktyp des Feedbackobjekts ist INTEREST_GROUP_BUYER_FEEDBACK.
  • Der Ursprung des auf einer Interessengruppe basierenden Käufers.
  • Das Mindestgebot, das für den Käufer der Interessengruppe gewinnen muss, damit er die Gesamtauktion gewinnt.
  • Das Mindestgebot, das für den Käufer der Interessengruppe gewinnen muss, um das Gebot mit dem höchsten Rang von der serverseitigen Komponente der Gesamtauktion zu übertreffen.
  • Der Statuscode des Interessengruppenkäufers. Mögliche Statuscodes werden in der Datei interest-group-buyer-status-codes.txt definiert.

Die spezifischen Feldnamen finden Sie in der Protokolldokumentation zur RTB-Funktion in Authorized Buyers und in den OpenRTB-Erweiterungen.

Benachrichtigung zu Gebotsfeedback

Chrome bietet eine temporäre Debugging API für die Protected Audience API, mit der Ad Manager Server-zu-Server-Debug-Benachrichtigungen in Echtzeit senden kann, die Feedback zu einem Protected Audience-Gebot enthalten. In dieser Benachrichtigung werden Gründe aufgeführt, warum Gebote in der Protected Audience-Auktion im Browser herausgefiltert wurden. Außerdem finden Sie weitere Informationen zu einem Gebot, das unten beschrieben wird.

Bieter können ihren Account Manager bitten, eine statische URL zu konfigurieren, die zum Senden von Benachrichtigungen zu Gebotsfeedback in Protected Audience-Debugging verwendet wird. Diese statische URL wird von Google-Servern abgerufen und ausgewählte Makros werden nach Abschluss der Protected Audience-Auktion ersetzt. Folgende Makros werden unterstützt:

  • %%GOOGLE_QUERY_ID%%: Dieses Makro wird durch die Google-Abfrage-ID (BidRequest.google_query_id im Authorized Buyers-Protokoll und BidRequest.ext.google_query_id im OpenRTB-Protokoll) ersetzt, die in der kontextbezogenen Gebotsanfrage für Protected Audience gesendet wurde.
  • %%INTEREST_GROUP_OWNER%%: Der Ursprung des Inhabers der Interessengruppe.
  • %%BID_CPM%%: Der Gebotspreis in CPM, der vom Käufer in der Funktion generateBid() angegeben wurde.
  • %%RENDER_URL%%: Das ist die Rendering-URL des Creatives.
  • %%STATUS%%: Ein Statuscode, wenn das Gebot innerhalb von scoreAd() abgelehnt wurde. Werte sind Creative-Statuscodes.

Hier ist ein Beispiel für eine statische URL, die ein Bieter seinem Account Manager zur Verfügung stellen könnte:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

Die Benachrichtigung bei Gebotsfeedback ist eine vorübergehende Funktion, die von der temporären ForDebuggingOnly API von Chrome abhängig ist.

Klickereignissen

Bieter können Klickereignisse für Protected Audience-Anzeigen über die Fenced Frame Reporting API an Google melden. Bieter sollten den Ereignistyp click verwenden, um Google über Klicks zu informieren. Hier ein Beispiel:

window.fence.reportEvent({
    'eventType': 'click',
    // Google does not require bidders to send data to Google in 'eventData'.
    // However, 'eventData' must be a non-null value, such as an empty string.
    'eventData': '',
    'destinations': ['direct-seller']
});

TURTLEDOVE auf Produktebene

Anzeigen in mehreren Teilen oder TURTLEDOVE auf Produktebene (PLTD) werden Google-RTB-Partnern beim Protected Audience API-Test unterstützt. Teilen Sie Ihrem Account Manager während der Integration mit, wenn Sie PLTD testen möchten, da zusätzliche Ressourcen und Konfigurationen erforderlich sind.

Onboarding

So testen Sie die Protected Audience API:

Schritte

  1. Füllen Sie das Anfrageformular aus, um am Protected Audience API-Test teilzunehmen.
  2. Nachdem Sie das Antragsformular gesendet haben, wenden Sie sich an Ihren Account Manager oder reichen Sie über die Authorized Buyers-Hilfe ein Ticket ein.
  3. Sobald das Konto konfiguriert ist, können sowohl Google als auch der Partner die Einbindung mithilfe der Schritte in den Testphasen überprüfen.

Creative-Überprüfung

Damit Sie in Protected Audience API-Auktionen mit Anzeigen auf Produktebene (aus mehreren Teilen bestehende Anzeigen) bieten können, müssen Sie die folgenden Anforderungen erfüllen:

  • Fügen Sie den &pltd=True-Abfrageparameter in die renderUrl für den Container der Komponentenanzeige (auch als renderUrl der obersten Ebene bezeichnet) ein, um bei der Creative-Überprüfung die renderUrls der obersten Ebene zu unterscheiden.
  • Sie können ein repräsentatives Creative rendern, wenn der Container der Komponentenanzeige von Google zur Creative-Überprüfung abgerufen wird. Wenn Sie wissen möchten, wann ein repräsentatives Anzeigen-Rendering zurückgegeben werden sollte, können Sie sich den validation=True-Abfrageparameter ansehen, der vom Google-System für die Creative-Überprüfung festgelegt wurde.

Checkliste für die Integration

  • Richten Sie einen Endpunkt für Gebotsanfragen ein, damit in der kontextbezogenen Gebotsantwort Felder für die Protected Audience API ausgefüllt werden, z. B. interest_group_bidding.
  • Implementieren Sie das Tagging auf den Seiten des Werbetreibenden, um den Browser des Nutzers der Interessengruppe zuzuordnen.
  • Implementieren Sie generateBid() und reportWin().
  • Wählen Sie die Ursprünge der Interessengruppeninhaber aus und fügen Sie sie dem Authorized Buyers-Konto hinzu.
    • Die Quellen von Inhabern von Interessengruppen müssen mit den Ursprüngen übereinstimmen, in denen die generateBid()-Funktionen gehostet werden.
    • Wenden Sie sich dazu an den Account Manager oder reichen Sie über die Authorized Buyers-Hilfe ein Ticket ein.
  • Richten Sie Pre-Targeting für Inventar ein, das für Protected Audience API-Tests relevant ist.
  • Reichen Sie Creatives über die Creatives API zur Überprüfung und Freigabe ein.
  • Optional: Richten Sie die Endpunkte für vertrauenswürdige Gebotssignale ein.
  • (Optional) Richten Sie eine Testseite für Werbetreibende ein, auf der Google-Entwickler ihren Browser den Interessengruppen hinzufügen können, die dem Ursprung des Käufers der Interessengruppe gehören. So können Protected Audience-Auktionen manuell ausgelöst werden.
  • Optional: Aktivieren Sie Echtzeitfeedback für Ihr Konto, um Feedback zu Käufern von Interessengruppen zu erhalten, die in eine Protected Audience-Auktion aufgenommen werden sollen.
  • Optional: Wenden Sie sich an Ihren Account Manager, um eine statische URL zu konfigurieren, damit Sie eine Server-zu-Server-Benachrichtigung mit einem Protected Audience-Gebot-Feedback zum Status eines Gebots aus einer Protected Audience-Auktion auf dem Gerät erhalten. So lassen sich unerwartete Probleme leichter beheben. Weitere Informationen finden Sie in der Benachrichtigung zu Gebotsfeedback.

Testphasen

Phase 1: Manueller Test

So lösen Sie manuell eine Protected Audience-Auktion aus, sorgen dafür, dass die Anzeige gerendert werden kann, und erfassen die Impression:

  1. Sie verwenden Chrome 101 oder höher.
  2. Aktivieren Sie die Privacy Sandbox API und Fenced Frame mit chrome://flags/#privacy-sandbox-ads-apis und chrome://flags/#enable-fenced-frames. Weitere Informationen finden Sie unter Privacy Sandbox testen.
  3. Reichen Sie ein Creative über die Real-time Bidding API ein.
  4. Fügen Sie der Interessengruppe des Bieters auf der Seite des vom Bieter bereitgestellten Werbetreibenden einen Browser hinzu.

  5. Verwenden Sie die folgende von Google bereitgestellte Test-Publisher-Seite, um eine Protected Audience-Auktion auszulösen:

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

    Die Interessengruppe im Browser muss hoch genug bieten, um die Auktion zu gewinnen, da sie möglicherweise mit herkömmlichen serverseitigen Geboten konkurriert. Außerdem stellt Google für jeden Partner eine spezielle Publisher-Testseite bereit, auf der nur der jeweilige Partner an der Auktion teilnehmen kann. Es ist möglicherweise einfacher, zuverlässig Auktionen im Browser auf einer partnerspezifischen Seite zu gewinnen.

  6. Überprüfen Sie Folgendes:

    1. Die erwartete erfolgreiche Anzeige wird gerendert.
    2. Das Ergebnis der Auktion wird serverseitig gesendet, das heißt, der erfolgreiche Bieter erhält einen Ping von reportWin().
    3. Die Publisher-Testkonsole protokolliert für jedes Gebot eine Debug-Meldung mit den folgenden Informationen:
      • renderUrl: Die Rendering-URL des Gebots.
      • interestGroupOwner: Der Inhaber der Interessengruppe des Gebots.
      • accepted: Dieses Feld enthält true, wenn das Gebot angenommen wurde, und false, wenn es von scoreAd() abgelehnt wurde.
      • externalBidStatus: Ein Statuscode, wenn das Gebot innerhalb von scoreAd() abgelehnt wurde. Werte sind Creative-Statuscodes.

Phase 2: (optional) Test ohne Rendering

Nachdem Google und der Partner manuell überprüft haben, ob der Partner an der Protected Audience-Auktion teilnehmen kann, befähigt Google ihn zur nächsten Testphase.

Google weist einen kleinen Teil des Live-Traffics für Protected Audience-Auktionen zu. Dann müssen Google und der Partner keine Protected Audience-Auktion mehr manuell auslösen. Das Ergebnis der Protected Audience-Auktion wird nicht gerendert. So können wir die Integration in großem Umfang testen.

Wenden Sie sich dazu an Ihren Account Manager oder reichen Sie über die Authorized Buyers-Hilfe ein Ticket ein. Google aktiviert das Konto für diese Phase.

Phase 3: Renderingtest

Sobald Google und der Partner Protected Audience-Auktionen im großen Maßstab ohne Rendering verifiziert haben, kann Google dem Partner ermöglichen, die entsprechende Anzeige zu rendern. Google hat eine geringe Anzahl von Zugriffen, bei denen Protected Audience-Auktionen ausgeführt werden können und bei denen auf einer Interessengruppe erfolgreiche Anzeigen gerendert werden. Die Gebote der teilnehmenden Bieter im Browser konkurrieren mit den herkömmlichen Geboten.

Wenden Sie sich dazu an Ihren Account Manager oder reichen Sie über die Authorized Buyers-Hilfe ein Ticket ein. Google aktiviert das Konto für diese Phase.