Header bidding has become a leading programmatic technology over the years as it improves advertising revenue compared to traditional yield management methods of waterfall passbacks. Understanding the whole process behind header bidding is key to optimize your turnover. In this article, we will highlight the differences between client-side and server-side header bidding.
What is a header bidding wrapper?
Before exploring the pros and cons of client-side and server-side header bidding, there is one notion that should be understood in the first place: the notion of wrapper, a must-have to implement and run auctions. Indeed, a header bidding wrapper is a container or a framework that helps publishers gather the bids from multiple demand partners at the same time, under a set of rules, to control and optimize the bidding process, and collect the highest bid for each and every ad request.
At Opti Digital, we work with the leading wrapper, Prebid. Why? Because this free and open source solution has been adopted by the vast majority of publishers worldwide and gathers the most important community of developers, constantly improving the technology.
Prebid may be implemented in two ways:
- Prebid server: on a server-side.
Definition of client-side header bidding
In a client-side system, the auction tag (Prebid.JS) is placed on the publisher’s website source code and executed within the user’s web browser when the page is loaded.
In other words, when Prebid JS executes, the user’s browser calls the demand partners (Supply-side partners SSPs and bidders) to participate in the auction. The highest bidder wins the auction and sends the CPM value back to Prebid JS.
Because Prebid.JS runs on the browser, the bid request is rich with cookies providing relevant information about the user interest to the buy-side. Advertisers may target users according to their recent browsing history and reach their target audience at a lower cost.
Definition of server-side header bidding
In a server-side model (or server-to-server), header bidding auctions are executed on a server rather than the user’s browser. Instead of sending several ad requests, the user sends a single bid request to the server which calls many SSPs that are able to answer immediately.
This method has an undeniable advantage on the website speed as it requires less processing power from the user’s browser. The page loads faster, user experience is improved and ad viewability is optimized.
Pros and cons of both techniques
|Client-side header bidding
|Server-side header bidding
|It improves transparency and control to publishers. By using the Prebid JS open source technology you have access to all the compatible demand partners.
The cookies are directly synchronized between users, vendors and buyers, which allows advertisers to identify the user on the publisher’s website.
|Publishers can add more SSPs and ad networks to participate in the auctions.
It unifies the auctions instead of managing and setting up each ad unit separately.
It speeds up the page. The auction process is no longer happening on the client’s browser which has much less of an impact on the user experience.
|It increases the page latency as it runs all the ad requests on the user’s browser, which can degrade the UX.
The browsers may limit the number of demand partners that communicate simultaneously.
It may be incompatible with some browsers blocking connections to external pixels, leading to inefficient auctions.
|It leads to a lack of transparency as the auction process is done inside the server, publishers have no control over it.
It lacks cookie matching and requires cookie synchronization. Most user data are filtered when moved to the server which makes it harder for the advertisers to identify and target users.
Which solution is better for publishers?
Both technologies have pros and cons, which makes it difficult to know which one is the best for your advertising monetization unless you are able to test both.
Even if the server-side technology considerably improves the SEO, today the most adopted method remains client-side header bidding. There are 4 reasons for that in late 2022:
- Because publishers avoid the technical complexity of dealing with several server aspects such as: server infrastructure, bid requests and cookie synchronization management.
- In addition, some key demand partners may still rely on third-party cookies for targeting and are not compatible yet with server-side header bidding.
- Since third-party cookies are still available in the most used web browser Google Chrome, publishers chose to keep benefiting from them as long as possible.
- Eventually, Prebid JS also simply avoids the new cost associated with those servers.
However, preparing the end of third-party cookies is essential. As soon as they are removed from Chrome, the second and third reasons will disappear and publishers who keep running client-side header bidding may lose audience because of their page latency compared to the ones who anticipated and switched to a server-side wrapper.
At Opti Digital, we developed our first Prebid server wrapper back in 2019. Since then, we have faced its complexity, we have learned a lot, have become experts and have constantly optimized parameters to reach the best possible results today. Server costs are mutualized and controlled by our IT department.
As Prebid Server configuration is tricky, publishers may benefit from our expertise to anticipate the cookieless future.
Get prepared for the post-cookie era when we won’t be able to use third-party cookies. Decrease your web latency and increase your audience.
Contact us to share your situation with us and know more about how Opti Digital may help you.