Was ist ein Bid Request? Aufbau eines OpenRTB Bid Requests für Advertiser

Jede programmatische Impression, die Sie jemals eingekauft haben, begann als kleiner Datenblock, der an Ihre Plattform gesendet und in Sekundenbruchteilen beantwortet wurde. Dieser Datenblock ist der Bid Request. Er beschreibt den Werbeplatz, die Website oder App, auf der er sich befindet, das Gerät, auf dem er angezeigt wird, alles, was über die Person vor dem Bildschirm bekannt ist, sowie die rechtlichen Bedingungen, die an den Einkauf geknüpft sind.

Die meisten Media Buyer bekommen nie einen zu Gesicht. Sie arbeiten mit Kampagneneinstellungen – Geo, Gerät, Format, Gebot – und vertrauen darauf, dass die Plattform diese Einstellungen den richtigen Opportunities zuordnet. Das funktioniert so lange, bis die Performance ohne erkennbaren Grund einbricht oder eine Targeting-Regel stillschweigend den Großteil des zugesagten Inventars ausschließt – und der Kampagnenbericht keine Erklärung liefert.

Dieser Leitfaden erklärt, was ein Bid Request tatsächlich enthält, wie die OpenRTB-Objekte den Einstellungen entsprechen, die Sie bereits nutzen, was Ihre Plattform zurücksenden muss, um zu gewinnen, und warum die in einem Request vorhandenen Felder darüber entscheiden, wie viel des Marktes Ihre Kampagnen erreichen können.

Was ist ein Bid Request in der programmatischen Werbung?

Ein Bid Request ist eine strukturierte Nachricht, die eine Supply-Side-Plattform oder Exchange an eine Demand-Side-Plattform sendet. Sie bietet eine einzelne Werbemöglichkeit an und fragt nach einem Preis. Gesendet wird sie, wenn eine Seite lädt oder eine App einen Werbeplatz öffnet, und sie erwartet eine Antwort innerhalb einer Frist, die in Millisekunden gemessen wird.

Das branchenübliche Format für diese Nachricht ist OpenRTB, eine Spezifikation, die vom IAB Tech Lab gepflegt wird. Sie definiert eine JSON-Struktur mit benannten Objekten, sodass ein von einer Exchange erstellter Request von jedem konformen Käufer gelesen werden kann – ohne individuelle Integration für jeden einzelnen Partner. Ohne dieses gemeinsame Vokabular würde die Anbindung von tausend Supply-Quellen bedeuten, tausend Parser zu schreiben.

Entscheidend ist: Ein Bid Request ist ein Angebot, keine Auslieferung. Einen Request zu empfangen kostet nichts. Ihn zu beantworten verpflichtet Sie zu einem Preis. Alles, was Ihre Plattform entscheidet – ob sie bietet, wie viel und mit welchem Werbemittel –, wird anhand des Inhalts dieser einen Nachricht entschieden, ergänzt um das, was Ihre Plattform bereits über die Kampagne und den Nutzer weiß.

Woher ein Bid Request kommt

Die Kette beginnt beim Publisher. Ein Nutzer öffnet eine Seite oder App, ein Werbeplatz wird verfügbar, und der Ad Server oder Header-Bidding-Wrapper des Publishers beauftragt eine Supply-Side-Plattform mit der Monetarisierung. Die SSP erstellt einen OpenRTB Bid Request, der die Opportunity beschreibt, und sendet ihn an die angebundenen Demand-Partner.

Ihre DSP empfängt diesen Request als einen von vielen, die jede Sekunde eintreffen. Sie parst den Request, gleicht ihn mit jeder infrage kommenden Kampagne ab, wendet Filter an, berechnet ein Gebot und gibt eine Bid Response zurück – oder gar nichts, was eine gültige und sehr häufige Antwort ist. Die SSP sammelt die Antworten, führt die Auktion durch und teilt dem Gewinner mit, dass er gewonnen hat.

Die Frist legt der Verkäufer fest. Die meisten Requests enthalten einen tmax-Wert: die maximale Zeit in Millisekunden, die die Exchange auf Ihre Antwort wartet. Typische Werte liegen im niedrigen dreistelligen Bereich. Eine Antwort, die nach Ablauf von tmax eintrifft, wird verworfen – selbst wenn sie das höchste Gebot war. Damit ist Latenz ein kommerzielles und nicht nur ein technisches Thema. Hier wird auch das Request-Volumen zur Grenze: Ist die Queries-per-Second-Kapazität Ihrer Plattform gedeckelt, werden Requests schon an der Tür abgewiesen, bevor überhaupt eine Bidding-Logik greift. Deshalb ist unbegrenztes QPS für Plattformbetreiber so wichtig.

Die vollständige Auktionsmechanik – wie der Gewinnerpreis ermittelt wird und wie Benachrichtigung und Werbemittel ausgeliefert werden – behandeln wir ausführlicher in unserer Schritt-für-Schritt-Erklärung, wie Real-Time Bidding funktioniert. Dieser Artikel konzentriert sich auf den Request selbst.

Der Aufbau eines OpenRTB Bid Requests

Ein OpenRTB Bid Request ist ein JSON-Objekt mit einer Kennung auf oberster Ebene und einer Reihe verschachtelter Objekte, von denen jedes eine Dimension der Opportunity beschreibt. Nicht jedes Objekt ist in jedem Request enthalten. Was vorhanden ist und wie vollständig es befüllt ist, unterscheidet sich zwischen den Supply-Quellen enorm.

Zwei davon verdienen besondere Aufmerksamkeit, da sie von Käufern am häufigsten missverstanden werden.

Das erste ist die Wahl zwischen site und app. Ein Request enthält entweder das eine oder das andere, niemals beides – und diese eine Entscheidung bestimmt, welche Kennungen verfügbar sind, welche Werbeformate infrage kommen und welche Verifizierungsdatei gilt. App-Inventar gut einzukaufen ist eine andere Disziplin als der Einkauf im Web. Deshalb behandeln wir das Thema separat in unserem Leitfaden zu In-App Programmatic Advertising.

Das zweite sind bcat und badv. Dabei handelt es sich um die eigenen Ausschlüsse des Verkäufers – blockierte Content-Kategorien und blockierte Advertiser-Domains –, die auf Verkäuferseite durchgesetzt werden. Taucht die deklarierte Kategorie oder Advertiser-Domain Ihres Werbemittels in diesen Listen auf, wird Ihr Gebot verworfen, nachdem Sie es abgegeben haben. Sie zahlen nichts, erfahren aber auch nichts aus dem Kampagnenbericht, denn ein abgelehntes Gebot sieht in der Regel genauso aus wie eine verlorene Auktion.

Das Impression-Objekt: Was Sie tatsächlich kaufen

Das imp-Objekt ist der kommerzielle Kern des Requests. Ein Request kann mehrere Impression-Objekte enthalten, wenn eine Seite mehrere Werbeplätze gleichzeitig anbietet; auf jedes wird unabhängig geboten. Darin deklariert eines von vier Unterobjekten das Format: banner, video, audio oder native. Ihre Plattform kann nur antworten, wenn sie über ein Werbemittel verfügt, das dem deklarierten Format und den akzeptierten Abmessungen entspricht.

Neben dem Format enthält das Impression-Objekt die Felder, die über die Wirtschaftlichkeit entscheiden:

• bidfloor und bidfloorcur – das minimal akzeptierte Gebot und die Währung, in der es angegeben ist. Liegt Ihr Gebot unter dem Floor, wird es einfach verworfen.
• tagid – die Kennung des Verkäufers für die konkrete Platzierung, die Reporting und Blocking auf Platzierungsebene erst ermöglicht.
• secure – ob die Impression ein HTTPS-Werbemittel erfordert. Wird ein unsicheres Asset in eine sichere Seite ausgeliefert, blockiert der Browser die Anzeige, nachdem Sie bereits bezahlt haben.
• instl – ob es sich bei dem Platz um ein Vollbild-Interstitial statt um eine In-Page-Einheit handelt.
• pmp – etwaige Private-Marketplace-Deals, die an diese Impression geknüpft sind, jeweils mit eigener Deal-ID und eigenem Floor.

Das pmp-Feld lohnt einen zweiten Blick. Erscheint in einem Request eine Deal-ID, die zu einem Deal Ihrer Kampagne passt, konkurriert diese Impression in der Regel in einer kleineren Auktion zu besseren Konditionen als im Open Market. Eine Plattform, die das pmp-Objekt ignoriert, bietet auf Deal-Inventar zu Open-Market-Preisen und schöpft den Vorteil, für den sie bezahlt hat, nie aus.

Identität, Datenschutz und fehlende Felder

Im user-Objekt ist der zielgruppenbasierte Einkauf angesiedelt. Es kann die eigene Nutzerkennung der Exchange enthalten, eine mit Ihrer Plattform synchronisierte Buyer-seitige Kennung sowie Zielgruppensegmente von Datenpartnern. Bei mobilem App-Inventar ist die dauerhafte Kennung meist die Advertising ID im device-Objekt und nicht etwas im user-Objekt.

Diese Felder fehlen immer häufiger. Browser schränken Third-Party-Cookies ein, mobile Plattformen verlangen ein ausdrückliches Opt-in, bevor eine Advertising ID weitergegeben wird, und Nutzer, die ablehnen, erzeugen Requests, in denen die Kennung genullt oder vollständig entfernt ist. Der Request kommt trotzdem an. Er lässt sich nur nicht personalisieren.

Das regs-Objekt nennt die rechtlichen Bedingungen. Es kennzeichnet, ob der Request unter die DSGVO fällt, ob Regeln für kindgerichtete Angebote gelten und welches Datenschutzsignal anzuwenden ist; der Consent-String selbst wird als Extension im user-Objekt übermittelt. Ein Request ohne gültige Einwilligung kann dennoch eingekauft werden – allerdings nur kontextuell, anhand von Seite, Format und Gerät, ohne jegliche personenbezogene Daten.

Das hat unmittelbare Folgen für Kampagnen. Eine eng getargetete Zielgruppenkampagne kommt nur für den Teil der Requests infrage, der noch eine verwertbare Identität enthält. Liefert eine Kampagne trotz reichlich Restbudget zu wenig aus, liegt die Ursache oft nicht beim Gebot, sondern beim Filter: Dem Großteil des verfügbaren Inventars fehlte schlicht das Feld, das die Targeting-Regel voraussetzt. Bei der Frequenzsteuerung stößt man an dieselbe Grenze: Ein Cap, der darauf beruht, dieselbe Person ein zweites Mal zu erkennen, lässt sich bei Requests mit anonymen Personen nicht durchsetzen.

Den Supply Path im Request lesen

Das source-Objekt beantwortet eine Frage, die sich jeder Käufer stellen sollte: Wer verkauft diese Impression eigentlich? Es enthält eine Transaktions-ID, die den Request über die gesamte Kette hinweg einer einzigen Auktion zuordnet, sowie das Supply-Chain-Objekt – eine geordnete Liste aller Akteure, die die Impression zwischen dem Publisher und Ihnen gehandhabt haben.

Eine Supply Chain mit einem Knoten bedeutet, dass Sie direkt über das eigene Seller-Konto des Publishers einkaufen. Drei oder vier Knoten bedeuten, dass die Impression weiterverkauft wurde, wobei jeder Zwischenhändler einen Anteil dessen einbehält, was Sie zahlen. Die Kette ist zudem der Mechanismus, mit dem Sie überprüfen können, ob der Verkäufer überhaupt berechtigt ist, dieses Inventar zu verkaufen – abgeglichen mit den eigenen Angaben des Publishers. Mehr dazu in unserem Leitfaden zu ads.txt, app-ads.txt und sellers.json.

Dieses Feld konsequent auszuwerten, ist die praktische Grundlage jeder Supply-Path-Arbeit. Zwei Requests können denselben Nutzer auf derselben Seite im selben Moment beschreiben und dennoch über unterschiedliche Reseller zu unterschiedlichen Floors eintreffen. Den kürzeren, günstigeren Weg zu wählen, ist nur möglich, wenn Ihre Plattform die Kette bei jedem Request speichert, statt sie zu verwerfen.

Was Ihre Plattform zurücksendet

Eine Bid Response ist deutlich kleiner als der Request. Sie gibt die Request-ID zurück und enthält dann einen oder mehrere Seat Bids, die wiederum die eigentlichen Gebote enthalten. Jedes Gebot muss die Impression benennen, auf die es antwortet, sowie einen Preis und das auszuliefernde Werbemittel.

Sich gegen ein Gebot zu entscheiden, ist ebenfalls eine Antwort, und OpenRTB sieht dafür einen No-Bid-Reason-Code vor. Diese Codes sind das am wenigsten genutzte Diagnosewerkzeug im programmatischen Einkauf. Wenn ein Supply-Partner zurückmeldet, warum Ihre Plattform abgelehnt hat – kein Nutzer-Match, blockierter Publisher, unter dem Floor, nicht unterstütztes Format –, erhalten Sie eine präzise Übersicht darüber, wo Ihre Kampagne an Reichweite verliert, statt nur zu raten.

So nutzen Sie Bid-Request-Daten als Käufer

Sie müssen kein rohes JSON lesen, um vom Verständnis des Requests zu profitieren. Ihre Plattform muss jedoch über die Felder berichten, damit Kampagnenentscheidungen auf Basis dessen getroffen werden, wie das Inventar tatsächlich aussieht – und nicht, wie Sie es vermuten.

1. Prüfen Sie die Verfügbarkeit der Felder, bevor Sie Targeting aufsetzen. Fragen Sie, welcher Anteil der eingehenden Requests eine verwertbare Kennung, einen Standort auf Stadtebene oder ein deklariertes App-Bundle enthält. Targeten Sie auf Felder, die tatsächlich vorhanden sind.
2. Vergleichen Sie Floors nach Platzierung, nicht nach Partner. Die tagid zeigt Ihnen, welche konkreten Werbeplätze teuer sind. Ein über eine ganze Exchange gemittelter Floor verschleiert die Platzierungen, die den Wert verzerren.
3. Behalten Sie die No-Bid-Gründe im Blick. Lehnt eine Kampagne die meisten Requests aus einem einzigen Grund ab, ist das ein Konfigurationsproblem und kein Marktproblem – und meist in wenigen Minuten behoben.
4. Verfolgen Sie die Länge der Supply Chain. Erreicht Sie dieselbe Domain über mehrere Wege, behalten Sie den kurzen und testen Sie, die übrigen abzuschalten.
5. Stimmen Sie Werbemittel auf die deklarierten Formate ab. Secure-only-Plätze, Interstitials und Native-Platzierungen erfordern jeweils Assets, die bereitstehen müssen, bevor der Request eintrifft – nicht danach.

Warum der Zugriff auf Bid Requests davon abhängt, wem die Plattform gehört

Alles oben Beschriebene findet innerhalb der Demand-Side-Plattform statt. Ob Sie es sehen können, hängt vom Reporting der Plattform ab – und genau darin liegt der Unterschied zwischen dem Mieten des Zugangs zu einer DSP und dem Besitz einer eigenen. Den Unterschied zwischen Einkaufs- und Verkaufsseite dieses Austauschs erläutern wir in unserem Beitrag zu DSP vs. SSP.

Bei einem gemieteten Seat sehen Sie die Felder, die der Anbieter freigibt. Fill Rates auf Feldebene, Aufschlüsselungen der No-Bid-Gründe und Supply-Chain-Daten werden häufig wegaggregiert, sodass aus einer Diagnose, die eine einzige Abfrage erfordern würde, ein Support-Ticket wird. Zudem übernehmen Sie die Anbindungsliste des Anbieters: Ist ein Supply-Partner nicht integriert, erreichen Sie dessen Requests nie, und eine Anbindung können Sie lediglich anfragen.

Bei einer eigenen Plattform gehört der Request-Stream Ihnen. Sie entscheiden, welche Felder protokolliert werden, welche Reports Sie erstellen, welche Partner Sie integrieren und wie viel Request-Volumen Sie annehmen. Eine Supply-Quelle hinzuzufügen ist eine technische Aufgabe unter Ihrer Kontrolle statt einer kommerziellen Verhandlung – die praktischen Schritte finden Sie in unserer Checkliste zur SSP-Integration.

Bereit, die Plattform zu besitzen, die Ihre Bid Requests liest?

AdTech Europe liefert Enterprise-Technologie für Demand-Side-Plattformen an Agenturen, Ad Networks, Media-Buying-Teams und AdTech-Unternehmer, die ihren Einkaufs-Stack lieber besitzen als mieten. Jedes Paket umfasst unbegrenzte QPS-Skalierung, über 1.000 SSP-Integrationen, White-Label-Branding und lebenslang kostenlose Upgrades – so wird der Request-Stream, der Ihre Plattform erreicht, durch Ihre kommerziellen Entscheidungen begrenzt und nicht durch ein Seat-Kontingent.

Stand September 2026 stehen folgende Optionen zur Wahl: eine gemanagte White Label DSP für $500 pro Monat ohne Einrichtungsgebühr, eine DSP License für einmalig $25,000 oder eine vollständige DSP Acquisition mit kompletter Source-Code-Eigentümerschaft für einmalig $50,000. Für die beiden Eigentumsmodelle sind Ratenzahlungen möglich – aktuelle Preise finden Sie stets auf der DSP-Preisseite. Wenn Sie sehen möchten, wie Ihr eigener Bid-Request-Stream aussehen würde, vereinbaren Sie ein Strategiegespräch zu Programmatic – wir gehen das Setup gemeinsam mit Ihnen durch.

FAQs

Was ist ein Bid Request, einfach erklärt?

Ein Bid Request ist eine Nachricht, die die Supply-Plattform eines Publishers an die Plattformen von Werbetreibenden sendet, um einen Werbeplatz anzubieten und nach einem Preis zu fragen. Sie beschreibt den Werbeplatz, die Seite oder App, das Gerät und – sofern zulässig – den Nutzer. Käufer haben Millisekunden Zeit für ihre Antwort.

Was ist OpenRTB?

OpenRTB ist die Spezifikation des IAB Tech Lab, die das Standardformat für Bid Requests und Bid Responses festlegt. Sie gibt Käufern und Verkäufern eine gemeinsame Struktur, sodass jede konforme Demand-Side-Plattform Requests von jeder konformen Exchange lesen kann, ohne für jede eine eigene Integration zu benötigen.

Was ist der Unterschied zwischen einem Bid Request und einer Bid Response?

Der Request kommt vom Verkäufer und beschreibt die Opportunity. Die Response kommt vom Käufer und enthält einen Preis und ein Werbemittel. Ein Käufer kann auch gar nichts zurückgeben – eine gültige Antwort und bei den meisten Supply-Quellen die häufigste.

Was bedeutet tmax in einem Bid Request?

tmax ist die maximale Zeit in Millisekunden, die die Exchange auf Ihre Bid Response wartet. Antworten, die danach eintreffen, werden unabhängig vom Preis verworfen. Damit ist die Antwortlatenz eine direkte kommerzielle Einschränkung dafür, wie viel Inventar Sie gewinnen können.

Warum enthalten manche Bid Requests keine Nutzerkennung?

Weil Browser Third-Party-Cookies einschränken und mobile Betriebssysteme ein ausdrückliches Opt-in verlangen, bevor eine Advertising ID weitergegeben wird. Requests ohne Kennung kommen trotzdem an und können weiterhin kontextuell eingekauft werden, doch Zielgruppen-Targeting, Retargeting und Frequency Capping lassen sich auf sie nicht anwenden.

Kann ich die rohen Bid Requests sehen, die meine Kampagnen erhalten?

Bei einem gemieteten DSP-Seat sehen Sie in der Regel nur die aggregierten Reports, die der Anbieter bereitstellt. Bei einer eigenen oder lizenzierten Plattform steuern Sie das Logging selbst, sodass sich Feldverfügbarkeit, No-Bid-Gründe und Supply-Chain-Daten in genau der Detailtiefe auswerten lassen, die Sie benötigen.

Wofür wird das Supply-Chain-Objekt verwendet?

Es listet jeden Zwischenhändler auf, der die Impression zwischen dem Publisher und Ihrer Plattform gehandhabt hat. Käufer nutzen es, um zu erkennen, wie viele Reseller im Pfad sitzen, um zu prüfen, ob jeder davon zum Verkauf dieses Inventars berechtigt ist, und um kürzere und günstigere Wege zur selben Zielgruppe zu wählen.