Processar a solicitação

Uma interação de lance em tempo real começa quando o Google envia uma solicitação de lance para seu aplicativo. Este guia explica como codificar seu aplicativo para a solicitação de lance.

Analisar solicitação

O Google envia uma solicitação de lance como um buffer de protocolo serializado anexado como o payload binário de uma solicitação POST HTTP. O Content-Type está definido como application/octet-stream. Consulte Exemplo de solicitação de lance para ver um exemplo.

Analise essa solicitação em uma instância do BidRequest mensagem. BidRequest é definido em realtime-bidding.proto, que podem ser obtidos na página de dados de referência. É possível analisar a mensagem usando o método ParseFromString() na classe gerada para a BidRequest. Por exemplo, o código em C++ a seguir analisa uma solicitação recebe um payload POST em uma string: 

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

Depois de ter o BidRequest, você pode trabalhar com ele como um para extrair e interpretar os campos necessários. Por exemplo, em C++:

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

Algumas informações enviadas em um BidRequest, como o usuário do Google ID, idioma ou localização geográfica nem sempre estão disponíveis. Se você tiver grupos de anúncios de pré-segmentação que usam informações desconhecidas para um determinado impressão, esses grupos de anúncios não serão correspondentes. Nos casos em que os elementos for irrelevante para as condições de pré-segmentação, as solicitações de lance serão enviada com a informação omitida.

As informações sobre o grupo de anúncios de pré-segmentação estão disponíveis no MatchingAdData grupo para cada AdSlot. Ele contém primeiro ID do grupo de anúncios correspondente do grupo de anúncios de pré-segmentação que fez o Google envie a solicitação de lance, ou seja, o grupo de anúncios e a campanha cobrados se sua resposta vencer o leilão para a impressão. Abaixo de determinados circunstâncias, é necessário especificar explicitamente o billing_id para no BidResponse.AdSlot, por exemplo, quando o BidRequest.AdSlot tem mais de um matching_ad_data. Para mais informações sobre as restrições de conteúdo do lance, consulte o realtime-bidding.proto.

Arquivos de dicionário

A solicitação de lance usa identificadores definidos em arquivos de dicionário, que são disponíveis nos dados de referência página.

Macros de URLs de lances

Opcionalmente, alguns campos do BidRequest podem ser inseridos no o URL usado na solicitação POST HTTP. Isso é útil, por exemplo, se você usar um front-end leve com balanceamento de carga em vários back-ends usando um valor da solicitação. Entre em contato com seu gerente técnico de contas para solicitar suporte para novas macros.

MacroDescrição
%%GOOGLE_USER_ID%%

Substituído por google_user_id do BidRequest. Por exemplo, o URL do bidder 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
 será substituída por algo como 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
 no momento da solicitação.

Se o ID de usuário do Google for desconhecido, a string vazia será substituída por um resultado semelhante a

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

Substituído por 1 ou 0 ao chamar has_mobile() de BidRequest.
%%HAS_VIDEO%%

Substituído por 1 (verdadeiro) ou 0 (falso). ao chamar has_video() de BidRequest.
%%HOSTED_MATCH_DATA%%

Substituído pelo valor do campo hosted_match_data do BidRequest.
%%MOBILE_IS_APP%%

Substituído por 1 (verdadeiro) ou 0 (falso). do campo mobile.is_app de BidRequest.

Encontrar o ID do app para dispositivos móveis no URL da transação

As transações de aplicativos para dispositivos móveis informarão URLs com esta aparência:

mbappgewtimrzgyytanjyg4888888.com

Use um decodificador de base 32 para decodificar a parte da string em negrito (gewtimrzgyytanjyg4888888).

Você pode usar uma configuração decodificador, mas terá que colocar as letras maiúsculas e substituir as letras 8s com valores =.

Então, decodificando esse valor: 

GEWTIMRZGYYTANJYG4======
 resulta em: 
1-429610587
 A string 429610587 é o ID do app iOS. iFunny.

Veja outro exemplo. O URL denunciado é: 

mbappgewtgmjug4ytmmrtgm888888.com
 Decodificando esse valor: 
GEWTGMJUG4YTMMRTGM======
 resulta em: 
1-314716233
 O resultado 314716233 é o ID do app iOS. TextNow (link em inglês).

Encontrar o nome do app para dispositivos móveis no URL da transação

Veja um exemplo de como conseguir o nome do app. O URL informado é o seguinte: 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 Decodificando esse valor: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 resulta em: 
air.com.hypah.io.slither
 O resultado equivale ao app Android slither.io.

Campos do Open Bidding

Solicitações de lance enviadas para os bidders da troca e da rede que participam do Open Bidding Os lances são semelhantes aos dos Authorized Buyers que participam das campanhas padrão lances em tempo real. Os clientes do Open Bidding receberão um pequeno número de campos adicionais, e alguns campos existentes podem ter usos alternativos. Esses incluem o seguinte:

OpenRTB Authorized Buyers Detalhes
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

Contém o código de rede do Ad Manager do editor seguido pelo anúncio de unidade de medida, separados por barras.

Como exemplo, isso apareceria com uma formatação semelhante a: /1234/cruises/mars:
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

Pares de chave-valor repetidos enviados do editor para o bidder da troca.

Você pode determinar que os valores são pares de chave-valor enviados pelo editor quando BidRequest.user.data[].name for definido como “Publisher Passed”.

Declarar fornecedores permitidos

Fornecedores de tecnologia que prestam serviços como pesquisa, remarketing e a veiculação de anúncios pode desempenhar um papel na interação entre compradores e vendedores. Somente fornecedores com participação verificada pelo Google no Authorized Buyers são permitidas.

Para entender o BidRequest e criar seu BidResponse, você precisa conhecer os dois de declarar fornecedores de tecnologia:

  1. Alguns fornecedores não precisam ser declarados. esses fornecedores estão listados na Ajuda do Authorized Buyers.
  2. Outros fornecedores só poderão participar se forem declarados tanto no BidRequest e BidResponse:
    • No BidRequest, a allowed_vendor_type especifica quais fornecedores o vendedor permite. Fornecedores que serão enviados o campo allowed_vendor_type do BidRequest são listados em Vendors.txt de dicionário.
    • Na BidResponse, o campo vendor_type especifica quais desses fornecedores permitidos o comprador pretende usar.

Exemplo de solicitação de lance

Os exemplos a seguir representam amostras legíveis do Protobuf e Solicitações JSON.

Google

JSON do OpenRTB

Protobuf do OpenRTB

Para converter a solicitação de lance em um formato binário, da mesma forma que você faria com o POST em uma solicitação real, faça o seguinte (em C++). Observação: No entanto, isso não é aplicável ao JSON do 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
  }
}

Remarketing

O Authorized Buyers transmite um ID de publicidade para dispositivos móveis nas solicitações de lance de um aplicativo para dispositivos móveis. O ID de publicidade móvel pode ser uma IDFA do iOS ou ID de publicidade do Android, que é enviado pelo %%EXTRA_TAG_DATA%% na tag JavaScript gerenciada pelo Authorized Buyers.

A macro %%ADVERTISING_IDENTIFIER%% permite que os compradores recebam IDFA do iOS ou ID de publicidade do Android na renderização de impressões. Ele retorna uma buffer proto criptografado MobileAdvertisingId "gostei" %%EXTRA_TAG_DATA%%:

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

O user_id_type é um dos valores definidos no enum AdxMobileIdType:

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

Você pode criar listas de usuários com base em IDs de publicidade para dispositivos móveis usando IDs de publicidade. coletados durante a renderização de impressões. Essas listas de usuários podem ser mantidas no seu servidor ou no nosso. Para criar listas de usuários nos servidores do Google, você pode usar nosso recurso de upload em massa.

Quando o ID de publicidade para dispositivos móveis corresponde a uma lista de usuários, ele pode ser usado na execução remarketing.

Feedback em tempo real

O feedback em tempo real também está disponível para o Authorized Buyers. como trocas e redes que usam o Open Bidding.

O feedback da resposta do lance é compatível com a solicitação de lance subsequente para ambos protocolo AdX e OpenRTB. Para o OpenRTB, ele é enviado BidRequestExt:

Além dos campos padrão enviados no Feedback da resposta do lance, é possível também enviar dados personalizados na resposta do lance (no Proto do AdX ou no OpenRTB) usando um event_notification_token retornado no BidResponse. O event_notification_token é dados arbitrários conhecidos somente pelo proponente que possam ajudar na depuração, por exemplo: um novo ID de segmentação ou de lance que representa uma nova tática ou metadados associados ao criativo que o bidder sabe apenas. Para mais detalhes, consulte OpenRTB Buffer de protocolo de extensões (link em inglês) para RTB e Protocolo do AdX para o AdX.

Quando o Authorized Buyers envia uma solicitação de lance para um bidder, o bidder responde com um BidResponse. Se o bidder tiver ativado o feedback em tempo real, Em uma próxima solicitação de lance, o Authorized Buyers envia feedback sobre resposta em uma mensagem BidResponseFeedback, conforme mostrado abaixo:

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

A partir dessa mensagem, o primeiro campo a ser verificado é bid_response_feedback.creative_status_code você encontra o código significado em criativo-status-codes.txt. Se você ganhar o lance, poderá desativar com base no feedback sobre o preço. Para mais informações, consulte de não participar.

O feedback em tempo real inclui o ID da solicitação de lance e uma das seguinte:

Resultado do leilão Feedback em tempo real
O comprador não enviou um lance. Nada
O comprador enviou um lance que foi filtrado antes de alcançar no leilão. O código de status do criativo (creative-status-codes.txt).
O comprador enviou um lance, mas perdeu o leilão. O código de status do criativo 79 (lance superado em leilão).
O comprador enviou um lance que venceu o leilão. O preço de liberação e o código de status do criativo 1.

Para uma impressão de aplicativo e um código de status do criativo de 83, o editor de apps poderia estar usando uma hierarquia de mediação e, portanto, o lance vencedor teria competido com outra demanda na campanha a cadeia de cascata de passbacks. Saiba como usar sampled_mediation_cpm_ahead_of_auction_winner quando lances.

Exemplo

Confira a seguir um exemplo de feedback em tempo real protocolos:

Google

JSON do OpenRTB

Protobuf do OpenRTB

Criar um modelo de lances para leilões de primeiro preço

Depois de dar um lance em um leilão de primeiro preço, você receberá feedback, incluindo minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner se o lance não foi filtrada do leilão. Esses indicadores podem ser usados para informar lógica de lances com base em quanto maior ou menor seu lance poderia ter sido para ganhar a impressão.

  • minimum_bid_to_win: o lance mínimo que poderia ter sido para vencer o leilão de lances em tempo real. Se você tiver vencido o leilão, o lance mais baixo que você poderia ter feito e ainda fosse o vencedor. Se você perdeu o leilão, esse será o lance vencedor.
  • sampled_mediation_cpm_ahead_of_auction_winner: se houver outras redes na cadeia de mediação, a o valor deste campo é um preço que representa um lance de amostra de um dos redes de mediação qualificadas que foram maiores do que o vencedor do leilão, ponderados pela taxa de preenchimento esperada. Esse valor será definido como "0" se nenhuma das redes da cadeia de mediação precisa ser preenchida, ou se o editor não usar o SDK mediação.

Como funciona

Para descrever os cálculos usados para determinar os valores possíveis para minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner, primeiro precisamos defina o seguinte:

  • Veja a seguir os CPMs na cadeia de mediação em ordem decrescente:
    \[C_1, C_2, …, C_n\]
  • A tabela a seguir representa as taxas de preenchimento correspondentes para os CPMs na cadeia de mediação:
    \[f_1, f_2, …, f_n\]
  • A seguir, temos uma função usada para determinar o CPM esperado e seu probabilidade do elemento da cadeia de mediação \(i\), com base no preenchimento fornecido taxa:
    \(X_i = \{C_i\) com probabilidade \(f_i\); \(0\) com probabilidade \(1 - f_i\}\)
  • A cadeia de mediação vencedora final será:
    \[\{C_1, C_2, …, C_K, W\}\]
    em que \(W\) é o lance vencedor e \(C_K > W >= C_{K+1}\)
  • O preço de reserva, ou mínimo, é indicado como \(F\).
  • O lance secundário é indicado como \(R\).
Cálculos do vencedor do leilão
Campo Cálculo
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) com probabilidade \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Para \(1 <= i <= K\).
Cálculos para perdedor do leilão
Campo Cálculo
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

Exemplo com uma cadeia de mediação simples

Suponha que um editor use lances em tempo real e uma cadeia de mediação de SDK como da seguinte forma:

Cadeia de mediação do SDK CPM esperado Taxa de preenchimento
Rede 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
Rede 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
Rede 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
Rede 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

Considere o seguinte como resultado do leilão de RTB:

Leilão de RTB CPM
Vencedor do leilão (W) US$ 1,00
Segundo o leilão (R) US$ 0,05
Preço de reserva / mínimo (F) US$ 0
Lance que venceu o leilão

Veja a seguir um exemplo de como os valores e as probabilidades minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner são calculados para uma de lance que venceu.

minimum_bid_to_win Probabilidade
\(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		 Probabilidade
\(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\%\)
Lances que perderam o leilão

Veja a seguir um exemplo de como os valores e as probabilidades minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner são calculados para uma lances perdidos.

minimum_bid_to_win Probabilidade
\(max(F, W) = $1.00\) \(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 Probabilidade
\(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\%\)

Separação de lances

A separação de lances descreve o processamento de um único BidRequest em várias solicitações de lance que são enviadas aos seus para o aplicativo. Como eles retêm IDs idênticos (BidRequest.google_query_id no protocolo RTB do Authorized Buyers) ou BidRequestExt.google_query_id no protocolo OpenRTB), será possível determinar quais solicitações de lance estão correlacionadas após a separação.

Formatos de anúncio

Algumas oportunidades de anúncio aceitam vários formatos. Com a separação de lances, cada formato é enviado em uma solicitação de lance distinta em que atributos como IDs de faturamento são relevantes para o formato especificado na solicitação.

As solicitações de lance com os formatos a seguir serão reduzidas solicitações de lance distintas:

  • Banner
  • Vídeo
  • Áudio
  • Nativo

Exemplo de separação do formato do anúncio

Veja abaixo um exemplo que mostra uma solicitação de lance JSON do OpenRTB simplificada sem anúncio nivelamento de formato em comparação com um conjunto equivalente de solicitações simplificadas:

Pré-nivelar

Pós-achatamento

Ofertas

Uma oportunidade de anúncio para determinado bidder pode ser aplicável a várias transações diferentes, além do leilão aberto. Com a separação de lances para transações, um lance solicitação será enviada para o leilão aberto e uma para cada tipo de item de linha negócios. Na prática, as restrições de anúncios podem variar entre leilões e preços fixos de transações, por exemplo, para uma determinada oportunidade de anúncio em vídeo disponível para no leilão aberto e na transação de preço fixo, um proponente receberá diferentes solicitações de lance para cada um, em que restrições como duração máxima do anúncio e se os anúncios puláveis permitidos podem ser diferentes. Como resultado, a separação é aplicada ao anúncio permite que você discuta mais facilmente as restrições de anúncios para a campanha leilão e a transação de preço fixo.

Duração máxima do vídeo pulável

O protocolo do Google e a implementação do OpenRTB são compatíveis com os seguintes campos para a duração do vídeo e a possibilidade de pular:

Duração Duração do trecho pulável Recurso para pular
Protocolo do Google max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration N/A skip

Isso significa que, embora o protocolo do Google possa ter um link e duração não pulável, a implementação do OpenRTB tem apenas um o valor máximo da duração.

Antes da separação de lances, o maxduration do OpenRTB era definido como o menor dos max_ad_duration do protocolo do Google e Campos skippable_max_ad_duration. Esse comportamento mudou para enviar duas solicitações de lance separadas quando esses valores forem diferentes: uma representando os campos maxduration para puláveis e os não puláveis oportunidades.

Os exemplos a seguir mostram como uma solicitação de protocolo do Google converte para o OpenRTB antes e depois da separação de lances. O protocolo equivalente do Google solicitação tem um max_ad_duration de 15 e um skippable_max_ad_duration de 60.

Exemplo max_ad_duration skip (verdadeiro OU falso)
Solicitação original sem nivelamento 15 true
Solicitação nivelada no 1: não pulável 15 false
Solicitação nivelada no 2: pulável 60 true

A separação da solicitação de lance de duração de vídeo pulável só vai ocorrer quando estas condições sejam atendidas:

  • A solicitação permite vídeo.
  • Vídeos pulados e não puláveis são permitidos, e os dois respectivos e durações diferentes em termos de valor.
  • Esta solicitação está qualificada para leilões privados ou abertos.
  • A conta do bidder tem endpoints OpenRTB ativos.

Para desativar esse tipo de nivelamento, entre em contato com seu gerente de contas.

Conjuntos de vídeos

As solicitações de lance para um conjunto de vídeos com várias oportunidades de anúncio são separadas, de modo que cada solicitação de lance seja para uma oportunidade de anúncio individual desse conjunto. Isso permite que você dê lances em várias oportunidades de anúncio para um determinado conjunto.

Open Measurement

Com o Open Measurement, você pode especificar fornecedores terceirizados que serviços independentes de medição e verificação para anúncios veiculados em apps para dispositivos móveis e ambientes de teste.

É possível determinar se um editor aceita o Open Measurement no lance solicitação verificando se a oportunidade de anúncio exclui o atributo OmsdkType: OMSDK 1.0 encontrado em Editor excluído atributos do criativo. Para o protocolo do Authorized Buyers, seria encontrado abaixo de BidRequest.adslot[].excluded_attribute. Para o protocolo OpenRTB, encontrado no atributo battr para Banner ou Vídeo, dependendo o formato.

Para mais informações sobre como interpretar solicitações de lance que contêm indicadores de medição, consulte a documentação do do SDK da Central de Ajuda.

Exemplos de solicitações de lance

As seções a seguir mostram exemplos de solicitações de lance para diferentes tipos de anúncio.

Banner de aplicativo

Google

JSON do OpenRTB

Protobuf do OpenRTB

Intersticial de app

Google

JSON do OpenRTB

Protobuf do OpenRTB

Vídeo de intersticial do app

Google

Protobuf do OpenRTB

Nativo do app

Google

JSON do OpenRTB

Protobuf do OpenRTB

Vídeo na Web

Google

Banner da Web para dispositivos móveis para o bidder da troca

Protobuf do OpenRTB