Server-side header bidding is gaining a lot of popularity, thanks to the reduced latency with server-side setup. Google has been offering its server-side header bidding for a long time and Amazon has solutions like UAM. But we are all aware of the transparency and control issues with the tech giants.
So, as an alternative to the proprietary solutions, we have Prebid Server. It is an open-source solution for server-to-server header bidding. Being open-source, Prebid Server has its own merits and demerits which we are going to discuss in this post.
Table of Contents
Why Prebid Server?
Let’s start with a simple question. Why do you need a Prebid server?
With the help of the Prebid server, you can scale up your demand. You can add as many SSPs as you want, without worrying about latency. You can also expect as much as 40% improvement in latency. But this benefit is not limited to prebid only, you’ll get this scalability and reduced latency with any other server-side setup as well.
A client-side setup sends multiple requests to the ad server, and the browser handles the auction, so the latency increases. On the other hand, a server-side setup needs just a single request, and the complete auction takes place on the server-side, so the latency decreases automatically.
Another benefit of Prebid Server is that it is best suited for monetizing AMP pages. AMP pages use the RTC framework which is very restrictive for implementing header bidding. It limits the number of requests, at the same time, the timeouts in AMP are also very short (1000ms).
Prebid Server shines in such an environment with unified auctions (single request) and less latency. How?
The RTC framework allows only up to 5 requests at a time. It means you cannot connect more than 5 demand partners with an AMP page, but typically a publisher connects with 7-8 demand partners to create a high demand for increased revenue. To overcome this obstacle, the Prebid server acts as a wrapper that can send requests to as many demand partners as you want. The dedicated servers are also way more powerful than a user’s browser, hence the auction takes place at lightning speed with no timeout issues.
How does Prebid Server work?
Here’s an overview of how Prebid Server works for banner and video ads:
Banners
- The prebid server parses the request and holds the auction
- The response is sent back to the browser
- Prebid.js also passes ad server targeting variables to the page, the page forwards the variables to the ad server.
- When an ad wins, the ad server responds with the Prebid Universal Creative.
- The Prebid Universal Creative renders the display creative
Video
- Prebid.js is configured to run the header auctions on the server-side.
- When a page loads, Prebid Server parses the request and holds the auctions (not Prebid.js as it happens on client-side bidding).
- VAST XML bid responses are then stored in Prebid Cache.
- Prebid Server sends the results and Cache ID to the Prebid.js on the page.
- Prebid.js passes the bid information to the player and the player calls the ad server (GAM).
- When a header bidding partner wins, the ad server sends the URL from which to retrieve the VAST XML — back to the video player.
- The player pulls the winning VAST from the Prebid Cache and displays it appropriately.
Getting Started with Prebid Server?
You have two options to host the Prebid Server.
- Host it yourself
- Leverage Bid Servers from Partners.
Host it yourself:
The first option is to host it by yourself.
- To start with Prebid Server, first, you need to host the server. But note that the server infrastructure can have a huge impact on the revenue. Having a distributed network of servers across the globe can be important if your user base is dispersed across several geographies.
- Second, you need to update your Prebid.js with the Prebid Server code.
- Finally, you have to configure the adapters and enable the server-side setup. If you’re familiar with Prebid.js engineering/ops setup, then this will be a bit easier.
What do you need to consider?
- Building a distributed server cluster is expensive as well as time-consuming.
- Optimization and engineering work that goes into the Prebid server shouldn’t be overlooked as well.
- Just like Prebid.js, you have to find the SSPs yourself if you are taking the “build-your-own-server” approach. Some SSP’s will have their own Prebid Server setup and demand sources. But you may already be aware of the fact that top SSPs rarely work directly with publishers who have traffic in the millions. Wrapper providers are generally best for publishers of every size.
Leverage Prebid Servers from Partners:
The second option is to use the Prebid Server from your monetization partners (say, header bidding provider). This way you don’t need to be concerned about Servers, CDNs, optimization, technical hiccups, and SSP partnerships.
Related read: Here’s how we run a server-side infrastructure to enable our publishers to run low-latency header auctions.
Is there any Privacy Compliance with Prebid Server?
The Prebid Server can comply with GDPR, CCPA and COPPA.
- GDPR: Prebid Server can read TCF 2 consent signals for and take necessary enforcement actions to comply with GDPR
- CCPA: Prebid Server can read US Privacy Consent String for CCPA compliance. It supports AMP too.
- COPPA: The Prebid Server can read COPPA flags and take appropriate enforcement actions
Any Shortcomings of the Prebid Server?
- Discrepancy
- Troubleshooting
- Expensive
- Lower Bids
Discrepancy: Due to the fragmented nature of the server-side setup, the discrepancies in impressions, revenue, etc, is much higher with the prebid server. You need to have a strong and stable server-side setup to ensure minimum discrepancies.
Troubleshooting: Troubleshooting in the Prebid server can sometimes be a huge headache. The problem exists partly because it is open-source, and partly because it is server-side. This is why dealing with Prebid Server can be time-consuming.
Expensive: You need a server for server-side auctions. Building and managing a server can be expensive, especially when you are doing it yourself.
Lower Bids: Server-side header bidding suffers from user syncing issues and lower match rates. The ad buyers do not get as much information about the user as they would have got in client-side header bidding. This happens because the cookie matching process takes place at different server levels, extra syncing takes place with the auction server, so the extra steps added to the ad delivery process lead to higher chances of data loss and lesser chances of identifying the users.
Without enough information, it is difficult to serve highly relevant ads to the user. When lesser ads are relevant, there are fewer chances that the user will convert, so the advertisers have to buy more ads to reach the required sales goals. As a result, the advertisers bid lower than usual.
What’s the Ideal Setup with Prebid Server?
You can keep your best-performing partners on the client-side so that you are not risking their match rates. Consider features like response time, bid rate, winning rate, etc to decide which demand partners should remain on the client-side. The remaining partners can go to the server-side. The slowest responding partners can also be sent to the server-side so that they are not delaying the auction on your site.
Additionally, you can have other non-prebid-based demand sources to increase the competition, including Amazon’s UAM and Google’s Open Bidding.
What’s Next?
We recommend using the Prebid Server to monetize your AMP pages because it’s the best solution for AMP. Kindly note that only a handful of companies would be able to help you with the AMP monetization part, but we have already sorted it out for you. If you want to reduce the latency on header auctions using a hybrid setup, we recommend keeping your top partners on the client-side and remaining on the server-side. It is so because the server-side setup can reduce the ad rates due to the reasons we mentioned earlier, and any reduction from your top buyers can have a great impact on your overall revenue.
