Przetwarzanie żądania

Interakcja związana z określaniem stawek w czasie rzeczywistym rozpoczyna się, gdy Google wyśle do Twojej aplikacji pytanie o stawkę. Z tego przewodnika dowiesz się, jak zakodować aplikację, aby przetwarzać pytanie o stawkę.

Żądanie analizy

Google wysyła pytanie o stawkę w formacie OpenRTB JSON lub Protobuf jako ładunek żądania HTTP POST. Otrzymany format zależy od konfiguracji punktu końcowego. Przykład znajdziesz w artykule Przykładowe pytanie o stawkę.

Aby otrzymać zserializowany obiekt BidRequest, musisz przeanalizować tę prośbę. Jeśli używasz formatu Protobuf, musisz pobrać pliki openrtb.proto i openrtb-adx.proto ze strony danych referencyjnych i użyć ich do wygenerowania biblioteki, która może służyć do analizowania wiadomości BidRequest. Na przykład ten kod w C++ analizuje żądanie na podstawie ładunku POST w ciągu znaków: 

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

Gdy masz już BidRequest, możesz z nim pracować jako z obiektem, wyodrębniając i interpretując potrzebne pola. Na przykład w C++ iteracja po transakcjach w obiekcie `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

Pytanie o stawkę otrzymujesz, gdy zasoby reklamowe wydawcy są kierowane na co najmniej jedną z Twoich konfiguracji kierowania wstępnego. BidRequest.imp.ext.billing_id zostanie wypełnione identyfikatorami rozliczeniowymi kwalifikujących się kupujących i odpowiednimi konfiguracjami wstępnego kierowania. W przypadku zasobów reklamowych objętych umową możesz też znaleźć identyfikatory płatności powiązane z odpowiednimi kupującymi, korzystając z BidRequest.imp.pmp.deal.ext.billing_id. Podczas składania oferty można podać tylko identyfikatory rozliczeniowe kupujących uwzględnionych w pytaniu o stawkę.

Jeśli w pytaniu o stawkę znajduje się kilka identyfikatorów płatności, musisz określić identyfikator płatności kupującego, któremu chcesz przypisać swoją stawkę, za pomocą pola BidResponse.seatbid.bid.ext.billing_id.

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

Określanie zablokowanych kategorii

Gdy składasz stawkę, dołączona kreacja nie może mieć wykrytych kategorii, które zostały zablokowane przez wydawcę. W przeciwnym razie stawka zostanie odfiltrowana z aukcji.

Zablokowane kategorie dla wyświetlenia możesz znaleźć, sprawdzając pole BidRequest.bcat, które jest wypełnione kategoriami z taksonomii skonfigurowanej na Twoim koncie.

Poniższy przykład pokazuje zablokowane kategorie na podstawie skonfigurowanej taksonomii kategorii reklam:

Taksonomia treści IAB w wersji 1.0

// 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": {
    ...
  }
}

Pliki słownika

Pytanie o stawkę używa identyfikatorów zdefiniowanych w plikach słownika, które są dostępne na stronie danych referencyjnych.

Makra adresu URL licytującego

Opcjonalnie niektóre informacje z BidRequest można wstawiać do adresów URL punktów końcowych określania stawek za pomocą makr. Jeśli skonfigurujesz adres URL punktu końcowego z co najmniej 1 makrem, zostaną one rozwinięte, jeśli te informacje będą obecne w pytaniu o stawkę. Może to być przydatne np. wtedy, gdy chcesz przeprowadzić równoważenie obciążenia na podstawie informacji w BidRequest. Aby poprosić o obsługę nowych makr, skontaktuj się z menedżerem konta.

MakroOpis
%%GOOGLE_USER_ID%%

Zastąpiony identyfikatorem użytkownika Google znalezionym w BidRequest.user.id. Na przykład adres URL licytującego http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%% zostanie w momencie wysłania żądania zastąpiony adresem podobnym do http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl.

Jeśli identyfikator użytkownika Google jest nieznany, zostanie zastąpiony pustym ciągiem, a wynik będzie podobny do

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

Zastąpiony wartością 1, aby wskazać, że pytanie o stawkę pochodzi z urządzenia mobilnego, lub wartością 0 w innych przypadkach. Jest to oparte na wartości BidRequest.device.devicetype, gdzie urządzenia mobilne są oznaczone jako HIGHEND_PHONE (4) lub Tablet (5).
%%HAS_VIDEO%%

Zastąpiony wartością 1, aby wskazać, że pytanie o stawkę zawiera zasoby reklamowe wideo, lub wartością 0 w innych przypadkach. Zależy to od tego, czy w pytaniu o stawkę jest wypełnione pole BidRequest.imp.video.
%%IS_CTV%%

Zastąpiony wartością 1, aby wskazać, że pytanie o stawkę pochodzi z urządzenia CTV, lub wartością 0 w innych przypadkach. Zależy to od wartości BidRequest.device.devicetype. W przypadku Protobuf urządzenia CTV to CONNECTED_TV, CONNECTED_DEVICE lub SET_TOP_BOX, co w przypadku JSON odpowiada wartościom całkowitym 3, 6 lub 7.
%%HOSTED_MATCH_DATA%%

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

%%MOBILE_IS_APP%%

Zastąpiony przez 1, aby wskazać, że pytanie o stawkę dotyczy zasobów reklamowych aplikacji mobilnej, lub przez 0 w innych przypadkach. Zależy to od tego, czy pole BidRequest.app jest wypełnione.

Znajdowanie identyfikatora aplikacji mobilnej w adresie URL transakcji

W przypadku transakcji w aplikacjach mobilnych raportowane będą adresy URL w tym formacie:

mbappgewtimrzgyytanjyg4888888.com

Użyj dekodera base32, aby zdekodować część ciągu pogrubionego (gewtimrzgyytanjyg4888888).

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

Dekodowanie tej wartości: 

GEWTIMRZGYYTANJYG4======
 daje w rezultacie: 
1-429610587
 Ciąg znaków 429610587 to identyfikator aplikacji na iOS iFunny.

Oto kolejny przykład. Zgłoszony adres URL to: 

mbappgewtgmjug4ytmmrtgm888888.com
 Dekodowanie tej wartości: 
GEWTGMJUG4YTMMRTGM======
 daje w rezultacie: 
1-314716233
 Wynikiem 314716233 jest identyfikator aplikacji na iOS TextNow.

Znajdowanie nazwy aplikacji mobilnej na podstawie adresu URL transakcji

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

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Dekodowanie tej wartości: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 daje w rezultacie: 
air.com.hypah.io.slither
 Wynik odpowiada aplikacji na Androida slither.io.

Pola Otwartego ustalania stawek

Pytania o stawkę wysyłane do oferentów z giełd i sieci uczestniczących w Otwartym ustalaniu stawek są podobne do tych, które są wysyłane do kupujących korzystających z Authorized Buyers w przypadku 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 zastosowania. Obejmują one:

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

Zawiera kod sieci Ad Managera wydawcy, a po nim hierarchię jednostek reklamowych rozdzieloną ukośnikami.

Na przykład będzie to wyglądać mniej więcej tak:/1234/cruises/mars.
BidRequest.user.data.segment

Powtarzające się pary klucz-wartość wysyłane od wydawcy do podmiotu ustalającego stawki na giełdzie.

Możesz określić, że wartości są parami klucz-wartość wysyłanymi przez wydawcę, gdy parametr BidRequest.user.data.name ma wartość “Publisher Passed”.

Deklarowanie dozwolonych dostawców

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

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

  1. Niektórzy dostawcy nie muszą być deklarowani. Są oni wymienieni na liście Dostawcy zewnętrzni z certyfikatem Ad Managera.
  2. Inni dostawcy mogą uczestniczyć w aukcji tylko wtedy, gdy zostaną zadeklarowani w BidRequest:
    • W polu BidRequest pole BidRequest.imp.ext.allowed_vendor_type określa, których dostawców sprzedawca dopuszcza. Dostawcy, którzy zostaną wysłani w ramach parametru allowed_vendor_type, są wymienieni w pliku słownika vendors.txt.

Przykładowe pytanie o stawkę

Poniższe przykłady przedstawiają zrozumiałe dla człowieka próbki żądań Protobuf i JSON.

OpenRTB Protobuf

OpenRTB JSON

Aby przekonwertować pytanie o stawkę na postać binarną, taką jak ładunek POST w rzeczywistym żądaniu, możesz wykonać te czynności (w C++). Pamiętaj jednak, że nie dotyczy to formatu 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 kupujących korzystających z programu Authorized Buyers, a także dla giełd i sieci korzystających z Otwartego ustalania stawek.

Informacje zwrotne w czasie rzeczywistym są wypełniane w BidRequest.ext.bid_feedback na podstawie wyników co najmniej jednej stawki złożonej wcześniej. Można ich używać do wyszukiwania szczegółów, takich jak to, czy stawka wygrała aukcję, lub minimalna stawka potrzebna do wygrania aukcji. Aby włączyć opinie w czasie rzeczywistym, skontaktuj się z menedżerem konta.

Oprócz domyślnych pól wysyłanych w ramach opinii o odpowiedzi na pytanie o stawkę możesz też wysyłać w odpowiedzi na pytanie o stawkę dane niestandardowe za pomocą pola BidResponse.seatbid.bid.ext.event_notification_token. Wartość event_notification_token to dowolne dane znane tylko oferentowi, które mogą pomóc w debugowaniu, np. nowy identyfikator kierowania lub identyfikator licytowania reprezentujący nową taktykę albo metadane powiązane z kreacją znane tylko oferentowi. Szczegółowe informacje znajdziesz w pliku bufora protokołu rozszerzeń OpenRTB.

Gdy Authorized Buyers wysyła do licytującego pytanie o stawkę, licytujący odpowiada BidResponse. Jeśli licytujący ma włączone odpowiedzi na pytania o stawkę w czasie rzeczywistym, w kolejnym pytaniu o stawkę Authorized Buyers wysyła odpowiedź na pytanie o stawkę w 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;

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

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 przesyłania informacji o cenie. Więcej informacji znajdziesz w artykule Jak zrezygnować.

Odpowiedź w czasie rzeczywistym zawiera identyfikator pytania o stawkę i jedną z tych informacji:

Wynik aukcji Odpowiedzi w czasie rzeczywistym
Kupujący nie przesłał oferty. 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ł aukcję. Kod stanu kreacji 79 (przelicytowana na aukcji).
Kupujący przesłał stawkę, która wygrała aukcję. Cena rozliczeniowa i kod stanu kreacji 1.

W przypadku wyświetlenia reklamy w aplikacji i kodu stanu kreacji 83 wydawca aplikacji mógł używać kaskady zapośredniczenia, a zatem wygrywająca stawka konkurowała z innym popytem w kaskadowym łańcuchu przekazywania wydawcy. Dowiedz się, jak korzystać z atrybutu sampled_mediation_cpm_ahead_of_auction_winner podczas określania stawek

Przykład

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

OpenRTB Protobuf

OpenRTB JSON

Tworzenie modelu określania stawek na potrzeby aukcji pierwszej ceny

Po złożeniu oferty w aukcji pierwszej ceny otrzymasz w czasie rzeczywistym informacje zwrotne, w tym pola minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner, jeśli oferta nie została odfiltrowana z aukcji. Te sygnały mogą być wykorzystywane w logice określania stawek, aby określić, o ile wyższa lub niższa mogła być Twoja stawka, aby uzyskać wyświetlenie.

  • minimum_bid_to_win: minimalna stawka, jaką można było złożyć, aby wygrać aukcję określania stawek w czasie rzeczywistym. Jeśli wygrasz aukcję, będzie to najniższa stawka, jaką możesz złożyć, aby wygrać. Jeśli aukcja została przegrana, będzie to stawka zwycięska.
  • sampled_mediation_cpm_ahead_of_auction_winner: jeśli w łańcuchu zapośredniczenia są inne sieci, wartość tego pola to cena reprezentująca przykładową stawkę z jednej z kwalifikujących się sieci zapośredniczenia, która była wyższa niż stawka zwycięzcy aukcji, ważona przez oczekiwany współczynnik wypełnienia. Jeśli żadna z sieci w łańcuchu zapośredniczenia nie ma wypełnić żądania lub wydawca nie korzysta z zapośredniczenia za pomocą pakietu SDK, wartość tego parametru będzie wynosić 0.

Jak to działa

Aby opisać obliczenia używane do określania możliwych wartości minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner, musimy najpierw zdefiniować te pojęcia:

  • Poniżej przedstawiamy wartości CPM w łańcuchu zapośredniczenia w porządku malejącym:
    \[C_1, C_2, …, C_n\]
  • Poniżej przedstawiamy odpowiednie współczynniki wypełnienia dla wartości CPM w łańcuchu zapośredniczenia:
    \[f_1, f_2, …, f_n\]
  • Poniżej znajduje się funkcja służąca do określania oczekiwanego CPM i jego prawdopodobieństwa na podstawie elementu łańcucha zapośredniczenia \(i\)na podstawie podanego 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, który wygra aukcję, będzie wyglądać tak:
    \[\{C_1, C_2, …, C_K, W\}\]
    gdzie \(W\) to stawka wygrywająca, a \(C_K > W >= C_{K+1}\)
  • Cena minimalna jest oznaczona jako \(F\).
  • Druga najwyższa stawka jest oznaczona symbolem \(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 dla przegranego 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 zarówno z określania stawek w czasie rzeczywistym, jak i z łańcucha zapośredniczenia pakietu SDK w sposób opisany poniżej:

Łańcuch zapośredniczenia SDK Oczekiwany 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 te wyniki:

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

Poniżej znajdziesz przykład obliczania wartości i prawdopodobieństw dla elementów minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner w przypadku wygranej stawki.

minimum_bid_to_win Prawdopodobieństwo
\(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		 Prawdopodobieństwo
\(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 aukcję

Poniżej znajdziesz przykład obliczania wartości i prawdopodobieństw dla elementów minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner w przypadku utraconych stawek.

minimum_bid_to_win Prawdopodobieństwo
\(max(F, W) = $1.00\) \(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Prawdopodobieństwo
\(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 stawek to proces przetwarzania jednego złożonego pytania o stawkę na wiele pytań o stawkę, które są wysyłane do Twojej aplikacji.BidRequest Gdy pytanie o stawkę zostanie spłaszczone, możesz sprawdzić, które pytania o stawkę były częścią pierwotnego pytania, ponieważ będą miały identyczną wartość w polu BidRequest.ext.google_query_id.

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

Formaty reklam

Niektóre możliwości reklamowe mogą akceptować wiele formatów. W przypadku rozdzielania stawek każdy format jest wysyłany w ramach osobnego pytania o stawkę, w którym atrybuty takie jak kwalifikujące się identyfikatory płatności są powiązane z formatem określonym w żądaniu.

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

  • Baner
  • Wideo
  • Audio
  • Natywna

Przykład spłaszczania formatu reklamy

Poniżej znajdziesz przykład uproszczonego pytania o stawkę w formacie JSON OpenRTB bez spłaszczania formatu reklamy w porównaniu z równoważnym zestawem spłaszczonych pytań:

Wstępne spłaszczenie

Po spłaszczeniu

Okazje

Możliwość reklamowa w przypadku danego licytującego może dotyczyć różnych typów umów, a nie tylko aukcji otwartej. W przypadku rozdzielania stawek w umowach wysyłane jest jedno pytanie o stawkę na aukcję otwartą i jedno na każdy typ umowy o stałej cenie. W praktyce ograniczenia dotyczące reklam mogą się różnić w zależności od aukcji i rodzajów stałych ofert cenowych. Na przykład w przypadku danej możliwości reklamowej wideo, która jest dostępna zarówno w aukcji otwartej, jak i w stałej ofercie cenowej, licytujący otrzyma osobne pytania o stawkę dla każdej z nich, w których mogą się różnić ograniczenia, takie jak maksymalny czas trwania reklamy i to, czy dozwolone są reklamy możliwe do pominięcia. Dzięki temu spłaszczenie zastosowane do możliwości reklamowej ułatwia rozpoznawanie ograniczeń reklamy w przypadku aukcji otwartej i stałej oferty cenowej.

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 wykorzystuje rozdzielanie stawek do rozróżniania tych wartości za pomocą istniejących pól BidRequest.video.maxduration i BidRequest.video.skip.

Oto przykład spłaszczania 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 to 60.

Przykład max_ad_duration skip (prawda LUB fałsz)
Oryginalna prośba bez spłaszczania 15 true
Spłaszczone żądanie nr 1: reklama niemożliwa do pominięcia 15 false
Spłaszczone żądanie 2: można pominąć 60 true

Rozdzielanie pytań o stawkę na podstawie czasu trwania filmu możliwego do pominięcia będzie miało miejsce tylko wtedy, gdy zostaną spełnione te warunki:

  • Żądanie zezwala na film.
  • Zezwól na reklamy wideo możliwe i niemożliwe do pominięcia, a maksymalne czasy trwania tych reklam różnią się od siebie.
  • To żądanie kwalifikuje się do aukcji prywatnej lub otwartej.

Aby zrezygnować z tego typu uśredniania, 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 o różnych maksymalnych czasach trwania w zależności od możliwości pominięcia, parametr skip zostanie ustawiony na true, a parametr maxduration zostanie ustawiony na krótszy czas trwania spośród ograniczeń dotyczących reklam możliwych i niemożliwych do pominięcia.

Bloki reklamowe wideo

Pytania o stawkę dotyczące bloku reklam wideo z wieloma możliwościami reklamowymi są rozdzielane, tak aby każde pytanie dotyczyło pojedynczej możliwości reklamowej w tym bloku. Umożliwia to składanie ofert w przypadku wielu możliwości wyświetlania reklam w danym bloku.

Open Measurement

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

Aby sprawdzić, czy wydawca obsługuje Open Measurement, sprawdź, czy w możliwości reklamowej wykluczono atrybut OmsdkType: OMSDK 1.0, który znajduje się w atrybutach kreacji, które wydawca może wykluczyć. Znajduje się on w atrybucie battr dla formatu Baner lub Film, w zależności od formatu.

Więcej informacji o interpretowaniu pytań o stawki zawierających sygnały Open Measurement znajdziesz w artykule w Centrum pomocy na temat pakietu SDK Open Measurement.

Przykładowe pytania o stawkę

W sekcjach poniżej znajdziesz przykładowe żądania stawek dla różnych typów reklam.

Baner aplikacji

OpenRTB Protobuf

OpenRTB JSON

Reklama pełnoekranowa w aplikacji

OpenRTB Protobuf

OpenRTB JSON

Pełnoekranowa reklama wideo w aplikacji

OpenRTB Protobuf

OpenRTB JSON

Aplikacja natywna

OpenRTB Protobuf

OpenRTB JSON

Film internetowy

OpenRTB Protobuf

OpenRTB JSON

Baner w przeglądarce mobilnej dla oferenta giełdy

OpenRTB Protobuf

OpenRTB JSON

Natywne i wideo w wielu formatach

OpenRTB Protobuf

OpenRTB JSON