Das Connected TV (CTV) Wachstum boomt und die Werbeausgaben werden laut IAB in diesem Jahr voraussichtlich 21,2 Milliarden Dollar erreichen. Dennoch ist die programmatische Technologie immer noch nicht in der Lage, eine optimale Werbeunterbrechung zu ermöglichen, die den Erwartungen von Media Ownern, Buyern und Zuschauern entspricht.
Tatsächlich schätzt Watching That dass etwa 15 % des programmatischen CTV-Inventars unbesetzt bleibt, was zu einem Verlust von mehr als einer Milliarde Dollar führt.
CTV setzt auf Ad-Podding, um einzelne Werbespots in einer Werbepause zusammenzufassen. Ad-Pods müssen Duplizierung, Trennung von Wettbewerbern, Latenz oder Pufferung und Frequency Capping bewältigen – alles wichtige Faktoren, um das qualitativ hochwertige, geradlinige Fernseh-Erlebnis im CTV zu reproduzieren.
Viele Programmatic-Tools und -Standards wurden für Web und Display entwickelt und wurden einfach nicht auf die Bedürfnisse von Media Ownern und Buyer im CTV zugeschnitten.
Beispielsweise hat sich das vom IAB Tech Lab entwickelte Protokoll OpenRTB 2.5 in der programmatischen Welt weit verbreitet und ist in vielerlei Hinsicht ein sehr effektiver Standard. Es wurde jedoch 2016 veröffentlicht, also vor dem Aufkommen programmatisch verkaufter Videowerbung in CTV- und anderen Over-the-Top-Umgebungen (OTT).
Die Branche hat mit OpenRTB 2.5 einige rudimentäre Möglichkeiten für den Handel mit Video-Ad-Pods gefunden, die jedoch zu suboptimalen Zuschauererlebnissen führten und das Wachstum des programmatischen CTV gebremst haben könnten.
Spulen wir ins Jahr 2022 vor. Das IAB Tech Lab veröffentlichte OpenRTB 2.6 in diesem Frühjahr mit dem Ziel, diese Podding-Herausforderungen im CTV zu lösen. Wir freuen uns sehr über die neuen Funktionen in OpenRTB 2.6 und wir sind stolz darauf, zur Veröffentlichung beigetragen zu haben.
Wie verbessert OpenRTB 2.6 die CTV Ad Pods und warum sollte die gesamte Branche es nutzen?
OpenRTB 2.6 wurde speziell mit Blick auf die Feinheiten von CTV und Ad-Podding entwickelt. Es führt einen standardisierten Ansatz ein, um die Verfügbarkeit von podded-Angeboten in CTV und anderen OTT-Videos zu signalisieren – etwas, das unserer Branche seit Jahren gefehlt hat.
Hier sind drei Möglichkeiten, wie OpenRTB 2.6 die Mängel von OpenRTB 2.5 behebt und dazu beiträgt, TV-ähnliche Werbeerlebnisse für Media Owner, Buyer und Zuschauer zu schaffen.
1. Doppelte Anzeigen
Durch die kontrollierte Ausstrahlung und die weitgehend manuelle Auswahl der Werbung im Fernsehen sehen die Zuschauer fast nie wiederholte oder doppelte Werbung. Die Programmatic-Technologie konnte dieses Erlebnis bei CTV nur bedingt wiedergeben, was Werbetreibende, Content Creators und Zuschauer gleichermaßen frustriert.
Mit OpenRTB 2.5 haben Media Owner zwei Möglichkeiten, Bid Requests für Podded Impressions zu senden: Mehrere nicht korrelierende Bid Requests oder einen Multi-Impression Bid Request.
Bei diesen Ansätzen gibt es mehrere Probleme. Das Hauptproblem bei nicht korrelierenden Bid Requests besteht darin, dass die Empfänger sie in der Regel nicht als Requests innerhalb einer zusammenhängenden Werbepause oder eines Pods behandeln können. So kann es vorkommen, dass Buyer ein und dasselbe Werbemittel mehrfach zurückgeben und Media Owner und Supply Plattformen doppelte Gebote abgeben müssen.
Media Owner können diese nicht korrelierenden Bid Requests seriell verschicken und den Werbetreibenden signalisieren, dass sie Gebote ausschließen, die sie bereits erhalten haben. Dies verringert zwar die Zahl der doppelten Anzeigen, erhöht aber die Latenzzeit und den Bedarf an langen tmax-Werten (der OpenRTB-Parameter, der einem Buyer mitteilt, wie lange er für die Rückgabe eines Gebots Zeit hat, bevor die Response-Zeit ausläuft).
Bid Requests für Multi-Impressions sind eine Verbesserung, aber viele Buyer unterstützen sie nicht. Darüber hinaus gibt es keinen Standard, um einen Video-Ad-Pod von mehreren einzelnen Video-Impressionen innerhalb einer Anfrage zu unterscheiden, sodass einige Buyer immer noch mehrere Instanzen desselben Werbematerials zurückgeben können.
OpenRTB 2.6 nimmt doppelte Anzeigen ins Visier, indem es Ad-Pods klar von Videoanfragen mit mehreren Impressionen abgrenzt und Media Ownern ermöglicht, diesen Ad-Pods eine klare Struktur zu geben. Auf diese Weise verfügen die Buyer über alle Informationen, die sie benötigen, um fundierte Angebote ohne Duplikate oder Wettbewerbskonflikte abzugeben.
2. Geometrie des Ad-Pods
Jeder Media Owner hat unterschiedliche Anforderungen an die Monetarisierung von Werbung. Einige ziehen es vor, so viele Einnahmen wie möglich aus Werbeunterbrechungen mit fester Länge zu erzielen; andere ziehen es vor, so wenig Werbung wie möglich zu zeigen und dennoch ihre Monetarisierungsziele zu erreichen. Einige sind bei der Dauer der Werbepods flexibel, andere verlangen eine genaue Werbedauer, um Leerlauf während der Livestream-Übertragungen zu vermeiden.
OpenRTB 2.5 kann diese Präferenzen nicht berücksichtigen, da es den Media Ownern nur erlaubt, die minimale und maximale Anzeigendauer für jede Position in einem Pod sowie einen statischen TKP Bid Floor anzugeben.
OpenRTB 2.6 führt das Konzept der strukturierten, dynamischen und hybriden Pods ein, zusammen mit einer Reihe von zusätzlichen Feldern, die es Media Ownern ermöglichen, die „Geometrie“ des zu befüllenden Ad Pods auszudrücken.
So können sie beispielsweise Buyer bitten, Ad Pods einer bestimmten Dauer mit einer begrenzten Anzahl von Werbemitteln zu füllen, indem sie die Felder poddur und maxseq im Bid Request verwenden. Media Owner können mit dem Feld mincpmpersec auch dynamische Bid Floors auf der Basis von TKP pro Sekunde festlegen. Oder sie können das Array rqddurs verwenden, um eine genaue zulässige Dauer für jede Anzeigenposition anzugeben.
3. Ad Pods und Slot-Positionen
Im Fernsehen werden für verschiedene Werbepausen innerhalb einer Sendung oder sogar für verschiedene Positionen innerhalb einer Werbepause unterschiedliche Preise verlangt. In OpenRTB 2.5 gibt es keinen Standard für die Abgrenzung zwischen mehreren Pods oder Positionen, und Media Owner und Buyer behandeln Gebote in der Regel einfach als eine Sammlung von Werbemitteln, die die Media Owner nach eigenem Ermessen zusammenstellen können.
OpenRTB 2.6 führt podseq ein, das Media Owner im Bid Request verwenden können, um anzugeben, ob ein bestimmter Pod der erste, der letzte oder der mittlere eines Programms ist. Das Feld slotinpod gibt die gleichen Positionen innerhalb eines Ad Pods an. Media Owner können jedem Pod sogar eine podid zuweisen, so dass mehrere Pods mit einem einzigen Bid Request verkauft werden können.
Auf der anderen Seite können Buyer auswählen, auf welche Pods sie bieten möchten und das Feld slotinpod in ihren Bid Responses verwenden, um bestimmte Positionen innerhalb dieser Pods anzusteuern.
Es ist an der Zeit, OpenRTB 2.6 zu unterstützen und zu übernehmen
OpenRTB 2.6 ist ein großer Schritt nach vorne in Bezug auf die Möglichkeiten, die es Media Ownern, Buyern und Ad-Tech-Anbietern bietet. Es definiert die Standards für CTV neu und eröffnet einen reichhaltigen Marktplatz, der dem Fernsehen helfen wird, den wahren Wert der programmatischen Werbung zu erkennen. Und es ermöglicht letztlich ein besseres Zuschauererlebnis.
Wir haben bereits damit begonnen, OpenRTB 2.6 bei Index zu implementieren. Wir empfehlen Media Ownern und Buyern, sich unserer Unterstützung anzuschließen, da wir glauben, dass OpenRTB 2.6 bald zum Standard gehören wird.
Wenn Sie OpenRTB 2.6 besser verstehen, verwenden oder interpretieren möchten, zögern Sie bitte nicht, unser Team zu kontaktieren. Wenn Sie bereit sind, diese neuen Funktionen zu nutzen und von deren Vorteilen zu profitieren, stehen wir Ihnen zur Seite.
