More than 70% of publishers use header bidding to boost eCPMs, increase fill rates, and maximize revenues. These calls can be made either client-side or server-side; or even as parallel calls. Lately more and more of the focus is on the Prebid server, as it is generally a faster and more reliable way of making calls, but it also comes with larger complexity.
First, we would like to start by explaining a little bit about the difference between client-side and server-side, before we move the focus on what a move from client-side to server-side Prebid can actually mean for your company and the people working with your Prebid setup.
In server-side header bidding, the publisher chooses a server-side bidding technology partner to implement and host the solution; or they build this server structure themselves - often using the Prebid Framework.
A single call is made from the web page or application to a server, which then continues making calls server-side to all integrated demand sources. The “wrapper” sends all bids and prices back to the publisher, so pricing is transparent. This is especially great for mobile, where high bandwidth is necessary to sustain the connection and ensure the ads are properly delivered. This is different compared to a client-side call, where all calls are being made from the user's browser, which in most cases takes slightly longer.
Several ad tech providers developed their own wrappers for client-side header bidding, and a few also support server-side header bidding. The Relevant Yield solution can do both, and it is done quite easily by clicking a button, and selecting if you want to do a client-side call, a server-side call - or 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. More about performance uplifts later on though!
One major difference is of course that if there is no client browser, the prebid server is the natural solution. Relevant Yield wrapper, HB Manager, supports server-side, working with the prebid framework, and supports all of the server-side components in the framework:
- Prebid server
- Prebid Mobile
- Prebid AMP
- Prebid Video
Where the latter three are extensions on the core Prebid server.
What are the advantages of server-side header bidding through a solution like the Relevant Yield HB Manager?
- A solution for latency issues - faster loading of ads.
- It works better for Rich Media: videos are often slow to load, so switching to server-side bidding greatly improves user experience. A server-side implementation is also the only way to show ads on over-the-top (OTT) devices.
- Unified Header bidder reporting through our HB Analytics solution, which covers both client-side and server-side header bidder reporting.
- Easy set-up: identical setup as the client-side and no extra mapping; just activate with a single button if you want to run with the same settings as client-side. You can also differentiate your demand sources based on the call type you utilize, making sure you work with the best sources in each individual case and mediatype.
- Switch between methods by pressing a button, or even run in parallel. You can mix load types on a placement level to utilize the perfect call structure on each individual level.
- You do not need to build or host the Prebid Server.
- You do not need to add a monitoring or analytics system for your Prebid server.
What are the drawbacks of server-side header bidding?
- Lower levels of users that are cookie synced in the server-side-calls might be seen in the beginning after enabling prebid server as during the first auction synchronization of cookies has not been completed yet.
- Increased technical complexity, cost and dependencies for the publisher’s development team.
What does it mean for your development team working with Prebid in a server-side environment compared to client-side?
As we see an increased interest for a prebid server, there are also new challenges for the publishers who have decided to build their own prebid setups. Many publishers run their own Prebid client-side setup, and even though the principles of the prebid remain the same, the technical consequences are very big switching to server-side.
Server-side requires a different setup compared to client-side, as the auction takes place on a server, rather than in the user’s browser. So first of all, the publisher’s tech-team needs to set up a prebid server in order to handle the auction itself. They also need to add a way to easily change and work with the prebid server code, and a proper monitoring system. This has prompted publishers who run their own Prebid client-side to talk to vendors like Relevant Digital, because the publisher’s own development team does not necessarily want to take on this increased “technical burden”, and push to outsource the Prebid Server project. The added technical complexity is simply cheaper and more efficiently handled by an external partner, so the development team can focus on core business related tasks - which makes sense in most cases. As prebid is also a developing and evolving framework, keeping the system up to date is another aspect that the development team might not want to focus on.
Prebid Server can be a really good solution for the user experience, and as such we do find that most publishers’ development teams actually prefer server-side compared to client-side, as it is technically more controlled and efficient way of handling the calls; but as mentioned above, it comes with an additional level of complexity.
Uplift on revenues and performance with HB Manager in server-side
We have spent some time discussing the negative aspects of server-side, so now it is time to highlight why it is still a really good thing for publishers to start working with Prebid Server!
Page speed in general is a highly important factor in generating a good user experience and in order to make sure your ad stack performs well. Advertisers and agencies are willing to pay higher prices and bid more often on inventory that has high viewability levels, and with a slow site that becomes difficult to achieve.
In order to maintain good site speed, there is a limit of how many bidders you can run client-side as all add a bit of latency to the setup. With server-side setups such limitation does not exist as the auction is held on a separate server, which enables you to have a larger number of demand partners running without a negative impact. It is also a great way to test new partners as the auction is contained in a safe and controlled environment, where the adapter can be quickly turned on/off; without affecting the user's experience.
The HB Manager enables you to do flexible testing and experimenting with different options; You can easily change the configuration from the UI on whether a bidder should run client-side or server-side. This enables 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?
Relevant Yield in 2mins
Read more about our solution: Relevant Yield
If you are interested in hearing more about our services, you can leave a contact request here.