What is Prebid Server?
Prebid.org community continues to expand, and the years of work are paying off. Prebid.js was designed in 2015 by AppNexus, and now it’s one of the most popular header bidding wrappers.
Header bidding is a crucial piece of technology that publishers and ad tech partners using web inventory have successfully incorporated into their monetization strategy.
Prebid server can be viewed as an add-on for prebid.js or a replacement, where prebid.js can’t be implemented.
In this article you’ll learn what prebid server is, how it works, and how it can benefit your header bidding strategy.
What is a Prebid Server?
The prebid server allows publishers to move client-side bid requests to the server-side. It works as a proxy for bid requests for prebid.js, prebid mobile, or a standalone solution for AMP (Accelerated Mobile Pages).
The user experience for many publishers was significantly improved by the server-side approach since it eliminated latency issues and improved the website’s loading speed.
Nowadays, many publishers employ a hybrid header bidding system that combines both prebid.js and prebid server. It allows to call multiple demand partners, reduce browser requests, and improves the overall ad revenue.
Differences between a prebid.js and a prebid server
Prebid.js is an open-source header bidding wrapper that lets multiple demand partners (SSPs and ad exchanges) bid on the publisher’s inventory simultaneously.
There are two types of header bidding–client-side and server-side. With the client-side header bidding, the auction runs on the users’ browsers, and many ad requests are sent from the user’s browser to each demand partner separately.
With the server-side header bidding, one call is made to the prebid server, and multiple calls are made from prebid server to demand partners.
Prebid server, in contrast to prebid.js, is a server. It requires a location to run, and that location should be scalable, distributed, and fast.
Prebid.js allows you to perform auctions in the header of your website:
- An ad call is sent to each bidder.
- The bids are sent back to prebid.js.
- The winner is determined in the header.
On the other hand if you incorporate prebid server with prebid.js, it uses the prebid.js implemented in the header of your website:
- One ad call is sent by prebid.js to the prebid server.
- Prebid server then sends bid requests to all bidders.
- Then bidders send back their bids to the prebid server.
- Prebid server returns all bids to prebid.js and the auction takes place in the header.
In summary, the decision essentially comes down to how you want to increase demand and improve the user experience.
You may add as many SSPs as you like with the help of a prebid server without being concerned about slowing down or interfering with your user experience while the ads are loading into the page.
Additionally, with the server-side setup (as opposed to the client-side setup of prebid.js), you only need to make one request.
Prebid.js is significantly simpler and quicker to set up for publishers that lack the capacity to run their own server solution.
Whatsoever, prebid.js is needed either way–if prebid server is used or not.
Additionally, client-side may offer better revenue chances because of a higher cookie match rate.
Client-side VS. server-side connections
Most publishers and monetization companies currently use client-side header bidding. The real-time header bidding auction in this setup takes place on the user’s web browser, such as Google Chrome.
On the other hand, with server-side header bidding, the user sends a single request to the server, which then makes several requests to SSPs and ad exchanges.
Without the user’s browser becoming involved, every bidder responds faster.
It’s easier for sellers to execute server-side header bidding across all formats thanks to the investments made by several top suppliers in the solutions that integrate the prebid server with their technology while preserving the advantages of an open-source wrapper.
Prebid server in header bidding concept
Header bidding is improved by prebid’s transparency, flexibility, and community-driven innovation. Prebid header bidding is a significantly better way of monetization than waterfall for generating ad revenue.
Despite being a preferable alternative, prebid.js lacks the features required to support ads on mobile apps and AMP sites.
And that’s where prebid server comes to save the day.
Header bidding is a complex technology and it isn’t easy for publishers to handle. Prebid Server allows publishers to easily use header bidding for their Android and iOS apps.
Prebid Server reduces latency of the header bidding process by allowing simultaneous bids from demand sources interested in the publisher’s inventory.
Setupad offers a customized header bidding solution–a direct prebid.js solution that connects to a publisher’s current SSP accounts and allows optimization between programmatic and direct sales.
Setupad’s server-to-server (S2S) connections allows publishers to benefit from additional demand and generate extra ad revenue without impacting the website speed.
How Does a Prebid Server Work?
Prebid server works as an add-on for prebid.js, and it makes it possible to move client-side bid requests to the server-side.
The workflow below shows how prebid server operates:
- Through the code “s2sConfig“, prebid.js is configured to manage auctions for one or more bidders.
- The auction is held once the prebid server analyzes the request.
- The browser receives the response with all creatives along with the body of the winning creative.
- For apps, video, and AMP prebid server returns a link to prebid cache, where the creative code is cached.
- Prebid.js passes ad server targeting variables to the page, which forwards it to the ad server.
- The ad server responds to the page with the prebid universal creative when a header bidding ad wins.
- This directs prebid.js to use its render function to display the creative.
The website’s ad placement is served by the partner who places the highest bid. It’s important to note that the overall auction winner is not determined by the prebid server. That is the ad server’s responsibility.
It does, however, make two choices that affect which bids are sent to the ad server:
- Each bidder’s best bid for each impression. For each impression object, the prebid server returns one offer from each bidder. The client may receive multiple bid responses from the same bidder if the request supports multibid.
- Which bidder receives the targeting values for hb_pb, hb_size, and hb_bidder for each impression object? This action is taken only when ext.prebid.targeting is provided. Although this is most crucial for AMP, other clients (e.g. app) could rely on the prebid server to select the “winning” header bid.
The fundamental steps of how a prebid server works are:
- The prebid server verifies and completes the incoming requests–resolves dynamic stored requests (applies only for AMP and apps), and enforces privacy regulations.
- Then prebid server calls server-side bid adapters.
- After all the bidders have responded (or the timeout expires), the prebid server generates a valid response–the prebid server takes care of currency conversion, quantizes bids, and caches VAST XML or creatives.
In addition to the prebid server, the prebid cache supports use cases for AMP and video by storing VAST and bids as needed. Pebid cache stores creative code returned by the bid, which could be both VAST creative or simple display ad code.
Source: Prebid
What are prebid server benefits?
Here are 5 main benefits prebid server can provide:
- Greater transperency.
- Optional analytics support.
- Simultaneous auctions.
- Multiple partners.
- Reduced page latency.
For prebid SDK there’s no concept of cookies, so no syncing takes place in that scenario, and the ID in mobile is based on IDFA (identifier for advertisers).
Additionally, as cookies are removed, prebid server won’t need a separate user-match layer as much because it already has a significant user identity advantage.
Running a prebid server – hosted VS. custom solution
Prebid server has dramatically simplified the process, but deploying header bidding still is challenging since you might need the help of an AdOps team and extra time to execute contracts with bidders.
It may be expensive for publishers to implement header bidding independently with a prebid server. Therefore, there are occasions when it makes sense to choose solutions that have already optimized all of the processes.
Partnering with a prebid server provider like Setupad is the quickest and most cost-efficient way to acquire prebid server capability.
One drawback is that the code provided to you by a third-party vendor is not under your control. If another service handles your header bidding experience, it may increase page latency on your website, depending on how it’s set up.
In the end, if you want to use your own prebid server, you need to have the resources in place and time (which can take years). On the other hand, a managed solution will take care of everything for you.
Prebid’s drawback
For some sellers, prebid’s most valuable attribute–open-source–is a drawback. Since prebid is transparent due to its open-source design, publishers should take the initiative or look for a knowledgeable tech partner.
Because publishers lack the skills to manage prebid, several subsequently adopted proprietary wrappers, but they also have disadvantages. The differences in counting methods and payment make it difficult for buyers and sellers to conduct business.
Additionally, in situations where internal teams haven’t updated or created third-party adapters to integrate proprietary wrappers into the auction, some wrappers exclude specific types of demand from participating.
Publishers often run different header bidding solutions simultaneously (e.g., Prebid, Google Open Bidding).
Therefore, DSPs receive impressions from each SSP once, multiplied by the wrappers, which led to dissatisfaction among the DSP community. It also led to a demand that SSPs and publishers select a single wrapper format.
Industry standards change and it’s expected that most publishers will choose prebid as their primary wrapper.
How to Get Started With Prebid Server?
There are 3 main steps to get started with prebid server:
- You need a server to host prebid server. Publishers must have a server to host the prebid server. They can cooperate with partners who have a prebid server like Setupad or set up their own server.
- You need to install or update the prebid.js setup. Existing prebid.js users must update their versions with the prebid server code. Publishers who don’t have a prebid server adapter need to download the prebid.js file with prebid server enabled.
- You need to add adapters. The setup of the auctions and adapter configuration are important. Publishers who already use prebid.js can request that the server-side setup is enabled by their current teams.
Conclusion
Prebid offers a group of open-source header bidding products that are managed by a worldwide community. Because of this, it’s reasonably affordable and appeals to all ad tech players in the community.
Since you as a publisher want to concentrate on creating content and save your resources, many managed solutions provide prebid implementation for you. Setupad Prebid solution is a comprehensive and effective way for publishers to maximize their ad revenue while optimizing direct campaigns with programmatic demand partners.
This technology is preconfigured, adapters are provided to connect with existing publishers’ GAM and SSP accounts, and the ad revenue is directly paid to the publisher from demand partners. All campaigns and programmatic bids compete in the same header bidding auction, which increases publishers’ ad revenue.
Additionally, Setupad’s header bidding wrapper is built using prebid.js and is optimized for smooth integration into a website’s source code or the publisher’s ad server. The tag-based solution gathers bids from the client and server-side connections to show the winning programmatic ads.
Whatsoever, if you decide to handle prebid independently, ensure your team can manage it.
