Header bidding was introduced for publishers to reach out to more buyers and maximize yield. However, header bidding came with its own challenges (page latency and browser limitations). Due to these challenges, it became necessary for the industry to have a process dealing with the drawbacks of header bidding.
Hence, we got server-side header bidding. But that’s not perfect, either. So before we go deep into client-side header bidding vs server-side header bidding, let’s go through a quick recap.
What Is Client-Side Header Bidding?
Client-side header bidding (or header bidding) is a process where publishers take the inventory to multiple demand partners as soon as an impression becomes available. This is also called browser-side header bidding.
Every time an impression is available, ad requests are sent to demand partners to place their bids. After that, the bids are compared with floor price (set by the publisher). Next, the highest bid is selected and the winning bidder gets to display his/her ad.
This entire auction is conducted on a user’s browser. The process requires a header bidding wrapper that goes into a web page’s head code and the publisher gets to select how many demand sources to plug into the wrapper.
Next, What Is Server-Side Header Bidding?
Server-side header bidding, also known as server-to-server header bidding, is a technique when the auction takes places in a server instead of the user’s browser.
This was introduced to counter the page latency problem that prevails in client-side header bidding. With server-side header bidding, a single call is made to the server, once an impression is available.The an ad request is then sent to the server.
The server picks the request and calls demand partners to execute the auction. Once the bid is sold, the ad is displayed without affecting the page load time.
Why Choose Client-Side Header Bidding Over Server-Side Header Bidding?
Publisher’s control: With header bidding, publishers get to choose the buyers using the header bidding wrappers. Furthermore, the floor price of each ad unit is decided by publishers. Consequently, the entire auction process becomes transparent for the publishers and advertisers. However, server-side doesn’t offer such transparency for publishers. Surely, floor price are decided by publishers, however, publishers don’t get to choose buyer and the auction process remains hidden.
Auction management: Again, header bidding wrappers allow publishers to control and manage the auction. Using the wrappers, publishers can choose buyers, set up time-out settings, and make sure all buyers get the bid requests simultaneously. On the other hand with server-side header bidding, server reaches out to buyers and send them bid requests, hence, managed by server.
Cookie matching: With client-side header bidding, advertisers access the ad units directly from publishers web page using the wrapper which gives access to user’s cookie data. This can further be used for ad targeting. Whereas, server-side header bidding lacks cookies matching. This is because most user data is filtered while syncing the publisher’s and server’s DMP.
Interested buyers: Client-side header bidding still prefered by most publishers and advertisers. This might be because of the transparency factor. Server-side header bidding is still too young to be accepted by ad industry.
Why Choose Server-Side Header Bidding Over Client Side Header Bidding?
Reduced latency: As mentioned above, server-side header bidding is carried out in a server instead of a browser which reduces the page load time. Though latency is a few milliseconds lesser when compared with client-side header bidding, publishers still take page latency seriously as it affects the overall user experience.
Access as many demand partners: With server-side header bidding, server sends bid request to as many buyers the publishers want. This offers better ad fill rate and increases competition. However, client-side header bidding is not that flexible as publishers choose just the required number of buyers to make sure impression is sold before auction timeout.
Perfect for video header bidding: Videos are rich media files and hence take more time to load on web pages than other ad formats. It’s clear by now that client-side header bidding increases page latency. And adding this to fact, videos are slow to load, can cause serious damage to user experience when used with client-side. However, server-side doesn’t pose such complications and works perfectly for video header bidding.
No browser request limitation: Web browsers limit the number of requests a web page can send. As client-side header bidding takes place on the browser, publishers have a limited number of ad requests they can send via a browser during a session. Although server-side header bidding remains unaffected from such problems because of it independency from the browser,
What About Google Exchange Bidding?
Looking at the tug-of-war between the client-side header bidding and server-side header bidding, Google launched EBDA (Exchange Bidding Dynamic Allocation), and called it Google’s header bidding. It’s known to solve page latency problems and offers Google’s support.
Google exchange bidding is as good as server-side header bidding. But it’s not available to every publisher. To get access, ou need to be partners with Google Certified Publishing Partners.
Also, Google manages and control the process for publishers causing transparency issues. On the plus side, publishers can get benefits of header bidding without doing the leg work as Google manages everything for them (even the payments).
So, What Should I Choose?
It depends on you (publishers). Also, your inventory type, demand, and market trends. As you can see, each of these header bidding processes has its own pros and cons. Hence, choosing one blindly is never recommended.
Ideally, a publisher should test them first and compare the results. The data generated by the results will give you the answer to your question‒which is better, client-side header bidding or server-side header bidding?