Diese Seite wurde von der Cloud Translation API übersetzt.

Protected Audience API (früher FLEDGE)

Im Rahmen der Privacy Sandbox hat Chrome die Protected Audience API vorgeschlagen. Das ist eine In-Browser-API, mit der Werbetreibende und Anbieter von Anzeigentechnologien Anzeigen mit Interessengruppen-Targeting ausliefern können, ohne Drittanbieter-Cookies zu verwenden. Gleichzeitig werden Nutzer vor websiteübergreifendem Tracking geschützt.

In Chrome wird ein Ursprungstest für die Protected Audience API durchgeführt. Authorized Buyers können an Tests der Protected Audience API für Ad Manager-Publisherinventar teilnehmen. Bieter können durch das Testen der Protected Audience API Folgendes erreichen:

In diesem Kurs erfahren Sie mehr über die Wirksamkeit von Protected Audience API-Abläufen.
Generieren Sie in öffentlichen Foren Feedback zu möglichen API-Verbesserungen – für Beispiel: GitHub.
Bereiten Sie sich darauf vor, personalisierte Werbung über die API zu unterstützen, ohne Drittanbieter-Cookies zu verwenden.

Authorized Buyers, die an Tests interessiert sind, finden im Abschnitt zum Onboarding weitere Informationen.

Zusammenfassung des Auslieferungsablaufs

Hier finden Sie eine Zusammenfassung des Verfahrens zur Anzeigenbereitstellung mit Protected Audience für Authorized Buyers. Partner:

Flussdiagramm

Eine Gebotsfunktion arbeitet mit seinen Werbetreibenden zusammen, um Interessengruppen für jede Gruppe zu verwalten. Werbetreibenden. Häufig fügen Werbetreibende das Tag eines Bieters zum Seite des Werbetreibenden, um einen Browser zu Interessengruppen hinzuzufügen.
Ein Endnutzer besucht die Seite eines Werbetreibenden. Die Seite enthält möglicherweise Tag.
Das Tag des Bieters ruft die Protected Audience API joinAdInterestGroup() auf. Mit diesem Aufruf wird der Browser aufgefordert, den Nutzer einer Interessengruppe hinzuzufügen.
Der Endnutzer besucht die Webseite eines Publishers. Die Browseranforderungen des Nutzers Publisher-Anzeigen-Tag von Google.
Über das Publisher-Anzeigen-Tag von Google wird eine kontextbezogene Anzeigenanfrage an einen Google-Server gesendet.
Google sendet Kontextgebotsanfragen an die teilnehmenden Bieter. Weitere Informationen finden Sie in der Weitere Informationen
Der Bieter gibt eine Gebotsantwort mit der InterestGroupBidding-Nachricht zurück, die für die Teilnahme an der Auktion für die Interessengruppe erforderlich ist. In OpenRTB wird dies mit dem Feld BidResponse.ext.igbid angegeben. Im eingestellten Google RTB-Protokoll wird dies mit dem Feld BidResponse.interest_group_bidding angegeben. Wenn der Bieter keine erfasst Google den Ursprung des Bieters nicht interestGroupBuyers in der Auktionskonfiguration. InterestGroupBidding kann auch optionale käuferspezifische Signale enthalten, die werden im Browser an die Gebotsfunktion des Bieters übergeben Auktion. In OpenRTB wird dies im Feld BidResponse.ext.igbid.igbuyer.buyerdata und im verworfenen Feld RTB-Protokoll von Google, das mit dem BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals ein. Weitere Informationen finden Sie im Abschnitt Änderungen an Gebotsantworten.
Google führt die serverseitige Auktion durch und gibt eine Gebotsantwort an den Browser. Bei der serverseitigen Auktion werden herkömmliche, serverseitige Gebote berücksichtigt. Die Gebotsantwort kann Informationen zu einem kontextbezogenen erfolgreichen Gebot enthalten, sofern beliebige).
Die Gebotsantwort enthält eine Auktionskonfiguration für die In-Browser-Auktion. Dabei kann es sich um Kontextsignale von jedem teilnehmenden Käufer handeln. (die über die buyerdata von OpenRTB oder die eingestellte RTB-Funktion von Google gesendet wurden per_buyer_signals des Protokolls), kontextbezogene Informationen zum Gewinner und Einstellungen für die Gebotsberechtigung.
Das Publisher-Tag von Google ruft die Protected Audience API aufrunAdAuction(), um die On-Device-Auktion für Interessengruppen zu starten. Google berücksichtigt nur Käufer, die bei der Auktionskonfiguration als InterestGroupBuyer in InterestGroupBidding enthalten waren.
Google übergibt die optionalen käuferspezifischen Signale jedes berechtigten Bieters an den Konfiguration der Protected Audience-Auktion.
Wenn für die Interessengruppen eines Bieters die trustedBiddingSignalsUrl angegeben ist, sendet der Browser eine Anfrage an die trustedBiddingSignalsUrl jeder Gruppe, um Echtzeitsignale für jede Gruppe abzurufen. Weitere Informationen finden Sie in der Protected Audience API-Spezifikation.
Der Browser ruft die generateBid() des Bieters für jede Interessengruppe auf die für die Teilnahme an der browserinternen Auktion infrage kommen. Dieses wird das Gebot berechnet und ein Creative ausgewählt. generateBid() hat Zugriff auf die vom Bieter bereitgestellten optionalen Käufersignale und die vertrauenswürdigen Gebotssignale für die jeweilige Interessengruppe.
Der Browser ruft die scoreAd() des Verkäufers (in diesem Fall von Google) auf, um Jedem Gebot in der auf einer Interessengruppe basierenden Anzeigenauktion wird ein Rang zugewiesen. Gebote nach Rang und gefiltert nach Schutzmaßnahmen von Publishern, Werberichtlinien und anderen Einschränkungen.
Der Browser führt eine Auktion mit den infrage kommenden Geboten für auf Interessengruppen basierende Anzeigen durch. Das höchste kontextbezogene Gebot nimmt an der In-Browser-Auktion teil.
Wenn nach der Auktion ein Gewinner einer Interessengruppe ermittelt wurde, ruft der Browser reportResult() des Verkäufers und reportWin() des Bieters, damit jeder den Gewinner der Browser-Auktion äußern.
Wenn eine Anzeige für eine Interessengruppe ausgewählt wird, wird sie über das Publisher-Tag von Google in einem Iframe gerendert.

Details zum Bereitstellungsablauf

Vor der Anzeigenbereitstellung

Creative-Überprüfung

Creatives müssen von Google überprüft und genehmigt werden, bevor sie über Browser-interne Auktionen mit Protected Audience-Zielgruppen. Sie können Creatives zur Überprüfung einreichen über die Real-time Bidding API oder über automatische Creative-Überprüfung. Creatives für In-Browser-Auktionen mit Protected Audience-Anzeigen auf Interessengruppenbasis müssen zur Überprüfung renderUrls enthalten.

Anforderungen für renderUrls:

Der über die API gesendete renderUrl muss mit dem verwendeten renderUrl übereinstimmen Interessengruppen-Anzeigenauktion.
Jede renderUrl darf nur einen einzelnen Werbetreibenden oder eine einzelne Werbekampagne repräsentieren. Ein bestimmtes renderUrl kann nicht zum Rendern von Anzeigen im Namen mehrerer Werbetreibender verwendet werden. Jeder renderUrl muss einem einzelnen Creative zugeordnet sein.
Die renderUrl muss bis zu sieben Tage nach dem letzten Gebot für die Offline-Systeme zur Creative-Prüfung von Google zugänglich und abrufbar sein.

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 das automatische Creative-Scannen für Creatives einrichten, die nicht über die Real-Time Bidding API hochgeladen werden.

Wenn Sie die automatische Creative-Prüfung einrichten, werden Creatives in der In-Browser-Auktion von Google gefunden und automatisch geprüft, damit sie für zukünftige Auktionen infrage kommen.

So aktivieren Sie die automatische Überprüfung von Creatives:

Fügen Sie dem Konto des autorisierten Käufers alle renderUrl-Quellen des Creatives für die Interessengruppe 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, codiert gemäß RFC2396.

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>

Ablaufzeit des Creatives

Creatives sind 15 Tage lang genehmigt. Wenn Sie Creatives mit der Echtzeitgebots-API einreichen, müssen Sie sie nach 15 Tagen noch einmal einreichen. Wenn Sie sich auf werden die Creatives beim automatischen Scannen automatisch erneut gescannt.

Berichts-ID für Käufer

Sie können Berichtsmesswerte wie Impressionen mithilfe von Dimensionen aufschlüsseln. (z. B. Kampagnen-ID oder Werbetreibenden-ID), So fügen Sie ein Dimension für Interessengruppenausgaben, geben Sie einen buyerAndSellerReportingId für wenn Sie der Interessengruppe das Gerät des Nutzers hinzufügen. Weitere Informationen finden Sie in der Protected Audience-Dokumentation.

Im folgenden Beispiel wird gezeigt, wie buyerAndSellerReportingId in die Konfiguration der Interessengruppe eingefügt wird:

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

Die buyer_reporting_id wird im Berichtstool für autorisierte Käufer als neue Dimension mit dem Namen Buyer Reporting ID-Dimension angezeigt.

Serverseitige Auktion

Änderungen an Gebotsanfragen

Im Test werden die folgenden frühen Versionen unterstützter Protokolle verwendet:

Early Link zu OpenRTB
RTB-Protokoll von Google (eingestellt) Early Link

Unterstützung bei Auktionen für Interessengruppen angeben

Gebotsanfragen enthalten neue Felder, mit denen die Unterstützung für Auktionen mit Interessengruppen angegeben werden kann:

OpenRTB:
- BidRequest.imp.ext.ae
- BidRequest.imp.ext.igbid
Google RTB-Protokoll (eingestellt):
- BidRequest.adslot.supported_auction_environment
- BidRequest.adslot.interest_group_bidding_allowed

Mit diesem Feld können Sie zwischen Umsatzchancen für Impressionen unterscheiden, die Protected Audience-Auktion für Interessengruppen im Browser unterstützen. unterstützen nur die herkömmliche serverseitige Auktionsplattform. Die AuctionEnvironment-Enumeration kann die folgenden Werte haben:

SERVER_SIDE_AUCTION (OpenRTB-JSON: 0): Die Auktion, über die der die erfolgreiche Anzeige auf den Servern der Anzeigenplattform ausgeführt wird.
ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB-JSON: 1): Anfragen mit mit der Protected Audience-Unterstützung, bei der eine kontextbezogene Auktion auf dem die Server der Anzeigenplattform und das Gebot für eine Interessengruppe und die letzte Auktion, im Browser ausgeführt wird.
SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): Die kontextbezogene Auktion wird auf den Servern der Anzeigenplattform ausgeführt. Die Gebotslogik für Gebote für Interessengruppen und die Bewertungslogik zur Bestimmung der endgültigen Gewinneranzeige werden auf Gebots- und Auktionsservern ausgeführt.

Größe der Protected Audience-Anzeigenfläche angeben

Die Gebotsanfrage enthält die folgenden Felder, um Ihnen die geschützten Größe der Zielgruppenanzeigenfläche:

OpenRTB:
- BidRequest.imp.ext.interest_group_auction.width
- BidRequest.imp.ext.interest_group_auction.height
Google RTB-Protokoll (eingestellt):
- BidRequest.adslot.interest_group_auction.width
- BidRequest.adslot.interest_group_auction.height

In diesen Feldern wird die Größe der Anzeigenfläche für die Auktion mit geschützten Zielgruppen in Pixeln angegeben.

Diese Größe kann von denen in der kontextbezogenen Anfrage abweichen, wie sie beispielsweise in der BidRequest.imp.banner.format.w von OpenRTB und BidRequest.imp.banner.format.h oder das eingestellte RTB-Protokoll von Google BidRequest.adslot.width und BidRequest.adslot.height.

Die kontextbezogene Anfrage kann mehrere Größen haben. Die Anzeige, die die On-Device-Auktion gewonnen hat, sollte nur eine einzige feste Slotgröße füllen.

Renderingbarkeit von Protected Audience-Anzeigen angeben

Ob Anzeigen für geschützte Zielgruppen gerendert werden, hängt von der aktuellen Integrationsphase ab (siehe Test zum Nicht-Rendern). Das render_interest_group_ads in der Gebotsanfrage gibt an, ob die erfolgreiche Protected Audience-Anzeige dargestellt wird.

OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
RTB-Protokoll von Google (eingestellt): BidRequest.adslot.interest_group_auction.render_interest_group_ads

Verwendung von Nutzerkennungen minimieren

Kontextbezogene Gebotsanfragen, die in den Protected Audience API-Tests enthalten sind, können weiterhin traditionelle cookiebasierte IDs enthalten, sofern diese vom Browser verfügbar sind, z. B. die Felder BidRequest.user.id und BidRequest.user.buyerid oder BidRequest.google_user_id und BidRequest.hosted_match_data im eingestellten Google RTB-Protokoll. Die Verwendung solcher IDs in Gebotsanfragen unterliegt den geltenden Datenschutzrichtlinien. Wir empfehlen Ihnen, nicht auf cookiebasierte Kennungen für Ausrichtungs- und Gebotszwecke angewiesen sind, Tests zur Vorbereitung auf effiziente Einkäufe ohne Drittanbieter-Cookies nicht mehr verfügbar sind.

Google kann auch kleine Tests durchführen, bei denen Cookie-basierte Kennungen werden aus Gebotsanfragen entfernt, die für die Protected Audience API-Tests relevant sind. So können wir die potenziellen Auswirkungen der Einstellung von Drittanbieter-Cookies besser beurteilen.

Von Chrome unterstützte Tests zur Einstellung von Drittanbieter-Cookies

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

Websites und Anbieter können ihre Systeme mithilfe von Chrome-gestützten Tests unter 3PCD testen. Im Test sind Chrome-Browser einer 3PCD-Testgruppe zugewiesen, entweder Modus A oder B. Jedem Browser wird ein einheitliches Label zugewiesen zu einer bestimmten 3PCD-Testgruppe gehören, der Chrome API im Browser.

Google übergibt das unveränderte Label aus der Chrome API an das RTB-Gebot Aufgrund der geringen Zugriffsanteile eines einzelnen Labels kann Google das Label in datenschutzkonformen Kontexten nicht immer enthält.

In den folgenden Feldern wird das Label angezeigt:

OpenRTB: BidRequest.device.ext.cdep
Google RTB-Protokoll (eingestellt): BidRequest.device.cookie_deprecation_label

Änderungen an Gebotsantworten

Teilnahme an Interessengruppenauktionen angeben

Sie sind dafür verantwortlich, ausdrücklich anzugeben, dass Sie Interesse am Programm browserinterne Auktion durch Rückgabe des InterestGroupBidding-Objekts im Kontextbezogene Gebotsantwort:

OpenRTB: BidResponse.ext.igbid
Google RTB-Protokoll (eingestellt): BidResponse.interest_group_bidding

Sie müssen eine kontextbezogene Gebotsantwort bereitstellen. Die Antwort ist nicht erforderlich, um Ein kontextbezogenes Gebot einschließen. Das InterestGroupBidding-Objekt sollte für jede InterestGroupBuyer die origin enthalten, die mit einem der vom Bieter für sein Konto konfigurierten Ursprünge übereinstimmen muss. Der Wert für origin wird dem interestGroupBuyers der Auktionskonfiguration hinzugefügt, wenn das Google Publisher-Tag runAdAuction() aufruft.

Kontextsignale von Käufern weitergeben

Sie können die Signale eines Käufers in die kontextbezogene Gebotsantwort aufnehmen. Google übergibt diese dann als JSON-Objekt über das Argument perBuyerSignals an die On-Device-Gebotsfunktion. Dies kann in der Gebotsantwort mit der Eigenschaft folgende Felder je nach Protokoll:

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

Kontextsignale für die Darstellung von Käufern weitergeben

Bei Creatives für Interessengruppen können während des Renderings eingeschränkte kontextbezogene Signale verwendet werden. Dazu werden diese Signale über die kontextbezogene Gebotsantwort gesendet und mithilfe der Makroerweiterung in der Anfrage für die Rendering-URL empfangen. Zum Beispiel wird das Rendern Signale können verwendet werden, um das Design eines Creatives anzupassen, die Leistung im Kontext einer bestimmten Anzeigenfläche oder Publisher-Seite zu messen.

Sie können die Rendering-Signale eines Käufers, die als URL-sicherer String serialisiert sind, in die kontextbezogene Gebotsantwort einfügen. Google ersetzt sie dann in der Render-URL der Gewinnerinteressengruppe durch das ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}-Makro.

Je nach Protokoll können Rendering-Signale in der Gebotsantwort mit den folgenden Feldern angegeben werden:

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

Bis zu drei Sätze von Rendering-Signalen mit unterschiedlichen Makrosuffixen können enthalten sein in der Gebotsantwort ein, um verschiedene Signale unterscheiden zu können. Beispiel: Ein Suffix können verwendet werden, um eine bestimmte Gruppe von Signalen abzugleichen, die nur für Creatives gelten. mit dem entsprechenden Makro in der Rendering-URL, wodurch die Datenübertragung Größe.

Der Käufer einer Interessengruppe wird von der Teilnahme am Protected Zielgruppenauktionen, wenn die Signale nicht URL-sicher sind, Makrosuffixe nicht eindeutig sind oder mehr als drei Gruppen von Signalen bereitgestellt werden.

Maximalgebot für In-Browser-Gebote angeben

In der Protected Audience API , wird die Gebotsberechnung und die endgültige Auktion erwartungsgemäß lokal auf dem Gerät. 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 Maßnahme, die während der Tests der Protected Audience API von Google für seine RTB-Partner unterstützt wird, können Sie in jeder Antwort auf eine kontextbezogene Gebotsanfrage einen erwarteten maximalen Gebotswert angeben. Das erwartete Höchstgebot ist der wird Ihre Bidding-Funktion zurückgegeben. Wenn das aus der In-Browser-Auktion gemeldete erfolgreiche Gebot diesen Betrag überschreitet, wird es nicht als abrechenbares Ereignis gezählt. Dieser Ansatz kann sich ändern.

In der Gebotsantwort können Sie den erwarteten maximalen Gebotswert in der folgenden Feldern:

OpenRTB: BidResponse.igbid.igbuyer.maxbid (in CPM-Währungseinheiten ausgedrückt)
RTB-Protokoll von Google (eingestellt): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (ausgedrückt in microCPM)

Impressionen mehreren Konten zuordnen

Ein Bieter muss eine Abrechnungs-ID auswählen, um seine Interessen zuzuordnen die Impressionen des Gruppengebots in die folgenden Felder ein:

OpenRTB: BidResponse.igbid.igbuyer.billing_id
RTB-Protokoll von Google (eingestellt): BidResponse.interest_group_bidding.interest_group_buyers.billing_id

Die ausgewählte Abrechnungs-ID muss eine zulässige Abrechnungs-ID aus der Gebotsanfrage sein:

OpenRTB: BidRequest.imp.ext.billing_id
Google RTB-Protokoll (eingestellt): BidRequest.adslot.matching_ad_data.billing_id

Wenn die Abrechnungs-ID, der Gebote für Interessengruppen zugeordnet werden sollen, 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 konfigurieren möchten. für ein Kinderkonto.

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.

Abrechnungs-IDs für alle untergeordneten Konten mit verfügbarem Budget, die auf das Impression erscheint in der Gebotsanfrage für die Attributionsauswahl für Ausgaben. Kontakt wenden Sie sich an Ihren Account Manager, um das Budget für eine Interessengruppen-Abrechnungs-ID zu ändern.

Während der In-Browser-Auktion

In-Browser-Gebote generieren

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

Google stellt die folgenden Parameter bereit:

auctionSignals: Leer
perBuyerSignals: Ein JavaScript-Objekt mit denselben Signalen, die vom Bieter in der Kontextantwort

Folgende Parameter werden zurückgegeben:

ad: Dieses Feld wird von Google ignoriert.
bid: Numerisches Gebot für die Teilnahme an der Auktion Muss in CPM-Einheiten angegeben werden (nicht „micros“).
render: Die URL, die zum Anzeigen des Creatives gerendert wird, wenn das Gebot den Auktion. Diese URL muss von Google geprüft und genehmigt werden, andernfalls wird sie herausgefiltert aus der Auktion.
allowComponentAuction: Muss true sein. Google unterstützt derzeit Tests bei Auktionen mit mehreren Verkäufern.

Beispiel:

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

Protected Audience-Spezifikation auf dem Gerät ansehen Gebote finden Sie eine Erläuterung der generateBid()-Funktion.

Gebotswährung

Gebote für In-Browser-Auktionen werden in CPM-Einheiten der ausgewählten Gebotswährung abgegeben.

Die Währung des Gebots muss sowohl in der Antwort auf die kontextbezogenen Gebote als auch im Rückgabewert von generateBid angegeben werden. Sie muss ein gültiger Alphacode gemäß ISO 4217 sein, z. B. „USD“, „EUR“ oder „JPY“.

Verwenden Sie in OpenRTB das neue Feld cur im InterestGroupBuyer-Objekt 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 InterestGroupBuyer-Nachricht in der Gebotsantwort.

Beispiel:

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

Bieter generateBid-Funktionen müssen Gebote in derselben Währung zurückgeben wie die in der kontextbezogenen Gebotsantwort angegeben sind. Fülle 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 der kontextbezogenen Gebotsantwort von der Währung unterscheidet von generateBid zurückgegeben oder wenn bei einem der beiden eine ungültige Währung zurückgegeben wird, wird der Gebot vor der Auktion herausgefiltert.

Qualitätsprüfungen für Anzeigen

Die Erzwingung der Creative-Richtlinien und Publisher-Steuerelemente ist möglicherweise restriktiver für Gebote für Interessengruppen im Browser während des Protected Audience API-Tests für RTB Partner.

Unterstützung für das Gesetz über digitale Dienste

Gemäß Artikel 26 des Gesetzes über digitale Dienste können Publisher Käufer auffordern, Transparenzinformationen in Anzeigen zu platzieren. Wenn die Option „Käufer bitten, Anzeigen nur mit dynamischen Suchanzeigen zu schalten“ Transparenzinformationen auf meiner Website oder in meiner App im EWR“ wird durch eine Publisher können auf einer Interessengruppe basierende Käufer festlegen, welche Werbechancen sie die für Transparenz erforderlich sind, indem die Werte BidRequest.regs.dsa.required und BidRequest.dsa.pubrender im Gebot (BidRequest.dsa.dsa_support und BidRequest.dsa.publisher_rendering_support in der verworfenen RTB-Protokoll von Google).

Wenn ein Bieter, der an Protected Audience API-Auktionen teilnehmen möchte, in der Gebotsanfrage das Signal erhält, dass die DSA-Transparenz für Anzeigen angezeigt werden muss, die über die Protected Audience API ausgeliefert werden, sollte er prüfen, ob die erforderlichen Informationen angemessen dargestellt werden können. Dazu muss er BidResponse.ext.igbid.igbuyer.dsaadrender festlegen (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render im eingestellten Google RTB-Protokoll). Andernfalls wird der Käufer nicht in die Protected Audience API-Auktion aufgenommen.

Weitere Informationen zur Anzeigentransparenz im Rahmen des Gesetzes über digitale Dienste finden Sie hier: Hilfeartikel: Unterstützung des Gesetzes über digitale Dienste

Gebotsfilterung

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

Nach der In-Browser-Auktion

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 mitzuteilen.

Weitere Informationen finden Sie im Abschnitt Käuferberichte zu Render- und Anzeigenereignissen der Erläuterung zur Protected Audience API.

Makros

Das renderUrl-Element, das auf das Creative der Protected Audience API verweist, kann einen oder mehrere Platzhalter enthalten, die als Makros bezeichnet werden. Nach der Interessengruppenauktion vor dem Rendern durch die entsprechenden Werte. Die in der On-Device-Auktion verwendete renderUrl kann Folgendes umfassen: Makros:

`${GDPR}`	Wird zu „0“, wenn die DSGVO nicht gilt, oder zu „1“, wenn die DSGVO gilt. Dokumentation ansehen
`${GDPR_CONSENT_XXXX}`	Wird in die Transparenz & Einwilligungsstring (TC-String), der der Anfrage zugeordnet ist. Wenn die Transparenz- und Der Einwilligungsstring (TC-String) ist leer oder ungültig. Dieses Makro wird nicht erweitert. Verwenden Sie dieses Makro, um den TC-String in einer URL an einen Anbieter zu übergeben, der für die IAB-GVL registriert ist. Ersetzen Sie `XXXX` durch die IAB-GVL-ID der IAB-GVL-registriert. Zulieferunternehmen. Wenn der TC-String leer oder ungültig ist, wird das Makro nicht erweitert. Creatives mit dem Makro `${GDPR_CONSENT_XXXX}` können wird blockiert, wenn der mit der IAB-GVL-ID verknüpfte Anbieter, der in der IAB-GVL registriert ist, keine Nutzereinwilligung eingegeben hat. Das `${GDPR_CONSENT_XXXX}`-Makro darf nur einmal innerhalb eines `renderUrl`.
`${ADDL_CONSENT}`	Das Makro wird in den String für die zusätzliche Einwilligung erweitert, der der Anfrage zugeordnet ist.
`${AD_WIDTH}, ${AD_HEIGHT)`	Mit diesen Makros werden Breite und Höhe der Werbefläche eingefügt.
`${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}`	Makro mit Käufersignalen zur Laufzeit, die in der Gebotsantwort angegeben sind. Platzhalter `buyer.origin.example` durch Ursprung ersetzen des Interessengruppen-Käufers. Dieser Wert sollte der `interest_group_buyers.origin` in die Gebotsantwort ein. Sie können ein `_OPTIONAL_SUFFIX` einfügen, um bis zu drei verschiedene Werte für das Renderingsignal anzugeben.

Zählung von Impressionen

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

Da das Ereignis, das von Google zum Zählen von Impressionen in In-Browser-Auktionen für geschützte Zielgruppen verwendet wird, möglicherweise vom Ereignis abweicht, das von RTB-Käufern zum Zählen von Impressionen verwendet wird, können sich die Impressionszahlen unterscheiden.

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

Zuordnung der abrechenbaren Impressionen

Alle Ausgaben eines Bieters aus In-Browser-Auktionen für geschützte Zielgruppen werden basierend auf der Zuordnung der für den Bieter konfigurierten Inhaber von Interessengruppen einem einzelnen Bieterkonto zugeordnet. Die Ausgaben für verschiedene Untergeordnete Nutzerkonten eines Bieters werden nicht unterstützt.

Tagesbudgetlimit

Während der Tests der Protected Audience API hat jedes Konto ein Tagesbudget für Protected Audience-Ausgaben auf Kontoebene. Das Tagesbudget begrenzt das Risiko in der In-Browser-Auktionsumgebung. Sobald die tägliche Budgetobergrenze erreicht ist, Konto keine Gebotsanfragen mehr für Protected Audience.

Das Konto kann auch nach Erreichen des Limits für geschützte Zielgruppen an serverseitigen kontextbezogenen Auktionen teilnehmen. Ein Bieterkonto, das das Limit für geschützte Zielgruppen erreicht, kann beispielsweise eine Gebotsanfrage mit auction_environment = SERVER_SIDE_AUCTION (OpenRTB JSON: 0) erhalten, auch wenn die Gebotsanfrage für eine Auktion mit geschützten Zielgruppen infrage kommt.

Echtzeitfeedback und Mindestgebot, um zu gewinnen

Bieter, die den Erhalt von Informationen aktiviert haben Feedback in Echtzeit erhält Feedback für Käufer einer Interessengruppe, die in eine Protected Audience-Auktion auf dem Gerät an. Für jeden Interessengruppenkäufer, den ein Bieter in einer Gebotsantwort angibt, wird ein Feedbackobjekt gesendet, unabhängig davon, wie viele Gebote der Interessengruppenkäufer in der Protected Audience-Auktion abgibt. Die folgende Informationen sind im Käufer-Feedback der Interessengruppe verfügbar -Objekt enthält:

Der Feedbacktyp des Feedback-Objekts ist INTEREST_GROUP_BUYER_FEEDBACK
Der Ursprung des Käufers der Interessengruppe.
Das Mindestgebot, das der Käufer der Interessengruppe abgeben muss, um die gesamte Auktion zu gewinnen.
Das Mindestgebot, das der Interessengruppenkäufer abgeben muss, um das höchste Gebot der serverseitigen Komponente der gesamten Auktion zu überbieten.
Der Statuscode des Käufers der Interessengruppe. Mögliche Statuscodes sind definiert in interest-group-buyer-status-codes.txt.

Die spezifischen Feldnamen finden Sie in der Protokolldokumentation für die RTB-Funktion in Authorized Buyers und die OpenRTB-Erweiterungen.

Benachrichtigung über Gebotsfeedback

Chrome bietet eine vorübergehende Debugging-API für die Protected Audience API, mit der Ad Manager Echtzeit-Debugging-Benachrichtigungen von Server zu Server senden kann, die Feedback zu einem Gebot für Protected Audiences enthalten. In dieser Benachrichtigung werden Gründe aufgeführt, warum Gebote die in der browserinternen Protected Audience-Auktion herausgefiltert werden, sowie andere zu einem der unten beschriebenen Gebote.

Bieter können ihren Account Manager bitten, eine statische URL zu konfigurieren, zum Senden von Benachrichtigungen zum Protected Audience-Debugging für Gebotsfeedback. Dieses Die statische URL wird von Google-Servern abgerufen, wobei die ausgewählten Makros ersetzt werden nach der Protected Audience-Auktion weiter. Die folgenden Makros sind unterstützt:

%%GOOGLE_QUERY_ID%%: Dieses Makro wird durch die Google-Abfrage-ID ersetzt. der in der für Protected Audience aktivierten kontextbezogenen Gebotsanfrage gesendet wurde. Im OpenRTB-Protokoll wird dies mit BidRequest.ext.google_query_id angegeben, während im eingestellten Google RTB-Protokoll BidRequest.google_query_id verwendet wird.
%%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 der Creative-Status Codes.

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 zu Gebotseingaben ist eine vorübergehende Funktion, die von der vorübergehenden ForDebuggingOnly API von Chrome abhängt.

TURTLEDOVE auf Produktebene

Anzeigen, die aus mehreren Teilen bestehen oder Produktebene TURTLEDOVE PLTD-Partner werden während der Protected Audience API für RTB-Partner von Google unterstützt Tests durchführen. Informieren Sie Ihren Account Manager während der Integration, wenn Sie PLTD testen möchten, da zusätzliche Ressourcen und eine zusätzliche Konfiguration erforderlich sind.

Onboarding

So testen Sie die Protected Audience API:

Schritte

Füllen Sie das Anfrageformular aus. um am Protected Audience API-Test teilzunehmen.
Wenden Sie sich nach dem Absenden des Antragsformulars an Ihren Account Manager oder an Ihre Datei. ein Ticket über die Authorized Buyers-Hilfe .
Sobald das Konto konfiguriert ist, können sowohl Google als auch der Partner die wie unter Testphasen beschrieben.

Creative-Überprüfung

Wenn Sie in Protected Audience API-Auktionen mit Anzeigen auf Produktebene (Anzeigen, die aus mehreren Elementen bestehen) bieten möchten, müssen folgende Anforderungen erfüllt sein:

Fügen Sie den Abfrageparameter &pltd=True in den renderUrl für den Container der Komponentenanzeige (auch renderUrl der obersten Ebene genannt) ein, um renderUrls der obersten Ebene bei der Creative-Überprüfung zu unterscheiden.
Ein repräsentatives Creative wird gerendert, wenn der Container der Komponentenanzeige von Google für eine Creative-Prüfung abgerufen wird. Um zu verstehen, wann ein repräsentatives Anzeigen-Rendering zurückgegeben werden soll, können Sie dem validation=True-Suchparameter wurde vom Google-System für die Creative-Überprüfung festgelegt.

Checkliste für die Integration

Richten Sie einen Endpunkt für Gebotsanfragen ein, der die Protected Audience API füllt zugehörige Felder in der kontextbezogenen Gebotsantwort, z. B. interest_group_bidding
Implementieren Sie Tagging auf den Seiten des Werbetreibenden, um den Browser des Nutzers der Interessengruppe zuzuordnen.
Implementieren Sie generateBid() und reportWin().
Wählen Sie die Eigentümer von Interessengruppen aus und fügen Sie sie dem Konto des autorisierten Käufers hinzu.
- Die Ursprünge der Eigentümer von Interessengruppen müssen mit den Ursprüngen übereinstimmen, an denen die generateBid()-Funktionen gehostet werden.
- Wenden Sie sich an den Account Manager oder reichen Sie über die autorisierte Käufer-Hilfe, um führen Sie diesen Schritt aus.
Pre-Targeting für Inventar einrichten, das für die Protected Audience API relevant ist Tests durchführen.
Reichen Sie Creatives über die Creatives API zur Überprüfung und Genehmigung ein.
Optional: Richten Sie die Endpunkte für Trusted Bidding-Signale ein.
Optional: Richten Sie eine Testseite für Werbetreibende ein, über die Google-Entwickler ihren Browser den Interessengruppen hinzufügen können, deren Inhaber der Käufer Ihrer Interessengruppe ist. So können wir Protected Audience-Auktionen manuell auslösen.
Optional: Aktivieren Sie in Ihrem Konto Echtzeitfeedback, um Feedback für Käufer von Interessengruppen zu erhalten, die in einer Protected Audience-Auktion berücksichtigt werden sollen.
(Optional) Wenden Sie sich an Ihren Account Manager, um eine statische URL für eine Server-zu-Server-Benachrichtigung mit einem Protected Audience-Gebot erhalten. Feedback zum Status eines Gebots von einer Protected Audience auf dem Gerät , um bei der Behebung unerwarteter Probleme zu helfen. Weitere Informationen finden Sie in der Benachrichtigung zum Gebotsfeedback.

Testphasen

Phase 1: Manueller Test

So lösen Sie eine Protected Audience-Auktion manuell aus: gerendert werden soll und die Impression erfasst:

Verwenden Sie Chrome 101 oder höher.
Aktivieren Sie die Privacy Sandbox API und den Fenced Frame mit chrome://flags/#privacy-sandbox-ads-apis und chrome://flags/#enable-fenced-frames. Weitere Informationen finden Sie unter Privacy Sandbox testen.
Reichen Sie ein Creative mithilfe der Real-Time Bidding API zur Genehmigung ein.
Verwenden Sie die vom Bieter bereitgestellte Werbetreibendenseite, um der vom Bieter verwalteten Interessengruppe einen Browser hinzuzufügen.
Verwenden Sie die folgende von Google bereitgestellte Test-Publisher-Seite, um eine geschützte Zielgruppenauktion:

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

Das Gebot für die In-Browser-Zielgruppe muss hoch genug sein, um die Auktion zu gewinnen, da sie möglicherweise mit herkömmlichen serverseitigen Geboten konkurriert. Google bietet auch eine Publisher-Testseite für jeden Partner, auf der nur der entsprechende Partner an der Auktion teilnehmen können. Es kann einfacher sein, In-Browser-Auktionen auf einer partnerspezifischen Seite zuverlässig zu gewinnen.
Gehen Sie so vor:
1. Die erwartete erfolgreiche Anzeige wird gerendert.
2. Das Auktionsergebnis wird serverseitig gesendet. Das bedeutet, dass der Bieter, der die Auktion gewonnen hat, einen Ping von reportWin() erhält.
3. In der Console der Test-Publisherseite wird für jede Gebot eine Debug-Nachricht mit den folgenden Informationen protokolliert:
  - renderUrl: Die Render-URL des Gebots.
  - interestGroupOwner: Der Inhaber der Interessengruppe, auf die sich das Gebot bezieht.
  - accepted: Dieses Feld hat den Wert true, wenn das Gebot angenommen wurde, und false. Das Gebot wurde von scoreAd() abgelehnt.
  - externalBidStatus: Statuscode, wenn das Gebot innerhalb von scoreAd(). Werte sind der Creative-Status Codes.

Phase 2 (optional): Test ohne Rendering

Nachdem Google und der Partner manuell bestätigt haben, dass der Partner an der Protected Audience-Auktion teilnehmen, ermöglicht Google dem Partner, die nächste Phase des Tests.

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

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

Phase 3: Renderingtest

Sobald Google und der Partner Protected Audience-Auktionen in großem Umfang verifiziert haben kann Google dem Partner ermöglichen, die geschützten Inhalte Anzeige, die Ihre Zielgruppe anspricht. Google verzeichnet nur wenige Zugriffe, bei denen Auktionen für geschützte Zielgruppen zulässig sind und Anzeigen für die Gewinnerinteressengruppen ausgeliefert werden. Die In-Browser-Gebote der teilnehmenden Bieter konkurrieren mit den traditionellen Geboten.

Wenden Sie sich an Ihren Account Manager oder reichen Sie ein Ticket über den Authorized Buyers- Hilfe, sobald Sie bereit sind. Google aktiviert das Konto für diese Phase.

Zusätzliche Funktionen

Die folgenden Funktionen sind Erweiterungen des Kernprotokolls.

Parallelisierung

Die Parallelisierung ist eine Optimierung, die die End-to-End-Auktionslatenz verringert, indem die Anfrage für die kontextbezogenen Anzeigen parallel zu den Anfragen an die in trustedBiddingSignalsUrl angegebenen vertrauenswürdigen Server des Käufers gestartet wird.

Parallelisierung reduziert die Latenz, wirkt sich aber auf die Interessengruppe aus Eignungskriterien für Käufer und Support für koordinierten Tests. Die Parallelisierung gilt für alle Bieter, die an der On-Device-Interessengruppenauktion. Bieter müssen keine Maßnahmen ergreifen, um an parallelen Auktionen teilnehmen, sich mit den wie sich die Parallelisierung auf ihre Eignung für On-Device-Auktionen auswirken kann. Testgruppen-IDs für koordinierte Tests werden in parallelen Auktionen noch nicht unterstützt.

Zusammenfassung des Auslieferungsablaufs

Zusammenfassung des parallelen Auktionsablaufs: Flussdiagramm

Voraussetzungen für Käufer von On-Device-Interessengruppen

Bei parallelen Auktionen wird navigator.runAdAuction vor der Rückgabe der kontextbezogenen Anzeigenantwort aufgerufen. Um den Käufer als vertrauenswürdig einzustufen Serveraufrufe, erfordert navigator.runAdAuction, dass der Der interestGroupBuyers-Parameter muss als Wert übergeben, während die restlichen Auktionsparameter JavaScript akzeptieren Promises, die nach der kontextbezogenen Anzeigenantwort aufgelöst werden können. Da interestGroupBuyers vor der kontextbezogenen Anzeigenantwort übergeben wird, kann anhand der kontextbezogenen Anzeigenantwort (einschließlich Gebotsantworten) nicht ausgewählt werden, welche Käufer an der parallelen Auktion für die jeweilige Anfrage teilnehmen. Stattdessen werden die Publisher-Tag-Caches von Google, im Browser des Nutzers den Parameter interestGroupBuyers aus dem vorherigen navigator.runAdAuction Ausführungen in derselben Domain.

Bei der Parallelisierung müssen mehrere wichtige Aspekte berücksichtigt werden:

Auktionssignale, die für vertrauenswürdige Serveranfragen des Käufers nicht erforderlich sind, wie perBuyerSignals, kann weiterhin in Gebotsantworten für Echtzeitgebote angegeben werden. wie bei nicht parallelisierten Auktionen. Sobald die Promises für diese Signale geklärt sind, können die verbleibenden Schritte des Die On-Device-Auktion wird genauso abgeschlossen wie die nicht parallele Auktion Auktionsablauf.
Da die Parallelisierung auf dem Caching der Liste der Käufer von Interessengruppen basiert, führt Google nicht immer eine parallele Auktion durch, da der Parallelisierungscache möglicherweise leer oder abgelaufen ist. Wenn der Cache leer oder abgelaufen ist, führt Google eine standardmäßige nicht parallele Protected Audience API-Auktion durch und verwendet die Kaufabsicht, um an der nicht parallelen Auktion teilzunehmen und den Cache für Käufer mit gemeinsamen Interessen zu erstellen.
Wenn für die aktuelle Publisher-Domain mindestens ein Käufer für jeden Bieter im Cache gespeichert ist, führt Google eine parallele Auktion durch. Dies wird in der Gebotsanfrage angegeben:
- Google RTB-Protokoll: BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized
Jede registrierte Interessengruppe des Käufers für einen bestimmten Bieter, der die an der parallelen Auktion teilnehmen, ParallelAuctionBuyer-Eintrag:
- Google RTB-Protokoll: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
- OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer
Wenn eine parallele Auktion ausgeführt wird, aber eine bestimmte Käuferquelle nicht im Cache vorhanden ist, kann dieser Käufer der aktuellen On-Device-Auktion nicht hinzugefügt werden. Dies wird durch eine Anfrage mit parallelized=True angezeigt, für die für den Käuferursprung einer bestimmten Interessengruppe kein ParallelAuctionBuyer-Eintrag vorhanden ist. Bietern, die ihr Interesse durch Angabe gültiger und berechtigter InterestGroupBuyer in ihrer Gebotsantwort signalisieren, werden die entsprechenden Käufer-Herkunftsquellen der Interessengruppe jedoch in den Cache aufgenommen. Diese Herkunftsquellen können dann für zukünftige parallele Anfragen aus demselben Browser und derselben Domain verwendet werden. Die Absicht, an Auktionen für Interessengruppen teilzunehmen, kann in den folgenden Feldern angegeben werden:
- Google RTB-Protokoll: BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB: BidResponse.ext.igbid.igbuyer
Im Cache gespeicherte Käuferursprünge (die in der parallelen Auktion enthalten sind) interestGroupBuyers-Parameter), für die der Bieter keine Absicht angibt zur Teilnahme an ihrer Gebotsantwort möglicherweise einen vertrauenswürdigen Serveraufruf vom Käufer erhalten. aber nicht an der parallelen Auktion teilnehmen.