Header bidding was introduced for publishers to reach out to more buyers and maximize yield. It served well for that matter, however, it 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 (A.K.A. browser-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.
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). The highest bid is selected and the winning bidder gets to display the 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 the number of 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 place on a server instead of the user’s browser.
This was introduced to counter the page latency problem that prevails in client-side header bidding. Once an impression is available, a single ad request is sent to the server from the browser.
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, floor price of each ad unit is decided by publishers. Consequently, the entire auction process becomes transparent for publishers and advertisers. However, server-side doesn’t offer such transparency for publishers. Surely, floor price is decided by publishers, however, publishers don’t see buyers participating in the auction and the auction process remains hidden.
- Auction management: Header bidding wrappers allow publishers to control and manage the auction. Using the wrappers, publishers add 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 sends them bid requests, hence, managed by server. In short, with server-side, most management tasks remain in the hands of server than publishers.
- Cookie matching: With client-side header bidding, advertisers access the ad units directly from publishers web pages 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 preferred 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. Although latency time varies by a few milliseconds 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 increases competition and offers a better ad fill rate. 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 have a limit to number of requests they can generate. 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 doesn’t depend on browser to generate and send ad requests, rather ad server takes care of this.
What About Google Open Bidding (EBDA)?
Looking at the tug-of-war between the client-side header bidding and server-side header bidding, Google launched EBDA (Exchange Bidding Dynamic Allocation, now Open Bidding) and called it Google’s header bidding. It’s known to solve page latency problems and offers Google’s support.
Open Bidding is as good as server-side header bidding. But it’s not available to every publisher. To get access, you need to be partners with Google Certified Publishing Partners.
Google deals in Net-30 whereas most demand partners go for Net-45, -60, and -90 cycles. As the revenue cycle doesn’t line-up, this discourages demand partners to choose Open Bidding. Hence, Open Bidding leads to comparatively low demand and reduced competition on inventory.
To access Google’s demand, sellers and buyers have to get in a contractual relationship with Google. This takes time and adds more steps to the inventory selling process. Not to forget, publishers would have to share a part of their earnings with Google. Whereas with header bidding, publishers would be getting dollars directly from demand.
Also, Google manages and controls 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?
Alternatively, try Hybrid Header Bidding. The hybrid method allows publishers to run client-side and server-side auction, together. Using Google Ad Exchange, publishers can make Google’s demand and header bidding compete for an impression.
Here’s how it works:
Once an impression is available, ad requests are sent to Google AdX and header bidding. Within the AdX system, both AdX and Open Bidding buyers place their bids to win the impression. Meanwhile, header bidding starts collecting bid responses from its demand partners. Upon completion, AdX and Open Bidding pass on a buyer(X). Similarly, header bidding passes on another (Y). Finally, AdX compares these bids and choose the winner (highest bid).
This solves the issue of lack of demand as AdX and header bidding are now involved along with their buyers. To sum up, Hybrid Header Bidding means more demand, improved bids, and more revenue for publishers.