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. Neste guia, explicamos como codificar seu aplicativo para processar 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 da mensagem BidRequest. BidRequest é definido em realtime-bidding.proto, que pode ser recebido na página de dados de referência. Você pode analisar a mensagem usando o método ParseFromString() na classe gerada para o BidRequest. Por exemplo, o código C++ a seguir analisa uma solicitação dada 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 objeto, extraindo e interpretando 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 User-ID, o idioma ou a localização geográfica do Google, nem sempre estão disponíveis. Se você tiver grupos de anúncios de pré-segmentação que usam informações desconhecidas para uma determinada impressão, esses grupos de anúncios não serão correspondentes. Nos casos em que as informações ausentes não são importantes para as condições de pré-segmentação, as solicitações de lance são enviadas com as informações omitidas.

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

Arquivos de dicionário

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

Macros do URL do lance

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

MacroDescrição
%%GOOGLE_USER_ID%%

Ele foi substituído pelo google_user_id do BidRequest. Por exemplo, o URL do bidder

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
será substituído 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, com um resultado semelhante a:

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

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

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

Ele foi substituído pelo valor do campo hosted_match_data de BidRequest.
%%MOBILE_IS_APP%%

Substituído por 1 (verdadeiro) ou 0 (falso) do campo mobile.is_app do 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 base-32 para decodificar a parte da string em negrito (gewtimrzgyytanjyg4888888).

Você pode usar um decodificador on-line, mas precisará usar letras maiúsculas nas letras e substituir 8s à direita por valores =.

Portanto, decodificar este valor: 

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

Veja outro exemplo. O URL informado é: 

mbappgewtgmjug4ytmmrtgm888888.com
A decodificação deste valor: 
GEWTGMJUG4YTMMRTGM======
resulta em: 
1-314716233
O resultado 314716233 é o ID do app para iOS TextNow.

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

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

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
A decodificação desse valor: 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
resulta em: 
air.com.hypah.io.slither
O resultado equivale ao app Android slither.io.

Campos do Open Bidding

As solicitações de lance enviadas aos bidders da troca e da rede que participam do Open Lances são semelhantes às dos Authorized Buyers que participam de lances padrão 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. Elas 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 pela hierarquia do bloco de anúncios, separado por barras.

Por exemplo, ele vai aparecer 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 pelo editor para troca do bidder.

É possível determinar que os valores são pares de chave-valor enviados pelo editor quando BidRequest.user.data[].name estiver definido como “Publisher Passed”.

Declarar fornecedores permitidos

Os fornecedores de tecnologia que prestam serviços como pesquisa, remarketing e veiculação de anúncios podem desempenhar um papel na interação entre compradores e vendedores. Somente fornecedores aprovados pelo Google para participação nas interações do Authorized Buyers são permitidos.

Para entender o BidRequest e criar sua BidResponse, você precisa estar ciente das duas possibilidades diferentes para declarar fornecedores de tecnologia:

  1. Alguns fornecedores não precisam ser declarados. Eles estão listados na Ajuda do Authorized Buyers.
  2. Outros fornecedores só poderão participar se forem declarados no BidRequest e no BidResponse:
    • Em BidRequest, o campo allowed_vendor_type especifica quais fornecedores são permitidos pelo vendedor. Os fornecedores que serão enviados no campo allowed_vendor_type do BidRequest estão listados no arquivo de dicionário Vendors.txt.
    • Em BidResponse, o campo vendor_type especifica quais fornecedores permitidos o comprador pretende usar.

Exemplo de solicitação de lance

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

Google

JSON do OpenRTB

Protobuf do OpenRTB

Para converter a solicitação de lance em um formato binário, como você receberia do payload POST em uma solicitação real, faça o seguinte (em C++). No entanto, isso não se aplica 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 apps para dispositivos móveis. O ID de publicidade para dispositivos móveis pode ser um IDFA do iOS ou um ID de publicidade do Android, que é enviado pela macro %%EXTRA_TAG_DATA%% na tag JavaScript gerenciada pelo Authorized Buyers.

A macro %%ADVERTISING_IDENTIFIER%% permite que os compradores recebam o IDFA do iOS ou o ID de publicidade do Android na renderização de impressões. Ela retorna um buffer proto criptografado MobileAdvertisingId, como %%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,
};

É possível criar listas de usuários com base nos IDs de publicidade para dispositivos móveis utilizando os IDs de publicidade coletados durante a renderização de impressões. Essas listas de usuários podem ser mantidas em seu servidor ou no nosso. Para criar listas de usuários nos servidores do Google, use o recurso de upload em massa.

Quando o ID de publicidade para dispositivos móveis corresponder a uma lista de usuários, você poderá usá-lo para fazer remarketing.

Feedback em tempo real

O feedback em tempo real está disponível para o Authorized Buyers, as trocas e as redes que usam o Open Bidding.

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

Além dos campos padrão enviados no feedback de resposta do lance, também é possível 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 são dados arbitrários conhecidos apenas pelo bidder que podem 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 só o bidder conhece. Para mais detalhes, consulte Buffer de protocolo de extensões do OpenRTB para RTB e AdX Proto para o AdX.

Quando o Authorized Buyers envia uma solicitação de lance a um bidder, o bidder responde com um BidResponse. Se o bidder tiver o feedback em tempo real ativado, em uma solicitação de lance subsequente, o Authorized Buyers vai enviar feedback sobre a 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;
}

Nesta mensagem, o primeiro campo que você precisa verificar é bid_response_feedback.creative_status_code. É possível encontrar o significado do código em creative-status-codes.txt. Se você ganhar o lance, poderá desativar o feedback de preço. Para mais informações, consulte Como desativar.

O feedback em tempo real inclui o ID da solicitação de lance e um dos seguintes itens:

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 chegar ao 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 no 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 app e um código de status do criativo de 83, o editor do app poderia estar usando uma hierarquia de mediação e, portanto, o lance vencedor teria competido com outra demanda na cadeia de hierarquia de passback do editor. Saiba como usar o sampled_mediation_cpm_ahead_of_auction_winner ao dar lances.

Exemplo

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

Google

JSON do OpenRTB

Protobuf do OpenRTB

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

Depois de definir um lance em um leilão de primeiro preço, você vai receber feedback em tempo real, incluindo os campos minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner, se o lance não tiver sido filtrado do leilão. Esses indicadores podem ser usados para informar sua lógica de lances sobre o quanto o lance poderia ser maior ou menor para vencer a impressão.

  • minimum_bid_to_win: o lance mínimo que poderia ter sido feito para vencer o leilão de lances em tempo real. Se você venceu o leilão, esse será o lance mais baixo que poderia ter feito enquanto ainda venceria. 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, o valor desse campo será um preço que representa um lance de amostra de uma das redes de mediação qualificadas que foram maiores do que o vencedor do leilão, ponderado pela taxa de preenchimento esperada. Ele será definido como 0 se nenhuma das redes na cadeia de mediação tiver que ser preenchida ou se o editor não usar a mediação do SDK.

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 definir o seguinte:

  • Veja a seguir os CPMs na cadeia de mediação em ordem decrescente:
    \[C_1, C_2, …, C_n\]
  • Confira a seguir as taxas de preenchimento correspondentes aos CPMs na cadeia de mediação:
    \[f_1, f_2, …, f_n\]
  • Veja a seguir uma função usada para determinar o CPM esperado e a probabilidade dele do elemento da cadeia de mediação \(i\), com base na taxa de preenchimento especificada:
    \(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 do segundo lugar é indicado como \(R\).
Cálculos para o 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 o 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 do SDK da seguinte maneira:

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 RTB:

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

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

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 de minimum_bid_to_win e sampled_mediation_cpm_ahead_of_auction_winner são calculados para 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\%\)

Redução de lances

A separação de lances descreve o processamento de uma única BidRequest complexa em várias solicitações de lance que são enviadas ao seu aplicativo. Como elas retêm IDs idênticos (BidRequest.google_query_id no protocolo RTB do Authorized Buyers ou BidRequestExt.google_query_id no protocolo OpenRTB), é possível determinar quais solicitações de lance sã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 qualificados, são relevantes para o formato especificado na solicitação.

As solicitações de lance que contêm os formatos a seguir serão divididas em solicitações de lance distintas:

  • Banner
  • Video
  • Áudio
  • Nativo

Exemplo de nivelamento do formato do anúncio

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

Pré-nivelar

Depois do achatamento

Ofertas

Uma oportunidade de anúncio para um determinado bidder pode ser aplicada a vários tipos de transação, além do leilão aberto. Com a separação de lances, uma solicitação de lance é enviada para o leilão aberto e outra para cada tipo de transação de preço fixo. Na prática, as restrições de anúncios podem ser diferentes entre leilões e tipos de transação de preço fixo. Por exemplo, para uma determinada oportunidade de anúncio em vídeo disponível para o leilão aberto e para uma transação de preço fixo, um bidder vai receber solicitações de lance diferentes para cada um, em que as restrições, como duração máxima do anúncio e se os anúncios puláveis são permitidos podem ser diferentes. Como resultado, o nivelamento aplicado à oportunidade de anúncio permite discernir com mais facilidade as restrições de anúncios para o leilão aberto 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 duração e capacidade de pular do vídeo:

Duração Duração do trecho pulável Capacidade de 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 uma duração granular pulável e não pulável, a implementação do OpenRTB tem apenas um único valor de duração máxima.

Antes do nivelamento de lances, o maxduration do OpenRTB seria definido como o menor valor dos campos max_ad_duration e skippable_max_ad_duration do protocolo do Google. Esse comportamento mudou para enviar duas solicitações de lance separadas quando esses valores forem diferentes: um representando maxduration para anúncios puláveis e outro para oportunidades não puláveis.

Os exemplos a seguir mostram como uma solicitação de protocolo do Google é convertida em OpenRTB antes e depois do nivelamento de lances. A solicitação de protocolo do Google equivalente 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 das solicitações de lance de duração de vídeos puláveis só acontece quando estas condições são atendidas:

  • A solicitação permite vídeo.
  • Vídeos pulados e não puláveis são permitidos, e as duas durações máximas são diferentes em termos de valor.
  • Esta solicitação está qualificada para leilão privado ou leilão aberto.
  • A conta do bidder tem endpoints do OpenRTB ativos.

Para desativar esse tipo de separação, entre em contato com seu gerente técnico de contas.

Conjuntos de vídeo

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

Open Measurement

Com o Open Measurement, é possível especificar fornecedores terceirizados que oferecem serviços independentes de medição e verificação para anúncios veiculados em ambientes de apps para dispositivos móveis.

Para determinar se um editor é compatível com o Open Measurement na solicitação de lance, verifique se a oportunidade de anúncio exclui o atributo OmsdkType: OMSDK 1.0 encontrado em Atributos de criativo excluídos pelo editor. Para o protocolo do Authorized Buyers, ele fica em BidRequest.adslot[].excluded_attribute. Para o protocolo OpenRTB, ele pode ser encontrado no atributo battr de Banner ou Vídeo, dependendo do formato.

Para mais informações sobre como interpretar solicitações de lance que contêm indicadores do Open Measurement, consulte o artigo SDK do Open Measurement 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úncios.

Banner de aplicativo

Google

JSON do OpenRTB

Protobuf do OpenRTB

Intersticial de app

Google

JSON do OpenRTB

Protobuf do OpenRTB

Vídeo intersticial de 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 de troca

Protobuf do OpenRTB