Header bidding is a programmatic ad sales technique used by more than 70% of publishers to boost eCPMs, increase fill rates, and maximise ad revenues. It can be implemented in two different ways: client-side or server-side.
The interest in server-side header bidding has grown stronger recently, even though Google decided to not phase out third-party cookies anymore. A server-side implementation is a good option for improving user experience, technical manageability, and efficiency. While client-side has a limit on how many SSPs can be connected without disrupting page load, server-side doesn’t. However, with great power comes great responsibility and great costs.
First, choose a server-side bidding technology partner to implement and host the Prebid Server. Alternatively, build this server structure in-house using the Prebid Framework. Find out which option suits you here.
The developers must implement a Prebid server to compete for demand sources on the server. Additionally, you must find an easy way to change the server-side implementation code when required and monitor its performance. The Prebid Framework is constantly evolving, so the implementation must be updated for optimal performance.
In-house implementation usually requires considerable technical resources as it’s a complex project. In many cases, it is more sensible to turn to technical platforms (such as Relevant Yield) to reduce the technical burden of server-side implementation and maintenance while remaining in control of your stack. This means less dependence on the developers and more tech autonomy in the hands of adops and yield specialists.
Opting to build a Prebid Server in-house may appear cost-effective and self-governing initially but often comes with hidden challenges. Prebid Server expertise is, frankly, niche, requiring years of experience in header bidding technologies. As such, finding skilled developers can be difficult, narrowing the available talent pool and making hiring lengthy and costly. Even if you manage to secure a suitable developer, they risk becoming dependent on that individual, which could jeopardise the stability of their advertising monetisation function.
It’s been well-established that Prebid Server implementation and maintenance are not the simplest. Why do premium publishers and networks still go for it? Here are a few reasons for Prebid Server’s benefits that justify its demanding technicality.
Better Revenue through Improved User Experience: in a server-side implementation, a single call is made from the web page or mobile app to a server, which continues making calls server-side to all integrated demand sources. The "wrapper" returns all bids and prices to the sellers, so pricing is transparent. This differs from a client-side call, where all calls are made from the user's browser, which usually takes slightly longer. Longer page load speed can mean higher bounce rates, negative user experience, fill rates, and hence low revenue.
In-App Ad Monetisation with Prebid Mobile: Besides Amazon and Google, Prebid is a common header bidding monetisation option for mobile apps. It is not possible to integrate Prebid Mobile on the client-side, so prepare to have Prebid Server support ready. Relevant Yield has supported various app publishers in ad monetisation with Prebid Mobile and seen great results, like WetterOnline with 10%+ uplift.
Accelerated Mobile Pages (AMP): Originally a Google initiative to boost search rankings, AMP is, however, losing its ranking advantage. If you're not yet using AMP, consider whether it fits your Prebid setup, as many publishers find it a straightforward path to compliance. If you want to go for AMP, you need a server-side implementation.
Prebid DOOH: Prebid launched this product in September 2024, so it’s relatively new. However, Prebid has decided to leverage Prebid Server to enable a unified auction process, improving transparency in the bidding process. Read more about the launch here.
Additionally, Prebid Server offers the same optimisation features as Prebid.js (client-side), so the switch has no trade-off. Sellers can choose to run some SSPs on client-side and others on server-side for optimal performance as well. Different SSPs in different geos with different setups can deliver different performance on the server-side, so it’s good to test and see what works for you.
There is no absolute yes or no when it comes to server-side implementation, but we believe you should be free to switch between client- and server-side flexibly. Tying yourself to one option is never a progressive idea for growth!
Relevant Yield’s philosophy is that Sellers should be able to do both. Using our Prebid wrapper solution - HB Manager, you get support for every Prebid product, including Prebid.js and Prebid Server. There’s also an option to call both in parallel. It might seem counterintuitive to call both client- and server-side with the same call, but different SSPs are focusing bid strategies on different call types, and some are just stronger in one call type than the other, so it is certainly a good idea to test the performance. We highly recommend you use this feature strategically to balance financial outcomes and sustainability.
HB Manager’s no-code UI enables flexible testing and experimenting with different options and is based on real-time analytics collected by HB Analytics. Most configurations and customisations can be done from the UI, such as enabling server-side auctions, traffic shaping on SSPs, geo-based pricing, etc. This allows you to find the optimal setup for you: How many bidders should I run client-side vs. server-side? What impact does it have on page speed if I decrease the number of client-side bidders, and does it generate a desired uplift in KPIs?