Обработать запрос

Взаимодействие с назначением ставок в реальном времени начинается, когда Google отправляет запрос ставки в ваше приложение. В этом руководстве объясняется, как написать код приложения для обработки запроса ставки.

Разобрать запрос

Google отправляет запрос ставки в виде сериализованного буфера протокола, прикрепленного как двоичная полезная нагрузка HTTP-запроса POST. Content-Type имеет значение application/octet-stream . См. пример запроса ставки .

Вам необходимо преобразовать этот запрос в экземпляр сообщения BidRequest . BidRequest определяется в realtime-bidding.proto , который можно получить на странице справочных данных . Вы можете проанализировать сообщение, используя метод ParseFromString() в сгенерированном классе для BidRequest . Например, следующий код C++ анализирует запрос, содержащий полезные данные POST в строке:

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

Получив BidRequest вы можете работать с ним как с объектом, извлекая и интерпретируя нужные поля. Например, в С++:

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

Некоторая информация, отправленная в BidRequest , например идентификатор пользователя Google, язык или географическое местоположение, не всегда доступна. Если у вас есть группы объявлений с предварительным таргетингом , в которых для конкретного показа используется неизвестная информация, эти группы объявлений не будут совпадать. В тех случаях, когда недостающая информация не имеет значения для условий предварительного таргетинга, запросы ставок отправляются без этой информации.

Информация о группе объявлений с предварительным таргетингом доступна в группе MatchingAdData для каждого AdSlot . Он содержит первый соответствующий идентификатор группы объявлений с предварительным таргетингом, который побудил Google отправить запрос ставки, то есть группы объявлений и кампании, с которых взимается плата, если ваш ответ выиграет аукцион за показ. При определенных обстоятельствах вам необходимо явно указать billing_id для атрибуции в BidResponse.AdSlot , например, если BidRequest.AdSlot имеет более одного matching_ad_data . Дополнительную информацию об ограничениях на содержимое заявки см. в файле realtime-bidding.proto .

Файлы словарей

В запросе ставки используются идентификаторы, определенные в файлах словарей, которые доступны на странице справочных данных .

Макросы URL ставок

При желании некоторые поля BidRequest можно вставить в URL-адрес, используемый в запросе HTTP POST. Это полезно, например, если вы используете облегченный интерфейс, который балансирует нагрузку на несколько серверов, используя значение из запроса. Свяжитесь со своим техническим менеджером по работе с клиентами, чтобы запросить поддержку для новых макросов.

Макрос Описание
%%GOOGLE_USER_ID%%

Заменено на google_user_id из BidRequest . Например, URL-адрес системы назначения ставок

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
будет заменен чем-то вроде
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
во время запроса.

Если идентификатор пользователя Google неизвестен, подставляется пустая строка с результатом, аналогичным

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

Заменяется на 1 или 0 при вызове has_mobile() BidRequest .

%%HAS_VIDEO%%

Заменяется на 1 (true) или 0 (false) при вызове has_video() BidRequest .

%%HOSTED_MATCH_DATA%%

Заменено значением поля hosted_match_data из BidRequest .

%%MOBILE_IS_APP%%

Заменено на 1 (истина) или 0 (ложь) из поля mobile.is_app BidRequest .

Найти идентификатор мобильного приложения по URL-адресу транзакции

Транзакции мобильных приложений будут сообщать URL-адреса, которые выглядят следующим образом:

mbappgewtimrzgyytanjyg4888888.com

Используйте декодер Base-32 для декодирования части строки, выделенной жирным шрифтом ( gewtimrzgyytanjyg4888888 ).

Вы можете использовать онлайн-декодер , но вам придется использовать заглавные буквы и заменять конечные 8 значениями = .

Таким образом, декодирование этого значения:

GEWTIMRZGYYTANJYG4======
приводит к следующему:
1-429610587
Строка 429610587 — это идентификатор приложения для iOS iFunny .

Вот еще один пример. Сообщаемый URL-адрес:

mbappgewtgmjug4ytmmrtgm888888.com
Декодирование этого значения:
GEWTGMJUG4YTMMRTGM======
приводит к:
1-314716233
Результат 314716233 — это идентификатор приложения для iOS-приложения TextNow .

Найти название мобильного приложения по URL-адресу транзакции

Вот пример получения имени приложения. Сообщаемый URL-адрес выглядит следующим образом:

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
Декодирование этого значения:
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
приводит к:
air.com.hypah.io.slither
Результат соответствует приложению Android slither.io .

Открытые поля ставок

Запросы ставок, отправляемые бирже и сетевым участникам торгов, участвующим в Open Bidding, аналогичны запросам Авторизованных покупателей, участвующих в стандартных торгах в режиме реального времени. Клиенты Open Bidding получат небольшое количество дополнительных полей, а некоторые существующие поля могут иметь альтернативное использование. К ним относятся следующие:

OpenRTB Авторизованные покупатели Подробности
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

Содержит код сети Менеджера рекламы издателя, за которым следует иерархия рекламных блоков, разделенных косой чертой.

Например, это будет иметь формат, аналогичный: /1234/cruises/mars .

BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

Повторяющиеся пары "ключ-значение", отправленные издателем системе назначения ставок на бирже.

Вы можете определить, что значения представляют собой пары «ключ-значение», отправленные издателем, если BidRequest.user.data[].name установлено значение “Publisher Passed” .

Объявить разрешенных поставщиков

Поставщики технологий, которые предоставляют такие услуги, как исследования, ремаркетинг и показ рекламы, могут играть определенную роль во взаимодействии между покупателями и продавцами. Допускаются только те поставщики, которых Google проверил на предмет участия во взаимодействии с Авторизованными покупателями.

Чтобы понять BidRequest и создать свой BidResponse , вам необходимо знать о двух различных возможностях объявления поставщиков технологий:

  1. Некоторых поставщиков указывать не требуется; эти поставщики перечислены в справке Авторизованных покупателей .
  2. Другие поставщики могут участвовать только в том случае, если они указаны как в BidRequest , так и BidResponse :
    • В BidRequest поле allowed_vendor_type указывает, каких поставщиков разрешает продавец. Поставщики, которые будут отправлены в поле allowed_vendor_type запроса BidRequest , перечислены в файле словаря Vendors.txt .
    • В BidResponse vendor_type указывает, каких из разрешенных поставщиков покупатель намерен использовать.

Пример запроса ставки

Следующие примеры представляют собой удобочитаемые образцы запросов Protobuf и JSON.

Google

OpenRTB JSON

OpenRTB Протобуф

Чтобы преобразовать запрос ставки в двоичную форму, как если бы вы получили из полезных данных POST в реальном запросе, вы можете сделать следующее (на C++). Однако обратите внимание, что это неприменимо к 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
  }
}

Ремаркетинг

Авторизованные покупатели передают идентификатор мобильной рекламы в запросах ставок из мобильного приложения. Идентификатором мобильной рекламы может быть идентификатор iOS IDFA или рекламный идентификатор Android , который отправляется с помощью макроса %%EXTRA_TAG_DATA%% в теге JavaScript, управляемом авторизованными покупателями.

Макрос %%ADVERTISING_IDENTIFIER%% позволяет покупателям получать идентификатор iOS IDFA или рекламный идентификатор Android при показе. Он возвращает зашифрованный протобуфер MobileAdvertisingId , например %%EXTRA_TAG_DATA%% :

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

user_id_type — это одно из значений, определенных в enum AdxMobileIdType :

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

Вы можете создавать списки пользователей на основе идентификаторов мобильной рекламы, используя рекламные идентификаторы, которые вы собрали во время обработки показа. Эти списки пользователей могут храниться на вашем сервере или на нашем. Чтобы создавать списки пользователей на серверах Google, вы можете использовать нашу функцию массовой загрузки.

Если идентификатор мобильной рекламы соответствует списку пользователей, вы можете использовать его для запуска ремаркетинга.

Обратная связь в режиме реального времени

Обратная связь в режиме реального времени доступна авторизованным покупателям, а также биржам и сетям, использующим Open Bidding.

Обратная связь с ответом на ставку поддерживается в последующем запросе ставки как для протокола AdX, так и для OpenRTB. Для OpenRTB он отправляется в BidRequestExt .

Помимо полей по умолчанию, отправляемых в ответе на запрос ставки, вы также можете отправлять в ответе на запрос ставки собственные данные (в AdX Proto или OpenRTB), используя event_notification_token , который возвращается в BidResponse . event_notification_token — это произвольные данные, известные только системе назначения ставок, которые могут помочь при отладке, например: новый идентификатор таргетинга или идентификатор ставки, представляющий новую тактику, или метаданные, связанные с креативом, известные только системе назначения ставок. Подробные сведения см. в разделах «Буфер протокола расширений OpenRTB для RTB» и «Протокол AdX для AdX».

Когда Авторизованные покупатели отправляют запрос ставки участнику торгов, тот отвечает BidResponse . Если у участника торгов включена обратная связь в реальном времени, то в последующем запросе ставки Авторизованные покупатели отправляют отзыв об ответе в сообщении BidResponseFeedback , как показано ниже:

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

В этом сообщении первое поле, которое вам следует проверить, — это bid_response_feedback.creative_status_code ; Значение кода можно найти в файле Creative-status-codes.txt . Обратите внимание: если вы выиграете тендер, вы можете отказаться от обратной связи по цене. Дополнительную информацию см. в разделе «Как отказаться» .

Обратная связь в режиме реального времени включает идентификатор запроса ставки и одну из следующих данных:

Результат аукциона Обратная связь в режиме реального времени
Покупатель не подал заявку. Ничего.
Покупатель подал ставку, которая была отфильтрована до того, как поступила на аукцион. Код статуса объявления ( Creative-status-codes.txt ).
Покупатель подал заявку, но проиграл аукцион. Код статуса креатива 79 (перекуп на аукционе).
Покупатель подал заявку, которая выиграла аукцион. Клиринговая цена и код статуса креатива 1 .

Для показа приложения и кода статуса объявления 83 издатель приложения мог использовать каскад медиации, и поэтому выигравшая ставка конкурировала бы с другим спросом в каскадной цепочке возврата издателя. Узнайте, как использовать sampled_mediation_cpm_ahead_of_auction_winner при назначении ставок .

Образец

Ниже приведен пример обратной связи в режиме реального времени, как показано в поддерживаемых протоколах:

Google

OpenRTB JSON

OpenRTB Протобуф

Создайте модель торгов для аукционов первой цены.

После размещения ставки на аукционе первой цены вы получите обратную связь в режиме реального времени, в том числе minimum_bid_to_win и sampled_mediation_cpm_ahead_of_auction_winner , если ставка не была отфильтрована на аукционе. Эти сигналы можно использовать для информирования вашей логики назначения ставок о том, насколько выше или ниже могла бы быть ваша ставка, чтобы выиграть показ.

  • minimum_bid_to_win : минимальная ставка, которую можно было бы сделать для победы на аукционе ставок в реальном времени. Если вы выиграли аукцион, это будет самая низкая ставка, которую вы могли бы сделать, пока выигрывали. Если вы проиграли аукцион, это будет выигрышная ставка.
  • sampled_mediation_cpm_ahead_of_auction_winner : если в цепочке медиации есть другие сети, значением этого поля является цена, представляющая примерную ставку из одной из подходящих сетей медиации, которая была выше, чем у победителя аукциона, взвешенная по ожидаемому уровню заполнения. Для этого параметра будет установлено значение 0, если ожидается, что ни одна из сетей в цепочке медиации не будет заполнена, или если издатель не использует медиацию SDK.

Как это работает

Чтобы описать вычисления, используемые для определения возможных значений minimum_bid_to_win и sampled_mediation_cpm_ahead_of_auction_winner , нам сначала необходимо определить следующее:

  • Ниже представлены цены за тысячу показов в цепочке медиации в порядке убывания:
    \[C_1, C_2, …, C_n\]
  • Ниже представлены соответствующие показатели заполняемости для цен за тысячу показов в цепочке медиации:
    \[f_1, f_2, …, f_n\]
  • Ниже приведена функция, используемая для определения ожидаемой цены за тысячу показов и ее вероятности на основе элемента цепочки медиации \(i\)на основе заданной скорости заполнения:
    \(X_i = \{C_i\) с вероятностью \(f_i\); \(0\) с вероятностью \(1 - f_i\}\)
  • Окончательная выигрышная посредническая цепочка будет такой:
    \[\{C_1, C_2, …, C_K, W\}\]
    где \(W\) — выигрышная ставка, а \(C_K > W >= C_{K+1}\)
  • Резервная цена или минимальная цена обозначается как \(F\).
  • Ставка, занявшая второе место, обозначается как \(R\).
Расчеты для победителя аукциона
Поле Расчет
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_ of_auction_winner
sampled_mediation_cpm_ahead_ of_auction_winner
\(\{C_i\) с вероятностью \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Для \(1 <= i <= K\).

Расчеты для проигравшего на аукционе
Поле Расчет
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_ of_auction_winner
sampled_mediation_cpm_ahead_ of_auction_winner
\(max\{X_1, …, X_K\}\)

Пример с простой цепочкой медиации

Предположим, издатель использует как назначение ставок в реальном времени, так и цепочку медиации SDK следующим образом:

Цепочка медиации SDK Ожидаемая цена за тысячу показов Наполняемость
Сеть 1\(C_1 = $3.00\)\(f_1 = 5\%\)
Сеть 2\(C_2 = $2.00\)\(f_2 = 45\%\)
Сеть 3\(C_3 = $0.50\)\(f_3 = 80\%\)
Сеть 4\(C_4 = $0.10\)\(f_4 = 85\%\)

Предположим, что в результате RTB-аукциона произойдет следующее:

RTB-аукцион цена за тысячу показов
Победитель аукциона (Ж) 1,00 доллара США
Второе место на аукционе (R) 0,05 доллара США
Резервная цена/минимальный уровень (F) $0
Ставка, выигравшая аукцион

Ниже приведен пример расчета значений и вероятностей для minimum_bid_to_win и sampled_mediation_cpm_ahead_of_auction_winner для выигравшей ставки.

minimum_bid_to_win Вероятность
\(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
sampled_mediation_cpm_ ahead_of_auction_winner		 Вероятность
\(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\%\)
Ставки, проигравшие аукцион

Ниже приведен пример расчета значений и вероятностей для minimum_bid_to_win и sampled_mediation_cpm_ahead_of_auction_winner для проигравших ставок.

minimum_bid_to_win Вероятность
\(max(F, W) = $1.00\)\(100\%\)
sampled_mediation_cpm_ ahead_of_auction_winner
sampled_mediation_cpm_ ahead_of_auction_winner		 Вероятность
\(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\%\)

Сглаживание ставок

Сглаживание ставок описывает обработку одного сложного BidRequest в несколько запросов ставок, которые отправляются в ваше приложение. Поскольку они сохраняют идентичные идентификаторы ( BidRequest.google_query_id в протоколе RTB авторизованных покупателей или BidRequestExt.google_query_id в протоколе OpenRTB), вы можете определить, какие запросы ставок коррелируют после выравнивания.

Форматы рекламы

Некоторые рекламные возможности могут принимать несколько форматов. При выравнивании ставок каждый формат отправляется в отдельном запросе ставки, где такие атрибуты, как допустимые платежные идентификаторы, соответствуют формату, указанному в запросе.

Запросы ставок, содержащие следующие форматы, будут объединены в отдельные запросы ставок:

  • Баннер
  • видео
  • Аудио
  • Родной

Пример выравнивания формата объявления

Ниже приведен пример, показывающий упрощенный запрос ставки OpenRTB JSON без выравнивания формата объявления по сравнению с эквивалентным набором объединенных запросов:

Предварительное выравнивание

Пост-сглаживание

Специальные предложения

Рекламная возможность для конкретного участника торгов может быть применима к различным типам сделок, помимо открытого аукциона. При выравнивании ставок для сделок на открытый аукцион будет отправлен один запрос ставки и по одному для каждого типа сделки с фиксированной ценой. На практике ограничения на рекламу могут различаться в зависимости от аукциона и типа сделки с фиксированной ценой. Например, для конкретной возможности видеорекламы, доступной как для открытого аукциона, так и для сделки с фиксированной ценой, участник торгов будет получать отдельные запросы ставок для каждой из них. такие ограничения, как максимальная продолжительность объявления и разрешенность объявлений с возможностью пропуска, могут различаться. В результате сглаживание, примененное к рекламным возможностям, позволяет легче определить рекламные ограничения для открытого аукциона и сделки с фиксированной ценой.

Максимальная продолжительность видео с возможностью пропуска

Протокол Google и реализация OpenRTB поддерживают следующие поля для продолжительности видео и возможности пропуска:

Продолжительность Продолжительность с возможностью пропуска Возможность пропуска
протокол Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration н/д skip

Это означает, что хотя протокол Google может иметь детальную продолжительность с возможностью пропуска и без нее, реализация OpenRTB имеет только одно максимальное значение продолжительности.

Перед выравниванием ставок maxduration OpenRTB будет установлено меньшее из полей max_ad_duration и skippable_max_ad_duration протокола Google. Теперь это поведение изменилось: если эти значения различаются, теперь отправляются два отдельных запроса ставок: один представляет maxduration для возможностей с возможностью пропуска, а другой — для возможностей без возможности пропуска.

В следующих примерах показано, как запрос протокола Google преобразуется в OpenRTB до и после выравнивания ставок. Эквивалентный запрос протокола Google имеет max_ad_duration , равный 15 , и skippable_max_ad_duration , равный 60 .

Пример max_ad_duration skip (истина ИЛИ ложь)
Исходный запрос без выравнивания 15 true
Упрощенный запрос № 1: без возможности пропуска 15 false
Упрощенный запрос № 2: с возможностью пропуска 60 true

Сглаживание запросов ставок на продолжительность видео с возможностью пропуска будет происходить только при соблюдении следующих условий:

  • Запрос разрешает видео.
  • Разрешены видео как с пропуском, так и без пропуска, при этом две соответствующие максимальные продолжительности различаются по значению.
  • Этот запрос может участвовать в частном или открытом аукционе.
  • Учетная запись участника торгов имеет активные конечные точки OpenRTB.

Вы можете отказаться от этого типа сведения, обратившись к своему техническому менеджеру по работе с клиентами.

Видео-модули

Запросы ставок для модуля видео с несколькими рекламными возможностями объединяются, так что каждый запрос ставки предназначен для отдельного рекламного варианта из этого модуля. Это позволяет вам делать ставки на несколько рекламных возможностей для данного модуля.

Открытое измерение

Open Measurement позволяет указать сторонних поставщиков, которые предоставляют независимые услуги по измерению и проверке рекламы, показываемой в средах мобильных приложений.

Вы можете определить, поддерживает ли издатель Open Measurement в запросе ставки, проверив, исключает ли рекламная возможность атрибут OmsdkType: OMSDK 1.0 который находится в атрибутах объявлений, исключаемых издателем . Для протокола Авторизованных покупателей это можно найти в разделе BidRequest.adslot[].excluded_attribute . Для протокола OpenRTB это можно найти в атрибуте battr для Banner или Video , в зависимости от формата.

Дополнительную информацию о том, как интерпретировать запросы ставок, содержащие сигналы Open Measurement, можно найти в статье Справочного центра Open Measurement SDK .

Примеры запросов ставок

В следующих разделах показаны примеры запросов ставок для различных типов объявлений.

Баннер приложения

Google

OpenRTB JSON

OpenRTB Протобуф

Межстраничное объявление приложения

Google

OpenRTB JSON

OpenRTB Протобуф

Межстраничное видео приложения

Google

OpenRTB Протобуф

Приложение родное

Google

OpenRTB JSON

OpenRTB Протобуф

Веб-видео

Google

Мобильный веб-баннер для системы торгов на бирже

OpenRTB Протобуф