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.
Analyseanfrage
Google sendet eine Gebotsanfrage als serialisierten Protokollzwischenspeicher, der als
binäre Nutzlast einer HTTP-POST-Anfrage. Content-Type ist festgelegt auf
application/octet-stream. Ein Beispiel finden Sie unter Beispiel für eine Gebotsanfrage.
Sie müssen diese Anfrage in eine Instanz von BidRequest parsen
angezeigt. BidRequest ist in realtime-bidding.proto definiert,
Sie finden sie auf der Seite Referenzdaten. Sie können die Nachricht parsen
mit der Methode ParseFromString() in der generierten Klasse für die
BidRequest. 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 das BidRequest haben, können Sie es als
-Objekt zu extrahieren und die benötigten Felder zu extrahieren und zu interpretieren. Beispiel:
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 Informationen, die in einem BidRequest gesendet werden, z. B. der Google-Nutzer
ID, Sprache oder geografischer Standort sind nicht immer verfügbar. Wenn Sie haben
Pre-Targeting-Anzeigengruppen mit Informationen, die für eine bestimmte
eine Impression erzielen, stimmen diese Anzeigengruppen nicht überein. In Fällen, in denen die fehlenden
für die Pre-Targeting-Bedingungen keine Rolle spielen, werden Gebotsanfragen
mit ausgelassenen Informationen gesendet.
Informationen zur Pre-Targeting-Anzeigengruppe finden Sie im
Gruppe „MatchingAdData“ je „AdSlot“. Es enthält die
erste übereinstimmende Anzeigengruppen-ID der Pre-Targeting-Anzeigengruppe, über die Google dazu aufgefordert wurde,
senden Sie die Gebotsanfrage, also die Anzeigengruppe und Kampagne,
wenn Ihre Antwort die Auktion für die Impression gewinnt. Unter bestimmten
unter Umständen möchten, müssen Sie die billing_id explizit für
in der BidResponse.AdSlot. Beispiel:
BidRequest.AdSlot hat mehr als ein matching_ad_data.
Weitere Informationen zu den Beschränkungen für den Inhalt des Gebots finden Sie unter
realtime-bidding.proto.
Wörterbuchdateien
Die Gebotsanfrage verwendet IDs, die in Wörterbuchdateien definiert sind. Diese IDs sind
die in den Referenzdaten verfügbar sind.
Seite.
Gebots-URL-Makros
Optional können einige Felder von BidRequest in
Die in der HTTP-POST-Anfrage verwendete URL. Dies ist beispielsweise nützlich, wenn Sie
Ein einfaches Front-End, das das Load-Balancing über mehrere Back-Ends mithilfe eines Werts durchführt
aus der Anfrage. Wenden Sie sich an Ihren Technical Account Manager, um Unterstützung für
neue Makros zu erstellen.
Macro
Beschreibung
%%GOOGLE_USER_ID%%
Durch google_user_id ersetzt
aus dem BidRequest. z. B. die Bieter-URL
Das Ergebnis entspricht der Android-App.
slither.io.
Open Bidding-Felder
Gebotsanfragen, die an Anzeigenplattform- und Netzwerkbieter gesendet werden, die an Open Bidding teilnehmen
Die Gebote ähneln denen von Authorized Buyers,
Echtzeitgebote nutzen. Open Bidding-Kunden erhalten eine kleine Anzahl von
zusätzliche Felder. Für einige vorhandene Felder gibt es möglicherweise alternative Verwendungsmöglichkeiten. Diese
umfassen Folgendes:
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 Anzeige
Hierarchie von Einheiten, getrennt durch Schrägstriche.
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 die Anzeigenplattform 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 Forschung, Remarketing und
kann die Anzeigenbereitstellung bei der Interaktion zwischen Käufern und Verkäufern eine Rolle spielen. Nur
Anbieter, die Google für die Teilnahme am Authorized Buyers-Programm überprüft hat
Interaktionen sind zulässig.
Damit Sie die BidRequest verstehen und Ihr eigenes
BidResponse, müssen Sie die beiden unterschiedlichen
Möglichkeiten für die Angabe von Technologieanbietern:
Einige Anbieter müssen nicht angegeben werden. Diese Anbieter sind in der Authorized Buyers-Hilfe aufgeführt.
Andere Anbieter können nur teilnehmen, wenn sie sowohl im
BidRequest und BidResponse:
<ph type="x-smartling-placeholder">
</ph>
In der BidRequest, der allowed_vendor_type
gibt an, welche Anbieter der Verkäufer zulässt. Anbieter, die gesendet werden
das Feld allowed_vendor_type von BidRequest sind
aufgeführt in der Vendors.txt
-Wörterbuchdatei.
Im Feld BidResponse hat das Feld vendor_type
gibt an, welche dieser zulässigen Anbieter der Käufer nutzen möchte.
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
}
}
Remarketing
In Authorized Buyers wird in Gebotsanfragen von einer
für mobile Apps. Die ID für mobile Werbung kann ein
IDFA für iOS oder
<ph type="x-smartling-placeholder"></ph>
Die Werbe-ID von Android, die über das
<ph type="x-smartling-placeholder"></ph>
%%EXTRA_TAG_DATA%%-Makro im JavaScript-Tag, das von verwaltet wird,
Authorized Buyers-Partner.
Mit dem %%ADVERTISING_IDENTIFIER%%-Makro können Käufer
Die IDFA von iOS oder die Werbe-ID von Android beim Rendern von Impressionen. Es wird ein
verschlüsselter Proto-Zwischenspeicher MobileAdvertisingId Gefällt mir
<ph type="x-smartling-placeholder"></ph>
%%EXTRA_TAG_DATA%%:
Mithilfe von Werbe-IDs lassen sich Nutzerlisten aus mobilen Werbe-IDs erstellen.
die beim Impressions-Rendering erfasst wurden. Diese Nutzerlisten können gepflegt werden,
auf Ihrem Server oder auf unserem Server. Zum Erstellen von Nutzerlisten auf den Google-Servern können Sie
unsere Bulk-Upload-Funktion.
Wenn die ID für mobile Werbung mit einer Nutzerliste übereinstimmt, können Sie sie für
Remarketing.
Feedback in Echtzeit
Authorized Buyers können sich in Echtzeit Feedback
wie Anzeigenplattformen und
Netzwerke mit Open Bidding.
Feedback zu Gebotsantworten wird in der nachfolgenden Gebotsanfrage für beide unterstützt.
AdX-Protokoll und OpenRTB. Bei OpenRTB wird er gesendet in
BidRequestExt
Zusätzlich zu den Standardfeldern, die im Feld „Feedback zu Gebotsantworten“ gesendet werden, können Sie
auch benutzerdefinierte Daten in der Gebotsantwort senden (entweder in AdX Proto oder OpenRTB)
mit einem event_notification_token, das im
BidResponse. event_notification_token ist
Beliebige Daten, die nur dem Bieter bekannt sind und die bei der Fehlerbehebung helfen,
Beispiel: eine neue Targeting-ID oder Gebots-ID, die eine neue Taktik darstellt, oder
Metadaten zum Creative, die nur dem Bieter bekannt sind. Weitere Informationen
siehe OpenRTB
Erweiterungsprotokollzwischenspeicher für RTB und AdX Proto
für AdX.
Wenn über Authorized Buyers eine Gebotsanfrage an einen Bieter gesendet wird, antwortet dieser
mit einem BidResponse. Wenn für den Bieter Feedback in Echtzeit aktiviert ist,
In einer darauffolgenden Gebotsanfrage sendet Authorized Buyers
Antwort in einer BidResponseFeedback-Nachricht wie unten gezeigt:
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;
}
Das erste Feld, das Sie überprüfen sollten, ist
bid_response_feedback.creative_status_code; können Sie den Code
Bedeutung in
Creative-Statuscodes.txt. Wenn Sie das Gebot gewinnen, können Sie
aus dem Preisfeedback. Weitere Informationen finden Sie unter Anleitung für
deaktivieren.
Das Echtzeit-Feedback enthält die Gebotsanfrage-ID und eine der
Folgendes:
Auktionsergebnis
Feedback in Echtzeit
Der Käufer hat kein Gebot abgegeben.
Nichts.
Der Käufer hat ein Gebot abgegeben, das herausgefiltert wurde, bevor
an der Auktion teilnehmen.
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 sein können.
um die Echtzeitgebotsauktion zu gewinnen. Wenn Sie die Auktion gewonnen haben,
das niedrigste Gebot, das Sie hätten abgeben können,
wodurch Sie dennoch gewonnen haben. Wenn Sie das
Auktion gewinnen, 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 sich die möglichen Werte ermitteln lassen
für minimum_bid_to_win und
sampled_mediation_cpm_ahead_of_auction_winner, müssen wir zuerst
definieren Sie Folgendes:
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\]
Mit der folgenden Funktion werden der erwartete CPM und seine
Wahrscheinlichkeit aus dem Vermittlungskettenelement \(i\), basierend auf der angegebenen Füllung
Preis:
\(X_i = \{C_i\) mit Wahrscheinlichkeit \(f_i\); \(0\) mit Wahrscheinlichkeit \(1 - f_i\}\)
Die letztendlich erfolgreiche 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 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 als
folgt:
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\%\)
Das Ergebnis der RTB-Auktion wird wie folgt ermittelt:
RTB-Auktion
CPM
Auktionsgewinner (W)
1,00 $
Zweitplatzierte Auktion (R)
0,05 $
Mindestpreis / Mindestpreis (F)
0 $
Gebot, mit dem die Auktion gewonnen wurde
Das folgende Beispiel zeigt, wie Werte und Wahrscheinlichkeiten
minimum_bid_to_win und
sampled_mediation_cpm_ahead_of_auction_winner berechnet für eine
Gebot, das gewonnen hat.
Das folgende Beispiel zeigt, wie Werte und Wahrscheinlichkeiten
minimum_bid_to_win und
sampled_mediation_cpm_ahead_of_auction_winner berechnet für eine
Gebote, die verloren gegangen sind.
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 Geboten
Bei der Aufschlüsselung von Gebotsanfragen wird die Verarbeitung eines einzelnen komplexen
BidRequest in mehrere Gebotsanfragen unterteilt, die an Ihre
. Weil sie identische IDs behalten
(BidRequest.google_query_id im RTB-Protokoll von Authorized Buyers)
oder BidRequestExt.google_query_id im OpenRTB-Protokoll) können Sie
bestimmen, welche Gebotsanfragen nach der Aufschlüsselung korrelieren.
Anzeigenformate
Für einige Umsatzchancen sind mehrere Formate zulässig. Bei der Aufschlüsselung von Gebotsanfragen
wird in einer separaten Gebotsanfrage gesendet, wobei Attribute wie
Abrechnungs-IDs sind für das in der Anfrage angegebene Format relevant.
Gebotsanfragen mit den folgenden Formaten werden in
unterschiedlichen Gebotsanfragen:
Banner
Video
Audio
Nativ
Beispiel für die Aufschlüsselung von Anzeigenformaten
Das folgende Beispiel zeigt eine vereinfachte OpenRTB-JSON-Gebotsanfrage ohne Anzeige
Formatvereinfachung im Vergleich zu einem äquivalenten Satz vereinfachter Anfragen:
Eine Opportunity für einen bestimmten Bieter kann für verschiedene Deals gelten.
offenen Auktionen ausgewählt werden. Bei der Aufschlüsselung von Geboten für Deals wird ein Gebot
für die offene Auktion und eine Anfrage pro Festpreistyp
Deal. 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
für die offene Auktion und einen 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 Google-Protokoll und die OpenRTB-Implementierung unterstützen folgende Felder:
für Videodauer und Überspringbarkeit:
Dauer
Dauer bis überspringbar
Ü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 Aufschlüsselung von Geboten würde maxduration von OpenRTB auf
des Google-Protokolls max_ad_duration und
skippable_max_ad_duration-Felder. 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. Entsprechendes Google-Protokoll
der Anfrage ist für max_ad_duration15 und
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 für die Dauer von überspringbaren Videos erfolgt nur, wenn
folgende Bedingungen erfüllt sind:
Die Anfrage lässt Video zu.
Es sind sowohl Videos zum Überspringen als auch nicht überspringbare Videos zulässig, wobei die beiden entsprechenden maximalen
unterscheiden sich im 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 Ihren technischen
Account Manager.
Video pods
Gebotsanfragen für einen Videopod mit
mehreren Umsatzchancen werden aufgeschlüsselt,
Jede Gebotsanfrage bezieht sich also
auf eine einzelne Werbechance aus diesem Pod.
So können Sie auf mehrere Umsatzchancen für einen bestimmten Pod bieten.
Open Measurement
Mit Open Measurement können Sie Drittanbieter angeben,
Unabhängige Mess- und Überprüfungsdienste für Anzeigen, die in mobilen Apps ausgeliefert werden
Umgebungen.
Sie können feststellen, ob ein Publisher Open Measurement im Gebot unterstützt
Anfrage, indem Sie prüfen, ob die Werbechance das Attribut OmsdkType:
OMSDK 1.0 ausschließt, das unter Vom Publisher ausgeschlossene Elemente
Creative-Attributen. Für das Authorized Buyers-Protokoll wäre das
unter BidRequest.adslot[].excluded_attribute gefunden. Für die
OpenRTB-Protokoll zu finden ist unter dem Attribut battr
für Banner oder
Video, je nach
des Formats.
Weitere Informationen zur Auswertung von Gebotsanfragen mit offenen
Messsignale, siehe den Artikel Open Measurement
SDK-Hilfeartikel.
Beispiele für Gebotsanfragen
In den folgenden Abschnitten sehen Sie Beispiele für Gebotsanfragen für verschiedene Anzeigentypen.
