Mike On Ads

Unless you’ve been living under a rock you’ve heard the term ‘DSP’ — “Demand Side Platform” thrown around like no other. The term has hit such a buzz that there is almost no meeting that doesn’t start with — “Wait, are you a DSP? What is a DSP? Is ____ a DSP? Are you working with a DSP? Which DSP should I work with?”.

Let’s start with some history. I’m not quite sure who coined the term originally but it was primarily used to describe cross exchange buying desks & bid management solutions like Invite, Turn & DataXu. We at AppNexus even briefly described ourselves as a DSP — that was of course when the ‘Platform’ was still a part of DSP — more on that in a bit.

Since then, agencies started allocating budgets away from “networks” and towards “DSPs”…

Wait… what?

You got it –agencies, eager to cut into the hefty margin networks take, started to allocate budgets towards DSPs for exchange buying. What’s of course ironic, is that the typical relationship between an agency and a DSP is certainly not a “platform” relationship but a simple media IO. Early versions of the platforms weren’t (and many still aren’t) mature and the only way they could make them work is by having people manually traffic and optimize campaigns on ad exchanges. Although the spirit of the relationship was one of a platform optimizing media across exchanges the reality is that it is primarily a service driven offering… something which practically looks very similar to a network with a slightly more defined box of inventory and in some cases clearer rules & margins.

Networks of course become massively threatened when their IO budgets got cut in favor of DSPs & Exchange Buying. Now if you’re a network, what do you do? You just rebrand yourself as a DSP or launch a new DSP arm of the business! Voila… now you can go right back to the exchange and say — “Oh, we do that too!”. Now every ad-network is suddenly a DSP…. Of course the response from the first set of DSPs has been to quickly try to define DSPs as “not a network”. You can read two examples on AdExchanger here: Zach Coelius @ Triggit, Nat Turner @ Invite.

Now the majors (Google/Yahoo/MSFT) of course see their direct relationships with the agencies being marginalized by this new “DSP” concept. So what do you do… that’s right, you become a DSP!! Yahoo has already announced this strategy and Google has been rumored to buy a DSP — Microsoft can’t be far behind.

There you have it… who is a DSP? Everybody. The problem is that in this whole process the ‘P’ of ‘DSP’ has disappeared — where is the platform– it just seems to be anybody who plays on the Demand Side — technology vendors, ad-networks & brokers, portals and a few hybrid tech/network companies. Platforms draw valuations, therefore everybody is a platform. The thing is that platform implies that people can build technology on top of your technology. Of the umpteen companies calling themselves a ‘DSP’, how many can say that there is technology being built on top of them? How many have open APIs that you can integrate with?

Here is my proposal… let’s retire the term DSP. It’s loaded, and effectively doesn’t mean anything anymore. Instead, let’s talk about Display Engine Marketing (DEM) and ad technology vendors. DEM companies are ones that will take your media $ and optimize it for you across aggregators of Display. This is the media relationship. Adserving & RTB technology vendors are ones that will license a technology — which may or may not be a platform on it’s own — to integrate with supply aggregators and help run a DEM business. Of course going to be DEM companies that build their own and some that license others, that’s expected in this world. Similarly there are going to be technology vendors that have their own in house DEM teams (*cough* dem==ad network *cough*) that will take an IO and run the media on your behalf.

In the end I want to point you back to an old post I wrote: I don’t care who you say you are, what do you DO?. The next time someone says they are a DSP — respond with — “That’s great, but what do you actually do?”

Cookie Matching.

A number of people have asked about how cookie matching works in the RTB world. Everybody today relies on cookies to store information about a user — which ads he’s seen, what sites he’s been to, which behavioral segment he’s in — all the good stuff. Without cookies, we can’t frequency cap, we can’t remarket, we can’t track, basically, advertising becomes pretty useless!

Now the way browsers work, cookies are tied to a domain. Say an ad-exchange has ad tags on a page under ‘ad.exchange.com’. When a browser requests an ad from the exchange, it only passes along the cookie data that’s stored inside that domain name. This means that the exchange has zero insight into whatever data the bidder might have collected under ad.bidder.com.

So why is this a problem? Well, if the exchange is going to do a server-side bid request to the bidder, it’s pretty hard for the bidder to make a decision about what ad to serve if it has no access to either frequency or behavioral data!

An Example. Bidder is running a behavioral campaign for marketer “marketer.com”. Bidder has a pixel on the marketer’s site, it’s internal ID for the pixel is 27. Each time this pixel fires the bidder ads a cookie to it’s domain ‘ad.bidder.com’, ‘segment=27′. The bidder now wants to buy as much inventory as possible for this remarketing segment across exchanges. Bidder has a user-id, ‘ABC’ for this cookie.

Exchange, ‘exchange.com’ wants the bidder to be able to buy as much inventory as possible. Hence the exchange wants the bidder to be able to use all remarketing segments to buy. Problem is (as mentioned above), they’re using separate cookie domains. So what needs to happen is that the exchange and the bidder need to synchronize their domains so that when the bidder receives a real time bid request he can look-up the information associated with that user.

Fundamentally the logic for synchronizing IDs is pretty simple. The exchange drops a pixel on a page somewhere which points to a bidder’s domain and a simple usersync call. When the call hits the bidder, it reads in it’s cookie ID, redirects off to the exchange passing it’s ID in the querystring so that the exchange can read and store it into it’s cookie space.

The above diagram shows this process. First a pixel is dropped that hits the bidder domain. The bidder receives this call and reads in it’s cookie ID of ‘ABC’. Bidder then redirects the user to get a request from the exchange under ad.exchange.com, passing in the id ‘ABC’ in the querystring. The exchange now receives a call, reads in from the cookie that his ID is 123, and can now map that his user 123 maps to bidder’s user ABC.

Now user IDs are synchronized, the exchange and the bidder can talk about a single user in the same manner. Note that in the above example I noted that the exchange is storing the ID for the bidder. Admeld, PubMatic & the like all work like this. Google does it slightly differently and instead requires the bidder to store the mapping on his end — effectively just the reverse of the above process.

Check out the post by Tim Cranton on theMicrosoft Blog about five suits he just filed against a variety of malware purveyors.

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

Please check out my last post on RTB first. Since this last post, a pretty big announcements has hit the wire. Namely, Google has announced Ad Exchange 2.0. Most significantly:

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.

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

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!

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:

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.

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: 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!

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 mike@mikeonads.com if you’re interested in meeting up.

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

CNN.com 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 “EarnMyDegree.com” — doubtful that’s guaranteed.

MSN.com 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?