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 napisać kod aplikacji, aby przetwarzać żądanie stawki.

Prośba o analizę

Google wysyła żądanie stawki 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 komunikatu 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

Żądanie stawki 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 rozliczeniowe powiązane z odpowiednimi kupującymi za pomocą funkcji 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 podać identyfikator płatności kupującego, któremu chcesz przypisać stawkę, w polu 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 wydawca zablokował. W przeciwnym razie stawka zostanie odfiltrowana z aukcji.

Zablokowane kategorie w przypadku wyświetlenia możesz sprawdzić w polu BidRequest.bcat, które jest wypełnione kategoriami z taksonomii skonfigurowanej na Twoim koncie.

Przykład poniżej 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

Żądanie stawki 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 żądaniu stawki. 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ąpiono 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 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 żądanie stawki 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 żądanie stawki zawiera zasoby reklamowe wideo, lub wartością 0 w innych przypadkach. Zależy to od tego, czy w żądaniu stawki znajduje się wartość parametru BidRequest.imp.video.
%%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 w 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 raporty będą zawierać adresy URL podobne do tego:

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

Żądania stawek wysyłane do oferentów z giełd i sieci uczestniczących w Otwartym ustalaniu stawek są podobne do żądań wysyłanych do kupujących z programu Authorized Buyers uczestniczących w standardowym określaniu 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 przez wydawcę 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 poznać 2 różne możliwości deklarowania dostawców technologii:

  1. Niektórzy dostawcy nie muszą być deklarowani. Są oni wymienieni na liście Certyfikowani dostawcy zewnętrzni Ad Managera.
  2. Inni dostawcy mogą uczestniczyć w programie tylko wtedy, gdy zostaną zgłoszeni w BidRequest:
    • W polu BidRequest pole BidRequest.imp.ext.allowed_vendor_type określa, na których dostawców zezwala sprzedawca. 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ą czytelne dla człowieka próbki żądań Protobuf i JSON.

OpenRTB Protobuf

OpenRTB JSON

Aby przekonwertować żądanie stawki na postać binarną, taką jak w przypadku ładunku POST w prawdziwym żądaniu, możesz wykonać te czynności (w C++). Pamiętaj jednak, że nie ma to zastosowania do 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
  }
}

Opinie w czasie rzeczywistym

Informacje zwrotne w czasie rzeczywistym są dostępne dla kupujących w programie 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 1 wcześniej złożonej stawki. Możesz ich używać do znajdowania szczegółów, np. czy stawka wygrała aukcję lub jaka była 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 żądanie stawki możesz też wysyłać w odpowiedzi na żądanie stawki 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 protokołu buforowania OpenRTB Extensions.

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

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

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

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];
}

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 Opinie w czasie rzeczywistym
Kupujący nie przesłał oferty. Nic.
Kupujący przesłał stawkę, która została odfiltrowana przed dotarciem na aukcję. 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ć zapośredniczenia kaskadowego, a zatem wygrywająca stawka konkurowała z innym popytem w łańcuchu zapośredniczenia kaskadowego wydawcy. Dowiedz się, jak korzystać z 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 stawki 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 stawka nie została odfiltrowana z aukcji. Te sygnały mogą być wykorzystywane w logice ustalania stawek, aby określić, o ile wyższa lub niższa mogła być Twoja stawka, aby wygrać wyświetlenie.

  • minimum_bid_to_win: minimalna stawka, jaką można było złożyć, aby wygrać aukcję w ramach ustalania 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 zwycięska stawka.
  • 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ż zwycięska stawka w aukcji, ważona przez oczekiwany współczynnik wypełnienia. Jeśli żadna z sieci w łańcuchu mediacji nie ma wyświetlać reklam lub wydawca nie korzysta z mediacji 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 mediacji:
    \[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 mediacji \(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 zwycięski łańcuch zapośredniczenia będzie wyglądać tak:
    \[\{C_1, C_2, …, C_K, W\}\]
    gdzie \(W\) to zwycięska stawka, 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 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 otrzymaliśmy te dane:

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 stawek, które przegrały.

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 pytań o stawkę to proces przetwarzania jednego złożonego pytania o stawkęBidRequest na wiele pytań o stawkę, które są wysyłane do Twojej aplikacji. 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.

Wygładzanie 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 pytań o stawkę każdy format jest wysyłany w ramach osobnego pytania o stawkę, w którym atrybuty takie jak kwalifikujące się identyfikatory rozliczeniowe są powiązane z formatem określonym w żądaniu.

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

  • Baner
  • Wideo
  • Audio
  • Natywna

Przykład spłaszczania formatu reklamy

Poniżej znajdziesz przykład uproszczonego żądania stawki w formacie JSON OpenRTB bez spłaszczania formatu reklamy w porównaniu z równoważnym zestawem spłaszczonych żądań:

Wstępne spłaszczenie

Po spłaszczeniu

Okazje

Możliwość wyświetlenia reklamy w przypadku danego oferenta może dotyczyć różnych rodzajów umów, a nie tylko aukcji otwartej. W przypadku spłaszczania stawek w umowach wysyłane jest jedno żądanie stawki na aukcję otwartą i jedno na każdy typ umowy o stałej cenie. W praktyce ograniczenia reklam mogą się różnić w zależności od aukcji i rodzajów transakcji o stałej cenie. Na przykład w przypadku danej możliwości wyświetlenia reklamy wideo, która jest dostępna zarówno w aukcji otwartej, jak i w transakcji o stałej cenie, reklamodawca otrzyma osobne żądania stawek 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 wyświetlenia reklamy ułatwia rozpoznawanie ograniczeń reklamy 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 wykorzystuje spłaszczanie 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 wyświetlenia reklamy są rozdzielane, tak aby każde pytanie dotyczyło pojedynczej możliwości wyświetlenia reklamy 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 środowiskach aplikacji mobilnych.

Aby sprawdzić, czy wydawca obsługuje Open Measurement, sprawdź, czy w pytaniu o stawkę wykluczony jest 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 Wideo, 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