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.

Analizuj żądanie buforowania protokołu

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

Musisz przeanalizować to żądanie w instancji wiadomości BidRequest. W zależności od wybranego protokołu zdefiniowany jest protokół BidRequest w elemencie openrtb.proto lub w wycofanym realtime-bidding.proto, które można uzyskać z dane referencyjne. 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 oraz wyodrębnianie i interpretowanie potrzebnych pól. Na przykład w polu Powtarzanie w języku C++ umów w ramach metody „BidRequest” OpenRTB może wyglądać tak: następujące:

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

Identyfikatory płatności

Otrzymujesz pytanie o stawkę, gdy kierujesz reklamy na zasoby reklamowe wydawcy według konfiguracji 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 pytanie o stawkę zawiera kilka identyfikatorów płatności, musisz określić identyfikator płatności kupującego, któremu chcesz przypisać stawkę, BidResponse.seatbid.bid.ext.billing_id.

Pliki słownika

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

Makra URL stawek protokołu Google RTB

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

MakroOpis
%%GOOGLE_USER_ID%%

Zastą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 Google User ID jest nieznany, zostaje zastąpiony pustym ciągiem, co daje 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ąpiona wartością pola hosted_match_data z poziomu 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 napisać wielkimi literami i zastąpić resztę Elementy typu 8 z = wartościami.

Dlatego dekoduję tę wartość: 

GEWTIMRZGYYTANJYG4======
daje: 
1-429610587
Ciąg znaków 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 wydawcy w Ad Managerze, a za nim hierarchię jednostek reklamowych, rozdzielone 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[]

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

Można ustalić, że wartości są parami klucz-wartość wysyłanymi przez metodę Wydawca, gdy 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ć pewną rolę w interakcjach między kupującymi a 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órzy dostawcy nie muszą być deklarowani. ci dostawcy są wymienieni w Certyfikat zewnętrzny Ad Managera Dostawcy.
  2. Pozostali dostawcy mogą uczestniczyć tylko wtedy, gdy są zadeklarowani w BidRequest:
    • BidRequest Pole BidRequest.imp.ext.allowed_vendor_type określa na listę dostawców wybranych przez sprzedawcę. Dostawcy, którzy zostaną wysłani w pliku allowed_vendor_type, są wymienieni w pliku słownika vendors.txt.

Przykładowe pytanie o stawkę

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

OpenRTB Protobuf

Plik JSON OpenRTB

Google (wycofane)

Aby przekonwertować żądanie oferty do postaci binarnej, tak jak w przypadku ładunku POST w rzeczywistym żądaniu, 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
  }
}

Opinie w czasie rzeczywistym

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

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

Oprócz 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ę za pomocą funkcji BidResponse.seatbid.bid.ext.event_notification_token. event_notification_token to dowolne dane znane tylko licytujący, który może Ci pomóc w debugowaniu, np. nowy identyfikator kierowania lub identyfikator określania stawek reprezentujący nową taktykę lub metadane powiązane z kreacją znane tylko licytującemu. Więcej informacji: Buffer protokołu OpenRTB Extensions w przypadku OpenRTB lub Protokół Google RTB.

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

message BidFeedback {
  // The unique id from BidRequest.id.
  optional string request_id = 1;

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

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

  // The minimum bid value necessary to have 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 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 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 pierwszym polu, które należy sprawdzić w tym komunikacie, bid_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 Jak zrezygnować z reklam.

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

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ł na aukcji. Kod stanu kreacji 79 (przelicytowanie w aukcji).
Kupujący przesłał stawkę, która wygrała aukcję. Cena rozliczenia 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 wywołaniem. Dowiedz się, jak korzystać z funkcji sampled_mediation_cpm_ahead_of_auction_winner podczas ustalania stawek.

Przykład

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

OpenRTB Protobuf

Plik JSON OpenRTB

Google (wycofane)

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 stawka przegrała aukcję, będzie to stawka 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 określania możliwych wartości dla minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner, musimy najpierw zdefiniować:

  • Poniżej przedstawiamy wartości CPM w łańcuchu zapośredniczenia w kolejności malejącej:
    \[C_1, C_2, …, C_n\]
  • Poniżej znajdziesz odpowiednie współczynniki wypełnienia CPM w łańcuchu pośrednictwa:
    \[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 będzie wyglądał tak:
    \[\{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\).
  • Druga pod względem wysokości stawka jest oznaczona jako \(R\).
Obliczenia dotyczące zwycięzcy aukcji
Pole Obliczenie
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) z prawdopodobieństwem \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
\(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
Auction Runner-UP (R) 0,05 USD
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 pytań o stawkę to przetwarzanie pojedynczego złożonego BidRequest na wiele pytań o stawkę wysyłanych do aplikacji. Gdy pytanie o stawkę zostanie podzielone na grupy, możesz sprawdzić, które z nich były częścią oryginału, ponieważ będą miały identyczną wartość w 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. 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ę zawierające te formaty zostaną rozdzielone na osobne pytania o stawkę:

  • Baner
  • Wideo
  • Audio
  • Natywna

Przykład przenoszenia formatów reklam

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

Po spłaszczeniu

Okazje

Możliwość wyświetlania reklam 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 czas trwania reklamy z możliwością pominięcia i bez możliwości pominięcia, implementacja OpenRTB ma tylko jedną wartość maksymalnego czasu trwania.

Przed spłaszczaniem stawek wartość parametru maxduration w OpenRTB była ustawiana na mniejszą z wartości w polach max_ad_duration i skippable_max_ad_duration protokołu Google. Sposób działania zmienił się na wysyłanie dwóch osobnych pytań 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 żądanie protokołu Google jest tłumaczone na OpenRTB przed i po spłaszczeniu stawek. Odpowiednie żądanie protokołu Google ma max_ad_duration o wartości 15 i skippable_max_ad_duration o wartości 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 pytanie 2: można pominąć 60 true

Pytania o stawkę dotyczące czasu trwania reklam wideo możliwych do pominięcia mają miejsce tylko wtedy, są spełnione te warunki:

  • Prośba zezwala na film.
  • Dozwolone są zarówno filmy pomijane, jak i te, których nie można pominąć. czas trwania może się różnić.
  • To żądanie kwalifikuje się do aukcji prywatnej lub otwartej.
  • Konto licytującego ma aktywne punkty końcowe OpenRTB.

Aby zrezygnować z tego typu spłaszczenia, skontaktuj się z techniczną obsługą klienta.

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. Dzięki temu możesz określać stawki dla wielu możliwości reklamowych w danym bloku reklamowym.

Open Measurement

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

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

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

Przykładowe pytania o stawkę

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

Baner aplikacji

Bufor protokołu OpenRTB

Plik JSON OpenRTB

Google (wycofane)

Reklama pełnoekranowa w aplikacji

OpenRTB Protobuf

Plik JSON OpenRTB

Google (wycofane)

Pełnoekranowa reklama wideo w aplikacji

Bufor protokołu OpenRTB

Google (wycofane)

Aplikacja natywna

OpenRTB Protobuf

Plik JSON OpenRTB

Google (wycofane)

Film internetowy

Google (wycofane)

Baner internetowy na komórki dla licytujących w giełdzie

Bufor protokołu OpenRTB