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

Взаимодействие в режиме реального времени при размещении ставок начинается, когда 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 . 

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

Определите заблокированные категории

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

Заблокированные категории для показа можно найти, просмотрев поле BidRequest.bcat , которое заполняется категориями из таксономии, настроенной для вашей учетной записи.

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

Классификация контента IAB 1.0 

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}

Словарные файлы

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

Макросы 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

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

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

Итак, расшифровав это значение:

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

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

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

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

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

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

Открытые поля для торгов

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

OpenRTB Подробности
BidRequest.imp.ext.dfp_ad_unit_code

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

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

BidRequest.user.data.segment

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

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

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

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

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

  1. Некоторых поставщиков указывать не нужно; они перечислены в списке сертифицированных внешних поставщиков Ad Manager .
  2. Другие поставщики могут участвовать только в том случае, если они указаны в BidRequest :
    • В BidRequest поле BidRequest.imp.ext.allowed_vendor_type указывает, каких поставщиков разрешает продавец. Поставщики, которые будут указаны в поле allowed_vendor_type , перечислены в словаре vendors.txt .

Пример запроса на участие в тендере

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

OpenRTB Protobuf

OpenRTB JSON

Чтобы преобразовать запрос на ставку в двоичный формат, подобный тому, который вы получаете из полезной нагрузки POST-запроса в реальном запросе, можно сделать следующее (на C++). Однако следует отметить, что это неприменимо к JSON OpenRTB. 

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

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

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

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

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

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

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

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

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 [deprecated = true];
}

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

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

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

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

Образец

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

OpenRTB Protobuf

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 , нам сначала необходимо определить следующее:

  • Ниже представлен список CPM в цепочке медиации в порядке убывания:
    \[C_1, C_2, …, C_n\]
  • Ниже представлены соответствующие коэффициенты заполнения для CPM в цепочке медиации:
    \[f_1, f_2, …, f_n\]
  • Ниже представлена ​​функция, используемая для определения ожидаемого значения CPM и его вероятности на основе элемента цепочки медиации. \(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 Ожидаемый CPM Коэффициент заполнения
Сеть 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 CPM
Победитель аукциона (W) 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 .

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

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

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

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

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

Пример сглаживания формата рекламы

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

Предварительно расплющите

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

Сделки

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

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

В спецификации 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 для баннера или видео , в зависимости от формата.

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

Примеры запросов на участие в тендерах

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

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

OpenRTB Protobuf

OpenRTB JSON

межстраничное приложение

OpenRTB Protobuf

OpenRTB JSON

Вставка в приложение

OpenRTB Protobuf

OpenRTB JSON

Приложение нативное

OpenRTB Protobuf

OpenRTB JSON

Веб-видео

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

Многоформатные нативные и видеоформаты

OpenRTB Protobuf

OpenRTB JSON