EU Cookie Directive and your users

By Meriel Lenfestey

Cookies are technical solutions... but responding to the requirements of the EU E-Privacy Directive is not primarily a technical challenge. If organisations take steps to comply without due attention to the experience, the end users will go elsewhere.

Within organisations providing online services confusion reigns, and no one really knows how to proceed despite the fact that the law came into effect in May 2011. This is because most local attitudes to enforcement are still pending, and those who have decided are taking widely varying attitudes (e.g. UK vs. Netherlands).

No one is taking the lead in designing standard solutions for specific features or industries (aside from the behavioural advertising industry which had no choice), and it is unclear how much of the long term solution will be provided by browsers and platforms. In recognition of this, a grace period has been agreed during which the law will not be enforced whilst companies plan their solutions.

Developing solutions to the Cookie Directive

At Foolproof, we believe that being user centred is critical to developing good solutions. Here are some tips:

1. Put a project team together

Include user experience experts; remember – this isn’t just a technical and legal challenge.

2. Undertake a thorough audit of cookie use (yours and 3rd parties)

Include the following information:

  • Organisational description: e.g. to record display preferences, partially completed data, technical compatibility or previous visits
  • User benefits description (short): e.g. to remember your preferences for future visits, to retain your data and avoid making you retype everything again next time, to make you feel welcome when you arrive. Focus on the tangible benefit(s) the cookie is providing for the user, keep it short and in plain English
  • Technical information: when is it placed? How long does it last? Who provides it?
  • Importance: how important is it commercially? How important is it to the user experience?
  • Sensitivity: how invasive or sensitive is the data in the cookie? Who gets to see / use the data? What commitments are you making to user’s privacy?
  • Uniqueness: how ‘standard’ is this use generally or within your market / industry?

3. Quick Steps

A few simple steps will assist greatly in complying with the law ahead of the May 2012 enforcement whilst you work on full solutions.

  • Make sure your Privacy Policy includes references to cookies used on your site and consider adding a cookies page e.g. http://www.ico.gov.uk/Global/privacy_statement.aspx. Seek legal advice to make sure you are compliant.
  • Include a tick box in registration to gather consent from registering users. Store this consent in your member database.
  • Mail out to existing members to gather their consent by asking them to click a link to approve cookies.

4. Full Solutions

Develop a range of solutions appropriate to the service, customer type and cookie type. The optimal solution (and in some cases the level of enforcement) will be defined by:

  • The uniqueness of the cookie context
  • The importance in the customer relationship
  • Whether the user has specifically requested the associated feature
  • The market the service is intended for (UK only or broader)
  • The potential for privacy concerns / intrusion

You probably aren’t the only people trying to solve this for any specific cookie type. Developing a solution shouldn’t be an area where you look to gain competitive advantage (although doing so badly will give you a disadvantage!).

In the long run, a common solution is likely to provide the best user experience and indeed we believe that browser companies will build in solutions to make this the case. Work done now in the audit will assist with future developments if this is the case. In the shorter term, talk with others in your industry or elsewhere, who are tackling the same problem, to see if you can share the burden of design and development.

Any solutions which are visible to the end use MUST be framed in terms of user benefits and be placed in a susceptible moment – one where the benefits are tangible to the end user. They must not interrupt the user experience as far as possible, either remaining transparent, being passive or by being carefully placed and described.

We recommend avoiding the use of technical jargon (including the word ‘cookie’!). If a feature isn’t important in the customer relationship, but might be deemed sensitive then consider carefully whether it should be visible for all users. Importantly, you must consider how to manage a graceful UX degradation if a user refuses cookies.

In the UK, cookies associated with specific feature requests can be placed before the user is told unless the data is particularly sensitive. They can opt out rather than opt in. This fulfils the “informed consent” portion of the UK law. It may well be that a standard icon is developed to communicate this to users either within the web page or within the browser.

In some other EU countries, the user will need to consent prior to placement of any cookie. For most this could be a single catch all agreement in a registration process or on entering the site, but for particularly sensitive data, or for non-registered users, this requires either an interruption to the user experience, or a server based solution initially which delivers the requested feature and seeks permission to leave a cookie for future visits.

What do you think?