The 10 Step Graduated Approach to Cookie Compliance

As the May 26th Cookie Law compliance deadline fast approaches many companies are starting to panic a little at the prospect of unleashing something so potentially disruptive on their customers. Indeed, simply putting a prompt to consent on your website without warning will likely loose you a few customers. But this doesn’t have to be a “rip the plaster off quickly to get the pain over with” endeavour, in fact it may well benefit you to do the opposite. The ICO acknowledges the fact that having a fully functional solution up and running on May 27th may prove a challenge even with the greatest will in the world. A phased approach is perfectly valid assuming you can produce serious plans for following through on this.

So in that spirit, here’s my guide for a graduated approach to cookie compliance. The idea is that you guide your existing users into expressing their consent with more gentle methods before unleashing the more intrusive ones. You don’t necessarily need to implement all these steps, and perhaps a slightly different treatment of the same approach will work better for your business, but adhering to the spirit should minimise the impact to your business while staying on the right side of the ICO.

1) Audit your cookie usage and make a hitlist of cookies you don’t absolutely need

Make sure you know exactly what cookies you’re using, what they’re used for and what use they are to your business. There are various tools and services out there to help you with this.

Any cookies you don’t need should be removed before implementing any compliance solution – you really don’t want to bother your customers about cookies that you don’t use or don’t really need. Deliver this list to your tech team and have them remove the offending cookies.

2) Update your privacy policy

Update your privacy policy stating your intended approach to the cookie law. State clearly what cookies you are using and what they are used for. Set out your schedule for compliance and explain your reasons for doing what you are doing. Transparency is the key here. Be honest about what you’re doing, and include your overall approach stating your reasons for doing it this way

3) Contact your users and tell them what’s happening

It’s now time to start informing your users as to what you intend to do. This is your opportunity to educate them on the purpose of the much maligned cookie and state your case as to why you use them. Forewarned is forearmed, so when users turn up at your site and are given the opportunity to state a consent preference they’ll already know what it’s all about and won’t be baffled into any rash action.

You could do this by way of an email campaign, or perhaps part of an existing newsletter or on your company blog or all of these. Perhaps your site has internal messaging system that you could use. The idea is to make the user feel like you are coming to them proactively rather than just springing the whole thing on them. Collect data on open rates and clickthroughs to the landing pages which contain your messaging and use this to gauge interest.

You may also want to consider briefing your customer service teams so that they are fluent in the rudiments the cookie law and your approach to it. Use this an opportunity to gauge sentiment about the issue.

4) Implement a solution that allows users to opt-out of cookies without explicitly prompting for consent

Construct a page or area of your site where you can direct people where they can adjust their consent preference. This could be in the user’s profile settings or a simple stand alone page that drops a cookie to remember their preference. At this stage you can default this to ‘opt-in’. If you’re planting a cookie to remember a user’s consent preference then make sure you tell then that this is what you’re going.

5) Use on-site messaging to bring user’s attention to your changing policy

Make the link to your privacy policy more prominent on your pages, and use banners or information boxes, even javascript pop-ups to bring your users’ attention to your evolving policy and direct them towards your consent page. You may want to construct a suite of imformational pages that are softer, friendlier and clearer in message the the traditionally formal privacy policy. The idea is that your message should be easy to understand and palatable. Think of this as a marketing microsite.

6) Implement a option to consent at account sign-up

Take this opportunity to use this softer consent prompt for new users signing up for your service. This way you get their preference early in the customer’s lifecycle with minimal intrusion. Most internet users will have been presented with something similar in the past to opt-in or out of email marketing, so this will be a familiar action to them.

7) Place an on-site icon that directs users to a page where they can read about cookies and state their consent preference

Short of displaying an intrusive option to consent banner or lightbox, employ the  more subtle option of using an icon that users can click through on to adjust their preferences or find out more information. This can either be built into the structure of your page or as a ‘floating’ icon that sits in the corner. See CookieQ and Cookie Control for examples of how this can be done.

8) Record and analyse statistics relating to consent preference

All this so far has been about easing you users into the brave new cookie compliant world. You’ve not been shoving it down their throat, but are they actually paying attention? Whatever you do next needs to sensitive to how the users have reacted to what you have done so far. There are a few areas you can take a look at to understand how the users are reacting to the changes so far.

i) Survey data – this will be a vital source of information to understand user sentiment and any practical considerations. Even better if you can put some specific cookie related questions in there.

ii) Opt-in/out volumes – when the customer chooses their consent preference you should be able to register this server side. What we want is the rough volume of your user base that opted in, out or failed to set a preference (yet). The opt-out volumes help us gain a feel for the potential impact of the changes on our ability to measure our customer behaviour, but it’s the ‘no preference set’ group that is most interesting at this point. This tells us how hard we need to go with the next phase. If most users have expressed a preference then we can probably get away with a pretty gentle approach to gaining consent from the rest. If people really haven’t been going for it then we’ll need to be a bit more brutal. If at this stage you can segment these groups by new/existing/signed-up users then even better. Understanding how the different groups are behaving will give us a vital indication as to how to engage them further on.

iii) Clickstream data – you need to understand how users who saw your cookie pages found them and what got those who expressed a preference to do so. Above I outlined various mechanisms for driving users to you information and consent pages, but which ones of these are most effective? Which paths got users to make the effort to express consent? More importantly, what paths lead to an opt-in preference? Via your privacy policy? Maybe via a more friendly splash page. This is going to help you understand the best way to get the result that you want when you unleash your fully compliant solution.

You should set up goals or events in your web analytics to track this. Remember, you’re not claiming to be fully compliant at this point and you’re implying consent until a user specifically opts-out, so it’s valid to still be measuring them at this point until they explicitly opt-out.

9) Implement clear prompt to consent only for new users or those who have not yet stated a preference

So now you know what sort of task you’ve got ahead of you and how your customers reacted to various consent mechanisms and information, you can design a consent solution that’s optimal for your user base. You’re really just targeting new customers or those who have yet to express a preference. From here on we throw ‘implied consent’ out the window and we need to coerce users into setting a preference as soon as they arrive on the site. It may be that you treat new and existing customers differently. Your privacy policy and consent preference icon should still be available and prominent for customers who have already stated their preference.

10) Full compliance!

Having done all of that you should be most, if not all of the way to being cookie law compliant. Having eased your users into it you have ensured that they are neither surprised or confused, and hopefully got them to opt-in.


You could take up to 6 months to complete this phased roll out. Although the list is broadly sequential, items 2 – 7 can be run simultaneously to save time. This middle section really needs to run long enough to get a feel for how things stand with your users and to achieve maximum awareness and consent uptake with your existing user base.

There are probably many different ways of implementing the graduated approach, but the key point is, you don’t have to rip the plaster off all at once, as that’s unlikely to help anyone, least of all your customers.

Why the DO NOT TRACK header doesn’t solve the Cookie Law problem for businesses

Last week Vice President of the European Commission Neelie Kroes released a statement of emphatic support for the ‘Do Not Track’ (DNT) cookie header proposal. The HTTP header, which is currently patchily supported (IE9, Firefox 4+ and Safari), would, via the user’s browser settings, indicate a yes/no preference as to whether to track their session while on any given site. This, of course, is just a simple header, and for it to have any effect the websites themselves will need to implement functionality to recognise the header and act upon it accordingly. With the potential of having the weight of the law behind it, and the mounting pressure for European businesses to comply with the so called ‘EU Cookie Law’ some are seeing this as the ultimate solution for businesses wishing to comply with the law and users’ privacy concerns. However, it’s not that simple. Here’s why:

1) The solution needs widespread adoption – businesses need to adopt this standard wholesale, and the big players need to take the lead. Without widespread adoption the standard will be worthless and users simply won’t bother with it. Given that it will take a while for businesses, large and small, to adopt this, the May 26th Cookie law deadline will have come and long gone by the time they do, and many businesses will have to have implemented other solutions.

2) What if the user hasn’t touched or isn’t aware of the setting? In the current proposal there is no mention of a ‘no preference expressed’ type option. Given that legislation will likely urge the browser manufacturers to default to an opt-out status, then the VAST majority of users (at least in the early days) will be ‘opt-out’ and so any business following this particular consent route will be hobbling themselves out of the starting blocks. Even if there was a ’no preference expressed’ option then, again, if following the spirit of the law, you must assume no consent. Businesses are better off using more forthright methods to get unambiguous consent which will surely result in a higher uptake of opt-ins, because you’re able to give the users much more information and reassurance. You’ll also be able to tailor your message to suit your website’s specific needs or perhaps even get more explicit, detailed preferences about specific types of tracking.

3) Do not track what? There are no clear guidelines on defining what should or should not be tracked for users who have opted-out of tracking this way. Only 1st party tracking allowed? Google Analytics but not Doubleclick advertising? Tracking for recommendations but not web analytics? The ICO guidelines are currently an amorphous, non-committal mess of easy options and ‘get out of jail free’ cards and are spectacularly open to interpretation. If everyone is implementing different rules, then how can the users have confidence that their wishes are being followed?

4) It offers the user very little control – Being a web analyst and painfully aware of who or what is watching me, I can actually be quite specific about what I’m fine with and what I’m not. I’m happy with sites tracking me with GA, but take exception to invasive click tracking technologies. Some users may be happy with sites tracking them for recommendations but object to being watched for 3rd party advertising purposes. Groups that understand this stuff well enough to express a clear and informed preference are few and far between, but on the other hand, a Joe Bloggs user who opted-out in good faith may be somewhat disgruntled to find that his favourite e-commerce site is no longer showing him his ‘recently viewed items’ because he did this. Complicated browser preferences are not the answer here, but rather a richer, common sense set of options that are less brutal than a blanket yes to everything or no to everything (whatever ‘everything’ actually means).

5) We are not educating the user – There are many different types of and uses for tracking, some more legitimate that others. However, there’s already a growing culture of fear around tracking and most specifically the harmless little cookie, so much so that, in some people’s mind, they are evil, intelligent robot-viruses that will destroy your computer and publish naked pictures of you on the web. There’s little chance that browsers will annotate their settings with a discourse on the relative benefits and pitfalls of cookies or tracking, and even less chance that the users would actually read such a thing. So relying purely on browser settings means that you miss out on a vital opportunity to connect with the users, set the record straight, and show that you’re a trustworthy and caring business. Not only will you strengthen your relationship with the customer, there’s a higher chance that they’ll actually opt-in.

What all this adds up to is that businesses will not be well served to rely on the DNT standard alone, they need to connect with their customers on this issue for the benefit of both parties. So waiting around for a silver bullet that isn’t really a silver bullet is not really an option. Act on this issue now for the benefit of your business and its customers.

Strategies for tracking web and mobile apps with Google Analytics

Since its conception, the discipline of web analytics has been concerned with page views as the most atomic form of transaction. For many years this worked just fine in the vast majority of cases. However, with the advent of rich web applications, augmented by asynchronous methodologies such as AJAX, which use remote Javascript and  remote web services to update pages without a full page refresh, the pageview model has long been under pressure. How do you track actions on a page which doesn’t refresh when actions are performed on it?

Thankfully for Google Analytics users, this issue was addressed some time ago with the advent of ‘events‘. These were designed for capturing things that happen on the page that didn’t result in a page refresh, the classic example being someone playing (or stopping) a video. This seemed to do the trick for most applications for a while. But many modern sites revolve around single pages that rarely, if ever, refresh. Think of the Twitter and Facebook feed pages – they automagically grab new updates, and authoring of updates or comments are written and submitted entirely in-page. In Google Analytics you could mark each of these as separate events, but are they really ‘events’? Events are something that mark a specific moment, something of importance. You can easily segment by them, and they have a richer set of data associated with them (for example, you can associate a monetary value with them), but you can’t use them in any of the pathing type reports (either as in Conversions or the Navigation Summary you can get from Pages reports). They weren’t designed to be considered part of a flow, they are one off things that could happen anywhere.

But think about the Facebook ‘Update Status’ action. The action of updating the status itself could be considered an event, but in many cases there’s a process to it: click into the box -> write something -> add a photo (optional) -> change who can see it (optional) ->  add a person who you are with (optional) -> (a load of other optional actions) -> Submit.  Other than the first and last, these actions can happen in any order and are optional. If all you chose to do was register the ‘post new status’ event, you’d be hard pushed analyse users’ behaviour leading up to it in any meaningful way. If you tagged all of these as events, you’d not be able to see how one flowed to the next.

So what’s the solution to this? Well, back in the dark ages of the internet (5 or more years ago) these actions would simply have been new pages with form fields and submit buttons, so measuring them would be simple. But have things really changed that much? Arguably these actions are simply a more atomic analogue of a page view, and thus should be recorded as such. By setting each of these as a ‘pseudo-pageview’ (by firing _gaq.push(['_trackPageview', '/some/fabricated/url/']); ) then you get the full richness of pathing that you need. So now our flow would look more like this:

page 1: /feed

page 2: /feed/initiate_comment

page 3: /feed/add_photo

page 4: /feed/submit_comment

page 5: /feed


You could register any of these as an event as well if you want any of that functionality to track an action in more detail.

Sure, this will inflate your pageviews dramatically, but on a site where all the important stuff happens in page, who gives a damn about pageviews? Management are going to care much more about ‘likes’ and ‘status updates’. That said, there’s an easy fix for this by constructing your pseudo-urls with a common prefix denoting them as such, which will allow you to filter reports (using regular expressions for example) on a common pattern and get reports for real pageviews (or pseudo-pageviews) only.

The exact same logic applies to mobile apps that use remote web services. Simply break your application up into logical flows and assign pseudo-pageviews for each of the steps. If you have a both a web and mobile application, be sure align your stages where it makes sense to do so (events will more than likely be exactly the same across device so make sure these are aligned too). If both groups of data are going into the same profile then you’ll need to differentiate the urls to indicate which source they came from (something like /mobile/feed/add_photo and /web/feed/add_photo). This is so you can segment your reporting to get data for each individual platform.

The key to doing this well is in taking an organised and methodical approach to constructing your pseudo-urls so they are both human readable and represent a logical structure for reporting. Getting this badly wrong will make reporting needlessly difficult so it’s really a job for the analyst to design the structure rather than the techie implementing the actual code.

Analysing web and mobile applications isn’t easy and will challenge your closely held methodologies, but it’s a surmountable task if you break your experience down into logical chunks and analyse closely what’s important to you about each of these. This will help you understand how best to implement your web analytics in a way so as to get the best data about usage.

EU Cookie Law – burden or bonus?

YESThe EU Cookie Law is going to be a pain the proverbial for most companies, and one that was unplanned and unbudgeted for, which could have some undesirable consequences. However, that doesn’t mean that the situation without merit or opportunity.

A sensible organisation is already preparing for May 26th 2011 – finding out what tracking is important, and what, financially and operationally, this is really worth to them. If accurate user tracking is something your company simply cannot live without, it’s worth investing in, right? So why not use it as an opportunity to engage your customers, educate them about cookies and tracking and why you need them, and how you are careful with their data. Show them that you are a trustworthy company that cares.

So now they know what it’s all about, why not give them an incentive to hit the big YES button. Consider schemes whereby you give your customers something in return for consenting to tracking. Perhaps this is a voucher or discount, an offer or free extended trial on a premium service, some cashback, whatever it takes. It’s a small price to pay for this vital information right? And if do this well, then you may manage to convert some customers to advocates and premium users.

My advice is, stop hoping the Cookie Law will go away, and start thinking how you can make it work for you.

EU Cookie Law – it ain’t all about cookies (or browsers)

I am not alone…

This may come as a revelation to you, but the “EU Cookie Law” does not explicitly mention cookies (or to be more precise, the wording and subsequent amendment to the EU Privacy and Electronic Communications Regulations 2003 regulation 6, that is being widely referred to as “The EU Cookie Law” doesn’t). It also only makes a brief mention of “internet browsers”. At a cursory glance it doesn’t mention anything much at all, it merely alludes to various things, using generic legalese statements. This is very deliberate – the law relates to end-user’s privacy and aims to prevent you snooping on your customers while they use your website, app, widget or whatever other electronic method you are employing to get your message across, without asking permission to do so first. They’re not specific about the exact mechanism employed to track said user, they don’t want you doing it whatever the method. They’re not specific about the type of device, they mean any networked device, using whatever protocol. The EU Directive states:

6 (1) Subject to paragraph (4), a person shall not store or gain access to information stored, in the terminal equipment of a subscriber or user unless the requirements of paragraph (2) are met.
(2) The requirements are that the subscriber or user of that terminal equipment–
(a) is provided with clear and comprehensive information about the purposes of the storage of, or access to, that information; and
(b) has given his or her consent.

(3) Where an electronic communications network is used by the same person to store or access information in the terminal equipment of a subscriber or user on more than one occasion, it is sufficient for Version 1 09/05/11 the purposes of this regulation that the requirements of paragraph (2) are met in respect of the initial use.
(3A) For the purposes of paragraph (2), consent may be signified by a subscriber who amends or sets controls on the internet browser which the subscriber uses or by using another application or programme to signify consent.
(4) Paragraph (1) shall not apply to the technical storage of, or access to, information–
(a) for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
(b) where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user

The ICO’s interpretation of this states:

The law which applies to how you use cookies and similar
technologies for storing information on a user’s equipment such as
their computer or mobile device changed on 26 May 2011.

The Regulations also apply to similar technologies for storing
information. This could include, for example, Local Shared Objects
(commonly referred to as “Flash Cookies”).

As you can see, the law refers to generic methods of storing or accessing information stored on the end users “terminal equipment” ie. PC, laptop, smartphone, tablet, ZX Spectrum 48k etc. This aims to prevent you from identifying an individual using some sort of identifier stored somewhere on a user’s, errr, device. The obvious and common way to do such a thing is using cookies, but this also encompasses Flash Local Stored Objects, HTML5 Web Storage and Web SQL Databases, IOS SQLite DB’s, even ID’s passed in the URL query string. Whatever client side method you use to identify and track a single user requires their consent prior to employment.
Strangely, this doesn’t appear to include server side tracking methods, for example weblogs. True, this isn’t a very accurate or efficient way of tracking your users, but it’s certainly better than nothing at all, and can be reasonably representative (I’ll talk about this more in later articles).

So everyone’s carping on about cookies, and rightfully so, they are the main thing that the EU Cookie Law is concerned with. However, the legal eagles at the EU have tried to make the law as future-proof and all encompassing as possible, so don’t think that just because your not using cookies, or your services is not-browser based, that you get away scott free.

Businesses, you need to start educating your customers about cookies, now!

Governments and legislators are particularly talented at bulldozing through clumsy, ill-considered laws when it comes to technology. More often than not, their heart is in the right place, even if their logic is flawed. This is the case with the EU Cookie Law, which is in danger of collapsing under the weight of its own ineptitude and ambiguity. However, this doesn’t that a) the law is without merit, or b) should be ignored.

As we’ve seen with recent scandals relating to a certain, now defunct, UK newspaper, personal privacy is something the general public take VERY seriously (even if the ever resourceful British press are amping the hysteria surrounding the subject up to #11). OK, so hacking someone’s voicemail, however easy this is, is somewhat more unethical and seedy than tracking your customer’s browsing habits on your own site, however, individuals have the right to be made aware that this is being done, even if it’s for perfectly good reasons.

Currently, the only folks paying the slightest bit of attention to the EU Cookie Law are the ICO (Information Comissioner’s Office) and the web analytics community (who’s very trade is at stake here). However, this is a pretty invasive piece of legislation that will not only make life very difficult for businesses on the web, but will also affect consumers as they browse the web. At some point, as we approach ICO’s May 2012 deadine for compliance, this is going to hit the public domain (I can see the Daily Mail headline now: “Immigrants are spying on you while you browse the web”) and hysteria will ensue. Rest assured, this isn’t going to go away, or fizzle out, the EU Cookie Law is here to stay.

What heppened to tracked traffic when ICO implemented int Opt-in/out mechanism (via Techcrunch)

Now, the preferable solution to the problem of cookie opt-in/out for businesses is likely to be a browser based mechanism, which will be supported by ICO. However, for this to have any effect whatsoever then consumers are going to need to be educated on what to do to protect their privacy. As ICO’s experiment on opt-in/out proves, people are quite reactionary when it comes to privacy, but why? Anonymous, aggregated monitoring of web traffic can only be a good thing for consumers. It’s because they aren’t educated on the basics of what tracking cookies do, all they see is “cookies = evil”, a myth that ICO need to do a LOT more to dispel. However, businesses shouldn’t leave it to ICO to educate their customers, indeed ICO’s clumsy and simplistic handling of this law has thus far proven needlessly disruptive. If you want to continue to provide the optimal experience for your customers post May 2012 then you need to start talking with your customers about cookies and why they aren’t so bad. The message will take a while to sink in, so start doing this now.

How should you go about this? Here’s a few suggestions:

  • Blog about it. Tell your customers about the EU Law, and explain what cookies are and tell them how you currently use them. Explain to them why this is a good thing. Be clear about what data you collect (via your shopping basket or whatever) and how that data is segregated from you web analytics data. Give them examples of how web analytics data has been used to improve their experience.
  • Update your privacy policy to be explicit about what tracking technologies you use and why. Get the link to your Privacy Policy out via your social media channels
  • Train your customer service and social media teams on what cookies are and what you are using them for. Converse with your customers about this, be open an ready to answer all their questions and concerns
  • Put something in your email newsletter
  • Get your key advocates bought in. Hold a webinar on the subject and get them talking about it.

Of course before all this you need to get your policy straight, and relevant pre and post May 2012, then get everyone in your organisation bought in – if your message in inconsistently delivered then this could lead to a PR disaster. If you’re not actually acting on the law now while you wait for clearer direction from ICO, which is a perfectly reasonable course of action, then state this clearly.

It’s up to you to make sure that the Cookie Crunch doesn’t end in a Cookie Crisis, don’t wait until it’s too late.