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:
- 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 Feldinterest_group_bidding
zurück. Wenn der Bieterinterest_group_bidding
nicht angibt, gibt Google den Ursprung des Bieters in „interestGroupBuyers
“ in die Auktion aufnehmen Konfiguration. Die Gebotsantwort kann auchinterest_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 zuvorinterest_group_bidding
zurückgegeben haben alsinterestGroupBuyers
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 dietrustedBiddingSignalsUrl
, 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 bereitgestelltenper_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 undreportWin()
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 verwendetenrenderUrl
übereinstimmen Interessengruppen-Anzeigenauktion. - Jede
renderUrl
darf nur einen einzelnen Werbetreibenden oder eine einzelne Werbung repräsentieren. Kampagne. Eine bestimmterenderUrl
kann nicht zum Rendern von Anzeigen im Namen von verwendet werden: für mehrere Werbetreibende. JederrenderUrl
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 AuktionenON_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">
- </ph>
BidRequest.adslot.interest_group_auction.width
BidRequest.adslot.interest_group_auction.height
- OpenRTB:
<ph type="x-smartling-placeholder">
- </ph>
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
: LeerperBuyerSignals
: 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
: Musstrue
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.dsaadrender
fü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 Creatives mit dem Makro ${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 |
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 undBidRequest.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 FunktiongenerateBid()
.%%RENDER_URL%%
: Die Rendering-URL des Creatives.%%STATUS%%
: Ein Statuscode, wenn das Gebot innerhalb vonscoreAd()
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 dierenderUrl
für die der Komponentenanzeige (auch alsrenderUrl
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()
undreportWin()
. - 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.
- Die Ursprünge des Interessengruppeninhabers müssen mit den Ursprüngen übereinstimmen, in denen die
- 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
undchrome://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:
- Die erwartete erfolgreiche Anzeige wird gerendert.
- Das Auktionsergebnis wird serverseitig gesendet, d. h., der Bieter gewinnt.
erhält einen Ping von
reportWin()
. - Die Konsole der Publisher-Testseite protokolliert für jedes Gebot eine Meldung zur Fehlerbehebung mit
die folgenden Informationen:
<ph type="x-smartling-placeholder">
- </ph>
renderUrl
: Die Rendering-URL des Gebots.interestGroupOwner
: Der Inhaber der Interessengruppe des Gebots.accepted
: Dieses Feld hat den Werttrue
, wenn das Gebot angenommen wurde, undfalse
. Das Gebot wurde vonscoreAd()
abgelehnt.externalBidStatus
: Statuscode, wenn das Gebot innerhalb vonscoreAd()
. 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:
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
- Google RTB-Protokoll:
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
- Google RTB-Protokoll:
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 keinParallelAuctionBuyer
-Eintrag für eine bestimmte Käuferquelle einer Interessengruppe. Bei Bietern, die Interesse zeigen, indem sie gültige undInterestGroupBuyer
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
- Google RTB-Protokoll:
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.