Notice: This blog is no longer updated. You may find a broken link or two

You can follow my new adventures @mikeonwine

RTB Part I Followup

September 19th, 2009

Ok, so in the last post I explained what Real Time Bidding (RTB) was. Greg Yardley wrote a response on his blog which made me realize that I didn’t spend quite enough time on the technical implications of RTB. He wrote:

[...] If you’re using real-time bidding, and you’re buying one impression out of a hundred, it’s got to pay the cost of the ninety-nine other decisions not to buy. [...] I think you’ve got to have as close to real-time reporting as possible. [...] Finally, your models have got to account for the data that can’t arrive in real-time, or you’re going to put your efficiency gains at risk. [...]

Add all of the above up, and you may be wishing you stuck with your predefined rule sets.

So I guess I should clarify — building a real time bidder is technically almost exactly as complex as building a performance aware ad-server — it needs all the same pieces:
* Decisioning algorithms
* Targeting & frequency tracking
* Server-side cookie store
* Log Collection & Aggregation Pipelines
* Reporting & Analytics
* Budgeting & Campaign Pacing
* A Trafficking interface

This is certainly not an undertaking to take lightly. Many developer years go into building a scalable serving platform — so yes, hiring the talent and building out the infrastructure to build a scalable bidder is certainly an expensive proposition. But also, note that if you already have an adserver, it likely has a lot of the features listed above.

Put it another way — Real Time Bidding allows you to plugin your intelligence into a massive pool of inventory. If you don’t have any intelligence yet, obviously that will be a significant investment! I’ll talk more about building “bidders” in future posts.

Now to continue the intro on RTB.

A little aside from the personal blogging — I’m extremely excited to announce that Michael has joined the AppNexus executive team! Press release below:

AppNexus Names Google/DoubleClick Ad Exchange Executive as President

Company Prepares for Growth in Emerging Fields of Cloud Computing and Real-Time Advertising

NEW YORK, NY – September 9, 2009 – AppNexus, Inc., a cloud computing and real-time online advertising platform company, today announced that Michael Rubenstein has been named the company’s President, reporting to CEO and co-founder Brian O’Kelley.

Mr. Rubenstein is a 10-year veteran of Google/DoubleClick, where he has served in a variety of business leadership and executive management roles. Mr. Rubenstein most recently served as Google’s Director of Ad Exchange. Prior to Google’s acquisition of DoubleClick, Mr. Rubenstein founded and served as Vice President & General Manager of DoubleClick Ad Exchange, reporting to the company’s CEO David Rosenblatt.

“We are delighted to welcome someone of Michael’s extensive online experience, vision, and record of accomplishment to the AppNexus team,” said Brian O’Kelley, CEO of AppNexus. “AppNexus’s business is at the intersection of the most exciting emerging segments of the internet, including cloud computing and real-time online advertising, and Michael’s experience successfully commercializing new offerings will be an invaluable asset to the company as we continue our growth . This appointment is an important step in the company’s ongoing expansion and underscores our commitment to adding top industry talent.”

About AppNexus, Inc.
AppNexus is a cloud computing and real-time online advertising platform company based in New York City. AppNexus’s customers and partners include the largest buyers and sellers of online advertising. AppNexus’s proprietary technology platforms and cloud infrastructure are powering the development of the real-time advertising ecosystem. The company was founded in 2007 by Brian O’Kelley and Mike Nolet, and is backed by investors including Venrock, Kodiak Venture Partners, and First Round Capital. More information can be obtained by visiting AppNexus online at

Checking my news this morning I stumbled upon This Silicon Alley Insider post. The post has a simple AJAX application inside of it which lets people page through the “Top 10 iPhone Apps for Students”:

What’s interesting about this application is that every time you page left or right it refreshes both the 728×90 ad unit at the top and the 300×250 on the right — with no timer. Try it… in the span of 2 seconds I managed to get 20 ad views on this page — almost all for American Express and IBM. Complex AJAX applications pose an interesting challenge for publishers — think a live flash based stock ticker or Pandora — if someone is staring at a web page all day but doesn’t actually navigate away, it certainly doesn’t make sense to only show them a single ad. This on the other-hand seems to be taking that to another extreme. I mean, come on, most blogs will simply post a list of 10 applications and not a silly widget which appears to only be there to generate ad-views. Here’s a little snapshot from my HTTP sniffer:

Now the IAB recently published guidelines to specifically address this issue in their IAB Rich Internet Application Guidelines. I thought I’d go check these out, find a quote that specifically addressed SIA from showing 20 ads within just a few seconds. Guess what… technically SIA is following the rules:

User activity considered significant enough to trigger ad-counting is as follows:

Mouse Button Usage
Keyboard Activity, Typing (except when used to navigate away from the page alt-tab, etc).

This counting method closely resembles the current IAB Ad-Impression counting guideline because of the clear linkage of certain pre-identified user-initiated events with ad counting.

This highlights a typical problem with IAB guidelines. There are so many parties voicing opinions in the working groups that they are made to be so broad that following them doesn’t really mean anything.

Having my eye on dynamic applications today I noticed that Facebook has implemented ad refreshes while browsing photo pages. This makes a lot of sense to me, users can spend a significant amount of time browsing photos and it certainly makes sense to refresh the ad-content after a certain amount of time. It looks like they’ve set a 60 second timer, and only refresh ads if a user actually clicks through to a new photo after that timer has expired — much better!

RTB Part I: What is it?

August 30th, 2009

If you’ve been following popular blogs & trade magazines you’ve probably heard the phrase “Real Time Bidding” (RTB) pop up here and there. Adexchanger brought it up in this post:

With RTB, exchange participants have a new feature coming for the buy side which should make agency business intelligence mucky-mucks and advertisers delirious after watching the development of yield management tools for the publisher or supply-side.

Darren Herman brought up the topic here saying:

I don’t know how this is a hurdle, but I want to point out that saying “real-time” is the “cool” thing to say right now but there is almost no substance behind it to the trained eye.

Yet, nobody seems to be explaining either what RTB is, who’s doing it or what the implications of it are! This seems like the perfect opportunity for me to pickup blogging again (sorry for the long absence).

A Brief History Lesson

Real Time Bidding is the next evolution in how we deliver ads. First, a little refresher in how the traditional adserving process works. Take an ad-request that involves a publisher, an ad-network and an agency (if any of this is new to you, please read this post first):

The first thing to note is that the entire process is driven by the browser and not by either the publisher, network or agency adserver. Each time one party passes off the ad-request it’s sent off to the next. there is no impression level feedback loop or communication between the three serving systems. This leads to a number of challenges:

  • Long latency in ad-delivery. Lots of redirects, means lots of time for the browser to download content.
  • Lack of integration between systems. The browser naturally drops request and the integration between systems is a manual trafficking exercise. This leads to discrepancies, human error in ad scheduling and and overall pain for operations teams.
  • Pricing Inefficiencies. Perhaps most importantly the fact that these systems aren’t integrated means that it’s hard to buy intelligently. Buyers & algorithms must define a limited number of fixed trading rules which are implemented manually by operations teams. Additionally, the lack of integration between systems means behavioral data doesn’t translate directly and frequency caps are local to each adserver — strong limitations in a space that promises accountability and the opportunity to buy intelligently!

So what is RTB?

Ok, so we all know this world — so what is RTB? Real-Time bidding is exactly that — real time integration between serving systems. Rather than simply passing one impression off to the next system the sell-side adserver asks buyers whether or not they want to show an ad at that given time, and if so, how much they are willing to pay.

It almost looks too simple… doesn’t it? So why go real time? Well, it addresses all the issues shown above. Fewer client side hops results in faster ad-serving. Deep integration means lower discrepancies and a trail of accountability. No longer will can ad-networks claim “it wasn’t me” when a bad ads gets shown as the publisher will know exactly which as is served when. But perhaps most exciting — since the publisher asks each advertiser on every impression what he’s willing to pay he also maximizes revenue as every impression goes to the highest paying buyer.

Seems too simple

Now if you’re new to this industry the obvious question is — why wasn’t like this in the first place? First, you have to remember that the majority of adservers are focused on prioritization and not maximizing revenue or eCPM. These systems don’t function in the RTB world as they assume that delivery is a given and are trying to fulfill allocations & priorities. It’s much harder to estimate the effective CPM of all possible campaign/creative combinations versus trying to make sure that each of 20 campaigns gets it’s allocated share of impressions.

It is also worth mentioning that the idea itself isn’t particularly new. We were talking about this at Right Media over two years ago when I was still working there and Fox Audience Network has been live with a client-side real-time auction since 2007! It is also not until recently that the costs of hardware, bandwidth & CPU cycles have come down enough whereby adservers can cost-effectively decision on ads that they aren’t guaranteed to win.

What about Ad Exchanges?

Now if you read the post “Ad Exchange Model Part I” I referenced above, you may be wondering… Doesn’t Right Media solve all these problems? In theory, yes. Right Media was the first auction-based system which synchronized adserving across all parties who adopted the platform. Networks, Publishers and Advertisers who adopted either NMX, PMX or AMX respectively were integrated on a per-impression basis and didn’t suffer the problems listed above. There is one big issue with the traditional Right Media Exchange model — it requires everybody to adopt the same technology platform.

As soon as Yahoo adopted the RM platform every smart startup & technology player started calling wanting to integrate their secret sauce into the exchange. Therein lay the challenge — all these buying systems had to dumb down their algorithms into a limited number of buying rules (line items) to actually integrate. This is of course why Right Media is starting to talk publicly about RTB recently.

Now some of you may have read this post on the Right Media Blog:

If all of this sounds awfully similar to what Right Media already does on behalf of our demand and supply customers on every ad request, you’re correct: We’ve been doing real-time bidding for years. We were the first to offer it, we became the largest provider, and we are still the largest supply pool of real-time, bidded, non-guaranteed inventory.

I think the above statement has the potential to do a lot of hurt in people’s understanding of real time bidding so I’d like to throw out a little clarification: Right Media pioneered impression level auctions years ago, choosing the highest paying campaign based on either a pre-registered fixed CPM bid on a line item or a run-time predicted eCPM using the internal optimization system, but has not yet been accepting real-time bids from third parties. That being said — it sounds like they’re working on it, which is exciting news!

Ok, that’s enough for now. In Part II I’ll talk more about who’s doing it (or who isn’t?) and what does this all mean for industry participants.

August 30th, 2009

I’m massively late in writing about this, but better late than never!

Google has updated their special search site setup to help fight malvertising:

In addition to a search engine to help people do background checks on prospective buyers, the updated site contains a slew of tips for that EVERYBODY should ready through. Kudos to the Google team for spearheading the effort to fight malvertising!

Two Upcoming Conferences

May 10th, 2009

Seems May is malware month! There are two events coming up — The Anti Spyware Coalition on May 19th and the The Admonsters AdOps 360 in New York on May 21st. I’ll be speaking at AdOps and on a panel at ASC — would love to get together if any of you are going to be attending. Shoot me a note at if you’re interested in meeting up.

One of the things that boggles my mind is how massively fragmented and confusing the display world still is. It’s been over three years since the first ad-exchange launched yet the world hasn’t significantly changed. What makes matters more confusing is that there is no consistent terminology to describe what a company does. It seems everybody describes themselves as either a platform, marketplace or exchange — so what’s the difference?

A company can call itself a publisher, an agency, a network, a broker, a marketplace, an exchange, an optimizer — what does it all mean? What’s the difference between Right Media and Contextweb? Admeld and Rubicon? That’s really the problem — today’s commonly used labels are useless.

Instead of evaluating a company based on labels, evaluate it based on the services it provides, technology it has, the partners it works with, the revenue model and the media revenue it facilitates. Note — below I focus entirely on companies that in some shape or form touch an *impression* — either as a technology provider, buyer or seller. There are peripheral companies that provide a whole world of supporting services, but I’m leaving those out for now to avoid confusion.


Each company provides certain core services to partners, customers and vendors. These primarily center around the relationship the company has with the media that flows through it.

Service Description Example Implication
Selling of Owned & Operated Media The company represents and sells media inventory that it owns. Yahoo selling inventory on Yahoo Mail.
New York Times selling it’s inventory
Company’s sole objective is to maximize CPMs and revenue.
Arbitrage of Off-Network Media The company resells media inventory that it acquires from other services. Yahoo selling users on the newspaper consortium.
Rubicon selling inventory from it’s network of publishers.
Company takes arbitrage of the inventory which means that it’s incentivized to buy low and sell high to maximize it’s own revenue rather than that of the inventory owner or the advertiser.
Inventory or Advertiser Representation Services The company helps inventory owners sell inventory at a fixed margin. AdMeld serving as a direct rep for publishers remant
X+1 managing all campaigns for a specific advertiser or agency
Company is incentivized to maximize revenue for the inventory owner or ROI for the advertiser.
Data Aggregation Company aggregates user data and resells it BlueKai’s data exchange
Exelate’s data marketplace
Company hates Safari and IE8


There are certain core technologies that define what a company does. Note that you will find technologies such as dynamic creative optimization, behavioral classification and contextualization missing from the below list as they are differentiators — they don’t define what a company does but provide a competitive advantage over the competition.

Technology Description Example Implication
Internally available adserver Company has a proprietary in-house adserving system. Specific Media has it’s own proprietary adserving technology that it uses to manage it’s network.

Company sees technology as a competitive asset against competitors.
Externally available adserver An adserver that the company licenses (either free or paid) to third party companies to manage their own online media. OpenX providing their hosted adserver to publishers
Invite Media’s cross-exchange Bid Manager platform
Google’s Ad Manager
Multiple companies using the same platform provides both aggregation and consolidation opportunities. Technology in this case helps build an open platform (since everyone has access).
Internal Trading Inventory run through the externally available adserver can be bought and sold internally Google’s AdEx allows multiple participants to use the externally available adserver to buy and sell media.
Right Media’s NMX customers can buy and sell media to each-other directly.
There is a network effect related to the size of the platform. The more participants the more value there is for everybody involved.
Buying APIs Company provides an API, either real-time or non, through which buyers can upload creatives and manage campaigns. Right Media allows it’s customers to traffic line items and creatives using it’s APIs. Company is empowering buyers to be smarter by enabling deeper integration across platforms. The stronger the APIs, the more the buyers can spend.
Selling API Company provides a real-time API through which sellers can ask in real-time how much company is willing to pay for an impression. Right Media and respond in real-time to a ‘get-price’ request from Fox Interactive Media’s auction technology Company can value inventory in real-time.

Size Matters

Last but not least, the size and the partnerships of a company matters. I’ve written before about the perils of building technology in a void. You can have the most amazing platform that provides great services, but if you’re only running a few thousand dollars a month it’s all moot in the grand scheme of things.

Size can be measured either in impressions or revenue, the latter being far more telling. Getting a billion impressions of traffic a day isn’t hard these days — between Facebook and Myspace alone you probably have close to fifteen billion impressions of traffic running daily.

There’s a huge difference between a partnership and a media relationship. If you’re willing to foot the minimum monthly bill, anybody can buy Yahoo’s inventory through the Right Media platform. That doesn’t say much about who you are as a company. A partnership is different — it might be deep API integrations tying two platforms together or co-selling and marketing a joint solution.

What does it all mean?

Phew… that was a long list, so what does it all mean? Well, the above provides a slightly less fuzzy framework than the classical “ad-network”, “marketplace” or “exchange” commonly used labels to describe a company. Let’s look at a few examples:

Rubicon Project provides publisher representation services through it’s network optimization platform, arbitrages inventory through it’s internal sales team has both an internal and has an externally available adserver (one for the sales team and one for publishers) and is rumored to be working on real time buying APIs. That’s a hell of a lot more descriptive than “publisher aggregator” or “network optimizer”. The one thing I always find confusing about rubicon is that it their incentives seem to be fundamentally misaligned. How can you both arbitrage inventory and serve as a publisher representative? Updated (5/3/09 @ 8pm EST) — I seem to be misinformed. Per comments, Rubicon does not sell inventory directly to agencies.

Compare this to AdMeld which provides publisher representation services through it’s network optimization platform — an externally available adserver — and provides buying APIs (currently via passback). So what’s the difference with Rubicon? Well, one has an internal ad-network and the other doesn’t — different incentives. Publishers are starting to treat Rubicon as another ad-network in the daisy chain whereas AdMeld sells all remnant inventory as a trusted partner.

ContextWeb has an internal adserver (with a self-service interface… I don’t count that as external), they arbitrage inventory, and provide buying APIs. Compare this to Right Media which has an externally available adserver, buying and selling APIs, internal trading, data aggregation and arbitrages media (through BlueLithium/Yahoo Network). Both are “exchanges”, but clearly there is a pretty big difference between the two!

Of course if you get to Google your mind starts to explode just a little bit — as they do everything. Seriously. They buy & sell, have multiple adservers, provide buying APIs, internal trading, data aggregation…

Final Thoughts

I hope this post has given you some ways to start thinking about companies in the online ad space. I’d love to hear your feedback in the comments — what core services & technologies am I missing?

Now — next time someone says — “I’m an exchange”, why not ask — “Ok, that’s great, but what do you really do.”

Just browsing around the web today I noticed that the amount of quality ads seems to have disappeared overnight as we rolled into Q2 of 2009. I first noticed it on the New York Times — a house ad popped up on my second page view and the technology page was showing ads for Vonage — a traditional CPA/remant buyer.

So off I went to Yahoo — which has two serving systems, one for Class-I (premium/guaranteed) and the Right Media Exchange for Class-II (remnant) making it particularly easy to figure out which placements are sold premium or remnant. Of the various sites (news, mail, finance, movies, weather) only *one* showed me a Class-I advertisement, which implies that not too many guaranteed deals are flowing through sunnyvale (PS, RM folks, I’m getting 504 errors on your tags, see screenshot here). is showing Netflix on the first page view of the homepage, as far as i know they only buy on a CPA. Second page view went to “” — doubtful that’s guaranteed. is showing ads for IE8 — presumably an internal house-ad campaign.

This doesn’t look good — Q2 is going to be painful across the board… or maybe it’s all one big April Fools joke?

Watch this video:

How does it work? Pretty easy –> just traffic an ad with some JS that keeps writing out IFRAMES with ad tags. User never sees an ad and as long as the page is opening you are generating what appear to be valid ad requests from valid users!

Hopefully Right Media’s fraud filters are catching this!

If you haven’t already, you must read this post by Fred Wilson which summarizes a recent Comscore whitepaper Whiter The Click?.

I’m not going to re-summarize the paper as Fred’s post already does that. The findings are clear — display has a significant impact on consumers which is often not shown by clicks alone. Check out the graph:

This means that if you aren’t tracking (and billing!) on this behavior on performance based campaigns you are leaving some serious money on the table!

Question of the day — who’s got a good technology to track this?