Must Read BMO Capital Markets: Amazon's 2017 Ad Revenue Could Top $3.5B P&G Wants to Cut $1 Billion In Media Spend And Supply Chain Inefficiencies ComScore Eliminates Fees For Viewability Reporting And Nonhuman Traffic Detection Google To Support Addressable And Linear TV Ad Buys On DBM Header Bidding Unleashed A Huge Infrastructure Problem And Ad Tech Will Either Sink Or Swim The Ad Tech Rumor Mill Churns News Of A Chrome Ad-Block Addition After Moat Deal, New York City Ad Tech Pats Itself On The Back AdRoll Exceeds $300M Revenue Run Rate, Names Adap.TV Vet Toby Gabriner President After Moat, Does Nielsen Need To Buy Integral Ad Science? » Your DSP Has RTB by AdExchanger // Tuesday, February 9th, 2010 – 5:06 pm Share: "Data Driven Thinking" is written by members of the media community and containing fresh ideas on the digital revolution in media. Today's column is written by Zach Coelius, CEO of Triggit, an online advertising technology company. Last week the folks at Admeld threw a tremendous event on the topic of Real-Time Bidding (RTB) at the Time Warner Center in NYC. There were hundreds of people in attendance talking about RTB, DSPs and our emerging space. One of the conversation topics that emerged was how to define the various terms, and in particular: What is a Demand-Side Platform? As someone who has been in the space since the very beginning, before we were even called DSPs, it was exhilirating to see enthusiasm from so many in defining what it is we do. So, what is the proper definition for a DSP? As a technologist, my predilection is to focus on the technology innovations making this whole space possible, the most important being the advent of RTB. RTB has enabled a single platform to connect to multiple disparate inventory sources and make real-time buying decisions on each impression-by-impression. Buying decisions are thus powerfully transferred from the inventory vendor directly to the actual media buyer. In the past, if this media buyer wanted to buy media, they would work with a provider like Right Media, ValueClick, Google or one of the tens of thousands of publishers and ad networks out there. Ad buys were achieved by either inputting rules-based buying instructions on various fragmented interfaces, working with an account rep, or using an API to communicate with an ad server. Once these buying instructions were defined, a provider would serve an ad, and make a buy, when an impression occurred on that particular network or site fit within the defined criteria. Buyers could then login to run reports, optimize campaigns or make minor tweaks and changes. Media buyers (and their clients) who needed mass impression inventory would have to perform this task over dozens, if not hundreds, of sources to achieve scale, since in this highly fragmented space no provider has a dominant share of the inventory. A big agency could work with as many as a thousand digital media vendors when you count the publishers, exchanges, ad networks, and intermediaries. Suddenly, buyers were logging into numerous interfaces, pulling and collating disparate reports and are left trusting dozens of black boxes to run their ads in the right places. Very simply, the fragmentation in the display space made digital media buying a nightmare. Moreover, the vendor was in control of where the ads ran, which inhibited transparency and targeting for the buyer. RTB changes all this. Instead of each individual media buyer having to learn and rely on a incongruous collection of their vendors’ ad software, they can instead use a single DSP to manage buying all in one place. This single platform aggregates multiple inventory sources, making it possible to target very narrowly defined audience segments at scale using a single standard without fear of overlap. Buyers can now use data they have collected and developed about their customers‘ target users and communicate with those users directly as individuals. The modes of buying shift from targeting inventory sources to targeting individual users, and in turn, audiences. This leads me to my definition: At its core, a DSP is software for transparent automated media buying across multiple sources using unified targeting, data, optimization and reporting. A DSP needs to be able to connect to many different inventory sources to create a huge pool of inventory of tens of billions of impressions a day. Most likely this involves using RTB or some other solution where the DSP can see the impression without the requirement to buy it. The platform should make the final decision in real-time about which impressions to bid for and what price to bid for each. Platforms that buy media by sending instructions into another ad server in a non real-time manner are just an interface with very limited control and targeting powers. The DSP must be able to provide global frequency capping across all the inventory sources. Anyone who can’t provide this is most likely just sending instructions into another system and doesn’t actually control where the ads are being run. The DSP should provide unified optimization, analytics, reporting and impression attribution. This is one of the most valuable pieces to a good DSP. The DSP should enable its users to leverage 1st, 2nd and 3rd party data across the entire pool of impressions. This means that clients should be able to map their user data, work with the DSP’s data and buy third party data. This data should be usable in highly complex multivariate targeting routines. A DSP should be completely transparent in all aspects of the media and data buying process. There should be an interface that enables the buyer to manage all of their campaigns and transparently see costs, data, sites, conversions and impression attribution. The DSP should have cookie mapping and data sharing systems in place to enable integrations with third party data suppliers, agency data, analytics companies and client data. This process should be possible both on and off line. There should be no conflicts that would cause the DSP to do anything not in the best interests of its clients. This includes data, publishers, partners and exchanges. And last but not least, a DSP should calculate the value of each impression in real-time individually relative to the various characteristics of the impression. This process enables efficient and effective media buying. Follow Zach Coelius (@zcoelius), Triggit (@triggit) and AdExchanger.com (@adexchanger) on Twitter. Popular On AdExchanger Right Now: At Oracle’s Marketing Cloud Show, The Data Cloud Takes Center Stage 804 views Netflix’s Use Of Big Data: Lessons For Brand Marketers 744 views Netseer CEO Talks Contextual Ad Targeting Trends, New Viewability Tool 657 views Are Algorithms Ruining Marketing? 645 views P&G Wants to Cut $1 Billion In Media Spend And Supply Chain Inefficiencies 466 views 15 Comments Ajay Sravanapudi February 9, 2010 Nicely summed up. Hard to argue with this list. Reply Zach Coelius February 9, 2010 Thanks Ajay, that means a lot coming from a veteran of our space like you. Reply Earl Weaver February 9, 2010 What you describe is what used to be called a publisher ad server. The only notable difference is the addition of a realtime bid and an optional pass back. But this is just a certain use case of supply handling at high transaction speeds. Banks solved this decades ago. Finally the cost of doing it came down so low that it was profitable to do it on low value ad inventory on the Internet. Sure there are some other minor differences between pub servers and dsps: interface, mostly in reports and contract handling, a slightly different view of spend and better apis and better external data sources. All the other important functions listed in your numbered list have been standard features in Dart For Publishers and Open AdStream almost since version 1 in the late 90s! (Engage, RIP) The real decision all these tools make is: "What is the optimal campaign to serve at a single point in time based a given set of constraints and a set of data points about the user or the context." Everything else is packaging and presentation. e dub Reply Zach Coelius February 9, 2010 Earl, The big difference between a publisher ad server and a DSP is the location of the decision and how data is used in the process. In RTB many parties can all look at an impression with their own data, algorithms and business rules using their own system. That means that as a buyer you can look at billions of impressions and buy the few you like. That syndication process is totally different then anything that came before. In the old system you as a buyer were dependent on the publisher ad server and to achieve scale you would have to work with a collection of such partners and subsequently lose unified frequency capping, reporting and optimization. Reply Earl Weaver February 10, 2010 hi zach! Thanks for the response. Not to sound like a crusty codger but what you describe as a new "syndication process" was called "cherry picking" in the early 2000s. Many companies did this before Blue Lithium were the first to scale it. Only speed and the competition among a number of parties is really new. We're in agreement that the buyer in the old days lost much and scale was the most critical. But it was the agencies own fault. I was in the agency business from the late 90s and know it firsthand. The agencies already had scale. It was just distributed among different accounts on DFA. Had the agencies been using DFP instead of DFA to manage their clients campaigns in a pool and distributed a single (or a very few) tag for ALL their campaigns, they would've had unified frequency capping, optimization, reporting and cookie space. A few small agencies actually did this. So, where the decision is made is actually less important than the type of decision that is made. Not unimportant. Just less important. DFA decides among creatives. DFP decides among campaigns. A few years ago, the importance of this dawned on the Omnicoms, WPPs of the world. They could create a market among their clients for inventory if they managed their inventory more like a publisher did. Once they had a decision system which picks among all available client campaigns, the next logical step is to take ownership of inventory even if its just for a few milliseconds. Voila. They own inventory. They are a publisher. Why do you think that WPP bought 24-7? They looked at Google who have the largest "demand side platform" and have ownership of some of the most valuable inventory on the internet, the Google search results page. One of the many geniuses of Google is the fact that Google's client demand competes for Google's own supply in a mostly closed loop. That's the kind of business that the holding companies want to be in. Not saying that they can do it but thats what they want and a campaign decision system is the most important piece of that. e dub Reply Michael Walrath February 10, 2010 Zach - This is a nice outline of your vision for a platform/service that the market needs. It provides a good sense of how you view the market and the articles from others on the site this week do the same. However, I think all of these articles are making the same mistake. You guys are focusing on a moot argument (What is a "true" DSP?) instead of some of the much more interesting questions facing your segment of the market. This urge to debate over what is and isn't a DSP is part of what happens when a market gets crowded and noisy. Customers want to cut through the clutter and there's a temptation to try to create clarity through segmentation of the market. I've been through this. There was a time not so long ago that everyone and their brother started calling themselves an exchange. Did I agree that all of these offerings (or even most of them) were exchanges? Absolutely not. But to waste the kind of energy it takes to standardize around any one definition - that's a huge cost in time/energy that none of the companies in this space can afford. Not to mention that the outcome of such a debate is worse than the debate itself - which is to say that the best case scenario of arguing over the definition of a DSP is to get everyone to agree to a watered down definition that will leave everyone unsatisfied. This will only lead to more confusion. Next thing you know we'll have 10 more acronyms. With tongue firmly planted in cheek, I offer you: Service Oriented DSP (SODSP) Technology Oriented DSP (TODSP) Network Conflicted DSP (NCDSP) Vapor Ware DSP (VWDSP) If we're not careful, we'll wind up spending countless hours debating these topics when we should be focused on the larger issues. Where is competition coming from? When about commoditization of these offerings? Is that coming? How will the market evolve, and how will that force the players here to evolve? I know a lot of the folks behind this DSP debate personally - there's some real brainpower at work here. How about taking on some of the harder and more interesting issues here? Reply Zach Coelius February 10, 2010 Michael, Thanks for the great comment; I really appreciate it coming from someone with your experience in space. I think you are absolutely correct that defining a "true" DSP is an exercise in futility and I doubt any of us are planning on building to anyone else's definition. But, I do think there is some value in spelling out the value that DSPs as a class can provide to our customers that is very different that what is available from the other players in the market at the moment. By defining our strengths we can show the market how much we have to offer in terms of things like scale, transparency, accountability and performance. As far as I can tell the winners in this market will be the companies that can live up to that standard and provide value to our customers. Zach Reply Zach Coelius February 10, 2010 Earl, The big difference is that in order to do what you are describing your tag has to be on those publishers sites. With RTB I can see and buy billions of impressions a day across 100k+ sites with out having to negotiate to get my tag on a single site. Reply Earl Weaver February 11, 2010 zach- great! anyway.... Vapor Ware DSP (VWDSP). Best term of the year. e dub Reply Add a comment Click here to cancel reply. Name (required) Email (will not be published) (required) Website Comment XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> Notify me of follow-up comments by email. Notify me of new posts by email.