Look at the State of This Place
Navigate to almost any page of the web today, and you will be met with a modal pop-up, full of jargon-ridden text about cookies and links to privacy policies and terms and conditions so long that you couldn't possibly read and understand it all before consenting to the use of cookies. In the meantime, the site is visible through a semi-transparent layer covering the page, and by the time you've accepted all the cookies, you've forgotten just why you visited the site in the first place.
This is not a good user experience...
...And it's all over the web.
Why is it Even Like this?
The rules governing cookie consent are laid down in Directive 2002/58/EC of the European Parliament and of the Council - a long and difficult text, full of legalese that is as transparent as your cookie policy. Have you read it? I bet most people who implement these solutions didn't either - and those that have read it would have a hard time knowing what to actually do.
It's not surprising that most solutions are identical - who would want to read through and interpret such a text when they could just copy a "best practice" example and call it a job well done?
Beyond the confusion caused by the legal text, it's simply easier for the developer to package everything into a central, one-shot consent modal than to integrate a more user-friendly and sophisticated solution. Even easier is to purchase an off-the-shelf module and integrate that - and of course such a solution would not be architected in a sophisticated manner, tailored to your website, but rather in a way that makes it quick and easy for the developer to integrate - just add a javascript file to your page template, and a central, one-shot consent modal will solve all your cookie consent problems!
Finally, departments in companies often have competing goals that affect the choice of implementation. The revenues department may want to maximise advertisement revenue, so will want a solution that nudges the user to accept targetted ads from the first page-load, even at the expense of the overall user experience.
What each of these explanations have in common however is that they are focussed on making the company's life easier. To create a solution that makes the user's life easier, we need to understand what types of cookies exist, and what sort of consent is required.
The Four Cookie Types
We can categorise cookies in many different ways - duration, origin, function, etc. For our objective, we will split cookies up into four types by purpose.
Strictly Necessary Cookies
Cookies which are necessary in order for users to use the website. This includes features like user authentication and shopping carts. Normally, these features will be implemented using first-party session cookies.Preferences Cookies
Cookies for remembering user settings between sessions. For example: language and regional preferences or information for automatic login.Statistics Cookies
Analytics cookies used to harvest information about how users use a website - Which pages have they visited? Where did they click? Is this visitor unique?Marketing Cookies
Cookies which track the websites a user has visited in order to deliver targeted advertising.
Consent is not required for Strictly Necessary Cookies or Statistics Cookies, but the existence and purpose of the cookies should be explained to the user. For all other cookie types, consent is required.
A Solution
How could we structure a better solution? For Stricly Necessary Cookies and Statistics Cookies, my suggested solution is straight-forward - a link visible on every page called "Cookie Policy". This link will take the user to a page detailing what the cookies do, and why they are necessary, thus fulfilling the requirement to inform users. It could be in the nav-bar at the top of the page, in a side-bar, or at the bottom in your footer menu. The important thing is not the placement, but that it is clearly visible and accessible.
For Preference Cookies, I think we have a few options: requesting consent at time of use, requesting consent at login/signup, not saving preferences for non-logged in users.
Requesting consent at time of use can be achieved through a simple checkbox when submitting the preference or at first interaction, as appropriate. The label for the checkbox can link to the cookie policy for that specific cookie or a more general policy. It might become annoying for the user to constantly tick checkboxes for every preference setting widget a website has, but to be perfectly honest, I'm having a really hard time coming up with a use-case for a preference that I would want/need to persist across visits. Answers in the comments below?
Not saving preferences for non-logged in users is pretty straight forward, and we can use techniques from the "old" web (query string params, anyone?) to persist across pages, but not across visits.
Requesting consent at login is also pretty straight-forward and trivial to envision. We could employ the same check-box and link in label solution for requesting consent at time of use, or we could take today's modal popup and cram that into the sign-up/account setup page.
The real problem (and the real reason for the ePrivacy Directive) is Marketing Cookies. This is why you're getting the big modal popup - so that the website can make more money from adverts that are targetted specifically at you.
We've already discussed an unobtrusive way of requesting consent from users with an account. This method can be used in this case alongside a time-of-use consent mechanism. Near any advert a user sees, we can place a button that says "Show me relevant ads", with a link to our cookie policy beside it. When the user clicks the button, they consent to the site's marketing cookies. Users who don't/haven't yet consented can be served adverts based on approximate location.
Yes, I know, your colleagues in ad revenues will be upset that they don't pay as well as targeted ads. But do you what pays even better? Actual brand deals. They require no cookies, no tracking, no targetting, and will earn you more! This is what youu say when the ad revenues department complains.
High-Five
We've solved this now, I guess? Well, we've solved part of it. I think. It sure sounds nice - visit a website, only consent to what you want to, when you need to by checking a few boxes or at signup. Turn on targetted ads if you like, or get adverts for your local area restaurant if you don't. So what's missing?
We've only really solved the user experience. We haven't solved the other problem I mentioned at the start of this article: privacy policies and terms and conditions so long that you couldn't possibly read and understand it all before consenting. And if you haven't read the terms and conditions, can you actually give consent? In common law countries the standard isn't even consent, but informed consent. So the answer is no.
Until companies write their cookie policies in such a way that you don't have to be a lawyer on a four week holiday just to understand them, the UX part is the only part developers and UX specialists can solve. Let's not rely on store-bought cookie-cutter solutions, but bake something better; something more elegant, less obtrusive, and delivers a world class user experience.
Top comments (1)
Great article and as an internet user I really appreciate that you're trying to put the user's needs into the equation somewhere.
Personally, I like the cheap cookie-cutter solutions because with one or two right clicks I can block the annoying consent popups and that silly tinted overlay. That is usually enough to view whatever page I'm trying to see and if it doesn't work I simply write the site off and never return to it.
In my opinion, I shouldn't have to click anything to decline unnecessary cookies. Places that insist on wasting my time with unnecessary things don't deserve my time or clicks. If some ad team doesn't understand that, well, then that is a good example of why the ad-based revenue model is outdated and should be pushed to the grave as quickly as possible.