Przetwarzanie żądania

Interakcja z określaniem stawek w czasie rzeczywistym rozpoczyna się, gdy Google wysyła pytanie o stawkę do Twojej aplikacji. Ten przewodnik wyjaśnia, jak zakodować aplikację pod kątem do przetwarzania pytania o stawkę.

Żądanie analizy

Google wysyła pytanie o stawkę jako zserializowany bufor protokołu dołączony jako ładunek binarny żądania HTTP POST. Content-Type jest ustawiony na application/octet-stream Przykładowe pytanie znajdziesz w sekcji Przykładowe pytanie o stawkę.

Musisz przeanalizować to żądanie w instancji BidRequest . Pole BidRequest jest zdefiniowane w zakresie realtime-bidding.proto, które znajdziesz na stronie z danymi referencyjnymi. Możesz przeanalizować wiadomość za pomocą metody ParseFromString() w wygenerowanej klasie dla argumentu BidRequest Na przykład ten kod w C++ analizuje żądanie dla danego ł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 już masz BidRequest, możesz używać go jako wyodrębniania i interpretowania potrzebnych pól. Na przykład w polu C++:

for (int i = 0; i < bid_request.adslot_size(); ++i) {
  const BidRequest_AdSlot& adslot = bid_request.adslot(i);
  // Decide what to bid on adslot.
}

Niektóre informacje wysłane w aplikacji BidRequest, na przykład Użytkownik Google Identyfikator, język i lokalizacja geograficzna nie zawsze są dostępne. Jeśli masz grupy reklam z kierowaniem wstępnym, które korzystają z nieznanych informacji wyświetlenia, grupy reklam nie zostaną dopasowane. W przypadkach, gdy brakuje w przypadku warunków kierowania wstępnego pytania o stawkę nie mają znaczenia. wysyłane z pominiętymi informacjami.

Informacje o grupie reklam z kierowaniem wstępnym znajdziesz na stronie MatchingAdData grupę na każdą zmienną AdSlot. Zawiera on identyfikator pierwszej pasującej grupy reklam z grupy reklam z kierowaniem wstępnym, która skłoniła Google do wyświetlenia wysyła pytanie o stawkę, czyli grupę reklam i kampanię, które zostały obciążone jeśli Twoja odpowiedź wygra aukcję dla tego wyświetlenia. W przypadku określonych wartości okoliczności, musisz wyraźnie określić billing_id dla w BidResponse.AdSlot, np. gdy BidRequest.AdSlot ma więcej niż jeden element typu matching_ad_data. Więcej informacji na temat ograniczeń dotyczących treści stawki: realtime-bidding.proto.

Pliki słownika

Pytanie o stawkę wykorzystuje identyfikatory zdefiniowane w plikach słownika, czyli dostępne w danych referencyjnych stronę.

Makra adresu URL stawki

Opcjonalnie niektóre pola BidRequest można wstawić do adres URL użyty w żądaniu HTTP POST, Jest to przydatne, jeśli na przykład używasz uproszczony frontend, który równoważy obciążenie z wieloma backendami za pomocą wartości od wniosku. Skontaktuj się z technicznym menedżerem konta, by poprosić o pomoc nowych makr.

MakroOpis
%%GOOGLE_USER_ID%%

Zastąpione przez: google_user_id od BidRequest. Na przykład adres URL licytującego 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
 zostanie zastąpione przez coś w rodzaju 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
 w odpowiednim momencie.

Jeśli identyfikator użytkownika Google jest nieznany, pusty ciąg jest zastępowany znakiem wynik podobny do

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

Podczas połączenia zamieniono na 1 lub 0 has_mobile() użytkownika BidRequest.
%%HAS_VIDEO%%

Zastępowana wartością 1 (prawda) lub 0 (fałsz) podczas połączenia z: has_video() użytkownika BidRequest.
%%HOSTED_MATCH_DATA%%

Zastąpiono wartością pola hosted_match_data. od BidRequest.
%%MOBILE_IS_APP%%

Zastępowana wartością 1 (prawda) lub 0 (fałsz) z pola mobile.is_app użytkownika BidRequest.

Znajdowanie identyfikatora aplikacji mobilnej z adresu URL transakcji

Transakcje dotyczące aplikacji mobilnych będą zawierać adresy URL podobne do tych:

mbappgewtimrzgyytanjyg4888888.com

Zdekoduj pogrubioną część ciągu za pomocą dekodera base-32 (gewtimrzgyytanjyg4888888).

Za pomocą adresu online , ale musisz zapisać wielkie litery i zastąpić końcowego Elementy typu 8 z = wartościami.

Dlatego dekoduję tę wartość: 

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

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

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

Znajdowanie nazwy aplikacji mobilnej z adresu URL transakcji

Oto przykład uzyskania nazwy aplikacji. Zgłoszony adres URL wygląda tak: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Dekodowanie tej wartości: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 daje: 
air.com.hypah.io.slither
 Wynik jest taki sam jak aplikacja na Androida. slither.io.

Pola Otwartego ustalania stawek

Pytania o stawkę wysłane do giełd i sieciowych licytujących uczestniczących w programie Open Określanie stawek jest podobne do tych w Authorized Buyers, którzy uczestniczą w standardowym określania stawek w czasie rzeczywistym. Klienci korzystający z Otwartego ustalania stawek otrzymają niewielką liczbę dodatkowych pól, a kilka z istniejących pól może mieć alternatywne zastosowania. Te należy uwzględnić następujące elementy:

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

Zawiera kod sieci Ad Managera wydawcy, po którym następuje reklama. hierarchii jednostek rozdzielanych ukośnikami.

Mogłoby to wyglądać np. z użyciem formatowania podobnego do: /1234/cruises/mars
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

Powtórzone pary klucz-wartość wysłane od wydawcy do systemu licytującego na giełdzie.

Można ustalić, że wartości są parami klucz-wartość wysyłanymi przez metodę Wydawca, gdy BidRequest.user.data[].name ma wartość “Publisher Passed”

Zadeklaruj dozwolonych dostawców

dostawców technologii, którzy świadczą usługi takie jak badania, remarketing i wyświetlanie reklam może odgrywać rolę w interakcjach między kupującymi i sprzedawcami. Tylko dostawcy, którzy zostali zweryfikowani przez Google pod kątem udziału w programie Authorized Buyers; interakcje.

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

  1. Niektórych dostawców nie trzeba deklarować. ci dostawcy są wyszczególnini w Centrum pomocy Authorized Buyers.
  2. Pozostali dostawcy mogą uczestniczyć tylko wtedy, gdy są zadeklarowani w BidRequest i BidResponse:
    • BidRequest, allowed_vendor_type określa dostawców, na których używanie zezwala sprzedawca. Dostawcy, którzy zostaną przekierowani pole allowed_vendor_type BidRequest jest wymienionych w Vendors.txt słownik.
    • W polu BidResponse w polu vendor_type określa, z którego z tych dozwolonych dostawców kupujący chce skorzystać.

Przykładowe pytanie o stawkę

Poniższe przykłady przedstawiają czytelne dla człowieka próbki Protobuf i Żądania JSON.

Google

Plik JSON OpenRTB

Bufor protokołu OpenRTB

Aby przekonwertować pytanie o stawkę na postać binarną, jak w tagu POST w prawdziwym żądaniu możesz wykonać poniższe czynności (w C++). Uwaga: Nie dotyczy to jednak formatu JSON OpenRTB.

string text_format_example = /* example from above */;
BidRequest bid_request;
if (TextFormat::ParseFromString(text_format_example, &bid_request)) {
  string post_payload;
  if (bid_request.SerializeToString(&post_payload)) {
    // post_payload is a binary serialization of the protocol buffer
  }
}

Remarketing

Authorized Buyers przekazuje w pytaniach o stawkę identyfikator wyświetlania reklam mobilnych aplikacji mobilnej. Identyfikatorem wyświetlania reklam mobilnych może być IDFA w iOS lub identyfikatora wyświetlania reklam na urządzeniu z Androidem, który jest wysyłany przez %%EXTRA_TAG_DATA%% w tagu JavaScript zarządzanym przez Authorized Buyers.

Makro %%ADVERTISING_IDENTIFIER%% umożliwia kupującym otrzymanie Identyfikator IDFA w iOS lub identyfikator wyświetlania reklam na Androidzie podczas renderowania. Zwraca ono zaszyfrowany bufor protokołu MobileAdvertisingId podobny do: %%EXTRA_TAG_DATA%%:

message MobileAdvertisingId {
  optional bytes advertising_id = 1;
  optional int32 user_id_type = 2;
}

user_id_type jest jedną z wartości zdefiniowanych w parametrze enum AdxMobileIdType:

enum AdxMobileIdType {
  MOBILE_ID_UNKNOWN = 0,
  IDFA = 1,
  ANDROID_ID = 2,
};

Listy użytkowników możesz tworzyć na podstawie mobilnych identyfikatorów wyświetlania reklam, korzystając z identyfikatorów wyświetlania reklam. zebranych podczas renderowania wyświetleń. Te listy użytkowników można prowadzić na Twoim serwerze lub na naszym. Do tworzenia list użytkowników na serwerach Google możesz używać narzędzia do przesyłania zbiorczego.

Gdy identyfikator wyświetlania reklam mobilnych pasuje do listy użytkowników, możesz go używać do wyświetlania reklam remarketingu.

Opinie w czasie rzeczywistym

Użytkownicy Authorized Buyers mogą też korzystać z opinii w czasie rzeczywistym, jak giełdy i sieci korzystające z Otwartego ustalania stawek.

Odpowiedź na stawkę jest obsługiwana w przypadku kolejnego pytania o stawkę w przypadku Protokołu AdX i OpenRTB. W przypadku OpenRTB jest on przesyłany w ciągu BidRequestExt

Oprócz domyślnych pól przesłanych w opinii na temat odpowiedzi na stawkę możesz też wysyłać też dane niestandardowe w odpowiedzi na stawkę (w AdX Proto lub OpenRTB) przy użyciu funkcji event_notification_token, która jest zwracana w funkcji BidResponse event_notification_token to arbitralne dane znane tylko licytującym, które mogą pomóc w debugowaniu, np. nowy identyfikator kierowania lub identyfikator ustalania stawek reprezentujący nową taktykę; związane z kreacją znane tylko licytującemu. Więcej informacji: Więcej informacji: OpenRTB Extensions Protocol Buffer dla RTB i AdX Proto dla AdX.

Gdy kupujący z Authorized Buyers wysyłają pytanie o stawkę, licytujący odpowiada dzięki funkcji BidResponse. Jeśli licytujący ma włączone przesyłanie informacji zwrotnych w czasie rzeczywistym, w kolejnym pytaniu o stawkę usługa Authorized Buyers wysyła opinię na temat odpowiedź w wiadomości BidResponseFeedback, tak jak poniżej:

message BidResponseFeedback {
  // The unique id from BidRequest.id
  optional bytes request_id = 1;

  // The index of the BidResponse_Ad if there was more than one. The index
  // starts at zero for the first creative.
  optional int32 creative_index = 2;

  // The status code for the ad. See creative-status-codes.txt in the
  // technical documentation for a list of ids.
  optional int32 creative_status_code = 3;

  // If the bid won the auction, this is the price paid in your account
  // currency. If the bid participated in the auction but was out-bid, this
  // is the CPM that should have been exceeded in order to win. This is not
  // set if the bid was filtered prior to the auction, if the publisher or
  // winning bidder has opted out of price feedback or if your account has
  // opted out of sharing winning prices with other bidders. For first-price
  // auctions, minimum_bid_to_win is populated instead of this field.
  optional int64 cpm_micros = 4;

  // The minimum bid value necessary to have won the auction, in micros of
  // your account currency. If your bid won the auction, this is the second
  // highest bid that was not filtered (including the floor price). If your
  // bid did not win the auction, this is the winning candidate's bid. This
  // field will only be populated if your bid participated in a first-price
  // auction, and will not be populated if your bid was filtered prior to the
  // auction.
  optional int64 minimum_bid_to_win = 7;

  // The minimum bid value necessary to have won the server-side component of
  // the overall auction given that there was also an interest group bidding
  // component to the overall auction which ran using the Protected Audience
  // API. The value is expressed in CPM micros of the buyer account currency.
  // The minimum bid to win for the overall auction, including bids from the
  // server-side and the on-device interest group components, is populated in
  // the minimum_bid_to_win field of the same BidResponseFeedback object.
  optional int64 server_side_component_minimum_bid_to_win = 16;

  // Billable event rate multiplier that was applied to this bid during
  // ranking. The adjustment reflects the likelihood that your bid would
  // generate a billable event (namely, the ad renders successfully) if it won
  // the auction, relative to the probability that other bids generate a
  // billable event if they won the auction. This adjustment can be larger or
  // smaller than 1. This affects the final ranking in the auction only; in
  // particular, this multiplier does not affect the payment or whether the
  // bid clears any floor price.
  optional float billable_event_rate_bid_adjustment = 15 [default = 1];

  // When a publisher uses an RTB auction and waterfall-based SDK mediation on
  // the same query, the winner of the real-time auction must also compete in
  // a mediation waterfall (which is ordered by price) to win the impression.
  // If the bid participated in the auction and there was no waterfall, the
  // value of this field is 0. If the bid participated in the auction and
  // there was a waterfall, the value of this field is a price representing a
  // sample bid from the eligible mediation networks that were higher than the
  // auction winner, weighted by expected fill rate. This field can be used
  // in conjunction with minimum_bid_to_win to train bidding models. The CPM
  // is in micros of your account currency.
  optional int64 sampled_mediation_cpm_ahead_of_auction_winner = 10;

  // Event notification token that was included in the bid response.
  optional bytes event_notification_token = 5;

  // Buyer creative ID that was included in the bid response.
  optional string buyer_creative_id = 6;

  // Possible types of bid response feedback objects.
  enum FeedbackType {
    FEEDBACK_TYPE_UNSPECIFIED = 0;

    // Feedback for a bid that was submitted on a bid response.
    BID_FEEDBACK = 1;

    // Feedback for an interest group buyer submitted on a bid response to
    // particpate in an interest group bidding component of the auction run
    // using the Protected Audience API.
    INTEREST_GROUP_BUYER_FEEDBACK = 2;
  }

  // The type of the BidResponseFeedback message. Google will send separate
  // BidResponseFeedback objects for:
  // a) Each bid submitted on a bid response
  // b) Each buyer submitted on a bid response to particpate in an interest
  // group bidding component of the auction run using the Protected Audience
  // API.
  optional FeedbackType feedback_type = 17;

  // Origin of an interest group buyer that was included in the bid response.
  // This field is populated only for feedback where a bidder opted in an
  // interest group buyer to participate in the interest group bidding
  // component of the overall auction run using the Protected Audience API.
  // To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
  // To learn more about interest group bidding and the Protected Audience
  // API, see
  // https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
  optional string buyer_origin = 18;

  // The status code for the submitted interest group buyer. This field is
  // only populated in the feedback for an interest group buyer that a bidder
  // requested to enter into the interest group auction through the bid
  // response. Individual creative status codes of bids submitted by the buyer
  // in the on-device interest group auction are not available. See
  // https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
  // for a list of interest group buyer status codes.
  optional int32 interest_group_buyer_status_code = 19;
}

W pierwszym polu, które należy sprawdzić w tym komunikacie, bid_response_feedback.creative_status_code; znajdziesz kod znaczenie w języku Creative-status-codes.txt. Pamiętaj, że jeśli wygrasz stawkę, możesz zrezygnować na podstawie opinii o cenie. Więcej informacji znajdziesz w artykule Instrukcje i zrezygnuj.

Opinia w czasie rzeczywistym zawiera identyfikator pytania o stawkę oraz jeden :

Wynik aukcji Opinie w czasie rzeczywistym
Kupujący nie przesłał stawki. Nic.
Kupujący przesłał stawkę, która została odfiltrowana, zanim osiągnęła wartość aukcji. Kod stanu kreacji (creative-status-codes.txt).
Kupujący przesłał stawkę, ale przegrał aukcję. Kod stanu kreacji 79 (przelicytowana za aukcji).
Kupujący przesłał stawkę, która wygrała aukcję. Cena rozliczenia i kod stanu kreacji 1.

W przypadku wyświetlenia w aplikacji i kodu stanu kreacji 83 parametr wydawca aplikacji mógł korzystać z kaskady zapośredniczenia, zwycięska stawka konkurowałaby z innymi ofertami wydawcy łańcucha kaskady przebiegu zwrotnego. Naucz się używać sampled_mediation_cpm_ahead_of_auction_winner, gdy .

Przykład

Oto próbka opinii w czasie rzeczywistym w obszarze protokoły:

Google

Plik JSON OpenRTB

Bufor protokołu OpenRTB

Tworzenie modelu określania stawek na potrzeby aukcji pierwszej ceny

Po ustaleniu stawki w aukcji pierwszej ceny będziesz otrzymywać opinie, w tym minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner, jeśli stawka nie został odfiltrowany z aukcji. Te sygnały mogą służyć do przekazywania logika określania stawek określająca, o ile wyższa lub niższa stawka mogłaby być wygrywają wyświetlenia.

  • minimum_bid_to_win: minimalna stawka, jaką można było osiągnąć aby wygrać aukcję z określaniem stawek w czasie rzeczywistym. Jeśli wygrasz aukcję, być najniższą stawką, jaką można było ustawić, nadal wygrywając. Jeśli zgubiłeś(-aś) w aukcji, to ta stawka będzie zwycięska.
  • sampled_mediation_cpm_ahead_of_auction_winner: jeśli masz w innych sieciach w łańcuchu zapośredniczenia, jest to cena reprezentująca przykładową stawkę z jednego odpowiednie sieci zapośredniczenia, które były wyższe od zwycięzcy aukcji, ważone od oczekiwanego współczynnika wypełnienia. Jeśli żadna z sieci w zostanie wypełniony łańcuch zapośredniczenia lub jeśli wydawca nie korzysta z pakietu SDK; pośrednictwa.

Jak to działa

Aby opisać obliczenia służące do wyznaczenia możliwych wartości dla minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner, musimy najpierw zdefiniować następujące elementy:

  • Poniżej przedstawiamy wartości CPM w łańcuchu zapośredniczenia w kolejności malejącej:
    \[C_1, C_2, …, C_n\]
  • Poniżej przedstawiono odpowiednie współczynniki wypełnienia dla CPM w łańcuch zapośredniczenia:
    \[f_1, f_2, …, f_n\]
  • Poniżej przedstawiono funkcję służącą do określania oczekiwanego CPM i jego prawdopodobieństwo z elementu łańcucha zapośredniczenia \(i\), na podstawie danego wypełnienia stawka:
    \(X_i = \{C_i\) z prawdopodobieństwem \(f_i\); \(0\) z prawdopodobieństwem \(1 - f_i\}\)
  • Ostateczny łańcuch zapośredniczenia, który wygra łańcuch zapośredniczenia, to:
    \[\{C_1, C_2, …, C_K, W\}\]
    gdzie \(W\) to zwycięska stawka \(C_K > W >= C_{K+1}\)
  • Cena minimalna (minimalna) jest oznaczona jako \(F\).
  • Stawka za drugie miejsce 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 domeny \(1 <= i <= K\).
Obliczenia dotyczące przegranej 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 jako następujące:

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

Oto wynik aukcji RTB:

Aukcja RTB CPM
Zwycięzca aukcji (W) 1 USD
Druga połowa aukcji (R) 0,05 USD
Cena minimalna / cena minimalna (F) 0 USD
Stawka, która wygrała aukcję

Poniższy przykład pokazuje, jak wartości i prawdopodobieństwa dla wartości minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner są obliczane dla która wygrała.

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 aukcję

Poniższy przykład pokazuje, jak wartości i prawdopodobieństwa dla wartości minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner są obliczane dla które przegrały.

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 stawek opisuje przetwarzanie pojedynczego kompleksu BidRequest w kilka pytań o stawkę wysyłanych do Twojego aplikacji. Ponieważ zachowują one identyczne identyfikatory (BidRequest.google_query_id w ramach protokołu RTB Authorized Buyers lub BidRequestExt.google_query_id w protokole OpenRTB), możesz określać, które pytania o stawkę są skorelowane po współdzieleniu.

Formaty reklam

Niektóre możliwości wyświetlania reklam mogą przyjmować wiele formatów. Przy rozdzielaniu stawek każda są wysyłane w osobnym pytaniu o stawkę, gdzie atrybuty takie jak „odpowiedni” są powiązane z formatem określonym w żądaniu.

Pytania o stawkę, które zawierają podane niżej formaty, zostaną podzielone na różne pytania o stawkę:

  • Baner
  • Wideo
  • Dźwięk
  • Natywna

Przykład udostępniania w formacie reklamy

Poniżej znajduje się przykład uproszczonego pytania o stawkę JSON OpenRTB bez reklamy spłaszczony format w porównaniu z równoważnym zbiorem żądań w rozdzielczości:

Wstępnie spłaszcz

Do wyrównania

Okazje

Możliwość wyświetlenia reklamy w przypadku danego licytującego można wykorzystać w różnych umowach typy reklam, a nie tylko aukcje otwarte. Przy rozdzielaniu stawek w przypadku umów: 1 stawka zostanie wysłane do aukcji otwartej i jedno dla każdego typu stałej ceny umowy. W praktyce ograniczenia dotyczące reklam mogą się różnić w zależności od aukcji i stałej ceny ofert, np. dla danej możliwości związanej z reklamą wideo, która jest dostępna dla aukcji otwartej i umowy o stałej cenie, licytujący otrzyma różne pytań o stawkę w przypadku każdego typu, w którym ograniczenia, np. maksymalny czas trwania reklamy, mogą się różnić. W rezultacie do reklamy została zastosowana wygładzanie. pozwala łatwiej określić ograniczenia dotyczące reklam w otwartych aukcji ze stałą ceną.

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

Protokół Google i implementacja OpenRTB obsługują poniższe pola czas trwania filmu i możliwość pominięcia:

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, możliwy do pominięcia i czasu trwania niemożliwego do pominięcia, implementacja OpenRTB ma tylko jeden maksymalny czas trwania.

Przed rozłożeniem stawek wartość maxduration OpenRTB zostałaby ustawiona na niższy z parametrów max_ad_duration i protokołu Google skippable_max_ad_duration pól. Sposób działania zmienił się na wysyłając dwa osobne pytania o stawkę, gdy te wartości się różnią: jedno odpowiada maxduration w przypadku reklam możliwych do pominięcia, a drugie w przypadku reklam niemożliwych do pominięcia. możliwości.

Poniższe przykłady pokazują, jak jest translowane żądanie protokołu Google do OpenRTB przed i po rozdzieleniu stawek. Odpowiednik protokołu Google żądanie zawiera max_ad_duration o wartości 15 i skippable_max_ad_duration z 60.

Przykład max_ad_duration skip (prawda LUB fałsz)
Pierwotne żądanie bez podziału 15 true
Spłaszczone żądanie nr 1: niemożliwe do pominięcia 15 false
Spłaszczone żądanie nr 2: możliwe do pominięcia 60 true

Pytanie o stawkę dotyczące czasu trwania reklamy wideo możliwej do pominięcia ma miejsce tylko wtedy, są spełnione te warunki:

  • Żądanie zezwala na odtwarzanie filmu.
  • Dozwolone są zarówno filmy pomijane, jak i te, których nie można pominąć. Dozwolone są też 2 odpowiednie atrybuty maks. czas trwania może się różnić.
  • To żądanie może kwalifikować się do aukcji prywatnej lub otwartej.
  • Konto licytującego ma aktywne punkty końcowe OpenRTB.

Aby zrezygnować z tego typu rozdzielania, skontaktuj się ze swoim menedżera konta.

Bloki reklamowe wideo

Pytania o stawkę dotyczące bloku wideo z wieloma możliwościami reklamy są rozdzielane na poszczególne części, w taki sposób, aby każde pytanie o stawkę dotyczyło pojedynczej możliwości reklamy z tego bloku. Dzięki temu możesz określać stawki dla wielu możliwości reklamowych w danym bloku reklamowym.

Open Measurement

Open Measurement pozwala wskazać dostawców zewnętrznych, niezależne usługi pomiarowe i weryfikacyjne w przypadku reklam wyświetlanych w aplikacjach mobilnych. w różnych środowiskach.

Możesz sprawdzić, czy wydawca obsługuje Open Measurement w stawce żądania, sprawdzając, czy możliwość wyświetlenia reklamy wyklucza atrybut OmsdkType: OMSDK 1.0 w atrybucie Publisher-excludable atrybutów kreacji. W przypadku protokołu Authorized Buyers będzie to wartość znaleziono w grupie BidRequest.adslot[].excluded_attribute. W przypadku atrybutu protokołu OpenRTB. Można go znaleźć w atrybucie battr. dla elementu Banner lub Wideo, w zależności od format.

Więcej informacji o interpretowaniu pytań o stawkę zawierających otwarte Sygnały pomiarowe, zapoznaj się z dokumentem Open Measurement Artykuł w Centrum pomocy o pakiecie SDK.

Przykładowe pytania o stawkę

W sekcjach poniżej znajdziesz przykładowe pytania o stawkę dotyczące różnych typów reklam.

Baner aplikacji

Google

Plik JSON OpenRTB

Bufor protokołu OpenRTB

Reklama pełnoekranowa w aplikacji

Google

Plik JSON OpenRTB

Bufor protokołu OpenRTB

Pełnoekranowa reklama wideo w aplikacji

Google

Bufor protokołu OpenRTB

Reklama natywna w aplikacji

Google

Plik JSON OpenRTB

Bufor protokołu OpenRTB

Film internetowy

Google

Baner w internecie mobilnym dotyczący licytującego na giełdzie

Bufor protokołu OpenRTB