Das IAB Tech Lab hat im Frühjahr diesen Jahres OpenRTB 2.6 veröffentlicht, ein bemerkenswertes Update des OpenRTB-Protokolls, das die Abwicklung des Inventars für Connected TV (CTV) verbessern soll.
Etwas mehr als ein Jahr lang hat das IAB Tech Lab mit Index Exchange und anderen führenden Unternehmen der Branche zusammengearbeitet, um Industriestandards zu entwickeln, die die häufigsten Herausforderungen im Bereich CTV lösen. Das Ergebnis ist OpenRTB 2.6, und es ist ein großer Schritt nach vorne für die digitale Werbung. Die Spezifikation berücksichtigt die Feinheiten des Fernsehens in einer programmatischen Umgebung und wird bei der Skalierung von CTV eine wichtige Rolle spielen.
Wir ermutigen alle Media Owner, Buyer und Technologieanbieter, OpenRTB 2.6 zu verwenden. Hier sind 10 neue Funktionen, auf die wir uns besonders freuen.
1. Unterstützung für Ad Podding
Jahrelang hat es unserer Branche an einem standardisierten Ansatz gefehlt, um die Verfügbarkeit von podded-Angeboten im CTV und anderen Over-the-Top (OTT)-Videos zu signalisieren. Ad Pods, d. h. Gruppen von mehreren Werbespots, die nacheinander laufen, ähneln den traditionellen linearen TV-Werbeunterbrechungen und werden häufig im CTV verwendet. Es gab jedoch keine eindeutige und einfache Möglichkeit, die TV-Werbeunterbrechungen im CTV nachzubilden, was die Beibehaltung einer wettbewerbsfähigen Trennung und die Vermeidung von Duplizierungen innerhalb eines Werbeblocks erfordert.
OpenRTB 2.6 führt Funktionen ein, die es Buyern ermöglichen, ihre Gebote auf verschiedene Positionen innerhalb eines Ad Pods auszurichten, und die es Media Ownern erlauben, einen TKP pro Sekunde als Gebotsuntergrenze festzulegen (im Gegensatz zu einer statischen Untergrenze).
Media Owner und Buyer können die TV-Werbeerlebnisse, an die sich die Verbraucher gewöhnt haben, besser nachbilden und gleichzeitig von den Targeting- und Messmöglichkeiten profitieren, die nur Programmatic bieten kann.
2. Leitfaden für die Umsetzung der flexiblen Anzeigenschaltung
OpenRTB 2.6 führt außerdem die Konzepte der strukturierten, dynamischen und hybriden Ad Pods ein, um die Anforderungen einer Reihe von verschiedenen Video- und Audioanwendungen flexibel zu erfüllen.
- Strukturierte Pods: feste Anzahl von Anzeigen, alle mit bestimmten Längen
- Dynamische Pods: feste Dauer für die Werbepause mit Flexibilität bei der Anzahl und Länge der Werbeblöcke
- Hybride Pods: Kombination von strukturierten und dynamischen Pod-Merkmalen
Die Dokumentation zu OpenRTB 2.6 enthält realistische Beispiele für CTV Bid Requests und Responses, um jede dieser Szenarien und die Verwendung der neuen Felder zu demonstrieren. Diese Implementierungsanleitung wird einen großen Beitrag zur Schaffung eines standardisierten Ansatzes für die Monetarisierung von CTV und OTT leisten, indem sie sicherstellt, dass Media Owner und Buyer die Spezifikation einheitlich auslegen.
3. Leitfaden für die Zählung von Impressionen
OpenRTB bietet zwar eine Vielzahl von Funktionen für Bid Requests und Responses, hat aber keine eindeutige Position dazu eingenommen, wie Buyer und Seller Rechnungsbenachrichtigungen behandeln sollten. Ohne einen standardisierten Ansatz neigen Media Buyer (oft unter Anleitung der MRC) dazu, die Bedingungen dafür festzulegen, wann Impressionen als geliefert und abrechenbar gelten. Dies hat zu einer Fragmentierung in der Art und Weise geführt, wie Impressionen signalisiert und gezählt werden.
OpenRTB 2.6 bietet Best Practices dafür, wie Media Owner DSP, SSP und Media Buyern abrechenbare Ereignisse sowohl in clientseitigen als auch in serverseitigen Beaconing-Szenarien anzeigen sollten. Zudem sind Anleitungen aus anderen IAB Tech Lab Standards enthalten, inklusive VAST 4.X und ads.cert, um die Widerstandsfähigkeit gegen Fraud und bösartige Akteure zu verbessern. Dieser Leitfaden standardisiert die Erwartungen und wird zu einer besseren Interoperabilität und weniger Diskrepanzen zwischen Media Ownern und Buyern führen.
4. Verabschiedung neuer Taxonomien
In früheren OpenRTB-Versionen haben Media Owner und Buyer die IAB-Taxonomie für Content-Kategorien an verschiedenen Stellen verwendet (z. B. bei der Angabe der Kategorie für eine Website oder App, für einen bestimmten Abschnitt oder eine Seite innerhalb der Website oder App oder für ausgeschlossene Kreativkategorien). Ursprünglich für das Web entwickelt, war diese Taxonomie einschränkend, da sie keine eindeutigen Deskriptoren für Inhalte, Anzeigen und Zielgruppen ermöglichte.
OpenRTB 2.6 erweitert diese Kategorisierung um das neue Feld cattax, das klarstellt, welche Taxonomie in Bid Requests und Responses verwendet wird. Media Owner und Buyer können sich auf benutzerdefinierte Taxonomien einigen oder die vom IAB Tech Lab bereitgestellten Taxonomien verwenden:
- Ad Product Taxonomy
- Audience Taxonomy
- Content Taxonomy
5. Umfangreichere Metadaten für CTV
Es gibt neue Objekte zur Darstellung des Konzepts des Netzwerks (z. B. eines Content-Lizenzgebers oder -eigentümers wie A+E Networks) und des Senders (z. B. The HISTORY Channel und Lifetime) in Bid Requests, die zur Klärung der CTV-Inventarsbeziehungen beitragen. Dieser zusätzliche Kontext hilft Buyern, den Content zu verstehen, in dem sie ihre Anzeigen platzieren, damit sie sicherstellen können, dass er am besten zu ihrer Marke passt.
6. Unterstützung für strukturierte User-Agent-Informationen
Chromium-basierte Browser (einschließlich Google Chrome und Microsoft Edge) fangen an, User-Agent-Strings einzufrieren, um das Fingerprinting von Geräten zu verhindern und die Privatsphäre der Verbraucher zu verbessern. Die Browser ersetzen stattdessen den alten User-Agent durch eine neue Reihe von HTTP-Headern und Javascript-APIs, um User-Agent Client Hints zu liefern.
Folglich können sich RTB-Buyer nicht auf die alte User-Agent-Zeichenkette verlassen, um Informationen auf Geräteebene zu erhalten, einschließlich Gerätemarke, -modell und -betriebssystem. OpenRTB 2.6 führt das Feld sua (Structured User-Agent) innerhalb des Device-Objekts ein, um Media Ownern die Möglichkeit zu geben, Informationen auf Geräteebene, die von diesen neuen User-Agent Client Hints abgeleitet sind, an Buyer zu übermitteln.
7. Bessere Erwartungshaltung für SSAI
Die Technologie der serverseitigen Werbeeinblendung (SSAI) wird häufig zur Bereitstellung von CTV-Streams verwendet, da sie ein nahtloses Zuschauererlebnis ohne Unterbrechungen zwischen Content und Werbepausen bietet. Die verschiedenen SSAI-Implementierungen gehen jedoch auf unterschiedliche Weise mit Mess- und Abrechnungsmeldungen (so genannten Beacons) um.
OpenRTB 2.6 führt ein neues ssai-Feld innerhalb des Imp-Objekts ein, das es einem Media Owner ermöglicht, SSP und DSP mitzuteilen, ob das Stitching und Beaconing von Kreativmaterialien auf der Client- oder der Serverseite erfolgt.
Dieses Signal gibt nicht nur Aufschluss über die Qualität des Zuschauererlebnisses, sondern auch über möglichen Fraud. Wenn beispielsweise ein Media Owner angibt, dass die Beacons vom Client stammen sollen, sollten SSP und DSP skeptisch gegenüber Abrechnungsmeldungen sein, die von einem Server oder der IP eines Rechenzentrums stammen.
8. Unterstützung für Rewarded Ads
Media Owner und Buyer verließen sich bisher auf eine Reihe nicht standardisierter Erweiterungen, um Möglichkeiten für Rewarded Ads zu signalisieren, bei denen Verbraucher eine Werbeanzeige ansehen und dafür im Gegenzug eine Belohnung erhalten, z. B. in Form einer Spielwährung. Die OpenRTB 2.6 Spezifikation führt einen standardisierten Weg ein, um zu bestätigen, dass jede Art von Impression eine belohnte Erfahrung sein kann, indem das Feld rwdd zum Imp-Objekt hinzugefügt wird.
9. Weitere hilfreiche Bid Responses im Audio- und Videobereich
In früheren Versionen von OpenRTB mussten Media Owner den Inhalt des Ad- Markup-Feldes (adm) überprüfen, um den Kreativtyp in einem Bid Response zu bestimmen. Dies war eine besondere Herausforderung bei Anfragen mit mehreren Formaten, die für Banner-, Video- oder native Bid Responses in Frage kamen. Bei Video- oder Audioanzeigen mussten die Media Owner auch das Markup (ein VAST-Dokument, das oft ein Wrapper für eine andere VAST war) analysieren, um die Dauer des Kreativmaterials zu bestimmen.
Mit zwei neuen Feldern im Bid-Objekt in OpenRTB 2.6 können Buyer den Media Ownern diese Arbeit abnehmen, so dass neue Kreativmaterialen schneller bedient werden können:
- dur: gibt die Dauer des Video- oder Audiokreativs im Gebot eines Buyer an
- mtype: gibt die Art des Werbemittels (Banner, Video, Audio, Native) im Gebot eines Buyers an
10. Listen beziehen sich jetzt auf AdCOM 1.0
Alle Aufzählungen (Listen) für Attribute in OpenRTB 2.6 Objekten verweisen nun auf die AdCOM 1.0 GitHub. Eines der Probleme mit 2.5 war, dass die Aktualisierung veralteter Listen die Veröffentlichung einer völlig neuen Version der Spezifikation erforderte. Die Verwendung des AdCOM GitHub für Listen bedeutet, dass die Ad-Tech-Community im Laufe der Zeit Werte hinzufügen oder ändern kann, unabhängig davon, ob die OpenRTB-Spezifikation aktualisiert wird oder nicht.
Das Wachstum von CTV wurde durch das Fehlen branchenweiter Standards und programmatischer Tools, die auf die Besonderheiten des Fernsehens abgestimmt sind, gebremst. OpenRTB 2.6 korrigiert dies und schafft eine Standardisierung für eine Vielzahl neuer Funktionen, die den Weg für die CTV-Anzeigen der Zukunft ebnen werden.
Nun, da die Standards definiert sind, ist es an der Zeit, dass der Markt sie so schnell wie möglich unterstützt und übernimmt.
Welche Auswirkungen hat die OpenRTB 2.6-Spezifikation seit ihrer Veröffentlichung im Jahr 2022 auf die Streaming-TV-Landschaft gehabt? Lesen Sie unser neuestes Update dazu.
