Prebid.js vs Amazon TAM vs Google Open Bidding: the wrapper you buy through shapes your bid

Prebid.js vs Amazon TAM vs Google Open Bidding: the wrapper you buy through shapes your bid

A wrapper orchestrates the header-bidding auction on the publisher's side. The three dominant ones treat your bid differently, which matters even though you do not control the wrapper.

1. Prebid.js (open-source, client-side): transparent, every SSP called simultaneously in the browser. You compete on even footing, but you inherit browser timeout risk — a slow bid response is simply dropped.

2. Amazon TAM (Transparent Ad Marketplace): a server-side wrapper. Lower latency, but a more closed pipe; visibility into the auction is thinner.

3. Google Open Bidding: server-side, run by the same company that runs the ad server beneath it. Convenient, but the structural conflict (auctioneer also bidding) has been the subject of long-running scrutiny.

4. The buyer-side tell: which wrapper a publisher uses changes your effective timeout, your match rate, and how your schain reads. Prebid paths show many parallel SSP nodes; server-side wrappers collapse into fewer.

Why it matters: the same campaign wins more on a fast server-side wrapper and times out more on a slow client-side one, independent of your bid price. Segment win-rate by wrapper signature in log-level data. If you are losing auctions on a specific wrapper at a competitive bid, the loss is latency, not price — raising bids there is wasted budget.