We know that there are two major parties that we need to care about, are Demand and Supply.
“Demand” is a term used for advertisers or media buyers. A Demand Side Platform, or DSP, is where the marketers can programmatically purchase ad inventories.
Whereas, the term “Supply” includes the inventory sellers or publishers (those who create content online). A Supply Side Platform, or SSP, is where they can sell their ad inventory in real-time.
Sometimes, Platforms such as Ad Networks or Ad Exchanges are also used along with DSP and SSP.
So, we have both parties in place. We have platforms that provide the facility to perform an auction, so that both parties can do programmatic business.
There are several ways of doing an auction -
- First-price auctions - Participating advertisers submit their bids for each impression in real-time and whichever has the highest bid wins the auction. Here, the winning advertiser pays the exact amount that they submitted.
- Second-price auctions - Here the auction mechanism is similar to First-Price auction. The highest bidder still wins, but it pays the second-highest bid amount plus a pre-determined amount, usually one cent.
- Fixed CPM/Guaranteed Auctions - In this type of auction, the advertiser and publisher have an agreement that the buyer party should pay a pre-determined price for a particular impression, trumping all the bids.
To understand these in detail, you can refer to this article.
Now, we have two parties, bidding on a platform and doing business nicely. What about the flow or setup through which Demand Partners get a chance to display their ads on the supplier’s website?
There are mostly two models:
1. Header Bidding – Read More
2. Waterfall
This strategy is generally used by publisher to sell their remnant inventory. Firstly, the publisher makes an ad slots in such a way that it catches everyone’s attention. Something like, at the very beginning of the webpage. Those prime slots are usually reserved for ads coming from direct sales. However, in the programmatic world, it may so happen that publishers were not able to sell their best ad slots for its worth price.
To overcome this problem, they follow a strategy where, if one advertiser does not fill the inventory, the publisher’s ad server passes the same impression to another advertiser until it is sold. This creates a sequential chain or ‘daisy chain’ of buyers, thus the name “waterfall.”
There is a downside of this approach – there may be high latency in filling of ad slots, timeouts can happen, and the yield lowers. Most importantly, huge manual effort is needed in setup.
This method is widespread among Ad Networks, as they are connected to many demand parties and they promise the publisher to fill the ad slot. Therefore, they rotate the same ad impression until it is filled.
We can understand this with an example –
Let’s say, a publisher is connected to an Ad Network. And the Ad Network is connected to 4 different DSPs.
When a user comes to publisher’s website, an Ad Request is generated and goes to the publisher’s server. That server calls Ad Network. The Ad Network calls the first DSP in line and waits for a response. If there is no response or timeout, the Ad Call returns to Ad Network and find the second DSP in line.
Similarly, the same Ad Call keeps moving to-and-fro, until some DSP responds.
Secondly, in the worst case, if no DSP fills the Ad Call, a House Ad or PSA set at Ad Network’s end, will be displayed on the publisher’s website.
However, advertisers and publishers cannot just come on a platform and start their business by setting up a waterfall or header bidding. There has to be a set of rules or defined protocols that they both need to comply with.
Here comes, RTB.
Real-Time Bidding is a system that defines a protocol for buyers and sellers. Adhering to which, an auction for ad inventory takes place in real-time. The primarily focuses is on bidding for each impression.
As per the Interactive Advertising Bureau, “Real-time Bidding (RTB) is a way of transacting media that allows an individual ad impression to be put up for bid in real-time.”
Typically, RTB involves server-to-server communication, broadly having these steps –
- Receives of Bid Requests from Supply Sources
- Selects Bidders to participate in the auction
- Collects Bid Response from all Bidders
- Processes and then sends valid Bid Response to exchange
- In case of auction won, gets acknowledgment from exchange
- Sends Ad payload to publisher
- Finally, gets Ad Render/Click information
Do You Know: An ad is auctioned, finalized, and displayed on the publisher’s website within the blink of an eye! (usually within 500 milliseconds)
IAB Tech Lab is continuously evolving and working to make the protocols more efficient. The Interactive Advertising Bureau Tech Lab released the latest version of RTB protocol, i.e., v3.0.
Security is an essential feature of this, as it asks all the parties involved for an imprint in the whole ad call chain. This means better visibility for the buyers; they’ll know the origin of the inventory (as it’ll have a unique imprint of source thus making it legitimate), as well as the type of inventory they are buying. This ultimately helps in removing fraudulent activities like domain masking. Similar to what ads.txt does.
RTB v3.0 also introduced support for issues caused by header bidding, PMP, OTT and Open-Auction.
By issues here, we mean that (for example) specs in the bid requests are of a different type when it comes from PMP, OTT or from an Open-Auction. Additionally, since Header Bidding is a “broadcast” of bid requests to a large number of Partners, processing of which puts a strain on servers!
So, if a publisher opts to run any combination of these, using the same ad exchange. Then the ad exchange needs to work on multiple and different sets of rules. There will be an overlap of the majority of RTB protocol contents.
To overcome this, v3.0 can be used. Its structure is made in such a way that it cuts down redundant or repetitive codes and drastically reduces computational load on servers. As a result, we get faster bidding.
The only downside that can be seen for now is, if a company wants to implement RTB v3.0, then they would need to do manual works and dedicate resources to reform its platform.
All the current AdTech players would need to upgrade themselves by adapting v3.0, only then…
An everyday user would see no delay in seeing an ad;
Publisher will make more money, as they will experience negligible latency and good yield because they’ll have proper transparency about the advertiser serving the ad;
Moreover, advertisers will have a broader reach, because they will be displaying ads to verified users in lesser time.
...................................................................................
Post Written By:
Tenzin Kalsang
Software Engineer
Kritter Software Technology Pvt. Ltd.
