In this blog post, we will dive into Prebid, a type of header bidding that provides publishers with high performance. We’ll also look at how Prebid can play a role in audience identification (ID) solutions, which is growing in popularity as an alternative to 3rd-party cookies and IDFAs.
The article will look to detail how Prebid works, how Prebid can be used in applications, and how it relates to ID Solutions.
Contents
–The Emergence of Header Bidding in AdTech
– How Header Bidding Works
– Overview of Header Bidding
– Overview of Prebid
– Features of Prebid – Pros and cons of implementing Prebid
– Prebid for apps
– Prebid with ID solutions
– Summary
The Emergence of Header Bidding in Adtech
To explain Prebid, we will start with a background on the emergence of header bidding in advertising technology.
When using Google’s Google Ad Manager (GAM), a platform used by many publishers, ad requests are passed to the Google Ad Exchange (AdX), through a mechanism called dynamic allocation within GAM. If AdX does not purchase the ad, the ad request is sent to supply side platforms (SSP) connected as 3rd-party ad servers. In other words, Google is able to preferentially purchase ad inventory within Google’s own ecosystem. This article will continue with the assumption that GAM is used as the ad server.
On the other hand, non-Google SSPs will not have the option to acquire high-quality, high unit-price ad inventory, and can only purchase ad inventory that AdX did not purchase. AdX is generally considered to have a high unit price, but from the SSP operator’s perspective, it may be possible to purchase ads at a unit price higher than AdX in some cases, but not being given even that chance is a major opportunity loss for both the SSP operator and the publisher.
Against this background, a solution called header bidding was created to provide opportunities for SSPs to purchase better quality ad inventory.
How Header Bidding Works
Header bidding, as the name suggests, is a mechanism that bids ads by embedding an ad tag in the “Head” of a website, and is a solution for ad networks and SSPs to bid for ad inventory on a level playing field – before Google.
Let us explain exactly how it works.
When a user first visits a website, an ad tag in the site head fires and sends a request to the header bidding solution wrapper, before the ad server tag is loaded. Within this wrapper, the highest bid will be sent to the ad server after receiving bids from each connected operator (Bidder). The ads will then be displayed on the website after competing with the ad server’s own offers for the best price.
Through this mechanism, each SSP can now have the opportunity to bid for and purchase ads on the same level as AdX, without AdX buying first and publishers losing the opportunity through dynamic allocation within GAM.
Overview of Header Bidding
Header bidding can be divided into two main types, depending on the server used.
The first has bidding taking place on the website’s server (client to server), done through Prebid.js, an open-source solution. The second type of bidding is performed on a separate server (server to server). Some examples of header bidding utilization include Amazon’s Transparent Ad Marketplace and Unified Ad Marketplace, and Google’s Open Bidding.
We’ll dive further into Prebid.js later in this article, but Amazon’s header bidding solution uses it to conduct auctions.
On the other hand, Google’s Open Bidding service takes place within GAM. When an ad request is generated and information is passed to the ad server in GAM, a bid request is sent to connected SSPs and this flow is processed asynchronously with dynamic allocation. An auction is then conducted in accordance with the bid request, and the highest bid unit price is then returned to GAM. After which, a unified auction is conducted in GAM, where bidding prices from connected SSPs, AdX, eCPM and direct demand are compared, and the ad with the highest unit price is delivered.
Overview of Prebid
Having explained the background and structure of header bidding, we will now go deeper into Prebid.js.
Prebid.js is a type of header bidding solution for web advertising monetization, a service developed at https://prebid.org/
Its greatest pull is that it is open source technology. Although the bidders connected to each wrapper my differ slightly, the same technology can technically be used, and there are many wrapper providers that use Prebid.js technology. At AnyMind Group, we have a solution called ATS.
Features of Prebid – Pros and cons of implementing Prebid
The biggest advantage a publisher gets when implementing Prebid is, above all, the increase in revenue per ad. As explained earlier in this article, the advent of header bidding has created opportunities for other SSPs to purchase high-quality advertisements, where ultimately the publisher wins as they are able to sell ad inventory at higher unit prices. With Prebid being open-sourced, transactions are also highly transparent and more ad-serving providers will be able to enter this space – ultimately leading to more profitable transactions for publishers.
On the other hand, a disadvantage is latency. Prebid is performed on publisher-side servers, and as the number of demand sources increases, delays in site loading times will be expected. There is also a concern about the risks of delays in displaying an ad, as bidding is conducted once ad requests to GAM have stopped. In this scenario, a timeout value can also be set so that requests to GAM will be skipped if no bids are received within a specific amount of time.
Prebid for apps
Prebid.js can also be implemented in mobile apps. This is delivered through an open source software development kit (SDK) called Prebid Mobile. By implementing this SDK together with the ad server’s mobile SDK, it is possible to compete with bidding within ad servers (such as GAM and AdMob, along with other ad serving providers).
Prebid Mobile’s benefits include the following:
1. Direct access to more mobile buyers by providing a single point of integration with the Prebid server
2. When changing a bidder’s connection configuration, there is no need to update the app itself, ultimately requiring fewer man-hours on the developer’s side when changing operators
3. Open source and highly transparent header bidding service
4. Compared to mediation, real-time bidding requires fewer man-hours for partner management and ad operations
5. Less latency compared to mediation
These features make it a solution that can be expected to more efficiently improve mobile app advertising revenue. However, there are some disadvantages, which are:
1. More man-hours required compared to Prebid.js for websites and Google’s Open Bidding for mobile apps
2. Less inventory compared to Prebid for websites
Therefore, there will be questions on expected improvement in revenues generated when compared to the man-hours needed for implementation.
Prebid with ID solutions
We’ll also look at Prebid’s relationship with ID solutions.
ID solutions are expected to become an alternative to 3rd-party cookies. For publishers, data is collected and with the consent of the user, is turned into an ID by the ID solution provider and stored in the site’s first-party data repository.
But how are these stored identities actually used in advertising transactions?
Summary
In this issue, we dived into the basic structure and the advantages and disadvantages of header bidding
Many publishers have already implemented header bidding, but it would also be helpful to strengthen understanding of the features and mechanisms of both types of header bidding, whether you are currently considering implementing header bidding or have concerns about its future operations.