In your second diagram you show the interaction between the publisher adserver and multiple networks. Does this potentially multiple source back and forth not slow down the adserving in the same way a series of dumb redirects would? Especially when you consider that presumably if Network 1 came back with the best price out of 3 or four networks, once the publisher ad server knew that it would need to go back to it and request the actual ad again. It would be interesting to see some realistic HTTP traces for this stuff.

This is indeed a great question. Technically it looks like there are the same # of requests going back and forth in RTB versus a traditional ad-call. Although this is the case, RTB is going to be significantly faster… and here’s why.

Technically a browser downloading content from an adserver is a five step process:
* DNS lookup of the adserver domain name
* Establishment of a TCP connection
* Requesting content
* Acknowledge of request & sending back content
* Terminating the TCP connection

Assume for this case that a DNS lookup takes about 100ms. Each of these steps requires a number of packets to go from the local computer up to the adserver and a series of response packets. Here’s the # required for each step:

* TCP Connection: Two packets up, and one packet down (SYN, SYN-ACK, AKC)
* Requesting content: One packet up (minimum)
* Request acknowledgement and content: One packet down (minimum) & one packet up
* Terminating the connection: One packet

So the minimum number of packets sent back and forth is 7. If the latency from an end-user is 50ms to the adserver, this means it will take *at least* 450ms (100ms DNS + 350ms ad-request) to request the ad.

Now you’d think this would be the same for real-time, but it’s not! There are three reasons a request between two serving systems is much faster:
* Better connectivity — Adservers are hosted in datacenter that generally have much better internet connectivity than the average end-user. This means lower latency between the two adserving systems.
* No DNS lookup — The RTB system can cache DNS lookups for all RTB partners, effectively removing this 100ms.
* Persistent TCP connections — Any intelligent RTB integration would use persistent TCP sessions between the sell and buy side systems. This means a connection is established once and reused thousands of times after that.

With the above three, here’s how requesting a “bid” looks from sell to buy side:
* Requesting content: One packet
* Acknowledge of request & sending back content: One packet

So assume 25ms latency between systems (rather than 50) and the minimum time for an RTB request between systems is only 50ms compared to the 450ms it would take for an actual end-user or 9 times faster. The slower the end users connection and the faster RTB will be.

Conclusion — yes, adserving individual requests becomes a little bit slower but the removal of redirects makes the overall process signficantly faster.

For those technically curious, here’s are tcpdumps that prove this.

Browser to adserver:

15:45:04.380042 IP 10.0.1.31.59541 > 8.12.226.77.http: Flags [S], seq 50484529, win 65535, [...]
15:45:04.397395 IP 8.12.226.77.http > 10.0.1.31.59541: Flags [S.], seq 661028066, ack 50484530 [...]
15:45:04.397529 IP 10.0.1.31.59541 > 8.12.226.77.http: Flags [.], ack 1, win 65535, length 0
15:45:04.397831 IP 10.0.1.31.59541 > 8.12.226.77.http: Flags [P.], seq 1:1288, ack 1, win 65535, length 1287
15:45:04.424466 IP 8.12.226.77.http > 10.0.1.31.59541: Flags [.], seq 1:1461, ack 1288, win 62780, length 1460
15:45:04.424472 IP 8.12.226.77.http > 10.0.1.31.59541: Flags [P.], seq 1461:1543, ack 1288, win 62780, length 82
15:45:04.424546 IP 10.0.1.31.59541 > 8.12.226.77.http: Flags [.], ack 1543, win 65535, length 0

Adserver to adserver with persistent connections:

20:00:10.709152 IP 64.208.137.8.41096 > 8.12.226.77.80: . ack 1023 win 7154
20:00:10.754844 IP 8.12.226.77.80 > 64.208.137.8.41096: P 1023:2045(1022) ack 501 win 62780

Kudos to Microsoft for taking action! The wild-wild west of display advertising is slowly growing up.

One of the platform’s key features is the ability for ad networks and agency buyers to bid on inventory in real-time, letting them zero in on impression attributes such as geographic location or the presence of advertiser cookies before placing a bid. Yahoo’s Right Media ad exchange does not currently offer bidding in real-time, though it is available through some smaller ad marketplaces.

That’s right folks — Google’s real time exchange is coming. In this post we’ll talk about who is jumping on the RTB band-wagon on the supply side, and some implications this is going to have on the industry.

Ok Who’s In

Ok, so Google is doing it? Who else? Over the past few months pretty much any aggregator of supply has launched, announced or started work on some sort of RTB capability. All major exchanges — Yahoo’s Right Media, Microsoft’s AdECN and Google’s AdEx have RTB integrations in the works. Of the pub aggregators, AdMeld & PubMatic are live and Rubicon is actively working on a solution. As mentioned, FAN has been live with Myspace inventory for a while and there are a number of other parties, such as ContextWeb, AdBrite and OpenX, entering the space. The short summary is, over the next 12 months we can expect billions of daily impressions hitting hundreds of millions of unique users to become available RTB.

Death of the Traditional Ad Network

This is going to have huge implications for the display advertising space — primarily, the traditional ad-network model is on it’s last legs. Most traditional ad-networks today thrive because they have large business development teams that have developed deep relationships with supply. Ad.com, Specific Media & ValueClick all have large publisher bases that they rep to agencies. This posed a large difficult hurdle for new networks to overcome and effectively created a catch-22 for any new network entering the space. To get media dollars a network needs reach, but to get publisher deals a network needs media dollars.

This all changes when there are billions of biddable impressions out there. In this new world, any new network has instant access to the reach that historically would take years to build up. Now anybody can walk into an agency and claim to have a reach of over 100 million unique users.

Now of course this isn’t totally new. Right Media opening up Yahoo inventory to the world back in 2007 started this process and a number of companies have managed to start very succesful network (or “exchange desk”) businesses on this platform. AdECN, AdEx, Admeld, PubMatic and Rubicon take this to a new level as this opens up MSN, the DFP publisher base and the majority of the Comscore 1000 list!

Can Technology Finally Win?

I’ve written in the past about the plight of the ad-technology startup. The short summary is this — technology is great, but the lions share of revenue today comes from media not tech.

As access to inventory becomes commodity marketers and brands will inevitably start focusing on results over the ability to simply spend the budget. With everyone on an even playing field it’ll be easy for a marketer to compare the results from one buying network to the next — which means technology will finally matter.

There are already a number of successful technology focused startups who focus on exchange buying — and a couple that are simply building cross-exchange buying tools. Expect this to become the next hot space for startups in the advertising world.

Behavior behavior behavior!

The traditional problem with behavioral buying, whether remarketing or using third party data provided by companies like IXI, Exelate or Blue Kai, has always been reach. We all know that remarketing works wonders and has amazing ROI, but unless you can actually find your users on the web it’s hard to spend a significant amount of money this way.

With billions of impressions that of course changes — the probability of finding a user across the many RTB platforms becomes easier and easier and hence the actual required reach of any given behavioral segment becomes smaller and smaller. This in itself is going to make data-focused businesses more feasible and also open up a world of possibilities of highly targeted and focused media-campaigns and very granular behaviors.

Next Up

Ok, enough RTB for the day. Next up –> demand demand demand! Who are the new players that are taking advantage of this new RTB revolution and innovating both from a business model & technology perspective.

[...] 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.

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 www.appnexus.com.

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!

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.

Google has updated their special search site setup to help fight malvertising: anti-malvertising.com.

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!

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.

Services

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.

Technologies

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.

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.”