Eine Echtzeitgebotsinteraktion beginnt, wenn Google eine Gebotsanfrage an Ihre Anwendung sendet. In diesem Leitfaden wird erläutert, wie Sie Ihre Anwendung für die Verarbeitung der Gebotsanfrage codieren.
Analyseanfrage
Google sendet eine Gebotsanfrage als seriellen Protokollpuffer, der als binäre Nutzlast einer HTTP-POST-Anfrage angehängt ist. Content-Type ist auf application/octet-stream gesetzt. Ein Beispiel finden Sie unter Beispiel für eine Gebotsanfrage.
Sie müssen diese Anfrage in eine Instanz der BidRequest-Nachricht parsen. BidRequest ist in realtime-bidding.proto definiert, das auf der Seite Referenzdaten abgerufen werden kann. Sie können die Nachricht mit der Methode ParseFromString() in der generierten Klasse für BidRequest parsen. Mit dem folgenden C++-Code wird beispielsweise eine Anfrage bei einer POST-Nutzlast in einem String geparst:
string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
// Process the request.
}
Sobald Sie die BidRequest haben, können Sie damit als Objekt arbeiten und die benötigten Felder extrahieren und interpretieren. Zum Beispiel in C++:
for (int i = 0; i < bid_request.adslot_size(); ++i) {
const BidRequest_AdSlot& adslot = bid_request.adslot(i);
// Decide what to bid on adslot.
}
Einige der mit einem BidRequest gesendeten Informationen wie die Google User-ID, die Sprache oder der geografische Standort sind nicht immer verfügbar. Wenn Sie
Pre-Targeting-Anzeigengruppen verwenden, in denen Informationen verwendet werden, die für eine bestimmte Impression unbekannt sind, stimmen diese Anzeigengruppen nicht überein. Wenn die fehlenden Informationen für die Pre-Targeting-Bedingungen keine Rolle spielen, werden Gebotsanfragen ohne diese Informationen gesendet.
Informationen zur Pre-Targeting-Anzeigengruppe sind in der Gruppe MatchingAdData für jeden AdSlot verfügbar. Sie enthält die erste übereinstimmende Anzeigengruppen-ID der Pre-Targeting-Anzeigengruppe, die Google zum Senden der Gebotsanfrage aufgefordert hat. Dies sind die Anzeigengruppen und Kampagnen, die Ihnen in Rechnung gestellt werden, wenn Ihre Antwort die Auktion für die Impression gewinnt. Unter bestimmten Umständen müssen Sie die billing_id für die Attribution in der BidResponse.AdSlot explizit angeben, z. B. wenn BidRequest.AdSlot mehr als eine matching_ad_data hat.
Weitere Informationen zu den Einschränkungen für die Inhalte des Gebots finden Sie in der realtime-bidding.proto.
Wörterbuchdateien
Die Gebotsanfrage verwendet Kennungen, die in Wörterbuchdateien definiert werden und auf der Seite Referenzdaten verfügbar sind.
URL-Makros für Gebote
Optional können einige Felder von BidRequest in die URL eingefügt werden, die in der HTTP-POST-Anfrage verwendet wird. Dies ist beispielsweise nützlich, wenn Sie ein einfaches Frontend verwenden, das mithilfe eines Werts aus der Anfrage das Load-Balancing über mehrere Back-Ends verteilt. Wenden Sie sich an Ihren Technical Account Manager, um Unterstützung für neue Makros anzufordern.
Macro
Beschreibung
%%GOOGLE_USER_ID%%
Ersetzt durch google_user_id aus BidRequest. Beispielsweise wird die Bieter-URL
Das Ergebnis entspricht der Android-App slither.io.
Open Bidding-Felder
Gebotsanfragen, die an Bieter auf Anzeigenplattform und im Netzwerk gesendet werden, die Open Bidding nutzen, ähneln denen von Authorized Buyers, die Standard-Echtzeitgebote verwenden. Open Bidding-Kunden erhalten eine geringe Anzahl zusätzlicher Felder. Für einige der vorhandenen Felder gibt es möglicherweise alternative Verwendungszwecke. Dazu gehören:
OpenRTB
Authorized Buyers
Details
BidRequest.imp[].ext.dfp_ad_unit_code
BidRequest.adslot[].dfp_ad_unit_code
Enthält den Ad Manager-Netzwerkcode des Publishers gefolgt von der Anzeigenblockhierarchie, getrennt durch Schrägstriche.
Zum Beispiel würde dies mit einer ähnlichen Formatierung wie /1234/cruises/mars angezeigt werden.
BidRequest.user.data[].segment[]
BidRequest.adslot[].exchange_bidding.key_value[]
Wiederholte Schlüssel/Wert-Paare, die vom Publisher an den Anzeigenplattform-Bieter gesendet werden
Du kannst feststellen, dass die Werte Schlüssel/Wert-Paare sind, die vom Publisher gesendet werden, wenn BidRequest.user.data[].name auf “Publisher Passed” gesetzt ist.
Zulässige Anbieter deklarieren
Technologieanbieter, die Dienstleistungen wie Recherche, Remarketing und Ad Serving anbieten, können bei der Interaktion zwischen Käufern und Verkäufern eine Rolle spielen. Nur Anbieter, die von Google für die Teilnahme an Authorized Buyers-Interaktionen geprüft wurden, sind zulässig.
Damit Sie die BidRequest verstehen und die BidResponse erstellen können, müssen Sie die zwei verschiedenen Möglichkeiten zur Deklaration von Technologieanbietern kennen:
Andere Anbieter können nur teilnehmen, wenn sie sowohl in BidRequest als auch in BidResponse deklariert sind:
In der BidRequest gibt das Feld allowed_vendor_type an, welche Anbieter der Verkäufer zulässt. Anbieter, die im Feld allowed_vendor_type der BidRequest gesendet werden, sind in der Vendors.txt-Wörterbuchdatei aufgeführt.
Im BidResponse gibt das Feld vendor_type an, welche dieser zulässigen Anbieter der Käufer verwenden möchte.
Beispiel für eine Gebotsanfrage
Die folgenden Beispiele sind für Menschen lesbare Beispiele der Protobuf- und JSON-Anfragen.
Zum Konvertieren der Gebotsanfrage in eine Binärform, wie sie dies von der POST-Nutzlast in einer echten Anfrage wären, können Sie Folgendes tun (in C++). Dies gilt jedoch nicht für OpenRTB JSON.
string text_format_example = /* example from above */;
BidRequest bid_request;
if (TextFormat::ParseFromString(text_format_example, &bid_request)) {
string post_payload;
if (bid_request.SerializeToString(&post_payload)) {
// post_payload is a binary serialization of the protocol buffer
}
}
Remarketing
Authorized Buyers übergibt eine ID für mobile Werbung in Gebotsanfragen von einer mobilen App. Die mobile Werbe-ID kann eine iOS-IDFA oder
Werbe-ID für Android sein, die über das %%EXTRA_TAG_DATA%%-Makro im JavaScript-Tag gesendet wird, das von Authorized Buyers verwaltet wird.
Mit dem Makro %%ADVERTISING_IDENTIFIER%% können Käufer beim Impressions-Rendering die iOS-IDFA oder die Werbe-ID von Android erhalten. Sie gibt einen verschlüsselten Proto-Zwischenspeicher MobileAdvertisingId wie %%EXTRA_TAG_DATA%% zurück:
Mithilfe von Werbe-IDs, die Sie beim Rendern von Impressionen erfasst haben, können Sie Nutzerlisten aus mobilen Werbe-IDs erstellen. Sie können auf Ihrem oder
unserem Server verwaltet werden. Zum Erstellen von Nutzerlisten auf den Google-Servern
kannst du unsere Bulk-Upload-Funktion nutzen.
Wenn die mobile Werbe-ID mit einer Nutzerliste übereinstimmt, können Sie sie zum Remarketing verwenden.
Feedback in Echtzeit
Echtzeitfeedback ist für Authorized Buyers sowie Anzeigenplattformen und Netzwerke verfügbar, die Open Bidding verwenden.
Feedback zu Gebotsantworten wird in der nachfolgenden Gebotsanfrage sowohl für das AdX-Protokoll als auch für OpenRTB unterstützt. Bei OpenRTB wird er in BidRequestExt gesendet.
Zusätzlich zu den Standardfeldern, die im Feedback zu Gebotsantworten gesendet werden, können Sie in AdX Proto oder OpenRTB auch benutzerdefinierte Daten in der Gebotsantwort senden. Verwenden Sie dazu ein event_notification_token, das im BidResponse zurückgegeben wird. Die event_notification_token sind beliebige Daten, die nur dem Bieter bekannt sind und bei der Fehlerbehebung hilfreich sein können, z. B. eine neue Targeting-ID oder Gebots-ID, die eine neue Taktik repräsentiert, oder Metadaten, die mit dem Creative verknüpft sind, das nur dem Bieter bekannt ist. Weitere Informationen finden Sie unter Protokollzwischenspeicher für OpenRTB-Erweiterungen für RTB und AdX Proto für AdX.
Wenn Authorized Buyers eine Gebotsanfrage an einen Bieter sendet, antwortet der Bieter mit einer BidResponse. Wenn für den Bieter das Echtzeitfeedback aktiviert ist, wird in einer nachfolgenden Gebotsanfrage über Authorized Buyers in einer BidResponseFeedback-Nachricht Feedback zur Antwort gesendet (siehe unten):
message BidResponseFeedback {
// The unique id from BidRequest.id
optional bytes request_id = 1;
// The index of the BidResponse_Ad if there was more than one. The index
// starts at zero for the first creative.
optional int32 creative_index = 2;
// The status code for the ad. See creative-status-codes.txt in the
// technical documentation for a list of ids.
optional int32 creative_status_code = 3;
// If the bid won the auction, this is the price paid in your account
// currency. If the bid participated in the auction but was out-bid, this
// is the CPM that should have been exceeded in order to win. This is not
// set if the bid was filtered prior to the auction, if the publisher or
// winning bidder has opted out of price feedback or if your account has
// opted out of sharing winning prices with other bidders. For first-price
// auctions, minimum_bid_to_win is populated instead of this field.
optional int64 cpm_micros = 4;
// The minimum bid value necessary to have won the auction, in micros of
// your account currency. If your bid won the auction, this is the second
// highest bid that was not filtered (including the floor price). If your
// bid did not win the auction, this is the winning candidate's bid. This
// field will only be populated if your bid participated in a first-price
// auction, and will not be populated if your bid was filtered prior to the
// auction.
optional int64 minimum_bid_to_win = 7;
// The minimum bid value necessary to have won the server-side component of
// the overall auction given that there was also an interest group bidding
// component to the overall auction which ran using the Protected Audience
// API. The value is expressed in CPM micros of the buyer account currency.
// The minimum bid to win for the overall auction, including bids from the
// server-side and the on-device interest group components, is populated in
// the minimum_bid_to_win field of the same BidResponseFeedback object.
optional int64 server_side_component_minimum_bid_to_win = 16;
// Billable event rate multiplier that was applied to this bid during
// ranking. The adjustment reflects the likelihood that your bid would
// generate a billable event (namely, the ad renders successfully) if it won
// the auction, relative to the probability that other bids generate a
// billable event if they won the auction. This adjustment can be larger or
// smaller than 1. This affects the final ranking in the auction only; in
// particular, this multiplier does not affect the payment or whether the
// bid clears any floor price.
optional float billable_event_rate_bid_adjustment = 15 [default = 1];
// When a publisher uses an RTB auction and waterfall-based SDK mediation on
// the same query, the winner of the real-time auction must also compete in
// a mediation waterfall (which is ordered by price) to win the impression.
// If the bid participated in the auction and there was no waterfall, the
// value of this field is 0. If the bid participated in the auction and
// there was a waterfall, the value of this field is a price representing a
// sample bid from the eligible mediation networks that were higher than the
// auction winner, weighted by expected fill rate. This field can be used
// in conjunction with minimum_bid_to_win to train bidding models. The CPM
// is in micros of your account currency.
optional int64 sampled_mediation_cpm_ahead_of_auction_winner = 10;
// Event notification token that was included in the bid response.
optional bytes event_notification_token = 5;
// Buyer creative ID that was included in the bid response.
optional string buyer_creative_id = 6;
// Possible types of bid response feedback objects.
enum FeedbackType {
FEEDBACK_TYPE_UNSPECIFIED = 0;
// Feedback for a bid that was submitted on a bid response.
BID_FEEDBACK = 1;
// Feedback for an interest group buyer submitted on a bid response to
// particpate in an interest group bidding component of the auction run
// using the Protected Audience API.
INTEREST_GROUP_BUYER_FEEDBACK = 2;
}
// The type of the BidResponseFeedback message. Google will send separate
// BidResponseFeedback objects for:
// a) Each bid submitted on a bid response
// b) Each buyer submitted on a bid response to particpate in an interest
// group bidding component of the auction run using the Protected Audience
// API.
optional FeedbackType feedback_type = 17;
// Origin of an interest group buyer that was included in the bid response.
// This field is populated only for feedback where a bidder opted in an
// interest group buyer to participate in the interest group bidding
// component of the overall auction run using the Protected Audience API.
// To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
// To learn more about interest group bidding and the Protected Audience
// API, see
// https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
optional string buyer_origin = 18;
// The status code for the submitted interest group buyer. This field is
// only populated in the feedback for an interest group buyer that a bidder
// requested to enter into the interest group auction through the bid
// response. Individual creative status codes of bids submitted by the buyer
// in the on-device interest group auction are not available. See
// https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
// for a list of interest group buyer status codes.
optional int32 interest_group_buyer_status_code = 19;
}
In dieser Meldung sollten Sie als erstes Feld bid_response_feedback.creative_status_code prüfen. Die Bedeutung des Codes finden Sie in der Datei
creative-status-codes.txt. Wenn Sie das Gebot gewinnen, können Sie das Preisfeedback deaktivieren. Weitere Informationen finden Sie unter Deaktivieren.
Das Echtzeit-Feedback enthält die Gebotsanfrage-ID und eine der folgenden Optionen:
Auktionsergebnis
Feedback in Echtzeit
Der Käufer hat kein Gebot abgegeben.
Nichts.
Der Käufer hat ein Gebot abgegeben, das vor der Auktion herausgefiltert wurde.
Nachdem Sie ein Gebot in einer Erstpreisauktion abgegeben haben, erhalten Sie in Echtzeit Feedback, einschließlich der Felder minimum_bid_to_win und sampled_mediation_cpm_ahead_of_auction_winner, falls das Gebot nicht aus der Auktion herausgefiltert wurde. Anhand dieser Signale kann Ihre Gebotslogik bestimmen, wie viel höher oder niedriger Ihr Gebot hätte sein können, um die Impression zu gewinnen.
minimum_bid_to_win: Das Mindestgebot, das hätte platziert werden können, um die Echtzeitgebotsauktion zu gewinnen. Wenn Sie die Auktion gewonnen haben, ist dies das niedrigste Gebot, das Sie hätten abgeben können, wenn Sie trotzdem noch gewinnen. Wenn Sie die Auktion verloren haben, ist dies das erfolgreiche Gebot.
sampled_mediation_cpm_ahead_of_auction_winner: Wenn andere Netzwerke in der Vermittlungskette vorhanden sind, ist der Wert in diesem Feld ein Preis, der ein Beispielgebot aus einem der qualifizierten Vermittlungsnetzwerke darstellt, das höher war als der Auktionsgewinner, gewichtet nach der erwarteten Ausführungsrate. Dieser Wert wird auf 0 gesetzt, wenn keines der Netzwerke in der Vermittlungskette erwartet wird oder wenn der Publisher die SDK-Vermittlung nicht verwendet.
Funktionsweise
Um die Berechnungen zu beschreiben, die zur Ermittlung der möglichen Werte für minimum_bid_to_win und sampled_mediation_cpm_ahead_of_auction_winner verwendet werden, müssen wir zuerst Folgendes definieren:
Im Folgenden werden die CPMs in der Vermittlungskette in absteigender Reihenfolge dargestellt:
\[C_1, C_2, …, C_n\]
Im Folgenden sehen Sie die entsprechenden Ausführungsraten für die CPMs in der Vermittlungskette:
\[f_1, f_2, …, f_n\]
Mit der folgenden Funktion werden der erwartete CPM und seine Wahrscheinlichkeit für das Element der Vermittlungskette \(i\)anhand der angegebenen Ausführungsrate ermittelt:
\(X_i = \{C_i\) mit Wahrscheinlichkeit \(f_i\); \(0\) mit Wahrscheinlichkeit \(1 - f_i\}\)
Die abschließend erfolgreiche Vermittlungskette ist:
\[\{C_1, C_2, …, C_K, W\}\]
wobei \(W\) das erfolgreiche Gebot ist und \(C_K > W >= C_{K+1}\)
Der Mindestpreis oder Mindestpreis ist mit \(F\)angegeben.
Das zweite Gebot ist mit \(R\)angegeben.
Berechnungen für den Auktionsgewinner
Field
Berechnung
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_ of_auction_winner
\(\{C_i\) mit Wahrscheinlichkeit \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Für \(1 <= i <= K\).
Berechnungen für Auktionsverlierer
Field
Berechnung
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_ of_auction_winner
\(max\{X_1, …, X_K\}\)
Beispiel mit einer einfachen Vermittlungskette
Angenommen, ein Publisher verwendet sowohl Echtzeitgebote als auch eine SDK-Vermittlungskette:
SDK-Vermittlungskette
Erwarteter CPM
Ausführungsrate
Netzwerk 1
\(C_1 = $3.00\)
\(f_1 = 5\%\)
Netzwerk 2
\(C_2 = $2.00\)
\(f_2 = 45\%\)
Netzwerk 3
\(C_3 = $0.50\)
\(f_3 = 80\%\)
Netzwerk 4
\(C_4 = $0.10\)
\(f_4 = 85\%\)
Als Ergebnis der RTB-Auktion wird Folgendes angenommen:
RTB-Auktion
CPM
Auktionsgewinner (W)
1,00 $
Zweitplatzierte Auktion (R)
0,05 $
Mindestpreis / Mindestpreis (F)
0,00 $
Gebot, mit dem die Auktion gewonnen wurde
Im Folgenden sehen Sie ein Beispiel dafür, wie Werte und Wahrscheinlichkeiten für minimum_bid_to_win und sampled_mediation_cpm_ahead_of_auction_winner für ein erfolgreiches Gebot berechnet werden.
Im Folgenden sehen Sie ein Beispiel dafür, wie Werte und Wahrscheinlichkeiten für minimum_bid_to_win und sampled_mediation_cpm_ahead_of_auction_winner für verlorene Gebote berechnet werden.
minimum_bid_to_win
Probability
\(max(F, W) = $1.00\)
\(100\%\)
sampled_mediation_cpm_ ahead_of_auction_winner
Probability
\(C_1 = $3.00\)
\(f_1 = 5\%\)
\(C_2 = $2.00\)
\((1-f_1) \cdot f_2 =~ 42.8\%\)
\(0\)
\((1-f_1) \cdot (1-f_2) =~ 52.2\%\)
Aufschlüsselung von Gebotsanfragen
Bei der Aufschlüsselung von Gebotsanfragen wird ein komplexer BidRequest in mehrere Gebotsanfragen umgewandelt, die an Ihre Anwendung gesendet werden. Weil identische IDs beibehalten werden (BidRequest.google_query_id im RTB-Protokoll von Authorized Buyers oder BidRequestExt.google_query_id im OpenRTB-Protokoll), können Sie ermitteln, welche Gebotsanfragen nach der Aufschlüsselung korrelieren.
Anzeigenformate
Für einige Umsatzchancen können mehrere Formate akzeptiert werden. Bei der Aufschlüsselung von Gebotsanfragen wird jedes Format in einer eigenen Gebotsanfrage gesendet, wobei Attribute wie zulässige Abrechnungs-IDs für das in der Anfrage angegebene Format relevant sind.
Gebotsanfragen mit den folgenden Formaten werden in verschiedene Gebotsanfragen aufgeschlüsselt:
Banner
Video
Audio
Nativ
Beispiel für die Aufschlüsselung von Anzeigenformaten
Das folgende Beispiel zeigt eine vereinfachte OpenRTB-JSON-Gebotsanfrage ohne Aufschlüsselung des Anzeigenformats im Vergleich zu einer entsprechenden Gruppe aufgeschlüsselter Anfragen:
Eine Werbechance für einen bestimmten Bieter kann neben der offenen Auktion auch auf verschiedene Dealtypen angewendet werden. Bei der Aufschlüsselung von Gebotsanfragen für Deals wird eine Gebotsanfrage für die offene Auktion und eine für jede Art von Festpreisangebot gesendet. In der Praxis können sich die Anzeigeneinschränkungen je nach Auktion und Festpreis unterscheiden. Beispielsweise erhält eine Gebotsfunktion für eine Werbechance, die sowohl in der offenen Auktion als auch bei einem Festpreisangebot zur Verfügung steht, unterschiedliche Gebotsanfragen für jede Art von Gebot, bei der Einschränkungen wie die maximale Anzeigendauer und die Frage, ob überspringbare Anzeigen zulässig sind, unterschiedlich sein können. Bei der Aufschlüsselung, die auf die Anzeigenchance angewendet wird, können Sie also die Anzeigeneinschränkungen für die offene Auktion und das Festpreisangebot leichter erkennen.
Maximale Dauer überspringbarer Videos
Das Protokoll und die OpenRTB-Implementierung von Google unterstützen die folgenden Felder für Videodauer und Überspringbarkeit:
Dauer
Dauer bis zum Überspringen
Überspringbarkeit
Google-Protokoll
max_ad_duration
skippable_max_ad_duration
video_ad_skippable
OpenRTB
maxduration
–
skip
Das bedeutet, dass zwar das Google-Protokoll eine detaillierte Angabe zur Dauer überspringbar und nicht überspringbar ist, die OpenRTB-Implementierung hat jedoch nur einen einzigen Wert für die maximale Dauer.
Vor der Aufschlüsselung von Gebotsanfragen wird der maxduration von OpenRTB auf den niedrigeren Wert der Felder max_ad_duration und skippable_max_ad_duration des Google-Protokolls gesetzt. Jetzt werden zwei separate Gebotsanfragen gesendet, wenn sich diese Werte unterscheiden: eine für maxduration für überspringbare und die andere für nicht überspringbare Empfehlungen.
Die folgenden Beispiele zeigen, wie eine Google-Protokollanfrage vor und nach der Gebotsaufschlüsselung in OpenRTB umgewandelt wird. Die entsprechende Google-Protokollanfrage hat für max_ad_duration den Wert 15 und für skippable_max_ad_duration den Wert 60.
Beispiel
max_ad_duration
skip (wahr ODER falsch)
Ursprüngliche Anfrage ohne Aufschlüsselung
15
true
Aufgeschlüsselte Anfrage 1: Nicht überspringbar
15
false
Aufgeschlüsselte Anfrage 2: Überspringbar
60
true
Gebotsanfragen werden nur aufgeschlüsselt, wenn die folgenden Bedingungen erfüllt sind:
Die Anfrage lässt Video zu.
Sowohl überspringbare als auch nicht überspringbare Videos sind zulässig. Die beiden maximalen Dauer unterscheiden sich in ihrem Wert.
Diese Anfrage kommt für private oder offene Auktionen infrage.
Das Bieterkonto hat aktive OpenRTB-Endpunkte.
Sie können diese Art der Aufschlüsselung deaktivieren, indem Sie sich an Ihren Technical Account Manager wenden.
Video pods
Gebotsanfragen für einen Videopod mit mehreren Empfehlungen werden aufgeschlüsselt, sodass jede Gebotsanfrage für eine einzelne Werbechance aus diesem Pod gilt.
Auf diese Weise können Sie für einen bestimmten Pod ein Gebot für mehrere Werbechancen abgeben.
Offene Messung
Mit Open Measurement können Sie Drittanbieter angeben, die unabhängige Mess- und Verifizierungsdienste für Anzeigen bereitstellen, die in mobilen App-Umgebungen ausgeliefert werden.
Sie können feststellen, ob ein Publisher Open Measurement in der Gebotsanfrage unterstützt. Prüfen Sie dazu, ob die Werbechance das Attribut OmsdkType:
OMSDK 1.0 aus den vom Publisher ausgeschlossenen Creative-Attributen ausschließt. Beim Authorized Buyers-Protokoll befindet sie sich unter BidRequest.adslot[].excluded_attribute. Beim OpenRTB-Protokoll befindet sie sich je nach Format unter dem Attribut battr für Banner oder Video.
Weitere Informationen zur Auswertung von Gebotsanfragen mit Open Measurement-Signalen finden Sie im Hilfeartikel Open Measurement SDK.
Beispiele für Gebotsanfragen
In den folgenden Abschnitten finden Sie Beispiele für Gebotsanfragen für verschiedene Anzeigentypen.
