February 26th, 2010
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”…
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?”
- Exchange v. Network Part II: Adoption
- What’s really in my cookie cache?
- Gaining consumer trust for ads
- Exchange v. Network, Part I: What’s the difference?
- The Challenge of Scaling an Adserver