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

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

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

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

Вам необходимо преобразовать этот запрос в экземпляр сообщения BidRequest . В зависимости от выбранного вами протокола BidRequest определяется либо в openrtb.proto , либо в устаревшем файле 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 вы можете работать с ним как с объектом, извлекая и интерпретируя нужные поля. Например, в C++ итерация сделок в OpenRTB BidRequest может выглядеть следующим образом: 

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

Платежные идентификаторы

Вы получаете запрос ставки, когда на рекламные ресурсы издателя нацелена одна или несколько ваших конфигураций предварительного таргетинга . BidRequest.imp.ext.billing_id будет заполнен платежными идентификаторами всех подходящих покупателей и соответствующими конфигурациями предварительного таргетинга. Кроме того, для инвентаря сделки вы можете найти платежные идентификаторы, связанные с соответствующим покупателем, с помощью BidRequest.imp.pmp.deal.ext.billing_id . При размещении ставки можно указывать только платежные идентификаторы покупателей, включенных в запрос ставки.

Если в запрос ставки включено несколько идентификаторов выставления счетов, вы должны указать идентификатор выставления счетов покупателя, которому вы хотите присвоить свою ставку, в поле BidResponse.seatbid.bid.ext.billing_id .

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

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

Макросы URL-адресов ставок протокола Google RTB

При желании некоторые поля 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 — это идентификатор приложения TextNow для iOS.

Найти название мобильного приложения по 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 :
    • В BidRequest поле BidRequest.imp.ext.allowed_vendor_type указывает, каких поставщиков разрешает продавец. Поставщики, которые будут отправлены в allowed_vendor_type , перечислены в файле vendors.txt .

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

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

OpenRTB Протобуф

OpenRTB JSON

Google (устарело)

Чтобы преобразовать запрос ставки в двоичную форму, как если бы вы получили из полезных данных 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
  }
}

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

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

Обратная связь с ответом на заявку поддерживается в последующем запросе ставки как для OpenRTB, так и для устаревшего протокола Google RTB. Для OpenRTB он отправляется в BidRequest.ext.bid_feedback .

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

Когда Авторизованные покупатели отправляют запрос ставки участнику торгов, тот отвечает BidResponse . Если у участника торгов включена обратная связь в режиме реального времени, то в последующем запросе ставки Авторизованные покупатели отправляют отзыв об ответе в сообщении 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;

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

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

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

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

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

Образец

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

OpenRTB Протобуф

OpenRTB JSON

Google (устарело)

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

После размещения ставки на аукционе первой цены вы получите обратную связь в режиме реального времени, в том числе 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
\(\{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
\(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		 Вероятность
\(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		 Вероятность
\(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.ext.google_query_id .

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

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

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

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

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

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

Ниже приведен пример, показывающий упрощенный запрос ставки 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 который находится в атрибутах объявлений, исключаемых издателем . Его можно найти под атрибутом battr для Banner или Video , в зависимости от формата.

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

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

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

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

OpenRTB Протобуф

OpenRTB JSON

Google (устарело)

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

OpenRTB Протобуф

OpenRTB JSON

Google (устарело)

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

OpenRTB Протобуф

OpenRTB JSON

Google (устарело)

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

OpenRTB Протобуф

OpenRTB JSON

Google (устарело)

Веб-видео

OpenRTB Протобуф

OpenRTB JSON

Google (устарело)

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

OpenRTB Протобуф

OpenRTB JSON

Мультиформатное нативное и видео

OpenRTB Протобуф

OpenRTB JSON

Google (устарело)