Annunci video

Questa guida illustra i requisiti di integrazione, la configurazione e i campi pertinenti che puoi utilizzare quando fai offerte per l'inventario video.

Google supporta annunci video in-stream, nativi e interstitial rappresentati come singole opportunità pubblicitarie o pod di annunci video dinamici. I pod dinamici descrivono un raggruppamento di annunci video mostrati in sequenza, in cui una durata massima del pod è suddivisa in uno o più video di durata variabile. Per maggiori dettagli sui formati degli annunci nativi e interstitial, consulta le guide corrispondenti.

Requisiti per gli acquirenti

Protocollo RTB

Questa guida farà generalmente riferimento al formato Protobuf, ma i nomi e i percorsi dei campi sono equivalenti tra questo e il formato JSON, se non diversamente specificato.

Puoi trovare il proto OpenRTB e le estensioni OpenRTB specifiche di Google nella pagina Proto e dati di riferimento. Per maggiori informazioni sullo sviluppo di un offerente, consulta Elabora la richiesta e Crea la risposta.

Verifica delle creatività

Google consiglia di inviare le creatività per l'approvazione prima di utilizzarle per fare offerte. Puoi utilizzare la risorsa Creatives dell'API Offerte in tempo reale per avviare la procedura di revisione.

Configurazione di pretargeting

Per ricevere l'inventario video, il tuo account Authorized Buyers deve creare una configurazione di pretargeting che includa l'inventario video.

Macro

Puoi specificare le macro nel link dell'URL del video o nel codice XML VAST specificato in BidResponse.seatbid.bid.adm. Inoltre, se specifichi un URL video, puoi anche inserire macro nel documento XML VAST collegato. Per le creatività video sono supportate le seguenti macro:

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

Le macro clic come CLICK_URL_ESC non sono supportate perché Authorized Buyers include i propri tracker dei clic in un wrapper VAST. Per saperne di più sulle macro supportate, consulta Specifica le macro.

Dettagli del callout

Puoi utilizzare il campo BidRequest.imp.video di OpenRTB per identificare se una richiesta di offerta in entrata riguarda l'inventario video in-stream o interstitial e trovare ulteriori informazioni specifiche per i video sulla richiesta. Inoltre, per l'inventario di annunci nativi, puoi utilizzare BidRequest.imp.native.{request/request_native}.assets.video per informazioni simili specifiche per i video.

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

L'URL, senza parametri, della pagina che descrive i contenuti video. L'editore invia questo URL a Google. Ad esempio:

http://www.publisher.com/watchpagelink

banner.vcm

Se impostato su true, l'annuncio companion può essere scelto per il rendering come end-cap (scheda informativa) nell'area video al termine della riproduzione dell'annuncio video. In caso contrario, l'annuncio companion non viene visualizzato come codino.

BidRequest.imp.rwdd

Se impostato su true, indica che l'utente riceve un premio per la visualizzazione dell'annuncio video. I premi tipici potrebbero essere la lettura di un articolo aggiuntivo senza costi, la ricezione di una vita extra in un gioco o una sessione di musica sponsorizzata senza annunci.

BidRequest.imp.video.maxduration

La durata massima consentita in secondi per ogni singolo annuncio incluso nella risposta all'offerta. Se non viene impostata, non esiste una durata massima. Quando BidRequest.imp.video.skip è true, il comportamento può essere diverso. Per maggiori dettagli, consulta Durata massima video ignorabili.

BidRequest.imp.video.maxseq

Il numero massimo di annunci che potrebbero essere pubblicati in un pod di annunci video dinamico. Se poddur è impostato, ma maxseq non è impostato o è 0, non hai una limitazione sul numero di annunci che possono essere pubblicati in un pod video. Google supporta solo i pod dinamici.

Il numero effettivo di annunci video mostrati può essere inferiore o uguale a questo valore, ma non può superarlo.

BidRequest.imp.video.minduration

La durata minima in secondi di ogni singolo annuncio incluso nella risposta all'offerta. Se non viene impostata, non esiste una durata minima.

BidRequest.imp.video.plcmt

Indica dove verrà riprodotto il video.

PLCMT_UNKNOWN	Il posizionamento è sconosciuto o non determinabile.
PLCMT_INSTREAM	Annunci pre-roll, mid-roll e post-roll riprodotti prima, durante o dopo i contenuti video in streaming richiesti dal consumatore. Il video in-stream deve essere impostato su "audio attivo" per impostazione predefinita all'avvio del player o avere un user intent esplicitamente chiaro di guardare i contenuti video. Anche se il player potrebbe essere circondato da altri contenuti, i contenuti video devono essere l'oggetto della visita dell'utente. Deve rimanere il contenuto principale della pagina e l'unico video player visibile in grado di riprodurre l'audio durante la riproduzione. Se il player viene convertito in mobile/permanente, le chiamate dell'annuncio successive devono indicare con precisione le dimensioni aggiornate del player.
PLCMT_ACCOMPANYING_CONTENT	Annunci pre-roll, mid-roll e post-roll riprodotti prima, durante o dopo lo streaming di contenuti video. Il video player viene caricato e riprodotto prima, tra o dopo i paragrafi di testo o i contenuti grafici e inizia la riproduzione solo quando entra nell'area visibile. La riproduzione dei contenuti aggiuntivi deve iniziare solo quando entrano nell'area visibile. Può essere convertito in un player mobile/sticky quando scorre fuori dalla pagina.
PLCMT_INTERSTITIAL	Annunci video riprodotti senza contenuti video. Durante la riproduzione, deve essere l'elemento principale della pagina, occupare la maggior parte dell'area visibile e non può essere rimosso dalla visualizzazione tramite scorrimento. Questo può avvenire in posizionamenti come video in-app o presentazioni.
PLCMT_NO_CONTENT_STANDALONE	Annunci video riprodotti senza contenuti video in streaming. Ciò può avvenire in posizionamenti come presentazioni, feed nativi, contenuti o annunci fissi/mobili.

BidRequest.imp.video.playbackmethod

Descrive come riprodurre l'annuncio video. Il metodo di riproduzione viene determinato come riproduzione automatica o click-to-play in base alla migliore misurazione disponibile.

AUTO_PLAY_SOUND_ON	Si avvia al caricamento della pagina con l'audio attivo.
AUTO_PLAY_SOUND_OFF	Si avvia al caricamento pagina con l'audio disattivato.
CLICK_TO_PLAY	Si avvia al clic con l'audio attivo.
MOUSE_OVER	Si avvia al passaggio del mouse con l'audio attivo.
ENTER_SOUND_ON	Si avvia quando entra nell'area visibile con l'audio attivo.
ENTER_SOUND_OFF	Si avvia quando entra nell'area visibile con l'audio disattivato per impostazione predefinita.

BidRequest.imp.video.skip

Se true, indica che il player consentirà di saltare il video o che sono consentiti annunci ignorabili. In caso contrario, indica che gli annunci ignorabili non sono consentiti.

BidRequest.imp.video.startdelay

Un valore pari a 0 indica pre-roll, -1 indica mid-roll e -2 indica post-roll.

Qualsiasi altro valore positivo indica il tempo in secondi dall'inizio del video al punto in cui viene visualizzato l'annuncio.

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

Un array di oggetti DurFloors che indicano i rispettivi prezzi minimi per le creatività video o audio di varie durate con cui l'acquirente può fare offerte.

Di seguito è riportato un esempio di durfloors specificato da Google:

1. {"maxdur": 16, "bidfloor": 5} che rappresenta (0, 16) secondi a $5.
2. {"mindur": 16, "maxdur": 31, "bidfloor": 10} che rappresenta [16, 31) secondi a $10.
3. {"mindur": 31, "bidfloor": 20} che rappresenta [31, inf) secondi a $20.

Questi indicatori non sono esclusivi delle creatività video, ma sono particolarmente utili per gli offerenti:

BidRequest.device.ifa

Questo campo è un UUID di 36 caratteri che viene impostato solo quando si utilizza SSL e non viene sottoposto ad hashing. È la versione non criptata di BidRequest.device.dpidm5. Per i dispositivi iOS, contiene l'IDFA (Identifier for Advertisers) con tutti i caratteri in maiuscolo. Per i dispositivi Android, contiene l'identificatore Android (ADID) in caratteri minuscoli. Per i dispositivi TV connessi a internet, contiene i relativi identificatori univoci (ad esempio, RIDA di Roku).

BidRequest.device.devicetype

Specifica il tipo di dispositivo.

MOBILE	Un alias obsoleto per HIGHEND_PHONE o TABLET.
PERSONAL_COMPUTER	Include computer desktop e laptop.
CONNECTED_TV	include sia le TV connesse a internet (ovvero le smart TV) sia i dispositivi connessi (come Roku, Apple TV e così via).
HIGHEND_PHONE	Include smartphone di fascia alta.
TABLET	Sono inclusi i tablet.
CONNECTED_DEVICE	Include dispositivi di gioco dedicati.
SET_TOP_BOX	Include i set-top box.
OOH_DEVICE	Include dispositivi pubblicitari out of home, ad esempio cartelloni digitali.

BidRequest.device.make

Specifica il brand (ad esempio Nokia o Samsung) del dispositivo.

BidRequest.device.model

Specifica il modello esatto (ad esempio N70 o Galaxy) del dispositivo, se disponibile, altrimenti contiene un modello generico come "iphone" o "ipad".

BidRequest.imp.metric

Quando Metric.type è impostato su completion_rate, Metric.value sarà una frazione compresa nell'intervallo [0.0, 1.0] che rappresenta la percentuale di completamento storica degli annunci video pubblicati nell'area annuncio. Il valore predefinito -1.0 indica che i dati storici sulla percentuale di completamento non sono disponibili.

BidRequest.imp.video.poddur

La durata in secondi che puoi riempire per un pod di annunci video dinamico. Questo campo si riferisce alla durata dell'intera interruzione pubblicitaria. Se non è impostata, l'area annunci non fa parte di un pod.

La richiesta di offerta video contiene anche informazioni sull'inventario, come la verticale, i fornitori consentiti e le informazioni sul canale. Tutti gli altri campi esistenti nella richiesta di offerta si applicano anche ai video.

I campi relativi alla larghezza e all'altezza nel messaggio AdSlot di una richiesta video corrispondono alle dimensioni del video player.

BidRequest.imp.ext.allowed_vendor_type

I fornitori consentiti. Per un elenco degli ID, consulta il file vendors.txt nella documentazione tecnica. Ad esempio, 309 = unità video DFA.

BidRequest.imp.video.mimes

Una lista consentita che descrive i tipi MIME dei contenuti supportati per gli annunci pubblicati in risposta alla richiesta di offerta, ad esempio "video/mp4". La risposta all'offerta deve indicare il supporto per almeno uno di questi formati.

BidRequest.imp.video.protocols

Descrive le versioni VAST supportate da un publisher per le richieste di annunci video. Contiene un array di valori enum Protocol, tra cui: VAST_2_0, VAST_3_0, VAST_2_0_WRAPPER, VAST_3_0_WRAPPER, VAST_4_0, VAST_4_0_WRAPPER e altri ancora.

BidRequest.imp.video.companionad

Questo campo include un array di oggetti Banner che rappresentano gli annunci companion, se disponibili.

BidRequest.site.page

L'URL della pagina di visualizzazione del video o l'URL della pagina in cui è stato incorporato il video. Ad esempio:

http://www.publisher.com/watchpagelink

Quando risponde a una richiesta di video, l'offerente deve restituire un URL di reindirizzamento VAST o un XML VAST nel campo BidResponse.seatbid.bid.adm. La risposta all'offerta deve contenere anche la dichiarazione corretta per l'annuncio video. Di seguito è riportato un estratto di una risposta all'offerta video corretta:

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
}

I campi importanti in una risposta all'offerta video sono i seguenti:

BidResponse.seatbid.bid.ext.attribute

Attributi degli annunci che potrebbero essere mostrati da questo snippet. Consulta il file buyer-declarable-creative-attributes.txt per l'elenco degli ID. Verifichiamo che nessuno di questi attributi corrisponda a quelli non consentiti dal publisher nella richiesta di offerta. Ad esempio, se uno dei campi include 30, significa che l'annuncio richiede il supporto di VPAID per il rendering.

BidResponse.seatbid.bid.adm

Per gli annunci video, si tratta dell'URL di reindirizzamento VAST dell'annuncio video. Ad esempio:

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

In alternativa, potrebbe trattarsi di XML VAST non elaborato.

Esempi di richieste di offerta e risposte

• Esempi di richieste di offerta video
• Risposte all'offerta video di esempio

Correzione ignorabile

Google applica automaticamente la correzione ignorabile alle offerte di offerte in tempo reale per l'inventario video, il che può impedire che le tue offerte vengano filtrate dall'asta a causa di differenze tra la possibilità di ignorare un video richiesta nella richiesta di offerta e la possibilità di ignorare un video delle creatività che restituisci nella risposta all'offerta. La correzione ignorabile non viene applicata nei seguenti casi:

• La creatività specificata nella risposta all'offerta viene implementata utilizzando VPAID. Puoi determinare quali delle tue creatività video vengono implementate utilizzando VPAID con il campo Creative.video.videoMetadata.isVpaid nell'API Offerte in tempo reale.
• Il publisher eseguirà il rendering della creatività. Puoi determinarlo in base al campo BidRequest.imp.displaymanager, che è 'PUBLISHER' se il publisher eseguirà il rendering della creatività.

Di seguito sono riportati alcuni esempi che descrivono come viene applicata la correzione ignorabile:

• Scenario 1:
• Ricevi una richiesta di offerta con il campo BidRequest.imp.video.skip impostato su 0 per il formato JSON o false per il formato Protobuf.
• Fai un'offerta con una creatività ignorabile.
• Risultato: la tua offerta partecipa all'asta. Se la tua offerta vince e viene eseguito il rendering della creatività video, questa viene visualizzata come non ignorabile.
• Scenario 2:
• Ricevi una richiesta di offerta con il campo BidRequest.imp.video.skip impostato su 1 per il formato JSON o true per il formato Protobuf.
• Fai un'offerta con una creatività non ignorabile con una durata superiore a quella specificata nel campo BidRequest.imp.video.skipmin.
• Risultato: la tua offerta partecipa all'asta. Se la tua offerta vince e la creatività video viene visualizzata, viene visualizzata come ignorabile.

Formati video

• Come gli acquirenti possono includere i video
• Indicatori OpenRTB consigliati per tutti i formati video
• Indicatori consigliati per il protocollo Authorized Buyers per tutti i formati video
• In che modo i publisher possono consentire/non consentire i video
• Casi limite

In che modo gli acquirenti possono includere i video

Le tabelle seguenti illustrano i modi in cui gli acquirenti possono includere video nelle loro creatività e i posizionamenti in cui possono essere pubblicati rispettivamente per il web e l'app mobile.

Web

App mobile

Indicatori consigliati per OpenRTB

Le seguenti tabelle illustrano gli indicatori consigliati da OpenRTB per tutti i formati video per web mobile e desktop e app mobile.

Desktop e Web mobile

App mobile

In che modo i publisher possono consentire/non consentire i video

La tabella seguente illustra i modi in cui i publisher possono consentire/non consentire i video nei loro posizionamenti.

Casi limite

Glossario

Consulta il glossario dei video di Authorized Buyers.

Campi pertinenti per i formati in-stream e non in-stream

Consulta OpenRTB 2.5 (a partire da pagina 47)

Origine del valore della richiesta di offerta