Anúncios em vídeo

Este guia descreve os requisitos de integração, a configuração e os campos relevantes que podem ser usados ao fazer lances no inventário de vídeo.

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

Requisitos do comprador

Protocolo RTB

Este guia geralmente se refere ao formato Protobuf, mas os nomes e caminhos dos campos são equivalentes entre ele e o formato JSON, a menos que seja indicado o contrário.

Você encontra o proto do OpenRTB e as extensões específicas do Google 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 os criativos para aprovação antes de fazer lances com eles. Você pode usar o recurso de criativos da API Real-time Bidding 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

Você pode 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 seguintes macros 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 rastreadores de cliques em um wrapper VAST. Para mais informações sobre macros compatíveis, consulte Especificar macros.

Detalhes da frase de destaque

É possível usar 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 mais informações específicas sobre o vídeo na solicitação. Além disso, para inventário de anúncios nativos, você pode usar 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, com parâmetros removidos, 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 renderização como um encerramento (card de informações) no espaço do vídeo após a conclusão da reprodução do anúncio em vídeo. Caso contrário, o anúncio complementar não será renderizado como uma imagem final.
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 sem anúncios patrocinada.
BidRequest.imp.video.maxduration

A duração máxima permitida em segundos para cada anúncio incluído na resposta do lance. Quando não definido, não há uma duração máxima. Quando BidRequest.imp.video.skip é true, o comportamento pode ser diferente. Consulte Duração máxima dos 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 conjunto 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 para cada anúncio individual incluído na resposta do 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 indeterminada.
PLCMT_INSTREAM Anúncios precedentes, intermediários e finais que são veiculados antes, durante ou depois do conteúdo de vídeo por streaming solicitado pelo consumidor. O vídeo in-stream precisa estar definido como "som ativado" por padrão no início do player ou ter uma intenção clara do usuário de assistir o conteúdo de vídeo. Embora possa haver outros conteúdos 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 capaz de reproduzir áudio. 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 veiculados antes, durante ou depois do conteúdo de vídeo em streaming. O player de vídeo carrega e é reproduzido antes, entre ou depois de parágrafos de texto ou conteúdo gráfico, e começa a ser reproduzido somente quando entra na janela de visualização. O conteúdo complementar só pode começar a ser reproduzido quando entra na janela de visualização. Ele pode ser convertido em um player flutuante/fixo à medida que rola para fora da página.
PLCMT_INTERSTITIAL Anúncios em vídeo que são veiculados sem conteúdo de vídeo. Durante a reprodução, ele precisa ser o foco principal da página e ocupar a maior parte da janela de visualização, sem poder ser rolado para fora da tela. Isso pode ser em canais como vídeo no app ou apresentações de slides.
PLCMT_NO_CONTENT_STANDALONE Anúncios em vídeo reproduzidos sem conteúdo de streaming. Isso pode acontecer 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 ver com base na melhor medição disponível.
AUTO_PLAY_SOUND_ON Inicia no carregamento da página com o som ativado.
AUTO_PLAY_SOUND_OFF Inicia no carregamento da página com o som desligado.
CLICK_TO_PLAY Inicia com um clique e som ativado.
MOUSE_OVER Inicia ao passar o cursor do 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 true, isso indica que o player vai permitir que o vídeo seja pulado ou que anúncios puláveis são permitidos. Caso contrário, isso indica que os anúncios puláveis não são permitidos.
BidRequest.imp.video.startdelay

Um valor de 0 significa precedente, -1 significa intermediário e -2 significa final.

Qualquer outro valor positivo é o tempo em segundos desde o 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 indicam os preços mínimos respectivos para criativos de vídeo ou áudio de várias durações com que o comprador pode fazer lances.

Confira um exemplo de como seria um durfloors especificado pelo Google:

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

Esses indicadores não são exclusivos dos criativos em vídeo, mas são especialmente valiosos para os compradores de mídia:

BidRequest.device.ifa
Este campo é um UUID de 36 caracteres definido apenas ao usar SSL e não é hash. É a versão não criptografada de BidRequest.device.dpidm5. Para dispositivos iOS, ele contém o identificador para anunciantes (IDFA) em letras maiúsculas. Para dispositivos Android, ele contém o identificador do Android (ADID) em letras minúsculas. Para dispositivos de TV conectada, 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 TVs conectadas (ou seja, smart TVs) e dispositivos conectados (como Roku, Apple TV etc.).
HIGHEND_PHONE Inclui smartphones sofisticados.
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 de 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 de taxa de conclusão não estão disponíveis.
BidRequest.imp.video.poddur
É o tempo em segundos que você pode preencher para um conjunto de anúncios em vídeo dinâmico. Esse campo se refere à duração de todo o intervalo. Se não estiver definido, o espaço de 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 a categoria, os fornecedores permitidos e os dados do canal. Todos os outros campos existentes na solicitação de lance também se aplicam a vídeo.

Os campos "largura" e "altura" na mensagem "AdSlot" de uma solicitação de vídeo correspondem ao tamanho do player de anúncio 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 compatíveis com anúncios veiculados em resposta à solicitação de lance. Por exemplo, "video/mp4". A resposta de lance precisa indicar compatibilidade para pelo menos uma delas.
BidRequest.imp.video.protocols
Descreve as versões VAST compatíveis de um editor para solicitações de anúncios em vídeo. Contém uma matriz de valores de enumeração 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 da página em que ele 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 XML VAST no campo BidResponse.seatbid.bid.adm. A resposta de lance também precisa conter a declaração adequada para o anúncio em vídeo. Confira a seguir um trecho de uma resposta de bid de vídeo adequada: 

id: "n40G42d551UX18627ao8lt"
seatbid {
  bid {
    id: "17u6BnD62h88r5q7066"
    impid: "1"
    price: 0.797848
    adm: "https://video.test.com/ads?id=123456&wprice=%%WINNING_PRICE%%"
    adomain: "google.com"
    crid: "test_creative_id_987914"
    w: 320
    h: 480
    cattax: GOOGLE_CATEGORIES
    [com.google.doubleclick.bid] {
      attribute: 47
      attribute: 50
      billing_id: 55383762512
      skadn {
        version: "4.0"
        network: "306el65O"
        itunesitem: "832461214"
        sourceapp: "977150768"
        fidelities {
          fidelity: VIEW_THROUGH_ADS
          nonce: "0054e0b9-0b53-4426-99dd-a1eefeb45565"
          timestamp: "1757329316673"
          signature: "oE3Ek8347oZV1Yl1J42G2c88BSKr2dqEbiOK2S4ni7NVDh3v128NN0hlzWK5aX96ecV1504E9k288i0t0wGX73P317812WE7"
        }
        fidelities {
          fidelity: STOREKIT_RENDERED_ADS
          nonce: "0054e0b9-0b53-4426-99dd-a1eefeb45565"
          timestamp: "1757329316673"
          signature: "b1GqXA4v889p842512GQ1p3249q5VmPt1335f1H1zdK92fq24j7a7ml419W7u8B7rhhH97s507f2251923oWi89XF1voZv4b"
        }
        sourceidentifier: "8396"
      }
      app_promotion_type: INSTALLS
      clickurl: "google.com"
    }
  }
}
[com.google.doubleclick.bid_response] {
  processing_time_ms: 20
}

Os campos importantes em uma resposta de solicitação de lances 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 conferir a lista de IDs. Verificamos se nenhum desses atributos corresponde aos que foram proibidos pelo editor na solicitação de lance. Por exemplo, se um dos campos incluir 30, isso vai indicar que o anúncio precisa de suporte a VPAID para ser renderizado.
BidResponse.seatbid.bid.adm

Para anúncios em vídeo, é o URL de redirecionamento VAST do anúncio. 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 XML VAST bruto.

Exemplos de solicitações e respostas de lances

Formatos de vídeo

Como os compradores podem incluir vídeo

As tabelas a seguir ilustram maneiras de os compradores incluírem vídeo nos criativos e posições em que eles podem ser veiculados na Web e em apps para dispositivos móveis, respectivamente.

Web

Criativo de vídeo In-stream (todos) In-feed/artigo Nativo no feed/artigo Intersticial No banner

VPAID + VAST

 

VAST

 

MRAID + JS

 

 

 

 

 

JavaScript personalizado

 

Nativo + VAST

 

App para dispositivos móveis

Criativo de vídeo In-stream (todos) In-feed/artigo Nativo no feed/artigo Intersticial No banner

VPAID + VAST

 

 

 

 

 

VAST

MRAID + JS

JavaScript personalizado

Nativo + VAST

Chave: Formato/tecnologia não disponível

Criativo de vídeo aceito nesta posição, sujeito a bloqueios do editor

Criativo de vídeo não disponível nesta posição

Indicadores recomendados do OpenRTB

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

Web para computadores e dispositivos móveis

Formato de vídeo Parâmetros recomendados (apenas parâmetros relevantes para o vídeo) Indicadores relacionados (somente indicadores relevantes para vídeo)

In-stream (VPAID)

Objeto VIDEO presente   &
video.placement = INSTREAM   &

In-stream (sem VPAID)

Objeto VIDEO presente   &
video.placement = INSTREAM    &
video.api = 1 VPAID 1.0 or 2:VPAID 2.0

Não in-stream

Objeto VIDEO presente

A posição video.linearity: linear
depende da posição
real, com os valores abaixo
Video.startdelay = 0

In-feed

Objeto VIDEO presente   &
video.placement = IN-FEED

In-article

Objeto VIDEO presente   &
video.placement = IN-ARTICLE

Nativo

Objeto NATIVE presente e

No banner

Objeto de vídeo não presente &
banner.battr ≠ 6 Vídeo em banner (reprodução automática) &
banner.battr ≠ 7 Vídeo em banner (iniciado pelo usuário)

App para dispositivos móveis

Formato de vídeo Detalhes da solicitação de lance (somente os detalhes relevantes do vídeo)

In-stream

Objeto VIDEO presente   &
video.placement = INSTREAM    &

video.api = 1 VPAID 1.0 ou 2: VPAID 2.0

Não in-stream

Objeto VIDEO presente

A posição video.linearity: linear
depende da posição
real, com os valores abaixo
Video.startdelay = 0

In-feed

Objeto VIDEO presente   &
video.placement = IN-FEED

In-article

Objeto VIDEO presente   &
video.placement = IN-ARTICLE

Nativo

Objeto NATIVE presente e

Intersticial (VAST)

Objeto VIDEO presente   &
video.placement = INTERSTITIAL

Intersticial (sem VAST)

Objeto VIDEO presente   &
video.placement = INTERSTITIAL

Filtrado

No banner (MRAID)

Objeto de vídeo não presente &
banner.battr ≠ 6 Vídeo em banner (reprodução automática) &
banner.battr ≠ 7 Vídeo em banner (iniciado pelo usuário)

No banner

(sem MRAID)

Objeto de vídeo não presente &
banner.battr ≠ 6 Vídeo em banner (reprodução automática) &
banner.battr ≠ 7 Vídeo em banner (iniciado pelo usuário)

Como os publishers podem permitir/proibir vídeos

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

Opção de publicação Formatos aplicáveis Descrito na solicitação de lance como

Especificar um vídeo in-stream e uma unidade

In-stream (todos)

Objeto de vídeo presente e
video.placement = INSTREAM

Ativar o VPAID

In-stream na Web

Objeto de vídeo presente e
video.api = 1 (VPAID 1.0) ou 2 (VPAID 2.0)

Ativar a IBV

No banner

Intersticial

banner.battr ≠ 6 Vídeo em banner (reprodução automática) e/ou 7 Vídeo em banner (iniciado pelo usuário)

Ative (instruções)

In-feed

In-article

Objeto de vídeo presente e
video.placement = IN-FEED ou IN-ARTICLE

Ativar os anúncios não in-stream (instruções)

Nativo

Objeto nativo presente

Bloquear intersticial em vídeo

App intersticial

Objeto VIDEO ausente

Casos extremos

# Descrição do caso Comentários Solicitação de lance

1

Fechamento personalizado atrasado usando MRAID

Para intersticiais, fechar o anúncio pode enviar uma notificação ao comprador usando MRAID, mesmo que ele não tenha usado o fechamento personalizado.


O "X" aplicado pelo Authorized Buyers sempre vai aparecer acima de qualquer fechamento personalizado, mesmo que o fechamento personalizado apareça abaixo após 5 segundos.

Glossário

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

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

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

BidRequest.Video.
Placement
In-stream mWeb

1: in-stream
2: in-banner

mApp

1: in-stream
2: in-banner
Não in-stream mApp Interstitial

5: intersticial

Native

3: In-Article
4: In-Feed

Rewarded

rwdd: bool
linearity

Indica se a impressão precisa ser linear, não linear etc. Se nenhuma for especificada, considere que todas são permitidas.

In-stream mWeb

1: LINEAR (in-stream)

mApp

1: LINEAR (in-stream)
Não in-stream mApp Interstitial

2: INTERSTITIAL

Native

3: IN_FEED
5: IN_ARTICLE
videoad_start_delay
In-stream mWeb

>0: start delay in seconds
 0: PRE_ROLL
-1: GENERIC_MID_ROLL
-2: GENERIC_POST_ROLL

mApp

>0: start delay in seconds
 0: PRE_ROLL
-1: GENERIC_MID_ROLL
-2: GENERIC_POST_ROLL
Não in-stream Rewarded

>0: start delay in seconds
 0: PRE_ROLL
-1: GENERIC_MID_ROLL
-2: GENERIC_POST_ROLL

Origem do valor da solicitação de lance

Objeto
do OpenRTB		 Campos Authorized Buyers
/Exchange
Bidding
Non-instream		 Amostras de valores Quem determina isso?
/De onde vem esse valor?
Objeto
Vídeo mimes sim ["application/javascript",
"video/mp4"]",		 Google
minduration não Configurado pelo publisher
maxduration sim Configurado pelo publisher
playbackmet
hod		 sim [6] Geralmente, o Publisher
Configurado
api (MRAID) sim [1,2] Google
protocolos sim [2,3,5,6,7,8] Google
linearidade sim [1] Google
posição sim [1] Google
largura do player sim 400.400.300 Google
altura do jogador sim 225.300.153 Google
atraso do início sim 0 Google, padrão de 5 segundos
pular sim 1 Editor/Google
- para intersticial => Google
- para instream => Editor
decide se permite
puláveis, não puláveis ou ambos.
Anúncios premiados, sempre não puláveis;
taxa de bits mínima Não Google
taxa de bits máxima não Google
pos sim 1 Google
Dispositivo
Proporção de px sim 1 Google
impressão
Seguro sim 1 O Google
define o padrão como "true"
porque a tag de anúncio é sempre
segura