Header bidding vs open bidding (server-side): the latency-vs-control tradeoff

Header bidding vs open bidding (server-side): the latency-vs-control tradeoff

Both are ways for a publisher to let multiple demand sources compete before calling the ad server. The difference is where the auction runs, and it changes what you as a buyer see.

1. Client-side header bidding: the auction runs in the user's browser via a wrapper (Prebid.js is the common one). Each SSP gets a fair, simultaneous call. You see clean, un-deduplicated demand.

2. Server-side / open bidding: the auction runs on a server (Google's Open Bidding, or Prebid Server). Faster page load, but cookie matching degrades because the match happens server-to-server, hurting your user recognition rate.

3. The tradeoff for the buyer: client-side gives better identity resolution (your bid request carries a matched user) but adds browser latency and timeouts that can drop your bid. Server-side is fast but you lose addressability on a meaningful slice of users.

4. How to tell which you are buying through: server-side paths show lower match rates and often a wrapper/exchange node in schain. Client-side shows higher match rates and Prebid signals.

Why it matters: if your audience strategy depends on cookie/ID matching, a publisher's shift to server-side can quietly cut your addressable reach without changing your settings. Watch match-rate by supply path in log-level data — a sudden drop often means the auction moved server-side.