- Header Bidding
- App Monetization
- Header Bidding
- iOS Ad Mediation
Like any tech topic, header bidding is surrounded by industry-specific terms. And while everything may seem to be pretty clear with header bidding mechanics, terms like client-side header bidding, server-side header bidding, prebid wrappers, SSPs, DSPs, ad networks, ad exchanges, etc. might cause confusion. This glossary helps clarify their correct meaning in relation to each other. Here, you’ll find clear definitions of basic header bidding terms and get ready for a deeper dive into the topic.
Get actionable insights for your product
An ad server is the ad delivery technology that is used for the management, serving, and tracking of ads or the monetization of one’s ad slots. An ad server decides which ad to serve where and when, and enables all types of ads: direct deals, internal promotions, and programmatic ads. In the header bidding setup, the auction is conducted before the ad server is called.
There are two types of ad servers: sell-side and buy-side, which are also known as publisher-side and advertiser-side, respectively. While a sell-side server is responsible for serving and managing ads that appear in the publisher’s ad space, a buy-side ad server manages and tracks creatives that appear in the publisher’s ad space.
Despite all the advantages of an ad server, it is possible to avoid using one by letting the ad network do the whole job. However, if you are managing direct deals, internal promotions, and multiple programmatic partners, having a solid ad server in place is critical.
In client-side header bidding (or browser-side header bidding), the auction is executed on the user’s browser when they visit the publisher’s webpage. Since the entire process of requesting and receiving bids takes place on the user’s browser, this may lead to increased latency.
Server-side header bidding is basically the answer to the increased latency caused by the client-side approach. In server-side header bidding, the auction logic is executed on a separate server. As a result, the only thing the user’s browser does is send a single request to the auction server, while all the sending and receiving of bid requests and picking the winner is taken care of by the third-party server. This approach thus tackles the latency problem. However, this puts the publisher at the mercy of the third-party server with respect to auction mechanics, logic, and access to bid data. This fact makes server-side header bidding less popular than its client-side counterpart.
Since both server-side and client-side header bidding solutions have their own pros and cons, many publishers are increasingly trying to get the best of two worlds by combining the two, which is known as the hybrid approach. An example can be utilizing the server-side header bidding technology for demand partners with broader advertising goals (like increasing brand awareness) and turning to the client-side model when it comes to advertisers that are using cookies to target their chosen demographics.
Basically, in-app bidding is mobile header bidding — header bidding in the world of mobile apps. The catch is that since there is no header in a mobile app, the entire auction takes place on the server once the user begins the session, making in-app bidding is the variation of server-side header bidding.
In programmatic advertising terms, demand partners (also: header bidding partners, demand sources, and programmatic partners) are participants in the header bidding auction. They might include ad exchanges, supply-side platforms, ad networks, etc. It’s critical to be selective about your HB partners. Though it might be logical to resort to ‘the-more-the-better’ approach, too many bidders lead to increased latency.
CPM stands for ‘cost per mile’ or ‘cost per thousand.’ It is a price that an advertiser is willing to pay or bid for an ad impression multiplied by 1000. The notion of CPM is connected to eCPM, which means ‘effective cost per mile.’ Since advertisers usually bid on impressions with different CPMs, eCPM is the average of all CPMs as seen by a publisher for a particular ad placement.
Back in the day, publishers would add and manage each of their demand partners individually. The process was time-consuming, which has given rise to header bidding wrappers (also known as prebid wrappers).
To date, Prebid.js is the most popular open-source header bidding wrapper, while companies like Index Exchange can be found among the most popular proprietary header bidding solutions.
A supply-side platform is the AdTech software that helps website and mobile app owners monetize their products by selling vacant ad slots to advertisers. SSPs often serve as an intermediary between the publisher and the ad exchange, ad networks, and demand-side platforms, thus optimizing the entire monetization strategy and protecting the publisher’s ad space from unwanted ads. An SSP allows publishers to manage ad slots according to the needs of their localized audiences, conducts RTB auctions (more about that below), and chooses the best latency level for the publisher. Within the header bidding setup, a publisher can have multiple SSPs, which serve as demand partners. The top SSPs include Google Ad Manager, OpenX, AppNexus, and Rubicon Project.
A demand-side platform (DSP) is to an advertiser what an SSP is to a publisher. It is an AdTech software that helps advertisers buy publishers’ ad inventories and display their ads. A demand-side platform offers the following functions:
Here’s how the ad buying process works: 1) With the help of their SSPs, publishers list their vacant ad slots on the ad exchange 2) The ad exchange notifies the DSP about an available slot 3) The DSP analyzes the slot in terms of its compatibility with the advertiser’s brief and makes a bid in the real-time bidding auction, and 4) The winning bid receives the slot or takes part in the header bidding auction.
The top DSPs include: Epom DSP, Pocketmath, Amazon, SmartAds DSP, and MediaMath DSP.
An ad exchange is a virtual marketplace for programmatic ad buying and selling. Ad exchanges aggregate information from publishers and advertisers and facilitate the process through real-time auctioning. The latter fact sets them apart from ad networks that determine prices on their own. Simply put, an ad exchange is a pool of impressions.
Real-time bidding refers to selling and buying ad impressions through a real-time auction conducted by an ad exchange or an SSP. The process takes from 100 to 1500 milliseconds.
Though RTB auctions are associated with the waterfall setup, they can also co-exist with header bidding. Here’s how RTB works when header bidding is implemented:
When a user accesses the publisher’s webpage, the user’s browser asks multiple demand sources to make a bid. Many of these sources conduct RTB auctions to determine which bid to send. Then, the winning bids compete against each other in the header bidding auction.
In the RTB setup, demand partners mainly stick to the second-price auction model. This means that the auction winner doesn’t pay the price offered by them. In fact, they pay the second-highest price in the auction + $0.01. For example, if three demand partners take part in the auction, and DP A bids $4.00, DP B — $4.50, and a DP C — $4.20, the second bidder wins and pays $4.21.
This model promotes defining the ‘real market value’ of an impression and prevents advertisers from being ripped off if their bid is too high.
Despite the benefits of the second-price auction, it loses popularity. As the
‘intricacy” of the programmatic marketplace increases, Google, OpenX, and other major players are switching to the first-price auction model.
Within the first-price auction setup, bidders pay what they bid — an auction in its classic sense. For example, a buyer with a winning bid of $5 pays $5 — transparency at its best! While increasing transparency, the first-price approach makes it easier for advertisers to properly value inventory and minimizes operational complexity to publishers.