Formulating a Programmatic Buying Policy: Data Security

Addressing data leakage head-on

Making the dive into programmatic buying can be daunting, but a lot less so when fortified policies are in place. Below is an amalgam of how aggressive Media Trust clients in particular address ad quality and data leakage issues, split into four quality segments. 

  1. Ad Security
  2. Data Security
  3. Ad Quality – Brand safety and channel conflict management
  4. Traditional QA – Ad types, technical specification rules, site performance

2. Data Security – Showstopper?

Not defined by the media as a problem two years ago, data leakage has become the most complicated policy headache for most publishers we speak with. To be frank, we also know many publishers that choose not to have a data leakage problem by disregarding the concept entirely and that is OK too – if you fall into this category please skip this section. 

If this is your showstopper and you are having a hard time getting started, step back and take quick stock of what you are trying to accomplish. Start off by asking yourself these questions. 

1) Do I know what cookies and pixels are dropping on consumers visiting my site via direct and non-direct channels? 

2) Do I know what those pixels and cookies are doing and why they are there – can I separate out the presence of a domain that sometimes drops a cookie that collects data, and sometimes does not? 

3) Do I know the full chain of events that led them to my site enabling me to make the leap to enforcement? 

If you can say yes to questions 1, 2, and 3, then you can monitor any data leakage policy your legal team throws at you and move on to the final question.

4) If I have full transparency, do I have the courage and wherewithal to act on that information? 

If you cannot answer 1 through 3 in the affirmative and data leakage is a showstopper issue then you need to look for help from colleagues, your demand partners, or a vendor. There is plenty to discuss on latency and technical specifications in pixels, but if you take our advice you will leave that out of the data leakage problem and move that to quality segment 4, Traditional QA and Site Performance

After analyzing billions of publisher ad executions and web pages over the past few years a number of truths have become apparent. By impression numbers, the vast majority of non-house pixels and cookies dropping on most websites with medium to strong direct channels come from their direct agency relationships and not from networks, RTB, page content, or other third-party content. 

Unfortunately, the number of impressions counted for any given pixel is only useful as a tool for prioritizing which problems to address first. On the other hand, the largest breadth of unique pixels and cookies (by far) and their pathways to the site come from programmatic buying and traditional network relationships. 

Why You Gotta Make Things So Complicated?

This policy is as hard to write as your organizational requirements demand. The most complicated balancing act is maintaining enough flexibility to monetize RTB effectively while maintaining your policy. If your site has general or specific guidelines for data collection start there. 

Don’t complicate matters at the outset by incorporating special cookie relationships you have with large, direct advertisers. Stick with the basics. 

The two easiest policies to start off with are:

  1. We allow no third-party tracking on our site whatsoever, or 
  2. We allow any third-party tracking on our site. 

A slightly more open policy than no. 1 would be to allow third-party tracking if disclosed and approved ahead of time. If you are primarily concerned with protecting consumers versus protecting your ability to monetize your own data then another sample broad policy is to allow tracking code that meets OBA or country by country opt-out or disclosure requirements, but no others. 

Once you choose or are forced to leave the broad policy concept then you are moving into active flagging (white/black listing) specific potential for or presence of tracking code. This can be done at the vendor domain level, one step deeper at the domain host level, or all the way to the bottom, at the specific cookie/pixel level. If your policy is driven by flagging any of these specific data points you will be required to systematize the detection and notification for the presence of activity at whatever level you choose to enforce. 


The pros and cons of policy and enforcement at various levels of specificity are to numerous to discuss here. Ultimately, your policy needs to reflect your enforcement and remediation capabilities. If you state a policy, but can’t see the activity to enforce it, then your policy isn’t worth the paper it is written on. Here are a few pointers from your publisher colleagues.

First, data leakage monitoring in RTB cannot be done manually and written contracts stating that data collection is not allowed, though perhaps needed from a legal standpoint, do not enforce anything from the file cabinet. 

Second, data transparency and enforcement are not the same thing as OBA compliance and have little to do with consumer privacy notification on your site. Your policy should reflect your intention with consumers, but providing them with notice and opt out capabilities does not enforce your policy. 

Third, many exchanges, networks, and SSPs are working hard at policing data leakage and vendor presence as well. From everything we see, the middlemen and platforms are sincere in their efforts to meet your guidelines by dinging their partners every day for running undisclosed pixels and tracking code. It is assumed that publishers would act similarly in protecting their interests. 

Finally, when enforcing data leakage for any advertising on your site, direct or indirect, you need to know the ad that it ran with, the ad tag on your site that called the ad, the exchange partner that furnished the ad, and it certainly helps to know the origination point of the ad from above the exchange. If that information is not at your fingertips then remediating the problem is a bigger challenge.

Total time to write policy: half-day to one week.

Total time discussing policy with partner(s): 15-30 minutes per.

Set-up time: two days to one week.

Total time per week enforcing policy: Monitoring – less than 15 minutes per day; communicating with upstream partners – in your court, but typically less than 15 minutes per day.

Please also read Part 1, Ad Security, and Part 3, Ad Quality and Traditional QA.

OPS Macro-level changes are coming, and you can sieze the opportunities that follow at OPS NY. This event will bring together digital advertising leaders and ops professionals to discuss a rapidly evolving landscape and develop strategies for monetization. Register today for OPS NY which will be held Oct. 4, 2012.