Anúncios em vídeo

Este guia descreve os requisitos de integração, a configuração e os campos relevantes que você pode usar ao dar lances em inventários de vídeo.

O Google aceita anúncios em vídeo in-stream, nativos e intersticiais representados como oportunidades de anúncio individuais ou conjuntos de anúncios em vídeo dinâmicos. Os conjuntos dinâmicos descrevem um agrupamento de anúncios em vídeo mostrados em sequência, em que uma duração máxima para o conjunto é dividida em um ou mais vídeos que variam em comprimento. Consulte os guias sobre os formatos de anúncio nativo e intersticial para mais detalhes.

Requisitos do comprador

Protocolo de RTB

Este guia geralmente se refere ao formato Protobuf, mas os nomes e caminhos de campo são equivalentes entre ele e o formato JSON, a menos que indicado de outra forma.

O proto do OpenRTB e as extensões do OpenRTB específicas do Google estão disponíveis na página Protos e dados de referência. Para mais informações sobre como desenvolver um bidder, consulte Processar a solicitação e Criar a resposta.

Revisão do criativo

O Google recomenda que você envie criativos para aprovação antes de dar lances com eles. Use o recurso Criativos da API Lances em tempo real para iniciar o processo de revisão.

Configuração de pré-segmentação

Para receber inventário de vídeo, sua conta do Authorized Buyers precisa criar uma configuração de pré-segmentação que inclua inventário de vídeo.

Macros

É possível especificar macros no link do URL do vídeo ou no XML VAST especificado em BidResponse.seatbid.bid.adm. Além disso, se você especificar um URL de vídeo, também poderá colocar macros no documento XML VAST vinculado. As macros a seguir são compatíveis com criativos de vídeo:

• %%CACHEBUSTER%%
• %%WINNING_PRICE%%
• %%SITE%%

Macros de clique como CLICK_URL_ESC não são compatíveis porque o Authorized Buyers inclui os rastreadores de cliques em um wrapper VAST. Para mais informações sobre as macros compatíveis, consulte Especificar macros.

Detalhes da frase de destaque

Use o campo BidRequest.imp.video do OpenRTB para identificar se uma solicitação de lance recebida é para inventário de vídeo in-stream ou intersticial e encontrar outras informações específicas de vídeo sobre a solicitação. Além disso, para inventário de anúncios nativos, use BidRequest.imp.native.{request/request_native}.assets.video para informações semelhantes específicas de vídeo.

BidRequest.{app/site}.content.producer.domain

O URL, sem parâmetros, da página que descreve o conteúdo do vídeo. O publisher envia esse URL ao Google. Exemplo:

http://www.publisher.com/watchpagelink

banner.vcm

Se definido como true, o anúncio complementar poderá ser escolhido para ser renderizado como um card final (card de informações) no espaço de vídeo após o término da reprodução do anúncio em vídeo. Caso contrário, o anúncio complementar não será renderizado como um end cap.

BidRequest.imp.rwdd

Se definido como true, indica que o usuário recebe uma recompensa por assistir o anúncio em vídeo. As recompensas típicas podem ser ler um artigo extra sem custo financeiro, receber uma vida extra em um jogo ou ter uma sessão de música patrocinada sem anúncios.

BidRequest.imp.video.maxduration

A duração máxima permitida em segundos para cada anúncio individual incluído na resposta à solicitação de lance. Quando não definida, não há duração máxima. Quando BidRequest.imp.video.skip é true, o comportamento pode ser diferente. Consulte Duração máxima de vídeos puláveis para mais detalhes.

BidRequest.imp.video.maxseq

O número máximo de anúncios que podem ser veiculados em um pod de anúncios em vídeo dinâmico. Se poddur estiver definido, mas maxseq não estiver definido ou for 0, não haverá restrição quanto ao número de anúncios que podem ser veiculados em um conjunto de vídeos. O Google só aceita pods dinâmicos.

O número real de anúncios em vídeo mostrados pode ser menor ou igual a esse valor, mas não pode excedê-lo.

BidRequest.imp.video.minduration

A duração mínima em segundos de cada anúncio individual incluído na resposta à solicitação de lance. Quando não definido, não há duração mínima.

BidRequest.imp.video.plcmt

Descreve onde o vídeo será reproduzido.

PLCMT_UNKNOWN	A posição é desconhecida ou não pode ser determinada.
PLCMT_INSTREAM	Anúncios precedentes, intermediários e finais que são reproduzidos antes, durante ou depois do conteúdo de streaming de vídeo que o consumidor solicitou. O vídeo in-stream precisa estar definido como "som ativado" por padrão no início do player ou ter uma intenção do usuário explicitamente clara de assistir o conteúdo em vídeo. Embora possa haver outro conteúdo ao redor do player, o conteúdo de vídeo precisa ser o foco da visita do usuário. Ele precisa continuar sendo o conteúdo principal da página e o único player de vídeo visível com áudio durante a reprodução. Se o player for convertido em flutuante/fixo, as chamadas de anúncio subsequentes precisarão transmitir com precisão o tamanho atualizado do player.
PLCMT_ACCOMPANYING_CONTENT	Anúncios precedentes, intermediários e finais que são reproduzidos antes, durante ou depois do conteúdo de streaming de vídeo. O player de vídeo é carregado e reproduzido antes, entre ou depois de parágrafos de texto ou conteúdo gráfico, e só começa a ser reproduzido quando entra na janela de visualização. O conteúdo complementar só deve começar a ser reproduzido ao entrar na janela de visualização. Ele pode se transformar em um player flutuante/fixo ao rolar para fora da página.
PLCMT_INTERSTITIAL	Anúncios em vídeo reproduzidos sem conteúdo de vídeo. Durante a reprodução, ele precisa ser o foco principal da página, ocupar a maior parte da janela de visualização e não pode ser rolado para fora da tela. Isso pode ser em posições como vídeos no app ou apresentações de slides.
PLCMT_NO_CONTENT_STANDALONE	Anúncios em vídeo reproduzidos sem conteúdo de streaming de vídeo. Isso pode ser em posições como apresentações de slides, feeds nativos, no conteúdo ou fixos/flutuantes.

BidRequest.imp.video.playbackmethod

Descreve como reproduzir o anúncio em vídeo. O método de reprodução é determinado como reprodução automática ou clique para assistir com base na melhor medição disponível.

AUTO_PLAY_SOUND_ON	Inicia no carregamento de página com o som ativado.
AUTO_PLAY_SOUND_OFF	Inicia no carregamento de página com o som desativado.
CLICK_TO_PLAY	Inicia ao clicar com o som ativado.
MOUSE_OVER	Inicia ao passar o mouse com o som ativado.
ENTER_SOUND_ON	Inicia ao entrar na janela de visualização com o som ativado.
ENTER_SOUND_OFF	Inicia ao entrar na janela de visualização com o som desativado por padrão.

BidRequest.imp.video.skip

Se for true, indica que o player vai permitir que o vídeo seja pulado ou que anúncios puláveis são permitidos. Caso contrário, indica que os anúncios puláveis não são permitidos.

BidRequest.imp.video.startdelay

O valor 0 significa anúncio precedente, -1 significa anúncio intermediário e -2 significa anúncio final.

Qualquer outro valor positivo é o tempo em segundos do início do vídeo até o ponto em que o anúncio é exibido.

BidRequest.imp.video.durfloors e BidRequest.imp.audio.durfloors

Uma matriz de objetos DurFloors que indica os respectivos preços mínimos para criativos de vídeo ou criativos em áudio de várias durações em que o comprador pode dar lances.

Veja um exemplo de como seria o durfloors especificado pelo Google:

1. {"maxdur": 16, "bidfloor": 5}, que representa (0, 16) segundos em $5.
2. {"mindur": 16, "maxdur": 31, "bidfloor": 10} que representa [16, 31) segundos em $10.
3. {"mindur": 31, "bidfloor": 20}, que representa [31, inf) segundos em $20.

Esses indicadores não são exclusivos dos criativos de vídeo, mas são particularmente valiosos para os bidders:

BidRequest.device.ifa

Este campo é um UUID de 36 caracteres que é definido apenas ao usar SSL e não é com hash. É a versão não criptografada de BidRequest.device.dpidm5. Para dispositivos iOS, ele contém o Identificador para anunciantes (IDFA) em caracteres maiúsculos. Para dispositivos Android, contém o identificador do Android (ADID) em caracteres minúsculos. Para dispositivos de smart TV, ele contém os identificadores exclusivos (por exemplo, o RIDA do Roku).

BidRequest.device.devicetype

Especifica o tipo de dispositivo.

MOBILE	Um alias obsoleto para HIGHEND_PHONE ou TABLET.
PERSONAL_COMPUTER	Inclui computadores e laptops.
CONNECTED_TV	inclui smart TVs e dispositivos conectados (como Roku, Apple TV etc.).
HIGHEND_PHONE	Inclui smartphones de alta qualidade.
TABLET	Inclui tablets.
CONNECTED_DEVICE	Inclui dispositivos de jogos dedicados.
SET_TOP_BOX	Inclui conversores.
OOH_DEVICE	Inclui dispositivos de publicidade out of home, como outdoors digitais.

BidRequest.device.make

Especifica a marca (como Nokia ou Samsung) do dispositivo.

BidRequest.device.model

Especifica o modelo exato (como N70 ou Galaxy) do dispositivo, se disponível. Caso contrário, contém um modelo genérico, como "iphone" ou "ipad".

BidRequest.imp.metric

Quando Metric.type é definido como completion_rate, Metric.value é uma fração no intervalo [0,0, 1,0] que representa a taxa de conclusão histórica dos anúncios em vídeo veiculados no espaço do anúncio. O valor padrão de -1.0 indica que os dados históricos da taxa de conclusão não estão disponíveis.

BidRequest.imp.video.poddur

O tempo em segundos que você pode preencher para um pod de anúncios em vídeo dinâmico. Esse campo se refere à duração de todo o intervalo de anúncio. Se não for definido, o espaço do anúncio não fará parte de um conjunto.

A solicitação de lance de vídeo também contém informações sobre o inventário, como o setor, os fornecedores permitidos e as informações do canal. Todos os outros campos na solicitação de lance também se aplicam ao vídeo.

Os campos de largura e altura na mensagem AdSlot de uma solicitação de vídeo correspondem ao tamanho do player de anúncios em vídeo.

BidRequest.imp.ext.allowed_vendor_type

Os fornecedores permitidos. Consulte o arquivo vendors.txt na documentação técnica para ver uma lista de IDs. Por exemplo, 309 = unidade de vídeo do DFA.

BidRequest.imp.video.mimes

Uma lista de permissões que descreve os tipos MIME de conteúdo aceitos para anúncios veiculados em resposta à solicitação de lance, por exemplo, "video/mp4". A resposta à solicitação de lance precisa indicar compatibilidade para pelo menos uma delas.

BidRequest.imp.video.protocols

Descreve as versões do VAST compatíveis com um editor para solicitações de anúncios em vídeo. Contém uma matriz de valores de tipo enumerado Protocol, incluindo: VAST_2_0, VAST_3_0, VAST_2_0_WRAPPER, VAST_3_0_WRAPPER, VAST_4_0, VAST_4_0_WRAPPER e muito mais.

BidRequest.imp.video.companionad

Esse campo inclui uma matriz de objetos Banner que representam anúncios complementares, se disponíveis.

BidRequest.site.page

O URL da página de exibição do vídeo ou o URL da página em que o vídeo foi incorporado. Exemplo:

http://www.publisher.com/watchpagelink

Ao responder a uma solicitação de vídeo, o bidder precisa retornar um URL de redirecionamento VAST ou um XML VAST no campo BidResponse.seatbid.bid.adm. A resposta à solicitação de lance também precisa conter a declaração adequada para o anúncio em vídeo. Veja a seguir um trecho de uma resposta à solicitação de lance de vídeo adequada:

id: "eW3q768m3k93fv93a80tGQ"
seatbid {
  bid {
    id: "0uMc95E6ClImM3p5FSe"
    impid: "1"
    price: 0.034745
    adm: "https://video.test.com/ads?id=123456&wprice=%%WINNING_PRICE%%"
    adomain: "google.com"
    crid: "test_creative_id_168019"
    cat: "7"
    w: 320
    h: 480
    cattax: GOOGLE_CATEGORIES
    [com.google.doubleclick.bid] {
      attribute: 47
      attribute: 50
      billing_id: 61170857882
      app_promotion_type: INSTALLS
      clickurl: "google.com"
    }
  }
}
[com.google.doubleclick.bid_response] {
  processing_time_ms: 30
}

Os campos importantes em uma resposta à solicitação de lance de vídeo são os seguintes:

BidResponse.seatbid.bid.ext.attribute

Atributos dos anúncios que podem ser mostrados nesse snippet. Consulte o arquivo buyer-declarable-creative-attributes.txt para ver a lista de IDs. Verificamos se nenhum desses atributos corresponde aos que não são permitidos pelo publisher na solicitação de lance. Por exemplo, se um dos campos incluir 30, isso indica que o anúncio precisa de suporte ao VPAID para ser renderizado.

BidResponse.seatbid.bid.adm

Para anúncios em vídeo, esse é o URL de redirecionamento VAST do anúncio em vídeo. Por exemplo:

http://ad.doubleclick.net/pfadx/N270.132652.1516607168321/B3442378.3;dcadv=1379578;sz=0x0;ord=79879;dcmt=text/xml

Como alternativa, pode ser um XML VAST bruto.

Exemplos de solicitações e respostas de lance

• Vídeos de amostra de solicitações de lance
• Exemplos de respostas a solicitações de lance de vídeo

Correção de anúncios puláveis

O Google aplica automaticamente a correção de anúncios puláveis aos lances em tempo real para inventário de vídeo, o que pode impedir que seus lances sejam filtrados do leilão devido a diferenças entre a capacidade de pular solicitada na solicitação de lance e a capacidade de pular dos criativos que você retorna na resposta à solicitação de lance. A correção de anúncios puláveis não é aplicada nos seguintes casos:

• O criativo especificado na resposta à solicitação de lance é implementado usando o VPAID. É possível determinar quais dos seus criativos de vídeo são implementados usando VPAID com o campo Creative.video.videoMetadata.isVpaid na API de lances em tempo real.
• O publisher vai renderizar o criativo. É possível determinar isso com base no campo BidRequest.imp.displaymanager, que será 'PUBLISHER' se o publisher for renderizar o criativo.

Veja a seguir exemplos que descrevem como a correção de anúncios puláveis é aplicada:

• Cenário 1:
• Você recebe uma solicitação de lance com o campo BidRequest.imp.video.skip definido como 0 para o formato JSON ou false para o formato Protobuf.
• Você dá um lance com um criativo pulável.
• Resultado: seu lance entra no leilão. Se o lance vencer e o criativo de vídeo for renderizado, ele será renderizado como não pulável.
• Cenário 2:
• Você recebe uma solicitação de lance com o campo BidRequest.imp.video.skip definido como 1 para o formato JSON ou true para o formato Protobuf.
• Você define um lance com um criativo não pulável com duração maior do que a especificada no campo BidRequest.imp.video.skipmin.
• Resultado: seu lance entra no leilão. Se o lance vencer e o criativo de vídeo for renderizado, ele será renderizado como pulável.

Formatos de vídeo

• Como os compradores podem incluir vídeos
• Indicadores recomendados do OpenRTB para todos os formatos de vídeo
• Indicadores recomendados do proto do Authorized Buyers para todos os formatos de vídeo
• Como os publishers podem permitir/proibir vídeos
• Casos extremos

Como os compradores podem incluir vídeos

As tabelas a seguir ilustram como os compradores podem incluir vídeos nos criativos e nas posições em que podem ser veiculados para Web e apps para dispositivos móveis, respectivamente.

Web

App para dispositivos móveis

Indicadores recomendados do OpenRTB

As tabelas a seguir mostram os indicadores recomendados do OpenRTB para todos os formatos de vídeo em computadores e na Web para dispositivos móveis e em apps para dispositivos móveis.

Web para computadores e dispositivos móveis

App para dispositivos móveis

Como os publishers podem permitir/proibir vídeos

A tabela a seguir mostra como os editores podem permitir/proibir vídeos nas posições.

Casos extremos

Glossário

Consulte o glossário de vídeo do Authorized Buyers.

Campos relevantes para formatos in-stream e não in-stream

Consulte o OpenRTB 2.5 (a partir da página 47).

Origem do valor da solicitação de lance