In the latest column from the IAB’s Display Trading Council, Michelle Raubenheimer (pictured below), director, business development, PulsePoint, along with co-authors James Prudhomme, managing director EMEA, Index Exchange, and Emma Newman, country manager, UK, PubMatic, clarifies the difference between client-side and server-side auctions and how publishers can decide which header bidding option is right for them, once they’re committed to it.
Despite recent industry coverage on server-to-server integrations, exemplified by the news of collaboration between AppNexus and Index Exchange, many unexplained questions on server-side header bidding still remain amongst publishers. These range from those who are still getting to grips with it, and those who aren’t yet using it, to those who understand it, and then those who have partners in place to help maximise it.
Still following? “Barely”, I hear you say? What this tells me is that, in our industry, the pace of change and tech innovation moves so quickly and that we as an ad tech community must start doing a better job of working together to help publishers grasp this fast-moving technology in a more simplified manner to help support their bottom line goals: monetisation and yield.
There is no doubt that 2016 was the year of header bidding, as publishers started to quickly explore this new technology in favour of bringing control back in-house and getting a better deal. But how exactly does header bidding do this? To understand just how it works, let’s take a step back and look at the header bidding options: in browser and in server.
Header bidding boasts two distinct flavours: browser-side, with the auction running on the client webpage, and server-side, with the auction running in the server. With browser-side, it’s easy to add more bidders to the unified auction and setup is fast. To cut to the chase, the big problem it solves is liquidity.
Server-side header bidding works essentially the same way; however, with less implementation work for the publisher. The key difference, from a revenue perspective, is that with server-side, all bids are submitted to a server, which returns the highest winning bid to the ad server, reducing latency, improving reliability of the auction and minimising the risk of lost revenue.
In essence, server-side header bidding promises to improve latency, scalability, and auction logic issues seen in traditional header bidding by moving communication with exchanges away from the browser and into servers. The process is essentially the same way SSPs and DSPs integrated for years; except this time the SSPs are integrating with each other.
So then, how does a publisher decide what is right for their business? We outline five key questions to ask and address before making a decision:
This comes down to what is important to your business. For example, if you are a video publisher specialising in native video, then you may want to consider why a server-side integration would be beneficial to your revenue. As the market is still maturing in this sector, there is limited independent reporting which can show the benefits of migrating from browser side to server side. In this instance, maybe a browser-side integration would impact the liquidity of your business far more quickly.
Publishers with multiple domains are likely to benefit from server-side solutions with reduced bidder latency, sustained user experience, and a more supportive operational setup. Domain publishers may opt for browser side for faster implementation and liquidity of partners.
This question is specifically important to publishers who place high value on first-time user cookie matching. The fill rate is significantly reduced on server-side integrations that lose users through inadequate cookie syncing between exchange partners. Server-to-server could harm monetisation through poor cookie match rates. This raises additional questions about the future of tech players in this space – will it call for independent cookie stores to mediate between partners and ensure user matching is sustained and fair across all demand sources?
This question still remains at the forefront of all industry integrations, including server-side. If publishers are to trust one partner to mediate auctions across multiple bidders, the demand for transparent log-level reporting of bid-stream data, including a fair auction model, must be maintained across all bidder partners.
“Server-to-server integrations provide little to no added value unless they are fair, transparent, and interoperable. The technology is here to provide publishers with everything they need; and, as more technology providers begin to work together, publisher success will inevitably continue to grow.” – Emma Newman, Country Manager, UK, PubMatic.
Going back to KPIs – are you interested in having an exclusive with one partner, or do you want maintain control over the partners you add over time? If the latter, then you may want to question which partners can offer a more agnostic and open integration structure and answer the above questions to suit your strategy needs. For example, if you choose to work with just a couple of partners, do they cover your demand requirements, cookie syncing needs, integration times, and transparency needs? Time will tell.
So, where do we go from here? Server-to-server auctions bring more control back into the hands of the publishers, who have been on the back foot since the rise of programmatic advertising. The industry is moving fast, but don’t rush big decisions. The benefits of server-side may be quite clear, so long as publishers understand the integration model and how it relates to their monetisation needs.
This is not to say publishers need to choose one over the others and, in fact, some publishers who manage both browser- and server-side bidders within a wrapper solution will find they can more easily balance their revenue needs against user experience. But one thing is clear, when publishers execute on a truly unified auction, they maintain direct control and can increase revenue opportunities while also enhancing transparency across the board.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form