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

Google wysyła żądanie stawki zaszyfrowane w formacie OpenRTB JSON lub Protobuf, dołączone jako ładunek żądania HTTP POST. Format otrzymanych danych zależy od konfiguracji punktu końcowego. Przykład znajdziesz w sekcji Przykładowe żądanie stawki.

Aby otrzymać serializowany obiekt BidRequest, musisz przeanalizować to żądanie. Jeśli używasz formatu Protobuf, musisz pobrać pliki openrtb.proto i openrtb-adx.proto ze strony dane referencyjne, a następnie użyć ich do wygenerowania biblioteki, której można użyć do zanalizowania wiadomości BidRequest. Na przykład ten kod w języku C++ analizuje żądanie, które zawiera ładunek 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” w 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 będzie 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, korzystając z funkcji 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 adresu URL oferenta

Opcjonalnie możesz wstawiać niektóre informacje z BidRequest do adresów URL punktów określania stawek za pomocą makr. Jeśli skonfigurujesz adres URL punktu końcowego z co najmniej 1 makro, zostaną one rozwinięte, jeśli te informacje są obecne w prośbie o określenie stawki. Może to być przydatne, jeśli chcesz na przykład wykonać równoważenie obciążenia na podstawie informacji w BidRequest. Aby uzyskać pomoc dotyczącą nowych makr, skontaktuj się z menedżerem konta.

MakroOpis
%%GOOGLE_USER_ID%%

Zastąpiono go identyfikatorem użytkownika Google znajdującym się w komórce BidRequest.user.id. Na przykład adres URL licytującego http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% zostanie zastąpiony podczas wysyłania żądania przez wartość http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl.

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ąpiony wartością 1, aby wskazać, że żądanie stawki pochodzi z urządzenia mobilnego, lub wartością 0 w innych przypadkach. Jest ona określana na podstawie wartości parametru BidRequest.device.devicetype, gdzie urządzenia mobilne są oznaczone wartością HIGHEND_PHONE (4) lub Tablet (5).
%%HAS_VIDEO%%

Zastąpiony przez 1, aby wskazać, że żądanie oferty zawiera zasoby reklamowe wideo, lub 0 w innym przypadku. To zależy od tego, czy w pytaniu o stawkę jest podana wartość parametru BidRequest.imp.video.
%%HOSTED_MATCH_DATA%%

Zastąpiony wartością na podstawie BidRequest.user.buyeruid.

%%MOBILE_IS_APP%%

Zastąpiony przez 1, aby wskazać, że żądanie stawki dotyczy zasobów reklamowych w aplikacji mobilnej, lub 0 w innym przypadku. To zależy od tego, czy pole BidRequest.app jest wypełnione.

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 kody dziesiętne, użyj dekodera base-32 (gewtimrzgyytanjyg4888888).

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. Adres URL zawarty w raporcie to: 

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 między innymi:

OpenRTB Szczegóły
BidRequest.imp.ext.dfp_ad_unit_code

Zawiera kod sieci wydawcy w Ad Managerze, a za nim hierarchię jednostek reklamowych, rozdzielone ukośnikami.

Na przykład:/1234/cruises/mars.
BidRequest.user.data.segment

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 to żądania Protobuf i JSON w formie zrozumiałej dla człowieka.

OpenRTB Protobuf

OpenRTB w formacie JSON

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.

W polu BidRequest.ext.bid_feedback wyświetlane są informacje w czasie rzeczywistym na podstawie wyniku co najmniej 1 wcześniejszej stawki. Można z nich się dowiedzieć, czy stawka wygrała aukcję, lub jaka jest minimalna stawka potrzebna do wygrania aukcji. Aby włączyć opinie w czasie rzeczywistym, skontaktuj się z menedżerem konta.

Oprócz pól domyślnych wysyłanych w informacjach zwrotnych o określaniu stawek 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. Szczegółowe informacje znajdziesz w pliku OpenRTB Extensions Protocol Buffer.

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, w kolejnych żądaniach stawek Authorized Buyers wysyła informacje zwrotne dotyczące 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 protokolach:

OpenRTB Protobuf

OpenRTB w formacie JSON

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 stawka przegrała 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. Ta wartość zostanie ustawiona na 0, jeśli żadna z sieci w łańcuchu zapośredniczenia nie będzie w stanie wypełnić żądania lub jeśli wydawca nie korzysta z zapośredniczenia za pomocą pakietu SDK.

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 przedstawiono 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 prawdopodobieństwem \(f_i\); \(0\) z prawdopodobieństwem \(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 dla 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 ł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 uzyskano następujące wyniki:

Aukcja RTB CPM
Auction Winner (W) 1 USD
Drugie miejsce w aukcji (R) 0,05 USD
Cena minimalna (F) 0 USD
Stawka, która wygrała aukcję

Poniżej przedstawiamy przykład obliczania wartości i prawdopodobieństwo dla minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner w przypadku wygranego udziału w kliknięciu.

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 prawdopodobieństwo dla parametrów minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner w przypadku przegranych ofert.

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ęść oryginalnego żą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 znajduje się 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 preferencyjnych wysyłane jest 1 żądanie stawki na aukcję otwartą 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 stawkach. 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 stawkach, licytujący otrzyma oddzielne żądania stawek 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.

Możliwość pominięcia i czas trwania filmu

Specyfikacja OpenRTB nie zawiera osobnych pól do określania maksymalnego czasu trwania reklam wideo możliwych i niemożliwych do pominięcia. Wdrożenie Google korzysta z spłaszczenia stawek, aby rozróżniać te typy za pomocą istniejących pól BidRequest.video.maxduration i BidRequest.video.skip.

Poniżej przedstawiamy przykład spłaszczenia zasobów reklamowych wideo, gdy maksymalny czas trwania reklamy niemożliwej do pominięcia wynosi 15, a maksymalny czas trwania reklamy możliwej do pominięcia wynosi 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 jest tylko wtedy, gdy spełnione są te warunki:

  • Prośba zezwala na film.
  • Dozwolone są zarówno reklamy wideo 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.

Aby zrezygnować z tego typu spłaszczenia, skontaktuj się z technicznym menedżerem konta. Gdy ta opcja jest wyłączona, a wydawca zezwala na reklamy wideo możliwe i niemożliwe do pominięcia z różnymi maksymalnymi czasami trwania zależnymi od możliwości pominięcia, parametr skip zostanie ustawiony na true, a parametr maxduration – na krótszy czas trwania między ograniczeniami dotyczącymi reklam możliwych i niemożliwych do pominięcia.

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 wyświetlania reklam 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 zapytań o stawki zawierających sygnały Open Measurement znajdziesz w tym artykule w Centrum pomocy dotyczącym 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

Reklama pełnoekranowa w aplikacji

OpenRTB Protobuf

OpenRTB w formacie JSON

Pełnoekranowa reklama wideo w aplikacji

OpenRTB Protobuf

OpenRTB w formacie JSON

Aplikacja natywna

OpenRTB Protobuf

OpenRTB w formacie JSON

Film internetowy

OpenRTB Protobuf

OpenRTB w formacie JSON

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