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


Leave a Reply

Your email address will not be published. Required fields are marked *