Guides

OpenRTB vs Prebid and header bidding: how they fit together

"OpenRTB vs Prebid" is one of the most common searches in programmatic, and it is a category error, in a useful way. They are not alternatives you choose between. One is a protocol, one is an auction technique, and one is software that implements the technique using the protocol. Once you see the layering, the confusion goes away.

Three different kinds of thing

  • OpenRTB is a protocol: the IAB Tech Lab message format for a real-time auction, the JSON bid request an exchange sends and the bid response a bidder returns. It defines the vocabulary, not the plumbing. See what OpenRTB is.
  • Header bidding is an auction technique: letting a publisher offer an impression to several demand sources at once, before calling its primary ad server, so those sources compete instead of being ranked in a fixed waterfall.
  • Prebid is software: the dominant open-source implementation of header bidding, governed by Prebid.org. It is not a protocol and not a demand source of its own.

What header bidding actually does

Before header bidding, publishers ranked demand in a waterfall: ask partner A, and if it passes, ask B, and so on. That leaves money on the table because a lower-priority partner might have bid more. Header bidding replaces the sequence with a parallel auction: all participating demand sources are asked to bid at the same time, and the winner competes in the ad server on price. It runs in one of two places:

  • Client-side, in the browser, where a script runs the auction before the page calls the ad server.
  • Server-side, where the browser makes one call to a server that runs the auction against many demand sources, trading some transparency for speed and a lighter page.

What Prebid is, concretely

Prebid is a family of components, not one program:

  • Prebid.js: the client-side library that runs the in-browser auction and manages bidder adapters.
  • Prebid Server: the server-side auction (with Go and Java implementations) that runs the same idea in the cloud.
  • Prebid Mobile: SDKs for in-app header bidding.

The important detail for this comparison: Prebid Server talks to its bidder adapters using OpenRTB. Its auction endpoint takes an OpenRTB request and it exchanges OpenRTB bid requests and responses with demand partners under the hood. Prebid does not compete with OpenRTB; it is one of the largest emitters of it.

How they stack

Read from the publisher down to the bidder, the layers nest rather than compete:

Publisher page / app
  Header bidding            <- the technique: run a unified auction
    Prebid                  <- the software running that auction
      OpenRTB               <- the protocol Prebid uses to ask each bidder
        Exchange / SSP
          OpenRTB           <- the same protocol, exchange to DSP
            DSP / bidder

OpenRTB shows up twice because it is the common tongue at every hop where one party asks another to bid. Header bidding and Prebid decide who gets asked and where the auction runs. OpenRTB is how the asking is phrased.

Side by side

 OpenRTBHeader biddingPrebid
What it isA protocol / message formatAn auction techniqueSoftware
Owned byIAB Tech LabNobody; an industry practicePrebid.org
LayerThe wire between any two auction partiesUpstream, at the publisherImplements header bidding
Uses OpenRTB?It is OpenRTBYes, to call each demand sourceYes, Prebid Server speaks it

Where validation fits

Because Prebid Server and every SSP in the chain emit OpenRTB, the same validation applies wherever a bid request is produced. If you build or operate a Prebid Server deployment, a bidder adapter, or an exchange, the requests you send are OpenRTB and can drift from the spec in the usual ways: a stale placement enum, a consent string in ext, a floor without its currency. See common OpenRTB mistakes for the frequent ones.

  • Paste a request or response into the tester to check it client-side.
  • Gate a Prebid adapter or exchange build with the CLI and validation in CI.

Sources