Over the past few years, Clearcode has worked on many Prebid-related projects for our clients where we’ve built wrappers, adapters and user interfaces to manage the header bidding process and various demand sources.
We’ve also built our own header bidding solution — Header Bidding Control Center — that allows companies to manage their Prebid setup via an easy to use UI.
Recently, Clearcode’s Head of Marketing, Michael Sweeney, talked with Jacek Jagiełło, a system architect in Clearcode’s R&D department, about how companies can build, configure and implement Prebid Server.
An Overview of Prebid
What Is Prebid?
Prebid is an open-source solution that allows publishers to run header bidding auctions on their websites and mobile apps. Prebid.org is the organization that manages and maintains the standards, JavaScript libraries and SDKs that companies can use to add header-bidding capabilities to their digital properties (e.g. websites and mobile apps).
Header bidding is a technical process whereby publishers can sell ad impressions via multiple supply-side platforms (SSPs) before their ad server is called to find an ad for available ad space.
The benefit of using header bidding is that publishers are often able to find higher-paying advertisers via header bidding than via the deals they have set up in their ad server, e.g. direct deals and OpenRTB deals.
We Can Help You Build a Header Bidding Solution
Our AdTech development teams can work with you to design, build, and maintain a custom-built header bidding solution for any programmatic advertising channel.
What Is the Difference Between Prebid.js and Prebid Server?
When it comes to implementing header bidding using Prebid, publishers have two main options — Prebid.js and Prebid Server. In simple terms, Prebid.js is a JavaScript library that publishers can use to run client-side header bidding auctions, and Prebid server is a dedicated server that publishers can use to run these auctions on a server, rather than in the web browser (e.g. client-side header bidding).
Both the client-side (Prebid.js) and server-side (Prebid Server) implementation have pros and cons.
The main benefit of running header bidding auctions in web browsers is that it’s easier to identify individuals, e.g. via cookies. However, the main downside is page-load latency. The more demand partners a publisher works with, the longer it will take to display the ads, which can cause a poor user experience.
The main benefit of running header bidding auctions on a server is that you move all of the client-side requests away from the web browser, which reduces the latency to the bidders. The main downside is that it’s harder to identify individuals as it’s harder to pass cookies from the web browser to the Prebid Server.
For app developers wanting to monetize their mobile ad inventory, they have to use Prebid Server, since the Prebid Mobile SDK requires it.
Prebid.js vs Prebid Server: Which Option Delivers the Most Ad Revenue?
Identifying which implementation method delivers the most ad revenue can be hard to determine as it often depends on other factors, such as the publisher’s inventory type, audience, and the demand partners it works with.
In general, if a publisher relies on cookie matching — i.e. identifying an individual via IDs located in web cookies — to sell its inventory, then they may see a decrease in ad revenue if they switch from Prebid.js (client-side header bidding) to Prebid Server (server-side header bidding).
The reason for this is because advertisers will pay less money for an impression if they can’t identify the individual and determine if they’re a member of their target audience.
To get the best of both worlds, some publishers opt for a hybrid model whereby they run their best-performing demand partners via Prebid.js and use Prebid Server for all other demand partners.
Q&A: How Can You Use Prebid Server to Build an Ad Exchange?
What Is Prebid Server and How Is It Typically Implemented?
Michael Sweeney: Before we dive into the specifics around using Prebid Server to build an ad exchange, let’s discuss how Prebid Server is typically used vs when it’s used as an ad exchange. What are the differences in how it’s used in these two different situations?
Jacek Jagiełło: Let’s start by talking about the typical use case of Prebid Server for a publisher.
Typically, a publisher would have its own Prebid.js setup configured on their website, so they can sell their inventory through multiple supply-side platforms (SSPs).
For performance reasons, they may decide to use server-side header bidding (SSHB), so they deploy Prebid Server, configure the adapters on the server-side, and then adjust their Prebid.js configuration to connect to Prebid Server to perform server-side header bidding.
However, an agency that has a well established demand network needs a way to connect new publishers to their demand network, which is essential to scale their business.
To make it possible to onboard new publishers to the demand network, the agency can create an adapter which connects to their Prebid Server, and offer it to publishers. In this case, the agency’s adapter will essentially act as another Prebid.js adapter for the publisher.
Michael Sweeney: So in some situations, a publisher might be using Prebid Server themselves and be approached by an agency saying “We can give you access to more demand via our Prebid server”. Would that situation be possible? Can publishers implement and call multiple different Prebid servers?
Jacek Jagiello: The agency’s adapter that the publisher will configure on the website to get access to the agency’s demand can call any endpoint that will return the bids. This endpoint could be Prebid Server.
This is beneficial for the agency, since they do not need to develop their own software that integrates with each demand source; they can use Prebid Server instead.
However, if a publisher is using the same bid adapter as an agency in their demand network, then it’s possible that the publisher could receive two or more bids from the same demand source. Bid duplication is actually fairly common with both header bidding implementations (i.e. SSHB and CSHB).
Michael Sweeney: Yea, bid duplication is an issue in header bidding, especially if you have multiple partners — SSPs or even Prebid servers. As you said, the publisher and the agency they work with could have the same demand sources in their adapters, meaning they would both be receiving bids from the same demand source.
Jacek Jagiello: Yes, and they might have different user IDs but eventually the bids would come from a single website, which can also be identified as you can pass the domain in an OpenRTB request.
Michael Sweeney: Right, so how can advertisers determine whether they are sending back bid responses for the same impression?
The advertiser might be able to detect this duplication by correlating the time the two bid requests were received. There are a few ways in which an advertiser can detect duplicated bids.
Michael Sweeney: And how can a publisher identify whether they are getting the same bids when they are using two different Prebid Server setups? Is there a way for publishers to see which demand sources their agency is using?
Jacek Jagiello: It depends on the implementation of the agency’s adapter. The agency might act as a proxy whereby it works with a bunch of demand partners but feeds them to the publisher via its own adapter.
The agency might say “We use these adapters and this demand source returned this bid.”
But they also might say “Here is a bid from us, (but they actually got it from AppNexus), but we say it’s our bid because it comes from our network, from our adapter.”
But under the hood, the agency may have used different adapters. So it depends on the agency’s policy I guess.
If the publisher contacts the agency and asks for the list of the partners they work with, they should be able to spot overlapping bidders.
How Can Agencies Build An Exchange Using Prebid Server?
Michael Sweeney: Let’s start by providing an overview of how the header bidding process works with Prebid Server.
Jacek Jagiełło: The process looks like this:
- A user visits a web page and the page starts loading.
- The page loads the Prebid.js script, which is located in the header (i.e. between the <head> </head> tag) of the web page, and sends a request to the Prebid Server.
- The Prebid Server then passes on the information about the website, inventory and user (e.g. user ID, if available) to the various supply-side platforms and ad exchanges that have been configured in the Prebid Server adapter.
- The SSPs then pass on a bid request to the various demand sources like demand-side platforms (DSPs) and ad exchanges. The demand sources will likely have hundreds, even thousands, of ad campaigns to choose from on behalf of the advertisers they represent.
- The SSPs analyze responses from demand sources, and return the bid to Prebid Server.
- The Prebid Server returns bids to Prebid.js configured on the publisher website.
- Depending on Prebid.js configuration, all bids or only the highest bid is passed to the publisher’s ad server. This bid can now compete with the other ad-monetization sources in the ad server, e.g. direct deals.
- If the publisher’s ad server decides that the header-bidding bid wins the auction, a special creative is returned from the ad server to the website, which renders the advertisement contained in the bid.
Michael Sweeney: In this example, we’re talking about an agency operating a Prebid Server implementation, but could SSPs and even a publisher operate a Prebid Server implementation?
Jacek Jagiełło: Yes, the Prebid Server implementation can be operated by the publisher, or it can be provided by an SSP, or in this case, by an agency.
The Prebid Server would contain various adapters from SSPs and ad exchanges, which would be called when the Prebid Server receives a request from the website or mobile app.
Michael Sweeney: Tell us about the role the agency plays here and what its adapter does.
Jacek Jagiełło: So in this case, the agency operates and manages the Prebid Server and offers it to publishers so they can add it to their website and access the demand sources provided by the agency.
The agency has the identifiers, the bid parameters, etc. that they use across multiple publishers. They can also generate specific parameters for specific publishers if they need to. This information, along with the configurations, are hosted in Prebid Server.
To allow publishers to start using their Prebid Server, the agency simply needs to provide them with its adapter, which is added to the publishers’ websites.
Michael Sweeney: To benefit from building this Prebid Server, you would need to have access to a lot of demand, i.e. different DSPs, as well as relationships with a lot of publishers, right?
Jacek Jagiełło: Yes. The Prebid Server works in a similar way to an exchange, except that there are no auctions taking place — the actual decision about which bid should be returned takes place in the SSP or ad exchange, just like in a typical real-time bidding (RTB) auction. The Prebid Server is used to host and manage the various connections with demand sources.
Someone may use the term “Prebid auction”, but what they mean is that the bids are sent to different SSPs. The auctions don’t take place in the Prebid Server.
It’s also worth pointing out that Prebid Server isn’t an ad server either.
There is no complex logic that you can program into Prebid Server like you would do in an ad server. That’s one of the differences between Prebid Server and an ad server — the Prebid server doesn’t use any complicated logic to determine the winning bids; either it returns all bids or the highest bid obtained from the demand sources.
It’s also worth mentioning that the publishers will be using an ad server, e.g. Google Ad Manager or another ad server, that makes the final decision about which ad to show.
The ad server receives the winning bid from the header bidding auction and then puts that up against the other line items, e.g. direct deals, and then selects the highest-paying option.
How Does Prebid Server Pass On the Winning Bid to the Ad Server?
Michael Sweeney: You just mentioned that Prebid Server is responsible for passing on the bid requests to the SSPs and ad exchanges and then collecting the bid responses. So once it’s collected the bid responses from the SSPs and ad exchanges, does the Prebid Server then connect directly to the ad server and pass that highest bid, or all bids if that’s how it’s been configured, to the ad server?
Jacek Jagiełło: Prebid Server doesn’t interact with the ad server directly — it returns bids to the browser. The web browser then passes them to the ad server via Prebid.js, which is configured to either send all of the bids, or only the highest-paying bid to the ad server.
Michael Sweeney: What information is passed from the browser to the ad server to display the ad?
Jacek Jagiełło: There is a special creative called Prebid Universal Creative that needs to be configured in the publisher’s ad server. It’s an HTML snippet that you put into the ad server. You then need to configure a line item with a creative.
This creative is then returned to the browser, and the snippet calls Prebid to display a winning creative. It’s like the ad server saying to Prebid “you won the auction, please display this creative.”
It’s a bit like Piggybacking because the code used to display the Prebid ad is served as a piece of HTML code from the ad server.
So the ad server only knows that this line item won the auction and has to pass the snippet. The snippet code then calls Prebid to display the ad.
Michael Sweeney: It’s amazing how all of this happens in the time that it needs to happen. We’re talking about sending a request from the browser to the Prebid Server, and then to all these other AdTech platforms, and then back again. And then sending it back to the browser and then to the ad server. The ad server then needs to decide which ad to show out of all of the different deals and then carry out the whole ad serving process. And this happens while the web page is loading!
Jacek Jagiełło: Yes, there are many processes happening behind the scenes when a web page is loading and it’s all happening extremely quickly.
And because of all that, it’s prone to human error and misconfigurations on multiple levels, which is why it’s important that companies work with a team that knows how to properly build, configure and implement either a Prebid.js or Prebid Server setup.
One small error or misconfiguration can result in the whole header bidding process not working at all.
How Long Does It Take to Build an Exchange Using Prebid Server?
Michael Sweeney: I know that Clearcode has worked on a few projects recently where we’ve essentially built an exchange using Prebid Server adapters for our clients, so how long does it generally take to build a solution like this?
Jacek Jagiello: It depends on a couple of factors, such as the demand sources that the publisher or agency would like to integrate with.
The implementation itself is pretty straightforward as you need only to deploy the Prebid server, and then write the adapter. Generally speaking, that part would take about a month or so, but then you may need to spend another 4 or 6 weeks configuring the adapter, testing and resolving issues and implementing any custom features etc.
We Can Help You Build a Header Bidding Solution
Our AdTech development teams can work with you to design, build, and maintain a custom-built header bidding solution for any programmatic advertising channel.
