This is the second article in a four part series on Geotargeting. Click here to read part one. 

In today’s digital ad market, geotargeting depends on mapping a user’s IP address to a physical location, a task every ad server outsources to my knowledge.  This is because the process of assigning a geographic location to an IP is messy and complex to say the least.  Just because the ad server outsources the functionality however doesn’t give Ops an excuse to ignore this important and highly utilized feature.

How is an IP Address Associated with a Geographic Location?

By and large, IP addresses are arbitrary – meaning they could be anywhere, and there isn’t much rhyme or reason to their values from a geographic perspective.  It isn’t as though if the IP address starts with a 1 it is always located in the United States, for example.  Instead, companies like Digital Envoy use a multi-layered approach to assign geographic qualities to a user, some highly technical, and some which are just common sense, and some that are a combination of the two.

On the common sense side, a fair amount of geolocation companies can leverage Regional Internet Registries, or RIRs, to assign high level qualities, like country or continent.  The RIRs each own dedicated ranges of IP values and exist to allocate IP addresses within their regions, and cooperate among each other to ensure that the same IP isn’t being used in more than one place. So placing the IP address within a specific RIR’s range allows the service to identify location at a very high level.  Some geolocation services are rumored to work with large registration based sites as well, and have zip code information that a user might manually enter during a sign up process.

Pings, Traceroutes, Reverse DNS, and Other Technical Methods of Geolocation

From there though, the heavy lifting is usually done through a combination of three technical processes known as pings, traceroutes, and reverse DNS lookups.  Let’s run through a high level explanation of all three processes, and then explain how they work in concert to geographically locate a single IP address.

A ping is just a small piece of information sent from one computer to another, with a request to call the originating computer back.  Pings can also record the round trip time of the journey, and are used for a variety of administrative network processes.  Think of it like a submarine’s sonar technology, applied to the internet.

Tracerouting is basically a way to record the network routing process of the ping service, or the detail behind how the ping got from one machine to its destination.  Tracerouting records how a ping is routed, who it is routed through, and the time it takes at each step.  When information travels across the internet, be it a ping or just regular surfing, it moves through a series of very high speed fiber optic networks owned by various public and private entities.  Now, when the information gets physically close to a user, it passes down to an Internet Service Provider (ISP), which sells internet access to consumers.  The ISP eventually moves the packet of information to a nearby network router to the user, which connects directly to the user.  By using the traceroute utility, the geolocation service can know every system the information was passed through in order to get to its final destination.  The important piece of information the service gets from a traceroute is the IP address of that final network router, geographically nearest to the user.  You can ping or see the traceroute command in action on your own machine at Network Tools.

With the network router’s IP address in hand, the geolocation service can finally use a technique known as a reverse DNS lookup to identify who owns that network router, which it can use to lock in on the physical location of the user.  Reverse DNS is simply a service to identify the hostname of an IP address, that is, who owns an IP address.  For many home computers, the host ends up being the ISP.  For businesses, the host ends up being the company’s domain. DNSStuff provides a reverse DNS lookup service – just enter an IP address into their ‘IP Information’ tool to try it out.

Geolocation in Action

Now that you understand the basic approach, here’s how it all works together at a high level –

When a geolocation service wants to triangulate an IP, it starts by pinging that IP address from a central server it owns, and then looking at the traceroute.  From the traceroute, the service can identify the nearest network router to the user by IP, labeled point A on the diagram below.  Then, using a reverse DNS lookup, the service can find out which ISP owns that router, and then query the location from public data, the ISP itself if the service has a business relationship in place, or failing that, triangulate the location with the process below.

In all likelihood, the geolocation service already knows the location of this network router, either by working with an ISP directly, or through previous triangulation efforts.  With that location in hand, the geolocation service hands off the triangulation process to servers closest to that network router, of which it also knows the exact geographic location.  Now, the service sends a ping from at least three of its own separate servers (1, 2, 3), and records the time it takes to reach the user.  Only time can be recorded from a ping, not distance, but using time as a radius, the geolocation service can draw a circle around each server, and know that the target location must exist at some point on the arc.

With three separate locations, the target location should exist at the one point where all the arcs meet, which also gives the service the exact vector to the target from each server.  And, since information runs through fiber optic cable at a known, constant speed (about 2/3 the speed of light), the service can now translate that time into a distance, and with the vector and a known server location, calculate the exact location of the target, within a certain margin of error, depending on the exact method used, and how many points of triangulation are employed. Currently, the most advanced geolocation triangulation methods employ as many as 36 points to eliminate problem data and increase accuracy, and can accurately map an IP address within 700m – but we’ll talk more about that in the final piece in this series.

Network Maps & WHOIS Lookups

Using either piece of information, the ISP or the business domain, the geolocation service can further refine the geographic values of a given IP.  Geolocation services may also work directly with ISPs to get the general physical location, when available of a given IP, since the ISP will know the exact address of the customer using that connection at any given time.  It’s important to note that no PII is exchanged in that process, a zip code is just mapped to the IP address, and not all ISPs participate, or may simply provide the location of the final network router instead of the end-user’s zip.

Some of the more sophisticated geolocation services may be able to deduce the physical location of an ISPs network routers, also known as the ISP’s network map, by pinging those routers from various servers with known geographic locations, measuring the time it takes to get a response, and using that information to triangulate the router.

Businesses may also have a specific address, available through a WHOIS lookup, which allows country, state, city, and zip to be assigned.  The WHOIS directory is a public registry of who owns what domain, along with their name, and importantly, address.  Through this information, geolocation services can get a better idea of the physical location of each machine.

Where Does Geolocation Data Come From?

In most cases, a 3rd party table from a company that specializes in geolocation data.  Practically speaking, most of the advertising industry relies on a small company called Digital Envoy, founded in 1999 by a few smart entrepreneurs, and was acquired by a larger media company called Dominion Enterprises in 2007.  Digital Envoy pioneered the process of linking an IP address to a geographic location, and specializes in keeping the information current, and accurate.

Effectively, Digital Envoy maintains a massive table of literally billions of IP addresses and their inferred geographic qualities, and then sells access to that table at various levels of granularity to ad servers and lots of other companies who have an interest in identifying the location of a user, an ad server for example, who then cache the information in their local database, and can run queries against it.

Other companies that perform this service include Quova, MaxMind, GeoBytes, Cyscape, IP2Location, andAkamai’s EdgeScape product, though there are also free services out there such as HostIP, IPInfoDB, andSoftware 77.

[This article was originally published on Run of Network in Dec of 2011]

This is the first of a four part series on Geotargeting – see the links at the end of this article for parts two through four.  

Before the web, most advertising was targeted in a specific geographic area by default.  Virtually all newspapers, radio stations, billboards, and even television stations were local entities.  It’s true that there were some national platforms out there, but most media publishers served a local advertising market, and in fact, living in that market was often the only way to get that media.

On the web however, every publisher is a global publisher, with their content readily available and immediately accessible from any connection on earth.  For marketers, even very large marketers, this presents a problem, since they likely only want to reach people in a certain market, and may even want to track their campaigns by market.  Having spent decades and billions of dollars refining a market-based approach, the advertising industry is in no hurry to abandon their hard won knowledge around geo-based messaging.

To fulfill this need and others outside the advertising industry that rely on knowing the physical location of a virtual user, geolocation services were created to map a user’s IP address to their real life location, though usually nowhere near as specific as their real-life address.

From an Ad Ops point of view, geotargeting might be the most common targeting criteria required by an advertiser, so it’s critical to understand how it works, what the limits are, and where geotargeting is going in the future.

Geotargeting & the Ad Selector

To understand geotargeting though, you first need a baseline understanding of how an ad server selects a specific ad for a user.  Imagine for a moment the challenge of the ad server – it has perhaps thousands of ads it could serve to any given impression, each with a different impression goal, flight dates, priority, and targeting requirements.  The ad server’s job is to work within all these restrictions and deliver each campaign evenly over the course of its flight, or at least to the extent possible.  To do this, the ad server has to look at each ad call individually and make a decision as to which ad is in most need of that potential impression in just a few milliseconds.

Easier said than done!  There are likely hundreds of potential variables for the ad server to consider in making its decision, some of which pull from the ad call itself, some which pull from a user agent, and others which might reference cookies.  To make the final decision of what ad to serve, the ad server runs a selection program which identifies a value for every single variable for a given ad call, cross references those values with every ad in the system to determine which ads can meet the criteria for that particular impression, and then whittles down the list of possibilities based on priority and pacing needs until it identifies the best ad.

Said another way, the ad server has a list of items or variables it must define, and a list of potential values for each item.  The variables could be things like ad size, and the values might be 728×90, 300×250, 160×600, and so on.  To pick an ad, the ad server must define for each item from its respective list of values, even if the ad it ends up picking only happens to actually use a handful of those targeting values.

In plain English, the logical process would look something like the below -

For geotargeting however, there are far too many potential values for the method above to be effective. At a zip code level alone, for example, the ad server would add more than 40,000 additional values to define before it could select an ad, and many campaigns, particularly in the mobile realm require even more granularity, adding perhaps millions or even billions of potential values.  Even if that was possible, it’s an inefficient and brute strength approach to go about the problem and frankly, unnecessary.This process continues for every variable utilized in the ad server, well almost every variable.

Instead, to identify the geographic attributes for a given impression, ad servers tend to run a parallel process, and outsource those particular variables.   On the desktop side, geotargeting almost always references a user’s IP address, which is readily available from any web request, and then queries that IP address against a 3rd party database which has likely already classified a variety of geographic characteristics to that IP, and many hundreds of millions more.  This separate process simply returns all the relevant values for that ad call, so instead of the ad server picking from a predefined list of values for any geographic variables, the query just tells the ad server what the right values are.

So now, the process looks like this:

With this approach, the ad selector can make faster decisions, and leverage more accurate information from an outside company that specializes in location data, which as you’ll read in the next article, is a far more complex process than you might imagine.

[This article was originally published on Run of Network in Dec of 2011]

Ad Operations Departments build their reputations on the quality of their QA.  More so than any other department at an interactive media organization, Ad Operations is held accountable for any and all problems with the ads, regardless of the source.  So it is particularly important then that all members of an Ad Operations team are skilled in their ability to identify the root cause of any issue so they can quickly address it.  That means knowing how to replicate a problem and trace that problem to a specific tag in the ad server.

Luckily, there are number of tools available, some free, some paid, that are immensely helpful. One of my favorites, however, is Firebug, a Firefox Add-on that is quite useful toward a number of ends from a web development perspective, but also works well as a debugging application that you can repurpose for tracing ads.

What Does Firebug Do?

Firebug records every call to and from your browser, and makes all that code simple to view in-line regardless of when pieces of content actually execute with respect to the browser, but how it actually renders on the page.  I find it particularly easy to use and teach others to use precisely because it displays information based on how the end user sees it rather than the order in which it actually happens from the browser’s perspective, which is how most other tools operate.

Hover and Inspect

Firebug has a few advantages over other tools.  First, Firebug has a brilliant ‘inspect element’ functionality built-in, which allows you to simply hover over any specific area of web page and see the exact html code that was used to generate it.  For example, hover over a problematic ad and you’ll see the publisher side ad call, the redirect to the marketer’s ad server, and the final creative on the CDN, in addition to any other parties involved.

This might seem like a messy view, but since the code is displayed in the path it loaded, it makes it easy to look at the chain of events from publisher to the final ad, and pick out and call each piece independently if you so desire.  Finally, from a data leakage perspective, looking at the ad calls in a chain format allows you to identify any 3rd parties that might be involved in the ad call, but perhaps invisible from the user perspective.

How to Trace an Ad

So how do you actually trace an ad call?  Let’s look at a site and walk through the process.  I’ll use my own personal blog, AdOpsInsider.com as the publisher for this example. If you have trouble reading the text in any image, you can simply click on any one to open a larger image.

After you download and install the program, you should see an icon in Firefox’s toolbar (circled in red below).

Click the button and a window will pop up at the bottom of your screen.  At first, you’ll see just a few collapsed sections of HTML code, but you’ll see that you can click and expand any section you like.

In fact, if you expand a few sections, you’ll start to see that when you hover over a piece in the code, that exact section of the page is automatically highlighted to show you what it produces on the page.

That’s pretty useful if you’re a web developer and need to see what a piece of code you just published actually does on the page, but it can make it a bit difficult from a debugging perspective.  Fortunately, Firebug also allows you to reverse the process, whereby you can hover over a part of the page and it was automatically take you to the relevent section in the code.  Just click on the blue cursor icon in the upper left corner of the Firebug window (circled in red below) and hover over one of the ads on the page.

This method always tends to yield an approximate location somewhere in the chain of the ad call.  To really dig in, you’ll have to switch to the code itself at this point.  Conveniently, however, the page element will remain highlighted so long as you hover over a relevant piece of the code.  In this case we can scroll up quite a bit until we find the div element I used to place a text widget on my WordPress platform where I manually added the Google AdSense code, which is how I put ads on my site at the time I took the screenshots.  We can expand the JavaScript inside that div to look at the exact ad code on the page, which allows me to identify the name of the tag, and more importantly, the ID of the tag.  This will vary for your site, but with a little research, you should be able to locate a unique identifier for the tag from your ad server in the call itself.

To actually find the source on the marketer’s side however, we have to dig a bit deeper down the page code.  Now I don’t profess to be an expert on how Google uses Doubleclick to serve AdSense, but after looking around a few sites between various browsers, it appears as though the Object ID correlates to the ad’s unique ID in their ad server, which is how they might trace the call on their end.  Additionally, you can look at the next box and see the actual location of the raw swf file on the CDN.  Keep in mind that in most all scenarios, a publisher side Ops team only needs to locate the unique ID in their own ad server, which in turn allows them to locate the advertiser, order, flight or campaign, and the actual 3rd party tag.

Firefox or Bust

Unfortunately, as great as Firebug is, for now, it only functions in Firefox.  There’s no support in Internet Explorer, Safari, Chrome, Opera, or other major browsers, which can be an issue, since many ad issues today are browser specific, and not only that, but isolated to Internet Explorer.  Still, as a first line of defense, Firebug is a no-cost option you can start using today.  If you’re looking for browser-agnostic tools, you can look to Chrome’s built in toolset, or consider trying Fiddler or Charles, which function a bit differently, but have the same ability to pull HTML code apart and organize it call by call.

[This article was originally published on Run of Network in Oct of 2011]

Digital media is notoriously difficult to manage – not only are there technical and administrative challenges with getting a campaign live, but as the inventory is so perishable, campaign delivery can be tricky.

Underdelivery Despite Capacity

It’s no secret most publishers on the internet have plenty of inventory on a site wide basis, but often struggle with meeting campaign goals as they add targeting restrictions, frequency caps, competitive separation requirements, or have to deliver to a specific geographic area.  Not only that, but in many cases publishers and advertisers have a need to actively track delivery trends to ensure campaigns deliver as expected, and meet their goal within the scheduled timeframe.  Ad servers generally fill this role when capacity isn’t a problem, but when there isn’t enough supply to satisfy the demand, it falls on Ad Operations to prioritize delivery, and optimize problem areas.

But when there are hundreds or thousands of campaigns running at a given time, all with different goals, targeting requirements, and flight dates, how can anyone make sense of the data?  Many publishers have an inadequate process, relying on billing of financial reports to surface problems, or pawn the delivery management onto the sales team, which rarely has the expertise to effectively address the problem.

A far better solution is to build a simple report, a dashboard really, and use it as front line tools to catch problems early, before they spiral on for days.  This report is typically known as an At-Risk Report and in many cases can not only save revenue, but time, frustration, and significantly cut down on the finger pointing that Ad Ops groups often face.

Building an Effective At-Risk Report

The At-Risk Report is the most critical day-to-day report for most sophisticated publisher-facing delivery management groups.  The primary job of this report is to create a ‘delivery dashboard’ of sorts to catch all campaigns that are not delivering to their expected quota, allowing Ad Ops to flag issues early, and optimize as necessary.  Some ad servers, such as DFP, offer this type of report, pre-built, with many of the necessary pieces of data, but if yours does not, it is usually simple work to get create the report yourself. In either case, I recommend simply getting the raw data and moving it into Excel, where you can apply your own custom filters and calculations using Pivot Tables.

The first step in creating an At-Risk report is to pull the right data.  At minimum you’ll need advertiser / order / flight or campaign / start date / end date / targeting requirements / priority / ad size / flight or campaign status, as well as delivery information to date and the flight or campaign goal. In addition to those pieces of information though, consider adding other fields like sales rep, trafficker, site, or paid rate (be it CPM, CPC, CPA, or something else) to help route issues to the right contacts later.

The raw data should look something like this:

The On-Schedule Indicator

Once you have a data set created and in hand, the one critical field you’ll want to add to your data in Excel is an On Schedule Indicator, or OSI.  The OSI is a concept that DFP initially developed to help index campaigns to a standard performance metric.  In this case, the metric is what % of goal the campaign is expected to deliver.

The OSI is especially helpful because it corrects for different flight dates, goal levels, and the other pieces of noise that make it difficult to simply look at the raw data and determine which campaigns are delivering fine and which need help.  The OSI calculation is displayed as a %, which you can use as a filter in a pivot table so you can just look at the flights that are expected to deliver less than 100% of goal.  Typically the OSI is calculated off impressions, but you could easily change the formula references to run off clicks if you sell on a CPC basis.

You can use the following formula in Excel to create your own OSI – this may seem more complicated than necessary, but the formula is written in a way so that if the current date exceeds the end date of your campaign, the formula uses the campaign’s end date to calculate loss instead of the current date:

=IF(Current Date > End Date, ((Delivery To Date / (End Date – Start Date)) * (End Date – Start Date)) / (Goal), ((Delivery To Date / (Current Date – Start Date)) * (End Date – Start Date)) / (Goal))

You can now see that the OSI easily exposes problematic campaigns:

Organizing the Data

I recommend you create an initial pivot table to filter and organize the data.  Start by applying a report filter to reduce the results to campaigns that have OSIs under 100% and then use the row filters to break out that data by target, then advertiser and finally by flight or campaign.  Then, prioritize the results by sorting by end date, or urgency, and / or revenue at stake, but you can prioritize issues in whatever way makes most sense for your business. At the end of the day, you want a master view that looks something like this:

In my experience, you should try to pull and review your At-Risk report every single day, which will give you a deep knowledge of what is happening on your site, where inventory is scarce, and which campaigns need special attention.  If you find that you have very few struggling campaigns, it may be enough to pull the report on a weekly basis, but it typically takes only a few minutes to refresh the data, update your pivot table dashboard.

More Error-Catching Customizations

As a side benefit, you can use the same data set from the At-Risk report to catch trafficking errors, or flag other potential issues that don’t pop-up as pacing concerns.  For example, you could create a report to look at any campaigns that deliver a 728×90 ad in a 300×250 ad slot.  Or, you could use the data to create a calculated field that alerts you if any flight exceeds an abnormal delivery threshold, perhaps signaling an incorrect goal due to a trafficking error.

There are likely a handful of common human-errors you can track and catch with some thoughtful filters in your At Risk report.  Consider the common issues facing your Ad Ops team, which errors you are most prone and see if you can create a filter or calculated field using the At-Risk data to help you reliably identify those issues.  An At-Risk report won’t solve all your problems, but has the potential to play a cornerstone role in improving your organization.

[This article was originally published on Run of Network in Oct of 2011]

Even though it’s been the ‘year of mobile’ for the last decade, mobile advertising really did seem to reach a critical mass this year, as many publishers sold some of their first campaigns, and marketers moved more share of budgets to the mobile medium.  From an Ops point of view, this was also the first year for a lot of organizations to come to terms with needing a real process around mobile campaign implementation on both the mobile web as well as in application environments. As it turns out, getting ads, particular rich media ads to work in an app is fairly complex, requiring a higher level of technical expertise than desktop advertising.

Thank goodness then for the IAB’s release of the first set of development specs for mobile rich media APIs, known as MRAID and written in partnership with ORMMA to unify the industry’s approach to in-application advertising and simplify the implementation of mobile rich media.

Why is MRAID Necessary?

Thanks to some of the security features built it to smartphones, a layer of software called a software development kit, or SDK is typically required in the app to allow ads to expand over content, play sound and video, and do other things that are fairly standard in a desktop environment.  An SDK is nothing more than a block of code that a vendor like a rich media company might write to get their products to work in other applications, so the application developers don’t have to write the code themselves.  The problem is that every ad server and network has their own proprietary SDK for publishers to implement in order to get their ads to work, which usually requires an update to get released through the app store, which typically takes a few weeks.

Publishers not only have to do some development work to make this happen, but they then have to ensure that it doesn’t break the app itself before releasing it and then have to support updates to the SDK, basically forever, since not all users will update their apps, so legacy SDKs will stay in place long after a publisher might remove a vendor’s code from the most current version of the app.

So, with all that headache, the IAB took up the challenge to set some standards for SDK development, creating an open standard for rich media APIs to communicate with a mobile device, which is what an SDK does. By standardizing the API code, publishers can hopefully move to an SDK agnostic place, where they can use one centralized SDK that works with all rich media, and not need to support multiple piece of vendor code to enable ads. This is a big deal for the Ad Ops community and the Ad Tech community, who have struggled under the weight of technical problems to get campaigns live and facilitate mobile ad budgets. Hopefully MRAID makes a huge dent in those operational problems, and makes it faster and easier to get campaigns up and running, which should encourage advertisers to put more money to work in mobile.

I would encourage all Ops professionals to demand MRAID compliant apps and ads in your mobile ad spec and with vendor negotiations. The good news is that MRAID has enjoyed wide adoption and compliance from the major players in the mobile marketplace from the beginning, so there is already considerable momentum here.

Read about the other most significant developments in Ad Ops in 2011:

MediaBank & Donovan Data Systems Merger
Adobe Emerged as a Major Force in Ad Tech

I can’t think of another powerhouse corporation that has moved so quickly into the ad tech business as Adobe did this year. Before 2011, Adobe had only happenstance exposure to the market, playing a key role in things like site analytics (via Omniture), and rich media development (via Macromedia’s Flash), but didn’t have much involvement in the delivery of ads themselves. In the course of a year however, Adobe bought its way to a leadership position in data management, cross platform video ad serving, and social marketing. Thanks to three major ad tech acquisitions book-ending the year as well as the launch of an ambitious product to streamline ad trafficking, Adobe’s moves should make any Ops department sit up and take notice as one of the most viable competitors to the Google stack to come along yet.

Demdex

The first, and perhaps most significant move this year happened in January, however when Adobe bought one of the leading Data Management Platforms (DMP) in the marketplace, Demdex. In a year where ‘data’ was certainly one of the most powerful macro themes, Adobe’s purchase is a big deal. Demdex is a cloud based, cookie management and segmentation platform that allows media organizations to target people based on observed and inferred behaviors, and one of a handful of companies leading the charge toward audience targeting, site personalization, and richer, data driven experiences online. Big data solutions for digital media companies have existed for a long time online, but Demdex and other DMPs make that data actionable in other systems.

Adobe’s acquisition of Demdex adds momentum to the adoption of data management platforms among big companies, and is likely to drive adoption of the technology with major marketers and publishers, who may have been hesitant until now to share their data with a startup ecosystem. Certainly seeing the resources of a public company behind the big ideas of a startup will be interesting to watch over the coming year. I’m particular interested to see how Adobe integrates Demdex into the Omniture suite of products.

Auditude

After Demdex, Adobe’s acquisition of the video monetization and ad serving platform, Auditude was their next most important move of the year in my opinion. Auditude has done a lot of work in the video space to make cross platform video ad serving easy, whether the creative is destined for a smartphone, tablet, or desktop device. They’ve done a ton of integrations work as well to make sure the product plays nice with traditional ad servers and measurement companies as well, which is what big brands want to hear.

While it represents a small piece of the pie now, make no mistake, advertising on digital video, especially on mobile devices is going to a major growth story in the coming years. Video supply is far more constricted in the market, and the user experience and engagement results are much richer for advertisers, so video is one of the few places where publishers have real pricing power. There’s going to be tremendous investment on the publisher side because of the available budget, so Auditude makes a lot of sense for Adobe.

Efficient Frontier

Then, red hot after the Auditude acquisition, Adobe announced their purchase of Efficient Frontier, a search and social advertising company that is best known for its technology to execute and optimize ad buys on Facebook. Despite billions in ad revenue and thousands of advertisers ranging from local mom and pop stores to Fortune 500 brands, Facebook still feels like an untapped market and most industry sources agree that the social network should effective double revenues year over year for the next few years.

Adthenticate

Finally, outside of acquisitions, Adobe launched an under-reported project around ad tag validation in October, perhaps their most relevant project to Ad Ops professionals. I’ve written about Adthenticate in detail in a prior post on this site, but the big idea is to streamline the ad trafficking process through ad tag certification against a publisher’s ad spec, and potentially integrate that functionality into Macromedia Flash, also an Adobe product, so creative is built to spec from the get go. This is yet another case of exciting potential versus having a product live in production, so time will tell how successful the effort will be, but I’m optimistic at Adobe’s ability to execute.

What’s Next for Adobe?

With so many acquisitions, it leaves one to wonder what’s next for Adobe in 2012? In my mind the answer is clear – buy an ad server. If Adobe acquired or developed a mobile ready, RTB enabled ad server, they’d have one of the most impressive offerings in ad tech out there, well positioned for the next arc in digital marketing. Adobe, are you listening?

Read about the other most significant developments in Ad Ops in 2011:

MediaBank & Donovan Data Systems Merger
MRAID Specs Released

If you’ve ever used Google’s AdWords product, you know how blissfully simple it is to plan, budget, buy, track, and pay for your campaigns from a single interface.  It’s intuitive enough for virtually any small business to figure out on their own, but flexible enough to scale up to the world’s largest marketers.  Compare that now to the way most agencies buy digital media from online publishers, hacking their way through Excel templates, a pile of system interfaces, gobs of email threads, and fax machine printouts with an army of entry-level communications graduates.  To get a display media campaign live, it’s downright prehistoric, and certainly one of the biggest growth liabilities to the industry.

That’s why the MediaBank / Donavan Data Systems merger, assuming it gets approved by the Department of Justice, is so significant, because it has the potential to link all the systems an agency needs to execute a media buy from start to finish, thereby dramatically simplifying the process, and making it more efficient to spend money in digital.  If you work in Ops, MediaOcean has the promise to effectively end standard ad trafficking as you know it, moving your team away from ad server monkeys to a far more strategic QA and custom campaign execution experts.

How exactly would this happen?  The vision is for these companies to combine their existing agency workflow management software, and then develop a powerful open source API connection for outside ad technology companies to build on top of their existing product.  Between the two companies, MediaBank & DDS already effectively own the market for agency workflow systems.  This is the software agencies already use to manage traditional advertising campaigns, covering everything from tracking client budgets and agency fees, to actually booking ads with publishers.  Now, the companies want to combine forces to enable those same benefits on digital channels.  Through their APIs, the systems might connect the marketer’s ad server to the publisher’s ad server, allowing a machine to book the campaign, or at least mostly, instead of a human.

In my mind, the success of MediaOcean would move the Ad Ops department in most companies to a much more strategic place in the organization, removing the need for a brute force army of traffickers, and instead creating the opportunity for more technical strategists.  By spending less time going through the motions in the ad server to get simple campaigns live, Ad Ops could transition to client facing, cross-department consultants that enable highly specialized sponsorship campaigns, cross platform buys, and provide smart optimization strategies to drive more impactful results for advertisers.  Vendor implementations, campaign measurement, campaign execution, company communication, everything gets easier.  It’s about as close to a silver bullet solution as I could think of to some of the biggest issues facing digital advertising.

Here’s hoping it works, and next year we’re talking about the impact of MediaOcean, instead of its potential.

Read about the other most significant developments in Ad Ops in 2011:

Adobe Emerged as a Major Force in Ad Tech
MRAID Specs Released

While new to the market and perhaps less established than AdValidation, Adthenticate is an exciting development in the ad validation space for lots of reasons.  First, it has the resources of Adobe behind it, a mammoth corporation with some seriously smart development talent which I hope will continue to build on the current offering.  Second, Adobe owns Flash, the mainstay creative format of virtually every form of desktop display rich media ad, which means it has more than its fair share of QA problems for publishers, and for which Adobe is best positioned to address.  Adobe understands this technology better than anyone else possibly could, so it’s exciting to see a technology owner enter the validation space.  Finally, after speaking with Adobe directly, it’s clear they have a forward thinking vision for where this technology can go, the potential applications, and the resources and clout to make it happen.

Specific to their technology, Adthenticate for now only QAs Flash tags, although it seems to do so exceedingly well.  Adthenticate checks all the basics you would expect such as ad dimensions and filesize, but looks at framerate, animation time, and CPU usage similar to AdValidation.  Uniquely, however, Adobe’s product goes deep in video, measuring a variety of elements like the file format, which codec is utilized, video framerate, and more.  From a measurement standpoint, Adthenticate is pretty comprehensive.

Any user who likes can sign up for an account with Adobe to test a tag, either a swf hosted on a url (which you can likely scrape off a website of your choice using Firebug, or a similar web development tool), a local file you might have, or even an ad tag you have hanging around. For now the demo account only checks against the IAB 3.0 specs, but publishers, advertisers, agencies, or even rich media vendors who are interested in using their own spec can contact Adobe to partner with them during the beta period.  The service also offers an API connection that’s integrated with DFP and other ad servers, so publishers can automatically push tags from the ad server for QA if they want.

For now, Adthenticate still has some work to do to be a home run solution, but for a beta release, it’s not half bad.  What’s most interesting to me however is their vision of integrating ad validation into the current agency and rich media vendor workflow, and get ahead of the problem before it ever reaches Ad Ops.  Speaking with their Entrepreneur-in-Residence, Lalit Balchandani, a few weeks ago, he outlined a roadmap Adobe has to integrate Adthenticate’s abilities into Flash Pro (check out the mock-up below) so advertisers and rich media vendors can ensure tags will comply with ad specs as they build the creative.

Taking the concept even further, Balchandani explained that eventually, Adobe wants to build a type of 3rd party certification into ad tags, so publishers know that tags have already been QA’d against a particular ad spec based on meta data or some type of fingerprint built into the ad.  The idea would be that publishers could load their ad spec into a centralized validation tool, and advertisers could automatically validate their ads against that spec in advance, and provide independent verification that their ads comply.  Now wouldn’t that be nice?

We’ll see if it happens, but the approach makes a ton of sense for the Ops community on all sides, and has the potential to remove a major implementation roadblock for the industry as a whole. Going forward, I’d like to see Adobe do more to extend their service to more than just flash files, and do some more work on the workflow side of the product to make it simpler to batch ads to the system, without the need for Ops to manually separate the tags from the ad server export files.  Adobe’s API is promising, particularly if the agency side gets engaged in tacking the issue on their end, before they get to a publisher’s Ops department.   A more effective option for the near term to keep publishers excited might be to take a similar approach to AdValidation’s ability to parse & queue tags directly from agency emails.  I’d also like to see Adobe make it simple to export results to agencies, or host the results on a dedicated URL, which Ops teams could email as evidence, and provide the necessary detail on a tag basis.

All that said, this is a project to watch.  Adobe has already built an impressive toolset and their roadmap for the product is exciting to say the least.  Ad Ops teams would do well to take a moment from their week and at least explore the demo functionality.  For teams with especially burdensome QA work, this could also be an excellent opportunity to get involved and shape the product roadmap, which Adobe seems to have customized quite a bit for certain clients.  For more information, visit the Adthenticate site or email the Adobe team at Adthenticate (at) adobe.com.

Based out of Sweden of all places, AdValidation is the first and the best tool I’ve seen focused on ad tag QA to date, though because of their location, not many people outside of Europe are familiar with the company.  That’s a real shame, because the feature set is quite robust, and there are a number of smart, platform agnostic solutions in place to make workflow easier.  As many things like this start, AdValidation was actually developed as an internal tool for a Swedish ad network to help them address the issues of working with hundreds of various publisher specs in their own business before they realized it could be a standalone product on its own.  The benefit of course is that the tool has been battle tested, debugged, and enhanced by a real world customer.  

The concept behind AdValidation is to enable publishers or marketers to enter in a required ad spec in advance, and then easily bounce any 3rd party tags they want against that spec with an automated system.  From what I’ve seen, the tool is by far the most comprehensive and flexible in terms of feature set, allowing customers to check not only all the basic qualities of an ad like dimension and file size, but more advanced concepts like clicktag format and functionality, auto-audio detection, and so forth.  Perhaps the most innovative concept AdValidation developed was around measuring CPU usage, which is all but impossible to do manually or consistently.  Using a graph, the tool can show just how taxing an ad is on a computer, and measures the average usage, peak usage, and maximum sustained usage over 2 seconds or more, for the same type of machine every time.  What’s more, the tool allows publisher to set a spec based on multiple metrics, to consider both average usage as well as peak usage thresholds.

AdValidation runs all these checks on robot machines that load up the ad and record performance, instead of just decompiling and inspecting the file, though the service does that as well to check other things.  By using virtual machines and tracking actual performance, AdValidation can test what happens when a user clicks on an ad, if any 4^th party calls are made when the ad is called, and makes it simple to push large volumes of tags through the system.

In fact, AdValidation even lets you forward an email with a bunch of tags attached, parses them, puts them into a queue for QA, and then emails you back the results, or just lets you see it in their UI.  As an additional benefit, the tool makes the results page linkable, so it’s easy to provide the information back to the agency or marketers showing exactly what tags are breaking spec, and in what way.

From a usability standpoint as well as feature standpoint, AdValidation has a fairly compelling offering in my opinion, but I would encourage publishers to see a demo of the tool themselves, and weigh it against Adobe’s Adthenticate product.  Adobe has arguably already surpassed AdValidation in terms of advanced criteria, though it appears for now AdValidation is still easiest to use, and fastest to implement.

Read More: Adobe’s Vision for the Future of Ad Validation – Project Adthenticate

There are lots of reasons to be excited about what’s happening in the ad technology world right now from a business point of view, but from an Ad Ops perspective, the current landscape is pretty daunting.  For lots of folks at the implementation level, ad technology often means more integration projects, more complexity, more relationships to manage, and frankly, more work to pack into the day with the same amount of resources.  There are lots of tools and services being built for advertisers and publishers alike, but where’s the innovation for Ops teams on either side?

To date, with perhaps the exception of tag management solutions, I haven’t seen many products that seek to simplify the operational process for the direct sales channel – most everything seems focused on creating new, more complex products or bringing new, automated sales channels to market.  Those are fine goals, but I would submit that much like the years of neglect around resolving 3^rd party discrepancies, the ad tech community has to date ignored a huge potential opportunity to make life easier for Ad Ops teams.  In the past few weeks, however it seems like that may be about to change.

Specifically, during IAB Ops 2011, Adobe announced their entry into the ad validation space with some fanfare, throwing some much needed attention and hopefully some serious resources on a little known service with tremendous possibilities but few solutions.  For those interested in learning more, I hope you’ll read my new series on the ad validation space to explain the need, the current solutions, and where the space looks to be headed in the future.

Why Does Ops Need Ad Validation?

As a standard practice, publishers review the ads that marketers want to run before they are put in front of an audience.  This is true for traditional print and television publishers as much as it is digital publishers.  Most media outlets won’t allow marketers to swear in their ads, for example, but beyond content, publishers of every type have what is called an ad spec.  The ad spec details the format in which advertisers have to use for their ads.  For print ads, the ad spec covers things like colors, and dimensions; for television the spec might cover length, volume limits, and other technical aspects.

For digital publishers however the ad spec tends to get far more complex, covering not only basic details like ad dimensions, but also highly technical aspects such as framerate, peak CPU usage, animation cycles, clicktag formats, actionscript behavior, and allowable external dependencies.  For every piece of creative or ad tag that comes in, publishers have to check the ad against their spec, running down a long checklist, gobbling up hours and hours of time ensuring that the marketer’s ad is in line with what the company’s predefined limits to protect the user experience on their site.  The process is important, but so arduous, that plenty of publishers only check a handful of characteristics, if they have a QA process in place at all.

As any trafficker can tell you, the amount of time and energy wasted on ad tag QA is just silly at this point, and that’s just for the tags that will actually meet spec.  Find a tag that breaks a publisher’s creative guidelines, and a protracted battle begins between the publisher’s sales team, the agency, and other outside vendors that can last weeks or months, delaying campaigns, and costing everyone time and money.  The sales team always prefers to simply make an exception, so as not to bother the agency, and in some cases it can make sense.  The agency also tends to want the publisher to make an exception, and in some cases demands it, either because it will cost them money to rework the ad, or it will take so much time that it isn’t worth the trouble for the money they plan to spend with the publisher.  At the end of the day, the publisher has to weight these consequences against upsetting their users by possibly burdening them with ads that take a long time to load, interrupt the rest of the content, or are just obnoxious or annoying. 

Beyond the direct sales channel, as exchange-based demand has ramped up, publishers have less visibility on what runs on their site from an ad spec perspective than ever before.  Is a creative breaking a frame rate limitation?  What is the CPU usage to load the ad?  Are the click tags working and coded properly?  These are questions that no SSP or ad exchange will ask a publisher, let alone try to monitor and control.  Surely, there’s a better way, and ad validation technology just might be the answer.

How Does Ad Validation Help?

Quite simply, ad validation seeks to automate the QA process of checking ad tags against a publisher spec, saving publishers the time and effort to check all tags, allowing them to focus on problems instead.  These tools can measure a laundry list of qualities, everything from ad size dimensions to decompiling a flash file to inspect the clicktag format, and determine if the click tracker is functional.  While there are a number of browser plugins that can assist toward this end such as HTTP Watch or Firebug, but to my knowledge there are currently only two standalone tools built for ad validation – AdValidation, which is an independent company fairly established in the space, and Adobe’s Project Adthenticate, which is the new, but promising given Adobe’s importance and influence on the Flash technology.

Read More: AdValidation – First and Still the Best…For Now