Videoanzeigen

In diesem Leitfaden werden die Integrationsanforderungen, die Konfiguration und die relevanten OpenRTB-Protokollfelder beschrieben, die Sie beim Abgeben von Geboten für Videoinventar verwenden können. Das Google RTB-Protokoll wird eingestellt und wird in diesem Leitfaden nicht näher behandelt. Informationen zu Videoanzeigen im Google RTB-Protokoll finden Sie im Leitfaden zu Videoanzeigen im Google RTB-Protokoll.

Google unterstützt In-Stream-, native und Interstitial-Videoanzeigen. Weitere Informationen zu diesen Formaten finden Sie in den Leitfäden zu nativen und Interstitial-Anzeigen.

Anforderungen an Käufer

RTB-Protokoll

In diesem Leitfaden wird in der Regel auf das Protobuf-Format verwiesen. Feldnamen und Pfade sind jedoch, sofern nicht anders angegeben, mit denen im JSON-Format identisch.

Das OpenRTB-Proto und die OpenRTB-Erweiterungen von Google finden Sie auf der Seite Protos und Referenzdaten. Weitere Informationen zum Entwickeln eines Bieters finden Sie unter Anfrage verarbeiten und Antwort erstellen.

Creative-Überprüfung

Wir empfehlen Ihnen, Creatives zur Genehmigung einzureichen, bevor Sie mit ihnen Gebote abgeben. Sie können die Creatives-Ressource der Real-Time Bidding API verwenden, um den Überprüfungsprozess zu starten.

Pre-Targeting-Konfiguration

Damit Sie Videoinventar erhalten, müssen Sie in Ihrem Authorized Buyers-Konto eine Pre-Targeting-Konfiguration mit Videoinventar erstellen.

Makros

Sie können Makros entweder in der Video-URL oder in der VAST-XML-Datei angeben, die in BidResponse.seatbid.bid.adm angegeben ist. Wenn Sie eine Video-URL angeben, können Sie auch Makros in das verknüpfte VAST-XML-Dokument einfügen. Für Video-Creatives werden die folgenden Makros unterstützt:

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

Klick-Makros wie CLICK_URL_ESC werden nicht unterstützt, da Authorized Buyers seine Klick-Tracker in einem VAST-Wrapper einfügt. Weitere Informationen zu unterstützten Makros finden Sie unter Makros angeben.

Zusatzinformationen

Mit dem OpenRTB-Feld BidRequest.imp.video können Sie feststellen, ob eine eingehende Gebotsanfrage sich auf In-Stream- oder Interstitial-Videoinventar bezieht, und weitere videospezifische Informationen zur Anfrage abrufen. Für natives Anzeigeninventar können Sie außerdem BidRequest.imp.native.{request/request_native}.assets.video für ähnliche videospezifische Informationen verwenden.

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

Die URL der Seite, auf der die Videoinhalte beschrieben werden, ohne Parameter. Der Verlag oder Webpublisher sendet diese URL an Google. Beispiel:

http://www.publisher.com/watchpagelink
banner.vcm
Wenn diese Option auf true festgelegt ist, kann die Companion-Anzeige so konfiguriert werden, dass sie nach der Wiedergabe der Videoanzeige als Endcap (Infokarte) im Video-Slot gerendert wird. Andernfalls wird die Companion-Anzeige nicht als Endcap gerendert.
BidRequest.imp.rwdd
Wenn „true“ festgelegt ist, erhält der Nutzer eine Prämie für das Ansehen der Videoanzeige. Typische Prämien sind beispielsweise das kostenlose Lesen eines zusätzlichen Artikels, ein zusätzliches Leben in einem Spiel oder eine gesponserte Musiksitzung ohne Werbeunterbrechungen.
BidRequest.imp.video.maxduration

Die maximal zulässige Dauer der Anzeige in Sekunden, die Sie zurückgeben sollten. Wenn dieser Parameter nicht festgelegt ist, gibt es keine maximale Dauer. Wenn BidRequest.imp.video.skip = true ist, kann sich das Verhalten unterscheiden. Weitere Informationen finden Sie unter Maximale Dauer des überspringbaren Videos.

BidRequest.imp.video.maxseq

Die maximale Anzahl von Anzeigen im Video-Pod. Wenn dieser Parameter nicht festgelegt ist, ist der Anzeigenblock nicht Teil eines Video-Pods.

Die tatsächliche Anzahl der ausgelieferten Videoanzeigen kann kleiner oder gleich diesem Wert sein, darf ihn aber nicht überschreiten.

BidRequest.imp.video.minduration
Die Mindestdauer in Sekunden der Anzeige, die Sie zurückgeben sollten. Wenn dieser Wert nicht festgelegt ist, gibt es keine Mindestdauer.
BidRequest.imp.video.plcmt
Hier wird angegeben, wo das Video wiedergegeben wird.
PLCMT_UNKNOWN Placement ist unbekannt oder nicht bestimmbar.
PLCMT_INSTREAM Pre-Roll-, Mid-Roll- und Post-Roll-Anzeigen, die vor, während oder nach dem angeforderten gestreamten Videocontent wiedergegeben werden. Bei In-Stream-Videos muss der Ton beim Starten des Players standardmäßig aktiviert sein oder der Nutzer muss ausdrücklich seine Absicht bekunden, sich die Videoinhalte anzusehen. Auch wenn es andere Inhalte um den Player herum geben kann, muss der Videocontent der ausschlaggebende Grund für den Aufruf des Nutzers sein. Es sollte der primäre Inhalt auf der Seite bleiben und der einzige Videoplayer, der bei der Wiedergabe Audio unterstützt und im Sichtfeld ist. Wenn der Player in einen schwebenden/fixierten Player umgewandelt wird, sollten nachfolgende Anzeigenaufrufe die aktualisierte Playergröße korrekt übermitteln.
PLCMT_ACCOMPANYING_CONTENT Pre-Roll-, Mid-Roll- und Post-Roll-Anzeigen, die vor, während oder nach dem Streamen von Videoinhalten wiedergegeben werden. Der Videoplayer wird vor, zwischen oder nach Textabsätzen oder grafischen Inhalten geladen und wiedergegeben. Die Wiedergabe beginnt erst, wenn der Videoplayer in den Darstellungsbereich gelangt. Die Wiedergabe des begleitenden Videocontents sollte erst gestartet werden, wenn der Videoplayer in den Darstellungsbereich gelangt. Wenn der Videoplayer beim Scrollen nicht mehr auf der Seite sichtbar ist, wird er möglicherweise in einen schwebenden/fixierten Player umgewandelt.
PLCMT_INTERSTITIAL Videoanzeigen, die ohne Videocontent ausgeliefert werden. Während der Wiedergabe muss es im Mittelpunkt der Seite stehen, den Großteil des Darstellungsbereichs einnehmen und nicht aus dem Sichtfeld herausgescrollt werden können. Das kann in Placements wie In-App-Videos oder -Diashows erfolgen.
PLCMT_NO_CONTENT_STANDALONE Videoanzeigen, die ohne Streaming von Videocontent ausgeliefert werden. Das kann in Placements wie Bildschirmschonern, nativen Feeds, In-Content-Anzeigen oder fixierten/schwebenden Anzeigen erfolgen.
BidRequest.imp.video.playbackmethod
Beschreibt, wie die Videoanzeige wiedergegeben wird. Die Wiedergabemethode wird anhand der besten verfügbaren Messung als „Automatisch“ oder „Klick-zu-Wiedergabe“ festgelegt.
AUTO_PLAY_SOUND_ON Wird beim Seitenaufbau gestartet, wenn der Ton aktiviert ist.
AUTO_PLAY_SOUND_OFF Wird beim Seitenaufbau ohne Ton gestartet.
CLICK_TO_PLAY Wird durch einen Klick gestartet, wenn der Ton aktiviert ist.
MOUSE_OVER Wird durch Mausbewegung gestartet, wenn der Ton aktiviert ist.
ENTER_SOUND_ON Wird gestartet, wenn der Darstellungsbereich betreten wird und der Ton aktiviert ist.
ENTER_SOUND_OFF Wird beim Einblenden des Darstellungsbereichs gestartet, wobei der Ton standardmäßig ausgeschaltet ist.
BidRequest.imp.video.skip
Wenn true angezeigt wird, kann das Video im Player übersprungen werden oder es sind überspringbare Anzeigen zulässig. Andernfalls gibt es an, dass überspringbare Anzeigen nicht zulässig sind.
BidRequest.imp.video.startdelay

„0“ steht für Pre-Roll, „-1“ für Mid-Roll und „-2“ für Post-Roll.

Bei anderen positiven Werten handelt es sich um die Zeit in Sekunden vom Beginn des Videos bis zum Zeitpunkt, an dem die Anzeige eingeblendet wird.

Diese Signale sind nicht nur für Video-Creatives relevant, sondern besonders wertvoll für Bieter:

BidRequest.device.ifa
Dieses Feld ist eine 36-stellige UUID, die nur bei Verwendung von SSL festgelegt wird und nicht gehasht wird. Das ist die unverschlüsselte Version von BidRequest.device.dpidm5. Bei iOS-Geräten enthält sie den Identifier for Advertisers (IDFA) in Großbuchstaben. Bei Android-Geräten enthält sie die Android-ID (ADID) in Kleinbuchstaben. Bei internetfähigen Fernsehern enthält sie ihre eindeutigen Kennzeichnungen (z. B. die RIDA von Roku).
BidRequest.device.devicetype
Gibt den Gerätetyp an.
MOBILE Ein veralteter Alias für HIGHEND_PHONE oder TABLET.
PERSONAL_COMPUTER Umfasst Computer und Laptops.
CONNECTED_TV umfasst sowohl internetfähige Fernseher (d. h. Smart-TVs) als auch internetfähige Geräte (z. B. Roku, Apple TV usw.).
HIGHEND_PHONE Dazu gehören auch High-End-Smartphones.
TABLET Dazu gehören auch Tablets.
CONNECTED_DEVICE Dazu gehören auch spezielle Gaming-Geräte.
SET_TOP_BOX Umfasst Set-Top-Boxen.
OOH_DEVICE Umfasst Geräte für Außenwerbung, z. B. digitale Billboards.
BidRequest.device.make
Gibt die Marke des Geräts an, z. B. Nokia oder Samsung.
BidRequest.device.model
Gibt das genaue Modell des Geräts an (z. B. N70 oder Galaxy), sofern verfügbar. Andernfalls enthält es ein generisches Modell wie „iphone“ oder „ipad“.
BidRequest.imp.metric
Wenn Metric.type auf completion_rate festgelegt ist, ist Metric.value ein Bruch im Bereich [0,0; 1,0], der die bisherige Abschlussrate für Videoanzeigen darstellt, die in der Anzeigenfläche ausgeliefert wurden. Der Standardwert -1.0 gibt an, dass keine Verlaufsdaten zur Abschlussrate verfügbar sind.
BidRequest.imp.video.poddur
Die Dauer der gesamten Werbeunterbrechung in Sekunden, einschließlich aller Slots, aus denen der Pod besteht. Dieser Wert wird auf den Wert festgelegt, der in den vom Videoanbieter bereitgestellten Videometadaten angegeben ist.

Die Videogebotsanfrage enthält außerdem Informationen zum Inventar, z. B. die Branche, zulässige Anbieter und Kanalinformationen. Alle anderen vorhandenen Felder in der Gebotsanfrage gelten auch für Videoanzeigen.

Die Felder „width“ und „height“ in der AdSlot-Nachricht einer Videoanfrage entsprechen der Größe des Videoanzeigen-Players.

BidRequest.imp.ext.allowed_vendor_type
Zulässige Anbieter. Eine Liste der IDs findest du in der technischen Dokumentation in der Datei vendors.txt. Beispiel: 309 = DFA-Videoblock
BidRequest.imp.video.mimes
Eine Zulassungsliste, die die unterstützten MIME-Typen für Inhalte für Anzeigen beschreibt, die als Reaktion auf die Gebotsanfrage ausgeliefert werden, z. B. „video/mp4“. Die Gebotsantwort muss mindestens eine der Technologien unterstützen.
BidRequest.imp.video.protocols
Hier werden die unterstützten VAST-Versionen eines Publishers für Videoanzeigenanfragen beschrieben. Enthält ein Array von Protocol-Enum-Werten, darunter: VAST_2_0, VAST_3_0, VAST_2_0_WRAPPER, VAST_3_0_WRAPPER, VAST_4_0, VAST_4_0_WRAPPER und mehr.
BidRequest.imp.video.companionad
Dieses Feld enthält ein Array von Banner-Objekten, die Companion-Anzeigen darstellen, sofern verfügbar.
BidRequest.site.page

Die URL der Wiedergabeseite des Videos oder die URL der Seite, in die das Video eingebettet ist. Beispiel:

http://www.publisher.com/watchpagelink

Bei der Beantwortung einer Videoanfrage sollte der Bieter eine VAST-Weiterleitungs-URL oder eine VAST-XML-Datei im Feld BidResponse.seatbid.bid.adm zurückgeben. Die Gebotsantwort muss außerdem die korrekte Erklärung für die Videoanzeige enthalten. Im Folgenden finden Sie einen Auszug aus einer korrekten Gebotsantwort für Videoanzeigen: 

id: "cRPF1960K8WH788KM8ZT5k"
seatbid {
  bid {
    id: "99862J52T2r9f8n6hzY"
    impid: "1"
    price: 0.2873480215418293
    adid: "test_creative_id_958969"
    adm: "https://video.test.com/ads?id=123456&wprice=%%WINNING_PRICE%%"
    adomain: "google.com"
    cid: "80831705186"
    crid: "test_creative_id_958969"
    w: 480
    h: 854
  }
  seat: "5731:4728:218110"
}
bidid: "dR2wx766-444e907U-Xpv0-634m58Wa5V73"
cur: "USD"

Die wichtigsten Felder in einer Videogebotsantwort sind:

BidResponse.seatbid.bid.ext.attribute
Attribute für die Anzeigen, die über das Snippet ausgeliefert werden können. Die Liste der IDs finden Sie in der Datei buyer-declarable-creative-attributes.txt. Wir prüfen, ob keine dieser Attribute mit den Attributen übereinstimmt, die vom Publisher in der Gebotsanfrage abgelehnt wurden. Wenn Sie beispielsweise festlegen, dass eines der Felder 30 enthält, bedeutet das, dass für das Rendern der Anzeige VPAID-Unterstützung erforderlich ist.
BidResponse.seatbid.bid.adm

Bei Videoanzeigen ist das die VAST-Weiterleitungs-URL der Videoanzeige. Beispiel:

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

Alternativ kann es sich auch um rohe VAST-XML-Dateien handeln.

Beispiel-Gebotsanfragen und -antworten

Videoformate

So fügen Käufer Videos hinzu

In den folgenden Tabellen wird dargestellt, wie Käufer Video in ihre Creatives einbinden und in welchen Placements sie jeweils im Web und in mobilen Apps ausgeliefert werden können.

Web

Video-Creative In-Stream (alle) In-Feed/Artikel Native In-Feed-/In-Article-Anzeigen Interstitial In-Banner

VPAID + VAST

 

VAST

 

MRAID + JS

 

 

 

 

 

Benutzerdefiniertes JS

 

Native Anzeigen + VAST

 

Mobile App

Video-Creative In-Stream (alle) In-Feed/Artikel Native In-Feed-/In-Article-Anzeigen Interstitial In-Banner

VPAID + VAST

 

 

 

 

 

VAST

MRAID + JS

Benutzerdefiniertes JS

Native Anzeigen + VAST

Schlüssel: Format/Technologie nicht verfügbar

Video-Creative für dieses Placement akzeptiert, aber von Publisher-Blockierungen betroffen

Video-Creative für dieses Placement nicht verfügbar

Empfohlene OpenRTB-Signale

In den folgenden Tabellen sind die von OpenRTB empfohlenen Signale für alle Videoformate für Computer und das mobile Web sowie mobile Apps aufgeführt.

Computer und mobiles Web

Videoformat Empfohlene Signale (nur videorelevante Signale) Zugehörige Signale (nur Videosignale)

In-Stream (VPAID)

VIDEO-Objekt vorhanden   &
video.placement = INSTREAM   &

In-Stream (keine VPAID)

VIDEO-Objekt vorhanden   &
video.placement = INSTREAM    &
video.api = 1 VPAID 1.0 or 2:VPAID 2.0

Nicht In-Stream

VIDEO-Objekt vorhanden

video.linearity: linear
placement depends on actual
placement, values as below
Video.startdelay = 0

In-Feed

VIDEO-Objekt vorhanden   &
video.placement = IN-FEED

In-Article

VIDEO-Objekt vorhanden   &
video.placement = IN-ARTICLE

Nativ

NATIVE object present &

In-Banner

Videoobjekt nicht vorhanden &
banner.battr ≠ 6 In-Banner-Video (automatische Wiedergabe) &
banner.battr ≠ 7 In-Banner-Video (vom Nutzer gestartet)

Mobile App

Videoformat Details zur Gebotsanfrage (nur die für das Video relevanten Details)

In-Stream

VIDEO-Objekt vorhanden   &
video.placement = INSTREAM    &

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

Nicht In-Stream

VIDEO-Objekt vorhanden

video.linearity: linear
placement depends on actual
placement, values as below
Video.startdelay = 0

In-Feed

VIDEO-Objekt vorhanden   &
video.placement = IN-FEED

In-Article

VIDEO-Objekt vorhanden   &
video.placement = IN-ARTICLE

Nativ

NATIVE object present &

Interstitial (VAST)

VIDEO-Objekt vorhanden   &
video.placement = INTERSTITIAL

Interstitial (kein VAST)

VIDEO-Objekt vorhanden   &
video.placement = INTERSTITIAL

Gefiltert

In-Banner (MRAID)

Videoobjekt nicht vorhanden &
banner.battr ≠ 6 In-Banner-Video (automatische Wiedergabe) &
banner.battr ≠ 7 In-Banner-Video (vom Nutzer gestartet)

In-Banner

(kein MRAID)

Videoobjekt nicht vorhanden &
banner.battr ≠ 6 In-Banner-Video (automatische Wiedergabe) &
banner.battr ≠ 7 In-Banner-Video (vom Nutzer gestartet)

Videoanzeigen für Publisher zulassen oder deaktivieren

In der folgenden Tabelle wird dargestellt, wie Publisher Videoanzeigen in ihren Placements zulassen oder deaktivieren können.

Pub-Option Zulässige Formate In der Gebotsanfrage wird Folgendes angegeben:

In-Stream-Video als Anzeigenblock festlegen

In-Stream (alle)

Videoobjekt vorhanden &
video.placement = INSTREAM

VPAID aktivieren

In-Stream-Videos im Web

Videoobjekt vorhanden und
video.api = 1 (VPAID 1.0) oder 2 (VPAID 2.0)

IBV aktivieren

In-Banner

Interstitial

banner.battr ≠ 6 In-Banner-Video (automatische Wiedergabe) und/oder 7 In-Banner-Video (vom Nutzer gestartet)

Aktivieren Sie (Anleitung).

In-Feed

In-Article

Videoobjekt vorhanden &
video.placement = IN-FEED oder IN-ARTICLE

Nicht-In-Stream-Anzeigen aktivieren (Anleitung)

Nativ

Natives Objekt vorhanden

Video-Interstitial blockieren

Interstitial in Apps

VIDEO-Objekt nicht vorhanden

Sonderfälle

# Fallbeschreibung Kommentare Gebotsanfrage

1

Verzögerte benutzerdefinierte Schließung mit MRAID

Beim Schließen von Interstitials kann über MRAID eine Benachrichtigung an den Käufer gesendet werden, auch wenn er keinen benutzerdefinierten Abschluss verwendet hat.


Das von Authorized Buyers angewendete X wird immer über allen benutzerdefinierten Schließelementen angezeigt, auch wenn das benutzerdefinierte Schließelement nach 5 Sekunden darunter erscheint.

Glossar

Weitere Informationen finden Sie im Glossar für Authorized Buyers-Videos.

Relevante Felder für In-Stream- und Nicht-In-Stream-Formate

Weitere Informationen finden Sie unter OpenRTB 2.5 (ab Seite 47).

BidRequest.Video.
Placement
In-Stream mWeb

1: In-Stream
2: In-Banner

mApp

1: In-Stream
2: In-Banner
Nicht In-Stream mApp Interstitial

5: Interstitial

Native

3: In-Article
4: In-Feed

Rewarded

is_rewarded_inventory: Boolescher Wert der OpenRTB-Erweiterung
linearity

Gibt an, ob die Impression linear, nicht linear usw. sein muss. Ist keine Angabe vorhanden, sind alle zulässig.

In-Stream mWeb

1: LINEAR (In-Stream)

mApp

1: LINEAR (In-Stream)
Nicht 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
Nicht In-Stream Rewarded

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

Wertquelle der Gebotsanfrage

OpenRTB-
Objekt		 Felder Authorized Buyers 
/Anzeigenplattform
Bidding
Nicht In-Stream		 Beispiele Wer bestimmt das?
/Woher stammt dieser Wert
Object
Video mimes Ja ["application/javascript",
"video/mp4"]",		 Google
minduration Nein Vom Publisher konfiguriert
maxduration Ja Vom Publisher konfiguriert
playbackmet
hod		 Ja [6] Normalerweise vom Publisher
Konfiguriert
API (MRAID) Ja [1,2] Google
Protokolle Ja [2,3,5,6,7,8] Google
Linearität Ja [1] Google
placement Ja [1] Google
player width Ja 400,400,300 Google
Spielerhöhe Ja 225.300.153 Google
Startverzögerung Ja 0 Google, Standardeinstellung 5 Sek.
Überspringen Ja 1 Publisher/Google
– für Interstitial => Google
– für In-Stream => Publisher
entscheidet, ob überspringbare, nicht überspringbare oder beide Anzeigen zulässig sind.

Anzeigen mit Prämie, immer nicht überspringbar;
Minimale Bitrate Nein Google
max bitrate Nein Google
pos Ja 1 Google
Gerät
Pixelverhältnis Ja 1 Google
Impression
Sicher Ja 1 Google
standardmäßig „wahr“
(adtag ist immer
sicher)