Welchen Videoplayer verwenden die meisten Publisher?

Dieser Beitrag wurde zuletzt am 6. Juli 2022 aktualisiert

In diesem ausführlichen Blogbeitrag werfen wir einen genaueren Blick auf die verschiedenen Videoplayer, die Publishern auf dem Markt zur Verfügung stehen, vergleichen ihre Funktionen (einschließlich Vergleichstabelle), betrachten die Bereitstellung von Videoanzeigen, verschiedene Videoanzeigenblöcke und sogar die Fallstricke von Anzeigenschaltung.

Wenn Sie derzeit mit Google Ad Exchange arbeiten, haben wir auch einen Abschnitt mit Best Practices für die Bereitstellung von Videoanzeigen eingefügt. Lass uns anfangen!

JW-Spieler

Der JW-Player ist einer der am häufigsten verwendeten webbasierten Player, der eine Vielzahl von Formaten (HLS, VAST 3.0, VPAID 2.0) unterstützt und sich in die meisten großen Werbenetzwerke integrieren lässt.

Erfahren Sie hier mehr über VPAID vs. VAST.

Dieser Videoplayer unterstützt die plattformübergreifende Anzeigenbereitstellung mit erweiterten Funktionen wie Live-Stream-Unterstützung, Untertiteln und ist zukunftssicher mit nativer Unterstützung für die Wiedergabe von 360-Grad- und VR-Videos.

Es bietet native SDKs für Android und iOS für In-App-Implementierungen. Es ist auch ein vertrauenswürdiger Anbieter für die Schaltung von Anzeigen über die DoubleClick-Suite von Google und ein von Google zertifizierter Verlagspartner.

Zu den Kunden von JW-Playern gehören Amazon, Vice, Univision, Fox und viele mehr. JW Player hat in Zusammenarbeit mit SpotX kürzlich natives Header Bidding (Video) zur Monetarisierung von Inhalten eingeführt, die mit JW Player bereitgestellt werden.

Demo- und Beispiel-Player-Implementierungen finden Sie hier, um sich ein Bild von den Player-Fähigkeiten und funktionalen Aspekten zu machen.

In JW Player 8 verfügbare Funktionen:

• Multiprotokoll-Streaming-Unterstützung: HLS, DASH (Adobe RTMP wird nicht unterstützt)
• 4k-Videowiedergabeunterstützung im HTML5-Modus
• 60FPS-Videowiedergabeunterstützung
• Unterstützung für Wiedergabelisten im RSS/XML- und JSON-Format
• VAST 4.0, VPAID 2.0, VMAP-Unterstützung
• Integration mit den wichtigsten Anzeigenserver-SDKs: Google IMA SDK und FreeWheel Ad Manager SDK
• Podding, Wasserfall/Fallback, Anzeigenplanung

Die Preise für diesen Videoplayer beginnen bei 5 $ pro Monat (wird jährlich abgerechnet). Die benutzerdefinierten Preise für die Monetarisierung über Adserving basierend auf dem Traffic betragen mehr als 50 $ pro Monat. Die IMA SDK-Integration ist für die Einstiegs- (5 US-Dollar pro Minute) und mittleren (50 US-Dollar pro Minute) Angebote nicht verfügbar.

Ooyala

Die neueste Version des Ooyala-Videoplayers bietet eine lange Liste von Funktionen, die alle Ihre Anforderungen an die Veröffentlichung und Monetarisierung von Videos erfüllen. Ihr UI-Design folgt den Google Material UX-Richtlinien und ist in hohem Maße anpassbar, um Ihr Branding widerzuspiegeln.

Einige der in Ooyala Player 4.0 verfügbaren Funktionen sind:

• Inhaltsbewusste Player-Steuerung
• Untertitel (DFXP)
• Möglichkeit, Inhalte in sozialen Medien zu teilen
• Empfehlungsmaschine
• Unterstützte Formate: VAST 3.0, VPAID 2.0, VMAP 1.0, HLS und MP4, OSMF Flash HDS, von Akamai verpacktes HDS sowie DASH und HLS
• Rückwärtssuche bei der Wiedergabe von Live-Stream-Inhalten
• Podding- und Cue-Point-Verwaltung
• Android- und iOS-SDKs
• Google IMA-Integration über ein Plugin.
• Unterstützung mehrerer Analyseplattformen (Adobe, comScore, Nielsen, Google Analytics usw.)
• Natives Monetarisierungsangebot über Ooyala pulse.
• Verfügt über mehrere Werbenetzwerk-Integrationen, die sofort einsatzbereit sind.

Preise: Siehe die Kundenpreisstruktur.

Brightcove

Die Videoveröffentlichungs- und Monetarisierungsangebote von Brightcove richten sich an große Verlage mit hohem Datenverkehr und riesigen Inhaltskatalogen. Die Produktsuite von Brightcove erfüllt alle Anforderungen für die Veröffentlichung von Videoinhalten, von der grundlegenden Wiedergabe von Inhalten bis hin zum Hosten von Inhalten, Aufnahme von Inhalten, erweiterten Analyse- und Marketingtools.

Dies trägt dazu bei, die Anzahl der beweglichen Teile zu reduzieren, wodurch Kompatibilitätsprobleme beseitigt und die Zuverlässigkeit erhöht werden. Einige der größten Marken wie Ford, BBC, Oracle, Condenast und GoDaddy verwenden die Brightcove-Suite für ihre Publishing-Anforderungen.

Features sind:

• IMA-, OnceUX-, SpotX- und FreeWheel-Integration von Google
• Unterstützung der 360-Grad-Videowiedergabe
• Verfügbarkeit von DRM-Inhaltsschutz (Widevine Media-Format)
• Unterstützung für Live-Stream-Lieferung in mehreren Formaten (HLS, DASH, FairPlay Streaming von Apple)
• Native iOS- und Android-SDKs für In-App-Implementierungen
• Native Unterstützung für tvOS (Apple TV).
• Airplay-Unterstützung für nicht monetarisierte Inhalte mit nativem iOS SDK
• Native Analytics- und Adobe Analytics-Integration
• Unterstützung mehrerer Audiospuren auf nativen iOS- und Android-SDKs
• Serverseitige Adserving-Unterstützung

Preise: Nur benutzerdefinierte Preise verfügbar.

Video.js

Im Gegensatz zu den anderen Playern auf dieser Liste ist Video.js ein Open-Source-Angebot eines HTML5-basierten Videoplayers mit Unterstützung für die Monetarisierung von Videos. Der Hauptsponsor des Projekts ist Brightcove, dessen Videoplayer ebenfalls auf dem video.JS-Framework aufbaut.

Das Projekt hat eine sehr hilfreiche Community mit einer breiten Palette von Plugins für die Integration von Drittanbietern und zusätzlichen Diensten. Es kann je nach Anforderung angepasst werden (HTML-, CSS- und Javascript-Optimierung erforderlich) oder sofort verwendet werden.

Sehen Sie sich die Anleitung hier und das Plug-in an, das zur Unterstützung der IMA SDK-Integration verfügbar ist.

Einige bekannte Kunden sind Instagram, Twitter, Microsoft, Github, IGN, The Guardian und viele mehr.

Von Plugins unterstützte Funktionen sind:

• Kuratierung von benutzerdefinierten Wiedergabelisten
• Airplay- und Chromecast-Unterstützung (Browser- und geräteabhängig)
• Google Analytics-Integration
• Live-Streaming-Unterstützung (HLS & DASH)
• Benutzerdefinierte Fehlerberichterstattung
• Wiedergabe von DRM-Inhalten (Apple Fairplay)
• IMA SDK-Integration
• Ooyala CDN-Integration
• 360-Grad-, VR- und Panorama-Videounterstützung
• Inhaltsempfehlungs-Engine
• Social-Sharing-Integration

Preise: Kostenlos

Feature-Vergleichsmatrix

Hintergrundinformationen zu Videoplayern

Herkömmliche Videoplayer hatten nur eine Aufgabe zu erledigen, den Inhalt mit nur einfachen Navigationssteuerelementen abzuspielen. Die Spieler hatten eine Liste mit Videoformaten, die sie rendern konnten, und das war es auch schon.

Heutzutage haben sich Videoplayer weiterentwickelt, um einer ständig wachsenden Nachfrage und vielen Funktionen gerecht zu werden, die über das Abspielen eines Video-Assets hinausgehen. Mit der branchenweiten Einführung von HTML5 sind einst weit verbreitete Player, die auf dem Flash-Framework basieren, rapide zurückgegangen.

Es gibt mehrere Gründe für Sie, zu einem HTML5-Player anstelle von Flash-basierten Playern zu wechseln, von denen die beiden wichtigsten Faktoren Geschwindigkeit und Sicherheit sind.

Wenn Sie jedoch Flash-basierte Inhalte bereitstellen möchten, gibt es bereits jetzt mehrere Optionen für Sie, viele Videoplayer unterstützen Videodateien im Flash-Format.

Im Zusammenhang mit der Anzeigenschaltung wird Flash nicht mehr von allen gängigen Webbrowsern unterstützt.

Wie fordert ein Videoplayer eine Anzeige an und schaltet sie?

Ein Player erfordert zunächst die Implementierung eines Videoanzeigen-Tags, das an den Cue-Punkten ausgelöst wird, an denen die Anzeige gerendert werden soll.

Es gibt drei Hauptpositionen, an denen Videoanzeigen geschaltet werden:

1. Pre-Roll: Die Werbung, wenn sie abgespielt/gerendert wird, bevor die Inhaltswiedergabe initiiert wird.
2. Mid-Roll: Jede Position zwischen dem Anfang und dem Ende des Inhalts wird als Mid-Roll betrachtet.
3. Post-Roll: Die Anzeige, wenn sie am Ende/Fertigstellung des Inhalts abgespielt/gerendert wird.

Wenn die Anfrage an den Ad-Server gestellt wird, findet die Anzeigenauswahl/RTB statt und die erfolgreiche Anzeige wird in einer VAST-XML-Antwort mit allen zugehörigen Media-Assets und Tracking-Ereignis-Pings zurückgegeben.

(VAST steht für „Digital Video Ad Serving Template“, eine Spezifikation, die vom IAB entwickelt wurde, um eine gemeinsame XML-Antwort von allen Ad-Servern zu haben. Vorher erforderte jeder Ad-Server und Player eine Antwort in unterschiedlichen Formaten, was nicht effizient war.)

Sobald der Player die VAST-XML-Antwort vom Ad-Server erhält, ruft er die Creative-Asset-Dateien ab und rendert sie an den vordefinierten Cue-Punkten vor/während/nach der Inhaltswiedergabe.

Der Player löst auch die in der VAST-XML zurückgegebenen Tracking-Ereignisse bei den zugehörigen Ereignisauslösern aus. Sollte ein Fehler/Problem auftreten, wird ein VAST-Fehler ausgelöst und für zukünftige Analysen auf dem Ad-Server protokolliert.

Es gibt drei verschiedene Möglichkeiten, Medien-Assets bei der Bereitstellung von Videoanzeigen zu hosten:

Ad-Server gehostet

Medien-Assets werden auf dem Ad-Server gehostet, der zur Schaltung der Anzeigen verwendet wird. Der Vorteil dieses Ansatzes besteht darin, dass eine direkte Hosting-URL der Mediendateien in der VAST-Antwort zurückgegeben wird. Dadurch werden die Latenz und die Ausfallrate beim Abrufen der Mediendateien durch den Player erheblich reduziert.

Extern gehostet

Medienassets werden auf einem CDN eines Drittanbieters gehostet, und die Hosting-URL wird im VAST-XML zurückgegeben. Dies kann je nach CDN-Antwortzeit die Latenz beim Abrufen der Mediendateien erhöhen.

Umleitungs-Tags

Dies ist die am häufigsten verwendete Art des Media-Asset-Hostings, bei der ein Weiterleitungs-Tag im Ad-Server getraffickt wird und dasselbe Tag in der VAST-XML zurückgegeben wird. Der Player löst dann das Redirect-Tag aus, das dann die Mediendateien in einer zweiten VAST-Antwort abruft.

Diese Option wird typischerweise in Implementierungen verwendet, bei denen eine weitere Auktion auf einem zweiten Anzeigenserver durchgeführt wird und die Mediendateien/Werbung für jede Anfrage unterschiedlich sein können.

Arten von Videoanzeigenblöcken/-implementierung/-bereitstellung

Im Stream

Bei dieser Art der Bereitstellung von Videoanzeigen werden Videoanzeigen innerhalb eines Players/einer App bereitgestellt. Das Hauptaugenmerk der Zielgruppe liegt in diesem Fall auf den Inhalten, die speziell über den Videoplayer bereitgestellt werden. In dieser Umgebung werden im Allgemeinen 3 Anzeigenformate geschaltet:

1. Linear: Dies sind in der Regel Anzeigen im Videoformat und werden durch Unterbrechen der Inhaltswiedergabe geliefert.Es gibt drei Positionen/Zeitachsen, an denen lineare Anzeigen geschaltet werden können, vor dem Inhalt (Pre-Roll), während der Wiedergabe des Inhalts (Mid-Roll) und nachdem der Inhalt abgespielt wurde (Post-Roll).
2. Nicht linear: Dies sind im Allgemeinen statische Bilder oder Formate, die für Rich Media aktiviert sind und die die Inhaltswiedergabe nicht unterbrechen/pausieren.Sie sind in der Regel kleiner und werden im unteren/unteren Bereich des Videoplayers überlagert.
3. Companion: Dies sind allgemeine Display-Anzeigen, die zusammen mit den linearen Anzeigen in der Nähe des Players geschaltet werden, um ein intensiveres Erlebnis zu erreichen und den Benutzern auch die Möglichkeit zu geben, Maßnahmen in Bezug auf die Videoanzeige zu ergreifen, die früher geschaltet wurde, auch nachdem sie beendet wurde (nützlich für den Fall von kurzen Videoanzeigen).

Ausgangsstrom:

Bei dieser Art der Implementierung gibt es keinen zentralen Inhalt auf einem Videoplayer. Die Videoanzeigen werden in Übereinstimmung mit dem Anzeigeinhalt auf der Seite geschaltet.

Es gibt mehrere Möglichkeiten oder Implementierungen für die Bereitstellung von Outstream-Videoanzeigen. Am gebräuchlichsten ist das In-Banner-Video, bei dem eine Videoanzeige innerhalb eines Display-Werbeblocks gerendert wird.

Andere häufig verwendete Implementierungen sind Video-Interstitials, In-Page-Videos (Starten eines Players).

Häufige Schwachstellen bei der Bereitstellung von Videoanzeigen:

Timeout : Jeder Player hat die Möglichkeit, ein vordefiniertes Timeout festzulegen, bei dessen Erreichen die Wiedergabe des Inhalts gestartet wird.Dadurch wird sichergestellt, dass der Inhalt/die Wiedergabe nicht aufgehalten wird, falls beim Abrufen der Mediendateien eine Latenz/Verzögerung auftritt, was eine optimale Benutzererfahrung bietet.

Leere VAST-Antwort: Ist eine Möglichkeit bei Weiterleitungs-Tags, wenn die Weiterleitungs-URL keine Anzeige abgerufen hat, dh die Anfrage an den 3rd-Party-Ad-Server unbesetzt blieb.

Mehrere Weiterleitungen: Einige Werbetreibende/Anzeigenanbieter geben ein weiteres Weiterleitungs-Tag für das erste weitergeleitete Weiterleitungs-Tag zurück.Dies kann auf Daisy-Chaining und Endlosschleifen oder Verzögerungen in jeder der Umleitungsantworten zurückzuführen sein.

Um dies zu verhindern, haben Videoplayer ein Weiterleitungslimit, bei dessen Erreichen ein VAST-Fehler ausgelöst wird. Wenn kein Grenzwert festgelegt ist, ist der nächste Fehlerpunkt das Erreichen des Timeouts.

Nicht unterstütztes Media-Asset-Format: Wenn der Videoplayer die im VAST-XML zurückgegebenen Mediendateien nicht wiedergeben kann, wird dieser Fehler ausgelöst.Dieser Fehler tritt nicht sehr häufig auf, da mehrere Mediendateien zurückgegeben werden, jede mit unterschiedlicher Größe, Bitrate, Kodierung usw. Der Player kann diejenige auswählen, die am besten zu der Umgebung passt, in der die Anzeige gerendert werden soll.

Umsatzeinbußen, wenn eine Anzeige nicht abgespielt wird und einen Fehler auslöst?

Was passiert, wenn die Tags, die an Ihren Ad-Server weitergeleitet werden, keine Anzeige abrufen können?

Die Möglichkeit, diese spezifische Anfrage/Impression zu monetarisieren, geht verloren. Um dieses Problem zu lösen, kommt der Wasserfall/Fallback ins Spiel. Wenn auf Ihrem Ad-Server ein Fallback aktiviert ist, sendet er eine vordefinierte Anzahl erfolgreicher Anzeigen in der VAST-XML-Antwort.

Wenn die erste aus irgendeinem Grund fehlschlägt, geht der Spieler zur nächsten Anzeige in der Liste über. Dieser Vorgang wird fortgesetzt, bis der Spieler eine Anzeige abspielen kann.

Die offensichtliche Frage in diesem Szenario lautet: Wird dies zu einer Verzögerung/Erhöhung der Anzeigenlast und Renderzeiten führen?

Der Overhead ist in diesem Fall sehr vernachlässigbar und der Spieler durchläuft den Fallback innerhalb von Millisekunden.

Ein möglicher Fehlerpunkt, selbst wenn Fallback korrekt eingerichtet ist:

Der einzige Fehlerpunkt wäre in diesem Fall, wenn der Drittanbieter-Server keine Antwort zurückgibt oder eine leere Antwort zurückgibt, weil keine Anzeige vorhanden ist.

In diesem Fall wartet der Videoplayer auf das festgelegte Zeitlimit, das nach Erreichen die Inhaltswiedergabe einleitet. Die Anzeigen im Fallback werden nicht einmal ausprobiert worden sein.

Wie kann das Problem der Timeout-Auslösung gelöst werden, bevor alle Anzeigen im Fallback ausprobiert wurden?

Dazu gibt es zwei Ansätze:

1. Testen Sie die Latenz in der Antwort des Drittanbieter-Ad-Servers und vermeiden Sie die Verwendung von Ad-Servern/Tags, die viel Zeit brauchen, um eine Antwort zurückzugeben, wenn es keine erfolgreichen Gebote/Anzeigen gibt.
2. Stellen Sie das Standard-Timeout des Players auf eine längere Dauer ein, abhängig von den durchschnittlichen Ad-Server-Antwortzeiten der Tags, die an Ihren Ad-Server oder von Bedarfspartnern getraffickt werden.

Tipps und Best Practices für die Bereitstellung von Videoanzeigen über Google Ad Exchange (AdX)

• Um Anzeigen über die programmatischen Plattformen von Google schalten zu können, muss der Videoplayer in das IMA SDK integriert sein, ohne dass es zu Inkonsistenzen und Diskrepanzen bei der Berichterstellung kommen kann.

• Wenn die IMA SDK-Integration nicht möglich ist, bietet Google einen alternativen Ansatz, um die AdX-Nachfrage über die Verwendung von Adapter-Tags zu bedienen. Ein Adapter-Tag, das auf einem nicht in IMA integrierten Player bereitgestellt wird, emuliert die IMA SDK-Funktionalität für diese spezifische Anforderung und stellt alle Funktionsaufrufe und Funktionen eines integrierten IMA SDK-Players bereit. Adapter-Tags können generiert werden, indem die Technologie als "IMA-Adapter" ausgewählt wird, wenn die Video-Tags in Google AdX generiert werden.

• Vermeiden Sie die Bereitstellung von IMA-Adapter-Tags auf Playern mit integriertem IMA SDK, da dies nicht empfohlen wird und die Anzeige möglicherweise nicht wiedergegeben werden kann, wodurch ein VAST 901-Fehler ausgelöst wird.
• Achten Sie zusätzlich zu den AdX-Programmrichtlinien auf die Einhaltung der hier aufgeführten AdX-spezifischen Videorichtlinien.
• Ab April 2018 erzwingt das neue Richtlinienupdate von Chrome eine Einschränkung für Autoplay-Videoanzeigen. Dies wirkt sich nur aus, wenn Sie Autoplay-Videoanzeigen mit Ton schalten, und gilt nicht für Autoplay-Videoanzeigen, die standardmäßig stummgeschaltet sind.
• Nicht stummgeschaltete Autoplay-Videoanzeigen dürfen nur geschaltet werden, wenn eines der folgenden Kriterien erfüllt ist:
  • Bevor die Anzeige die Wiedergabe initiiert hat, hat der Nutzer auf Ihrer Website interagiert.
  • Der MEI (Media Engagement Index) des Benutzers ist höher als ein vordefinierter Schwellenwert (nur für Desktop). Die Berechnung des MEI-Index wird in diesem Artikel detailliert beschrieben.
  • Auf einer mobilen Plattform, wenn der Benutzer die Website auf dem Startbildschirm des Geräts angeheftet/mit einem Lesezeichen versehen hat.

Abschluss

Obwohl wir in diesem Artikel alle Informationen für Sie zusammengestellt haben, können Videoplayer und die Bereitstellung von Videoanzeigen kompliziert sein. Melden Sie sich noch heute für ein Professional-Konto bei MonetizeMore an, um Hilfe bei der Auswahl des richtigen für Ihr Verlagsgeschäft und dessen korrekter Implementierung zu erhalten!

Weitere Fragen