Necessity is the mother of invention, and ‘Header Bidding’ is one good example. So, when publishers and advertisers were losing revenue, were fed up with big players’ monopolies, and needed more efficiency, transparency, and flexibility in programmatic advertising- header bidding was born.
Header bidding was conceptualized in 2014 and went mainstream in 2016. It slowly picked up the pace, and became an instant hit, mainly after The Telegraph, a British newspaper, logged an increase of 70% in its programmatic revenues with header bidding implementation. According to a report by Statista, around 70% of online publishing websites and 16% of the top 100 thousand U.S. websites reportedly used header bidding in Q1 of 2022.
Source – Statista
Table of Contents
What Is Header Bidding and How Does it Work?
Header Bidding is an advanced programmatic advertising technology that enables publishers to offer their ad inventories to multiple ad exchanges, SSPs, DSPs, ad networks, etc., simultaneously for auction. Unlike selling the inventory to the highest bidder by sequentially going to the demand partners (waterfall method), header bidding calls all at once. This brings in more transparency and competition.
The publisher can know which demand source is ready to bid the highest at once. Header bidding also increases digital publishers’ ad revenue by opening their ad inventory to several demand sources before placing an ad call to Google Ad Manager or any other ad server.
How Header Bidding Works?
Header bidding works with JavaScript (js) code placed in the header (<header>) part of the page, also called header bidding wrapper.
Before exploring how header bidding works, it is important to understand its two important components: header bidding wrapper and adapter.
Header bidding wrapper: Also called a container and framework, it is a JavaScript code that the publisher adds to the header of the website.
It’s like the central functional hub, which receives the ad request call from the publisher’s website, and sends out the bid request to all the connected demand partners. It also performs the function of receiving the bid, selecting the highest bid, and then sending it to the ad server like GAM.
Header bidding adapter: They are, again, small pieces of JavaScript code that let the header bidding wrapper connect to the different demand partners.
Each demand partner will have a unique adapter built specifically for the wrapper. The adapter translates the wrapper’s generic bid requests and responses into the specific format required by that demand partner. Adapters also handle the communication between the wrapper and the demand partner’s ad server. We have explained this in detail later in the article.
Now, let’s see how header bidding works:
The header bidding wrapper begins loading as soon as the webpage loads in the user’s browsers. It then connects to the demand partners for bids before the ad server is called. All this happens within a fixed time frame, preferably two seconds, as set by the publishers. It means the SSPs, direct DSPs, ad exchanges, and ad networks must respond with their bids within two seconds.
Let’s understand the process in detail:
Step 1: The publisher places a line of JavaScript in the website’s header, called header bidding wrapper.
Step 2: The user hits the URL address.
Step 3: The publisher’s website loads the “wrapper” script (JavaScript) in the header of the page.
Step 4: The wrapper script sends ad requests to multiple ad exchanges, SSPs, and other demand sources, asking them to bid on the ad inventory. These bid requests are made either directly by the user’s browser or via an ad server (auction server). You can learn more about it in the article – client-side vs. server-side header bidding.
Step 5: While the header auction (or header bidding or pre-bidding) happens, Google Publisher Tag is paused. Each demand source responds with a bid, typically expressed as a CPM (cost per thousand impressions) or CPC (cost per click) offer.
Step 6: Once it gets the bids from header bidding partners, the wrapper script selects the highest bid. GPT calls the Google Ad Manager (ad server) and sends the secured bids for server auction.
Step 7: The server auction happens between the bids from header bidding partners and other deals, such as programmatic guaranteed, sponsorship, etc., connected to the ad server (for example, Google Ad Exchange). The highest bidder will get the impression.
Header bidding allows multiple advertisers to bid on ad inventory simultaneously before the ad server decides which ad to display. The process occurs in the webpage’s header before the page has fully loaded, allowing the publisher to receive higher bids for their inventory. As several advertisers bid in real-time (real-time bidding), it increases the competition for the publishers’ ad inventories and thus offers a better chance of getting higher CPM.
Waterfall Vs. Header Bidding
Waterfall
Before header bidding, the programmatic advertising ecosystem included the waterfall or daisy chaining technique to auction off the ad spaces. Let’s understand this in detail:
When a user loads a page, your site reaches out to the ad servers to serve direct-sold ads received via programmatic direct campaigns. These ads are either obtained via programmatic guaranteed or preferred deals.
If the spaces still remain remnant, i.e., no advertisers bid or bought your ad spaces, then the ad server will make it available for the SSPs to bid in real-time. The bidding here happens in the waterfall sequence, where the bid request is sequentially passed through top-ranked SSPs based on historical data. So, if your ad server has marked a particular SSP on the first rank based on size, previous CPM rates, or buying frequency, then this SSP will get the first chance to bid. If not, the bid request will be passed to the second (based on the same historical data), and so on.
The problem is that every time your impressions get passed down to another buyer, the price will cascade down. In some cases, there might be the highest bidder sitting in the second or third position who never got a chance to win the bid because of the hierarchy. Additionally, because the publisher has to wait for each SSP to bid on the inventory, the process can be slow and time-consuming.
Header Bidding
On the other hand, header bidding offers ad inventory to multiple demand sources simultaneously rather than sequentially. This allows publishers to access a wider pool of potential buyers and receive higher bids for their inventory.
Additionally, header bidding allows for real-time auctions rather than the delayed bidding that occurs in the waterfall method. This results in faster page load times for users and a better user experience. It gives publishers more control and transparency over their ad revenue and allows them to maximize revenue from their inventory.
To implement header bidding, you need a header bidding wrapper to connect to demand partners, send ad requests, solicit bids, and finally send them down to the ad server (like Google Ad Manager).
Simply put, the wrapper is a JavaScript code that works as a container and helps you facilitate bids from different demand partners (SSPs) for sending it down to the ad server.
The ad server will get the bids and then decides on the winner. It also sets the rules for programmatic auctions. Prebid is the preferred header bidding wrapper in the space. You can learn more about the header bidding wrapper in our detailed article.
What Is an Adapter?
In a nutshell, getting an adapter means getting demand from the supply-side platform. Then, why do we need a wrapper? Because wrappers are the containers that hold the adapters. A header bidding wrapper alone cannot help you to integrate demand partners. As we explained earlier, you need an adapter to access an SSP’s demand.
Adapters are of two types. One type can get you demand (bidder adapters), and the other is to help you with analytics (analytics adapter). We have detailed articles on bidder adapters and analytics adapters.
Real-Time Bidding Vs. Header Bidding
How to Setup Header Bidding?
To implement header bidding, you require a wrapper, adapters (or demand partners/SSPs), and you also need to create corresponding orders and line items in your Google Ad Manager account. It requires a continuous connection between the header bidding wrapper, the Ad Manager, and the adapters.
A publisher would need to do the following to set up header bidding:
- Implement the header bidding code on their website. This code needs to be placed in the header of the publisher’s webpage, and it typically includes the names of the ad exchanges, SSPs, and ad networks with whom the publisher wants to work.
- Test the header bidding setup to ensure it’s working correctly and that you receive bids from the ad exchanges.
Learn about the setup in detail with our article: How to Get Started with Header Bidding?
Alternatively, you can also use managed header bidding providers as a substitute to set up header bidding. Managed header bidding providers are companies that handle the technical aspects of header bidding for publishers, such as the setup, bring-in demand partnerships, integrating with ad exchanges, and optimizing bid requests.
Factors to Consider While Implementing Header Bidding
An improper header bidding implementation might result in a poor user experience and a revenue drop. So, while deploying header bidding, consider the following factors.
- Demand Partners: It is important to have strong demand partners to reap the benefits of header bidding. As a publisher, your initial step is to partner with SSPs and any demand partners to have several advertisers bid on your inventory.
Also, it is integral to have the ideal number of demand partners. The higher the number of bidders, the slower the page can load.
- Page Latency: As you know, in client-side header bidding, the browser calls the demand partners and waits for them to make their bids. This also results in increased page load time.
You can set a universal timeout using wrappers to avoid latency issues and the resulting poor user experience, i.e., how long should the browser wait to receive the bids. You can also experiment with a hybrid header bidding setup.
- Asynchronous: With a header bidding wrapper, you can also make the header bidding ‘asynchronous’. This will not make the content wait for the ad to load. The page content will load independently.
- Discrepancies: Though we all know how header bidding maximizes the publishers’ yield and embraces transparency, you should keep an eye on discrepancies. As soon as any bidder wins the auction on the server, Google Ad Manager records an impression.
But the header bidding partners wouldn’t record the impression until the actual creative is delivered while the user is on the page. This can lead to a discrepancy of up to 30%, which is a substantial loss in revenue. Here’s how to minimize the discrepancy between header bidding partners and Google Ad Manager.
Mistakes to Avoid in Header Bidding
There is a big no-no to certain factors when it comes to header bidding implementation, and you must avoid them:
- Too many header bidding solution providers: With multiple header bidding providers, you risk putting the same impression up for sale to the same buyer on more than one occasion. This will lead to duplicate bids, and the demand for your ad inventories will subsequently decrease.
- Too many bidders: Publishers should not include too many ad exchanges and SSPs in their header bidding setup. This can increase the latency and slow down the webpage. It’s recommended to test with a smaller number of demand partners first and then gradually increase the number of bidders.
- Inadequate server capacity: Header bidding generates a lot of requests and can put a lot of stress on the publisher’s server. Publishers should ensure that their servers can handle the load and invest in additional resources if necessary.
- Not testing the setup: Publishers should thoroughly test the header bidding setup to ensure that it’s working correctly and that they’re receiving bids from the ad exchanges. This will help them to identify and fix any issues before they become a problem.
- Not optimizing timeouts: Timeout values should be set in a way that balances the number of bids received with latency. If the timeout value is too low, the publisher may not receive enough bids. The page may take too long to load if it’s too high.
- Not monitoring the performance: Publishers should regularly monitor the performance of their header bidding setup to ensure that it’s running efficiently and effectively. This will help them to identify any issues and make adjustments as needed.
The Road Ahead
Header bidding has undoubtedly revolutionized how publishers monetize their inventory by providing a more efficient and transparent way of selling advertising space. It has increased the competition for your ad inventory by letting more advertisers bid for it in real-time, thus increasing ad revenues. However, header bidding can also cause latency, especially when implemented poorly. You also run the risk of ad fraud and will need specialized technical expertise to run in-house header bidding. The best foot forward for the publishers will be thus to partner with a header bidding provider like Automatad.
With Automatad, you get easy access to 50+ SSPs and DSPs and the exclusive demand they bring. The header bidding wrapper runs unified auction (both client-side and server-side header bidding) by connecting with Google’s Open Bidding, Amazon’s Transparent Ad Marketplace, and Prebid. The fully transparent setup can go live within 72 hours of contract signing, plus you get access to our complimentary monetization products, an AdOps team to optimize your setup, and 24*7 support. Connect now!
FAQs:
1. What Is the Difference Between Open Bidding and Header Bidding?
Open bidding is server-to-server bidding where third-party exchanges are called to compete with Google AdX for your inventory in real-time. Open bidding is a header bidding solution brought by Google.
On the other hand, header bidding sends bid requests to all SSPs, DSPs, and exchanges. It can be conducted either on the client-side or server-side based on the needs of the publisher.
2. What is Dynamic Allocation?
Many of the site publishers utilizing Google’s ad server employ a setting called- dynamic allocation that allows its Ad Exchange (Google AdX) to outbid any of the winning waterfall bidders because AdX gets to make the last bid. This is supposed to maximize yield but also puts AdX in a privileged position. Google will wait to receive the bids from other exchanges and get the ‘last look’. And then it’ll try to outbid the exchanges to win the auction.
3. Can I Implement Header Bidding on a WordPress Site?
Yes, you can implement header bidding on a WordPress site. To implement header bidding on a WordPress site, you must add the header bidding code (aka script) to the head of your web pages.
