This post was written in the early days of RTB. While the description of the ecosystem it is still relevant, some of the products mentioned may have been renamed.
Real-Time Bidding (RTB) might seem like old hat already, but there are still many misconceptions out there about how it actually works. It seems that there’s not a ton of material out there that explains RTB in a straightforward manner; until now.
The market explains RTB as sales channel where advertisers bid on their desired ad impressions, with the targeted impression going to the highest bidder. RTB ad serving is made possible through APIs shared among networks, exchanges and optimization platforms that dictate detailed transaction conditions.
While RTB’s value to publishers seems enticing as access to more demand sources equates to increased publisher revenue, the risks, however less apparent, are significant. Because RTB gives advertisers their desired audience at the lowest possible price, publishers are at risk of downward pricing pressure – and net negative revenue impact – resulting from the buy-side’s increased efficiency .
It’s for this very reason that the Rubicon Project recently launched the REVV Protected RTB 1.0 beta. I’ll explain how the REVV for publishers ™ 3.2 Yield Optimization platform handles Protected RTB at a high level to paint a clearer, basic picture.
How Bidding Works
A quick note – as you read through the following, bear in mind that the entire process described in the paragraphs below takes place in less than 80 milliseconds. For perspective, it takes about 300-400 milliseconds to blink an eye.
Let’s start with the ad request. This is the same ad request (a request from a publisher to fill a given ad impression) that would come in without Protected RTB engaged. The REVV ad engine checks the rules for that impression to see if it is eligible to receive real-time bids (the system calls that “Protected RTB enabled”) and which Demand Side Platforms (DSPs) should get exposure to it, per the publisher’s permission control settings (we currently work with a number of DSPs including AppNexus, Turn, Triggit, MediaMath, DataXu, Quantcast and Media6Degrees). If the impression is Protected RTB enabled, then the REVV ad engine packages the pertinent information about the impression and anonymized user information (no personally identifiable information) and sends to REVV’s real-time bid system.
The bid system receives the request from the ad engine, unpacks it and creates distinct request packages for each DSP. Each bid request package includes information the DSP needs to make a decision whether to bid, including basic information about the site, the anonymized user information and ad itself parameters like dimensions and acceptable creative types. These request packages are all in a standard format defined for the REVV Protected RTB platform; each DSP has implemented the communication protocol according to REVV’s API specification.
How DSPs Respond to Bids
As mentioned, each DSP receives an individual bid request for the impression. Each DSP has it’s own response to these requests. Most DSPs have some form of business rule working for them to choose an appropriate response. Some of them are running auctions within their system, others are running rotation based ad serving solutions. Some are armed with third-party data or their own audience data and algorithms that work in real-time to decide which campaign to bid with and at what price.
Once their proprietary technology has evaluated the bid request, DSPs generally respond to a given bid request in one of two ways. They return a valid bid with an ad creative and the advertiser name, or they return a bid of 0 or send a non-bid signal, which indicates that they chose not to bid on the impression. If the response from the bid partner takes too long, REVV will ignore it. REVV will not let Protected RTB compromise expedient ad serving. Needless to say, in a process called real-time bidding, time is of the essence.
Ad Quality Protection & Real-Time Bids
With bids in hand, the REVV bid system checks each against the publisher’s advertiser block list with Real-Time Advertiser Blocking. The system not only blocks disallowed advertisers, it also tracks unknown advertisers and reports them to the Rubicon Project’s Ad Operations team for categorization. Sites can be configured to allow or disallow unknown advertisers. The bid system packs all the bids for the impression back into a single package and sends it back to the ad engine.
And At Last, the Real-Time Bidding Auction
After all these steps are complete and all viable bids are received, an auction takes place inside the REVV ad engine. All real-time bids are considered against one other; they are also considered alongside all other ad tags and direct campaigns that are eligible to serve on that publisher’s site. This is a critical feature of REVV Protected RTB – by competing against all other potential ad tags (from ad networks, exchanges, and other demand sources), real-time bidders face upward pricing pressure from the most sources of competition for that impression. Only real-time bids that beat out all of these other sources of demand, real-time or otherwise, will win auctions.
Bids also must beat any relevant price floors that are configured for the site. The auction is “second price” style, which means the winning bidder pays just more than the next highest bidder’s offered prices, or ad tag CPM. Further, CPMs from the REVV yield optimization engine act as bids within the decision process, helping to preserve the fair market value of publisher inventory. The winning RTB ad, ad tag or direct campaign is delivered to the site, and more specifically to the user, in around 80ms from request to delivery. The ad shows up just like any other ad from REVV with one difference. Protected RTB ads have the price encoded on the ad request. This mechanism sends the signal back to the DSP communicating that their ad won the auction and lets them know what the clearing price is.
As a result, REVV Protected RTB 1.0 is allowing publishers to leverage all the benefits of real-time bidding while ensuring their direct sales channels, pricing and site visitors remain safe.
This post is also hosted at the Rubicon Project blog.
[SlideDeck id=’97’ width=’100%’ height=’250px’]
