The Role of Prebid in App and ID Solutions

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 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.  This article will continue with the assumption that GAM is used as the ad server.

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 may differ slightly, the same technology can technically be used, and there are many wrapper providers that use Prebid.js technology.

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?

This is where Prebid.js and the UserID module come into play. The publisher will be able to access a number of ID solutions through Prebid’s UserID module, and 1st-party data is managed within the wrapper. The IDs managed within the wrapper will then allow user identification, making ad requests more efficient for demand-side ad transactions on Prebid.

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.

Author: Ben Chien, Managing Director of AnyMind Group (IAB Hong Kong AdTech & Programmatic Committee)

Please address any questions or comments about this blog to Alvina Chan, Secretariat Office, IAB (Hong Kong) - alvina.chan@iabhongkong.com