In his continuing regular series, programmatic expert Paul Gubbins looks at one of the hottest topics in programmatic right now: header bidding.

If you know me, youll already be familiar with the industry jokes about me being obsessed with header bidding. To be fair, I am. I genuinely believe it will change – and is already changing – everything about the way a publisher sells, and the tactics applied by smart buyers to access said publishers inventory and their associated audiences.

Spoiler: this is not another piece about how header bidding works as I am assuming you all know the basics already (if you don’t – it means a publisher running a unified auction and calling all demand sources at the same time rather than the traditional sequential approach referred to as the waterfall). What follows is a quick overview of everything you need to know today in order to sound like an expert when next on stage, or in front of your clients.

Iteration One: Wrappers delight

All SSPs and exchanges (Rubicon, OpenX, PubMatic, Index et al) used to compete with each other for a position within a publisher’s ad server (typically DFP). If they managed to secure a higher place than their competitors, this gave them a USP when talking to buyers. Many also used to negotiate for the ability to sell PMPs exclusively – another major USP if these rights were secured. For the SSPs that did not secure a priority position, they would ordinarily work with the publisher at a lower priority and may have been clearing open exchange inventory. 

Fast forward to the age of header bidding, though, and publishers were removing tags on pages and opting to place SSP tags in their headers, thus completely flattening their waterfall and opting to call all SSPs they were working with at the same time before their ad server was being called.

What were Google offering to publishers at this stage?
Many claim header bidding was born out of a need to disintermediate the relationship between DFP and AdX, the Google-owned ad exchange. Google had made it very easy for a publisher to default to AdX in order to sell their inventory to programmatic buyers. Although fill was high due to the volume of buyers connected to Google, many claimed that eCPM was not as strong as it could have been with external competition competing and submitting a price before AdX had a chance to fill.

Google was quick to sense this growing wave of publisher sentiment and witnessed first-hand how many of their publishers were implementing independent header tags from 3rd parties and that was hindering their ability to win the auction. As a result, Google very quickly released a beta known as Exchange Bidding in Dynamic Allocation (EBDA). For the first time, this enabled third-party SSPs that were included in the launch beta (Rubicon and Index) to compete at the same level as AdX when the dynamic allocation feature was selected by DFP publishers. We will return to Google later, but first…

Step forward the wrapper arms race
Publishers very quickly realised that running a unified auction was creating an incremental uplift in eCPM and fill. However, multiple Java tags in their headers was causing page latency, essentially kryptonite for publishers. In answer to this growing publisher concern, many SSPs developed their own proprietary containers, or ‘wrappers’, that a publisher could adopt and leverage in order to holistically manage all header tags and their time out windows with ease to reduce this latency.

Rather than any one SSP winning out when it came to market share adoption of their wrapper, an open-source wrapper called Prebid.js, born out of the AppNexus engineering camp, started to get real traction. In fact, Rubicon Project recently stated that that over 75 per cent of their publishers had adopted Prebid, and were now openly supporting the open-source wrapper rather than trying to disintermediate and selling a Rubicon equivalent – according to many, a smart play.

The reason publishers were choosing an open source wrapper was that it was perceived to be neutral by those who had to place their tags within it, and empowered publishers to build out bespoke and custom features that met their unique requirements around holistic yield management.

Iteration Two: Server- vs client-side

With the practice of header bidding now widely adopted across the majority of comScore top 100 publishers, many were slowly starting to realise there was a tipping point in the number of header tags they could place within their implemented wrappers, regardless of whether the wrapper was open source or proprietary.

The race to the server side
Publishers quickly realised that by removing the auction from the user’s page and moving to the server, they would not be limited to the number of participants they could run in the auction – and more importantly, their user would not feel the side effect of client-side header bidding, potential page latency.

Vendor interoperability for client-side header bidding is pretty strong at the moment. Most tier-one SSPs will sit within each others’ wrappers or an open-source wrapper like Prebid. Although it took some work to get all parties to agree, I think the fact this is a transparent environment where everybody can see and audit the auction dynamics meant that competing vendors are now more comfortable working with each other, as they have realised collaboration is a must to grow the market and to support their publishers…

However, server-side header bidding removes a lot of the transparency that is offered by client-side header bidding, and SSPs need to really trust that everybody is acting fairly and in the interests of the publisher. In English, when a publisher appoints a vendor to be their main server side header bidding partner, they are responsible for running the auction. However, nine times out of 10 they are also participating in the auction, hence a reluctance from many parties to migrate from client- (where they can see what happens in the wrapper) to server-side, where they become partially sighted.

The recent partnership between AppNexus and Index Exchange is a massive step forward as we are seeing competitors sharing log level information in order to create a fair and transparent server side demand ecosystem that will drive yield for their collective clients, the publishers.

However, there are some clear points of differences between client and server side implementations that need to be understood from both the sell and buy sides:

1. Server-to-serve (S2S) auctions can accommodate several hundred demand partners, versus 7-10 client-side.
2. Latency increases with the more demand partners added via a client-side implementation.
3. Cookie match rates fall between 55-90 per cent with S2S header bidding, according to AppNexus stats.

If an SSP has strong demand and does not want to participate in a S2S partnership due to transparency concerns, publishers may still want to keep their header tag client-side, as a demand partner with a reduced cookie match rate is a buyer massively disfranchised with your supply.

However, those with weaker demand may be asked to migrate to reduce what I am starting to refer to as a ‘space trash’. Like the defunct satellites that orbit the earth, publishers will remove header tags that clutter their wrappers, cause latency and do not drive any differentiated demand, and ask them to migrate to the server-side where they can be, at best, a filler to help drive bid density.

Step out of the shadows Amazon
With all of the debate in the press on the pros and cons of client versus server side, Amazon – from what felt like out of nowhere – announced last December its plans to offer publishers a cloud-based server-side header bidding solution. Many have questioned their ability to execute this model, but it is important to remember that Amazon already runs a very large cloud-based business in AWS, and has a lot of experience under its belt as a data-driven programmatic ad buyer.

It is yet to be seen who will be able to participate in this beta, but needless to say, it could prove a welcome boost to publishers yields and divide camps even further, as the utopia of vendor interoperability is tested daily in ad tech.

Okay, but what about Facebook?
Rather than building any type of header bidding product for publishers, Facebook is talking about making one of its strongest assets available to existing sell-side vendors who build header bidding products: its demand.

Facebook recently announced it is going to open up its Facebook Audience Network (FAN) demand to publishers who implement certain wrappers. It has reportedly certified Amazon Publisher Services, Index Exchange, Media.net, Sonobi, Sortable and AppNexus. This means that any publisher who has a client-side wrapper from these vendors can, in theory, now access mobile web demand from FAN buyers – a welcome revenue boost to many premium publishers who are struggling to ramp their mobile yields. Facebook are yet to announce their plans for publishers who have implemented a server-side header bidding solution.

Back to Google…
Late last month, there were reports in the industry press that Google would be ramping up its efforts around EBDA and opening up to additional demand partners and publishers. But most of what we read about header bidding today is not about mobile or video. Other than the recent Facebook announcement, most of what of what you have read or seen discussed on panels at events is likely focused around desktop. Mobile header bidding is technically different due to the nature of apps and video, and the player formats.

That said, the concept of a unified auction is beneficial to a publisher regardless of the format at the centre of the auction, and with a scarcity of video and demand at an all-time high, we are starting to see SSPs talking about their early successes in their video header beta tests.

To summarise: think smart and ask challenging questions. For example, I would want to know how header bidding vendors are building product for life beyond the cookie, client- or server- side.