May 17, 2015

The rise of the Chief Data Officer

mad-men-monolithAs the final season of Mad Men came to a close this weekend, one of my favorite memories from Season 7 is the appearance of the IBM 360 mainframe in the Sterling Cooper & Partners offices, much to the chagrin of the creative team (whose lounge was removed to make space for the beast), especially poor old Ginsberg, who became convinced the “monolith” was turning him gay (and took radical steps to address the issue).

My affection for the 360 is partly driven by the fact that I started my career at IBM, closer in time to Man Men Series 7 (set in 1969) than the present day (and now I feel tremendously old having just written that sentence). The other reason I feel an affinity for the Big Blue Box is because my day job consists of thinking of ways to use data to make marketing more effective, and of course that is what the computer at SC&P was for. It was brought in at the urging of the nerdish (and universally unloved) Harry Crane, to enable him to crunch the audience numbers coming from Nielsen’s TV audience measurement service to make TV media buying decisions. This was a major milestone in the evolution of data-driven marketing, because it linked advertising spend to actual advertising delivery, something that we now take for granted.

The whole point of Mad Men introducing the IBM computer into the SC&P offices was to make a point about the changing nature of advertising in the early 1970s – in particular that Don Draper and his “three martini lunch” tribe’s days were numbered. Since then, the rise of the Harry Cranes, and the use of data in marketing and advertising, has been relentless. Today, many agencies have a Chief Data Officer, an individual charged with the task of helping the agency and its clients to get the best out of data.

But what does, or should, a Chief Data Officer (or CDO) do? At an advertising & marketing agency, it involves the following areas:

Enabling clients to maximize the value they get from data. Many agency clients have significant data assets locked up inside their organization, such as sales history, product telemetry, or web data, and need help to join this data together and link it to their marketing efforts, in order to deliver more targeted messaging and drive loyalty and ROI. Additionally, the CDO should advise clients on how they can use their existing data to deliver direct value, for example by licensing it.

Advising clients on how to gather more data, safely. A good CDO offers advice to clients on strategies for collecting more useful data (e.g. through additional telemetry), or working with third-party data and data service providers, while respecting the client’s customers’ privacy needs.

Managing in-house data assets & services. Some agencies maintain their own in-house data assets and services, from proprietary datasets to analytics services. The CDO needs to manage and evolve these services to ensure they meet the needs of clients. In particular, the CDO should nurture leading-edge marketing science techniques, such as predictive modeling, to help clients become even more data-driven in their approach.

Managing data partnerships. Since data is such an important part of a modern agency’s value proposition, most agencies maintain ongoing relationships with key third-party data providers, such as BlueKai or Lotame.The CDO needs to manage these relationships so that they complement the in-house capabilities of the agency, and so the agency (and its clients) don’t end up letting valuable data “walk out of the door”.

Driving standards. As agencies increasingly look to data as a differentiating ingredient across multiple channels, using data and measurement consistently becomes ever more important. The CDO needs to drive consistent standards for campaign measurement and attribution across the agency so that as a client works with different teams, their measurement framework stays the same.

Engaging with the industry & championing privacy. Using data for marketing & advertising is not without controversy, so the DCO needs to be a champion for data privacy and actively engaged with the industry on this and other key topics.

As you can see, that’s plenty for the ambitious CDO to do, and in particular plenty that is not covered by other traditional C-level roles in an ad agency. I think we’ll be seeing plenty more CDOs appointed in the months and years to come. diggDigg RedditReddit StumbleUponStumbleUpon

December 19, 2011

Building the Perfect Display Ad Performance Dashboard, Part II – metrics

Welcome to the second installment in my Building the Perfect Display Ad Performance Dashboard series (Note to self: pick a shorter title for the next series). In the first installment, we looked at an overarching framework for thinking about ad monetization performance, comprised of a set of key measures and dimensions. In this post, we’ll drill into the first of these – the measures that you need to be looking at to understand your business.


How much, for how much?

As we discussed in the previous post, analysis of an online ad business needs to focus on the following:

  • How much inventory was available to sell (the Supply)
  • How much inventory was actually sold (the Volume Sold)
  • How much the inventory was actually sold for (the Rate)

Of these, it’s the last two – the volume sold and the rate at which that volume was sold – where the buck (literally) really stops, since these two combine to deliver that magic substance, Revenue. So in this post we’ll focus on volume sold, rate and revenue as the core building-blocks of your dashboard’s metrics.

Volume, rate and revenue are inextricably linked via a fairly basic mathematical relationship:

Revenue = Rate x Volume

Another way of thinking about this is that these three measures form the vertices of a triangle:


Some business and economics textbooks call Rate and Volume “Price” and “Quantity” (or P and Q), but the terms we’re using here are more common in advertising.

Different parts of an ad business can be driven by different corners of the triangle, depending on the dynamics of how each part is transacted. Here are some examples:

  • Ads sold on a time-based/”sponsorship” basis are best thought of as driving revenue performance, because deals are done on a revenue basis regardless of volume/rate (though the advertiser will have a volume & rate expectation, which they’ll want to be met).
  • For premium ads sold on a CPM basis, deals revolve around Rate; the name of the game is to add value to inventory so that, impression-for-impression, it achieves more revenue.
  • For remnant ads and networks, volume is king (assuming you can maintain a reasonable rate) – you’re looking to maximize the amount of inventory sold, and minimize the amount that has to be given away or sent to “house” advertising.

Because of these different dynamics, measurement of ad monetization can easily fragment into various sub-types of measure; for example, as well as cost-per-thousand (CPM) rate, some ads are purchased on a CPC or CPA basis. So a more complete version of the diagram above looks like this:


However, it’s essential to remember the key relationship and dynamic between rate, volume and revenue, which is manifested in the CPM, Impressions and Delivery Revenue measures in the diagram above. So let’s look at these measures.



In the online ad business, Volume is measured in Ad Impressions. I have talked about ad impressions before on this blog, in this installment of Online Advertising 101 (you may want to take a moment to read the section entitled “What’s the product?” in that post). From a measurement point of view, whenever your ad server serves an ad (or more accurately, fields a request for an ad), its measurement system should log an ad impression. How much data is logged with this impression will vary depending on the ad server you’re using, but will likely include most of the following:

  • Date & time of the impression
  • Advertiser
  • Campaign and/or creative
  • Location/placement (i.e. where the ad was served)
  • Attributes of the individual who requested the ad (e.g. targeting attributes)

We’ll come back to those attributes (and how you can use them to segment your impressions for better analysis) in another post.

Capturing a true view of the ad impressions on your site can be a little more challenging if you are using multiple ad servers or networks to sell your inventory, particularly if you are using a combination of your own first-party ad server (for example, DFP) and redirecting some impressions to a third-party such as an ad network. When you have delivery systems chained together in this way, you may need to combine the impression counts (and other data) from those systems to get a true picture of impression volume, and you will need to be careful to avoid double-counting.

For reasons that will become clearer when we get on to talking about rate, it’s essential that you capture impression counts for your ad sales where you possibly can, even for parts of your site or network where the supply is not sold on an impression basis.

Other volume measures such as Clicks and Conversions become very useful when you’re looking to assess how valuable your inventory is from an advertiser perspective, since both are a proxy for true Advertiser ROI. They’re also useful for deriving effective rate, as we’ll see below.



At the highest level, rate is a simple function of volume and revenue – simply divide your total revenue by your total volume (and usually multiply by 1,000 to get a more usable number) and you have your overall rate – in fact, you have the most commonly used kind of rate that people talk about, known as “Effective Cost-per-Mille (Thousand)”, or eCPM (don’t as me why the e has to be small – ask e.e. cummings). Just to be clear, eCPM is calculated as:

eCPM = (Revenue) * 1000 / (Volume)

Sometimes eCPM is known as eRPM (Where the R stands for “Revenue”).

The reason we’re talking about eCPM before revenue in this post is because many advertising deals are struck on a CPM basis – i.e. the advertiser agrees to buy a certain amount of impressions at a certain pre-agreed rate. However, even for inventory is not being sold on a CPM basis, it’s essential to be able to convert the rate to eCPM. Here’s why.

The beauty about eCPM is it is the lowest common denominator – regardless of how a particular portion of your impression supply was sold (e.g. on a cost-per-click basis, or on a “share of voice” or time-based basis), if you can convert the rate back into effective CPM you can compare the performance of different subsets of your inventory on a like-for like basis. Consider the following example of delivery info for the parts of a fictional autos site:

Site area Sold as… Deal
Home page Share-of-voice $10,000 up-front
Car reviews Reserved CPM $2.50 CPM
Community AdSense $1.20 CPC

With just the information above, it’s impossible to understand whether the Home Page, Reviews or Community site areas are doing better, because they’re all sold on a different basis. But if you add impression counts (and, in the case of the Community area, click counts), it’s possible to derive an overall rate for the site, as well as to see which parts are doing best:

Site area Sold as… Deal Impressions Clicks CPC Revenue eCPM
Home page Sponsorship $10,000 up-front 5,347,592 n/a n/a $10,000 $1.87
Car reviews Reserved CPM $2.50 CPM 3,472,183 n/a n/a $8,680.45 $2.50
Community AdSense $1.20 CPC 1,306,368 5,832 $1.20 $6,998.40 $5.36
Total   10,126,144 $25,678.85 $2.53

See? Who knew that the Community area was throwing off so much money per impression compared to the other areas?

eCPM isn’t the only rate currency you can use, though its connection to both volume and revenue puts it at a distinct advantage, and it means most to publishers because it speaks to the one thing that a publisher can exert (some) control over – the volume of impressions that are available to sell.



If you sell your inventory on a fairly straightforward CPM or CPC basis, then your site’s revenue will pop neatly out of the equation:

(Revenue) = (eCPM) * (Volume) / 1000

However, if you’re running a larger site and engaging in sponsorship-type deals with advertisers, your revenue picture may look a little more complex. This is because “sponsorships” (a term which covers a multitude of sins) can contain multiple revenue components, some of which can be linked to ad delivery (and which therefore lend themselves to rate calculations), and some of which cannot.

For example, the sponsorship deal on our fictitious autos site referenced above could in fact contain the following components on the invoice sent to the advertiser or agency:

Item Cost Impression Target
100% Share-of-voice rotation, 300x250, Home Page (1 day) $6,000 3,000,000
100% Share-of-voice rotation 120x600, Home Page (1 day) $4,000 3,000,000
Sponsor branding – Home Page background (1 day) $8,500 n/a
Sponsored article linked from Home Page (1 day) $3,500 n/a
Sponsor watermark on Home Page featured video (1 day) $1,500 n/a

In the above table, only the first two items are expected to be delivered through the ad server; the other three are likely to be “hard-coded” into the site’s CMS and actually deliver with the page impressions (or video stream, in the case of the last one).

There are a couple of different options for dealing with this second kind of revenue (which we’ll call “non-delivery” revenue) which can’t be directly linked to ad impressions. One is to attribute the revenue to the ad delivery anyway, kind of on the assumption that the ads “drag along” the other revenue. So in the above example, with 5,347,592 impressions delivered across the two units, the “overloaded” eCPM for the ad units would be $4.39.

The challenge with this approach is that the extra revenue is not associated with delivery of any particular ad. So in the above example, if you wanted to calculate the eCPM for just the 120x600 unit on the home page (perhaps across an entire month), would you include the non-delivery revenue? If yes, then how much of it? 50%? 40%? The lack of ability to truly associate the revenue with ad delivery makes these kinds of calls incredibly hard, and open to dispute (which is the last thing you want if you are presenting your numbers to the CEO).

The other approach is to treat the “non-delivery” revenue as a separate bucket of revenue that can’t be used in rate calculations. This keeps the data picture simpler and more consistent on the “delivery” side of the house, but you do end up with an awkward block of revenue that people are constantly poking and saying things like “I sure wish we could break that non-delivered revenue out a bit more”.


A complicated relationship

Once you have your arms around these three core measures, you can start to see how they interact, and there lies the magic and intricacy of the dynamics of selling display advertising. The implacable logic of the simple mathematical relationship between the three measures means that if one changes, then at least on of the others must also change. Only by looking at all three can you truly understand what is going on. We’ll dig into these relationships more in subsequent posts, but here’s a simple example of the rate achieved for ads sold on a fictional news site home page:


Someone looking at this chart may well ask “OMG! What happened to our rate in June 2009?” Well, a quick search on Wikipedia will reveal that a certain “King of Pop” died in that month, sending the traffic (and hence the ad impression volume) of most news sites sky-rocketing. In our fictional home-page example, almost all revenue is driven by “share of voice” (time-based) deals, so all that extra volume does is depress the effective rate, because the site earns the same amount per day regardless of traffic levels. So here’s volume and revenue from the same data set, to round out the picture:


We can now see that in fact, June wasn’t a bad month for Revenue; it was the huge spike in traffic that did the rate in.

The above example takes something very important for granted – namely, that we have enough segmentation (or “dimensional”) data associated with our measures to be able to break down site performance into more useful chunks (in this case, just the performance of the home page). In the next blog post, we’ll look at some of the most important of these dimensions. Stay tuned! diggDigg RedditReddit StumbleUponStumbleUpon

January 14, 2009

PubMatic kicks us when we’re down (but gently)

image As if we weren’t all feeling gloomy enough already, PubMatic has just released its Q4 2008 Ad Price Index report, which makes for sobering reading. For those of you not familiar with PubMatic, they provide “multi-network optimization” for publishers who are looking to maximize the yield on their remnant ad inventory (i.e. the inventory the publisher can’t sell themselves).

Rather than manually dealing with a handful of networks directly, the publisher hands their inventory over to PubMatic who ensures that the most profitable ad is shown, whether it comes from Google Adsense, BlueLithium, AdBrite, or another network. Since a key part of what PubMatic does is measure the CPMs for online ads, they have access to lots of ad price data, and every quarter they roll this data up into a report (available here as a PDF).

PubMatic has been doing this for 15 months now, and so far, they’ve yet to deliver any good news:


Given the economic Armageddon that overtook the world, PubMatic’s report that average prices only softened by $0.01 during Q4 actually seems like pretty good news. But then again, Q4 was the holiday season; and compared to Q4 2007, Q4 2008’s numbers look pretty horrendous.

The detail of the report contains some more interesting tidbits: for example, the average CPMs for small sites (fewer than 1 million PV/mo) are the highest, at around $0.60, whilst the average CPMs for large sites languish at around the $0.17 mark.

Before you start predicting the doom of the mainstream media, however, it should be pointed out (as Mike Nolet has done) that there is a sample bias in the PubMatic numbers – whereas a small publisher is wholly dependent on ad networks for all their revenue (lacking the resources to sell their inventory themselves), and so is likely sending all its inventory (including the juiciest stuff on the home page) to PubMatic, a large site will only be sending the inventory that they couldn’t sell themselves – i.e. the bottom-of-the-barrel stuff.

It also turns out that average prices for the largest and smallest publishers have slumped by around 50% in the past year, whilst prices for medium-sized sites have remained more solid:


I’m at something of a loss to explain why this might be – at the high end, it may be because large sites are becoming more efficient at selling their inventory themselves, so it’s only the really cheap stuff that is being passed on to PubMatic; whilst at the bottom end, small publishers are becoming increasingly crowded out by new sites.

What would be immensely useful would be for PubMatic to provide some kind of indication of the proportion of inventory from sites that is being served through them; this would make it easier to understand if changes in average prices through PubMatic are the result of a change in the mix of inventory that is being passed to the company. However, I would be very surprised if PubMatic had access to this kind of data.

One more thing…

image Once you’re done reading the Ad Price Report, stick around on the PubMatic site a little longer and download their White Paper entitled “Death to the Ad Network Daisy Chain”. This little document does a nice job of explaining how an impression is passed from one ad network to another, and highlights the surprisingly high proportion of ad calls that are returned ‘unsold’ by networks. The document then goes on to talk about how ad operations folk have to manually set up ‘daisy chains’ of ad networks to try to ensure that the maximum amount of inventory is sold. As the title of the document implies, this is held to be a bad thing.

Because of the nature of the business that PubMatic is in, the recommendation in the document is that publishers use ‘dynamic daisy-chaining’ (which is essentially what PubMatic does, choosing the order of daisy-chaining based on expectations about which network will be likely to monetize an impression most effectively) to solve this problem. At one point the document states (my emphasis):

Due to the volatility of online ad pricing … creating a dynamic “chain” of ad networks, rather than a static one, is the only way for a publisher to ensure that they can get the best price possible for their ad space.

I would respectfully disagree with this statement; another way of achieving this is to use an ad network that is a member of an ad exchange, and which can therefore draw on a larger pool of advertisers than just those with whom it has a direct relationship.

But I don’t disagree with the main sentiment of the PubMatic paper, which is that publishers still struggle with significant inefficiencies in the way they monetize inventory; and I believe we’ll see the kind of multi-network optimization solution that PubMatic offers (also available from Rubicon and AdMeld) become increasingly important as the year wears on. diggDigg RedditReddit StumbleUponStumbleUpon

October 29, 2008

Whence the universal tag?

With another E-metrics Summit over (sans me, sadly), it’s clear that interest in web analytics and online measurement remains high, even (or especially) in these troubled times. But as the technology sets for online advertising and web analytics continue to merge and overlap, one urgent question remains unanswered: what are we going to do about data collection?

You only have to talk to any medium-sized web agency, or marketing manager for an e-commerce site, to understand that online behavior data collection is deeply broken right now – ad servers and web analytics products still collect their data entirely separately, leading to misery for webmasters as they struggle to maintain two (or three, or four…) tracking tags on each page of a site, and misery for analysts as they struggle to reconcile differing numbers from different systems. If you throw ad tags (that is, the snippets of code that actually cause ads to be displayed on a page, such as the AdSense code) into the mix, things become even more complicated.

How we as an industry go about fixing this problem depends on who we care about more: webmasters (I use that term loosely to refer to the gaggle of unfortunates who are charged with maintaining and updating a website), or marketers; or whether we decide that we care about them both. Here are some ideas (none of them new) about how to approach the problem, together with “feel the love” rankings for marketers and webmasters. Feel free to add your own ideas in the comments.


Idea 1: Merge the back-end data

Marketers: ♥♥♥ (out of 5)
Webmasters: ♥ (out of 5)

head-on-collision It’s not uncommon for a site to be using multiple tag code from the same vendor, such as Google (which has separate tags for Adwords, AdSense, GA and DFA/DFP) or our good selves (adCenter, adCenter Analytics, Atlas and others). If this is the case, then the vendor has the opportunity – some would say the responsibility – to join together the data it collects at the back-end to provide a more joined-up and consistent set of reports for marketers.

Google has just taken another decent step in this direction with its inclusion of AdSense clickthrough and CPC data in GA reports. I don’t actually have detail on exactly how they’re doing this, but my best guess is that they’re merging the click data from AdSense with the impression data from Analytics.

You can generalize this approach to a situation where two or more vendors might group together to pool the data they have to provide a consolidated set of reports. This is (sort of) the approach used by Omniture and DoubleClick, where you can use an Omniture tag in place of DoubleClick spotlight tags for conversion tracking.

The crucial pre-requisite is that the different sources of data need to be mergeable; and that means a couple of things. First, the visitor ID needs to be shared between the data sets. This is fairly easy for a single vendor to achieve, but trickier for vendors working together.

The other implication is that it needs to be possible to de-duplicate individual transactions. If you have two tags on your page, one for a web analytics product, and one for an ad server’s conversion tracking, it can actually be pretty challenging to ensure that when a user requests a page, you don’t count the page impression twice. Either you ignore one source of data completely (which is sort of what Google seems to do with AdSense/GA), or you have to employ various heuristics to decide when to throw something away – for example, if you register two identical page requests within a fraction of a second of one another, you can be confident (though not certain) that they are duplicates.

As for the customers? The marketer gets a decent benefit from this approach; they’ll see merged data, though the quality of the data may still leave something to be desired (hidden ‘seams’ where the data has been stitched together can trip up the unwary analyst). The webmaster, on the other hand, sees little benefit – they still have to maintain both tags, especially if each tag has its own unique capability. So this solution is really more of a stepping-stone to a more complete approach than a destination in its own right.


Idea 2: A “tag management” system

Marketers: ♥♥
Webmasters: ♥♥♥♥

trashcan Even if a single vendor or pair of vendors can join forces to combine the data from a couple of tags, most sites are still going to be using multiple tags from multiple vendors, some of whom (by their very nature) are never likely to co-operate on data. Given this state of affairs, one obvious approach is to provide some more technology to the webmaster to help them manage the plethora of tags.

Such a system would be, essentially, a content management system for tagging, enabling the webmaster to define which tags from which vendors should appear in which places on their site. Such a system could come from a vendor, or a sufficiently motivated site owner could create it themselves.

A webmaster using such a system would see a dramatic reduction in the overhead associated with managing multiple tags (once they’d gone through the pain of implementing the tag management system’s tags, that is). Furthermore, a well-implemented tag management system would make it easier for the webmaster to introduce (and remove) tags, reducing some of the friction associated with moving from one analytics or ad serving vendor to another.

The big sticking point, however, with a system like this, is custom tagging. If you actually speak to a site owner about the pain of tag management, having to actually insert a JS file into the page is only a small part of the task – and that step is made much easier by modern content management systems.No, it’s the definition of custom variables, and integrating them with the data coming from the site, that is the challenging and time consuming step. Publishers (who are implementing ad server tag code to host ads on their site) also have the overhead of defining page groups for their content, which is a major task compared to the actual tagging itself.

So in order for such a system to be really useful, it would need to provide a standardized interface between the data coming from the site and the tags – essentially, its own custom variable schema with a defined set of mappings to Omniture, GA, Atlas AdManager, etc.

A company called Positive Feedback (based in London, which means they must be geniuses) has taken a stab at providing a solution here with their TagMan offering. And Tealium is looking to address the custom variables problem with their solution, TrackEvent.


Idea 3: A universal tag

Marketers: ♥♥♥
Webmasters: ♥♥♥

rfid-tag Ah, the universal tag. The holy grail of web analytics (at least, according to some). The idea here is that a group of vendors (perhaps under the augurs of the Web Analytics Association) come together to create a universal piece of tag code that can capture data for any of their services. The upshot is that the webmaster only has to place this single tag on their site, and then configure the tag for whichever vendor solutions they’re using. A side benefit of the “universal tag” is that it can direct beacon requests to the customer’s own data collection systems as well as a third-party’s – avoiding the problem of data ownership.

They key challenge with this approach is that, despite warm words on the topic from web analytics vendors, there’s little real incentive to put a bunch of effort into doing something like this. All the vendors get is a potentially more complicated implementation, and more client mobility. What we may find happening instead is vendors supporting other vendors’ custom variables and event calls  - so vendor A could come in and say “simply switch out your call JS file reference (or add ours), and we’ll start capturing the same data you’re already getting”. It would be interesting to see if any vendors complained that their IP was being infringed by this approach.

A variant of this idea is where a vendor creates a tag architecture and then works with partners to encourage them to abandon or supplement their own data collection with the vendor’s – thus making the vendor’s tag the universal tag. This is Omniture’s approach with Genesis. This approach strikes me as more likely to succeed, since the incentives work differently; it’s in Omniture’s interest to push continued Genesis tracking adoption.

The asymmetry of Omniture’s approach also makes a more general point about the universal tag idea – which is that it seems likely that the vendor who already has the most well-established tagging relationship with a client will be able to leverage that to get other systems’ data collection needs met within the framework of their tag. This is likely to be the web analytics vendor, so we should look to those organizations (rather than, say ad serving companies) to lead on a solution like this.


Idea 4: A universal data collection service

Marketers: ♥♥♥♥
Webmasters: ♥♥♥

InsideWarehouse_300 If you continue the thought process around universal tagging, and vendors looking to provide more and more help to customers with data collection, then you end up with the idea of a vendor providing a fully-fledged data collection service.

I’ve blogged about this idea before, as it happens. The core idea here is that some kindly organization (which has access to a large pool of cheap processing and data storage) takes it upon itself to offer a data collection service that is so flexible, reliable and cheap that many other vendors abandon their own data collection and use the common service.

Part of the service is a “universal tag” which can be configured to capture the data that each analytics/ad serving service needs. But the difference is that the universal tag doesn’t try to generate beacon calls in the correct formats  for the individual services, or even send that data to those services’ data collection servers – it just gathers the data to a centralized repository and the other services access this data programmatically.

This approach combines some of the benefits of the two preceding ideas – for webmasters, the tag management process is radically simplified because one tag can do multiple things. Marketers like it because it would finally deliver numbers which match up. However, the approach wouldn’t work for certain things, such as adserving tags – unless that system was merged together with the data collection service.

Of course, another obstacle to this kind of approach taking root is vendors’ reluctance to entrust their (or their customers’) data to a third-party. This reluctance is liable to increase in proportion to the size of the vendor. So whilst Omniture would like balk at using a data collection from Google or Microsoft in place of its own, a small vendor (such as our pluckly little friends at Woopra) may find such a service invaluable in allowing them to focus on analytics rather than data collection.


So those are my ideas – what are yours? And which one(s) of the above ideas do you think are most likely to gain traction? diggDigg RedditReddit StumbleUponStumbleUpon

September 25, 2008

Yahoo! APT (formerly AMP!) emerges blinking into the sunlight

apt_logo_150x76 Well, they said it would launch in Q3, and it has – yesterday Yahoo! unveiled its new ad management platform, called APT, at a razzamatazz-filled event in New York introduced by John Hamm, star of Mad Men (currently the topic of much debate in our house as to its merits).

APT started life as “Project APEX”, which Jerry Yang started to talk about around a year ago as a successor/complement to Panama (Yahoo’s search ad platform, properly known as Yahoo Search Marketing). Yahoo then pre-announced something called AMP! (Ad Management Platform) in March, saying that it would revolutionize the way that ad media was bought and sold, drastically simplifying the selling process for publishers in particular. And yesterday AMP!’s name had changed again, to APT. APT does not appear to stand for anything, but at least they have dropped the exclamation point.

So what is APT? Well, according to Yahoo, it’s “designed to simplify the process of buying and selling ads online while connecting all the market players -- publishers, advertisers, agencies, networks, partners and developers -- from a unified platform to do business more efficiently and effectively”.

However, in its first incarnation, APT is principally a tool for publishers, aiming to make it easier for them to respond to advertiser/agency RFPs, and allowing them to build ad hoc private networks in order to be able to re-sell other publishers’ inventory. This latter capability is strongly linked to the initial user base for AMP, which is Yahoo’s Newspaper Consortium [PDF] members. The Newspaper Consortium is a sort of hybrid advertising and content network. Two members of this network – the San Francisco Chronicle and San Jose Mercury News – are founding customers of APT.


APT for publishers

According to the blurb on the APT site, APT will bring the following benefits for publishers:

  • Simplified workflow (creative management, campaign management)
  • Analytics & yield optimization (inventory management & prediction)
  • Increased inventory liquidity through cross-selling abilities and integration with Right Media Exchange
  • Extensibility via web services & an API
  • Access to Yahoo!’s expertise (creative development, targeting, etc)

The only screenshot available is of the APT dashboard, which looks fairly nice, but doesn’t reveal that much about the functionality of the system (click the image to view it full-size):


There are also some more tidbits in the video which Yahoo release in April during the original AMP announcement.

Of the announced functionality, the ‘cross-selling’ capabilities in APT are some of the most interesting, representing a twist on the network model. Rather than running a traditional network where the publisher members give a certain portion of their inventory to a centrally managed hub, with APT, publishers can buy and sell inventory directly to and from one another. This will likely mean that publishers can get a better price for that inventory than if they sold it at remnant prices. If APT does a good job of this, it will make publishers’ lives much easier, and deliver a much-needed fillip to their revenues.

SImilarly, APT – by integrating with Yahoo’s Right Media Exchange (RMX) – could attract networks to work with Yahoo/RMX by offering a new pool of inventory that those networks could resell.


What about advertisers and agencies?

imageWhere APT’s value is less clear to me is as a tool for advertisers and agencies. APT will provide a one-stop-shop for buying inventory on Yahoo’s properties and those of its publisher partners (i.e. the Newspaper Consortium folks) – and, given Yahoo’s strength in behavioral targeting, should be able to offer innovative inventory packages and highly targeted buying. But do advertisers and agencies need another interface for buying ads? These organizations would prefer to buy their media through the third-party ad server solutions (DoubleClick and Atlas, mostly) that they already use. Already they face fragmentation in their buying systems for search, contextual, display and rich media advertising – another tool may add to the pain, not ease it.

This may seem like a biased comment (since Atlas is now part of Microsoft), but in fact Microsoft faces the same kinds of challenge as we evolve our advertising platform. Our adCenter product offers a web UI for buying advertising (mostly search and contextual, with display coming), but larger advertisers prefer to interact with it indirectly through its APIs. And this – rather than a ‘one-stop-shop’ buying UI – is how I think APT will end up interacting with advertisers and agencies. Sensibly, Yahoo seems to have appreciated this, since a big part of its APT story is its extensibility through third-party integration.

in conclusion, if APT can create a more transparent network buying experience, and at the same time enable publishers to gain more control over how their inventory is sold, then it will definitely be a Good Thing for the industry – and for Yahoo, as it looks to position itself against Google and Microsoft. It’s going to be interesting to see how APT develops. diggDigg RedditReddit StumbleUponStumbleUpon

September 02, 2008

Internet Explorer 8 beta 2: Privacy vs Monetizability

image Once upon a time, when I was a young turk, I would assiduously download every last doodad that my employer created as soon as it shipped - or often long before, happily reaching for the pile of floppy disks as I rebuilt my computer for the umpteenth time following the latest toxic combination of untested software.

Age (and a need to still be able to work on my computer) has slowed me down. So I passed over IE8 beta 1, preferring to read about others' experiences of the new "standards mode" that is the default rendering mode for the new browser.

But last week, only hours after its public availability, I downloaded and installed IE8 beta 2. Why? Because it contains a raft of new features for protecting user privacy. I've blogged previously about the eternal tension between user privacy on the web, and the measurement and tracking that is so essential to many websites' business models. Put simply, if users' behavior could not be measured online, a lot of online businesses would go out of business.


What's new?

So how does IE8 contribute to the debate? Well, there are a number of minor features to protect users, and one major one. The minor ones include a nice feature in the address bar to highlight the actual domain of the site you're looking at:


This makes it much easier to spot phishing attacks, since many phishing sites try to confuse users by including familiar looking domains as subdomains of the real site, e.g.:

Another nice feature, related to phishing, is the "Smartsite Filter". This allows the user to check the current website against a known list of bad sites.It's essentially a UI into the automatic phishing filter that was built into IE7  - but it allows users to report sites as well as check them, adding a Cloudmark-like element of user contribution to the process of spotting evil sites.

This feature is rolled up under a new Safety menu, which also contains options to view the privacy policy info for a site (which shows all the cookies that were served and/or blocked, per IE7), and the security report for a site (any problems with the site's SSL certificate etc). Neither of these features is new, but it's nice to see them called out in their own menu.

The other small enhancement worth noting is that the "browsing history deletion" feature has become smarter - you can elect to delete the cookies etc. for all sites except those in your favorites list. This is a step forward, but it still mystifies me that IE has no easy way for browsing the cookies (and their content) on your computer, and selectively deleting them (as Firefox has had since v2, it pains me to say).


InPrivate Browsing & Blocking

The big new security/privacy feature in IE8 is called InPrivate Browsing (others have dubbed it "porn mode", but I am above such lewdness). InPrivate Browsing allows the user to browse without storing any cookies or browsing history, or locally cached files. It's good for when you're borrowing someone else's computer, or if you share a computer and don't want the other people who use the computer to know what you've been up to (now you are starting to understand where the "porn mode" nickname comes from).

The naming of the InPrivate functionality is somewhat confusing. Once you turn on InPrivate Browsing (either from the Safety menu or using Ctrl+Shift+P), something called InPrivate Blocking is also activated. InPrivate Blocking prevents your browser from sending requests for third-party content that it thinks are principally for the purpose of tracking your behavior. The big difference here is that this isn't just blocking third-party cookies - it's third-party content. That's tracking pixels, third-party JS calls, and yes, ads.

InPrivate Blocking will block third-party requests if one of the two following conditions have been met:

  • The request URL has been made in a third-party context on more than 10 other domains
  • You have specifically added the request URL through an InPrivate Blocking Subscription

To understand the first condition, take a look at the screenshot below, which is the dialog that comes up if you select InPrivate Blocking from the Safety menu when InPrivate Browsing is active:


You'll notice that there are some third-party request URLs that come up, well, a lot. is the domain that Google AdSense ads are served from; and you will doubtless know what comes from In the dialog above, the four URLs across these two sites have each been requested at least 20 times in a third-party context, and I've only been using IE8 for a few days. With the default settings ("Automatically block"), these URLs are blocked when I am in InPrivate mode.

The other way of adding a URL to the blocked list is to subscribe to an InPrivate Blocking list. This is an RSS or Atom feed of URLs that IE8 should block in InPrivate mode. I have created a subscription list which blocks third-party requests to - the domain for adCenter Analytics's tracking JS and pixel. You can try it out by clicking here.

The power of the feed-based approach to InPrivate Blocking is that privacy advocacy sites can post a single link to a feed XML file which users subscribe to; if that file changes, the users' blocking lists change. So you can expect to find "click here to block ALL tracking pixels and ads" links on such sites in the not-too-distant future. You can take a look at your InPrivate Subscriptions through the Manage Add-ons option in the Tools menu:



"Aargh! This sucks!"/"Great!" [Delete as applicable]

Whether news of this functionality sends a shiver down your spine or warms the cockles of your heart depends on whether your business depends on online advertising or web analytics. Popular third-party analytics systems like Google Analytics, or third-party ad servers like Atlas Enterprise will lose data on users who enable InPrivate Browsing; and even a less popular service that might not normally be blocked automatically could end up on common "Opt-out" feeds and have its tracking blocked, especially if had a poor reputation for privacy.

I must admit that when I first read of this functionality, I was - ahem - a little apprehensive, for the reasons above. And in truth, only time will tell what proportion of users are engaging InPrivate browsing (although, given the nature of the functionality, we'll not be gathering this data). But my gut feel is that, whilst this capability is a welcome addition to the privacy and security arsenal of Internet Explorer, actual take-up of the feature will be low. It needs to be invoked explicitly, of course, and the blocking of persistent cookies means that some desirable features of websites (such as being able to remember you from visit to visit) will be disabled. So I imagine it will be used sparingly by the vast majority of users.

Even so, this feature could easily add another 1 - 2% to the existing disparity between different measurement systems (such as an in-house web analytics system and a third-party ad server). Though there are techniques that vendors could use to work around the automatic blocking - the best example being the use of CNAME DNS entries to make the third-party tracking URLs look like first-party URLs - these techniques will add complexity to the implementation of such systems; so it might be easier for us all to live with a little less certainty.


If you'd like to read more about the new features in IE8, there's a ton of stuff over at the IE blog. And, with my Microsoft hat firmly on my head, I should say that the IE team has done an outstanding job with this beta, which is performing really well for me, and rendering most sites flawlessly, with just a few slight layout differences cropping up here and there. Well done, guys. diggDigg RedditReddit StumbleUponStumbleUpon

July 18, 2008

Online Ad Business 101, Part III - Ad Networks

So far in my nascent Online Ad Business 101 series, I've covered the overall advertising value chain, and looked at a superficial level at how an ad 'call' is actually handled. This installment brings together themes from those two first posts, by taking a look at ad networks.

As I have mentioned before, ad networks are in the media representation business. Even the biggest publishers don't typically have the resources to sell every last scrap of their available inventory day in, day out, so they hand over a portion of their inventory - the remnant inventory - to ad networks. Small publishers, on the other hand, have no resources of their own to sell their inventory, so they have to go to the market via networks. The networks aggregate all the inventory that they have available and then sell this inventory to advertisers.

Ad networks make money by selling the inventory for a higher price than they buy it. They can achieve this in a number of ways, which I shall list in broad order of sophistication/difficulty (with the easiest first):

  • Simple arbitrage: The network buys from the publisher at a rock-bottom price (because the publisher would literally make nothing from the inventory otherwise) and sells the inventory on in larger aggregated blocks at a slightly higher price. The "value add" is small - the network is simply allowing the advertiser to soak up some remaining part of their budget without having to go to lots of individual publishers.
  • Vertical aggregation: The network buys lots of small parcels of inventory in specific verticals (e.g. travel). It then aggregates the inventory for sale according to these segments, enabling it to charge a bit more. The advertiser is able to extend the reach of their campaign in a target audience without having to deal with lots of publishers.
  • Price model arbitrage: The network buys inventory on a CPM (cost-per-thousand impressions) basis, providing the publishers with a nice, reliable revenue stream. But it sells the inventory on a CPC (cost-per-click) or CPA (cost-per-acquisition) basis, reducing the risk of the inventory for advertisers (who are only paying for success), and absorbing the associated risk itself. The network makes money on the difference between the CPM it pays publishers and the "effective CPM" (eCPM) it charges advertisers.
  • Platform specialization: Advertising on emerging-media platforms such as video and mobile still requires quite a lot of specialized technology, forcing Rich Media vendors to build close relationships with the publishers that they deal with. Over time, many of the vendors in this space have gone the extra mile for their advertiser customers and turned themselves into networks, making it easier for advertisers to buy ads in these new formats across a range of publishers.
  • Behavioral targeting: The network buys inventory from publishers, and when the ad call is passed over to the network, it drops a third-party cookie. By doing this across all its publisher clients, the network can build up a profile of users by cookie ID - knowing, for example, that cookie ID XYZ123 has visited ten sites about watersports in the past week. The network can then use this information to add value to the inventory it's reselling, enabling advertisers to buy "active surfer dudes" and the like.
Can you give me some examples?

Sure. Here are some examples of ad networks which (roughly) map to the types above. In practice, of course, most ad networks employ a combination of the above techniques to maximize the margin on the media they represent.

Simple arbitrage:
adcom No doubt my description of as a "simple arbitrage" network will generate howls of protest from AOL ('s parent company). But one of's main value propositions is the breadth of sites and audience it can deliver. Because deals with so many publishers, advertisers can almost always find some inventory that maps onto the audience they're looking for, and are happy to pay a (relatively) modest fee for the privilege.

Simple arbitrage 2: Google Content Network (AdSense)
adsense_logo_main No discussion of networks would be complete without a mention of Google AdSense. AdSense provides a way for lots of small publishers to make inventory available to the pool of advertisers that use Google Adwords - in addition to their ads appearing next to Google's search results, these ads can also appear on the small publishers' sites; the ads are matched with the sites on a contextual basis (the content of the site is crawled to extract keywords which then stand in for the keywords that advertisers normally bid against for paid search results).

A crucial feature of this system is that the publisher is paid on a cost-per-click basis, so assumes a big chunk of the risk - if no one clicks, the publisher doesn't get paid. Google makes its money on the margin between the cost-per-click they pay the publisher, and the cost-per-click they charge the advertiser. The value proposition lies in connecting lots of small (and large) advertisers to lots of small publishers who are running sites which have a really good content match to the advertiser's offering. In other words, if you manufacture Mongolian nose-flutes, AdSense allows you to get your ads onto all the Mongolian nose-flute fansites out there, with very little effort.

Vertical aggregation: Martha's Circle
marthascircle Martha's Circle is the (rather winsome) name for the ad network run by Martha Stewart Omnimedia. It's a classic example of a publisher/media owner extending their brand (and saleable audience) by signing up sites in the same sector (in this case, lifestyle) and creating a niche network. For an advertiser wanting to reach thirty-something women with an interest in the home, this kind of network is a no-brainer when building a media plan. is another good example, as is Fox Interactive Media.

Price Model Arbitrage: DRIVEpm
drivepm_logo DRIVEpm is Microsoft's own advertising network, acquired with the acquisition of aQuantive last year. DRIVEpm styles itself as a "performance" network, meaning that it uses a variety of techniques (amongst them, price model arbitrage) to enable advertisers to buy inventory on a cost-per-performance basis, whilst still paying publishers on a cost-per-thousand basis. Scott Howe, former GM for DRIVEpm and now VP for the Microsoft Advertising business unit, wrote a great article back in 2005 about some of the dynamics in a performance network from the perspective of a media buyer looking to get the best ROI. Well worth a read.

Platform specialization: VideoEgg
image VideoEgg is a video advertising network (the clue's in the name, I guess). Its offering is a classic mix of innovative ad unit technology (their latest offering is something called "AdFrames") with a network attached. Another feature of VideoEgg is that it offers advertisers a CPE (cost-per-engagement) model for buying video advertising, performing the same kind of price model arbitrage that DRIVEpm is doing. Their publisher audience is widget & app developers for social media environments such as Facebook and MySpace, ensuring that their value proposition to advertisers is further differentiated (essential as the online video market becomes more crowded).

Behavioral targeting: Tacoda
image Tacoda is also part of AOL's Platform A unit, and markets itself as the world's "first" behaviorally-targeted ad network (a hard claim to substantiate, but equally hard to refute). Tacoda tracks behaviors of the visitors to its network of over 4,000 sites and uses this information to associate behavioral profiles with those users. It then sells inventory on these sites on a user-target-group basis, rather than by group of site or content area. These "audience segments" have names like "Family Chef" and "Photo Bug".


How does it actually work?

Understanding how ad networks actually serve their ads is essential in understanding how some of the above business models (especially targeting) work. I'll cover two scenarios - a small publisher/small advertiser scenario, and a large publisher/large advertiser scenario.

Small publisher/small advertiser
A small publisher will insert their ad network's ad code directly onto their site - in many cases, this is the only ad code the publisher is using, and is serving 100% of that publisher's ads. On the other side of the fence, the ad network may provide a web UI to enable advertisers to create or upload ads, and (possibly) allow the advertiser to choose which sites (or groups of site) those ads will appear on. The diagram below summarizes this (thanks to Right Media for the advertiser & publisher people icons):


Examples of this kind of system are Google AdSense and the Yahoo Publisher Network (these are often called "self-service" ad networks). The actual ad delivery model is pretty simple - the same ad server (the network ad server) functions as both publisher and advertiser ad server (the ad call path is on the left side of the diagram above).

Large publisher/large advertiser
When it comes to large publishers using ad networks to deliver inventory to large advertisers, things get more complicated. In this scenario, both the publisher and the advertiser will likely have their own ad servers. The publisher will configure its ad server to "hand off" a certain block of inventory to the network, whilst on the advertiser side, the advertiser ad server will be configured to buy a certain portion of a campaign from a network (or networks). So the ad call has to be passed from the publisher to the advertiser via the network:



It's the point at which the ad call passes through the network ad server when the network is able to drop a cookie on the user's machine, enabling behavioral tracking and targeting (assuming, of course, that the users don't delete their cookies in the meantime).

Of course, hybrids of the two models above also exist: large publishers will sometimes hand over some of their inventory to a self-serve network, in particular, in which case the publisher's ad server calls the network ad server, which serves the ad itself.

This picture also becomes more complicated when you consider that many ad networks will pass the ad request on to another ad network if they themselves can't fulfil it (or fulfil it economically). So, for example, a targeted ad network may receive an ad call from a user it has no information about. Rather than serve an ad for that user at a low cost (and thereby preventing that ad impression from being served to another user at a higher cost), the ad network passes the ad call on to a "value" (read: cheap) network. So in the picture above you can have two, or even three or four, ad networks passing the ad call around like a hot potato.

This game of pass-the-parcel isn't really very good for the user, who has to wait a long time to see the ad (which really hurts the advertiser most, since a slow-loading ad might as well not render at all); and it's also not great from a security point of view, because the publisher is ceding control of a portion of their site's screen real-estate to an unknown network and an even more unknown advertiser. Which is why ad exchanges are emerging which provide a centralized clearing-house for inventory, thus dispensing with the round-robin approach described above.

Online Advertising Business 101 - Index of all posts diggDigg RedditReddit StumbleUponStumbleUpon

July 06, 2008

Online advertising's dirty secret: Malvertising

dodgy_spyware_ad There's been a lot of chatter recently about the "dark side" of online advertising, in particular, the activities of companies like NebuAd and Phorm using somewhat shady techniques to gather behavioral data about users and using this data to target ads. I've even blogged about it myself. And click fraud remains a significant challenge to confidence in online advertising.

But whilst the term "click fraud" generates about 25 million results on the world's best search engine, the term "malvertising" generates only 2,170. Since you may not be familiar with the term, I'll offer you the definition I found on (sadly, there's no Wikipedia entry for Malvertising):

An Internet-based criminal method for the installation of unwanted or malicious software through the use of Internet advertising media networks and exchanges.

So Malvertising = malware + advertising. See? Clever (if ugly). But despite its goofy name and low profile, malvertising arguably represents a greater threat to the online advertising industry than either unscrupulous behavioral targeting or click fraud.

Malvertising can take a number of forms, typically along the following lines:

  • Ads that try to trick you into going to a site, where malware is installed (e.g. those "Your PC is infected! Click here to install our anti-virus software NOW!" ads)
  • Hijacking legitimate ad clicks and redirecting users to sites which encourage them to install malware
  • Malware disguised as ads, that exploit security vulnerabilities in web client software (such as this one in Adobe Flash), either to install further malware, or to scrape PII from the browser

The enormous reach of modern ad networks, plus the ability to place malicious code on thousands of otherwise innocent sites, makes distributing malware via advertising networks a very attractive proposition.

The malware itself is usually focused on stealing users' personal data (e.g.login details for broker accounts), taking control of the user's machine for distributed denial-of-service attacks (turning it into a zombie), or convincing the user to spend their own money buying malware "removal" software after they have been "infected".

But it's not just the end user that suffers. The publisher who has unwittingly hosted the malvertising can find themselves besieged by angry users demanding to know why they've been served malware from their site. If the ad was served via an ad network, the publisher will possibly cancel their contract, depriving the ad network of their business (ESPN has already ditched ad networks altogether, although not ostensibly for this reason). And advertisers who want to use increasingly sophisticated ads with high levels of interaction may find that they are unable to because these ads are some of the ones most likely to contain malware, and so are blocked by the ad networks and publishers the advertiser wants to deal with.

Furthermore, if end users lose confidence in the ads they're being shown, either in terms of where a click will lead, or whether the ad itself is malicious, this will drive down ad clicks and drive up the installation of ad blocking software - both of which will have a disastrous effect on the industry.


What can be done?

The malvertising problem is not insoluble, but it will demand a concerted effort from all industry participants to fix (or, at least, contain) it. I'll blog about these topics again in more detail, but the main areas of attention will need to be:

Creative/URL scanning: Ad networks and third-party ad servers will need to start scanning creatives and destination URLs as a matter of course. The technical challenge of scanning Flash or Silverlight-based creatives is considerable, since malicious ads will take steps to cover their tracks, such as obfuscating code, and behaving normally if they detect they're being scanned. Ultimately, the co-operation of Adobe and Microsoft may be required to put in place more robust systems for determining an ad's provenance.

URL scanning is a more manageable problem - all ad networks should ensure that ad click destinations do not lead to sites which are known to host malware.

Creative template quality: Malware has been known to sneak into ads through sloppy management of creative templates - if an agency uses an infected template, then of course all ads created using that template will be infected. This problem will grow as larger numbers of smaller advertisers start to use online services which provide Flash templates that are customized to order - the advertisers will not have the technical sophistication to determine whether the resulting ads are safe or not. Some kind of 'quality seal' may be required for these services, though that will not stop bogus ones springing up.

Outlawing redirect-based tracking: At the moment, many ad networks use redirects to track ad clicks, meaning that a single ad click can be passed around many ad networks before the user is finally deposited at the advertiser site. This system is open to abuse via "click hijacking", where a bogus network sends some clicks for legitimate ads to malware sites. Publishers should inform ad networks that redirects for tracking are unacceptable, which will mitigate this problem.

Ad isolation: At the moment, an ad which is served with a page (rather than via an iframe) has access to that page's DOM, which means that if the ad is malicious, it can crawl the DOM, looking for user PII (such as usernames and passwords for the site the ad is on, or credit card details). Microsoft is working on some technology to isolate ads that are served on its network, so that even if they're served in a first-party context (i.e. not via an iframe or redirect), they are unable to access the page DOM. Other publishers & networks should consider doing the same.

Industry co-operation: Currently, very little specific information about malware is shared within the industry, partly for noble reasons (it can be difficult to be specific about a malware instance without revealing user PII) but mostly for ignoble ones (no ad network wants to advertise the fact that they've been subject to a malware attack). This must change - the industry needs to find a way to share this kind of data without an individual network or publisher having to step into the firing line.


As I said, I'll return to this subject with some more thoughts on some of the above issues. In the meantime, a great resource for information on malvertising is Spyware Sucks, a blog run by Microsoft MVP Sandi Hardmeier, who tirelessly chronicles various malvertising outbreaks. It makes for sobering reading. diggDigg RedditReddit StumbleUponStumbleUpon

June 20, 2008

Online Advertising Business 101, Part II - How does adserving actually work?

Welcome to the second part of my Online Advertising 101 series. One of the things that I've discovered people fail to appreciate about online advertising is how much goes on behind the scenes in order to bring you an innocuous-looking banner ad. Whilst this is a relatively technical topic to cover in a series which is supposed to deliver insights about how the industry works as a whole, I think it's instructive to consider it because the technical jiggery-pokery that goes on gives rise to many of the issues that define the industry (for example, security and behavioral targeting). So here goes.


Back in the olden days...

Once upon a time, when the online advertising industry was in its infancy (all of about 11 years ago), if you wanted to place an ad on a website, you had to call the publisher personally and broker your own deal, and then send the publisher the ad you wanted them to place on their site. The publisher would, essentially, include the ad as part of their site design (example), and, once it was live, users requesting the page(s) where the ad was referenced would see the ad, like any other graphic item on the page:


I've shown this basic scenario as four interactions, because the user first requests the page the ad is on, and then the HTML in the page tells the user's browser to fetch the ad, which is also on the publisher's web server.


Enter the publisher ad server

It didn't take long for publishers to tire of this arrangement - it meant that whenever the publisher wanted to change an ad, they had to make a change to their live website, which was time consuming and risky. So publishers started to put their ads onto a separate server - the publisher ad server - which would act as a repository for the ads.


Over time, publisher ad servers have evolved into sophisticated beasts, providing a wide range of functionality that helps the publisher manage and predict their ad inventory, handle billing to advertisers, and target ads.

But the most fundamental value that an ad server brings for a publisher is the ability to rotate multiple ads through a single ad unit (that is, a slot on a page for an ad). So if a publisher has 100,000 impressions on their home page a day, and they have a banner ad at the top of that page, they can sell 25,000 impressions to each of four advertisers, load the ads into the ad server, and let the ad server do the work of ensuring that each advertiser's ad is shown the right number of times.

Examples of publisher ad servers are DoubleClick's DART for Publishers (DFP), Atlas AdManager, 24/7 RealMedia's OpenAdstream, Yahoo's AMP and Google AdManager. Plus, there are a lot of small players who offer simpler systems which really just handle ad rotation, for small publishers.

In days of yore, all four ads in the above example would be loaded onto the publisher ad server (in fact, this is still the case for premium advertising on very popular sites like, partly to enable advertising that is very highly customized for the target site). But this arrangement quickly proved inefficient for advertisers, who would have to send their ads to each publisher they wanted to advertise with; and would then have to re-send those ads when they changed, etc.

In the above model, the advertiser also lacks the ability to track the performance of their ads across multiple publishers, and is completely dependent on the publisher for data on how many times their ads were served (which still remains the primary way of calculating the price of a campaign); and they have no means of changing the delivery rules for a campaign (for example, by increasing the frequency of one ad creative, whilst decreasing another), except by calling the publishers and asking them individually.


Enter the advertiser (third-party) ad server

Advertiser ad servers are often referred to as third-party ad servers because the advertiser's ad server is a 'third party' to the ad transaction (the publisher ad server being the 'first party'). I'm going to refer to this server as the advertiser ad server in this post to save you the trouble of trying to remember who is the first and third party in this world.

When the advertiser ad server enters the picture, the ad request is not fulfilled directly by the publisher's ad server. Instead, the publisher ad server responds to the ad request with a redirect, telling the browser to fetch the content it's asked for somewhere else - in this case, the advertiser's ad server.


Note in the above diagram that I've removed the original call to the publisher's website; take that as a given. So the publisher ad server receives the ad request, and passes it on to the advertiser ad server.

Advertiser ad servers have also become very sophisticated over the years, but in the context of ad delivery, they perform just a couple of major functions:

  • They manage which actual ad for a given campaign is delivered when an ad is asked for, implementing rules like frequency capping, ad rotation, and targeting
  • They help with managing the actual ad creatives (the GIFs of Flash files) which constitute the ads themselves
  • They track ad delivery across all the sites that are involved in a particular campaign, measuring the number of times ads were served, the number of times they were clicked, and (through instrumentation of the advertiser's site) the number of conversions generated by those clicks.

The benefit to using their own ad server to an advertiser is that they only have to upload their creative to one place, and they can plan and execute a campaign across multiple publishers easily (at least in theory - in practice, it's not that simple, but we'll come back to that point later).

The third-party advertiser ad server market is dominated by a couple of players: Microsoft/Atlas (with Media Console) and Google/DoubleClick (with DART for Advertisers, or DFA). But there is a host of smaller providers, particularly specializing in Rich Media (interactive Flash and Video) ad serving, which also play this role in the ad serving process. And there are a number of ad servers which are really front-ends for ad networks. But I'll cover both of these cases in a future post.

Ironically, one of the things that ad servers tend not to do these days is actually serve the ad - this grunt-work task is usually farmed out to a Content Delivery Network (CDN), such as Akamai, which maintains thousands of servers across the Internet to serve ads (and other content) on behalf of other people, as quickly as possible.So when a CDN is involved, the advertiser ad server simply returns yet another redirect, telling the browser where the content really (really, really) is.


Sheesh! Why so complicated?

You might still be wondering why there is all this complexity just to serve a single ad. Well, the answer comes when you think about the above pictures when you have a hundred advertisers, and a hundred publishers. The publisher and advertiser ad servers enable the one-to-many relationship that publishers and advertisers need to maintain. Or, put another way:

  • The publisher's ad server helps the publisher manage their inventory across many advertisers
  • The advertiser's ad server helps the advertiser manage their media buying across many publishers

I'm afraid to say, however, that the picture I've painted above represents a fairly simplistic view of the mechanics of ad serving. The picture becomes more complicated when you include ad networks, rich media, tracking & targeting, or ad exchanges in the mix. But you've probably read enough for today, so I'll pick up these topics in subsequent installments.

Feel free to add your comments/questions in the comments box.

Online Advertising Business 101 - Index of all posts diggDigg RedditReddit StumbleUponStumbleUpon

June 03, 2008

Try out Silverlight Streaming, earn money

silverlight_logo_mix You may have heard of Silverlight, our Rich Internet Applications framework - and if you haven't, you're sure to hear more about it this summer, as it'll be used on the NBC site to stream Olympics videos. But you don't have to be NBC to take advantage of Silverlight video streaming - or know anything about Silverlight development.

Our friends over on the Windows Live Dev team have had a hosted Silverlight Streaming service up and running for a little while now. You can upload your own videos (in pretty much any format) and we'll transcode them into streaming format and give you a nice little snippet of HTML that you can include on your own website to embed your streamed video whereever you like. And the quality is waaaaay better than those other guys - even if the content might be of questionable quality.

Why I'm telling you about it now is that we're about to start a trial program where we insert ads into the video stream as overlays, and cut you in on the revenues. All you have to do is add a few keywords each time you upload a video and we'll insert some relevant (and appropriate) advertising into the stream (see an example here - scroll down the page a little). So if you've been struggling to monetize your video content with something like AdSense, now's your chance.

Sign up for Silverlight Streaming itself by clicking here - and if you want to sign up for the ads trial, click here. I'm afraid this trial is only open to US residents with a US Social Security number or tax ID right now; if you don't have one of these, we can't pay you, unfortunately. diggDigg RedditReddit StumbleUponStumbleUpon


About me



Enter your email address:

Delivered by FeedBurner