Connected TV in Ihrer DSP oder SSP: Was sich ändert und was Sie selbst bauen sollten

Anzeigen auf Connected TV (CTV) sind Videoanzeigen, die auf internetfähigen Fernsehern laufen, meist in einer Werbepause aus mehreren Anzeigen innerhalb einer Streaming-App. Eine DSP oder SSP, die für Banner im Web und in Apps gebaut wurde, muss sich an vier Stellen ändern, um sie zu verarbeiten. Der Bid Request beschreibt eine ganze Werbepause statt eines einzelnen Werbeplatzes. Die Anzeige kommt als VAST-Antwort, also als XML-Dokument, das auf die Videodateien verweist. Viele TV-Apps können Anzeigen nicht so anfordern und tracken wie ein Browser, deshalb fügt ein Stitching-Dienst die Anzeige in den Stream ein. Dieser Dienst sendet dann die Ad Requests und oft auch die Tracking-Aufrufe im Namen des Fernsehers, daher müssen Sie Geräte anders identifizieren und Impressions anders zählen. Es lohnt sich, das Bieten auf Werbepausen und die VAST-Unterstützung in die eigene Plattform einzubauen. Das Stitching gehört zum Publisher oder zu einem Dienst, der für diese Aufgabe gebaut ist.

Was ist an Anzeigen auf Connected TV anders?

Auf einer Website fragt ein Ad Request meist eine Anzeige für einen Werbeplatz an, und der Browser lädt diese Anzeige und meldet die Impression. Auf einem Fernseher sieht der Zuschauer eine Sendung in einer Streaming-App, und die Anzeigen kommen in Werbepausen, wie im klassischen Fernsehen. Das IAB Tech Lab, das Gremium, das das Bidding-Protokoll OpenRTB pflegt, nennt eine solche Werbepause einen Ad Pod: eine oder mehrere Anzeigen, die „innerhalb eines Streams von Video- oder Audioinhalten unmittelbar hintereinander abgespielt werden“.

Die Spezifikation OpenRTB 2.6 des IAB Tech Lab beschreibt Version 2.6 als diejenige, die „Ad Pods für CTV-Transaktionen einführt“. Dieser Artikel stützt sich auf diese Spezifikation und auf die Implementierungshinweise des IAB Tech Lab dazu, abgerufen am 2. November 2026 wie die anderen Quellen hier.

Wie kommt eine Werbepause im Bid Request an?

In OpenRTB 2.6 kommt eine Werbepause als ein oder mehrere Impression-Objekte im Bid Request an, und Impression-Objekte mit derselben podid gehören zur selben Werbepause. Die Implementierungshinweise beschreiben drei Arten von Werbepausen:

• Strukturiert: Der Verkäufer legt die Zahl der Plätze, ihre Reihenfolge und die Länge jedes Platzes im Voraus fest, und jeder Platz ist ein eigenes Impression-Objekt
• Dynamisch: Der Verkäufer legt die Gesamtlänge und die maximale Zahl der Anzeigen fest, aber weder die Zahl noch die Länge der einzelnen Anzeigen, und die ganze Werbepause kann als ein einziges Impression-Objekt ankommen
• Hybrid: Ein Teil der Werbepause ist fest, ein Teil dynamisch

Die meisten Banner-Plattformen mussten die folgenden Felder noch nie lesen:

• poddur, die Gesamtzahl der Sekunden, die Advertiser in einer dynamischen Werbepause füllen dürfen, und maxseq, die größte Zahl von Anzeigen, die sie enthalten darf
• rqddurs, eine Liste exakter Anzeigenlängen. Laut der Spezifikation ist das Feld für Live-TV gedacht, „wo nicht exakte Anzeigenlängen zu unerwünschten ‚Sendelöchern‘ führen würden“
• slotinpod, das angibt, ob der Verkäufer den ersten oder letzten Platz garantieren kann, und podseq, die Position der Werbepause in der Sendung
• mincpmpersec, ein Mindestpreis (Price Floor) pro Sekunde Werbezeit für den dynamischen Teil einer Werbepause

Jedes Gebot gibt die Länge seiner Anzeige im Feld dur an. Die Implementierungshinweise sagen außerdem, dass Käufer „davon ausgehen sollten, dass die endgültige Zusammenstellung des Pods durch den Verkäufer erfolgt“. Wenn Sie mehrere Gebote für eine Werbepause senden, kann der Verkäufer beliebig viele davon verwenden, von keinem bis zu allen, und sie mit Anzeigen anderer Käufer mischen.

Senden Sie mit jedem Gebot die Domain des Advertisers (adomain) und die ID des Creatives (crid). Die Spezifikation führt beide unter den Attributen auf, die „für Prüfungen der Anzeigenqualität oder die Durchsetzung von Publisher-Beschränkungen“ verwendet werden.

Für eine DSP verändern Werbepausen die Gebotslogik. Ein Banner-Bidder bepreist jeweils eine Impression. Ein CTV-Bidder muss auswählen, welche seiner Anzeigen in die verbleibende Zeit der Werbepause passen, und sie pro Sekunde bepreisen, und er kann nicht steuern, welche davon der Verkäufer behält.

Was muss die VAST-Antwort enthalten?

Videoanzeigen werden mit VAST ausgeliefert, das das IAB Tech Lab als „ein universelles XML-Schema für die Auslieferung von Anzeigen an digitale Videoplayer“ beschreibt. Seine VAST-Seite, zuletzt im Juli 2024 aktualisiert, nennt VAST 4.3 vom Dezember 2022 als neueste Version. Das Repository für VAST 4.x des IAB Tech Lab auf GitHub enthält außerdem VAST 4.4, das laut einem Hinweis eines Maintainers dort am 22. Juli 2026 veröffentlicht wurde. VAST 4.4 ergänzt CTV-Formate wie Anzeigen beim Pausieren und als Bildschirmschoner. Die folgenden Zitate stammen aus VAST 4.3.

Im Juli 2024 veröffentlichte das IAB Tech Lab außerdem ein CTV-Addendum, das die Creative-ID und die Mezzanine-Datei von VAST 4 in die älteren Versionen VAST 2 und 3 bringt. Das Addendum sagt, dass diese früheren Versionen „den Markt noch heute dominieren“.

Auf dem Fernseher sind zwei Teile von VAST am wichtigsten:

• Eine Mezzanine-Datei, „die rohe, hochwertige Videodatei“, aus der die Systeme des Publishers eine Version für jeden Bildschirm erstellen. VAST 4.3 sagt, dass eine Mezzanine-Datei „bei Ausspielungen mit Ad Stitching erforderlich ist“ und dass ein Stitching-Dienst eine Antwort ohne sie ablehnen kann
• Eine UniversalAdId, ein Identifier, der das Creative von System zu System begleitet. VAST 4.3 verlangt sie für lineare Anzeigen, also solche, die innerhalb der Sendung laufen, und das Addendum ergänzt sie für VAST 2 und 3 als Extension. Stitching-Dienste erkennen daran, ob sie ein Creative bereits konvertiert haben

Im Stitching-Prozess, den VAST 4.3 beschreibt, muss ein Creative, das der Dienst noch nie gesehen hat, erst konvertiert werden, bevor es laufen kann, deshalb läuft in der Werbepause an seiner Stelle eine andere Anzeige. VAST 4.3 merkt an, dass der erste Download einer Mezzanine-Datei „mehrere Stunden dauern kann“. AWS beschreibt dieselbe Regel für MediaTailor, seinen Cloud-Dienst, der Anzeigen in Streams einfügt: „Wenn eine Anzeige noch nicht passend zum Inhalt transkodiert wurde, überspringt MediaTailor ihre Einfügung“, und die Anzeige wird für die nächste Anfrage vorbereitet.

Ein neues Creative kann deshalb bei jedem Stitching-Dienst seine ersten Gelegenheiten zur Ausspielung verpassen. Laut VAST 4.3 sollte ein Creative, das in irgendeiner Weise geändert wird, einen neuen Identifier bekommen. Ändern Sie den Identifier nicht, solange das Creative selbst unverändert ist, damit jeder Stitching-Dienst es nur einmal konvertiert.

Für Verifizierungscode empfiehlt VAST 4.3 Open Measurement (OMID) und rät „dringend von der Verwendung von VPAID ab“, also von der älteren Methode, Code innerhalb einer Videoanzeige auszuführen. Als Ersatz für VPAID bei interaktiven Anzeigen nennt es SIMID. VAST 4.3 hält interaktiven Code von der Videodatei getrennt, damit Player, die mit einem Stitching-Dienst arbeiten, das Video auch dann abspielen können, wenn sie den Code nicht ausführen können. Stellen Sie sicher, dass jedes TV-Creative auch als reines Video funktioniert.

Was ändert sich, wenn ein Server die Anzeige in den Stream einfügt?

Viele TV-Apps können Anzeigen nicht so anfordern und tracken wie ein Browser. VAST 4.3 beschreibt die Alternative, die serverseitige Anzeigeneinfügung (Server-Side Ad Insertion, SSAI) oder Ad Stitching heißt. Die App fordert den Stream bei einem Stitching-Dienst an, der Dienst fordert Anzeigen beim Ad Server an, und die Anzeigen werden in den Inhalt eingefügt, sodass der Zuschauer „einen durchgehenden Stream“ erhält.

OpenRTB 2.6 ergänzt das Impression-Objekt um ein Feld ssai, das angibt, wie viel vom Stitching und Tracking auf einem Server stattfindet. Seine Werte reichen von „vollständig clientseitig“ bis „vollständig serverseitig“. Im mittleren Fall erfolgt das Stitching des Videos auf dem Server, und die Tracking-Pixel werden vom Gerät ausgelöst. Der Standardwert 0 bedeutet, dass der Status unbekannt ist, ein Request ohne das Feld sagt Ihnen also weder das eine noch das andere.

Wenn die Ad Requests und die Tracking-Aufrufe von einem Server kommen, scheinen sich viele Zuschauer eine IP-Adresse zu teilen. VAST 4.3 warnt: „Für einen Ad Server, der Tracking-Informationen empfängt, sehen die Meldungen ähnlich aus wie ungültiger Traffic.“ Laut VAST 4.3 müssen Stitching-Anbieter die IP-Adresse und den User Agent des Geräts in zwei Headern, X-Device-IP und X-Device-User-Agent, mit ihren Tracking-Requests senden, und diese Werte müssen mit denen im ursprünglichen Ad Request übereinstimmen.

Für Ihre Plattform bedeutet das:

• Wenn Traffic über einen Stitching-Dienst kommt, entnehmen Sie die Gerätedaten diesen Headern und dem Bid Request. Die IP-Adresse, die sich dann mit Ihnen verbindet, gehört dem Stitching-Dienst, verwenden Sie sie also nicht für das Gerät
• Fragen Sie den Verkäufer nach jeglichem serverseitigen Traffic, der ohne die X-Device-Header ankommt
• Prüfen Sie, ob der Verkäufer in der app-ads.txt-Datei des Publishers aufgeführt ist. Die Spezifikation des IAB Tech Lab erweitert ads.txt auf Apps aus „App-Stores für Connected Television“
• Stützen Sie Frequency Caps und Zielgruppen auf Geräte-IDs. VAST 4.3 merkt an, dass ein Stitching-Dienst „nicht auf Cookies zugreifen kann“. In OpenRTB 2.6 trägt das Feld ifa eine Werbe-ID, von der erwartet wird, dass sie vom Betriebssystem des Geräts stammt, und das Feld lmt gibt an, wann Tracking eingeschränkt werden muss

Wie werden Impressions gezählt und abgerechnet?

Die Implementierungshinweise zu OpenRTB vergleichen die Wege, abrechenbare Events zu zählen. Für Audio und Video empfehlen sie das Impression-Event von VAST. Die Billing-Notice-URL (burl), die für Banner gut funktioniert, ist „für Audio/Video nicht empfohlen“.

Die Hinweise raten Biddern außerdem, die Verzögerung zwischen der Auktion und der Billing Notice zu verfolgen, weil Ausgabenziele, Frequency Caps und Pacing davon abhängen. In ihrer Tabelle angemessener Verzögerungen steht in der Zeile für Audio oder Video mit serverseitigem Stitching „Sehr lang oder unbekannt“.

Mit dem Feld exp gibt der Verkäufer im Request an, wie viele Sekunden zwischen der Auktion und der Impression vergehen dürfen, und der Käufer gibt im Gebot an, wie viele Sekunden er zu warten bereit ist. Beide Werte sind nur Empfehlungen. Die Hinweise warnen Bidder davor anzunehmen, dass eine Billing Notice, die nach dem exp ihres Gebots eintrifft, nicht abgerechnet wird, denn das ist eine Frage des Vertrags mit der Exchange.

Serverseitiges Stitching hat die Zählregeln nicht verändert. VAST 4.3 zitiert die gemeinsam mit dem Media Rating Council (MRC) entwickelten Measurement Guidelines des IAB: „Die Measurement Guidelines verlangen, dass die Zählung von Anzeigen einem clientinitiierten Ansatz folgt“. Dieselbe Passage erlaubt die Zählung auf einem Server, „sofern sie auf Grundlage clientseitiger Events und Messressourcen ausgelöst wird“. Sie lehnt eine Zählung ab, die ein Server von sich aus startet, weil diese „am weitesten davon entfernt ist, dass der Nutzer die Anzeige tatsächlich sieht“. Fragen Sie jeden Verkäufer, welches Event seine Impression-Zählung startet, wenn ein Server die Anzeige in den Stream einfügt.

Was sollten Sie selbst bauen, und was erledigen Partner bereits?

Manche Teile eines CTV-Setups gehören zum Publisher oder zu Diensten, die für Publisher gebaut sind. Das Stitching selbst ist einer davon. MediaTailor zum Beispiel sendet die Daten des Zuschauers an den Ad Decision Server, erhält die ausgewählten Anzeigen in der Antwort des Ad Servers und fügt sie in den Stream ein. Das Konvertieren von Videodateien in das Format jedes Publishers gehört zur selben Aufgabe.

Andere Teile entscheiden darüber, was Ihre Plattform verdient, und es lohnt sich, sie selbst zu bauen:

• Für eine DSP: auswählen, welche Anzeigen in eine Werbepause passen, und sie pro Sekunde bepreisen
• Für eine DSP: Pacing der Budgets, wenn Billing Notices spät eintreffen
• Für eine DSP: Creatives mit einer Mezzanine-Datei und einer Creative-ID ausliefern, die sich nur ändert, wenn sich das Creative ändert, im Element UniversalAdId von VAST 4 oder in der Extension des Addendums für VAST 2 und 3
• Für eine SSP: jede Werbepause aus den Geboten mehrerer Käufer zusammenstellen und die Regeln des Publishers anwenden, welche Advertiser erscheinen dürfen
• Für eine SSP: die Pod-Felder und den Wert von ssai an jeden Käufer weitergeben
• Für beide: Gerätedaten aus den X-Device-Headern lesen und ungültigen serverseitigen Traffic filtern
• Für beide: Impressions so zählen, dass Käufer und Prüfer es akzeptieren

Eine DSP, die nur testen will, ob ihre Advertiser CTV wollen, kann mit ein oder zwei SSPs beginnen, die CTV bereits verkaufen, und zunächst auf strukturierte Werbepausen bieten. Fragen Sie diese SSPs, welcher Anteil ihres CTV-Inventars als dynamische Werbepausen kommt, denn die Implementierungshinweise ermutigen Verkäufer, nach Möglichkeit dynamische Pods anzubieten. Live-TV mit seinen exakten Anzeigenlängen kann warten, bis die ersten Kampagnen zeigen, dass Advertiser es wollen.

Bauen Sie alles aus der Liste oben, wenn CTV zu einem dauerhaften Anteil Ihres Umsatzes wird. Dasselbe gilt, wenn Sie eigene Deals mit TV-Publishern abschließen oder wenn die Art, wie ein Partner Werbepausen handhabt, immer wieder darüber entscheidet, welche Ihrer Gebote laufen.

Was sollten wir eine Firma fragen, die CTV in unsere Plattform einbaut?

• Welche Pod-Felder aus OpenRTB 2.6 wird das System lesen, und wie wählt es Anzeigen für eine dynamische Werbepause aus?
• Wie bepreist das System Gebote pro Sekunde, und hält es mincpmpersec ein?
• Welche VAST-Versionen werden unsere Creatives nutzen, und woher kommen die Mezzanine-Dateien?
• Werden unsere Creatives registrierte UniversalAdIds tragen oder den Standardwert „unknown“?
• Wie geht das System mit serverseitigem Traffic um, und woher nimmt es die IP-Adresse und den User Agent des Geräts?
• Wie werden Impressions bei jedem Verkäufer gezählt?
• Wie bleibt das Pacing genau, wenn Billing Notices sehr spät eintreffen?
• Mit welchen Partnern testen wir zuerst, und welche Funktionen können warten?

Wo passt amBrain ins Bild?

Im Bereich AdTech arbeitet amBrain an DSP-Entwicklung, Real-Time-Bidding-Plattformen und Ad-Exchange-Engineering. Zwei Zeilen in seiner Liste von Leistungen lauten: „amBrain baut Supply-Side-Platforms (SSP) für Publisher.“ und „amBrain baut Ad Server: Targeting, Frequency Capping und Reporting.“ RTBBidder ist eine Demand-Side-Platform, die amBrain für einen Kunden gebaut hat.

amBrain entwickelt seit 2019 Software. Es arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. Zum Eigentum lautet sein Satz: „Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen unsere wiederverwendbaren Komponenten.“

Dieser Artikel ist keine Case Study. Abgesehen von der Nennung von RTBBidder beschreibt er keine Arbeit für Kunden: Er sagt nicht, dass amBrain Connected TV in irgendeine Plattform eingebaut hat, und er nennt weder Zahlen zu RTBBidder noch Preise oder Zeitpläne von amBrain. Das IAB Tech Lab und AWS werden aus ihren eigenen Dokumenten zitiert, und der Artikel behauptet keine Beziehung zwischen amBrain und einem von beiden. Wenn amBrain auf Ihrer Shortlist steht, stellen Sie ihm dieselben Fragen wie jeder anderen Firma.