Ad Serving 101, Revised

Way back in October 2001, I wrote a column with this same title. To this day, I get numerous e-mail from people thanking me for covering this topic. Given the state of the market right now, it’s probably time for an update.

Ad serving is increasingly becoming a commodity. The actual delivery of ads is certainly already commodity. The term “ad serving” is misleading and misunderstood. It sounds like just something that coordinates an ad’s delivery. There’s much more going on here than just that. Lets walk through it.

Publisher Ad Serving

Let’s begin with the nuts and bolts, the most basic functionality of ad serving, then I’ll dive in and explain where the complexities lie. Below is the simplest scenario. An advertiser bought advertising from a publisher and sent the files to the publisher to be delivered onto the page.

Examples of Publisher Ad Servers include Doubleclick DART for Publishers (DFP), Accipiter Ad Manager, and 24/7 RealMedia’s Open Ad Stream (OAS).

Publisher Only Scenario:

1. Browser points to a Web publisher and communicates via a publisher Web server. The publisher Web server responds back to the browser with an HTML file.
2. In the HTML file is a pointer back to the publisher ad server. The browser calls the ad server looking for an ad. The ad server responds with the ad’s file location. In this case, the file is sitting on a content delivery network (CDN) such as Akamai or Mirror Image.
3. The browser calls out to the CDN requesting the specific file containing the ad’s creative content (JPG, GIF, Flash, etc.). The CDN sends the file back to the browser.

This is relatively simple and easily understandable. But this deceptively simple diagram masks what’s going on behind the scenes at step 2. Let’s talk about that for a moment.

Every time an ad’s called, a series of very fast decisions and actions must take place. All this very detailed work should take only a few milliseconds:

1. The ad delivery engine is called and handed an ID that’s unique to a specific Web page or group of Web pages.
2. The delivery engine reads the ID and asks a sub-routine to choose which ad to delivery based on a bunch of facts – we’ll call this subroutine the “ad picker.”
3. The ad picker has a very complex job. It must hold all sorts of data ready, typically in memory or in very fast databases.

• Picker looks to see if the browser in question is part of any targeting groups in high demand, e.g. geographic location, gender or demographic data, behavioral groupings, etc.
• Picker looks at all business rules associated with each campaign assigned to the unique identifier.
• Picker looks at yield across the various options for each creative that match delivery criteria (which ad is most valuable to deliver at that moment).
• Picker sends final ad selection to the delivery engine. The ad is sent to the browser.

Data handed to inventory prediction system to help determine future ad availability and yield optimization.

Delivery and performance data handed to the reporting and billing systems.

I’ve masked some of the incredible technical complexity, particularly around inventory prediction and yield optimization, but the moving parts are relatively easy to track. I haven’t discussed the business management features of the publisher systems. Bear in mind there are sales interfaces, order input interfaces, billing and reporting interfaces, and many other features I do a bit of disservice to in skipping over.

So that’s publisher-side ad serving, and it’s relatively straightforward. Let’s look at the advertiser side of the equation.

Advertiser/Agency Ad Serving

It’s a bit misleading to call advertiser/agency campaign management systems “ad servers.” These solutions do serve ads, but only as a function of tracking them. Rhere are technical realities in the market that require the serving of ads in order to track delivery across multiple publishers from a central source.

Why does an advertiser or agency use these tools? Two reasons: workflow automation and centralized reporting. These agency tools allow a big chunk of an agency’s grunt work to be automated; the data input, creative management and trafficking steps are significantly automated. Since these tools deliver the ads across all Web sites in a campaign, they centralize reporting into one report set comparatively showing all publishers.

Examples of Advertiser Side Ad Servers include the Atlas Suite, Doubleclick’s DART for Advertisers (DFA), Mediaplex’s Mojo, or Bluestreak’s IonAd system.

Agency Ad Serving Scenario:

1. This begins as before: Browser points at a Web publisher, and communicates with a publisher Web server. The publisher Web server responds back to the browser with an HTML file.
2. In the HTML file is a pointer back to the publisher ad server. The browser calls to the ad server looking for an ad. This is where it changes. Instead of the publisher ad server pointing toward its own CDN, the ad server delivers a secondary ad tag, a simple piece of HTML that points toward the agency ad server.
3. The browser calls the agency ad server, which returns the final location of the creative in its own CDN.
4. The browser calls to the agency ad server CDN requesting the specific file with the ad’s creative content (JPG, GIF, Flash, etc.). The CDN sends the file back to the browser.

While there’s an additional set of hops between browser and ad server in this scenario, bear in mind that this entire transaction takes less than a second. As before, this relatively simple set of actions makes the complexity of what’s happening seem much simpler.

Behind the scenes is a complex, business-facing workflow system that automates about half of the tasks in a media buyer or agency ad operations person’s job. Without this automation, already complex agency roles would be unbearably difficult.

The next step is to get the last half of the agency workflow mapped into these systems and really automate the tasks.