Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Eine Echtzeitgebotsinteraktion beginnt, wenn Google eine Gebotsanfrage an
Ihre Anwendung. In diesem Leitfaden wird erläutert, wie Sie Ihre Anwendung für
die Gebotsanfrage verarbeiten.
Protobuf-Anfrage parsen
Google sendet eine Gebotsanfrage als serialisierten Protokollpuffer, der als das
binäre Nutzlast einer HTTP-POST-Anfrage. Content-Type ist auf application/octet-stream festgelegt. Ein Beispiel finden Sie unter Beispiel für eine Gebotsanfrage.
Du musst diese Anfrage in eine Instanz der BidRequest-Nachricht parsen. Je nach ausgewähltem Protokoll wird BidRequest entweder in openrtb.proto oder in der veralteten realtime-bidding.proto definiert, die auf der Seite Referenzdaten verfügbar ist. Sie können die Nachricht mit der ParseFromString()-Methode in der generierten Klasse für die BidRequest parsen. Der folgende C++-Code parset beispielsweise eine Anfrage, die eine POST-Nutzlast in einem String enthält:
string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
// Process the request.
}
Sobald Sie das BidRequest haben, können Sie es als
-Objekt zu extrahieren und die benötigten Felder zu extrahieren und zu interpretieren. In C++ könnte das Durchlaufen von Deals in einer OpenRTB-Gebotsanfrage beispielsweise so aussehen:
for (const BidRequest::Imp::Pmp::Deal& deal : pmp.deals()) {
DoSomething(deal.id(), deal.wseat());
}
Abrechnungs-IDs
Sie erhalten eine Gebotsanfrage, wenn das Anzeigeninventar eines Publishers auf eine oder mehrere Ihrer Pre-Targeting-Konfigurationen ausgerichtet ist. BidRequest.imp.ext.billing_id
mit den Abrechnungs-IDs aller berechtigten Käufer gefüllt und
Pre-Targeting-Konfigurationen. Außerdem
Angebot
Inventar die Abrechnungs-IDs, die mit dem entsprechenden Käufer verknüpft sind,
mit BidRequest.imp.pmp.deal.ext.billing_id. Nur Abrechnungs-IDs von
in der Gebotsanfrage enthaltene Käufer können beim Abgeben eines Gebots angegeben werden.
Wenn die Gebotsanfrage mehrere Abrechnungs-IDs enthält, müssen Sie angeben,
Abrechnungs-ID des Käufers, dem Sie Ihr Gebot zuordnen möchten
BidResponse.seatbid.bid.ext.billing_id.
Wörterbuchdateien
Die Gebotsanfrage verwendet IDs, die in Wörterbuchdateien definiert sind. Diese IDs sind
die in den Referenzdaten verfügbar sind.
Seite.
Makros für Gebots-URL des Google RTB-Protokolls
Optional können einige Felder von BidRequest in
Die in der HTTP-POST-Anfrage verwendete URL. Das ist beispielsweise nützlich, wenn Sie ein schlankes Frontend verwenden, das mithilfe eines Werts aus der Anfrage das Load Balancing über mehrere Back-Ends hinweg durchführt. Wenden Sie sich an Ihren Technical Account Manager, um Unterstützung für
neue Makros zu erstellen.
Macro
Beschreibung
%%GOOGLE_USER_ID%%
Ersetzt durch den google_user_id aus dem BidRequest. Beispielsweise wird die Bieter-URL
Das Ergebnis entspricht der Android-App.
slither.io.
Open Bidding-Felder
Gebotsanfragen, die an Anzeigenplattformen und Netzwerkbieter gesendet werden, die Open Bidding nutzen, ähneln denen von Authorized Buyers, die standardmäßige Echtzeitgebote verwenden. Open Bidding-Kunden erhalten einige zusätzliche Felder. Einige vorhandene Felder können auch anders verwendet werden. 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, durch Schrägstriche getrennt.
Die Ausgabe sollte mit einer Formatierung wie folgt aussehen:
/1234/cruises/mars
BidRequest.user.data[].segment[]
BidRequest.adslot[].exchange_bidding.key_value[]
Wiederholte Schlüssel/Wert-Paare, die vom Publisher an den Anzeigenplattform-Bieter gesendet werden.
Sie können feststellen, dass es sich bei den Werten um Schlüssel/Wert-Paare handelt, die vom
Publisher, wenn BidRequest.user.data[].name auf
“Publisher Passed”.
Zulässige Anbieter deklarieren
Technologieanbieter, die Dienstleistungen wie Recherche, Remarketing und Anzeigenbereitstellung anbieten, können eine Rolle bei der Interaktion zwischen Käufern und Verkäufern spielen. Nur Anbieter, die von Google für die Teilnahme an Authorized Buyers-Interaktionen überprüft wurden, sind zulässig.
Um die BidRequest zu verstehen und Ihre BidResponse zu erstellen, müssen Sie sich mit den beiden Möglichkeiten zur Deklarierung von Technologieanbietern vertraut machen:
Andere Anbieter können nur teilnehmen, wenn sie in der BidRequest deklariert sind:
Im BidRequest gibt das Feld BidRequest.imp.ext.allowed_vendor_type an, welche Anbieter der Verkäufer zulässt. Anbieter, die in der allowed_vendor_type gesendet werden, sind in der Wörterbuchdatei vendors.txt aufgeführt.
Beispiel für eine Gebotsanfrage
Die folgenden Beispiele stellen für Menschen lesbare Beispiele des Protobuf- und
JSON-Anfragen.
Um die Gebotsanfrage in ein Binärformat umzuwandeln, wie Sie es vom
POST-Nutzlast in einer echten Anfrage verwenden, können Sie Folgendes tun (in C++): Hinweis:
Das 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
}
}
Feedback in Echtzeit
Authorized Buyers können sich in Echtzeit Feedback
wie Anzeigenplattformen und
Netzwerke mit Open Bidding.
Feedback zur Gebotsantwort wird sowohl für OpenRTB als auch für das eingestellte Google RTB-Protokoll bei der nachfolgenden Gebotsanfrage unterstützt. Bei OpenRTB wird er gesendet in
BidRequest.ext.bid_feedback
Zusätzlich zu den Standardfeldern, die im Feedback zur Gebotsantwort gesendet werden, können Sie über das Feld BidResponse.seatbid.bid.ext.event_notification_token auch benutzerdefinierte Daten in der Gebotsantwort senden. event_notification_token ist ein beliebiger Datensatz, der nur dem Bieter bekannt ist und bei der Fehlerbehebung helfen kann. Beispiele: eine neue Ausrichtungs- oder Gebots-ID, die eine neue Taktik darstellt, oder Metadaten, die mit dem Creative verknüpft sind und nur dem Bieter bekannt sind. Weitere Informationen finden Sie im OpenRTB Extensions Protocol Buffer für OpenRTB oder im eingestellten Google RTB-Protokoll.
Wenn Authorized Buyers eine Gebotsanfrage an einen Bieter sendet, antwortet dieser
mit einem BidResponse. Wenn für den Bieter Feedback in Echtzeit aktiviert ist,
In einer darauffolgenden Gebotsanfrage sendet Authorized Buyers
Antwort auf eine BidFeedback-Nachricht:
message BidFeedback {
// The unique id from BidRequest.id.
optional string request_id = 1;
// 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 = 2;
// 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 double price = 3;
// The minimum bid value necessary to have the auction, in 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 double minimum_bid_to_win = 6;
// 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 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 BidFeedback object.
optional double sscminbidtowin = 14;
// 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 = 13 [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 your account currency.
optional double sampled_mediation_cpm_ahead_of_auction_winner = 8;
message EventNotificationToken {
// The contents of the token.
optional string payload = 1;
}
// The token included in the corresponding bid.
optional EventNotificationToken event_notification_token = 4;
// The creative ID included in the corresponding bid.
optional string buyer_creative_id = 5;
// 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 BidFeedback message. Google will send separate
// BidFeedback 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 feedbacktype = 15;
// 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 buyerorigin = 16;
// 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 igbuyerstatus = 17;
}
In dieser Nachricht sollten Sie zuerst das Feld bid_feedback.creative_status_code prüfen. Die Bedeutung des Codes finden Sie in creative-status-codes.txt. Wenn Sie das Gebot gewinnen, können Sie
aus dem Preisfeedback. Weitere Informationen finden Sie unter Anleitung für
deaktivieren.
Das Echtzeitfeedback enthält die Gebotsanfrage-ID und einen der folgenden Werte:
Auktionsergebnis
Feedback in Echtzeit
Der Käufer hat kein Gebot abgegeben.
Nichts.
Der Käufer hat ein Gebot abgegeben, das herausgefiltert wurde, bevor es die Auktion erreichte.
Nachdem Sie ein Gebot in einer Erstpreisauktion abgegeben haben, erhalten Sie
Feedback, einschließlich der minimum_bid_to_win und
sampled_mediation_cpm_ahead_of_auction_winner-Felder, wenn das Gebot
nicht aus der Auktion herausgefiltert. Anhand dieser Signale können Sie Ihr
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 abgegeben werden können, um die Echtzeitgebots-Auktion zu gewinnen. Wenn Sie die Auktion gewonnen haben,
das niedrigste Gebot, das Sie hätten abgeben können,
als Sie dennoch erfolgreich waren. Wenn Sie die Auktion verloren haben, ist dies das erfolgreiche Gebot.
sampled_mediation_cpm_ahead_of_auction_winner: Falls es
anderen Netzwerken in der Vermittlungskette,
Wert in diesem Feld ist ein Preis, der ein Beispielgebot aus einem der
geeignete Vermittlungsnetzwerke, die höher als der Auktionsgewinner waren, gewichtet
mit der erwarteten Ausführungsrate. Dieser Wert wird auf 0 gesetzt, wenn keines der Netzwerke im
die Vermittlungskette gefüllt ist, oder wenn der Publisher das SDK nicht verwendet
Vermittlung.
Funktionsweise
Um die Berechnungen zu beschreiben, mit denen die möglichen Werte für minimum_bid_to_win und sampled_mediation_cpm_ahead_of_auction_winner ermittelt werden, müssen wir zuerst Folgendes definieren:
Im Folgenden sind 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\]
Die folgende Funktion wird verwendet, um den erwarteten CPM und seine Wahrscheinlichkeit aus dem Element „Vermittlungskette“ \(i\)anhand der angegebenen Auslieferungsrate zu bestimmen:
\(X_i = \{C_i\) mit Wahrscheinlichkeit \(f_i\); \(0\) mit Wahrscheinlichkeit \(1 - f_i\}\)
Die endgültige Vermittlungskette, die den Zuschlag erhält, ist:
\[\{C_1, C_2, …, C_K, W\}\]
wobei \(W\) das erfolgreiche Gebot ist und \(C_K > W >= C_{K+1}\)
Der Mindestpreis wird mit \(F\)angegeben.
Das zweite Gebot wird mit \(R\)angegeben.
Berechnungen für den Auktionsgewinner
Feld
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
Feld
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\%\)
Bei einer RTB-Auktion wird Folgendes angenommen:
RTB-Auktion
CPM
Auktionsgewinner (W)
1,00 $
Zweitplatzierte Auktion (R)
0,05 $
Mindestpreis (F)
0 $
Gebot, mit dem die Auktion gewonnen wurde
Im Folgenden finden 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 einen erfolgreichen Gebot berechnet werden.
Im folgenden Beispiel wird gezeigt, wie Werte und Wahrscheinlichkeiten für minimum_bid_to_win und sampled_mediation_cpm_ahead_of_auction_winner für Gebote berechnet werden, die nicht berücksichtigt wurden.
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
Die Gebotsumwandlung beschreibt die Verarbeitung einer einzelnen komplexen BidRequest in mehrere Gebotsanfragen, die an Ihre Anwendung gesendet werden. Wenn eine Gebotsanfrage aufgeschlüsselt wird, können Sie ermitteln,
Teil des Originals waren, da sie in der
BidRequest.ext.google_query_id.
Die Aufschlüsselung von Gebotsanfragen ist standardmäßig aktiviert. Sie können sich aber an Ihr Konto wenden.
wenn Sie es deaktivieren möchten.
Anzeigenformate
Für einige Umsatzchancen sind mehrere Formate zulässig. Bei der Gebotsumwandlung wird jedes Format in einer separaten Gebotsanfrage gesendet, bei der Attribute wie berechtigte Abrechnungs-IDs für das in der Anfrage angegebene Format relevant sind.
Gebotsanfragen mit den folgenden Formaten werden in
unterschiedlichen Gebotsanfragen:
Banner
Video
Audio
Nativ
Beispiel für die Aufschlüsselung von Anzeigenformaten
Unten sehen Sie ein Beispiel für eine vereinfachte OpenRTB-Gebotsanfrage in JSON ohne Flattening des Anzeigenformats im Vergleich zu einer entsprechenden Gruppe von Flattening-Anfragen:
Eine Anzeigenbereitstellung für einen bestimmten Bieter kann neben der offenen Auktion auch für verschiedene Dealtypen gelten. Bei der Aufschlüsselung von Gebotsanfragen für Deals wird eine Gebotsanfrage für die offene Auktion und eine für jeden Festpreisdeal gesendet. In der Praxis können sich die Anzeigeneinschränkungen zwischen Auktionen und Festpreisen unterscheiden.
beispielsweise Dealtypen für eine bestimmte
Werbechance für Videoanzeigen, die für
sowohl für die offene Auktion als auch für ein Festpreisangebot gilt, erhält der Bieter
Gebotsanfragen für alle Anfragen, bei denen Einschränkungen wie die maximale Anzeigendauer und
überspringbare Anzeigen zulässig sind, können abweichen. Infolgedessen wurde die Aufschlüsselung auf die Anzeige angewendet.
können Sie die Einschränkungen
der Anzeigen für offene Auktionen
der Auktion und dem Festpreisangebot.
Maximale Dauer des überspringbaren Videos
Das Protokoll und die OpenRTB-Implementierung von Google unterstützen die folgenden Felder für die Videodauer und Überspringbarkeit:
Dauer
Dauer der überspringbaren Anzeige
Überspringbarkeit
Google-Protokoll
max_ad_duration
skippable_max_ad_duration
video_ad_skippable
OpenRTB
maxduration
–
skip
Das Google-Protokoll kann also
ein detailliertes, überspringbares
und nicht überspringbare Anzeigen
dauert, hat die OpenRTB-Implementierung nur eine
Wert für die maximale Dauer.
Vor der Bieterflacherung wurde maxduration in OpenRTB auf den niedrigeren Wert der Felder max_ad_duration und skippable_max_ad_duration des Google-Protokolls gesetzt. Dieses Verhalten wurde geändert zu
zwei separate Gebotsanfragen gesendet werden, wenn diese Werte unterschiedlich sind: eine für
maxduration für überspringbare und andere für nicht überspringbare Anzeigen
Werbechancen.
Die folgenden Beispiele zeigen, wie eine Google-Protokollanfrage
vor und nach der Aufschlüsselung der Gebote in OpenRTB. Die entsprechende Google-Protokollanfrage hat einen max_ad_duration von 15 und einen skippable_max_ad_duration von 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
Die Aufschlüsselung von Gebotsanfragen nach der Dauer überspringbarer Videos erfolgt nur, wenn folgende Bedingungen erfüllt sind:
Die Anfrage lässt Video zu.
Sowohl überspringbare als auch nicht überspringbare Videos sind zulässig. Die beiden maximalen Dauern unterscheiden sich.
Diese Anfrage ist für private oder offene Auktionen geeignet.
Das Bieterkonto hat aktive OpenRTB-Endpunkte.
Wenn Sie diese Art der Aufschlüsselung deaktivieren möchten, wenden Sie sich an Ihren Technical Account Manager.
Video-Pods
Gebotsanfragen für einen Video-Pod mit mehreren Werbechancen werden aufgeschlüsselt, sodass jede Gebotsanfrage für eine einzelne Werbechance aus diesem Pod gilt.
So können Sie auf mehrere Anzeigenflächen für einen bestimmten Anzeigen-Pod bieten.
Open Measurement
Mit Open Measurement können Sie Drittanbieter angeben, die unabhängige Analyse- und Überprüfungsdienste für Anzeigen in mobilen Apps anbieten.
Ob ein Publisher Open Measurement in der Gebotsanfrage unterstützt, können Sie daran erkennen, ob das Attribut OmsdkType:
OMSDK 1.0 in der Liste der vom Publisher auszuschließenden Creative-Attribute in der Anzeigenbereitstellung ausgeschlossen ist. Sie finden sie je nach Format unter dem Attribut battr für Banner oder Video.
Weitere Informationen zur Auswertung von Gebotsanfragen mit offenen
Messsignale, siehe den Artikel Open Measurement
SDK-Hilfeartikel.
Beispiel für Gebotsanfragen
In den folgenden Abschnitten finden Sie Beispielgebotsanfragen für verschiedene Anzeigentypen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-10-16 (UTC)."],[],[]]
