Header bidding — a technique that started to deal with the inefficiencies from the waterfall technique or daisy-chaining, eventually became the de facto way of running programmatic auctions. If you’re a digital publisher looking to move past ad networks and Google Ad Exchange, you’re likely to end up implementing header bidding (client-side or server-side).
While there are several advantages including — jump in eCPM & revenue and increased transparency & control, page latency has been considered a drawback that should be addressed.
If you use a managed header bidding provider, you’re sorted out. For example, at Automatad, we continually invest and maintain our server-side infrastructure to ensure our publishers aren’t facing any latency issues. On the other hand, if you have an in-house team and extensive resources (team & infrastructure), you’ll be able to reduce the latency to an extent. At the end of the day, latency wouldn’t be an issue.
So, if you are a publisher who doesn’t fall in either of the two buckets and still want to leverage header bidding, meet — Post bidding.
Sidenote: You can implement header bidding (or pre-bidding) yourself. But there are prerequisites to partner with the SSPs and ad server setup requires at least some technical know-how.
Table of Contents
So, What is Post-Bid or Post-Bidding?
Post-bidding is a way for publishers to directly connect with multiple demand partners and run simultaneous auctions to get their best bids — after the ad server delivered the creative.
Yes, it’s the same as header bidding or pre bidding with one important difference — unified auction happens after the ad creative from the post bid line item is delivered. Hence the name, post-bidding.
Let us show in a simple diagram:
Before we get into how it works, you should have a question. How can an auction happen once the creative is delivered? Well, in post bid, ad creative is nothing but a prebid.js tag (a third-party tag). So, if the post bid line item wins the auction, then the creative or prebid.js will render on the page. This, in turn, will call the demand partners and run the auction and serve the ad from the highest bidder.
How Does Post-Bid Work?
Alright. Let’s try to understand the complete process in the right order.
- When a page gets loaded, it calls the GAM (ad server) via GPT.
- Then ad server picks the right line items to sell the impressions in a unified first-price auction*.
- If the ad server calls the post bid line item and if it wins (based on historic price), then the ad creative will render on the page at the designed ad slot.
- In this case, as the ad creative is Prebid.js, it will initiate the typical bidding process. That is, it calls the demand partners and runs the simultaneous auctions.
- The winner’s ad is then rendered to the user.
*As you know, there’s no more waterfall in GAM and it’s now a unified, first-price auction. Why do publishers go with header bidding then? Well, that’s for a different post. You can get some ideas here.
What are the Benefits of Post-Bid?
There are a few advantages in post bidding.
- You don’t need a lot of resources and ad ops engineers or devs to implement it. As it’s similar to any regular line item setup — the only exception is you add prebid.js in place of third-party creative tag — it’s comparatively easy to get started.
- No added latency. The auction starts once the ad creative is served on the page and this means, there’ll be no latency.
Are there any Drawbacks?
It has its drawbacks. We’ll start with the most important one.
- Revenue uplift won’t be as great as header bidding. In header bidding, your revenue can jump substantially (by up to 50%) but in post-bid, it’s not the case. Why?
In header bidding, you get a real-time price for your ad impressions from the multiple demand partners and then send their bids to the ad server for another round of auction with the demand sources and direct line items configured inside the server. In post bidding, GAM picks the post-bid line item based on the historic price (not real-time) as the real-time auction happens only after the creative is delivered.
Another problem is, as it’s not the real-time price, you aren’t allowing demand partners to compete with AdX on an even footing.
- Multiple ad units on the page can result in multiple simultaneous auctions. Let’s say you have two ad units on the page and both of them are about to serve the post-bid ad, then there’ll be two separate auctions happening and this can overload the browser.
But it won’t affect the content on the page as content can load before the auctions.
- You can’t get granular reporting; only aggregated. You need to use a third-party analytics provider to get the bid-level data for the individual demand partners.
Should You Try Post-Bidding?
Post bid programmatic can help you run the auction on the client-side (so better match rates), have direct relationships with the demand partners, and provide transparency. It can reduce the latency compared to header bidding.
That being said, if you’re planning to try out post bidding — just because header bidding causes latency, don’t. You can resolve latency issues to an extent with a universal timeout, bidder-level optimization, etc. And besides, the header bidding script is asynchronous (it won’t even block the other content from loading). Else, you can consider footer bidding. The practice of running header auctions once the page elements/content are loaded.
As Google Ad Manager itself is running the unified first-price auction, you don’t have to run post-bid for the reason of parallel/simultaneous auction as well.
But if you don’t have the necessary resources and wouldn’t want to use any managed header bidding solutions, then post bid can work for you.