Diese Seite wurde von der Cloud Translation API übersetzt.

Protected Audience API (früher FLEDGE)

Chrome hat im Rahmen der Privacy Sandbox Geschützte Zielgruppe API: Browser-API mit der Werbetreibende und AdTech-Unternehmen Anzeigen schalten können, die auf Interessengruppen ohne sich auf Drittanbieter-Cookies zu verlassen, und schützen gleichzeitig die Nutzer vor websiteübergreifenden Verfolgung.

Chrome führt einen Ursprung aus Probeabo für die Protected Audience API. Authorized Buyers können am die Protected Audience API auf Ad Manager-Publisher-Inventar testen. 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 auf die Unterstützung personalisierter Anzeigen über die API vor, ohne Drittanbieter-Cookies zu nutzen.

Für Authorized Buyers-Nutzer, die an Tests interessiert sind, finden Sie in der Anleitung zur Einrichtung .

Zusammenfassung des Bereitstellungsablaufs

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. Bei diesem Aufruf wird der Browser aufgefordert, den Nutzer einer Interessengruppe hinzuzufügen.
Der Endnutzer besucht eine Publisher-Webseite. Die Browseranforderungen des Nutzers Publisher-Anzeigen-Tag von Google.
Das Publisher-Anzeigen-Tag von Google sendet eine kontextbezogene Anzeigenanfrage an einen Google-Server.
Google sendet kontextbezogene Gebotsanfragen an die teilnehmenden Bieter. Weitere Informationen finden Sie in der Weitere Informationen
Der Bieter gibt BidResponse mit dem Feld interest_group_bidding zurück. Wenn der Bieter interest_group_bidding nicht angibt, gibt Google den Ursprung des Bieters in „interestGroupBuyers“ in die Auktion aufnehmen Konfiguration. Die Gebotsantwort kann auch interest_group_bidding.per_buyer_signals enthalten. per_buyer_signals wird im folgenden Zeitraum an die Gebotsfunktion des Bieters übergeben eine Auktion im Browser. Weitere Informationen finden Sie im Hilfeartikel Änderungen an den Gebotsantworten“. finden Sie weitere Informationen.
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 den Browser. Auktion. Dabei kann es sich um Kontextsignale von jedem teilnehmenden Käufer handeln. (die über interest_group_bidding.per_buyer_signals gesendet wurden), Kontextinformationen zu Gewinnern und Einstellungen für die Gebotsberechtigung.
Das Publisher-Tag von Google ruft die Protected Audience API runAdAuction() auf um die On-Device-Auktion für eine Interessengruppe zu starten. Google umfasst nur Käufer, die zuvor interest_group_bidding zurückgegeben haben als interestGroupBuyers in der Auktionskonfiguration.
Google übergibt die per_buyer_signals jedes berechtigten Bieters an den geschützten Wert Konfiguration der Zielgruppenauktion.
Wenn in den Interessengruppen eines Bieters die trustedBiddingSignalsUrl, stellt der Browser eine Anfrage an die trustedBiddingSignalsUrl, um Echtzeitsignale für jede Gruppe abzurufen. Weitere Informationen finden Sie unter 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 den vom Bieter bereitgestellten per_buyer_signals und das Trusted Bidding 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 Interessengruppengeboten durch. Die das Kontext-Gebot mit dem höchsten Rang an der In-Browser-Auktion teilnimmt.
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.
Falls eine auf einer Interessengruppe basierende Anzeige erfolgreich ist, rendert das Publisher-Tag von Google die Anzeige in einer iFrame.

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 Auktionen von Protected Audience-Anzeigen für Interessengruppen im Browser müssen Folgendes enthalten: renderUrls zur Überprüfung.

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 Werbung repräsentieren. Kampagne. Eine bestimmte renderUrl kann nicht zum Rendern von Anzeigen im Namen von verwendet werden: für mehrere Werbetreibende. Jeder renderUrl muss einem einzelnen Creative zugeordnet sein.
renderUrl muss offline für Google zugänglich und abrufbar sein bis zu 7 Tage, nachdem das letzte Gebot für die Anzeige abgegeben wurde.

Real-time Bidding API

Bieter können mithilfe der Funktion Echtzeitgebote API zum Hochladen von Creatives auf Interessengruppen.

Automatische Creative-Überprüfung

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

Wenn Sie das automatische Scannen von Creatives einrichten, sucht Google Creatives in der in einer browserinternen Auktion ermittelt und automatisch überprüft, in zukünftigen Auktionen berücksichtigt werden.

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

Fügen Sie alle renderUrl-Ursprünge des Creatives für Interessengruppen zum Authorized Buyers-Konto.

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, das gemäß 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 Echtzeit- Bidding API verwenden, müssen Sie das Creative 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. vom Käufer bereitgestellt werden (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 in Protected Audience API-Informationen Dokumentation.

Das folgende Beispiel zeigt, wie buyerAndSellerReportingId in der Interessengruppenkonfiguration:

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

Das Feld „buyer_reporting_id“ wird im Bereich „Autorisierte Dienste“ als neue Dimension Berichtstool des Käufers, als Dimension „Berichts-ID des Käufers“

Serverseitige Auktion

Änderungen an Gebotsanfragen

Die folgenden Versionen sind frühe Versionen der unterstützten Protokolle für die Verwendung in der Experiment:

Early Link zum RTB-Protokoll von Google
Early Link zu OpenRTB

Unterstützung bei Auktionen für Interessengruppen angeben

Gebotsanfragen haben ein neues Feld: auction_environment.

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

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 auction_environment-Enum kann die folgenden Werte haben:

SERVER_SIDE_AUCTION (OpenRTB-JSON: 0): Herkömmliche serverseitige Auktionen
ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB-JSON: 1): Anfragen mit mit der Protected Audience-Unterstützung, bei der eine kontextbezogene Auktion auf dem auf den Servern der Anzeigenplattform und das Gebot für eine Interessengruppe und die letzte Auktion im Browser

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:

EZG-Protokoll von Google: <ph type="x-smartling-placeholder">
- BidRequest.adslot.interest_group_auction.width
- BidRequest.adslot.interest_group_auction.height
OpenRTB: <ph type="x-smartling-placeholder">
- 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 an in Pixeln.

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

Die kontextbezogene Anfrage kann mehrere Größen haben. Die erfolgreiche On-Device-Auktion -Anzeige nur eine feste Anzeigenflächengröße füllt.

Renderingbarkeit von Protected Audience-Anzeigen angeben

Protected Audience-Anzeigen werden je nach aktueller Integrationsphase (siehe Nicht-Rendering Test. Das render_interest_group_ads in der Gebotsanfrage gibt an, ob die erfolgreiche Protected Audience-Anzeige dargestellt wird.

EZG-Protokoll von Google: BidRequest.adslot.interest_group_auction.render_interest_group_ads
OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads

Verwendung von Nutzerkennungen minimieren

Kontextbezogene Gebotsanfragen, die für Protected Audience API-Tests infrage kommen, weiterhin herkömmliche Cookie-basierte IDs tragen, sofern diese über die wie google_user_id (BidRequest.user.id in OpenRTB) und hosted_match_data (BidRequest.user.buyerid in OpenRTB) Die Anwesenheit der Kennungen in Gebotsanfragen unterliegen weiterhin allen bestehenden Datenschutzerklärung. Wir raten davon ab, sich auf cookiebasierte Kennungen zu verlassen, Ausrichtungs- und Gebotszwecke nutzen, um ein effizientes Arbeiten wenn keine Drittanbieter-Cookies mehr verfügbar sind.

Google kann auch kleine Tests durchführen, bei denen Cookie-basierte Kennungen aus Gebotsanfragen für Protected Audience API-Tests entfernt. Dieses die potenziellen Auswirkungen der Einstellung von Drittanbieter-Cookies zu bewerten.

Tests zur Einstellung von Drittanbieter-Cookies, die von Chrome unterstützt werden

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

Websites und Anbieter können Chrome-gestützte Tests nutzen, um ihre Systeme 3PCD 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:

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

Änderungen an Gebotsantworten

Teilnahme an Auktionen für Interessengruppen 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:

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

Sie müssen eine kontextbezogene Gebotsantwort bereitstellen. Die Antwort ist nicht erforderlich, um Ein kontextbezogenes Gebot einschließen Das Objekt InterestGroupBidding sollte den Parameter origin des Interessengruppeninhabers, die mit einem der Ursprünge übereinstimmen muss die der Bieter für sein Konto konfiguriert hat. origin wird zur Auktion hinzugefügt interestGroupBuyers der Konfiguration, wenn das Google Publisher-Tag aufruft runAdAuction()

Kontextsignale für Käufer („perBuyerSignals“) weitergeben

Sie können Käufersignale in die kontextbezogene Gebotsantwort aufnehmen, die von Google wird über den Parameter perBuyerSignals-Argument. Dies kann in der Gebotsantwort mit der Eigenschaft folgende Felder je nach Protokoll:

RTB-Protokoll von Google: BidResponse.interest_group_bidding.per_buyer_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata

Kontext-Rendering-Signale für Käufer weitergeben

Bei Creatives für Interessengruppen werden beim Rendering möglicherweise eingeschränkte Kontextsignale verwendet. Diese Signale werden über die kontextbezogene Gebotsantwort gesendet und empfangen. mithilfe der Makroerweiterung in der Render-URL-Anfrage einfügen. 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 als URL-sicherer String serialisiert in der kontextbezogenen Gebotsantwort, die Google im gewinnenden Interesse ersetzt. Gruppen-Rendering-URL, indem Sie die Methode ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}-Makro.

Renderingsignale können in der Gebotsantwort folgendermaßen angegeben werden: enthalten:

RTB-Protokoll von Google: BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.rsig

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.

Preis für das maximale Gebot im Browser festlegen

In der Protected Audience API , wird die Gebotsberechnung und die endgültige Auktion erwartungsgemäß lokal auf dem Gerät. Dadurch entstehen möglicherweise Potenzielle Missbrauchsvektoren, die sich auf die Integrität der finalen Auktion auswirken können z. B. den Preis des erfolgreichen Gebots.

Als Abhilfemaßnahme während der Protected Audience API-Tests von Google für seine RTB-Partner können Sie in jedem kontextbezogene Gebotsantwort. Das erwartete Höchstgebot ist der wird Ihre Bidding-Funktion zurückgegeben. Wenn das erfolgreiche Gebot Wenn die Auktion im Browser diesen Betrag überschreitet, wird das erfolgreiche Gebot nicht gezählt. abrechnungsfähige Aktion auszuführen. Dieser Ansatz kann sich ändern.

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

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

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:

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 zulässige 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 für Interessengruppengebote zugeordnet werden sollen, erforderlich ist, nimmt der Bieter nicht an der Protected Audience-Auktion teil.

Untergeordnete Konten können bis zu zwei Abrechnungs-IDs haben. Der Käufer könnte eine Abrechnungs-ID für kontextbezogene Ausgaben und die andere für Ausgaben für Interessengruppen. 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 Ihr 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

Gebote im Browser generieren

Verwenden Sie generateBid(), um Browsergebote zu generieren.

Google stellt die folgenden Parameter bereit:

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

Die folgenden 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 überprü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 in Auktionen werden in CPM-Einheiten der ausgewählten Gebotswährung angegeben.

Die Gebotswährung muss sowohl in der kontextbezogenen Gebotsantwort als auch in den Rückgabewert von generateBid und muss ein gültiger ISO 4217-Alphacode sein, z. B. als „USD“, „EUR“ oder „JPY“.

Verwenden Sie in OpenRTB das neue Feld cur im InterestGroupBuyer-Objekt in Erweiterung für Gebotsantworten 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 die neue Property bidCurrency aus. Rückgabewert von generateBid:

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.

Überprüfung der Anzeigenqualität

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 im Gesetz über digitale Dienste

Aufgrund von Artikel 26 des Gesetzes über digitale Dienste (Digital Services Act) können Publisher Offenlegungen in der Anzeigentransparenz Wenn die Option „Käufer bitten, nur Anzeigen 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 die Transparenz des Käufers erforderlich sind, indem Sie die folgenden Felder erhaltene Gebotsanfragen: BidRequest.dsa.dsa_support und BidRequest.dsa.publisher_rendering_support für das Google Authorized Buyers-Protokoll und 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, erhält in der Gebotsanfrage das Signal, dass für die DSA-Transparenz angezeigt werden muss. über die Protected Audience API ausgeliefert werden, sollte geprüft werden, kann er die erforderlichen Informationen entsprechend anzeigen und festlegen, 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. Andernfalls wird der Käufer nicht an der Protected Audience API-Auktion teilnehmen.

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

Gebotsfilterung

Google setzt Publisher durch Einstellungen und Anzeige Richtlinien während der On-Device-Auktion an.

Nach der browserinternen 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 zu melden.

Käuferberichte zu Rendering und Anzeigen aufrufen Veranstaltungen im Abschnitt zur Erläuterung der Protected Audience API.

Makros

Die renderUrl, die auf das Protected Audience API-Creative verweist, können Folgendes enthalten: ein oder mehrere Platzhalter, sogenannte Makros. 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 erweitert, wenn die DSGVO nicht gilt, oder zu 1, wenn die DSGVO gilt. Dokumentation ansehen
`${GDPR_CONSENT_XXXX}`	Wird in die Transparenz und 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}`	Wird erweitert auf die zusätzlichen Einwilligungsstring (AC-String), der der Anfrage zugeordnet ist.
`${AD_WIDTH}, ${AD_HEIGHT)`	Mit diesen Makros werden Breite und Höhe der Anzeigenfläche eingefügt.
`${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}`	Makro mit Käufersignalen zum Rendering 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 Fügen Sie ein `_OPTIONAL_SUFFIX` ein, um bis zu drei verschiedene Signalwerte rendern.

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 Google zum Zählen von Impressionen in der Protected Audience API verwendet, browserinterne Auktionen können sich vom Ereignis unterscheiden, das für die Zählung verwendet wird. Impressionen nach seinen RTB-Käuferpartnern, kann die Anzahl der Impressionen abweichen.

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

Zuordnung der abrechenbaren Impressionen

Die gesamten Ausgaben eines Bieters aus Browser-Auktionen von Protected Audience betragen die einem einzelnen Bieterkonto zugeordnet sind, basierend auf der Zuordnung Ursprünge des Gruppeninhabers, die für den Bieter konfiguriert wurden. Die Aufteilung von Ausgaben auf verschiedene Untergeordnete Nutzerkonten eines Bieters werden nicht unterstützt.

Tagesbudgetobergrenze

Während des Protected Audience API-Tests hat jedes Konto eine Ausgabenlimit für das Tagesbudget der Protected Audience API. Die tägliche Budgetobergrenze begrenzt das Risiko in der Auktionsumgebung des Browsers besser geeignet ist. Sobald die tägliche Budgetobergrenze erreicht ist, Konto keine Gebotsanfragen mehr für Protected Audience.

Mit dem Konto können Sie weiterhin an serverseitigen kontextbezogenen Auktionen teilnehmen, nachdem die Protected Audience-Grenze erreicht ist. Beispiel: Ein Bieterkonto, das Möglicherweise erhält die Protected Audience-Begrenzung eine Gebotsanfrage mit auction_environment = SERVER_SIDE_AUCTION (OpenRTB: 0), auch wenn die Gebotsanfrage für eine Protected Audience-Auktion ab.

Feedback in Echtzeit und Mindestgebot, um erfolgreich zu sein

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. Jeder Käufer einer Interessengruppe, der von einem Bieter für eine Gebotsantwort ein Feedback-Objekt erhält, unabhängig davon, wie viele Gebote, die der Käufer einer Interessengruppe 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 Interessengruppenkäufers.
Das Mindestgebot, das der Käufer einer Interessengruppe gewinnen muss, um den für die gesamte Auktion.
Das zu gewinnende Mindestgebot für den Käufer einer Interessengruppe, um das das höchste Gebot von der serverseitigen Komponente der Gesamtauktion aus.
Der Statuscode des Käufers der Interessengruppe. Mögliche Statuscodes sind definiert in interest-group-buyer-status-codes.txt.

Weitere Informationen finden Sie in der Protokolldokumentation zu RTB-Funktion in Authorized Buyers und OpenRTB-Erweiterungen für die jeweiligen Feldnamen.

Benachrichtigung über Gebotsfeedback

Chrome bietet eine vorübergehende Fehlerbehebung API für die Protected Audience API, mit der Sie in Ad Manager Server-zu-Server-Fehlerbehebungsbenachrichtigungen, die Feedback zu einem geschützten Gebot für die Zielgruppe 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 der Protected Audience-Auktion weiter. Die folgenden Makros sind unterstützt:

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

Hier sehen Sie ein Beispiel für eine statische URL, die ein Bieter seinem Account Manager bereitstellen 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 über Gebotsfeedback ist eine vorübergehende Funktion, die auf der temporäre ForDebuggingOnly API.

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. Teilen Sie Ihrem Account Manager während der Integration mit, ob Sie vorhaben, PLTD, da zusätzliche Ressourcen und Konfigurationen 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

Um mit Anzeigen auf Produktebene zu bieten (Anzeigen, die aus mehreren Teilen bestehen) in Protected Audience API-Auktionen die folgenden Anforderungen:

Fügen Sie den Abfrageparameter &pltd=True in die renderUrl für die der Komponentenanzeige (auch als renderUrl auf oberster Ebene bezeichnet) aus, renderUrls auf oberster Ebene bei der Creative-Überprüfung unterscheiden können.
Ein repräsentatives Creative rendern, wenn der Container der Komponentenanzeige Creative-Überprüfung durch Google abgerufen. 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 mit der Interessengruppe.
Implementieren Sie generateBid() und reportWin().
Ursprünge für Interessengruppeninhaber auswählen und zum Authorized Buyers-Konto hinzufügen Konto.
- Die Ursprünge des Interessengruppeninhabers müssen mit den Ursprüngen übereinstimmen, in denen die generateBid()-Funktionen werden gehostet.
- 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 über die Schaltfläche Creatives API hinzu.
Optional: Richten Sie die Endpunkte für Trusted Bidding-Signale ein.
Optional: Richten Sie eine Werbetreibenden-Testseite ein, auf der Google-Entwickler ihren Browser mit den Interessengruppen, die den Käufern Ihrer Interessengruppe gehören, Ursprung. So können wir Protected Audience-Auktionen manuell auslösen.
(Optional) Aktivieren Sie Echtzeit-Feedback zu Ihrem Konto, um Feedback zu erhalten. Käufer von Interessengruppen, die in eine Protected Audience API aufgenommen werden sollen Auktion.
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. Siehe Feedback zu Geboten finden Sie weitere Informationen.

Testphasen

Phase 1: Manueller Test

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

Sie verwenden 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 Datenschutz testen Sandbox ein.
Creative mithilfe von Echtzeitgeboten zur Freigabe einreichen API hinzu.
Auf der Seite des vom Bieter bereitgestellten Werbetreibenden einen Browser zum Bieter hinzufügen Interessengruppe.
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

Die Interessengruppe im Browser muss hoch genug bieten, um die Auktion zu gewinnen, mit herkömmlichen serverseitigen Geboten konkurrieren. Google bietet auch eine Publisher-Testseite für jeden Partner, auf der nur der entsprechende Partner an der Auktion teilnehmen können. Es ist vielleicht einfacher, In-Browser-Auktionen auf einer partnerspezifischen Seite
Gehen Sie so vor:
1. Die erwartete erfolgreiche Anzeige wird gerendert.
2. Das Auktionsergebnis wird serverseitig gesendet, d. h., der Bieter gewinnt. erhält einen Ping von reportWin().
3. Die Konsole der Publisher-Testseite protokolliert für jedes Gebot eine Meldung zur Fehlerbehebung mit die folgenden Informationen: <ph type="x-smartling-placeholder">
  - renderUrl: Die Rendering-URL des Gebots.
  - interestGroupOwner: Der Inhaber der Interessengruppe des Gebots.
  - 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 eine kleine Menge an Live-Traffic für Protected Audience zu Auktionen. Dann müssen Google und der Partner nicht mehr manuell Protected Audience-Auktion ab. 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 reichen Sie ein Ticket über den Authorized Buyers- Hilfe, sobald Sie bereit sind. Google aktiviert das Konto für diese Phase.

Phase 3: Rendering-Test

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. Bei Google gibt es nur wenige Zugriffe Zielgruppenauktionen können durchgeführt werden und gerendert. Teilnehmende Bieter Gebote im Browser mit den herkömmlichen Gebote.

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

Parallelisierung ist eine Optimierung, bei der die Latenz der End-to-End-Auktion um die kontextbezogene Anzeigenanfrage parallel zu den Anfragen an die Vertrauenswürdige Server des Käufers in trustedBiddingSignalsUrl angegeben.

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 noch nicht unterstützt in parallelen Auktionen.

Zusammenfassung des Bereitstellungsablaufs

Zusammenfassung des parallelen Auktionsablaufs: Flussdiagramm

Eignung für Käufer auf einer Interessengruppe auf dem Gerät

Bei parallelen Auktionen erfolgt der Aufruf von navigator.runAdAuction vor wird die kontextbezogene Anzeigenantwort zurückgegeben. 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. Seit interestGroupBuyers wird vor der kontextbezogenen Anzeigenantwort übergeben. Kontextbezogene Anzeigenantwort (einschließlich Gebotsantworten) können nicht zur Auswahl der Käufer verwendet werden, die an der parallelen Auktion teilnehmen. für die jeweilige Anfrage. 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 Interessengruppen-Käufer basiert, Google führt nicht immer eine parallele Auktion durch, da der Parallelisierungs-Cache kann leer oder abgelaufen sein. Wenn der Cache leer oder abgelaufen ist, führt Google eine standardmäßigen, nicht parallelen Protected Audience API-Auktionen und nutzt die Absicht des Käufers, an der nicht parallelen Auktion teilnehmen, um den Käufer-Cache für Interessengruppen aufzubauen.
Wenn für den aktuellen Publisher mindestens ein Käufer für einen beliebigen Bieter im Cache gespeichert ist führt Google ein paralleles Auktion, die in der Gebotsanfrage angegeben wird:
- 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 keine bestimmte Käuferquelle in kann dieser Käufer nicht zum aktuellen On-Device- Auktion. Dies wird durch eine Anfrage mit parallelized=True angezeigt, bei der kein ParallelAuctionBuyer-Eintrag für eine bestimmte Käuferquelle einer Interessengruppe. Bei Bietern, die Interesse zeigen, indem sie gültige und InterestGroupBuyer für die Gebotsantwort(en) den entsprechenden Interessengruppen-Käufer Ursprüngen, die dem Cache hinzugefügt wurden und für für zukünftige parallelisierte Anfragen vom selben Browser und von derselben Domain. Absicht, an Auktionen für Interessengruppen teilzunehmen können 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.