Banner Ad: Please Fix Your Pacing Algorithm
Decorative Header Image

Tag Archive for RTB

| August 25, 2011
No comments

Top 10 Things Publishers Need To Know About Real-Time Bidding

I’ve been threatening on twitter to write a book on the things publishers need to know about Real-Time Bidding (RTB). At the Rubicon Project, we like to talk about ‘RTB Done Right’ and how to help publishers understand what’s really going on. With a full-time day job I don’t have quite enough time to bang out chapter after chapter of really fascinating business and technical aspects of RTB, so I thought I’d do a Top 10 list.

I started watching the Late Show with David Letterman to get the format down and then I popped over to a bunch of sites to make sure I wasn’t producing a fluff SEO piece. So based on what myself and our team has learned, here are the Top 10 Things Publishers Need To Know About Real-Time Bidding (link goes to admonsters.com article).

Category: Working On It | Tags: ,
| January 19, 2011
No comments

Using Dynamic Price Floors to Protect Publisher Value

I was reading a recent post on AdExchanger, “Smoking the RTB Weed,” about a Real-time bidding paper Metamarkets was gearing up to present at an industry event and it got me thinking about dynamic price floors (n.b. If you’re not already familiar with RTB, you might want to start with my earlier post on the topic to get up to speed. This post is pretty ‘inside baseball.’)

Disparity of Data

There’s a lot concern in the online ad ecosystem around the disparity of data between publishers and advertisers. These are not new concerns but they are attracting a lot of attention due to the opportunity that Real-Time Bidding (RTB) presents in leveling the playing field.

Historically advertisers have been incentivized to understand the audience behind the publisher in order to maximize their yield. This has led to a large investment in technology to serve the advertiser, tilting the balance of information to their favor and leading to rampant arbitrage.  As a result, most impressions are still sold without adequate protection.

Re-balancing Toward the Publisher

Real-Time Bidding affords the publisher an opportunity to re-balance the terms of the sale of inventory. In fact, in many ways the savvy, well-armed publisher can leverage RTB to gain an advantage in that each impression is evaluated and assigned a value by several buyers.

During an auction only one buyer can purchase the impression, but the data gathered from the other buyers is not discarded, rather it is captured by the publisher (or in our customers’ case, by REVV) and stored for analysis and pricing determination on all future bids.  Read more

Category: Working On It | Tags: , , ,
| October 14, 2010
No comments

RTB Primer

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 diagram

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. Read more

Category: Working On It | Tags: , , , ,
  Recent Entries »