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

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

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

Google отправляет запрос ставки, сериализованный в форматах OpenRTB JSON или Protobuf, который прикрепляется как полезная нагрузка HTTP-запроса POST. Полученный формат зависит от конфигурации вашей конечной точки . См. пример запроса ставки .

Вам необходимо проанализировать этот запрос, чтобы получить сериализованный BidRequest . Если вы используете формат Protobuf, вам необходимо скачать openrtb.proto и openrtb-adx.proto со страницы справочных данных и использовать их для создания библиотеки, которую можно использовать для анализа сообщения 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-адреса системы назначения ставок

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

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

Заменено идентификатором пользователя Google, найденным в BidRequest.user.id . Например, 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 в противном случае. Это основано на значении BidRequest.device.devicetype , где мобильные устройства обозначаются как HIGHEND_PHONE ( 4 ) или Tablet ( 5 ).

%%HAS_VIDEO%%

Заменяется на 1 , чтобы указать, что запрос ставки содержит видеоресурсы, или 0 в противном случае. Это зависит от того, заполнен ли BidRequest.imp.video в запросе ставки.

%%HOSTED_MATCH_DATA%%

Заменено значением, основанным на BidRequest.user.buyeruid .

%%MOBILE_IS_APP%%

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

Найти идентификатор мобильного приложения по 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

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

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

BidRequest.user.data.segment

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

Вы можете определить, что значения представляют собой пары «ключ-значение», отправленные издателем, если для 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

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

Обратная связь в режиме реального времени заполняет BidRequest.ext.bid_feedback на основе результата одной или нескольких ставок, которые вы разместили ранее, и может использоваться для поиска таких подробностей, как, например, выиграла ли ставка на аукционе или минимальная ставка, необходимая для победы в аукционе. Свяжитесь с менеджером своего аккаунта, чтобы включить обратную связь в режиме реального времени.

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

Когда Авторизованные покупатели отправляют запрос ставки участнику торгов, тот отвечает 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

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

После размещения ставки на аукционе первой цены вы получите обратную связь в режиме реального времени, в том числе 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 без выравнивания формата объявления по сравнению с эквивалентным набором объединенных запросов:

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

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

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

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

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

В спецификации OpenRTB нет отдельных полей для указания максимальной продолжительности видео для рекламы с возможностью пропуска и без нее. Реализация Google использует выравнивание ставок, чтобы различать их с помощью существующих полей BidRequest.video.maxduration и BidRequest.video.skip .

Ниже приведен пример выравнивания видеоинвентаря, когда максимальная продолжительность объявления без возможности пропуска – 15 , а максимальная продолжительность объявления с возможностью пропуска – 60 .

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

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

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

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

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

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

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

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

Вы можете определить, поддерживает ли издатель Open Measurement в запросе ставки, проверив, исключает ли рекламная возможность атрибут OmsdkType: OMSDK 1.0 , который находится в атрибутах объявлений, исключаемых издателем . Его можно найти под атрибутом battr для Banner или Video , в зависимости от формата.

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

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

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

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

OpenRTB Протобуф

OpenRTB JSON

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

OpenRTB Протобуф

OpenRTB JSON

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

OpenRTB Протобуф

OpenRTB JSON

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

OpenRTB Протобуф

OpenRTB JSON

Веб-видео

OpenRTB Протобуф

OpenRTB JSON

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

OpenRTB Протобуф

OpenRTB JSON

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

OpenRTB Протобуф

OpenRTB JSON