Measurement & Tracking

At Risk Management – How Every Ad Ops Department Should Start Their Day

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 Management Report

The At Risk Management 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. (more…)

Resolving 3rd Party Discrepancies

What are Discrepancies?

As a standard practice in interactive advertising, advertisers and publishers maintain independent ad servers to manage their campaigns.  There are number of reasons and efficiencies each party gains with this approach, but since each party counts an impression at a slightly different point in the delivery of an ad (publishers count at the ad request, advertisers count when the ad is delivered), the reporting from either system never matches the other.  This difference is called a 3rd party discrepancy, and unfortunately, they’re a fact of life in digital advertising.  While you can take steps to minimize discrepancies to a certain extent, at the end of the day you’re just going to have to put up with them as a cost of doing business.

Generally speaking though, discrepancies between your local ad server and a 3rd party ad server shouldn’t exceed 5 – 10%. Every now and again however you’ll find a particular campaign that skyrockets into the 30% territory or more.  In those cases, you really need to look into the campaign and try to correct the problem.  Below are some initial steps to take to try and resolve large discrepancies. Integrate this process into your Ad Ops group and you should be able to address a majority of the problem tags you encounter. Get your discrepancy checklist here…

Managing Data Leakage

Like any issue, the first step in managing data leakage is admitting it is a problem and understanding how it happens.  It sounds obvious, but getting a large organization to commit to implementing a data leakage policy at the potential cost of ad network revenue and upset clients and you have your work cut out for you.  After you have buy-in from the internal stakeholders and understand it from a technical perspective, you can start to craft a policy around controlling advertiser access to your audience.  The below would be my recommendations on how to setup a foundation policy on managing data leakage from the publisher side.

First, as a policy, you should prohibit advertisers from dropping cookies on your users – it is a business liability and may even potentially violate your privacy policy. This will address the primary data leakage channel but is also the toughest internal hurdle to clear, because it will likely anger your clients so be prepared for a potential fight with your sales organization. They may resist anything that will anger clients (and they will probably be angry – after all, they most certainly don’t want to gravy train of free data to end), but once you explain that this technical issue is selling against them by commoditizing the site audience, they will probably get on board. You’ll also need a way to enforce this policy, which can be tough if you are lean on development talent. Larger publishers usually have some programmers handy who can create an internal solution to address the problem, and a few of the SSPs out there have also devised solutions to monitor ad tags for cookie dropping through randomly sampling. That is to say, they have a bot call every ad tag on a regular basis and see if any cookies are dropped via that ad call. Some Ops people may ask, ‘why not just manually check for cookie-dropping during manual QA, before the tag goes live?’  The reason just one look at the tag isn’t enough is because it is a well known fact that advertisers may not get around, or perhaps wait by design to adding piggybacked pixel fires to their ad calls until after their tag is up and running. That means you might not catch the issue during normal QA and need to have a way to monitor every third party ad call on your site on a daily basis.

Second, look into a tag management platform or data management platform (DMP) such as Demdex, RedAril, or Krux, to help blind the pixels you know about and do want to fire on your audience.  The reason for this is even if you prevent cookie-dropping, plenty of data exchanges and data collection companies can still use javascript to scrape page content, record page URLS, and semantically categorize page content. It won’t be as useful without a cookie, but it is still valuable.  Even worse, you may be inadvertently sharing user-level information in your URL string, as many of the social media companies were found to have done in an article in the WSJ in 2010.   This will be much more difficult if the only referring URL they can see is from your ad server or a third party company managing those pixel requests. At the very least consider adding a universal container to your site so you can control the pixels on site through your ad server. The major data management platforms will offer this service as a standard part of their offering, but there are ways to create one yourself though an additional iFrame based ad call placed in the header. The benefit of a universal container is you won’t need to rely on your IT department to add and remove pixels from the site, or worry about getting on a site release schedule. In general, DMPs will allow you to offer an alternative and safe way for advertisers to access your audience in a way that you can control (and get paid for).

Third, find out what your advertisers want and how you can add value. If the advertiser wants to retarget your audience, why not offer an audience extension product on your own and retarget the audience yourself through the ad exchanges? Both SSPs and DSPs have ways for publishers to productize their audience off-site and keep themselves in the value chain, grow share of budget, and offer advertisers the expanded reach and frequency they want to achieve. That auto and career sites in particular pioneered the publisher-powered audience extension model, so look to those companies as a model for your own business.

Data can be a business liability or a major opportunity for publishers who choose to manage their destiny. Tools and partners exist to help you and in most cases, advertisers will be happy to work through the channels you enable.

Read the other articles in this series –

Part I: A Primer on Data Leakage for Digital Publishers

Part II: Audience Analytics Lights the Data Leakage Fuse

Part III: The Cost of Data Leakage


The Cost of Data Leakage

If you are a publisher that depends on advertising dollars to fund your operations, data leakage is a critical threat to your bottom line.  If you remember nothing else from this post, remember this – data means audience, and audiences are what advertisers pay to reach.  If they can reach them without  buying expensive content adjacency, they will.

Reaching a specific audience used to be hard.  Really hard.  That’s not to say you couldn’t buy it – any number of vertical publishers were happy to sell you millions of impressions if you wanted, but needed deep pockets and what advertisers want most after reaching a target audience  is to scale it to the hilt for the lowest possible cost. Anyone who doubts that can look toward the meteoric rise of ad networks and programmatic exchange buying, which has rocketed to a double-digit chunk of the display industry spend in just over a year.  Cost is a major factor in driving that.

That’s not to say expensive sponsorships and content adjacency are stupid or a waste of money, far from it – but content adjacency is usually a proxy for an audience, reached at scale in an operationally efficient manner, in the right frame of mind to drive brand awareness and brand recall.  Splashy sponsorships and content adjacency are what we call top of the funnel strategies, and they are expensive because it is incredibly difficult to attract a large audience looking to research a certain brand of car, or an HDTV, or their 401K allocation.  Vertical sites can charge a premium because it is not easy to build a deep, engaged, and reliably large audience. Advertisers are very aware of this.

By allowing advertisers to cookie users via pixel fires out of an ad tag, publishers are enabling their clients and ad network partners to remove them from the value chain.  If an advertiser can build a cookie pool on a publisher’s audience, it can readily retarget that audience for a much lower cost on the ad exchanges by using either a DSP or an Ad Network.  From the advertiser perspective this is a great way to extend reach, lower costs, and drive ROI.  The benefits are so great that it would seem absurd not to try, as if the publisher had simply left an unattended briefcase full of money outside the agency’s door.  Publishers without a way to secure their data are pretty much asking to have their audience filtered away from them.

A cookie pool on the loose has a number of negative impacts – first, it erodes the value of the publisher’s audience by allowing advertisers to access it through cheaper channels.  Publishers make enormous investments in technology and quality editorial to attract their audiences, which eventually becomes a competitive edge.  There is a long list of vertical publishers that have cornered the market in their chosen topic over years of hard work, and a marketer willing to pay premium CPMs to reach that audience is the reward.  If the advertiser doesn’t need the publisher to reach that audience any longer, that audience is suddenly worth less.  The audience is everywhere, on thousands of sites.  It is no longer Publisher X’s Unique Audience, it is CookiePool123, it is a commodity.

Finally, from a technical perspective, data leakage potentially exacts a huge cost on your site’s user experience through page latency.  All those third party ad pixels take time to execute, and in many cases may not work through an iFrame tag, meaning they must finish before the page content can continue to load.  At 20+ms for each call in addition to the time it takes for your ads to load, it doesn’t take much to make for a sluggish site from the user perspective. Anyone will tell you slow pages degrade almost every major site metric, not to mention can have a significant impact on SEO rankings.  Chew on that for a bit!

So what can a publisher do?  Read Next – Managing Data Leakage and find out.

Audience Analytics Lights the Data Leakage Fuse

As data collection started to take off on the advertiser side, companies like comScore and Nielsen were simultaneously trying to do more and more to build a story around demographic behaviors online, which is a huge challenge because of how inherently fragmented the internet is vs. traditional media.  The standard model for those traditional media measurement companies is to set up a small panel, reach statistical significance for a few major publishers, and extrapolate the results into official ratings.  The smaller the panel, the wider the margin of error, but typically they can get within a few % points with just a few hundred people.  Sounds great, but on the internet there aren’t a handful of major networks with distribution to every home in America, there are a hundred million destinations with a wide range of viewerships, some quite minuscule, so sampling with a small group is impossible.  The result is a panel approach doesn’t really work all that well, as evidenced by the typically huge discrepancy in what publishers report as the number of unique visitors per month and what comScore might tell you.

Then, in 2006, everything changed when a few really smart guys founded a visionary company called Quantcast.  Quantcast’s history is critical to understand as part of the data leakage story because they were the first company to really get people thinking about the value of audience data and then make that audience data actionable.  While they didn’t invent the mechanism to build an online audience, they were the first to figure out how to build a system that could algorithmically tie demographic information to a specific cookie, keep the data current, and scale that service at scale on hundreds of millions of cookies. They accomplished all this by directly measuring audiences instead of using a small panel of users.  This is a standard methodology today – every data exchange currently in market (BlueKai, AudienceScience, eXelate, and others) relies on having a redirect to their cookie sitting on thousands of sites to help them build a cookie pool they can profile, but no one was doing it in 2006.

Quantcast was able to pull off direct measurement of audiences on sites they didn’t own through a unique data-sharing proposition to publishers – put a pixel on your site, allow Quantcast to cookie your users and they would give you demographic analytics on your site audience – free.  Or rather, in exchange for surrendering your rights to any data Quantcast could collect.  Publishers big and small signed up in droves and in a short while, Quantcast was measuring tens of millions of people on tens of thousands of sites.  This mountain of data allowed them to do really sophisticated audience modeling and infer demographic and psychographic characteristics at a cookie level.  After building a unique audience profile on each cookie, they could aggregate that data for the unique cookies on any given publisher and report accurate demographic profiles for any publisher.  It was the reverse of traditional media measurement – publishers contributed thousands of data points on each user rather than users contributing data points on the publisher, but this solved the fragmentation problem.  By building confidence at the cookie level, Quantcast could simply re-purpose the data they had on a cookie for whatever group they saw on a tiny publisher.  You could have a site with thousands of visitors a month instead of tens of millions and still have the same extremely accurate demographic reporting.   It was pretty slick stuff and so effective that eventually it forced comScore and Nielsen to start doing direct measurement as well.

Suddenly, people saw the power of the cookie.

So now, you had a company with a truckload of audience data on a huge majority of the US internet population, down to the cookie level, and you had a ton of advertisers looking to get those exact same audience metrics on their pile of cookies.  What a great coincidence!  Now advertisers could use the same technology and instead of (or in addition to) dropping their own cookie on a user, they could drop Quantcast’s cookie on that user and then access the same sophisticated audience metrics that Quantcast had collected from publishers.

While impressive as a new frontier in media analytics, it all came together when Quantcast figured out how to enable ad targeting on their cookie pools.  Through a simple tag integration with an advertiser and publisher account, Quantcast could actually pass a key-value into an ad tag and target an advertiser’s ads against their cookie pool.  True, explicit audience targeting was born!  The best part was that advertisers didn’t have to build that cookie pool on any specific publisher in order to target against it.  Advertisers could cookie the audience on a premium site and then target that audience on another cheaper site.  In fact, you didn’t have to build a cookie pool at all, Quantcast would just sell you a cookie pool with your choice of demographic data if you wanted.  You could even get really fancy and take a small, directly cookied audience and scale it up exponentially with a statistical correlation against the Quantcast database Quantcast called look-alike modeling.  Basically, Quantcast was able to look at a small group of cookies, figure out what was similar about them, and then find other cookies not explicitly cookied by the advertiser to scale that audience into a much, much larger cookie pool.  Again, this is a standard offering with most DSPs and data exchanges today, but unheard of a few years ago.  Audiences were now portable, and true audience targeting was born.

To be fair, it’s not like Quantcast held a gun to publishers heads, the publishers readily volunteered access to their data – gave it away even!  They got access to new analytics and pushed media management from a panel based system to a data-driven model.  Small publishers in particular, which comScore and Nielsen wouldn’t have bothered with got a big helping hand from Quantcast’s trusted, 3rd party metrics when trying to sell their sites.  And, if publishers wanted, Quantcast was more than happy to help them productize their inventory by demographic characteristics to sell directly to advertisers.  I’m not sure the digital publishing community ever really got on board with that concept, but the ad networks certainly ran with the idea and used it to differentiate and add value.  The point is that Quantcast isn’t a bad actor in the industry, rather they are an innovator, and trusted by plenty of major media companies on the buy and sell side.  But they had a foundational role in the mechanism that potentially puts a great many publishers at risk of commoditizing their audience.  Publishers have to start paying attention to the potential risks.

Quantcast’s innovations in the media measurement and data management space forever changed the value of data by making it actionable, and would soon spawn a number of competitors that sought to do the same thing.  Eventually, this data management space would collide with the ad network and ad exchange space and throw a bucket of gasoline  on the whole issue of data leakage.

Read Next – Understanding the Costs of Data Leakage