Anfrage verarbeiten

Eine Echtzeitgebotsinteraktion beginnt, wenn Google eine Gebotsanfrage an Ihre Anwendung sendet. In diesem Leitfaden erfahren Sie, wie Sie Ihre Anwendung so programmieren, dass sie die Gebotsanfrage verarbeitet.

Anfrage parsen

Google sendet eine Gebotsanfrage, die entweder im OpenRTB-JSON- oder im Protobuf-Format serialisiert ist und als Nutzlast einer HTTP-POST-Anfrage angehängt ist. Das empfangene Format hängt von der Konfiguration Ihres Endpunkts ab. Beispiel für eine Gebotsanfrage

Du musst diese Anfrage parsen, um die serialisierte BidRequest zu erhalten. Wenn Sie das Protobuf-Format verwenden, müssen Sie openrtb.proto und openrtb-adx.proto von der Seite Referenzdaten herunterladen und damit eine Bibliothek generieren, mit der die BidRequest-Nachricht geparst werden kann. Im folgenden C++-Code wird beispielsweise eine Anfrage mit 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. 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 wird mit den Abrechnungs-IDs aller infrage kommenden Käufer und relevanten Konfigurationen für das Pretargeting ausgefüllt. Außerdem können Sie mit BidRequest.imp.pmp.deal.ext.billing_id die Abrechnungs-IDs für Deal-Inventar abrufen, die mit dem entsprechenden Käufer verknüpft sind. Beim Abgeben eines Gebots dürfen nur Abrechnungs-IDs von Käufern angegeben werden, die in der Gebotsanfrage enthalten sind.

Wenn die Gebotsanfrage mehrere Abrechnungs-IDs enthält, müssen Sie im Feld BidResponse.seatbid.bid.ext.billing_id die Abrechnungs-ID des Käufers angeben, dem Sie Ihr Gebot zuordnen möchten.

Wörterbuchdateien

Die Gebotsanfrage verwendet Kennungen, die in Wörterbuchdateien definiert sind. Diese sind auf der Seite Referenzdaten verfügbar.

URL-Makros für Bieter

Optional können einige Informationen aus der BidRequest mithilfe von Makros in Gebotsendpunkt-URLs eingefügt werden. Wenn Sie eine Endpunkt-URL mit einem oder mehreren Makros konfigurieren, werden diese Makros erweitert, wenn diese Informationen in der Gebotsanfrage vorhanden sind. Das kann beispielsweise dann nützlich sein, wenn Sie das Load Balancing basierend auf Informationen in der BidRequest ausführen möchten. Wenden Sie sich an Ihren Account Manager, um Unterstützung für neue Makros anzufordern.

MacroBeschreibung
%%GOOGLE_USER_ID%%

Wird durch die Google-Nutzer-ID in BidRequest.user.id ersetzt. Beispiel: Die Bieter-URL http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% wird bei der Anfrage durch eine URL wie http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl ersetzt.

Wenn die Google-Nutzer-ID unbekannt ist, wird der leere String ersetzt. Das Ergebnis sieht dann in etwa so aus:

http://google.bidder.com/path?gid=
%%HAS_MOBILE%%

Wird durch 1 ersetzt, um anzugeben, dass die Gebotsanfrage von einem Mobilgerät stammt, andernfalls durch 0. Das hängt vom Wert von BidRequest.device.devicetype ab. Mobilgeräte werden durch HIGHEND_PHONE (4) oder Tablet (5) gekennzeichnet.
%%HAS_VIDEO%%

Wird durch 1 ersetzt, um anzugeben, dass die Gebotsanfrage Videoinventar enthält, andernfalls durch 0. Das hängt davon ab, ob BidRequest.imp.video in der Gebotsanfrage ausgefüllt ist.
%%HOSTED_MATCH_DATA%%

Wird durch einen Wert ersetzt, der auf BidRequest.user.buyeruid basiert.

%%MOBILE_IS_APP%%

Wird durch 1 ersetzt, um anzugeben, dass die Gebotsanfrage sich auf Inventar für mobile Apps bezieht, andernfalls durch 0. Das hängt davon ab, ob BidRequest.app ausgefüllt ist.

Mobile App-ID anhand der Transaktions-URL ermitteln

Für Transaktionen von mobilen Apps werden URLs wie diese erfasst:

mbappgewtimrzgyytanjyg4888888.com

Verwenden Sie einen Base32-Decoder, um den fett formatierten Teil des Strings (gewtimrzgyytanjyg4888888) zu decodieren.

Sie können einen Online-Decoder verwenden, müssen aber die Buchstaben großschreiben und abschließende 8 durch =-Werte ersetzen.

So decodieren Sie diesen Wert: 

GEWTIMRZGYYTANJYG4======
 führt zu: 
1-429610587
 Der String 429610587 ist die App-ID für die iOS-App iFunny.

Ein weiteres Beispiel: Die gemeldete URL lautet: 

mbappgewtgmjug4ytmmrtgm888888.com
 Dekodierung dieses Werts: 
GEWTGMJUG4YTMMRTGM======
 führt zu: 
1-314716233
 Das Ergebnis 314716233 ist die App-ID für die iOS-App TextNow.

Namen der mobilen App anhand der Transaktions-URL ermitteln

Hier ein Beispiel für das Abrufen des App-Namens. Die gemeldete URL lautet: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Dekodierung dieses Werts: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 führt zu: 
air.com.hypah.io.slither
 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 Details
BidRequest.imp.ext.dfp_ad_unit_code

Enthält den Ad Manager-Netzwerkcode des Publishers, gefolgt von der Anzeigenblockhierarchie, durch Schrägstriche getrennt.

Das würde beispielsweise so aussehen: /1234/cruises/mars.
BidRequest.user.data.segment

Wiederholte Schlüssel/Wert-Paare, die vom Publisher an den Bieter der Anzeigenplattform gesendet werden.

Wenn BidRequest.user.data.name auf “Publisher Passed” gesetzt ist, handelt es sich bei den Werten um vom Publisher gesendete Schlüssel/Wert-Paare.

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:

  1. Einige Anbieter müssen nicht deklariert werden. Sie sind in der Liste der Ad Manager-zertifizierten externen Anbieter aufgeführt.
  2. Andere Anbieter können nur teilnehmen, wenn sie in der BidRequest deklariert sind:
    • Unter 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 sind lesbare Beispiele für Protobuf- und JSON-Anfragen.

OpenRTB Protobuf

OpenRTB JSON

So wandeln Sie die Gebotsanfrage in eine binäre Form um, wie sie in der POST-Nutzlast einer echten Anfrage enthalten wäre (in C++). Hinweis: Dies gilt 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

Echtzeitfeedback ist für Authorized Buyers sowie für Anzeigenplattformen und Netzwerke verfügbar, die Open Bidding verwenden.

Anhand des Echtzeit-Feedbacks wird BidRequest.ext.bid_feedback basierend auf dem Ergebnis eines oder mehrerer zuvor abgegebener Gebote ausgefüllt. So können Sie Details wie den Gewinner der Auktion oder das Mindestgebot ermitteln, das erforderlich gewesen wäre, um die Auktion zu gewinnen. Wenden Sie sich an Ihren Account Manager, um Echtzeitfeedback zu aktivieren.

Zusätzlich zu den Standardfeldern, die im Feedback zur Gebotsanfrage gesendet werden, können Sie über das Feld BidResponse.seatbid.bid.ext.event_notification_token auch benutzerdefinierte Daten in der Gebotsanfrage 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 in der OpenRTB-Erweiterungs-Protokollpufferdatei.

Wenn Authorized Buyers eine Gebotsanfrage an einen Bieter sendet, antwortet dieser mit einer BidResponse. Wenn der Bieter Echtzeitfeedback aktiviert hat, sendet Authorized Buyers in einer nachfolgenden Gebotsanfrage Feedback zur Antwort in einer 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;

  // Deprecated. This field is not populated and will be removed after March,
  // 2025. 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 [deprecated = true];

  // The minimum bid value necessary to have won 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 didn't 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 das Preisfeedback deaktivieren. Weitere Informationen finden Sie unter Deaktivierung.

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. Der Creative-Statuscode (creative-status-codes.txt).
Der Käufer hat ein Gebot abgegeben, aber die Auktion verloren. Der Creative-Statuscode 79 (Übergebot in Auktion).
Der Käufer hat ein Gebot abgegeben, mit dem er die Auktion gewonnen hat. Der Abrechnungspreis und der Creative-Statuscode 1.

Bei einer App-Impression mit dem Creative-Statuscode 83 hat der App-Publisher möglicherweise eine Vermittlungsabfolge verwendet. Das Gewinnergebot musste daher mit anderer Nachfrage in der Passback-Abfolge des Publishers konkurrieren. Informationen zur Verwendung von sampled_mediation_cpm_ahead_of_auction_winner bei Geboten

Beispiel

Im Folgenden finden Sie ein Beispiel für Echtzeit-Feedback in unterstützten Protokollen:

OpenRTB Protobuf

OpenRTB JSON

Gebotsmodell für Erstpreisauktionen erstellen

Nachdem Sie ein Gebot in einer Erstpreisauktion abgegeben haben, erhalten Sie Echtzeitfeedback, einschließlich der Felder minimum_bid_to_win und sampled_mediation_cpm_ahead_of_auction_winner, sofern das Gebot nicht aus der Auktion herausgefiltert wurde. Anhand dieser Signale können Sie Ihre Gebotslogik so anpassen, dass Sie wissen, wie viel höher oder niedriger Ihr Gebot hätte sein müssen, 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, ist dies das niedrigste Gebot, das Sie hätten abgeben können, um die Auktion zu gewinnen. Wenn Sie die Auktion verloren haben, ist dies das erfolgreiche Gebot.
  • sampled_mediation_cpm_ahead_of_auction_winner: Wenn sich in der Vermittlungsabfolge weitere Netzwerke befinden, ist der Wert dieses Felds ein Preis, der ein Beispielgebot aus einem der infrage kommenden Vermittlungsnetzwerke darstellt, das über dem Gebotspreis des Auktionssiegers lag, gewichtet mit der erwarteten Auslieferungsrate. Dieser Wert wird auf „0“ gesetzt, wenn keines der Netzwerke in der Vermittlungskette voraussichtlich eine Auslieferung vornehmen wird oder der Publisher keine SDK-Vermittlung verwendet.

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 aufgeführt:
    \[C_1, C_2, …, C_n\]
  • Unten sehen Sie die entsprechenden Auslieferungsraten für die CPMs in der Vermittlungskette:
    \[f_1, f_2, …, f_n\]
  • Mit der folgenden Funktion wird der erwartete CPM und seine Wahrscheinlichkeit aus dem Element „Vermittlungskette“ \(i\)anhand der angegebenen Auslieferungsrate ermittelt:
    \(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 als \(F\)angegeben.
  • Das zweithöchste Gebot wird als \(R\)bezeichnet.
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 den Verlierer der Auktion
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\%\)
Network 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

Angenommen, die RTB-Auktion hat folgendes Ergebnis:

RTB-Auktion CPM
Gewinner der Auktion (W) 1,00 $
Zweitplatzierter der 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.

minimum_bid_to_win Probability
\(max(F, R, C_3) = $0.50\) \(f_3 = 80\%\)
\(max(F, R, C_4) = $0.10\) \((1-f_3) \cdot f_4 = 17\%\)
\(max(F, R, 0) = $0.05\) \((1-f_3) \cdot (1-f_4) = 3\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Probability
\(C_1 = $3.00\) \(f_1 \div (1-(1-f_1) \cdot (1-f_2)) =~ 10.5\%\)
\(C_2 = $2.00\) \(((1-f_1) \cdot f_2) \div (1-(1-f_1) \cdot (1-f_2)) =~ 89.5\%\)
Gebote, die die Auktion verloren haben

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 flachgelegt wird, können Sie erkennen, welche Gebotsanfragen Teil der ursprünglichen Anfrage waren, da sie im Feld BidRequest.ext.google_query_id denselben Wert haben.

Die Aufschlüsselung von Geboten ist standardmäßig aktiviert. Wenn Sie sie deaktivieren möchten, wenden Sie sich an Ihren Account Manager.

Anzeigenformate

Für einige Anzeigenformate 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 separate Gebotsanfragen aufgeschlüsselt:

  • Banner
  • Video
  • Audio
  • Nativ

Beispiel für die Zusammenführung 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:

Vorab flachstellen

Nach dem Glätten

Angebote

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 Anzeigeneinschränkungen zwischen Auktionen und Festpreisdealtypen variieren. Wenn beispielsweise eine bestimmte Videoanzeigenfläche sowohl für die offene Auktion als auch für einen Festpreisdeal verfügbar ist, erhält ein Bieter für jede Auktion unterschiedliche Gebotsanfragen, bei denen sich Einschränkungen wie die maximale Anzeigendauer und die Zulässigkeit überspringbarer Anzeigen unterscheiden können. Wenn Sie die Anzeigenfläche flach darstellen, können Sie die Anzeigeneinschränkungen für die offene Auktion und den Deal mit Festpreis leichter erkennen.

Überspringbarkeit und Videodauer

Die OpenRTB-Spezifikation enthält keine separaten Felder für die Angabe der maximalen Videodauer von überspringbaren und nicht überspringbaren Anzeigen. Bei der Google-Implementierung wird die Gebotsanpassung verwendet, um anhand der vorhandenen Felder BidRequest.video.maxduration und BidRequest.video.skip zwischen diesen zu unterscheiden.

Im folgenden Beispiel wird gezeigt, wie Videoinventar zusammengeführt wird, wenn die maximale Dauer einer nicht überspringbaren Anzeige 15 und die maximale Dauer einer überspringbaren Anzeige 60 ist.

Beispiel max_ad_duration skip (wahr ODER falsch)
Ursprüngliche Anfrage ohne Flattening 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:

  • In der Anfrage ist Videoinhalt zulässig.
  • 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.

Sie können diese Art der Aufschlüsselung deaktivieren, indem Sie sich an Ihren Technical Account Manager wenden. Wenn die Funktion deaktiviert ist und der Publisher sowohl überspringbare als auch nicht überspringbare Videoanzeigen mit unterschiedlichen maximalen Dauern zulässt, die auf der Überspringbarkeit basieren, wird skip auf true und maxduration auf die kürzere Dauer zwischen den Einschränkungen für überspringbare und nicht überspringbare Anzeigen festgelegt.

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 Interpretation von Gebotsanfragen mit Open Measurement-Signalen finden Sie im Hilfeartikel Open Measurement SDK.

Beispiel für Gebotsanfragen

In den folgenden Abschnitten finden Sie Beispielgebotsanfragen für verschiedene Anzeigentypen.

App-Banner

OpenRTB Protobuf

OpenRTB JSON

App-Interstitial

OpenRTB Protobuf

OpenRTB JSON

Video-Interstitial in Apps

OpenRTB Protobuf

OpenRTB JSON

Native App

OpenRTB Protobuf

OpenRTB JSON

Webvideo

OpenRTB Protobuf

OpenRTB JSON

Mobiles Webbanner für Bieter auf Anzeigenplattform

OpenRTB Protobuf

OpenRTB JSON

Native und Videoanzeigen im Multiformat

OpenRTB Protobuf

OpenRTB JSON