Criar a resposta

Depois que seu aplicativo processar a solicitação de lance do Google, ele deverá criar e enviar uma resposta. Este guia explica como programar seu aplicativo para criar a resposta.

Criar mensagem Protobuf BidResponse

O Authorized Buyers envia BidRequest como o corpo da mensagem de um POST HTTP. Caso seu endpoint de lances esteja configurado para usar o Protobuf, seu aplicativo deve enviar uma resposta com os O cabeçalho Content-Type foi definido como application/octet-stream e um corpo de mensagem consistindo em um buffer de protocolo serializado. O buffer de protocolo é uma mensagem BidResponse, conforme definido em openrtb.proto. Seu aplicativo precisa retornar um BidResponse analisável em resposta a cada BidRequest. Tempos limite e as respostas que não podem ser analisadas são consideradas erros, e as limitações do Google proponentes com altas taxas de erro.

Se não quiser dar um lance em uma impressão, defina o BidResponse.ext.processing_time_ms sozinho e deixe todos outros campos vazios. É possível acessar openrtb.proto na página dados de referência.

ID do criativo

O BidResponse especifica um criativo pelo campo BidResponse.seatbid.bid.crid (limite de 64 bytes). Mesmo semelhantes criativos devem ter valores únicos para este campo se forem diferentes em características notáveis, incluindo, mas não se limitando a: tamanho, URL declarado, atributos de criativo e tipos de fornecedor. Em outras palavras, você deve dar diferentes IDs de criativo a dois anúncios que:

  • Ter uma aparência ou um comportamento diferente.
  • Renderizar em imagens diferentes.
  • Renderização por diferentes meios (por exemplo, um anúncio consiste em uma imagem, enquanto o outro é um vídeo).

Ao projetar seu aplicativo, decida uma maneira sistemática de gerar identificadores que faça sentido para os tipos de criativos que você planeja enviar.

Atributos do anúncio

O Google recomenda declarar atributos do criativo para descrever a características e sua segmentação usando uma combinação de BidResponse.seatbid.bid.apis e BidResponse.seatbid.bid.attr ou a BidResponse.seatbid.bid.ext.attribute extensão. O seguinte descreve como declarar atributos:

  • VPAID
    Defina BidResponse.seatbid.bid.apis como VPAID_1 ou VPAID_2. Para o formato JSON, ele pode ser definido como 1 ou 2, respectivamente.
  • MRAID
    Defina BidResponse.seatbid.bid.apis como MRAID_1 ou 3 para o formato JSON.
  • SIZELESS
    Definir BidResponse.seatbid.bid.attr como RESPONSIVE ou 18 para o JSON .
  • PLAYABLE
    Isso é indicado pela configuração de BidResponse.seatbid.bid.attr. como USER_INTERACTIVE ou 13 para o JSON .

Consulte a Recurso de criativos para saber como receber feedback sobre as propriedades detectadas seus criativos.

Campos do Open Bidding

As respostas de lance enviadas por bidders de troca e de rede que participam do Open Bidding são semelhantes às dos Authorized Buyers que participam dos lances em tempo real padrão. Os clientes do Open Bidding podem especificar um pequeno número de campos adicionais, e alguns campos atuais podem ter usos alternativos. Isso inclui o seguinte:

OpenRTB Authorized Buyers Detalhes
BidResponse.imp[].pmp.deals[].id BidResponse.ad[].adslot[].exchange_deal_id

É o ID da transação do namespace da troca associado a esta lance e informados aos editores.

BidResponse.seatbid[].bid[].ext.exchange_deal_type BidResponse.ad[].adslot[].exchange_deal_type

O tipo de transação informado aos editores, afetando o modo como ela é tratados no leilão.

BidResponse.seatbid[].bid[].ext.third_party_buyer_token BidResponse.ad[].adslot[].third_party_buyer_token Token usado para identificar as informações do comprador de terceiros final se os de rede como um Open Bidding é um intermediário. Ele é obtido do comprador terceirizado e precisa ser transmitido ao Google sem alterações na resposta do lance.

Recomendações

  • Ative as conexões HTTPS persistentes (também conhecidas como "sinal de atividade" ou "reuso de conexão") nos servidores. Defina o tempo limite como mínimo de 10 segundos. Valores mais altos são benéficos em muitos casos. O Google verifica isso durante os testes iniciais de latência do seu aplicativo, porque os compradores autorizados enviam solicitações a uma taxa alta e precisam evitar a sobrecarga de latência ao estabelecer uma conexão TCP separada para cada solicitação.
  • Inclua o URL de rastreamento de impressões opcional para acompanhar quando a impressão é renderizada, e não quando o bidder vence. Por causa da desistência entre vitórias e renderizações, isso gera um rastreamento estatísticas.

  • Mantenha o código do bidder sem dependências de campos descontinuados, que podem causar erros nos lances.
  • Inclua BidResponse.seatbid.bid.w e BidResponse.seatbid.bid.h no BidResponse. Uma BidResponse para uma solicitação que inclui vários tamanhos de anúncio precisa incluir esses campos ou será removida do leilão.
  • Limite o tamanho da resposta para menos de 8 KB. Respostas muito grandes podem aumentar a latência da rede e causar tempos limite.
  • Siga as diretrizes para lances em inventário do iOS que exigem atribuição da SKAdNetwork.

Exemplo de resposta de lance

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

Protobuf do OpenRTB

JSON do OpenRTB

Google

Importante: as mensagens Protobuf descritas nas amostras são representadas aqui como texto legível por humanos. No entanto, não é assim que as mensagens são enviadas pela rede. Ao usar o formato Protobuf do Google ou do OpenRTB, somente mensagens BidResponse serializadas serão aceitas.

É possível criar e serializar uma mensagem BidResponse usando o seguinte código C++:

BidResponse bid_response;
// fill in bid response with bid information
string post_response;
if (bid_response.SerializeToString(&post_response)) {
  // respond to the POST with post_response as the content
} else {
  // return an error to the POST
}

Especificar o criativo

Sua resposta do lance especifica o criativo que será veiculado se o lance vencer. Seu lance precisa incluir um dos formatos de anúncio compatíveis (AMP, vídeo, nativo). Neste exemplo, especificamos o criativo usando o campo html_snippet.

Como alternativa, é possível especificar o criativo usando um dos métodos campos a seguir, com base no formato do anúncio:

  • Anúncio renderizado pelo SDK
    • BidResponse.seatbid.bid.ext.sdk_rendered_ad
  • AMP
    • BidResponse.seatbid.bid.amp_ad_url
  • Vídeo
    • BidResponse.seatbid.bid.adm
  • Nativo
    • BidResponse.seatbid.bid.adm_native

Especifique um anúncio hospedado em seus próprios servidores usando um snippet HTML em o campo BidResponse.seatbid.bid.adm. O snippet está incluído um iframe inserido na página da web, resultando na recuperação do anúncio e renderizado quando a página é carregada. Você deve criar o snippet HTML para que o anúncio (banner ou intersticial) é renderizado corretamente em um iframe e em um tamanho apropriado para o espaço de anúncio para o qual você está definindo lances.

Além disso, o tamanho do anúncio declarado na resposta do lance precisa corresponder exatamente a uma das combinações de tamanho na solicitação de lance quando:

  • Um anúncio é um banner comum (não em vídeo, nativo ou intersticial).
  • O bidder declarou o tamanho na resposta do lance. A declaração de tamanho é necessária sempre que mais de um tamanho estiver presente na solicitação.
  • Há uma exceção para anúncios intersticiais. Para intersticiais, a largura precisa ser de pelo menos 50% da largura da tela e a altura de pelo menos 40% da altura da tela.

É possível especificar um criativo de snippet HTML usando qualquer código HTML válido que seja renderizado corretamente, mas lembre-se das restrições para especificar o campo crid na seção Criar mensagem BidResponse. Um uso para isso é colocar informações extras em argumentos dos URLs que são buscados em seus servidores como parte da renderização do anúncio. Isso permite que você transmita dados arbitrários sobre a impressão de volta para seus próprios servidores.

A maioria das políticas para snippets HTML retornados nas respostas de lance é a mesma das para anúncios de terceiros. Consulte Authorized Buyers Diretrizes do programa, Requisitos para terceiros veiculação de anúncios e Declarar URLs de clique nos anúncios para mais informações.

Especificar macros

Macros são textos formatados incorporados em alguns campos de resposta de lance que contêm URLs que são substituídos por um valor relevante no momento da veiculação do anúncio. Por exemplo, se o lance vencedor incluir a macro AUCTION_PRICE no criativo de snippet HTML incluído no lance, ela será substituída por um valor que pode ser descriptografado para determinar o valor pago pela impressão no leilão.

É possível incluir macros nos seguintes campos:

  • BidResponse.seatbid.bid.adm

    As macros são compatíveis com os formatos de snippet HTML, nativo, URL de vídeo e XML VAST de vídeo.

  • BidResponse.seatbid.bid.adm_native.eventtrackers.url

  • BidResponse.seatbid.bid.adm_native.imptrackers

  • BidResponse.seatbid.bid.ext.amp_ad_url

    Somente as propriedades WINNING_PRICE e WINNING_PRICE_ESC macros são compatíveis com criativos AMP.

  • BidResponse.seatbid.bid.burl

  • BidResponse.seatbid.bid.ext.impression_tracking_url

    Use essa opção em vez de BidResponse.seatbid.bid.burl se você exigem mais de um URL de faturamento.

Por exemplo, é possível incluir uma macro como parte de um snippet HTML incorporando ${MACRO} no URL usado para buscar o criativo, em que MACRO é uma das macros compatíveis descritas na especificação do OpenRTB.

Macros de RTB do Google

O Google aceita outras macros além daquelas encontradas no OpenRTB especificação. Eles são formatados de forma diferente e apareceriam como %%MACRO%% se incorporado em um URL. A tabela a seguir descreve essas macros:

Macro Descrição
ADVERTISING_IDENTIFIER Permite que os compradores recebam o IDFA do iOS ou o ID de publicidade do Android no renderização de impressões. Consulte Como descriptografar identificadores de anunciantes para mais detalhes.
CACHEBUSTER Uma representação de string de um número inteiro de quatro bytes aleatório não assinado.
CLICK_URL_UNESC

O URL de clique sem escape do anúncio. No snippet, um valor de escape do URL de clique de terceiros deve seguir diretamente os .

Por exemplo, se o URL de clique de terceiros for http://my.adserver.com/some/path/handleclick?click=clk, o código a seguir poderá ser usado com a versão com escape único do URL de clique de terceiros após a invocação da macro:

<a href="%%CLICK_URL_UNESC%%http%3A%2F%2Fmy.adserver.com%2Fsome%2Fpath%2Fhandleclick%3Fclick%3Dclk"></a>

No momento da veiculação do anúncio, ele é expandido para:

<a href="http://google-click-url?...&ad_url=http%3A%2F%2Fmy.adserver.com%2Fsome%2Fpath%2Fhandleclick%3Fclick%3Dclk"></a>

O URL vai registrar o clique com o Google e redirecionar para o URL de clique de terceiros.

CLICK_URL_ESC

O URL de clique com escape para o anúncio. Use esse valor em vez de CLICK_URL_UNESC se você precisar transmitir primeiro o valor por outro servidor que vai retornar um redirecionamento.

Por exemplo, o código a seguir pode ser usado em um snippet HTML:

<a href="http://my.adserver.com/click?google_click_url=%%CLICK_URL_ESC%%"></a>

No momento da veiculação do anúncio, ele é expandido para:

<a href="http://my.adserver.com/click?google_click_url=http://google-click- url%3F...%26ad_url%3D"></a>

Isso registrará o clique com my.adserver.com, que será responsável pelo redirecionamento para o URL passado no parâmetro google_click_url. Isso pressupõe que my.adserver.com retorna o escape do parâmetro google_click_url.

É possível anexar um URL com escape duplo após %%CLICK_URL_ESC%%. Depois que o processo de decodificação é feito por my.adserver.com, isso deixa uma versão com um único escape do URL anexado ao google_click_url. Quando o google_click_url foi buscado, ficará sem escape mais uma vez e redirecionar.

CLICK_URL_ESC_ESC

O URL com escape duplo para o anúncio. Use esse valor em vez de CLICK_URL_UNESC se você precisar transmitir o valor primeiro por outro servidor que vai retornar um redirecionamento.

Por exemplo, o código a seguir pode ser usado em um snippet HTML:

<a href="http://my.adserver.com/click?google_click_url=%%CLICK_URL_ESC_ESC%%"></a>

No momento da veiculação do anúncio, ele é expandido para:

<a href="http://my.otheradserver.com/click?google_click_url=http%3A%2F%2Fmy.adserver.com%2Fclick%3Fgoogle_click_url%3Dhttp%3A%2F%2Fgoogle-click-%20url%253F...%2526ad_url%253D"></a>
SCHEME Expandido para http: se a solicitação de lance não exigir SSL ou para https: se a solicitação de lance exigir SSL.
SITE É o domínio do URL de conteúdo com escape ou o ID anônimo do inventário anônimo.
SITE_URL Obsoleto. Substituída pela macro SITE, que fornece funcionalidade idêntica.
TZ_OFFSET A diferença de fuso horário.
VERIFICATION

Os diferentes valores para produção e quando o criativo é verificado no pipeline de verificação. O formato é: %%?VERIFICATION:true-val:false-val%%, em que qualquer valor exceto que as macros podem ser usadas para true-val e false-val, incluindo strings vazias. Para o Open Bidding, recomendamos que as trocas usem essa macro. depois que fazem isso, o lado da demanda e plataformas não precisam fazer alterações.

Por exemplo, se um criativo incluir %%?VERIFICATION:-1:5000%% e a substituição do texto. seria 5000 na veiculação e -1 na pipeline de verificação. Isso ajuda a diferenciar entre essas dois conjuntos de pings.

WINNING_PRICE

O custo de impressão codificado (ou seja, CPI em vez de CPM) em micros da moeda da conta. Por exemplo, um CPM vencedor de US $5 corresponde a 5.000.000 micros de CPM ou 5.000 micros de CPI. O valor decodificado de WINNING_PRICE nesse caso seria 5.000. O preço vencedor é especificado no CPI.

Para analisar essa macro, você precisa implementar um aplicativo que descriptografa as confirmações de preço. Consulte a página Como descriptografar confirmações de preço para mais informações.

WINNING_PRICE_ESC WINNING_PRICE com escape do URL.

O Google exige que você use as APIs CLICK_URL_UNESC ou CLICK_URL_ESC no criativo do terceiro veiculado anúncio. O Google usa as macros CLICK_URL para o acompanhamento de cliques.

O escape de URL em macros usa o seguinte esquema:

  • O caractere de espaço é substituído por um sinal de adição (+).
  • Os caracteres alfanuméricos (0-9, a-z, A-Z) e os caracteres do conjunto !()*,-./:_~ permanecem inalterados.
  • Todos os outros caracteres são substituídos por %XX, em que XX é o hexadecimal número que representa o caractere.

Restrições e requisitos para editores

A solicitação de lance inclui informações sobre os tipos de restrições e que os editores definem para os criativos no leilão.

  • BidRequest.bcat
    • É possível comparar as categorias bloqueadas especificadas por esse campo com as detectadas para os criativos enviados usando o campo detectedCategories da API Real-time Bidding.
  • BidRequest.imp.ext.allowed_vendor_type
  • BidRequest.imp.secure
    • Na prática, ele sempre será definido como true porque O Google exige suporte a SSL para todos os criativos.
  • BidRequest.imp.{audio/banner/native/video}
  • BidRequest.imp.{audio/banner/native/video}.api
  • BidRequest.imp.{audio/banner/native/video}.battr
  • BidRequest.imp.{audio/banner/video}.mimes

Nunca dê lances com um anúncio que contenha um recurso restrito. Para recursos permitidos, como o tipo de fornecedor, retorne um anúncio somente se o tipo de fornecedor estiver na lista allowed_vendor_type no BidRequest. Somente anúncio formatos especificados na solicitação de lance preenchendo campos como BidRequest.imp.banner precisa ser incluído no seu lance. Consulte a comentários para esses campos no buffer de protocolo BidRequest para mais detalhes.

Se um anúncio for retornado em BidResponse, você vai precisar defina BidResponse.seatbid.bid.attr com precisão, BidResponse.seatbid.bid.cat e BidResponse.seatbid.bid.adomain ou BidResponse.seatbid.bid.adm_native.link.url nos campos BidResponse: Se um anúncio tiver vários valores aplicáveis para esses campos, você precisará incluir todos os valores. Leia os comentários sobre esses campos em a definição do buffer de protocolo BidResponse para mais detalhes. As respostas que não tiverem esses campos definidos serão descartadas.

Open Measurement

Com o Open Measurement, você pode 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.

Os formatos de anúncio compatíveis incluem anúncios em vídeo, banner e intersticiais. Para mais informações sobre como usar o Open Measurement em uma resposta de lance que contenha essas formatos, consulte o SDK do Open Measurement artigo da Central de Ajuda.

Exemplos de respostas de lance

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

Banner de aplicativo

Protobuf do OpenRTB

JSON do OpenRTB

Google

Intersticial de app

Protobuf do OpenRTB

JSON do OpenRTB

Google

Vídeo intersticial do app

Protobuf do OpenRTB

Google

Nativo do app

Protobuf do OpenRTB

JSON do OpenRTB

Google

Vídeo na Web

Google

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

Protobuf do OpenRTB