Header bidding allows publishers to collect bids from all potential demand sources before making a decision about who to sell the ad space to. This represents a material change from the way that auctions were conducted prior to the technology being available; for more information on those changes, I recommend Clearcode’s “Waterfalling, Header Bidding and New Auction Dynamics” blog post.
Table of Contents:
Introduction
There are a variety of technologies that publishers use for header bidding, and client-side vs server-side implementation is big differentiator among those solutions.
In client-side cases, a piece of code on-page known as the “wrapper” creates simultaneous requests to all it’s integrated SSPs/Exchanges (known as “bidders”). All applicable bid responses are then aggregated, and the best bid wins the ad slot. One big complaint about this method is the latency that it introduces; the fact that auctions take place in the browser means that there can be a noticeable slowdown for the user.
In a server-side case, auctions are conducted by a trusted tech vendor outside of the browser; the fact that server-side auctions aren’t limited by the user’s device/connection means they can be much faster, and many more potential demand partners can be reached at once. Low user match rates are one of the most touted downsides of server-side header bidding, with another notable downside being the transparency afforded to the publisher.
As it stands now, most publishers who do header bidding tend to use a client-side wrapper, and many use a hybrid approach which leverages both client & server side header bidding. There is a bit of an absence of conclusive research into the share of the market commanded by server-side vs client-side implementations, but there have been some attempts.
At any rate, what happens server-side is out of our field of view, so our study examines sites using client-side header bidding solutions. Particularly, we are examining solutions based on Prebid, “a free and open source suite of software products that enables publishers to implement header bidding on websites and mobile apps.”
According to Kevel (formerly AdZerk), who maintains the Header Bidding Index, 72% of client-side wrappers use the Prebid codebase. In addition to its adoption rate, we chose to examine Prebid solutions due to the great diagnostics you can get from the publisher API.
Using data gathered from ~150,000 web publishers with Prebid based header bidding wrappers, between January 1st – May 21st 2021, we hope to present to our readers some compelling data points that have not been presented before.
Benchmarks
Ad Unit Level Activity Stats
For each individual ad unit that we saw for sale, we measured the following:
-
-
- Requests Per-Ad-Unit: how many header biding requests are created for a single ad unit, within the scope of a single auction sequence
- should grow linearly with the # of bidders per ad unit
- Bidders Contacted Per-Ad-Unit: how many bidders are contacted each time a single ad unit is auctioned
- More bidders contacted means more latency
- Prebid Wrappers Per-Ad-Unit: the number of wrappers offering each ad unit for sale
- This was “1” across the board; the norm here is clearly 1.
- Requests Per-Ad-Unit: how many header biding requests are created for a single ad unit, within the scope of a single auction sequence
-
Insights were also separated based on the rank of the site in order to observe if activity levels trended with rank; we found they didn’t really differ meaningfully.
Bidders Per Ad Unit
Across all rank buckets, the median # of bidders contacted per ad unit was between 6-8. The interquartile range (difference between the 75th & 25th percentiles) was between 5-7.
For all rank buckets, there’s a pretty clear takeaway: it’s odd to see more than a dozen bidders for a single ad unit.
Header Bidding Requests Per Ad Unit
We would expect this to be extremely similar to the previous chart, and for the most-part it is. We do observe small difference though, suggesting that there is some amount of bid duplication across all rank buckets.
Looking at outliers, we can certainly confirm that there are cases where the wrapper sends the same bidder dozens of requests for the same ad unit. I’ve put together a sample of such cases in the following table:
Page Level Activity Stats
For each page we visited, we captured the following stats about a single auction sequence (each ad unit being filled once):
-
-
- Header Bidding Requests: how many header biding requests are created for a single visit
- should grow linearly with the # of bidders per ad unit
- Bidders Contacted: how many bidders are contacted each page load
- More bidders contacted means more latency
- Ad Units Offered For Sale: The # of ad units made available to bidders through header bidding
- Not guaranteed to be the total # of ad units available; just whats offered via Prebid
- Prebid Wrappers In Use: the number of wrappers detected on page
- The norm here was clearly “1”, though we did see some outliers. With a range of 1-2, the chart was not particularly compelling, so it is not included.
- Header Bidding Requests: how many header biding requests are created for a single visit
-
Ad Units Offered Per Page via Header Bidding
The median here was fairly consistent across all rank buckets: between 3-4 unique ad units auctioned. The 75th percentile was also fairly steady between 6-7.
This suggests that your eyebrows should raise as the # of unique ad units offered in a single session approaches double digits.
Bidders Contacted Per Page Load
Across all rank buckets, the median # of bidders contacted per page load was between 7-9 (compared to between 6-8 per ad unit). The difference between the ad unit & page level stats suggests some degree of bidder exclusivity on a per-ad-unit basis.
Header Bidding Requests Per Page Load
With a median 3-4 ad units offered via header bidding per page, and a median 7-8 bidder offered each ad unit, the figures here could pretty much be expected. The median page with header bidding sends between 24-31 ad requests to connected bidders as it loads.
Looking past the median, there is quite a range of activity levels we have observed. Focusing on the page level requests may not prove useful, because it is more a function of the # of integrated bidders & the number of ad units offered, which seem much more material to gauging quality.
Further Findings
Most Common Wrapper Namespace
We touched a bit on it earlier, but a wrapper is a script that helps the publisher conduct header bidding auctions. The wrappers contain a variety of functions to help facilitate that process, which are housed under some global variable name. In the “vanilla” implementation of Prebid, that namespace is “pbjs”.
For example: pbjs.getHighestCpmBids() typed into the console produces an array of bid response objects:
As part of our analysis, we measured the namespaces of all wrappers we encountered, and are providing the top 25 most encountered wrappers here for review.
For each wrapper we provide the following stats:
-
-
- Market Share: % of sites from the study where this wrapper could be encountered
- Avg Requests Per Ad Unit: how many bid requests does the wrapper create for a single ad unit, within the scope of a single auction sequence
- should grow linearly with the # of bidders per ad unit
- Avg Requests for Each Ad Unit Per Bidder: how many bid requests does the wrapper tend to send a connected bidder for a single ad unit, within the scope of a single auction sequence
- should be extremely close to 1; it seems redundant to send multiple requests to the same bidder for the same ad-unit
- Avg Bidders Contacted Per Ad Unit: how many bidders does the wrapper tend to contact each time a single ad unit is auctioned
- More bidders contacted means more latency
-
Avg Requests for Each Ad Unit Per Bidder are of particular interest here; for certain long-tail wrappers, we can see that it’s regular practice to create duplicate bid requests for each bidder.
Unfortunately, there is not documentation associated with many of these wrappers, so it’s hard to assign a developer / company to most of them. I’d love to hear feedback from readers about which of these they recognize, and begin the work of mapping the namespace to a human readable name!
Most Common Bidders Encountered
When talking about header bidding, the bidder refers to the entity which the wrapper sends bid requests to.
For example, look at the red highlighted column below:
Our crawlers see data very similar to this, and we capture the “bidder” string as it appears in live traffic. As part of our analysis, we are providing the top 50 most encountered ones here for review. We left all formatting & casing intact for these, so you may see some duplication of items which only differ due to minor formatting reasons.
For each bidder we provide the following stats:
-
-
- Market Share: % of sites from the study where this bidder name could be encountered
- Avg Requests Per Ad Unit: how many bid requests does the bidder tend to get sent for a single ad unit, within the scope of a single auction sequence
- should be 1
- Avg Ad Units Offered Each Session: How many ad units is the bidder offered per session, within the scope of a single auction sequence
-
Time To Respond Stats
For this chart, we examined header bidding auctions that resulted in competition between bidders for the same ad unit (many auctions are won without competition, and often times ad slots are filled via alternate demand channels, so that’s why I specify).
There doesn’t seem to be a huge difference between the timings of winning & losing bids. Further research demonstrates what common sense would have us believe: the best price tends to win, not the fastest bid.
As we can see, the highest bid wins the header bidding battle 97.5% of the time. This is the promise of header bidding after all: by offering all potential buyers an ad unit at the same time, you don’t have to worry about throwing away a possible better price for your inventory.
Conclusion
Hopefully this has proved informative to those trying to understand the activity generated by client-side header bidding wrappers, and the entities involved.
Header bidding has fundamentally changed the way that auctions take place today, but there are still many lingering questions about its future:
-
-
- Will client-side implementations retain their popularity if cookie matching is less of a concern? As cookies are less available in modern browsers, there is sure to be interest in server-side header bidding for those publishers with the resources.
- How will DSPs handle the increased bandwidth costs that go along with header bidding? Compared to sites that rely on the waterfall method to trigger auctions, DSPs receive many times more opportunities from publishers who leverage header bidding. This is because every integrated SSP announces all possible ad units for sale each page load.
- Supply chain optimization has become extremely popular as a result; buyers are looking for the shortest & most efficient path to the inventory they want, and they also prefer certain auction dynamics (those vary by SSP).
-
Thanks for taking the time to read, and be sure to message us on LinkedIn or Twitter if you have any questions or comments about the findings!
Supplementary Datasets
In addition to the summary data provided in this post, we are also providing some lower-level examples here, in the form of a google sheet.
There are the following reports:
Duplicate Bids Examples
Similar to what was presented in the “Header Bidding Requests Per Ad Unit” section, but much longer. 12,000 rows of cases where there are inordinate numbers of requests send to a single bidder for one ad unit.
Domain Level Examples
This sheet allows readers to understand the client-side header bidding activity levels for a variety of sites
Domain / Wrapper Level Examples
Similar to the last sheet, but allows the reader to dive into specific header bidding wrappers. There is an “examples” column that’s currently hidden due to the size, which gives ad unit level specificity into high frequency cases. Reveal column “G” to access that information.
