Your DSP Has RTB
Posted By John Ebbert On February 9, 2010 (5:06 pm) In Data-Driven Thinking

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

巴西提出：
足球应该分为3人、5人、7人、11人×沙滩、室内、草地。
中国提出：
乒乓球应该分为直板、横板、直板双打、直板单打、直板横板混双。
跳水应该分为1m 2m 3m 4m 5m 6m 7m 8m 9m 10m
英国提出：
马术应该分成黑马马术、白马马术、红马马术、褐马马术、皇马马术、斑马马术。
肯尼亚提出：
长跑应该分为10000米、11000米、12000米、13000米。。。
日本提出：
所有男女混合项目应该增加3p、4p、5p、6p、7p。。。群p。。。500p。
泰国提出：
除了男子和女子项目外，所有应该加上人妖组。

唯独韩国在这方面没有要求，他们大声喊到：
菲尔普斯是韩国人

韩国《朝鲜日报》报道，韩国成均馆大学历史学系教授朴芬庆表示，大约在公元前1000年，生活在朝鲜最南端、今天的济州岛附近的古朝鲜人，曾有渔民飘洋过海到达美洲大陆定居。其中很大一部分经过迁徙,定居在今天美国马里兰州的巴尔的摩市,菲尔普斯家是土生土长的马里兰人,身上很有可能带有韩国血统. 在内陆的马里兰州,菲尔普斯对与水上运动的天赋,正是祖先的基因使然.

除了会计、人事、销售、营销等通常都会在并购交易后进行裁员的部门之外，Sun还将裁掉许多从事开源项目的员工，包括直接参与MySQL开发的员工。虽然甲骨文也需要一定数量的这类员工来继续开发MySQL，从而信守它对欧盟委员会所作的承诺，但是部分开发MySQL的员工仍然会被裁掉。

据一位不愿意透露身份的知情人士称：他们向欧盟委员会作出了5年的承诺，但是又裁掉了与MySQL直接相关的员工，因此我怀疑他们无法保证自己的承诺。

从支持工程师到营销，从销售到研发，Sun公司各部门都有参与开源项目的员工。知情人士估计，仅这些参与开源项目的员工数量就在3000人以上。

知情人士称，虽然这并不能给公司带来直接收益，但是许多组织尤其是美国之外的组织都把开源当做一项要求。

甲骨文并不是第一家开源公司，但是它确实也有一些开源的产品，包括InnoDB数据库及其牢不可破的Linux软件。

那么留下些什么呢?

现在Sun公司员工和Java创始人JamesGosling对此也摸不着头脑。JamesGosling以后的身份还不清楚，但是据说甲骨文并不想挽留他。一年一度的Java开发员会议JavaOne的命运也不明朗。尽管有传言称这个会议将被保留下来，但是目前还没有任何迹象能说明这个会议今后会怎样。

正如甲骨文所说的，它非常喜欢Solaris系统，但它也随时准备砍掉OpenSolaris项目。具体细节还不清楚，但甲骨文可能会让Solaris系统的开发回到前首席执行官乔纳森施瓦茨掌权时的闭源状态，而且不会将它用作新技术的试验田。

甲骨文对Java的计划还不太明确，但是大多数相关员工即从事OpenJDK项目的营销和技术人员都已经被裁掉了。

Sun的GlassFish是甲骨文优先考虑的产品，因此GlassFish的整个团队几乎原封不动地保留下来。Sparc处理器也将保留下来，因为甲骨文在几个月前就在华尔街日报上打广告时作出了承诺，如果不出意外的话，甲骨文还将原封不动地保留Sun公司的存储业务。

知情人士称，但是关于Rock将被放弃的传言却是千真万确的。纽约时报在几个月前报道称，Sun已经彻底放弃代码为Rock的新一代处理器开发计划。

Rock是真正被放弃了，但是Sun将继续开发UltraSparc芯片。在上周的财报分析师电话会议上，埃利森表示甲骨文将通过Sparc和x86专注于高端服务器市场，不再理会低端和中端市场。

Gartner的研究副总裁MartinReynolds对此并不感到意外。他说：你去看看Sun的财报就会发现，有许多开支项目并没有获得相应的收益。在并购交易完成之前，通常你都会设法剔除一些东西，因此这是一个好现象，Sun相信一切都会有个结果了。

作为并购交易的一部分，Sun必须在交易结束之前将自己清理干净，甲骨文在这段期间内不会干涉Sun的业务。Reynolds怀疑Sun会把事情搞得一塌糊涂。

他说：Sun现在所做的事情会让甲骨文很难兑现其承诺，这一点非常奇怪。因此我不太相信甲骨文会信守承诺。

但是Reynolds对于Sun的裁员并不感到意外。Sun有许多投资项目并未赚到钱，它的开源项目也没有什么亮点。例如，OpenSolaris虽然备受好评，但是却没有多大财务贡献。Reynolds补充说，如果未来版本的Solaris和Java不再以开源方式发布，他也不会感到奇怪。