RTB stands for Real-Time Bidding and refers to the automated process of buying and selling ads. RTB, as the name implies, runs in real-time, on a CPM basis, in the form of an auction. This process is facilitated by an SSP (a Supply Side Platform). 

The auction process, at its most basic, consists of a publisher (the supplier of the inventory),  an SSP (the facilitator of the auction), a DSP (the media buyer), and an advertiser (who wants their ad to be shown). 

At any second in the RTB ecosystem, there are countless bid requests on which DSPs are bidding. The process in which a single ad request is sent, until the end of the bidding process where there’s a winner, takes somewhere between 100-300 milliseconds.

A bid request, on the user’s side, is the moment in the app just before the ad appears. In many cases, before the ad even appears to the user, the SSP had already run the auction, a media buyer won the bid, and the ad had been pre-cached and will be displayed at the right moment. 

The process is automated, it can be programmatic or even ML-based, which allows advertisers to efficiently use their marketing budgets (bidding higher on users most likely to convert, lower on users who are less likely to convert, and dismissing the bid on unfitted users). 

To learn more, read our intro to programmatic mobile user acquisition 

Since RTB uses automatic media-buying, it is, by definition, programmatic, but that does not mean that all programmatic media-buying is done via RTB. RTB utilizes programmatic media buying by bidding in an open market. Having it be a real-time auction is what differentiates programmatic from RTB. 

Programmatic, on the other hand, can also refer to directly buying from a publishers’ inventory. The term programmatic solely refers to the fact that the inventory is bought automatically. 

There are different ways in which advertisers can acquire inventory in the RTB ecosystem, through the open market part of the RTB ecosystem. The two central types of auctions are first-price and second-price auctions. 

In a first-price auction, the process is simple: the highest bidder wins the impression for the exact price they bid with. In a second-price auction, the highest bidder still wins, but the price of the bid is decided by the second-highest bid (with a +$0.01 modification). Meaning, if the highest bid was $10 and the second-highest bid was $7, the winner will pay $7.01. 

First price auctions lead to more predictable results. They allow buyers to bid according to the users’ perceived value, in correlation with the campaign’s KPIs (i.e, the probability to install, deposit, etc’). Taking into account the user’s predicted value (for example, LTV or ROAS) and adjusting the bid accordingly, may increase the bid, but improve the bottom line by acquiring users who are more likely to return their investment. 

The key difference between first and second-price auction is having control over the bid. In the first-price auction, media buyers know the exact amount of money they spend on a bid, while in a second price auction, they don’t. 

Second price auctions offer a lower spend on impressions, with the risk of losing some of the bids as a result of the modified bidding price. The complexity and unpredictable nature of the second price auction are currently leading the industry to shift towards first-price auctions. 

“Now, as real-time bidding has become more prevalent and buyers have become increasingly sophisticated, it makes sense for the ecosystem to transition to a first price model” – Casie Attardi Jordan, Mopub

Bid shading is a practice used by programmatic bidders to eliminate the risk of overbidding in the realm of first-price auctions.

Bid shading is an algorithm that predicts the price of bids based on historical data. By allowing you to pay just enough to win the bid, bid shading helps you avoid significant overpaying. 

Having access to the historical record of what amount was spent in the past for the same bid—and taking into consideration app, placement, ad format, historical user data (for Android campaigns), and at what price the previous bids were lost—the algorithm on the DSP side can decide how much to bid on the impression.

Read this article to learn more about the essence of bid shading.

In-app ads offer an engaging user experience by using videos, playable ads, dynamic ads, and more. The three main types of in-app ads are interstitial, native, and banner ads. 

These 3 types of ads differ in many aspects. Interstitial is often referred to as the most engaging type of ad, since it’s both a full-screen ad, and it supports video and playable ads, which are considered to be the most effective ads.

“Due to their size, interstitial ads can be much more visually compelling than other static ad formats. It’s also possible to use these full-screen ads to share engaging content like videos and store locators.” Samuel Harries, Content Manager @ Adjust

These ad types also differ in size and price; 

• Banner ads, being the smallest, are considered to be the least intrusive, due to their size. This makes them less effective, less competitive, and results in them being the cheapest ad format. 

• Native ads are somewhere in the middle (in size, price, and affect), and include text-based elements that allow testing extensive amounts of creatives by changing each element independently, creating hundreds of variations.

• Interstitial ads are the biggest (being full-screen ads). As the most effective type of ad, the competition on interstitial placements results in a price increase, making them the most expensive ad placements. 

Each bid request includes a certain amount of data that helps DSPs estimate the user’s potential and decide how high of a bid to make, if at all. 

There is basic data that exists in almost all bid requests, then there are data enrichment tools that allow DSPs to receive additional information about the device, and, last but not least, there’s behavioral data that helps predict future behaviors and make accurate predictions on a bid request. 

Usually, the more data is available in the request, the more competition for it, leading to higher bids, as DSPs have more data to base their decision on.

Bid request data usually includes the following: 

1. The device data, which includes the UA string, model name, etc. 
2. The user Identifier (IDFA/GAID), unless the user is a LAT user (or iOS14 users who opted out). 
3. Location data, which can be as vague as the IP or a city, or as detailed as a ZIP code or even GPS coordinates.
4. The ad placement, which indicates the app name and the in-app placement of the ad. 
5. The OS Version, which may sound insignificant but can be very telling. There are a lot of conclusions to draw between users who stay up-to-date with the latest OS version and those who haven’t updated in a while (especially when combined with the rest of the data.) 

With the help of data enrichment tools, media buyers can get additional hardware-related details in the bid stream and improve their predictive capabilities. Information such as battery life, PPI (Pixels Per Inch), device memory, and others, can be indicators of the users’ correlation with the advertiser’s app. 

For example, users who install high fidelity 3D games (like action and FPS games) usually have higher PPI devices, leading to the conclusion that users with high PPI devices are more likely to install this type of games. Another example refers to the users’ current battery level – users with low battery are less likely to install any new app since they want to preserve the battery they have left for their regular usage. 

These examples are simplified and do not stand alone. These data enrichments add to the rest of the data when deciding whether or not to bid and if so, what bid to place on any given ad request.

We’ve been working with 51Degrees to enrich our device-related data, and you can read more about it and how it had improved our campaigns in our case study. 

SSPs can add extensions to the ad requests that provide additional data points. Fyber is one of the SSPs that puts a lot of effort into maximizing the enrichment of their requests with an abundance of useful attributes. 

By providing DSPs with data enrichment, adding details such as battery level, available disk space, impression depth, and session duration, Fyber helps DSPs improve their predictions, which, in turn, enables DSPs to bid higher on the likeliest users to convert.

This results in higher bids and more wins, which, in turn, increases the profits for all participating sides –  the publisher, the DSP, the SSP, and the advertiser, who ends up with better user acquisition campaigns. 

“We see great value in enriching the bid stream with unique, SDK-based, data parameters. It helps DSPs bid more effectively by providing real-time access to crucial targeting parameters and puts them on a level playing field with ad networks that have their own SDK.

Building close collaborations between DSPs and SSPs help ensure that everything from targeting to creative delivery via our SDK is optimal, creating a win-win scenario where advertisers enjoy better ROAS and publishers see better ad monetization”

Alon Golan, VP Product @ Fyber

Behavioral data is a key factor when running programmatic user acquisition campaigns. This data hinges on the IDFA\GAID to predict future user behavior, based on past usage patterns. Usage patterns can be anything from the genres and types of apps users use, how long they use them when they use them, and much more. 

These patterns help form predicted behaviors such as the types of apps users would be most interested in, when they’re likelier to install new apps, and even how much time they potentially could be spending in their targeted app. 

Behavioral data, having the potential to be this indicative as to users’ behaviors, plays a central role when it comes to the decision making behind bidding. 

Bid request data (basic, enriched, and predicted combined) can be used in many different ways (i.e, each DSP delivers different campaign results while having access to the same data). The differences usually stem from the way the data is being implemented, as we’ve covered in our Data Activation in Mobile UA entry.