No More Chasing Waterfalls: A Measurement Study of the
Header Bidding Ad-Ecosystem
Michalis Pachilakis

University of Crete / FORTH, Greece
mipach@ics.forth.gr

arXiv:1907.12649v2 [cs.CY] 26 Sep 2019

Evangelos P. Markatos

University of Crete / FORTH, Greece
markatos@ics.forth.gr

ABSTRACTIn recent years, Header Bidding (HB) has gained popularity among
web publishers, challenging the status quo in the ad ecosystem.
Contrary to the traditional waterfall standard, HB aims to give backto publishers control of their ad inventory, increase transparency,
fairness and competition among advertisers, resulting in higher
ad-slot prices. Although promising, little is known about how thisad protocol works: What are HB’s possible implementations, who
are the major players, and what is its network and UX overhead?
To address these questions, we design and implement HBDetector:
a novel methodology to detect HB auctions on a website at realtime. By crawling 35,000 top Alexa websites, we collect and analyze
a dataset of 800k auctions. We find that: (i) 14.28% of top websites
utilize HB. (ii) Publishers prefer to collaborate with a few Demand
Partners who also dominate the waterfall market. (iii) HB latency
can be significantly higher (up to 3× in median case) than waterfall.

CCS CONCEPTS•Information systems → Online advertising; Display advertising; Web log analysis;

KEYWORDS
Header Bidding, Digital Advertising, Waterfall, RTB
ACM Reference format:
Michalis Pachilakis, Panagiotis Papadopoulos, Evangelos P. Markatos, and Nicolas Kourtellis. 2016. No More Chasing Waterfalls: A Measurement Studyof the Header Bidding Ad-Ecosystem. In Proceedings of ACM Conference,
Washington, DC, USA, July 2017 (Conference’17), 14 pages.
DOI: 10.1145/nnnnnnn.nnnnnnn

1

INTRODUCTION

The largest portion of the digital advertisements we receive today
on the Web follows a programmatic ad-purchase model. Upon a
website visit, a real time auction gets triggered, usually via thereal-time bidding (RTB) protocol [27], for each and every available
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or afee. Request permissions from permissions@acm.org.
Conference’17, Washington, DC, USA© 2016 ACM. 978-x-xxxx-xxxx-x/YY/MM. . . $15.00
DOI: 10.1145/nnnnnnn.nnnnnnn

Panagiotis Papadopoulos
Brave Software
panpap@brave.com

Nicolas Kourtellis

Telefonica Research, Spain
nicolas.kourtellis@telefonica.com
ad-slot on the user’s display. These auctions are hosted in remotemarketplace platforms called Ad Exchanges (ADXs) that collect thebids from their affiliated Demand Site Platforms (DSPs). The highest
bidder wins, and delivers its impression to the user’s display.
However, there are more than one ad networks that can provide
bids for an ad-slot. In the traditional standard for ad-buying, called
waterfalling, the different ad networks (e.g., ADXs with their affiliated DSPs) are prioritized in hierarchical levels [32]. Thus, when
there is no bid from ad network #1, a new auction is triggered for ad
network #2, and so forth. Of course, apart from the auction-basedad purchase, there are still other non-programmatic channels likedirect orders from advertisers who run static campaigns for a certain
number of impressions [12]. Through these channels, advertisers
target not a user but the entire audience of a specific website (e.g.,an ad regarding Super Bowl on espn.com). Alternatively, if thereis neither a direct order nor a bid in these auctions, the ad-slot may
be filled via another channel for remnant inventory called fallback
or backfill (e.g., Google AdSense) [25].
The process of ad prioritization among the above different channels and ad networks in waterfall is managed through the publisher’s ad server or Supply Side Platform (SSP) (e.g., DoubleClickfor Publishers (DFP)). Priorities are typically set not at real time but
based on the average price of the past purchases for each channel.
As a consequence, in waterfall not all ad partners have the ability
to compete simultaneously. Therefore, the publishers do not get the
optimal charge price, since an ad-slot may not be sold at the highest
price (e.g., if the winning bid in the auction of ad network #1 is0.2$, the ad-slot will be sold even if there was a bid of 0.5$ in ad
network #2). Apart from the potential loss of revenue for the publishers, there is also a significant lack of transparency. Except fromthe winning bidder, the publishers do not know who else placeda bid for their ad-slot and for how much. In addition, the lack ofcontrol restricts the publishers from choosing Demand Partners, ordifferent sale channels in real time (e.g., to get a high price throughRTB when the quota of direct ads sold has not yet been depleted).
To remedy all the above, Header Bidding [55] (or parallel bidding
in mobile apps [42]) has been recently proposed and has started togain wide acceptance among publishers [20, 23, 36, 52]. As depicted
in Figure 1, HB is a different auction that takes place not on the adserver as in waterfall, but inside the header field of a HTML page,
before anything else is loaded on the page. It allows a publisher tosimultaneously get bids from all sale channels (e.g., direct orders,programmatic auctions, fallback) and Demand Partners (e.g., DSPs,
ADXs, ad agencies). HB not only gives the control back to the1M imps$1.1 CPM/imp

HEADER AUCTION(1st best price)1

Ad server

Website Request$1.5 CPM

Website’s header
Winner
$1.5 CPM

DSP

ADX
Bids

DSP

DSP

RTB AUCTION (2nd best price)$1.0 CPM

SSP1
10K imps$0.5 CPM/imp

Bid Requests
AuctionNotifications$0.7 CPM$1.0 CPM$0.9 CPM

Bidding phase$0.9 CPM

Bid reqs$0.7 CPM$1.0 CPM$1.9 CPM

DSP$0.9 CPM

DSP

Bid Responses

DSP

RTB AUCTION (2nd best price)$0.9 CPM$0.2 CPM$1.1 CPM

3

DSP

DSP

Winnerselection
phase

SSP2
DSP

Fallback

Figure 1: High level overview of the HB. The absence of priorities
aims to provide (i) fairness and higher competition among advertisers and (ii) increased revenue for the publishers.

publisher but also allows higher revenues than waterfall, since
it guarantees that the impressions with the higher price will bebought and rendered [10]. On the advertiser’s side, HB promotes
fairness since there are no priorities. Consequently, any advertiser
could win any auction, as long as it bids higher than others. HB
enables small advertisers to also be competitive, compared to big
advertisers who would have higher priority on the waterfall model.
Although there is a lot of research regarding the waterfall standard [5, 6, 34, 35, 41], we know very little about the innovativeand rapidly growing alternative of HB. How is it implemented?
What is the current adoption of HB on the Web? What is the performance overhead and how it affects the page rendering time?
How many bids the average publisher can receive? What are theaverage charge prices and how do these compare to the ones of
the waterfall standard? Which are the big players and how is themarket share divided?
To respond to all these questions, we study the different existing
implementations of HB and we design HBDetector: a novel methodology to detect HB auctions on the Web. Our approach aims toincrease transparency on the ad-ecosystem, by exposing at realtime the internals of the new and rapidly growing HB ad protocol:
in which sites it exists, the prices and partners involved, etc. Using
HBDetector, we crawl a number of popular websites, we collecta rich dataset of HB-enabled websites. Our tool helps us detect
particular browser events triggered by the HB libraries embedded
in such webpages, along with the ad partners participating in the
HB and metadata for the auctions executed on these websites. We
analyze and present the first full-scale study of HB aiming to shedlight on how this innovative technology works and investigate thetrade-off between the overhead it imposes on the user experienceand the average earnings it brings to publishers. In this paper, we
make the following main contributions:(1) We propose and implement HBDetector, the first of its kind
Web transparency tool, capable of detecting HB activity at realtime, on the Web. We provide it as an open-sourced browser
extension for Google Chrome1 .
1 https://www.github.com/mipach/HBDetector

2

RTB AUCTION (2nd best price)

DSP

4

Pushing Bid Responses to Ad Server
Winning Bid Response

Winner Notification

Check other channels:
direct orders, fallback,etc.

Direct Order

HEADER

Demandpartners

User

Publisher

Figure 2: Flow chart of the Header Bidding protocol.

(2) By running HBDetector across 35,000 top Alexa websites, wecollect a dataset of 800k auctions. This work is the first to
analyze the adoption and characteristics of HB.
(3) We extract a set of lessons on HB: (i) There are 3 different
implementations of HB: Client-side, Server-side and Hybrid
HB. (ii) There is at least 14.28% of top websites that use HB. (iii)
Publishers tend to collaborate with a small number of Demand
Partners, which are already reputable in the waterfall standard.
(iv) HB latency can be significantly higher (up to 3× in the
median case, and up to 15× in 10% of cases) than waterfall.

2

BACKGROUND ON HEADER BIDDING

In this section, we cover background knowledge required for ourstudy regarding the most important aspects of HB.

2.1

HB Protocol Description

Contrary to the traditional waterfall standard, in HB the ad auction
does not take place in a remote ADX, but on the user’s browser.
The HB process, depicted in Figure 2, is the following:
Step 1: When a user visits a website, the HTML page is fetched.
As soon as the header of the HTML is rendered in the browser,
user tracking code and the third-party library responsible for theprocedure of the HB is loaded as well.
Step 2: Then, the HB library sends (in parallel) HTTP POST
requests to the Demand Partners (e.g., DSPs, ad agencies, ADXs
which conduct their own RTB auctions) requesting for bids. Thesebid requests also include information about the current user (suchas interests and cookies). Such information can be used by the
Demand Partners to decide whether and how much they will bid
for an ad-slot in the particular user’s display. Note, that if a Demand
Partner does not respond within a predefined time threshold, its
bid is considered late and not taken into account.
Step 3: As soon as the Demand Partners respond with theirbids (and their impressions), the collected responses are sent to
the publisher’s ad server. The ad server will check the received
bids and compare with the floor price agreed with the publisher, todecide if the received prices are high enough [54]. If the floor priceis met, the HB process was successful and the ad-slot is satisfied.
Alternatively, the ad server can check the rest of the programmatic(or not) available channels (e.g., direct order, RTB, fallback) and willfind the best next option for the specific ad-slot. This step entails
communicating with SSPs for available direct orders which canprovide higher revenues to the publisher than regular RTB auctions.
The ad server can also communicate with Demand Partners for
RTB auctions, or other SSPs who can provide fallback ads, such as
Google AdSense, or even house ads.
Step 4: As soon as the impression is rendered on the user’s
display, a callback HTTP request notifies the winning Demand
Partner that its impression was rendered successfully on the user’s
browser, and the ad price that was charged (winner notification).
In theory, with this new protocol, the publisher has total control
over the ad inventory they provide, knowing exactly how much the
Demand Partners value each slot, and the actual amount of money
they are willing to pay for it. In addition, there is full transparency,
since the publisher can have access to all bids and decide at realtime the best strategy it should follow without the need to trust
any intermediaries. In the future, HB could provide the means topublishers to reduce advertising that is not suitable for, or does notmatch the semantics of their websites, and even curb malvertising.
However, as we will show later in Section 4, this transparency andcontrol is not always applicable under the various types of HB wehave detected.

2.2

HB Implementation & Performance

To implement the above protocol, publishers need to include HB
third-party libraries in their webpages. Although there does notexist a common standard for HB yet, the great majority of publishers use the open-source library of Prebid.js [45], supported by
all major ad companies. This library includes: (i) The core component which is responsible to issue the bid requests and collect
the responses, which are later sent to the publisher’s ad server.
(ii) The adapters which are plugged into the core and provide allnecessary functionality required for each specific Demand Partner. Prebid.js is supported by more than 200 Demand Partners(e.g., AppNexus, Criteo, OpenX, PulsePoint) that provide their own
adapters [44].
We note that in traditional waterfall, the auction information is
opaque to the client and the only information that can be inferred(if at all) is through the parameters of the notification URL (whichacts as a callback to the winning bidder). In contrast, in the HB, anddue to bidder responses, browser DOM events are triggered that
contain metadata directly available at the user browser, and can beused to clearly distinguish between waterfall and HB activity.
The non-hierarchical model of HB produces much more network
traffic than the waterfall standard. Indeed, HB sends one request
for each and every collaborating Demand Partner. This can result toan increased page latency, especially when some Demand Partners
take too long to respond. To make matters worse, as soon as theyreceive a bid request, some of these Demand Partners may run theirown auctions inside their ad network, with their own affiliatedbidders (as depicted in Figure 1). This increased page latency raises
significant concerns. Indeed, 40% of the publishers already mention

that such latency is capable of impacting their users’ browsing
experience [8, 9, 15].
It is worth noting, that HB technology is still in its early stages
and many ad networks are technologically not ready to move completely from the waterfall model to participate in this new model.
In order not to miss bids from such networks, some ad mediators(e.g., Appodeal) mix the two techniques in an attempt to provide
waterfall compatibility during this transitional period [42].

3

METHODOLOGY FOR MEASURING HB

In this section, we outline our methodology for detecting HB on
webpages, and our effort to crawl top Alexa websites for HB activity.

3.1

Detection Mechanism

In order to detect if a webpage is using HB for delivering ads to its
users, we need to detect HB-related activity originating from thesaid webpage. As explained above, the HB activity is performed
over different channels than ad protocols such as RTB, using alibrary (implemented in JavaScript) embedded in the header ofthe page. Therefore, by monitoring the events triggered by suchlibraries, we can confidently distinguish HB activity from othermodels such as waterfalling.
There are three main ways to detect if HB is present in a webpage:(1) Perform static analysis of the page and identify tags ofscripts that load known HB libraries.
(2) Detect DOM-related events that are triggered due to HB
embedded in the webpage.
(3) Detect web requests sent from the page to HB entities.
The first method is straightforward to implement with the following steps: Download the webpage source code and use regularexpressions to detect all known HB libraries. However, we notethat just detecting these libraries is not enough, as false positives orfalse negatives could occur. For example, static analysis is prone tofalse positives such as non HB libraries being misnamed using HBrelated names, or HB-related libraries appearing in the HTML code
but not executed Similarly, static analysis is vulnerable to false negatives such as renamed HB libraries to names that are not known
yet, or new HB libraries that do not match our HB-related keywords
from known libraries. To avoid such potential false positives andnegatives, we chose not to use static analysis in the HBDetector.
The second method is more difficult to implement, but offers
better detection rates with reduced false positives and negatives,
and thus, harder to evade. This method monitors the DOM events
that are triggered in a webpage, events that are sent to notify thecode of interesting activity that has taken place on the page. Events
can represent everything from basic user interactions to automatednotifications happening on the page. Most HB libraries trigger
events in several phases of an auction (initiation of the auction, bidcollection, winning bidder, etc.). If such an event is detected, weare certain that it is because of HB. Even better, by “tapping” onthese events [33], we can collect information about HB that thefirst method is not able to detect.
The third method is similar to the second, but operates at adifferent level in the browser: monitor the web requests of a pagein real-time, and detect all the request sent to and received fromknown HB Demand Partners. By constructing a list containing all

Table 1: Summary of collected data by crawling top Alexa webpages
using the HBDetector for HB-related activity.
HB latencies

Store for further
analysisData# of websites crawled# of websites with HB# of auctions detected# of bids detected# of competing Demand Partners# weeks of crawling

Plugin Database

HB metadata

WebRequest Inspector

HTML DOM Event Inspector

Web request inspection for
identification and metadata
collection of demand partners

DOM event inspection for
auction metadata
collection.

Applies HB list

Volume35,0004998
798,629
241,392
84
5

Monitors HB events

Web Browser + HBDetector

Figure 3: Overview of the HBDetector mechanism. After the user
accesses a webpage, all the incoming and outgoing WebRequests areinspected to detect HB partners. A content script is also injected in
the header of the webpage to detect HB events about the auction
performed.

the known Demand Partners, we can check all the incoming andoutgoing WebRequests to the browser, and keep the relevant to HB.
In this paper, we implemented HBDetector, a tool which combinesthe 2nd and 3rd methods to increase detection performance. An
overview of the tool is illustrated in Figure 3. HBDetector adds acontent script in the header of each webpage when the page isloaded. This script monitors the webpage’s activity for various
events and requests sent and received by the page, keeping theones relevant to HB (e.g., incoming responses from DSPs for HB
auctions). When such DOM events are triggered (which is a firstsign of HB activity), the tool filters the web requests triggering
these events by checking the parameters included in them. HBlibraries use predefined parameters such as “bidder ”, “hb partner ”,“hb price”, etc., which are not used by other ad-protocols such as
RTB. Thus, the tool keeps all web requests that triggered a DOM
event of a HB library, and also include HB parameters. It thenproceeds to extract the values from these parameters for analysis.
These parameters are typically fixed for each HB library, and all
HB partners must use them as such, to participate successfully in
HB auctions with that library. In contrast, in the RTB protocol, theparameter names used in the notification URLs are DSP dependentand do not utilize DOM events.
From the available HB libraries, we examined prebid.js (and its
variants), being the most famous one (64% of client-side wrappers
are built on prebid [28]), as well as gpt.js and pubfood.js libraries
for their available codebase and/or documentation. We decided tofocus our more in-depth reverse-engineering on prebid.js due toits popularity, available documentation and open-source code andAPIs [24, 43]. By performing code and documentation analysis for
the HB libraries that have such material available, we identified thefollowing list of HB events that our tool can detect:• auctionInit: the auction has started• requestBids: bids have been requested• bidRequested: a bid was requested from specific partner• bidResponse: a response has arrived• auctionEnd: the auction has ended• bidWon: a bid has won• slotRenderEnded: the ad’s code is injected into a slot
• adRenderFailed: an ad failed to render

In this work, we focus on three of these events: auctionEnd,
bidWon, and slotRenderEnded. The auctionEnd, as its name states,
is triggered after the auctions for the ad-slots have finished, i.e.,
the Demand Partners have submitted their offers. The bidWon
event is triggered after the winning Demand Partner has been
determined. Finally, the slotRenderEnded event is triggered when an
ad has finished rendering successfully on an ad-slot. By analyzingthese events, which can only be triggered by HB activity and notother libraries, we were able to collect several metadata about theauctions, such as the Demand Partners who bided, the ones whowon, the CPM (cost per million impressions in USD) spent, the adsize, currency, dimensions, etc.
We also constructed a list with all the known HB Demand Partners. We collected and combined several lists used by HB tools
designed to help publishers fine tune their HB on their websites.
Using this list, we can infer all the WebRequests about HB without altering them, in order to detect when a request to a Demand
Partner is sent, and when an answer is received. The HBDetector iswritten in a few hundred lines of JavaScript as a Google Chromebrowser extension.
HBDetector limitations: The tool does not analyze all libraries
used by the HB ecosystem due to unavailability of documentation
and/or code. Also, it cannot capture new DOM events if they get
added to existing libraries it is analyzing. Finally, it cannot capture
current DOM events if the events change format or parameters they
are using. In addition, the tool does not capture waterfalling RTB
activity, and therefore, does not allow direct comparison of the two
protocols with respect to Demand Partners involved, ad-prices, etc.
We plan to address these limitations in a future version of the tool.

3.2

Data Crawling

We used our tool to detect which websites employ HB, by crawling a
set of websites, based on a large top list purchased from Alexa [3] on
01/2017. Given the changes anticipated in such website ranking listand especially in its long tail [48], we focus on the head of the Alexalist, to capture a more stable part of the ranking distribution throughtime. Due to equipment, network and time costs, we limited thislist to 35,000 domains to crawl per day, during Feb’19. To confirm
the representativeness of this older list, we compared it with the
top 35k domains in 2017-2019 from [48], and found that it has anoverlap of 78.36%(06/2017), 62.10%(06/2018), 58.36%(02/2019) and55.34%(06/2019).
We used selenium and chromedriver loaded with HBDetector inorder to automate the crawling. We initiated a clean slate instance
before visiting each website, in order to keep the crawling processstateless (no previous history, no cookies, no user profile). When a100% of websites

80

Detected HB
Non Detected HB

60
40
20
0

2014 2015 2016 2017 2018 2019

Figure 4: Header Bidding adoption in the last six years for the top
1k Alexa websites of every year.

webpage is visited, the crawler waits for the page to be completely
loaded, and then allows an extra five seconds, in case additional
content needs to be downloaded or pending responses to be concluded. We set the page load timeout to 60 seconds, so that if thepage is not fully loaded in one minute, the crawler proceeds to thenext webpage in the list, after killing the previous instance andinitiating a new, clean instance.
With this crawling process, we detected HB in ∼5,000 (14.28%)of the websites, in a well-distributed fashion. In particular, HB
was found in 20-23% of the top 5k websites, 12-17% for the top
5k-15k, and 10-12% for the rest. Indeed, new top websites notincluded in this 35k list may have already adopted HB, leading toan underestimation of today’s adoption rate. However, as found in
our results in Sec. 4.1 were we use top 1k Alexa lists for 6 years,
we show similar HB adoption rate with the head of the top 35k list,
giving credence to our results. Then, we crawled these 5k websites
every day for a period of 34 days in Feb’19, collecting metadata
about the HB auctions, and performance exhibited from the various
websites using HB. In Table 1, we provide a summary of the datacollected.
We note that we detected 800k auctions but received 241k bids.
One could expect that each auction should have at least a bid. Indeed
this would be the case if actual users were involved and Demand
Partners were interested in them. However, there are cases wherebidders may avoid bidding when they know nothing about the user.
In our case, we are interested in the vanilla case using a clean state
crawler and no real user profiles.

4

THE 3 FACETS OF HEADER BIDDING

In this section, we analyze the crawled data and present results andobservations we have made about the HB adoption over time andtypes of HB we identified from our exploration.

4.1

Header Bidding Adoption

Since this is a new programmatic ad-protocol (standardized in2014[7]), we explore the general adoption of HB through the last
6 years. To do that, we downloaded snapshots of selected lists ofwebpages using the Wayback Machine [29]. Due to the involved
network and time cost to crawl from the Wayback Machine, we
focused on the top 1,000 publishers based on Alexa rankings, madeavailable in a recent study [48] and https://toplists.github.io/. The
list of top publishers was selected on a fixed day per year (6/6/2019,

6/6/2018, etc.). Since these historical webpages were static, we performed a static analysis looking for HB libraries and components intheir websites’ code. Someone could also try an analysis using the
HBDetector, by attempting to render each website, or even fingerprinting the libraries. However, such analyses: i) Take more time
to execute than static analysis. ii) The webpage must be renderable
and its components must work (scripts should be downloadable,
scripts should not fail to run, the page should not call unresponsive
servers, etc.). Therefore, dynamic analysis cannot be applied on
historical pages “played back”, with potentially deprecated libraries
or other scripts embedded, third-party partners not responding,etc., and expect 100% correctness on the results collected.
Figure 4 shows the yearly breakdown of HB found in thesewebsites. Interestingly, we observe a steady increase of the HBadoption. About 10% of these websites were early adopters andstarted using HB 6 years ago. After the breakthrough of 2016, when
HB became popular[49], there is a steady 20% of the websites using
this ad protocol. These adoption rates, and the general rate of 14.28%
in the 35k list, match industry-claimed numbers of ∼15% in the last
15 months (14.66% in Jan’18 - 15.84% in March’19, computed for the
top 1k out of 5k top Alexa websites that serve programmatic ads)
for the US market [19, 28].
We note that HBDetector catches 100% of the HB activities for the
libraries analyzed. Indeed, there are websites which could be using
HB libraries that we didn’t analyze at the time of data collection, andtherefore were not flagged as HB-enabled websites. This means we
get 100% precision but not 100% recall. However, the HB adoption
experiment using the 1k lists shows a rate that aligns with theoverall HB adoption rate in the 35k list, and these two rates closely
match what industry is claiming. These observations point to low
false positive and negative rates, and that the data collected by
HBDetector (i.e., using dynamic analysis) have high recall rate andprovide a representative picture of the HB ecosystem at the time ofeach crawl.

4.2

Types of Header Bidding Detected

Our in-depth investigation of the HB ecosystem and the data collected revealed that this new programmatic ad protocol is currently
being deployed in three facets: (i) Client-Side HB, (ii) Server-Side
HB, and (iii) Hybrid HB. This finding matches the 3 types of HB
wrappers (client-side, server-side and hybrid) suggested by industry reports [26]. In the Client-Side HB and Hybrid HB models, thead auctions are transparent, so we can distinguish them with ahigh degree of certainty due to the events sent and received by
the browser. On the other hand, on Server-Side HB model it isless clear, since most of the ad-related actions happen at the server.
However, after inspecting the responses received by the browser,
we can discover the parameters referring to HB (e.g. hb partner,
hb price, etc.). Next, we analyze each facet, including the steps
taken for the protocol’s execution, and potential consequences it
may have.

4.3

Client-Side HB

In Client-Side HB, as the name implies, the HB process happens in
the user’s browser. As illustrated in Figure 5, during this HB type,the user’s browser executes 8 steps, including the initiation of the

Ad Server

DSP

SSP

DSP

...
(6) Determine (5) Send
bids
auctionto ad
winnerPublisherserver
SSP(1) Request(3) Send available ad slots
website

SSP

...

DSP
Internal auction

Publisher(1) Request
Website(2) Receive
website’sheader(4) Receive bids(2) Receive
website’sheader

SSP

DSP

DSP

(5)Send available
ad slots Ad Server
SSP
to ad server and(5) Send available ad slots
client side bids(6) Receive bids(7) Receive
winning
impression

Data HubUser tracking(7) Notify winner
Data Hub
Retrieve user information

Figure 5: Client-Side HB overview and steps followed.
DSP(1) Request
Website(2) Receive
website’sheader(3) Send available Ad Server
SSP
ad slots(4) Send available ad slots
to ad server(5) Receive bids(6)Receive winning
impression

SSP

DSP
Internal auction

SSP

DSP
Internal auction

Data HubUser tracking

Retrieve user information

Figure 6: Server-Side HB overview and steps followed.

HB auction, receiving of bids from Demand Partners and notifying
the winning partner. Client-Side HB’s main goal is to improve
fairness and transparency. Publishers can choose the Demand
Partners they want to collaborate with, regardless of their market
cap. What matters is if their bids are competitive enough. Also,
because the whole HB process is performed at the client side, andthen sent to the publisher’s ad server, it is completely transparent
to the publisher and, in theory, to the user.
The publisher can know at any time which partners bid, forwhich ad-slots they were interested, how much they were willingto pay, etc. On the down side, Client-Side HB is harder to set up.
Publishers need to have good technical understanding to set up
and tune their HB library. Also, they need to operate their own ad
server, a task which is not trivial. Finally, because of the increased
number of messages to be exchanged, or due to a bad configurationin the HB library, longer latencies may be observed.
From the regular end-user’s point of view, the only thing that canbe observed is an increased latency for the loading of the webpage
when it employs Client-Side HB. However, the regular user cannot
be aware of all the HB (and other ad-tech) activity happening in the
background. This is where our HBDetector tool can help increasetransparency of the protocol from the point of view of the end-user,
and measure non-obvious aspects such as the communication andtime overhead for the browser during HB, winning bids, etc.

4.4

DSP
Internal auction(8) Fetch winning impression

Publisher

DSP
Internal auction

SSP

Internal auction

User tracking

SSP

Server-Side HB

In Server-Side HB, a single request is sent to a Demand Partner’sserver, which is responsible to do the whole HB process and send

Retrieve user information

Figure 7: Hybrid HB overview and steps followed.

back to the client only the winning impressions. As Demand Partners, in this scenario, we consider all possible ad partners (SSPs,
DSPs) that take part in the auction. Figure 6 shows the Server-Side
HB model and the steps performed by the user’s browser. The
careful reader will note a similarity of this model with Client-Side
HB with one Demand Partner. To distinguish Server-Side HB fromClient-Side HB, we check the responses sent back from the Demand
Partner involved to the browser, to filter out bid responses (which
would reveal Client-Side HB cases). This filtering using HB-related
keywords, also ensures that we are not mixing HB with traditional
waterfall activity. Obviously, in this model the publisher needs totrust that the Demand Partner (i.e., the server handling all requests)
is honest, will not execute waterfall in the backend instead of HB,
and will select the best bids as winners, thus providing the best
possible profits to the publisher.
Server-Side HB requires the least effort from the publishers tosetup their HB. However, in exchange for setup convenience, it
reduces transparency to the minimum, since the publishers have no
way of knowing the Demand Partners participating in the auctionsor their actual bids. Publishers don’t need to tune their library,nor set up an ad server. They just add to their webpage a preconfigured library, provided by the Demand Partner they choose
to collaborate with. Also, this setup could make small players lesscompetitive, compared to big ones with better infrastructure andhigher influence to the market, because publishers could tend totrust the latter ones. In effect, the Server-Side HB has re-enabled
the dominant players in RTB to regain control of the ad-bidding
process which was momentarily transferred on the user browser.
From the end-user’s point of view, this setup lacks transparency
and does not offer many insights on how the whole HB process
either works, performs, or what impact it has on the user’s browser:
all auctions are done in the background, at the ad server’s side. This
setup brings back the pros and cons of the typical RTB with ADXs
playing the crucial and controlling role in the protocol.

4.5

Hybrid HB

As its name states, this is a hybrid model that combines Client-Side
HB with Server-Side HB (Figure 7). In this model, the user fetches
the webpage which then requests bids from independent Demand
Partners (as in the Client-Side HB model). When the browser (HB
library) receives the bid responses, it sends them to the ad serveralong with the available slots. The ad server then performs its own

1.0

40

0.6

ECDF

20

DFP
AppN
e xu s
Rubi
con
Crite
o
Index
Ama
zon
Open
Pubm x
atic
AOL
Sovr
n
Sma
rt
Othe
r

0

0.4
0.0

Header Bidding Demand Partners

Figure 8: Top Demand Partners in HB. Google(with DFP) is present in 80% of websites with
HB. The rest of Demand Partners (N=73) havepresence in 36% of the websites with HB.

0

5
10
15
20
Number of demand partners

Figure 9: Demand Partners per website that
employes HB. More than 50% of publishers
use only one Demand Partner, but some use
as many as 20.

auction (as in the Server-Side HB model) and picks the final winning
impression(s) from all collected bids (both from client and serverside). This model tries to combine the pros of Client-Side HB andServer-Side HB, while avoiding their cons. It is a semi-transparent
model with a certain degree of fairness, which requires a moderate
degree of effort for the setup. Publishers can choose the Demand
Partners they will collaborate with directly, so they can know thebids they are willing to pay. Also they don’t need to operate theirown ad server, so the programmatic effort is reduced to tuning withthe selected Demand Partners.

4.6

Facet Breakdown

The 3 facets of HB that we observed and described above, have thefollowing breakdown as detected from the HBDetector in the wild
(no other cases were observed that could comprise a 4th category).
We find that the Server-Side HB currently comprises the larger
portion of the market with 48%. Then, the Hybrid HB is second
with 34.7%, and the Client-Side HB is third with 17.3%. This meansthat publishers prefer the centralization and control offered by aserver-side (or hybrid) model, which imposes a smaller overhead
and increases speed of transactions.
Indeed, the actors that provide both HB and waterfalling options
need to respect the protocols’ guidelines, otherwise they won’t
participate successfully in the HB process. Depending on the model
they are called to use in each auction, they have to use the appropriate notification channel and parameters to notify the browser.
As we will see in the next section, this highly skewed breakdown
towards server-side or hybrid is due to the presence of Google’s
DFP, which participates in many of these HB auctions.

5

100

10−1

0.2

ANALYZING THE HB ECOSYSTEM

Here, we analyze the data crawled in different dimensions:• Number, diversity and combinations of Demand Partners
participating in HB (Section 5.1)
• Latencies measured with respect to overall HB process,publishers and participating partners (Section 5.2)
• Auctions performed, bids received, bids taken into accountor got lost (Section 5.3)
• Properties of ads delivered: ad-slot prices paid and comparison with RTB prices. (Section 5.4)

5.1

D: DFP
C: Criteo
Y: Yieldlab
Am: Amazon
App: AppNexus
R: Rubicon
O: OpenX
I: Index
P: Pubmatic

101

D
Am, D
C
C, D
Y
Am
App, D
D, O
App, D, R
App, C, D, R
Am, D, Y
App, D, O
App, D, I
App, C, I, R
App, D, P, R

0.8

% of websites

60

102% of websites

80

Demand par ner combina ionsFigure 10: Most frequent Demand Partners
combinations. DFP owns the majority of themarket (48%). Criteo follows with 2.37% andYieldlab with 1.68%.

Demand Partners Involved in HB

As a next step, we examine the properties of Demand Partners
across the websites crawled and investigate who are the dominant
Demand Partners, how many participate per website, and how they
are combined together per webpage.
Who dominates the market?
First, we examine the popularity of each Demand Partner acrossall websites. We define as popularity the percentage of sites that agiven Demand Partner participates in the site’s HB process. In total,
we find 84 unique Demand Partners. Figure 8 shows the 11 mostpopular Demand Partners. As we can see, Google’s DoubleClickfor Publishers (DFP) is the most popular partner, with more than
80% of publishers utilizing it. The DFP can be used both as an adserver and as a server-side HB solution. Thus, it is not strange thatmost of the publishers choose this option over setting their own ad
server. We can also see that the list of top Demand Partners is fullof popular partners that can be found also in the waterfall standard,as presented in past works2 [35, 41]. These companies have alreadyinvested in the HB protocol and process early on, capitalizing on
their knowledge and market share in RTB, and most publishers
tend to choose these traditional big ad-partners over smaller ones.
How many Demand Partners are typically used?
A website can use more than one Demand Partner during the HBauction. But given that the more partners used could impact theloading time of the website, a question is what is typically employedby publishers. The number of unique Demand Partners participating in a HB auction are extracted from the incoming web requests
that trigger corresponding HB events at the browser, and detectedby the HBDetector (see Section 3.1 for details on the detection).
Figure 9 shows the CDF of the number of Demand Partners foundon each website. We can see that more than 50% of the websites
use only one Demand Partner. However, about 20% of the publishers collaborate with 5 or more Demand Partners, and about 5% of
publishers collaborate with ten or more Demand Partners.
Which Demand Partners are typically combined?
Demand Partners can appear on a website in different combinations.
Given that we already identified 3 types of HB setup (client-side,
server-side and hybrid), it is interesting to see how publishers select2 AppNexus, Index, Amazon, Rubicon, OpenX, AOL, Criteo, Pubmatic, and Sovrn, whichmatch exactly what the industry claims as the top HB bidders in Aug’19 reports [28]

30

1.0

Server-Side HB
Client-Side HB
Hybrid HB% of bids

20

0.6

rubiconappnexus
appnexus
appnexus
rubiconrubiconix
aduptech
ix
openx
ix
emx_digital
districtm
openx
brealtime
pubmatic
pubmatic
pubmatic
oftmedia
livewrapped
openx
brealtime
emx_digital
oftmedia
emx_digital
sovrn
districtm
smartadserver
oftmedia
sovrn

0.4

Figure 11: Top Demand Partners with respect to participation in HB
auctions, per facet of HB. Top 2 partners in all types are Rubicon and
AppNexus.

0.2
0.0

0

2

4
Latency (seconds)

6

Figure 12: Total HB latency per website. (1) Marks median latency of 600ms. (2) Marks a commonly used industry thresholdof 3 seconds which captures 90% of bid responses.

auctions. As expected, big DSPs like AppNexus and Rubicon holdthe highest shares, followed by Index Exchange.

3.5
3.0
Latency (seconds)

1

ECDF

10
0

2

0.8

2.5

5.2

2.0
1.5
1.0
0.5
0.0
1

2

3

4
5
6
7
Publishers (in buckets of 500)

8

9

10

Figure 13: HB latency Vs. domain popularity with respect to Alexa
ranking (in bins of 500 websites). Some outliers that goes as high as
10 seconds (removed for clarity).

different Demand Partners to participate in their HB auctions. We
should keep in mind that the mixture of partners selected can impact
the performance of HB with respect to delays and prices achieved.
Also, frequently selected combinations may reveal typical or unlike
competitions between Demand Partners. Therefore, we analyze thecommon combinations of Demand Partners found on webpages,
and show the top 15 with respect to popularity in Figure 10, out of
753 possible groups of competitors found.
As expected, DFP holds a majority of the market on its own (i.e.,
appearing without any competitors) in 48% of the cases. Interestingly, besides DFP which dominates the market as single-partner,
common groups of competitors include DFP in 51% of groups found.
Furthermore, Criteo and Yieldlab follow as single partners with
2.37% and 1.68%, respectively. Some popular pairs of competitors
include DFP and other companies such as Amazon, Criteo, andAppNexus. Finally, some triples include the above pairs with added
entities such as Rubicon, OpenX, etc.
Which Demand Partners are used in each HB facet?
Given the three HB facets, we anticipate that some Demand Partners
and publishers will prefer one facet of HB over another. Therefore,
we analyze the participation of Demand Partners into each type,in Figure 11. In contrast to Client-Side HB, which all the bidders
are transparent to the client, in Hybrid and Server-Side HB this is
not the case. For this reason, we analyze the responses from the adserver (most commonly the DFP) to find the partners who won the

Header Bidding Latency

In this section, we explore various aspects of Header Bidding such as
the imposed latency measured from different vantage points, withrespect to overall latency, publishers using it, number of partners
participating, etc. In all whiskers plots, we show 5th and 95th
percentiles, and the boxes show 25th and 75th percentiles, with a
red line for median (50th percentile).
How much latency does HB add?
The total latency of HB on a publisher’s webpage is defined as thetime from the first bid request to a Demand Partner (step 1 in Fig. 2)
until the ad server is informed and responds (step 3 in Fig. 2). In
Figure 12, we show the total time needed from the HB to process
the bid requests and responses. We see that the median latency isabout 600ms (point 1 in figure). However, some websites suffer amuch higher overhead. Indeed, about 35% percent of the websites
observe more than one second of latency, and as much as 4% of
websites observe more than 5 seconds of latency for the HB process
to conclude.
Based on our description so far, one might expect that a timeout
would be used during HB, to cut off responses from slow Demand
Partners. Although many of the wrappers use a timeout of 3 seconds, publishers are able to set their own threshold by making somechanges in the wrappers. Unfortunately, our results indicate that atleast 10% of the websites exceed the threshold of 3 seconds (point
2 in Figure 12), and some even need 20 seconds before the HB iscompleted (not shown in the figure for clarity of the other results).
Overall, even though most of the HB libraries strive to perform
HB activities in an asynchronous fashion, it appears that HB can
add significant overhead to a website if the library is badly tuned
and Demand Partners are slow to respond. In a recent report [11],the average page load time (PLT) of a webpage was measured at
8.66 seconds, which is above the median latency measured here for
HB. However, the industry recommends that the PLT should be
kept under 3 seconds [11], which would lead 10% of websites with
HB auctions experiencing time delays above this recommendation.
Does publisher popularity associate with HB latency?
As a next step, we study the latency measured with respect tothe ranking of each website. Someone could expect that highly

10

Piximedia
OneTagJustpremium
StickyAdsTV
Widespace
Polymorph
Yieldlab
Gjirafa
Atomx
Yieldbot
DFP
AppNexus
RubiconCriteoIndex
AmazonOpenx
Pubmatic
AOL
Sovrn
Smart
Trion
AdOceanFidelity
C1X
Yieldone
Aardvark
InnityBridgewell
Gamma SSP
Adgeneration

0

Figure 14: HB latency for the fastest partners (left-sideof plot), top partners in market share (middle-sectionof plot), and slowest partners (right-side of plot). Top
partners in market share are not the fastest.

8

40

6

30

4

20

2

10

0
1 3 5 7 9 11 13 15
Number of Demand Partners per website

Figure 14 shows the fastest, top and slowest Demand Partners,
respectively. We notice many small or unknown Demand Partners
in these lists. The fastest (slowest) Demand Partners have medianvalues in the range of 41-217ms (646-1290ms). Interestingly, thetop Demand Partners with respect to market share have latencies
that are small, but not low enough to qualify them for the fastest
partners (with the exception of Criteo which has a median latency
under 200ms).
Do multiple Demand Partners impact HB protocol’s latency?
As we mentioned earlier, a publisher may choose to use several
Demand Partners at the same time. Although this decision may
increase competition for the ad-slots offered, and can drive-up
the bidding prices, and consequently the publisher’s revenue, it
may also increase the latency of the webpage to load on the user’s
browser, and decrease the quality of the overall user experience.
Therefore, we explore the impact that the number of Demand Partners can have on the user experience with respect to latency.
Figure 15 shows the latency of websites vs. the number of Demand Partners each website has. We observe that publishers who
use only one Demand Partner have a small latency of 268.2 ms.
As can be seen by the second y-axis, this is the majority of websites. Also, publishers with two Demand Partners have a latency of1091.6 ms. Publishers with more than two Demand Partners have amedian latency in the range of 1.3-3.0 seconds. Does HB partner
popularity associate with HB latency?
Next, we study the latency of all 84 Demand Partners detected,
ranked based on their popularity in our dataset. In Figure 16, weshow the distribution of latencies observed per partner, when computed across all the websites each partner was found. We observe

600
400
200

0

Figure 15: Total HB latency (left y-axis)
and % of websites found (right y-axis) vs.
number of Demand Partners per website.
Publishers with more than one partner
tend to have higher page load times.

ranked publishers seek to have lower latencies for their websites,
and therefore add partners in their HB process who demonstratelower latencies. Also, higher-ranked websites may have available
more resources to use in their HB planning, which could lead to
reduced latencies and better performance. In Figure 13, we show thelatency of publishers vs. their Alexa ranking. Indeed, we find thatthe highest-ranked publishers (i.e., the first 500 websites) exhibit
significantly lower latencies (median = 310ms), than the rest of theranked websites (median = 500ms).
Which are the fastest and slowest Demand Partners?

800
Latency (ms)

500

1000
50
% of websites

1000

Latency (seconds)

Latency (ms)1500

10 20 30 40 50 60 70 80
Demand Partner Popularity Rank (bins of 10)
Figure 16: Distribution of latencies observed per Demand Partner across all
the websites. Partners are ranked basedon popularity. Popular partners tend tohave latencies with smaller variability.

that the most popular partners tend to have latencies with smaller
variability (up to 200ms), in comparison to the less popular partners
who may exhibit latency variability up to 500-1,000ms.
How many bids are late?
Here, we analyze the portion of bids that arrive too late to be
included in the auction. As late bids we define all the responses
about bids from Demand Partners which arrive too late, i.e., after
the request to the ad server is sent from the browser. Thus, it isimportant to understand what is the portion (and number) of bids
that were received from the browser, that came too late and were
not considered in the HB auction. In Figure 17, we show the CDF
of the portion of such late bids with respect to the total number ofbids received at a website for the HB auction. We see that in 50% of
the cases with late bids, almost 50% of the bid responses come toolate to be considered in the auction by the ad server. Also, for 10%of the auctions, more than 80% of the bids are late. In results notshow here due to space, we measured that in 60% of the auctions,
there was only one late bid, in 40% of the auctions there was atleast two late bids, and in 20% of auctions at least four late bids.
In Figure 18, we measure the percentage of late bids per Demand
Partner. We notice that 21 Demand Partners bid too late in 50% of
the auctions they participate. In some extreme cases, the Demand
Partner loses 100% of the bids they send. All these late bids point
to the possible loss of revenue from the publisher. This could be
the result of a poorly defined wrapper that sends the request to thead server the same time it sends the requests to Demand Partners,
without waiting for their responses first, as well as Demand Partners
that do not have the proper infrastructure to respond fast enoughto all incoming requests.

5.3

Auctioned Ad-slots

In this section, we investigate the properties of the auctioned adslots, such as the size, the number of auctions per website, and how
this impacts the overall performance of the protocol.
How many ad-slots are auctioned per webpage?
We start by investigating the number of ad slots that are available
for auction. In Figure 19, we plot the CDF of the number of ad-slots
across the websites, per HB type. In general, and for up to 70% of
websites, the Hybrid HB type auctions more ad-slots than the othertwo types. For the other 30% of websites, Server-Side HB auctions

ECDF

0.6
0.4

1.0

80

0.8

60
40

0.0

20

40
60
80
% of bids late from total bids per auction

Figure 17: Portion of late bids over the total bids received, due to high latency of apartner to respond. For 10% of auctions,they have 80% or more late bids.

0.4

20

0

0.2

0.6

ECDF

0.8

100

Atomx
Lifestreet
AdMatic
Piximedia
Consumable
Spotx
FreeWheel
LKQD
TremorInSkinAdKernelAdn
Quantum
SmartyAds
Clickonometrics
Justpremium
Adgeneration
Kumma
Yieldlab
Bridgewell
E-Planning
InnityAdOcean
C1X
ImproveDigital
Yieldone% of the late bids

1.0

Figure 18: Percentage of late bids out of all bids
sent per Demand Partner. Some partners have all
their bids arriving too late to be considered forauction.

Client-Side HB
Server-Side HB
Hybrid HB

0.2
0.0

0

5
10
15
Auctioned ad-slots per website

Figure 19: Auctioned ad-slots across websites, per HB facet. The median website has
2-6 available ad-slots. 90% of websites have
5-11 ad-slots (depending on the HB type).

8Server-Side HB
Client-Side HB
Hybrid HB

50

6% of ad-slots

40

Latency (seconds)

20

30

4

20
0

0
1

2

3

4

5

6 7 8 9 10 11 12 13 14 15
Auctioned ad-slots per website

Figure 20: HB latency as a function of the number of ad-slots
auctioned. More ad-slots result in higher median latency andvariability in latency for the HB process.

more ad-slots. The median website has 2-6 available ad-slots, and
90% of websites have up to 5-11 ad-slots (depending on the HB type).
Also, 3% of the websites provide more than 20 slots for auction.
Requesting bids for 20 ad-slots on a single page can be consideredodd, even a flag for suspicious or fraudulent behavior. Therefore,
we manually investigated such cases, and to our surprise, we foundthat some publishers request auctions for more slots than they haveavailable for display. After investigating this behavior further, weobserved that these ad-slots refer to several different devices andscreen sizes such as for tablet, smartphone, laptop, etc. We speculate
they do that due to either bad configuration of their wrapper (i.e.,they use the same HB wrapper for all the devices they serve without
customizing the requests), or because they want to receive bids for
multiple versions of the same ad-slots, for better optimization of
the publisher’s HB process later on. Indeed, this odd activity needs
to be studied in depth in the future, to understand if it is a matterof bad practice or an effort for ad-fraud.
Does the number of auctioned ad-slots impact latency?
Next, we checked if the HB latency is associated with the numberof ad-slots auctioned. Intuitively, we may expect that the moreslots are to be auctioned, the more time the HB will take. However,given that a lot of Demand Partners invest significant computing

300x250300x250300x250728x90300x600
728x90300x600
728x90300x600
320x50970x250
320x50970x250320x320970x250160x600
320x50160x600
336x280160x600
320x100
970x90100x200
336x280320x100
120x600
300x50468x60320x100
120x600

102ad-slot dimensions

Figure 21: Portion of ads for different HB ad sizes, per HB facet. The
side banner (300x250) and top banner (728x90) are among the mostpopular ad-slot sizes in all HB facets.

resources to parallelize and optimize bidding computations, theabove statement may not hold. In Figure 20, we plot the latency of
HB based on the number ad-slots auctioned in the website. In the
majority of cases, this latency includes the communication to the adserver. In Client-Side HB, we cannot know the ad server (since eachpublisher uses their own), so we have no means to infer this latency.
We observe that the total latency tends to increase with the numberof slots auctioned. In fact, when there are 1-3 ad-slots auctioned,
the median latency is 0.30-0.57 seconds, but when the slots are 3-5,
the median latency ranges to 0.57-0.92 seconds. Interestingly, weobserve that even if there is only one ad-slot to be auctioned, thelatency can still vary per auction, from a few tens of milliseconds
to almost two seconds. This variability can be due to extra latencies
as result of internal auctions occurring at each Demand Partner.
What are the most popular ad-slots auctioned?
Finally, we analyze the most popular dimensions of HB ad slots.
Our findings are presented in Figure 21, per facet of HB. The mostcommon ad size is the 300x250 (side banner), for all 3 facets. The
second most common is the 728x90 (top banner) and the 300x600(for the Client-Side HB). These are generally popular banners inboth mobile and desktop advertising, and they match results observed in the past for RTB [41]. Due to the increase of mobile

4.0

1.0

3.5

0.8

Bid price (CPM)

3.0
2.5

ECDF

0.6

2.0

0.4

1.5

0.2

1.0

Client-Side HB
Server-Side HB
Hybrid HB

0.0
0.0

0.5

0.5
1.0

1.5
Bid price (CPM)

2.0

2.5

Figure 22: CDF of the auctioned ad slots bid prices, per HB facet.
These are baseline prices that Demand Partners are willing to spend
when they have no information for the user.

Bid price (cpm)

0.6
0.4
0.2

0

0
300x5

00

0

320x5

300x1

00

728x9

120x6

0

80
336x2

50

00
160x6

300x2

00
300x6

970x9

50
970x2

0.0

Ad-slot dimensions, sorted by area

Figure 23: Distribution of bid prices in CPM per ad-slot size (x-axis
sorted by area of ad-slot). Even in our crawler’s baseline scenario,
partners bid high prices to reach users.

browsing, publishers can choose these specific sizes to keep the
HB configuration simple and well defined for multiple devices (asthey don’t need to set multiple sizes for different devices, and fewer
auctions need to occur on the Demand Partners’ side).

5.4

0.0

3.0

Ad-slot Bid Prices

In this section, we discuss the auctioned ad-slots’ bid prices andhow they vary depending on their size. We were able to detect thead prices using HBDetector. In case of Hybrid and Client-Side HB,
most of the prices are transparent to the client and easy to extractfrom the bid response messages. In contrast, in Server-Side HB theprices are not trivial to detect. We analyze in depth the auction
metadata, and based on several heuristics we find and extract theprices whenever they are included.
What are the HB partners willing to pay?
First, we analyze the prices bided by the Demand Partners during
the auctions. In Figure 22, we show the CDF of the baseline bid
prices (in CPM or cost per thousand ad impressions, in USD) thatadvertisers are willing to spend for the ad-slots auctioned, per typeof HB. In general, we note that Client-Side HB draws higher bid
prices for the publisher, in comparison to the other two types. Also,
more than 20% of the prices are more than 0.5 CPM, which is lower
but comparable to regular waterfall prices, as claimed in past studies(found to be ∼1 CPM [41]). Also, we should note that these prices
are baseline, so they are much lower than if they were referring totargeted users.

1

2
3
4
5
Demand Partner Popularity Rank (bins of 10)

6

Figure 24: Distribution of prices that partners bid, ranked by popularity of Demand Partner (who are grouped in bins of 10).

What are the HB partners paying per ad-slot?
Second, we compare ad-slot sizes with bid prices for each size. In
Figure 23 we plot the prices (in CPM) for each ad-slot. We see thatin the recorded dimensions, the median cost ranges from 0.000840.096 CPM. The most expensive ad-slot (based on median price)is 120x600 with 0.096 CPM. The cheapest ad-slot is 300x50 (which
also happens to have the least ad-area) with 0.00084 CPM. Also,
the most popular ad-slot size, which is 300x250, has a median costof 0.031 CPM. Previous studies on waterfall standard [41] find theprices of 300x250 slot ranging from 0.1 to 1.4 CPM, with a medianof 0.19 CPM. These prices are higher than the ones found in our HBstudy, but we should again consider that our detected prices arefor baseline users that Demand Partners have no prior knowledge,
whereas in [41] it was for real users. Therefore, a follow-up work
could apply real user profiles to collect HB prices, and thus, make amore fair comparison with RTB prices.
What is the variability of bid prices per DSP?
In Figure 24, we plot the prices (in CPM) that each Demand Partner
bid to examine possible association between a partner’s popularityand how high they bid in HB. The DSPs are ranked by popularityand grouped in buckets of 10 to ease illustration. The most popularpartners (first bins) tend to be more consistent and bid lower prices.
In contrast, less popular DSPs have higher median bid prices andvariability in their bids. This observation could be explained when
considering how the HB market works: for less popular DSPs to becompetitive and win auctions, they bid higher prices than popularpartners to reach sufficient number of users. Alternatively, this result could also indicate that more popular partners have technologythat detects when browsing is of a baseline (or bot/unknown) user
and therefore do not bid high, whereas the less popular partners
bid high, hoping to target a real user. Finally, it can also be a side
effect of how Demand Partners decide to spend their budget acrossthe websites they collaborate with: more popular partners exist in
more websites, and may chose to bid low in many of them, to covera wider range of websites.

6

RELATED WORK

User data and their economics have long been an interesting topic
and attracted a considerable body of research [2, 13, 21, 22, 35, 37,
41, 46, 47, 51, 53, 56]. In particular, Acquisti et al. discuss the valueof privacy after defining two concepts (i) Willingness To Pay: themonetary amount users are willing to pay to protect their privacy,

and (ii) Willingness To Accept: the compensation that users arewilling to accept for their privacy loss [2]. In two user-studies [13,51] authors measure how much users value their own offline andonline personal data, and consequently how much they would sellthem to advertisers. In [47], authors propose “transactional” privacy
to allow users to decide what personal information can be released
and receive compensation from selling them.
Papadopoulos et al. set out to explore the cost advertisers pay
to deliver an ad to the user in the waterfall standard and RTB
auctions [41]. In addition, they study how the personal data thatusers leak while browsing (like location and interests) can affect thepricing dynamics. The authors propose a methodology to computethe total cost paid for the user even when advertisers hide thecharged prices. Finally, they evaluate their methodology by using
data from a large number of volunteering users. Olejnik et al.
perform an analysis of cookie matching in association with the
RTB advertising [35] . They leverage the RTB notification URL toobserve the charge prices and they conduct a basic study to provide
some insights into these prices, by analyzing different user profiles
and visiting contexts. Their results confirm that when the users’
browsing histories are leaked, the charge prices tend to be increased.
In [39], the authors measure the costs of digital advertising on boththe user’s and the advertiser’s side in an attempt to compare how
fairly these costs are distributed between the two. In particular,
they compare the cost advertisers pay in the waterfall standard
with the costs imposed on the data plan, the battery efficiency and(by using cookie synchronization [1, 38, 40] as a metric) the privacyof the specific user.
In [31], the authors briefly describe HB and focus on optimizing
its bidding strategy and the produced yield. They consider revenue
optimization as a contextual bandit problem, where the context
consists of the information available about the ad opportunity, suchas properties of the internet user or of the provided ad slot. In [21],authors use a dataset of users’ HTTP traces and provide roughestimates of the relative value of users by leveraging the suggested
bid amounts for the visited websites, based on categories provided
by the Google AdWords. FDTV [22] is a plugin to inform users inreal-time about the economic value of the personal information
associated to their Facebook activity. In [30], Iordanou et al. try todetect both programmatic and static advertisements in a webpage,using (i) a crowdsourcing, and (ii) a crawling approach to determine
the criteria with which ads are displayed. They find biases on ads
depending on age, income and gender of users.
Bashir et al. study the diffusion of user tracking caused by RTBbased programmatic ad-auctions [6]. Results of their study showthat under specific assumptions, no less than 52 tracking companies
can observe at least 91% of an average user’s browsing history. In
an attempt to shed light upon Facebook’s ad ecosystem, Andreou
et al. investigate the level of transparency provided by the mechanisms “Why am I seeing this?” and Ad Preferences Page [4]. The
authors built a browser extension to collect Facebook ads and information extracted from these two mechanisms before performing
their own ad campaigns and target users that used their browser
extension. They show that ad explanations are often incomplete
and misleading. In [5], the authors aim to enhance the transparency
in ad ecosystem with regards to information sharing, by developing
a content agnostic methodology to detect client- and server- side

flows of information between ad exchanges and leveraging retargeted ads. By using crawled data, the authors collected 35.4K ad
impressions and identified 4 different kinds of information sharing
behavior between ad exchanges.

7

SUMMARY & DISCUSSIONHeader Bidding is gaining popularity among Web publishers, whowant to regain the control of their ad inventory and what advertisers are paying for it. Proponents of HB have touted that this new
ad-tech protocol increases transparency and fairness among advertisers, since more partners can directly compete for an ad-slot. HB,in theory, can boost the revenue of publishers, who can select the
Demand Partners that are competing for the publishers’ ad-slots,
and also remove intermediaries from the ad-selling process.
In this study, we investigate and present in full detail the different implementations of HB and how each of them works. Based onthese observations, we design and implement HBDetector: a firstof its kind tool to measure in a systematic fashion the evolving
ecosystem of HB, its performance and its properties. By running
HBDetector across a list of top 35,000 Alexa websites, we collected
data about 800k HB auctions and performed the first in-depth analysis of HB. We discuss our lessons from this study in the next
paragraphs.

7.1

Commoditization of Ad Supply

Header Bidding was introduced to put Demand Partners underpressure for more competitive pricing (and loosen Google’s grip on
the market). Indeed, it has changed the hierarchy on the supply side.
Depending on the publisher’s needs, we found that Header Bidding
can be implemented in 3 ways: (i) Client-Side HB, (ii) Server-Side
HB, and (iii) Hybrid HB. Therefore, Demand Partners that could
previously claim exclusive access to a publisher’s inventory (andthus higher positions in the waterfall) are no longer able to do so.
Instead, HB enabled all Demand Partners regardless of their sizeor relationship with publishers, to compete for the same inventory,
thus commoditizing supply [16].
However, as measured in this study, big companies such as DoubleClick, AppNexus, Rubicon, Criteo, etc., took advantage of their
existing dominance in the ad-market and placed themselves again
in a very centralizing (and process controlling) position within the
HB ecosystem (especially within the Server-Side HB and Hybrid HB
models). In fact, we identified that Server-Side HB dominates thismarket with 48% of auctions handled by a single partner/ad server.
Google, in particular, handles as much as 80% of HB auctions. DoubleClick for Publishers (DFP) dominates as a single partner, while italso appears in 51% of the competing groups of Demand Partners in
HB. Also, most publishers use only one Demand Partner, but someuse many (more than 10). Interestingly, this centralization is in
direct contrast to the publishers’ revenue. We found that websites
utilizing Client-Side HB achieve higher bid prices than the othertwo models.

7.2

Non-Viable Performance Overheads

The fear of latency has kept some premium publishers away fromheader integrations and continues to make others wary about embracing HB. Results of this study verify the concerns of publishers [14, 18] regarding the latencies imposed on the user side. We
measured up to 0.6 seconds for the median website and more than
3 seconds in 10% of websites. Furthermore, publishers with morethan one Demand Partner experienced higher HB latencies: one
Demand Partner imposes a small latency of 0.3 seconds, but 2 Demand Partners impose 1.1 seconds latency, and 3 Demand Partners
can impose up to 3 seconds latency. It is of no doubt that for the
publishers that do the utmost to provide readers with a high-quality
experience, such latency is capable of significantly degrading theuser experience. Interestingly, we find that the top 500 (in Alexa
ranking) websites exhibited significantly lower HB latency than
the rest of websites.
Although Header Bidding tech promises multiple, in-parallel bid
requests to Demand Partners that can provide the best possible ad
price to the publisher, Javascript on the users’ end is single-threaded.
This means that even if the HB provider’s wrapper performs welloptimized asynchronous ad calls, these still need to stand in the
network queue, thus increasing not only the overall HB execution
time but also the entire webpage’s loading time. These delays canhave adverse effects on user’s browsing experience while loadinga HB-enabled webpage. Interestingly, we find that the 10 mostpopular Demand Partners exhibit lower variability in latency than
the rest, demonstrating that they invest appropriate resources toreduce latencies at the user-end.

7.3

Late Bids: Revenue & Network Cost

The broadcasting nature of Header Bidding results in an enormous
amount of bid requests to multiple Demand Partners. As measured
in this study, a typical website has a small number of available
ad-slots (i.e., 2-6 ad-slots for the median case, depending on thetype of HB), but some auctions request for more ad-slots than they
have available to show (even up to 20). Side banner and top banner
are the most popular ad-slots auctioned in HB. For each ad-slot, aparallel auction takes place that requests bids from numerous DSPs.
As expected, the more ad-slots present in a webpage, the higher theoverall HB latency: when 1-3 ad-slots are auctioned, the medianlatency is 0.3-0.57 seconds, but for 3-5 slots, the median latency is
0.57-0.92 seconds.
This overwhelming volume of bid requests significantly increases
the needed processing power for ADXs and the decision enginesof DSPs, thus skyrocketing their infrastructure costs [17]. Indeed,
companies that started supporting HB experienced increases of up
to 100% in the bid requests they received [50] (i.e., between 5 million
and 6 million requests per second) for the very same number ofavailable ad-slots as before. Interestingly, the same partners may
in fact compete for the same ad-slots more than once: in the HB,
and then in the regular waterfall model, since the publisher may
still fall back to the waterfall if the HB does not reach high enoughprices for the auctioned slots [17].
Apart from skyrocketing the infrastructure costs, the increased
amount of bid requests also increases the response time for DSPs,
causing lots of delayed bids. We found that in more than 50% of

auctions, half of bid responses arrive too late (after the publisher’s
set threshold) to be considered, due to high latency. These latebids not only are wasted network resources and processing powerfrom the point of view of the Demand Partners, but also loss ofpotentially higher revenues for publishers.

7.4

Limitations & Future Work

The present work is a first, comprehensive study of the HB protocol, and an effort to measure the ecosystem and partners involved.
Unfortunately, HB documentation is scarce at best, and it has beena feat to reverse-engineer the protocol, and understand the numerous HB libraries used by the crawled websites. Due to several
limitations in the data collection process, in the present study, we
focused on specific dimensions and left others for future work. In afollow-up work on HB, it is important to address the limitations of
our HBDetector, and also perform extensions to study aspects notcovered in this work:• Perform extensive analysis of all available HB libraries, to increase coverage of the ecosystem and websites employing HB.
• Study in detail the impact that HB has on the UX and pageload time of each website, as well as the various hosting infrastructures responsible for the crawled websites, locations of
Demand Partners involved, and categories of websites to findassociations with HB prices and latencies.
• Investigate the privacy of online users accessing HB-enabledwebsites for potential PII leaks, and measure the impact that
HB may have on user anonymity, as well as the use of HTTP
vs. HTTPs for HB transactions.

ACKNOWLEDGEMENTS
We thank the anonymous reviewers and our shepherd Narseo Vallina Rodriguez, for the insightful comments and help to improve
the present manuscript. The research leading to these results hasreceived funding from EU Marie Sklodowska-Curie and Horizon
2020 Research & Innovation Programme under grant agreements
690972 and 786669, respectively. The paper reflects only the authors’view and the Agency and the Commission are not responsible forany use that may be made of the information it contains.

REFERENCES[1] Gunes Acar, Christian Eubank, Steven Englehardt, Marc Juarez, Arvind
Narayanan, and Claudia Diaz. The web never forgets: Persistent tracking mechanisms in the wild. In Proceedings of the 2014 ACM SIGSAC Conference on Computerand Communications Security, 2014.
[2] Alessandro Acquisti, Leslie K John, and George Loewenstein. What is privacy
worth? The Journal of Legal Studies, 2013.
[3] Alexa. Alexa, the top sites on the web. https://www.alexa.com/topsites.
[4] Athanasios Andreou, Giridhari Venkatadri, Oana Goga, Krishna Gummadi,
Patrick Loiseau, and Alan Mislove. Investigating ad transparency mechanisms
in social media: A case study of facebook’s explanations. In Proceedings of the
Network and Distributed System Security Symposium (NDSS), 2018.
[5] Muhammad Ahmad Bashir, Sajjad Arshad, William Robertson, and Christo
Wilson. Tracing information flows between ad exchanges using retargeted ads.
In 25th USENIX Security Symposium, 2016.
[6] Muhammad Ahmad Bashir and Christo Wilson. Diffusion of user tracking data inthe online advertising ecosystem. Proceedings on Privacy Enhancing Technologies,
2018.
[7] Ross Benes. An ad tech urban legend: An oral history of how header bidding
became digital advertising’s hottest buzzword. https://digiday.com/media/headerbidding-oral-history/, 2017.

[8] Ross Benes. How latency emerged as publishers’ worst user-experience
headache. https://digiday.com/media/latency-emerged-publishers-worst-userexperience-headache/, 2017.
[9] Ross Benes.
The state of header bidding in 4 charts.
https://digiday.com/media/state-header-bidding-4-charts/, 2017.
[10] Ricardo Bilton. With header bidding, publishers are boosting cpms by as muchas 50 percent. https://digiday.com/media/header-bidding-publishers-boostingcpms-much-50-percent/, 2015.
Site speed tips for performance nerds.
[11] Machmetrics Speed Blog.
https://www.machmetrics.com/speed-blog/average-page-load-times-websites2018/, 2018.
[12] The Ad-Juster Blog. Key differences between direct-sold and programmatic
advertising. https://blog.ad-juster.com/differences-between-direct-sold-andprogrammatic-advertising/, 2017.
[13] Juan Pablo Carrascal, Christopher Riederer, Vijay Erramilli, Mauro Cherubini,and Rodrigo de Oliveira. Your browsing behavior for a big mac: Economics of
personal information online. In Proceedings of the Conference on World Wide Web(WWW). ACM, 2013.
#opspov:
How header bidders affect latency.
[14] Chris 13.
https://www.admonsters.com/opspov-how-header-bidders-affect-latency/, 2016.
[15] Jessica Davies. Beware of page latency: The side effects to header bidding.
https://digiday.com/uk/beware-page-latency-side-effects-header-bidding/, 2016.
[16] Jessica Davies. Behind the bid-caching debate, signs of ad tech commoditization. https://digiday.com/media/behind-bid-caching-debate-signs-ad-techcommoditization/, 2018.
[17] Jessica Davies.
The winners and losers of header bidding.
https://digiday.com/media/header-bidding-winners-losers/, 2018.
[18] Avin Dunaway. The truth about latency and the header: A chat with pubmatic.
https://www.admonsters.com/truth-latency-header-pubmatic/, 2018.
[19] eMarketer Inc.
Five charts:
The state of header bidding.
https://www.emarketer.com/content/five-charts-the-state-of-header-bidding,
2019.
Fisher.
Headerbidding
update2018.
[20] Lauren
https://www.emarketer.com/content/header-bidding-update-2018, 2018.
[21] Phillipa Gill, Vijay Erramilli, Augustin Chaintreau, Balachander Krishnamurthy,
Konstantina Papagiannaki, and Pablo Rodriguez. Follow the money: Understanding economics of online aggregation and advertising. In Proceedings of theInternet Measurement Conference (IMC). ACM, 2013.
[22] José González Cabañas, Angel Cuevas, and Rubén Cuevas. Fdvt: Data valuation
tool for facebook users. In Proceedings of the 2017 CHI Conference on Human
Factors in Computing Systems. ACM, 2017.
[23] Goodway Group.
2018 header bidding trends: The update you needto read. https://www.mediapost.com/publications/article/332220/in-app-adsheader-bidding-enjoy-solid-growth.html, 2018.
[24] Google. Google publisher tag. https://developers.google.com/doubleclickgpt/reference.
[25] Kean
Graham.
What
is
a
bid
request?
https://www.monetizemore.com/blog/what-is-a-bid-request/, 2018.
[26] Goodway Group. 2018 header bidding trends: The update you need to read.
https://goodwaygroup.com/blog/2018-header-bidding-trends-update, 2018.
[27] The Interactive Advertising Bureau (IAB). Openrtb (real-time bidding).
https://www.iab.com/guidelines/real-time-bidding-rtb-project/, 2019.
[28] Adzerk Inc. Header bidding industry index. https://adzerk.com/hbix/, 2019.
[29] Internet Archive.
Internet archive:
The wayback machine.
https://archive.org/web/, 2019.
[30] C. Iordanou, N. Kourtellis, J.M. Carrascosa, C. Soriente, R. Cuevas Rumin, and
N. Laoutaris. Beyond content analysis: Detecting targeted ads via distributed
counting. In Proceedings of the International Conference on emerging Networking
EXperiments and Technologies (CONEXT). ACM, 2019.
[31] Grégoire Jauvion, Nicolas Grislain, Pascal Dkengne Sielenou, Aurélien Garivier,and Sébastien Gerchinovitz. Optimization of a ssp’s header bidding strategy
using thompson sampling. CoRR, abs/1807.03299, 2018.
[32] OKO Ad Managment. Ad waterfalls explained. https://oko.uk/blog/ad-waterfallsexplained, 2019.
[33] Mozilla.
Mdn web docs.
https://developer.mozilla.org/enUS/docs/Web/API/EventTarget/addEventListener.
[34] Lukasz Olejnik and Claude Castelluccia. To bid or not to bid? measuring thevalue of privacy in rtb. Technical Report, 2015.

[35] Lukasz Olejnik, Minh-Dung Tran, and Claude Castelluccia. Selling off user
privacy at auction. In 21st Annual Network and Distributed System Security
Symposium, NDSS, 2014.
[36] Gavin O’Malley.
In-app ads, header bidding enjoy solid growth.
https://www.mediapost.com/publications/article/332220/in-app-ads-headerbidding-enjoy-solid-growth.html, 2019.
[37] Michalis Pachilakis, Panagiotis Papadopoulos, Nikolaos Laoutaris, Evangelos P
Markatos, and Nicolas Kourtellis. Measuring ad value without bankrupting user
privacy. arXiv preprint arXiv:1907.10331, 2019.
[38] Panagiotis Papadopoulos, Nicolas Kourtellis, and Evangelos Markatos. Cookie
synchronization: Everything you always wanted to know but were afraid to ask.
In Proceedings of the World Wide Web Conference (WWW). ACM, 2019.
[39] Panagiotis Papadopoulos, Nicolas Kourtellis, and Evangelos P Markatos. The costof digital advertisement: Comparing user and advertiser views. In Proceedings ofthe World Wide Web Conference (WWW). ACM, 2018.
[40] Panagiotis Papadopoulos, Nicolas Kourtellis, and Evangelos P. Markatos. Exclusive: How the (synced) cookie monster breached my encrypted vpn session.
In Proceedings of the 11th European Workshop on Systems Security, EuroSec’18,
pages 6:1–6:6, New York, NY, USA, 2018. ACM.
[41] Panagiotis Papadopoulos, Nicolas Kourtellis, Pablo Rodriguez Rodriguez, andNikolaos Laoutaris. If you are not paying for it, you are the product: How muchdo advertisers pay to reach you? In Proceedings of the Internet Measurement
Conference (IMC). ACM, 2017.
[42] Wing Poon. Now that in-app header bidding is finally here, is the waterfall
era truly over? https://blog.appodeal.com/waterfall-parallel-bidding-part-one/,2018.
[43] Prebid. Publisher api reference. http://prebid.org/dev-docs/publisher-apireference.html.
[44] Prebid. Bidder params. http://prebid.org/dev-docs/bidders.html, 2019.
[45] Prebid.org. Prebid - header bidding unwrapped. http://prebid.org, 2017.
[46] Abbas Razaghpanah, Rishab Nithyanand, Narseo Vallina-Rodriguez, Srikanth
Sundaresan, Mark Allman, and Christian Kreibich Phillipa Gill. Apps, trackers,
privacy, and regulators. In Proceedings of the Network and Distributed System
Security Symposium, NDSS’18, 2018.
[47] Christopher Riederer, Vijay Erramilli, Augustin Chaintreau, Balachander Krishnamurthy, and Pablo Rodriguez. For sale : Your data: By : You. In Proceedings ofthe 10th ACM Workshop on Hot Topics in Networks, 2011.
[48] Quirin Scheitle, Oliver Hohlfeld, Julien Gamba, Jonas Jelten, Torsten Zimmermann, Stephen D. Strowes, and Narseo Vallina-Rodriguez. A long way to thetop:, significance, structure, and stability of internet top lists. In Proceedings ofthe Internet Measurement Conference (IMC). ACM, 2018.
[49] Sarah Sluis.
The year header bidding went mainstream.
https://adexchanger.com/publishers/year-header-bidding-went-mainstream/,
2016.
[50] Sarah Sluis. Header bidding unleashed a huge infrastructure problem and ad techwill either sink or swim. https://adexchanger.com/platforms/header-biddingunleashed-huge-infrastructure-problem-ad-tech-will-either-sink-swim/, 2017.
[51] Jacopo Staiano, Nuria Oliver, Bruno Lepri, Rodrigo de Oliveira, Michele Caraviello, and Nicu Sebe. Money walks: A human-centric study on the economicsof personal mobile data. In Proceedings of the ACM International Joint Conference
on Pervasive and Ubiquitous Computing, 2014.
[52] Statista. Growth rates of monetized header bidding advertising impressions volume worldwide from 1st quarter 2017 to 3rd quarter 2018, by device. https://www.statista.com/statistics/812228/header-bidding-ad-impressionchange/, 2019.
[53] Narseo Vallina-Rodriguez, Srikanth Sundaresan, Abbas Razaghpanah, Rishab
Nithyanand, Mark Allman, Christian Kreibich, and Phillipa Gill. Tracking the
trackers: Towards understanding the mobile advertising and tracking ecosystem.
arXiv preprint arXiv:1609.07190, 2016.
[54] Ratko Vidakovic.
Header bidding: What marketers need to know.
https://marketingland.com/header-bidding-marketers-need-know-199311, 2017.
[55] Ted Vrountas. Simplifying the header bidding process & what marketers should
know. https://instapage.com/blog/what-is-header-bidding, 2018.
[56] Apostolis Zarras, Alexandros Kapravelos, Gianluca Stringhini, Thorsten Holz,
Christopher Kruegel, and Giovanni Vigna. The dark alleys of madison avenue:
Understanding malicious advertisements. In Proceedings of the Internet Measurement Conference (IMC). ACM, 2014.