Post-bid allows a publisher’s demand sources to compete in one auction based on price after the ad server has declined to choose a direct-sold or exchange-based line item.
Post-bid is the configuration scenario where a publisher loads and runs Prebid.js
in a winning line item’s creative. In a post-bid setup,
demand sources compete after the ad server has chosen the post-bid line item. Compare this to:
This diagram summarizes the post-bid scenario:
The main reasons we have seen publishers opt for post-bid (instead of header bidding) are:
The post-bid creative is just a 3rd party tag. Once it’s served to the page, prebid.js runs an auction across all demand sources. The only technical work is to insert the tag Ids into the 3rd party tag’s JSON config for the demand sources. It’s trivial work.
Because post-bid is just a 3rd party tag, the ad server receives the impressions as soon as the page loads. The post-bid setup does not affect other ad spend. Post-bid actually reduces latency compared to a daisy chain mediation setup, because in post-bid all demand sources are requested concurrently, instead of in a waterfall.
Additionally, post-bid does not need as many line items, so initial setup is easier than header bidding.
We’ve listed the advantages of post-bid over header bidding in the previous section. The disadvantages include:
The bid price on the post-bid line item is static (based on historical price). It thus has the typical problems of a 3rd party tag line item. Due to this downside, the post-bid setup cannot make header bidding demand partners compete on an even footing with other types of demand.
If there are multiple ad units on a page that fall into the post-bid scenario, each creative loads and runs Prebid.js separately. This can cause more work for the browser (or device) as it loads the code multiple times and runs separate auctions. However, since this activity takes place after the ad calls, content is generally already loaded.
In the ad server’s post-bid line item report, you’d only get an aggregated report of all demand sources. You may need to rely on a 3rd party reporting service to record which demand partner wins how much inventory.
|No additional ad serving latency. Waterfall adds latency when networks do not fill.
|No additional ad serving latency. Parallel auction for demand sources thus minimum latency.
|Additional ad serving latency from the page’s timeout setting.
|Can compete among demand sources
|Can compete with direct-sold ads & AdX dynamic allocation
|Block page content from loading?
|No (with Prebid.js)
Yes. Check out the example.
Yes, it works the same as for browsers. When utilizing a server-to-server architecture, the app config option can be used to forward the mobile app details.
Please refer to the example.