In-App Header Bidding Explained

Header bidding is a great equalizer and a direct upgrade to real-time bidding (RTB). It’s a cool piece of technology that enables equal bidding opportunities. While having equal bidding opportunities sounds obvious now, it wasn’t possible up until recently, not for mobile ads market at least. In-app header bidding solves just that, but in order to better understand this algorithm, we have to go back in the past and trace the history of advertising up to this day.

History of ads 101

At the dawn of marketing as an industry, the conditions for ad placement used to be negotiated tête-à-tête between a publisher and advertiser. It took a lot of time, efforts, nerves, and was suboptimal overall. With the advent of computers and digital marketing, the programmatic advertising started to gain momentum.

While negotiating online is good in terms of saving time, bidding online is even better. Initially, the ads were served through a daisy-chain process, a.k.a. “Waterfall” or “Waterfall tags”. Ad placement requests are served sequentially within this setup. In other words, some advertisers get the privilege of participating in the auction before the competitors do. The priority is usually set, based on the Estimated Cost-per-Mille (CPM). There is also a price floor that publishers want to achieve.

Source: Liftoff

Basically, advertisers with a well-established reputation get to place their bets first. If the price floor is not met, then the next round for those with lower estimated CPM begins, up until the price floor is met. This causes at least two problems.

First come — first serve: the ad spot is typically awarded not to the highest bidder, but to the first advertiser in line. The lack of a long-term partnership with the publisher makes it improbable to win the impression, no matter the bid size.

Affiliates and media buyers suffer from this kind of bottleneck, but publishers are also handicapped. Instead of earning the maximum bid, they settle for the price floor, which is a missed opportunity: the underdogs might want to pay higher but have no chance to do so.

Source: Liftoff

With the technological advancement, it became possible to bid across multiple platforms in real time by sending requests simultaneously. Real-Time Bidding (RTB) is a subset of programmatic ads, where Supply Side Platforms (SSP) and Demand Side Platforms (DSP) sell and buy ad inventory in milliseconds, respectively.

A subset of RTB is Header Bidding, with the core element being a header code, located in the website header. Once someone visits the website, the browser requests an ad serving for a particular page.

1. A browser or server sends a request to SSP, where publishers sell their ad spots automatically
2. An SSP handles the request and pushes it forward to an ad exchange, where SSP meets DSP
3. Ad exchange pushes it further to DSP — the advertiser’s software for programmatic campaigning
4. DSP scans the publisher’s inventory and matches it to the advertiser’s, based on the targeting options
5. Advertisers bid simultaneously on the desired spot until the timer runs out and the highest bidder ads are shown

In-app header bidding

Header bidding has been around since 2015 and has become the go-to solution on the WEB. Mobile traffic on the other hand had no such option, mainly due to technical limitations and the absence of headers up until now.

Source: Liftoff

Much like its desktop sibling, in-app header bidding has a couple of advantages over the traditional waterfall method that the publishers will enjoy:

• Header bidding sells the ad inventory to the highest bidder, not the first suitable one
• Header bidding happens in real-time, thus decreasing the latency of sequential requesting
• Header bidding doesn’t need ad server adjustments unlike waterfall, which tags have to be updated now and then
• Header bidding increases demand, unlike waterfall, which favors the already known sources
• Header bidding improves the fill rate, while waterfall can fail to sell the inventory on time

Increased demand makes the CPM price climb higher, but that does not mean the advertisers are worse off. On the contrary, in-app header bidding benefits the advertisers too:

• Header bidding grants access to more traffic sources, which is discouraged under the waterfall bidding model
• Header bidding facilitates bidding for premium offers, while the waterfall is commonly used for selling remnants

As usual, header bidding is not without its flaws. Much like the waterfall, the header bidding technology is also prone to latency. It can be caused by the header script that takes longer to load, thus spoiling the user experience. The script is also harder to implement than a simple ad tag.

Also, publishers usually connect to several SSP to maximize the reach. Advertisers respond with several DSP, which leads to a problem — your DSP can start to compete against one another. Use White-Label DSP to mitigate this issue.

Header bidding might not be universally compatible with browsers. Some browsers might give low priority to external pixels or even block them off completely, making the whole auction go down the drain.

The in-app header bidding is still under testing and development, which is why transferring all your traffic to it is ill-advised. To make header bidding truly effective, it needs more DSP platforms, wider ad format support, and greater technological development. Don’t put all your eggs in a basket and try a hybrid waterfall instead.

Header bidding can be different

True, both waterfall and header bidding suffer from latency. Originally, a user’s browser sends a request to an SSP, causing the issue. This configuration is called client-side header bidding. However, there is an alternative:

Server-side header bidding makes the publisher’s ad server send a request to the SSP instead. While improving the page loading speed, it also increases the cost for publishers. Moreover, form it does not give much of control and transparency to the advertiser, because all the data are server-encrypted. The same reason makes user identification harder.

Client-side header bidding is an industry standard, providing better access to data and cookie matching. The choice between those two boils down to whether you seek improved user experience or maintained transparency.

Any RTB, and header bidding as a consequence, can be either second-price or first-price auction. The former is more forgiving to advertisers, while the latter is more beneficial to publishers:

Second-price auction is the initial model of RTB. In this case, the highest bidder pays not the winning bid itself but the second largest one plus $0.01. For instance:

1. Bidder A states: $2 per inventory spot
2. Bidder B states: $1.5
3. Bidder C states: $1

Bidder A, who named the highest bid of $2 pays only $1.51—just a fraction above the second highest stake. Theoretically, this can lead to price manipulations, when the leader tries to squeeze out the competition by bluffing.

First-price auction, on the other hand, makes the bidder accountable for every bit of dollar put on the line. So if the bidder A says $2 and wins the auction, then this exact number is charged. While it might sound harsh and unforgiving, this leads to greater transparency for advertisers and increased profit for publishers.

Conclusion

While using the waterfall bidding nowadays may sound wild due to its underrepresentation, it solved many pressing problems in the past. Header bidding is a more democratic solution that is harder to implement, especially when it concerns mobile apps with no headers to begin with.

The technological advancement enables more transparent and efficient auction to come to life. So why not leverage this opportunity and start to earn more dough per spot as a publisher or get high-quality inventory as an advertiser? However, make sure not to jump in blindly, because header bidding, especially in-app one, is still under rigorous testing and may underperform at times.