Getting Your Setup Right: client-side header bidding Pros and Cons
The header bidding phenomenon has grown up quickly for digital publishers, and we seem to be at a point in header bidding’s lifecycle where publishers are again making decisions about their header tech.
So, as we ponder the subject of header bidding, it makes sense to examine what has happened over the last few months in the industry and how thinking is changing. Right now the tailwinds seem to be on server-to-server header bidding (S2S) solutions as the number of publishers who look to be switching to server-side technology are steadily increasing.
As a refresher, server-to-server header bidding technologies “move” the auction process from the user’s browser to an external server, significantly reducing latency and hopefully improving the end user experience.
As header bidding technology itself has evolved, we have seen a gradual transition from client-side header bidding solutions to server-side header bidding solutions, with some publishers adopting even a hybrid solution that uses both.
In this article, we will walk you through the three solutions’ pros and cons, trying to help you understand which solution fits your needs the most, and what you should keep in mind when and if you implement one of them.
First, let’s understand the pros and cons of each solution:
Client-Side Header Bidding Solutions – Pros:
- Increased revenue: If you choose a client-side header bidding solution, you’ll improve margin because you’ll avoid some middlemen and potentially some additional costs if you use a free version of prebid.js. As with all header bidding models, you will connect directly to demand and SSPs to generate more competition and usually more revenue. However, with client-side header bidding solutions you can potentially earn more revenue than server-side header bidding solutions because – in most cases – the understanding of what is being bought is greater with client-side header bidding solutions (the bidder knows better what he is bidding on in a client-side solution, as today’s server-side header bidding solutions typically don’t offer as much audience information to buyers).
- Transparency and Control: When an auction lives in the browser, additional parts of the process are under the publisher’s control and – with some vendors – you can capture greater understanding of the process via access to your wrapper data (we highly recommend an analytics adapter to monitor partners). With a good analytics package, all auctions and bids should be visible so you can easily monitor discrepancies, time outs, and other key metrics.
- Improved cookie matching rate: As mentioned above, through the browser, header partners have a direct access to the user’s cookies file. Consequently, there is only one cookie-sync to pass through between the SSP and the DSP – hence a higher traceability and attractiveness for your demand partners. This leads to a better fill rate and higher monetization versus for S2S header bidding solutions. In this way, the same user will be identified and tracked in future requests.
Client-Side Header Bidding Solutions – Cons:
- Latency: Latency is the client-side solution’s main pitfall. Wrapper code runs in the browser header and waits for monetization partners’ bids, adding load to the browser and holding a certain number of http connections (browsers can’t handle more than 15-20 parallel connections – which include other connections you may require for your website). Because an RTB auction runs directly in the browser, client-side header bidding can slow down load times by up to 30%. This clearly affects the user experience and drives away many users who are not willing to wait for the page to load. As we all know, these slow load times and tracking pixels have pushed many to install ad blockers – the enemy of those selling digital advertising. Getting a handle on these metrics with a high fidelity analytics tool can help significantly here.
- Complexity of set-up: The code placed on page and the creation of all the requisite line items in the ad server make the process complex to implement. That said, wrapper technology and implementation continue to improve.
- Limitations in numbers of partners: As a result of the above issues, using client-side solutions generally have a limit of the number of partners you can effectively work with. Adomik does not recommend more than 6 to insure there is minimal latency.