Anfrage verarbeiten

Eine Echtzeitgebotsinteraktion beginnt, wenn Google eine Gebotsanfrage an Ihre Anwendung sendet. In diesem Leitfaden wird erläutert, wie Sie Ihre Anwendung so programmieren, dass die Gebotsanfrage verarbeitet wird.

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 wird. Das empfangene Format hängt von der Konfiguration Ihres Endpunkts ab. Ein Beispiel finden Sie unter Beispiel für eine Gebotsanfrage.

Sie müssen 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. Der folgende C++-Code parst beispielsweise eine Anfrage mit einer POST-Nutzlast in einem String: 

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 sie als Objekt verwenden und die benötigten Felder extrahieren und interpretieren. In C++ könnte das Durchlaufen von Deals in einer OpenRTB-`BidRequest` 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 von einer oder mehreren Ihrer Pre-Targeting-Konfigurationen angesprochen wird. BidRequest.imp.ext.billing_id wird mit den Abrechnungs-IDs aller berechtigten Käufer und den relevanten Pre-Targeting-Konfigurationen gefüllt. Außerdem können Sie für Dealinventar die Abrechnungs-IDs der relevanten Käufer mit BidRequest.imp.pmp.deal.ext.billing_id ermitteln. Bei der Abgabe 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.

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

Blockierte Kategorien ermitteln

Wenn Sie ein Gebot abgeben, darf das enthaltene Creative keine erkannten Kategorien enthalten, die vom Publisher blockiert wurden. Andernfalls wird das Gebot aus der Auktion herausgefiltert.

Die blockierten Kategorien für eine Impression finden Sie im Feld BidRequest.bcat. Dieses Feld wird mit Kategorien aus der Taxonomie gefüllt, die für Ihr Konto konfiguriert ist.

Im folgenden Beispiel werden blockierte Kategorien basierend auf einer konfigurierten Taxonomie für Anzeigenkategorien gezeigt:

Version 1.0 der IAB-Taxonomie für Inhalte

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}

Kontextbezogene Kategorien bestimmen

Gebotsanfragen können Felder für kontextbezogene Kategorien enthalten, die die Website oder App beschreiben, auf der eine Impression ausgeliefert wird. Für diese Felder werden auch Anzeigenkategorietaxonomien verwendet, sie stellen jedoch den Kontext der Impression und nicht Einschränkungen für das Creative dar. Diese Felder verwenden möglicherweise nicht dieselbe Taxonomie wie das Feld BidRequest.bcat. Google oder der Publisher können diese kontextbezogenen Kategorien bereitstellen. Die Verwendung von Kontextkategorien kann die Bewertung von Impressionen, das Kontext-Targeting und die Markensicherheit verbessern.

Von Google erkannte Kontextkategorien

Google füllt die folgenden Felder mit erkannten IAB-Inhaltskategorien für die Website, App oder Seite aus:

Feld Beschreibung
BidRequest.site.cat Ein Array von Inhaltskategorie-IDs, die die Website beschreiben.
BidRequest.site.pagecat Ein Array von Inhaltskategorie-IDs, die die aktuelle Seite oder Ansicht der Website beschreiben.
BidRequest.app.cat Ein Array von Inhaltskategorie-IDs, die die App beschreiben.
BidRequest.app.pagecat Ein Array von Inhaltskategorie-IDs, die die aktuelle Seite oder Ansicht der App beschreiben.

Die genaue Taxonomie, die für diese Felder für eine bestimmte Gebotsanfrage verwendet wird, finden Sie in den Feldern BidRequest.site.cattax oder BidRequest.app.cattax. Kontextbezogene Kategoriefelder werden aufgrund von Publisher-Einstellungen oder regulatorischen Bedenken möglicherweise nicht immer ausgefüllt. Weitere Informationen finden Sie unter Kontextbezogene OpenRTB-Kategorien in Google Ad Manager.

Vom Publisher bereitgestellte Signale

Zusätzlich zu den von Google erkannten Kontextkategorien können Gebotsanfragen auch vom Publisher bereitgestellte Signale enthalten, die ebenfalls den Kontext einer Impression beschreiben. Im Gegensatz zu den von Google erkannten Kontextkategorien werden diese Signale nur dann ausgefüllt, wenn sie vom Publisher bereitgestellt werden. Diese Signale werden in den Objekten BidRequest.site.content und BidRequest.app.content gesendet, z. B. content.data.segment und content.genre. Die für content.data.segment-Einträge verwendete Taxonomie wird in content.data.ext.segtax angegeben. Weitere Informationen finden Sie unter Vom Publisher bereitgestellte Signale (PPS) für Echtzeitgebote (RTB).

Wörterbuchdateien

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

Makros für Bieter-URLs

Optional können einige Informationen aus dem BidRequest mithilfe von Makros in die URLs des Gebotsendpunkts eingefügt werden. Wenn Sie eine Endpunkt-URL mit einem oder mehreren Makros konfigurieren, werden diese erweitert, wenn die entsprechenden Informationen in der Gebotsanfrage vorhanden sind. Das kann beispielsweise nützlich sein, wenn Sie Load Balancing basierend auf Informationen im BidRequest durchfü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. Beispielsweise wird die Bieter-URL http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% zum Zeitpunkt der Anfrage durch etwas wie http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl ersetzt.

Wenn die Google-Nutzer-ID unbekannt ist, wird der leere String eingesetzt, mit einem Ergebnis ähnlich dem folgenden:

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

Wird durch 1 ersetzt, um anzugeben, dass die Gebotsanfrage von einem Mobilgerät stammt, oder andernfalls durch 0. Dies basiert auf dem Wert von BidRequest.device.devicetype, wobei Mobilgeräte durch HIGHEND_PHONE (4) oder Tablet (5) gekennzeichnet sind.
%%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 angegeben ist.
%%IS_CTV%%

Wird durch 1 ersetzt, um anzugeben, dass die Gebotsanfrage von einem CTV-Gerät stammt, andernfalls durch 0. Dies basiert auf dem Wert von BidRequest.device.devicetype. Für Protobuf sind CTV-Geräte CONNECTED_TV, CONNECTED_DEVICE oder SET_TOP_BOX, was den Ganzzahlwerten 3, 6 oder 7 für JSON entspricht.
%%HOSTED_MATCH_DATA%%

Wird durch einen Wert auf Grundlage von BidRequest.user.buyeruid ersetzt.

%%MOBILE_IS_APP%%

Wird durch 1 ersetzt, um anzugeben, dass die Gebotsanfrage für App-Inventar gilt, oder durch 0. Dies hängt davon ab, ob BidRequest.app ausgefüllt ist.

ID einer mobilen App über die Transaktions-URL ermitteln

Bei Transaktionen in mobilen Apps werden URLs gemeldet, die so aussehen:

mbappgewtimrzgyytanjyg4888888.com

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

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

So decodieren Sie diesen Wert: 

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

Ein weiteres Beispiel: Die gemeldete URL lautet: 

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

Namen von mobilen Apps anhand der Transaktions-URL ermitteln

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

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Wert decodieren: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 ergibt: 
air.com.hypah.io.slither
 Das Ergebnis entspricht der Android-App slither.io.

Open Bidding-Felder

Gebotsanfragen, die an Exchange- und Netzwerkbieter gesendet werden, die an Open Bidding teilnehmen, ähneln denen von Authorized Buyers, die an Standard-Echtzeitgeboten teilnehmen. Open Bidding-Kunden erhalten eine kleine Anzahl zusätzlicher Felder und einige vorhandene Felder können alternativ 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, getrennt durch Schrägstriche.

Beispiel: /1234/cruises/mars.
BidRequest.user.data.segment

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

Sie können festlegen, 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 Dienste wie Marktforschung, Remarketing und Anzeigenbereitstellung anbieten, können bei der Interaktion zwischen Käufern und Verkäufern eine Rolle spielen. Es sind nur Anbieter zulässig, die von Google für die Teilnahme an Authorized Buyers-Interaktionen geprüft wurden.

Um die BidRequest zu verstehen und Ihre BidResponse zu erstellen, müssen Sie die beiden verschiedenen Möglichkeiten zum Deklarieren von Technologieanbietern kennen:

  1. Einige Anbieter müssen nicht deklariert werden. Diese Anbieter sind unter Zertifizierte externe Anbieter in Ad Manager aufgeführt.
  2. Andere Anbieter können nur teilnehmen, wenn sie in der BidRequest angegeben 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 sind menschenlesbare Beispiele für die Protobuf- und JSON-Anfragen.

OpenRTB-Protobuf

OpenRTB JSON

Wenn Sie die Gebotsanfrage in ein Binärformat konvertieren möchten, wie Sie es bei einer echten Anfrage aus der POST-Nutzlast erhalten würden, können Sie Folgendes tun (in C++). Beachten Sie jedoch, dass dies nicht zutreffend für OpenRTB JSON ist.

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
  }
}

Echtzeit-Feedback

Echtzeit-Feedback ist für Authorized Buyers-Nutzer sowie für Anzeigenplattformen und Netzwerke verfügbar, die Open Bidding verwenden.

Echtzeit-Feedback wird in BidRequest.ext.bid_feedback auf Grundlage des Ergebnisses eines oder mehrerer Gebote, die Sie zuvor abgegeben haben, eingefügt. Es kann verwendet werden, um Details wie das Mindestgebot zu ermitteln, das erforderlich war, um die Auktion zu gewinnen. Wenden Sie sich an Ihren Account Manager, um Echtzeit-Feedback zu aktivieren.

Zusätzlich zu den Standardfeldern, die im Feedback zur Gebotsantwort gesendet werden, können Sie mit dem Feld BidResponse.seatbid.bid.ext.event_notification_token auch benutzerdefinierte Daten in der Gebotsantwort senden. Die event_notification_token sind beliebige Daten, die nur dem Bieter bekannt sind und bei der Fehlersuche helfen können, z. B. eine neue Targeting-ID oder Gebots-ID, die eine neue Taktik darstellt, oder Metadaten, die nur dem Bieter bekannt sind und mit dem Creative verknüpft sind. Weitere Informationen finden Sie in der OpenRTB-Erweiterungsprotokollzwischenspeicher-Datei.

Wenn Authorized Buyers eine Gebotsanfrage an einen Bieter sendet, antwortet der Bieter mit einer BidResponse. Wenn der Bieter Echtzeit-Feedback 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;

  // 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;
}

Das erste Feld, das Sie in dieser Nachricht prüfen sollten, ist bid_feedback.creative_status_code. Die Bedeutung des Codes finden Sie in creative-status-codes.txt. Wenn Sie das Gebot gewinnen, können Sie die Preisrückmeldung deaktivieren. Weitere Informationen finden Sie unter Deaktivierung.

Das Echtzeit-Feedback enthält die Gebotsanfrage-ID und eines der folgenden Elemente:

Auktionsergebnis Echtzeit-Feedback
Der Käufer hat kein Gebot abgegeben. Nichts.
Der Käufer hat ein Gebot abgegeben, das herausgefiltert wurde, bevor es die Auktion erreicht hat. Der Creative-Statuscode (creative-status-codes.txt).
Der Käufer hat ein Gebot abgegeben, aber die Auktion verloren. Der Creative-Statuscode 79 (in Auktion überboten).
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 und einem Creative-Statuscode von 83 hat der App-Publisher möglicherweise eine Vermittlungsabfolge verwendet. Das erfolgreiche Gebot hätte dann mit anderen Nachfragen in der Passback-Abfolge des Publishers konkurriert. Informationen zur Verwendung von sampled_mediation_cpm_ahead_of_auction_winner bei Geboten

Beispiel

Hier ist ein Beispiel für Echtzeit-Feedback, wie es in unterstützten Protokollen angezeigt wird:

OpenRTB-Protobuf

OpenRTB JSON

Gebotsmodell für Erstpreisauktionen erstellen

Nachdem Sie ein Gebot in einer Erstpreisauktion abgegeben haben, erhalten Sie Echtzeit-Feedback, 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. Diese Signale können verwendet werden, um Ihre Gebotslogik darüber zu informieren, 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 Echtzeitgebote-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 Höchstgebot.
  • sampled_mediation_cpm_ahead_of_auction_winner: Wenn es andere Netzwerke in der Vermittlungskette gibt, ist der Wert dieses Felds ein Preis, der ein Beispielgebot von einem der infrage kommenden Vermittlungsnetzwerke darstellt, die höher als der Auktionsgewinner waren, gewichtet nach der erwarteten Ausführungsrate. Dieser Wert wird auf 0 gesetzt, wenn keines der Netzwerke in der Vermittlungskette voraussichtlich gefüllt wird oder wenn 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:

  • Die CPMs in der Vermittlungskette werden in absteigender Reihenfolge dargestellt:
    \[C_1, C_2, …, C_n\]
  • Die entsprechenden Auslieferungsraten für die CPMs in der Vermittlungskette sind:
    \[f_1, f_2, …, f_n\]
  • Die folgende Funktion wird verwendet, um den erwarteten CPM und seine Wahrscheinlichkeit aus dem Vermittlungskettenelement \(i\)anhand der angegebenen Fillrate zu bestimmen:
    \(X_i = \{C_i\) mit Wahrscheinlichkeit \(f_i\); \(0\) mit Wahrscheinlichkeit \(1 - f_i\}\)
  • Die endgültige Vermittlungskette ist:
    \[\{C_1, C_2, …, C_K, W\}\]
    Dabei ist \(W\) das erfolgreiche Gebot und \(C_K > W >= C_{K+1}\)
  • Der Mindestpreis wird als \(F\)bezeichnet.
  • 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\%\)
Netzwerk 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

Angenommen, die RTB-Auktion hat folgendes Ergebnis:

RTB-Auktion CPM
Auktionsgewinner (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 ein erfolgreiches 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 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 ein verlorenes Gebot 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

Die Aufschlüsselung von Gebotsanfragen beschreibt die Verarbeitung einer einzelnen komplexen BidRequest in mehrere Gebotsanfragen, die an Ihre Anwendung gesendet werden. Wenn eine Gebotsanfrage vereinfacht wird, können Sie erkennen, welche Gebotsanfragen Teil des Originals waren, da sie im Feld BidRequest.ext.google_query_id einen identischen Wert haben.

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

Anzeigenformate

Bei einigen Anzeigenchancen sind mehrere Formate zulässig. Bei der Aufschlüsselung von Gebotsanfragen wird jedes Format in einer separaten Gebotsanfrage gesendet. Attribute wie infrage kommende Abrechnungs-IDs sind für das in der Anfrage angegebene Format relevant.

Gebotsanfragen mit den folgenden Formaten werden in separate Gebotsanfragen aufgeschlüsselt:

  • Banner
  • Video
  • Audio
  • Nativ

Beispiel für die Vereinfachung von Anzeigenformaten

Im Folgenden finden Sie ein Beispiel für eine vereinfachte OpenRTB-JSON-Gebotsanfrage ohne Aufschlüsselung des Anzeigenformats im Vergleich zu einer entsprechenden Gruppe von aufgeschlüsselten Anfragen:

Vorab vereinfachen

Nach dem Glätten

Angebote

Eine Anzeigenchance für einen bestimmten Bieter kann neben der offenen Auktion auch für verschiedene Deal-Typen gelten. Bei der Aufschlüsselung von Gebotsanfragen für Deals wird eine Gebotsanfrage für die offene Auktion und eine für jeden Typ von Festpreis-Deal gesendet. In der Praxis können sich die Einschränkungen für Anzeigen zwischen Auktionen und Festpreisangeboten unterscheiden. Bei einer bestimmten Videoanzeigenfläche, die sowohl für die offene Auktion als auch für ein Festpreisangebot verfügbar ist, erhält ein Bieter beispielsweise unterschiedliche Gebotsanfragen für jede Fläche. Dabei können sich Einschränkungen wie die maximale Anzeigendauer und die Zulässigkeit von überspringbaren Anzeigen unterscheiden. Durch die Vereinfachung der Anzeigenfläche können Sie die Einschränkungen für die offene Auktion und das Festpreisangebot leichter erkennen.

Überspringbarkeit und Videodauer

In der OpenRTB-Spezifikation gibt es keine separaten Felder, um die maximale Videodauer von überspringbaren und nicht überspringbaren Anzeigen anzugeben. Bei der Implementierung von Google wird die Aufschlüsselung von Gebotsanfragen verwendet, um mithilfe der vorhandenen Felder BidRequest.video.maxduration und BidRequest.video.skip zwischen diesen zu unterscheiden.

Im folgenden Beispiel wird gezeigt, wie Videoinventar abgeflacht wird, wenn die maximale Dauer einer nicht überspringbaren Anzeige 15 und die maximale Dauer einer überspringbaren Anzeige 60 beträgt.

Beispiel max_ad_duration skip (true ODER false)
Ursprüngliche Anfrage ohne Reduzierung 15 true
Aufgeschlüsselte Anfrage 1: Nicht überspringbar 15 false
Aufgeschlüsselte Anfrage 2: Überspringbar 60 true

Die Aufschlüsselung von Gebotsanfragen für überspringbare Videodauer erfolgt nur, wenn die folgenden Bedingungen erfüllt sind:

  • Die Anfrage erlaubt Videos.
  • Sowohl überspringbare als auch nicht überspringbare Videos sind zulässig. Die beiden maximalen Dauern unterscheiden sich im Wert.
  • Diese Anfrage ist für private Auktionen oder offene Auktionen geeignet.

Sie können diese Art der Vereinfachung deaktivieren, indem Sie sich an Ihren Technical Account Manager wenden. Wenn die Option deaktiviert ist und der Publisher sowohl überspringbare als auch nicht überspringbare Videoanzeigen mit unterschiedlichen maximalen Dauern basierend auf der Überspringbarkeit zulässt, 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 Anzeigenchancen werden aufgeschlüsselt, sodass jede Gebotsanfrage für eine einzelne Anzeigenchance aus diesem Pod gilt. So können Sie für einen bestimmten Pod auf mehrere Anzeigenflächen bieten.

Open Measurement

Mit Open Measurement können Sie Drittanbieter angeben, die unabhängige Mess- und Überprüfungsdienste für Anzeigen bereitstellen, die in mobilen Apps ausgeliefert werden.

Sie können in der Gebotsanfrage feststellen, ob ein Publisher Open Measurement unterstützt. Prüfen Sie dazu, ob das Attribut OmsdkType: OMSDK 1.0, das Sie unter Vom Publisher ausschließbare Creative-Attribute finden, in der Anzeigenmöglichkeit ausgeschlossen ist. Diese 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.

Beispiele für Gebotsanfragen

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

App-Banner

OpenRTB Protobuf

OpenRTB-JSON

App-Interstitial

OpenRTB-Protobuf

OpenRTB JSON

App-Interstitial-Video

OpenRTB-Protobuf

OpenRTB-JSON

Native App-Anzeigen

OpenRTB Protobuf

OpenRTB-JSON

Webvideo

OpenRTB-Protobuf

OpenRTB-JSON

Banner für das mobile Web für Anzeigenplattform-Gebote

OpenRTB Protobuf

OpenRTB-JSON

Multiformat-Native- und Videoanzeigen

OpenRTB Protobuf

OpenRTB JSON