Banner Ad: Please Fix Your Pacing Algorithm
Decorative Header Image

Tag Archive for online advertising

| January 13, 2012
No comments

What data does a DSP have access to when bidding on an ad exchange?

Ie, what types of information are contained within the cookies made available? Thanks!
This question was asked on Quora.com, below is my answer.

Identity DataIn a typical RTB transaction there’s a user ID, pulled from the user’s cookie or some form of server side system, which is passed to the DSP from the SSP. That ID is, in most cases, the DSPs record locator for the user’s information. Most DSPs have a server side data store where this information is housed, updated and augmented from a variety of sources including data companies like Blue Kai and Excelate and their ilk. DSPs may also be collecting and distilling information based on bid request activity from that user (although most SSPs put language into the contracts governing the use of this “bid stream” data) or retargeting data gathered for their customers. This type of data system is generally referred to as a Data Management Platform (DMP) in the industry. While there are some stand-alone DMPs out there, more and more DSPs are integrating or building their own.

There are a variety of other bits of information about the ad impression that get passed in the bid stream. To get a sense of what might be passed you can look at the Open RTB API (http://code.google.com/p/openrtb/). It is, of course, very technical but there are grids that list out the information being exchanged.

Category: Working On It | Tags: , , , ,
| October 20, 2011
No comments

The Real Problem with Getting More Spend Online

Two weeks ago I participated in a couple of events during AdWeek in New York.  The first was Rubicon’s own #letsfixit event where agency advertising representatives joined a panel with publishers and the rest of the demand train to discuss the difficulties of running ads online.  The attention shifted from learning about the process to learning about where the process fails.

Familiarity

Spend OnlineBernhard Glock of Medialink, who was not on the panel, but chimed in with a profound thought.  Buying on television is buying something that’s familiar, with seemingly known or at least comfortable impact and expectations on results.  By contrast, buying online display is a complete mystery.  His solution, just buy on television because that’s what he understands.

In addition to all the great insight each panelist shared, this sticks out as an important point of the event.  If there’s something to be learned by this it’s that the Kawaja diagrams are illustrating the point – online is confusing to the buyers, and that’s bad.  Read more

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 »