Przetwarzanie żądania

Interakcja z określaniem stawek w czasie rzeczywistym rozpoczyna się, gdy Google wysyła do Twojej aplikacji żądanie stawki. Z tego przewodnika dowiesz się, jak zakodować aplikację, aby przetwarzała żądanie stawki.

Przetwarzanie żądania Protobuf

Google wysyła żądanie stawki jako zaszyfrowany bufor protokołu dołączony jako binarny ładunek żądania HTTP POST. Wartość Content-Type to application/octet-stream. Przykład znajdziesz w sekcji Przykładowe pytanie o stawkę.

Musisz przeanalizować to żądanie w instancji wiadomości BidRequest. W zależności od wybranego protokołu BidRequest jest zdefiniowany w openrtb.proto lub przestarzałym realtime-bidding.proto, który można uzyskać na stronie danych referencyjnych. Możesz przeanalizować wiadomość za pomocą metody ParseFromString() w wygenerowanej klasie BidRequest. Na przykład ten kod w C++ analizuje żądanie, korzystając z ładunku POST w postaci ciągu: 

string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
  // Process the request.
}

Gdy już masz BidRequest, możesz z nim pracować jak z obiektem, wyodrębniając i interpretując potrzebne pola. Na przykład w C++ iterowanie przez umowy w „BidRequest” OpenRTB może wyglądać tak:

for (const BidRequest::Imp::Pmp::Deal& deal : pmp.deals()) {
  DoSomething(deal.id(), deal.wseat());
}

Identyfikatory płatności

Otrzymasz żądanie stawki, gdy zasoby reklamowe wydawcy są kierowane przez co najmniej 1  konfigurację kierowania wstępnego. BidRequest.imp.ext.billing_id zostanie wypełniony identyfikatorami płatności wszystkich kwalifikujących się kupujących oraz odpowiednimi konfiguracjami wstępnego kierowania. Dodatkowo w przypadku asortymentu objętego umowami możesz znaleźć identyfikatory płatności powiązane z odpowiednim kupującym za pomocą BidRequest.imp.pmp.deal.ext.billing_id. Podczas określania stawki można podać tylko identyfikatory płatności kupujących zawarte w pytaniu o stawkę.

Jeśli w pytaniu o stawkę podano kilka identyfikatorów płatności, w polu BidResponse.seatbid.bid.ext.billing_id musisz podać identyfikator płatności kupującego, któremu chcesz przypisać stawkę.

Pliki słownika

Żądanie stawki używa identyfikatorów zdefiniowanych w plikach słownika, które są dostępne na stronie danych referencyjnych.

Makra URL stawek protokołu Google RTB

Opcjonalnie możesz wstawić niektóre pola BidRequest do adresu URL używanego w żądaniu HTTP POST. Jest to przydatne, jeśli używasz lekkiego interfejsu, który równoważy obciążenie między wieloma backendami za pomocą wartości z żądania. Aby uzyskać pomoc dotyczącą nowych makr, skontaktuj się z menedżerem technicznym konta.

MakroOpis
%%GOOGLE_USER_ID%%

Zastąpiono go wartością google_user_id z poziomu BidRequest. Na przykład adres URL oferenta 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
 zostanie zastąpione przez coś takiego: 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
w momencie wysłania żądania.

Jeśli identyfikator Google User ID jest nieznany, zostaje zastąpiony pustym ciągiem, co daje wynik podobny do

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

Zastąpione przez 1 lub 0 podczas wywoływania funkcji has_mobile() w BidRequest.
%%HAS_VIDEO%%

Zastępuje wartość 1 (prawda) lub 0 (fałsz) podczas wywoływania funkcji has_video() obiektu BidRequest.
%%HOSTED_MATCH_DATA%%

Zastąpiona wartością pola hosted_match_data z poziomu BidRequest.
%%MOBILE_IS_APP%%

Zastąpiono wartością 1 (prawda) lub 0 (fałsz) z pola mobile.is_app rekordu BidRequest.

Znajdowanie identyfikatora aplikacji mobilnej na podstawie adresu URL transakcji

Transakcje w aplikacji mobilnej będą zawierać adresy URL takie jak:

mbappgewtimrzgyytanjyg4888888.com

Aby odkodować część ciągu w królewskim (gewtimrzgyytanjyg4888888), użyj dekodera base-32.

Możesz użyć dekodera online, ale musisz pisać litery wielką literą i zastąpić końcowe 8 wartościami =.

Dekodowanie tej wartości: 

GEWTIMRZGYYTANJYG4======
 wyniki: 
1-429610587
Ciąg 429610587 to identyfikator aplikacji na iOS iFunny.

Oto kolejny przykład. Zgłaszany adres URL: 

mbappgewtgmjug4ytmmrtgm888888.com
 Dekodowanie tej wartości: 
GEWTGMJUG4YTMMRTGM======
 wyniki: 
1-314716233
Wynik 314716233 to identyfikator aplikacji TextNow na iOS.

Znajdowanie nazwy aplikacji mobilnej na podstawie adresu URL transakcji

Oto przykład uzyskiwania nazwy aplikacji. Zgłaszany adres URL: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Dekodowanie tej wartości: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 wyniki: 
air.com.hypah.io.slither
 Wynik jest równoważny aplikacji slither.io na Androida.

Pola Otwartego ustalania stawek

Żądania o stawkę wysyłane do licytujących giełd i sieci uczestniczących w otwartym ustalaniu stawek są podobne do żądań wysyłanych przez licytujących korzystających ze standardowego określania stawek w czasie rzeczywistym. Klienci korzystający z Otwartego ustalania stawek otrzymają niewielką liczbę dodatkowych pól, a kilka dotychczasowych pól może mieć inne zastosowanie. Są to m.in.:

OpenRTB Authorized Buyers. Szczegóły
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

Zawiera kod sieci wydawcy w Ad Managerze, a następnie hierarchię jednostek reklamowych oddzielonych ukośnikami.

Na przykład:/1234/cruises/mars.
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

Powtarzające się pary klucz-wartość wysyłane przez wydawcę do licytatora giełdy.

Gdy parametr BidRequest.user.data[].name ma wartość “Publisher Passed”, możesz stwierdzić, że wartości to pary klucz-wartość wysyłane przez wydawcę.

Deklarowanie dozwolonych dostawców

Dostawcy technologii, którzy świadczą usługi takie jak badania, remarketing i wyświetlanie reklam, mogą odgrywać pewną rolę w interakcjach między kupującymi a sprzedawcami. Dozwoleni są tylko dostawcy, którzy przeszli weryfikację Google pod kątem uczestnictwa w interakcjach Authorized Buyers.

Aby zrozumieć BidRequest i utworzyć BidResponse, musisz znać 2 różne możliwości deklarowania dostawców technologii:

  1. Niektórych dostawców nie trzeba deklarować. Są oni wymienieni na liście dostawców zewnętrznych z certyfikatem Ad Managera.
  2. Inni dostawcy mogą uczestniczyć w tym procesie tylko wtedy, gdy są zadeklarowani w sekcji BidRequest:
    • W BidRequest pole BidRequest.imp.ext.allowed_vendor_type określa, którzy dostawcy są dozwoleni przez sprzedawcę. Dostawcy, którzy zostaną wysłani w pliku allowed_vendor_type, są wymienieni w pliku słownika vendors.txt.

Przykładowe pytanie o stawkę

Poniższe przykłady przedstawiają żądania Protobuf i JSON w formie zrozumiałej dla człowieka.

OpenRTB Protobuf

OpenRTB w formacie JSON

Google (wycofane)

Aby przekonwertować żądanie oferty do postaci binarnej, tak jak w rzeczywistej prośbie w postaci POST, możesz wykonać te czynności (w C++). Pamiętaj jednak, że nie dotyczy to pliku 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
  }
}

Odpowiedzi w czasie rzeczywistym

Informacje zwrotne w czasie rzeczywistym są dostępne dla programów Authorized Buyers, giełd i sieci korzystających z Otwartego ustalania stawek.

Informacje o odpowiedzi na pytanie o stawkę są obsługiwane w kolejnych żądaniach stawek zarówno w przypadku protokołu OpenRTB, jak i starszego protokołu Google RTB. W przypadku OpenRTB jest on wysyłany w pliku BidRequest.ext.bid_feedback.

Oprócz pól domyślnych wysyłanych w informacjach zwrotnych o odpowiedzi na stawkę możesz też przesyłać dane niestandardowe w odpowiedzi na stawkę, korzystając z pola BidResponse.seatbid.bid.ext.event_notification_token. event_notification_token to dowolne dane znane tylko licytantowi, które mogą pomóc w debugowaniu, np. nowy identyfikator kierowania lub identyfikator licytowania reprezentujący nową taktykę lub metadane powiązane z kreacją znane tylko licytantowi. Więcej informacji znajdziesz w protokole OpenRTB Extensions Protocol Buffer dotyczącym OpenRTB lub w przypadku wycofanego protokołu Google RTB.

Gdy Authorized Buyers wysyła pytanie o stawkę do licytującego, ten odpowiada za pomocą BidResponse. Jeśli licytujący ma włączone informacje zwrotne w czasie rzeczywistym, to w kolejnych żądaniach stawek Authorized Buyers wysyła informacje zwrotne o odpowiedzi w wiadomości BidFeedback:

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

W tym komunikacie pierwszym polem, które należy sprawdzić, jest bid_feedback.creative_status_code. Znaczenie kodu znajdziesz w pliku creative-status-codes.txt. Pamiętaj, że jeśli wygrasz aukcję, możesz zrezygnować z opinii o cenie. Więcej informacji znajdziesz w artykule Jak zrezygnować z reklam.

Odpowiedź w czasie rzeczywistym zawiera identyfikator pytania o stawkę i jeden z tych elementów:

Wynik aukcji Odpowiedzi w czasie rzeczywistym
Kupujący nie przesłał stawki. Nic.
Kupujący przesłał stawkę, która została odfiltrowana przed dotarciem do aukcji. Kod stanu kreacji (creative-status-codes.txt).
Kupujący przesłał stawkę, ale przegrał na aukcji. Kod stanu kreacji 79 (przelicytowanie w aukcji).
Kupujący przesłał stawkę, która wygrała aukcję. Cena uzgodnienia i kod stanu kreacji 1.

W przypadku wyświetlenia aplikacji i kodu stanu kreacji 83 wydawca aplikacji mógł korzystać z łańcucha zapośredniczenia, więc stawka zwycięska musiała konkurować z innymi zapytaniami w łańcuchu zapośredniczenia z powrotnym przekazywaniem. Dowiedz się, jak korzystać z funkcji sampled_mediation_cpm_ahead_of_auction_winner podczas ustalania stawek

Przykład

Oto przykład opinii w czasie rzeczywistym w obsługiwanych protokołach:

OpenRTB Protobuf

OpenRTB w formacie JSON

Google (wycofane)

Tworzenie modelu określania stawek na potrzeby aukcji pierwszej ceny

Po ustaleniu stawki w aukcji pierwszej ceny otrzymasz informacje zwrotne w czasie rzeczywistym, w tym pola minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner, jeśli stawka nie została odfiltrowana z aukcji. Sygnały te mogą służyć do informowania logiki ustalania stawek o tym, o ile wyższa lub niższa mogłaby być stawka, aby wygrać wyświetlenie.

  • minimum_bid_to_win: minimalna stawka, która mogła zostać ustawiona, aby wygrać aukcję ustalania stawek w czasie rzeczywistym. Jeśli wygrasz aukcję, będzie to najniższa stawka, jaką można było ustawić, aby wygrać. Jeśli przegrałeś aukcję, będzie to stawka zwycięska.
  • sampled_mediation_cpm_ahead_of_auction_winner: jeśli w łańcuchu zapośredniczenia występują inne sieci, wartość tego pola to cena stanowiąca przykładową stawkę z jednej z kwalifikujących się sieci zapośredniczenia, która była wyższa niż stawka zwycięzcy aukcji, powiększona o oczekiwany współczynnik wypełnienia. Jeśli żadna z sieci w łańcuchu zapośredniczenia nie jest w stanie wypełnić żądania reklamy lub wydawca nie korzysta z zapośredniczenia za pomocą pakietu SDK, wartość zostanie ustawiona na 0.

Jak to działa

Aby opisać obliczenia służące do określania możliwych wartości dla minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner, musimy najpierw zdefiniować:

  • Poniżej podajemy CPM w łańcuchu zapośredniczenia w kolejności malejącej:
    \[C_1, C_2, …, C_n\]
  • Poniżej znajdziesz odpowiednie współczynniki wypełniania CPM w łańcuchu pośrednictwa:
    \[f_1, f_2, …, f_n\]
  • Oto funkcja służąca do określania oczekiwanego CPM i jego prawdopodobieństwa z elementu łańcucha zapośredniczenia \(i\)na podstawie danego współczynnika wypełnienia:
    \(X_i = \{C_i\) z pewnością \(f_i\); \(0\) z pewnością \(1 - f_i\}\)
  • Ostateczny łańcuch zapośredniczenia będzie wyglądał tak:
    \[\{C_1, C_2, …, C_K, W\}\]
    gdzie \(W\) to stawka wygrywająca aukcję, a \(C_K > W >= C_{K+1}\)
  • Cena minimalna jest oznaczona jako \(F\).
  • Druga najwyższa stawka jest oznaczona jako \(R\).
Obliczenia dotyczące zwycięzcy aukcji
Pole Obliczenie
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) z prawdopodobieństwem \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Dotyczy: \(1 <= i <= K\).
Obliczenia dotyczące przegranego udziału w aukcji
Pole Obliczenie
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

Przykład z prostym łańcuchem zapośredniczenia

Załóżmy, że wydawca korzysta z określania stawek w czasie rzeczywistym i z łańcucha zapośredniczenia pakietu SDK w taki sposób:

Łańcuch zapośredniczenia SDK Spodziewany CPM Współczynnik wypełnienia
Sieć 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
Sieć 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
Sieć 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
Sieć 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

Załóżmy, że w wyniku aukcji RTB:

Aukcja RTB CPM
Auction Winner (W) 1 USD
Auction Runner-UP (R) 0,05 USD
Cena minimalna (F) 0 USD
Stawka, która wygrała aukcję

Poniżej przedstawiamy przykład obliczania wartości i prawdopodobienstw dla minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner w przypadku wygranego limitu stawek.

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\%\)
Stawki, które przegrały na aukcji

Poniżej przedstawiamy przykład obliczania wartości i prawdopodobienstw dla parametrów minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner w przypadku przegranych stawek.

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\%\)

Rozdzielanie stawek

Rozdzielanie pytań o stawkę to przetwarzanie pojedynczego złożonego BidRequest na wiele pytań o stawkę wysyłanych do aplikacji. Gdy żądanie stawki zostanie spłaszczone, możesz sprawdzić, które żądania stawek stanowiły część pierwotnego żądania, ponieważ będą miały identyczną wartość w polu BidRequest.ext.google_query_id.

Spłaszczenie stawek jest domyślnie włączone, ale jeśli chcesz je wyłączyć, skontaktuj się ze swoim menedżerem konta.

Formaty reklam

Niektóre możliwości reklamowe mogą akceptować wiele formatów. W przypadku spłaszczenia stawek każdy format jest wysyłany w ramach osobnego pytania o stawkę, w którym atrybuty takie jak kwalifikujące się identyfikatory rozliczeń są istotne dla formatu określonego w pytaniu.

Pytania o stawkę zawierające te formaty zostaną rozdzielone na osobne pytania o stawkę:

  • Baner
  • Wideo
  • Audio
  • Natywna

Przykład spłaszczenia formatu reklamy

Poniżej znajdziesz przykład uproszczonego żądania stawki w formacie JSON OpenRTB bez spłaszczenia formatu reklamy w porównaniu z odpowiednim zbiorem spłaszczonych żądań:

Przed spłaszczeniem

Po spłaszczeniu

Okazje

Możliwość wyświetlenia reklamy danemu licytującemu może dotyczyć różnych typów umów, oprócz aukcji otwartej. W przypadku spłaszczenia stawek w umowach wysyłane jest 1 żądanie dotyczące stawki na potrzeby aukcji otwartej i 1 żądanie na każdy typ umowy o kosztach stałych. W praktyce ograniczenia reklam mogą się różnić w zależności od aukcji i typów umów o stałych cenach. Na przykład w przypadku danej możliwości wyświetlania reklamy wideo, która jest dostępna zarówno w ramach aukcji otwartej, jak i umowy o stałych cenach, licytujący otrzyma oddzielne prośby o ofertę dla każdej z nich, ponieważ ograniczenia takie jak maksymalny czas trwania reklamy i możliwość wyświetlania reklam możliwych do pominięcia mogą się różnić. Dzięki temu uproszczenie zastosowane do możliwości reklamowej ułatwia Ci ustalenie ograniczeń reklam w przypadku aukcji otwartej i umowy o stałej cenie.

Maksymalny czas trwania reklamy wideo możliwej do pominięcia

Protokół Google i implementacja OpenRTB obsługują te pola dotyczące czasu trwania filmu i możliwości pominięcia reklamy:

Czas trwania Czas trwania reklamy możliwej do pominięcia Możliwość pominięcia
Protokół Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration nie dotyczy skip

Oznacza to, że chociaż protokół Google może mieć szczegółowy czas trwania reklamy pomijalnej i niepomijalnej, implementacja OpenRTB ma tylko jedną wartość maksymalnego czasu trwania.

Przed spłaszczaniem stawek wartość parametru maxduration w OpenRTB była ustawiana na mniejszą z wartości w polach max_ad_duration i skippable_max_ad_duration protokołu Google. Zmieniliśmy to zachowanie, aby w przypadku różnych wartości wysyłać 2 osobne pytania o stawkę: jedno z wartością maxduration dla możliwości z możliwością pominięcia reklam, a drugie – z możliwością niemożliwości pominięcia reklam.

Poniższe przykłady pokazują, jak żądanie protokołu Google jest tłumaczone na OpenRTB przed i po spłaszczeniu stawek. Odpowiednie żądanie protokołu Google ma max_ad_duration 15 i skippable_max_ad_duration 60.

Przykład max_ad_duration skip (prawda LUB fałsz)
Pierwotne żądanie bez spłaszczenia 15 true
Spłaszczone żądanie 1: reklama niemożliwa do pominięcia 15 false
Spłaszczone żądanie 2: możliwość pominięcia 60 true

Rozdzielanie pytań o stawkę na podstawie czasu trwania reklamy możliwe do pominięcia będzie stosowane tylko wtedy, gdy spełnione są te warunki:

  • Prośba zezwala na film.
  • Dozwolone są zarówno filmy możliwe do pominięcia, jak i te, których nie można pominąć, a ich maksymalne czasy trwania różnią się od siebie.
  • To żądanie kwalifikuje się do aukcji prywatnej lub otwartej.
  • Na koncie licytującego są aktywne punkty końcowe OpenRTB.

Aby zrezygnować z tego typu spłaszczenia, skontaktuj się z technicznym menedżerem konta.

Bloki reklamowe wideo

Pytania o stawkę dotyczące bloku reklamowego z wieloma możliwościami reklamowymi są spłaszczone, dzięki czemu każde pytanie o stawkę dotyczy osobnej możliwości reklamowej z tego bloku. Umożliwia to określanie stawek za wiele możliwości reklamowych w danym bloku.

Open Measurement

Open Measurement umożliwia określenie zewnętrznych dostawców, którzy zapewniają niezależne usługi pomiaru i weryfikacji reklam wyświetlanych w środowiskach aplikacji mobilnych.

Aby sprawdzić, czy wydawca obsługuje Open Measurement w pytaniu o stawkę, sprawdź, czy możliwość wyświetlania reklam wyklucza atrybut OmsdkType: OMSDK 1.0 znajdujący się w atrybutach kreacji, które można wykluczyć dla wydawcy. Znajdziesz go w atrybucie battr w przypadku banera lub filmu, w zależności od formatu.

Więcej informacji o interpretowaniu żądań stawek zawierających sygnały Open Measurement znajdziesz w tym artykule w Centrum pomocy o Open Measurement SDK.

Przykładowe pytania o stawkę

W następnych sekcjach znajdziesz przykładowe żądania stawek dla różnych typów reklam.

Baner aplikacji

OpenRTB Protobuf

OpenRTB w formacie JSON

Google (wycofane)

Reklama pełnoekranowa w aplikacji

OpenRTB Protobuf

OpenRTB w formacie JSON

Google (wycofane)

Pełnoekranowa reklama wideo w aplikacji

OpenRTB Protobuf

OpenRTB w formacie JSON

Google (wycofane)

Aplikacja natywna

OpenRTB Protobuf

OpenRTB w formacie JSON

Google (wycofane)

Film internetowy

OpenRTB Protobuf

OpenRTB w formacie JSON

Google (wycofane)

Baner internetowy na urządzenia mobilne dla licytujących na giełdzie

OpenRTB Protobuf

OpenRTB w formacie JSON

Natywna i wideo w wielu formatach

OpenRTB Protobuf

OpenRTB w formacie JSON

Google (wycofane)