Author: Zoe Shuttleworth

On the 14th September 2019, PSD2 comes in to force. If you receive payments online from your customers, you should understand what changes to expect, and whether or not action will be required on your part to comply with the law and to avoid significant loss of income.

Let’s start with a little glossary

PSD2
The Revised Payment Services Directive is the second iteration of the ‘Payment Services Directive’ (PSD), a European Union (EU) directive first introduced in 2007 to regulate payment services and providers. The directive was introduced to break the banks’ monopoly on payment services, encouraging innovation and improved security.

SCA
Strong Customer Authentication is essentially the same as the Two Factor Authentication you may already be familiar with if you have ever had to receive a code by email or SMS in order to log in to an online service. Its purpose is to improve security by requiring two of the following three things:

  • Something the person knows (such as a password)
  • Something the person has (such as a mobile phone or device)
  • Something that the person is (such as a fingerprint or their face)

3DS2
3D Secure is a term used to describe additional authentication during an online payment. You may remember when 3D Secure first appeared in 2001 as “Verified by Visa” and many online card payments required a password? The interruption to the checkout process was hugely disruptive – damaging to businesses and frustrating to customers, but merchants were obliged to implement it or risk not being protected against fraudulent transactions. 3DS2 aims to address many of the shortcomings of 3D Secure 1 by introducing less disruptive authentication and a better user experience.

Frictionless Authentication

3D Secure 2 allows businesses and their payment provider to send more data elements on each transaction to the cardholder’s bank. This includes payment-specific data like the shipping address, as well as contextual data, such as the customer’s device ID or previous transaction history.

The cardholder’s bank can use this information to assess the risk level of the transaction and select an appropriate response:

  1. If the data is enough for the bank to trust that the real cardholder is making the purchase, the transaction goes through the “frictionless” flow and the authentication is completed without any additional input from the cardholder.
  2. If the bank decides it needs further proof, the transaction is sent through the “challenge” flow and the customer is asked to provide additional input to authenticate the payment.

Although a limited form of risk-based authentication was already supported with 3D Secure 1, the ability to share more data using 3D Secure 2 aims to increase the number of transactions that can be authenticated without further customer input.

Example flow of authenticating a payment using 3D Secure 2 with fallback support for 3D Secure 1

Frictionless Authentication

Even if a transaction follows the frictionless flow, your business will benefit from the same liability shift as for transactions that pass through the challenge flow.

Better user experience

Unlike 3D Secure 1, 3D Secure 2 was designed after the rise of smartphones and makes it easier for banks to offer innovative authentication experiences through their mobile banking apps (sometimes referred to as “out-of-band authentication”). Instead of entering a password or just receiving a text message, the cardholder can authenticate a payment through the banking app by just using their fingerprint, or even facial recognition. We expect many banks to support these smoother authentication experiences with 3D Secure 2.

The second improvement in user experience is that 3D Secure 2 is designed to embed the challenge flow directly within web and mobile checkout flows—without requiring full page redirects. If a customer authenticates on your site or webpage, the 3D Secure prompt now by default appears in a modal on the checkout page (browser flow).

Source: Stripe – https://stripe.com/en-fr/guides/3d-secure-2

How does this affect you and what actions are required of you as an online merchant?

As always, this depends on the platform that you use to sell online. The chances are that you will only have to take any significant action to comply with PSD2 if you host your own website (e.g. WordPress). In most other cases, it will be the responsibility of the website service provider to update their payment processes, and many have already done so. Your responsibility is only to check that the payment processing will be compliant. You can usually do this by browsing their forum or by asking their support team. A few examples include Squarespace, Wix, Shopify, Big Commerce, Etsy, eBay, Amazon, Eventbrite.

If you have a web hosting package and accept payments via a WordPress website for example, you will need to establish what payment gateway you use to receive the payments and if it has been implemented in a compliant way. At time of writing, Stripe are ahead of the curve, and the official Stripe plug-in for Woocommerce is already compliant. Do check your own implementation is up to date and compliant. If you use any PayPal off-site payment methods, no changes should be required as the payments are not processed on your website, but at present (5 August 2019), PayPal Pro (on site payments) is still not compliant.

 

As web users, we all know the frustration of a slow website. As our IT infrastructure has developed to allow many of us access to super fast broadband, the web has responded with a proliferation of rich media such as videos, large images and interactive websites. We have become accustomed to consuming this glorious abundance of media unhampered by frustrating delays, so when a click takes several seconds to deliver the expected results, we give up and click elsewhere.

As website owners, our users’ experiences on our website can have a direct and quantifiable impact on our business, and a sluggish website can be very damaging.

What are the causes of a slow website?

There are many factors that influence the speed of a web page. Among these are:

  • The visitor’s internet speed and their geographical location relative to the server your website is hosted on.
  • The size in Kilobytes or Megabytes of your web pages – this is the sum of all of your media files such as images and videos, plus all of your scripts such as JavaScript and CSS.
  • How many times your database is queried in order to display the web page in full.
    The configuration and power of the server that your website is hosted on.
  • Caching – whether the visitor’s browser has to ask the server individually for each element on the page, or whether these have been saved somewhere (including in the browser itself) for quick access.

As a website owner, the factors that you can control will depend on the platform used to build your website, the hosting environment and the technical expertise of those who maintain the website and its hosting environment for you.

If your website is hosted by a platform such as Squarespace, Shopify or Wix for example, you will be dependent on the platform to provide many of the tools required to ensure optimal performance. And on the whole they do. It is in their interests, not just to provide you with good service, but to minimise the load on their own servers. If your website is self-hosted (perhaps you have a WordPress site for example), you are much more likely to encounter problems with the performance (speed) of that website and to require the help of a developer and/or a good web host to achieve acceptable results.

Why does it matter?

Let’s take a look at some statistics*.

Back in 2007, Amazon discovered that every 100 milliseconds of latency cost them 1% in sales. In other words, for every extra tenth of a second their website took to load, they lost 1% of sales. At around the same time, Google discovered that by taking an additional half second to return a page of search results, they lost around 20% of traffic.

10 years later, in 2017, Akamai Technologies (a global leader in content delivery networks) published a report that suggests, not surprisingly, that those figures are now even more dramatic:

  • A 100-millisecond delay in website load time can hurt conversion rates by 7 percent
  • A two-second delay in web page load time increases bounce rate (when a visitor only views a single page and then leaves the website) by 103 percent
  • 53 percent of mobile site visitors will leave a page that takes longer than three seconds to load

Conversion rate

Whether or not sales are made directly on your website, the purpose of the website is most likely still to achieve a “conversion” of some sort. This may just be to give a visitor the information and positive impression they require to prompt them to contact you. If your website is slow, your conversion rate is certain to suffer.

Search Engine Optimisation (SEO)

While it has been a factor in Google’s ranking algorithm for many years, page speed is becoming more and more important for SEO year on year. This is largely in response to the increase in mobile search traffic, with mobile device users often hampered by slower download speeds and data usage restrictions.

Cost

Though the majority of small, low traffic websites on shared hosting packages may never approach the limits of the resources available to them, those that do may be forced to upgrade their package. Larger, more resource intensive sites will often pay directly for the bandwidth and server space they consume. In this case, optimisation will have very direct cost saving implications.

* https://blog.gigaspaces.com/amazon-found-every-100ms-of-latency-cost-them-1-in-sales/

What can you do about it?

1. Factors that you can’t control

Visitor’s internet speed – while many of us enjoy internet download speeds in excess of 10MB per second, a huge number are still stuck below 1MB some or all of the time. This may be wifi users at peak times or in remote locations, or it may be mobile users on a poor 3G network. As a website owner, you can either accommodate these users by ensuring that your website loads quickly, or risk losing them to a competitor, who is only ever a click away.

2. Factors that you can control, regardless of your technical ability

The size of your web pages – on most websites, the biggest drain on bandwidth and hence the main cause of slow loading is too many oversized and unoptimised images.

The file size of images is measured in Kilobytes (Kb) and is influenced by the file type (eg. JPEG, PNG, GIF), the dimensions (width x height in pixels) and the compression. Compression particularly applies to JPEG files, where the compression is represented as a percentage of quality, with 100% being not compressed at all. We optimise images for the web by finding the balance of these factors that allows us to display the image with the smallest possible file size and the least possible compromise to its visual appearance.

File type
In general JPEG is the best file type for complex images such as photographs, and PNG is the best choice for simple images such as logos, anything with a transparent background, and illustrations with very limited colours. Saving a photograph as a PNG can easily double the file size. It is not a common problem, but worth noting that JPEG images on the web must always have the correct colour space – RGB. CMYK colour space is used only for commercial printers and results in much larger file sizes as well as strange, excessively bright colours when used on the web.

Dimensions and compression
Typically, a JPEG image downloaded directly from a digital camera will be far bigger and of far higher quality than required for display on a website, and can easily have a file size in excess of 4Mb (4000Kb). There are no situations that I have encountered where an image should be more than about 2000px in width or greater than 80% JPEG quality. This should give the image a maximum file size of around 500Kb. Even 500Kb is a large file in web terms, and should ideally be the only image of its size on the page, with others kept well under 100Kb if possible.

The tools
Almost all desktop computers come with basic image management software that will allow you to control the format, dimensions and compression of your images. For Mac OS, you will find the Preview app has all that you need, and on Windows, Microsoft Paint should be able to do the job.

Alternatively, there are free online tools such as BeFunky (https://www.befunky.com/create/)

TinyPNG (https://tinypng.com/) is a great free service for compressing JPEG and PNG images. Their clever tool has been used to create all kinds of third party software to allow you to automate your image optimisation, either on your computer, or as you upload to your website, so you only have to think about the file dimensions. https://tinypng.com/third-party

3. Factors that may require technical support to address

If your images are optimised, but your website is still slow, the culprits are likely to be too much complexity in your website, and/or an unsuitable web hosting environment.

Themes and Plug-ins
Most self-hosted websites these days are built using WordPress, or a similar content management system such as Joomla or Drupal. All of these are fairly simple and lightweight applications when first installed, but their great strength lies in the mind-boggling array of ways in which we can enhance their appearance and functionality using themes and plug-ins.

Understanding how plug-ins can affect your website performance

  • The majority of plug-ins you add to your basic installation will add some overhead to the page load time. This is because in order to perform their intended function, they usually make queries to the website’s database and require the user’s browser to load additional scripts.
  • The standard of development of plug-ins and themes varies hugely. Those that have been developed well usually add little page load time, even to accomplish complex tasks, while others can add several seconds while performing very minor tasks.
  • Many people, not realising the consequences for their website’s performance, add far more plug-ins than they really need, and never think to disable the redundant ones. Although you may not be conscious of using them, there is a good chance that all active plug-ins are adding some additional load time to your web pages.

Web server configuration
It is possible for a very poorly optimised website to load at an acceptable speed on a very well configured web server, and conversely for a super optimised website still to be relatively slow on a very poor web server. The availability of memory and the PHP version are just two server options that will have a direct impact on the performance of your website. For those who do not have the luxury of a dedicated server environment, and who depend on shared hosting, your choice of web host is crucial. While not the cheapest, I highly recommend Siteground for great support and outstanding performance on their shared hosting plans.

Those with hosted sites such as Squarespace, Shopify, etc. have no control over web server configuration, but can rest assured that it will be optimal.

Caching and optimisation
If your website is hosted with Siteground, their optimiser tools will give you everything you need to optimise your website’s performance, and their technical support team will help you with the configuration if you don’t feel confident in doing so yourself. For a WordPress website on any other shared hosting package, you will most likely require one or more plug-ins and possibly the help of a web developer.

Browser cache
Instructs the visitor’s browser to save files in its memory so that it won’t have to download them from the server the next time they are needed.
Static cache
Saves whole pages in the server’s own memory so that the server doesn’t have to piece them together each time they are loaded.
Dynamic cache
Saves commonly used database queries in the server’s memory so they don’t have to be made afresh each time.
Minify (JavaScript, CSS and HTML)
A form of compression that slightly reduces file sizes.
Gzip compression
Compresses the content delivered to the visitor’s browser to reduce the file size.

Content Delivery Networks (CDN)

Wikipedia define a CDN as follows:

“A content delivery network or content distribution network (CDN) is a geographically distributed network of proxy servers and their data centers. The goal is to provide high availability and high performance by distributing the service spatially relative to end-users.”
https://en.wikipedia.org/wiki/Content_delivery_network

As mentioned earlier, one factor that affects the time it takes for a web page to load is the viewer’s geographical location relative to the server the website is hosted on. Over many thousands of kilometres, a time lag can become apparent as the data transfers. A CDN is a vast network of servers all over the world that will cleverly display your web pages to end users using the server nearest to them.

Cloudflare is an extremely popular CDN, largely because it is free for basic use, but also because they provide much of the caching and optimisation functionality mentioned above, as well as enhanced security and protection against large spikes in web traffic.
https://www.cloudflare.com/

If your web hosting is provided by Siteground, you can begin using Cloudflare at the flick of a switch in your hosting control panel. If not, you can sign up with Cloudflare for free but will need to be able to make some simple configuration changes to your website domain in order to use the service.

How can I tell how my website is performing?

Use these tools to objectively test your website

Before you start optimising your website, enter the address of one of your web pages in to one or all of these free tools and they will scan and analyse the page and return a report.

Make a note of the results of each test you carry out using these tools so that you can see what effects your optimisation efforts have.

Now try whichever of the following you can comfortably manage on your own, and retest to see what effect it has on your speed. Hopefully on subsequent tests your page size and load time will be reduced. Always remember to back up your website before making any changes:

  • Optimise the images on your web page. This includes background images if you have access to them.

You may prefer to do the following with support from a web developer

  • Deactivate any plug-ins you are not using, or that are not essential to the functioning of your website.
  • Install a caching and optimisation plug-in. For WordPress, popular options are WP Super Cache and W3 Total Cache. W3 Total Cache can achieve superior results, but is far more complex to configure than WP Super Cache.
  • In your web hosting control panel, check what PHP version your website is running on. Upgrade it to the latest version or the version recommended by your web host.
  • Use a Content Delivery Network such as Cloudflare.

So you’ve got a great product you’re sure the world would flock to buy? It sounds like you are probably ready to start selling online. You may be baffled by the array of choices facing you before you even start, or perhaps you had no idea they even existed. Unless you have already done extensive research and evaluated the many options, read on, this article is for you!

There are many ways to sell online

The countless e-commerce options available fall broadly in to three models, each with their pros and cons and each suitable for a particular set of circumstances. What do I recommend to my clients? Jump to the end to find out! 

1. Online Marketplaces & Social Media

ecommerce marketplace logos

  • How does it work
    You join the platform and are able to list your products for sale on their website. Visitors to that website are able to purchase your products using the platform’s own payment system. You can have a URL that will lead directly to your products, but it will not be on your own domain.
  • Examples
    Facebook, eBay, Amazon and Etsy

Pros

  • Little or no upfront or continued financial investment required.
  • Benefit from existing traffic to the platform as well as being able to drive traffic to your particular corner of the platform.
  • This may allow you to reach a wider market than you could with your own website.
  • Support available from platform itself and from community.
  • All security and technical functionality is taken care of by the platform.

Cons

  • Little control over the presentation of your products and brand.
  • Competition and distraction from others on the same platform.
  • May be perceived by customer as amateur.
  • Platform takes a high cut of sales.

Curated Stores

These are a sub-set of marketplaces and share some of the same characteristics, though the rigorous selection process means they are not an option for most sellers. Usually, as with other marketplaces, they will not hold your stock and you will be directly responsible for fulfilling orders. A fascinating and growing sector to keep an eye on.

2. Turnkey Websites

E-commerce turnkey websites

  • How does it work
    You join the platform and are able to use it to create your own website with your own domain. Your website will be hosted on the platform’s servers and you will only be able to access your assets (images, product data, etc.) using the admin interface that they provide.
  • Examples
    Shopify (specifically for e-commerce),  BigCommerce (specifically for e-commerce), Squarespace / Wix / Etc. (general website tools with limited e-commerce functionality)
  • More info
    https://www.websitebuilderexpert.com/ecommerce-website-builders/comparisons/
  • I use
    Shopify

Pros

  • Your own website – looks like you mean business and once a visitor is on your site, you face no competition from other brands or their products. If you employ a professional web designer or developer, with Shopify at least, the possibilities for creativity and functionality are almost unlimited.
  • Little upfront financial investment if you set it all up yourself (which most people can with some time, patience and just a little technical ability).
  • Low ongoing costs.
  • Highly customisable so you can control how your products and your brand are presented. This very much depends on your skills and may require the help of a professional to achieve.
  • Add-on functionality available (usually at extra cost) to customise the site to meet your particular needs.
  • Support available from platform itself and from community.
  • All security and technical functionality is taken care of by the platform.*
    *Customisations and third party add-ons are supported by their respective authors, and not by the platform.

Cons

  • You have to drive traffic to your website. Lots of it! This is hard work and is where most websites fail.
  • The platform takes a slightly higher cut of sales than if the website were self-hosted.
  • Ongoing costs can escalate with a lot of add-on functionality.
  • The functionality you require may be impossible to implement with some turnkey website platforms. In this case a self-hosted website may be your only option.

3. Self-Hosted Websites

ecommerce self hosted websites

  • How does it work
    You arrange your own domain and hosting with a web hosting company and install, configure and maintain the e-commerce platform software, usually with the assistance of a web designer or developer. You have direct access to all of your assets (images, database, etc.).
  • Examples
    Woocommerce, Magento, Prestashop and OpenCart
  • More info
    https://ecommerce-platforms.com/articles/open-source-ecommerce-platforms
  • I use
    Woocommerce

Pros

  • Your own website – looks like you mean business and once a visitor is on your site, you face no competition from other brands or their products. If you employ a professional (which you should), the possibilities for creativity and functionality are almost unlimited.
  • Platform itself does not take a cut of your sales, so you only incur payment gateway fees with each sale.
  • Highly customisable so you can control how your products and your brand are presented. This will require a skilled web designer / developer with particular experience with the platform in question.
  • Add-on functionality available (may be at extra cost) to customise the site to meet your particular needs.
  • Open source so your web developer has access to view and edit all files and database if they need to.
  • Community support is often good.

Cons

  • All security and technical functionality is your responsibility!
  • You have to drive traffic to your website. Lots of it! This is hard work and is where most websites fail.
  • Upfront cost likely to be high as you will require an experienced web designer / developer to set the site up for you. DIY is not recommended because of the challenges of implementing adequate security and technical functionality.
  • Maintenance of the software is essential to keep it secure. Countless variables between server configuration and software can cause security problems and malfunctions.
  • Ongoing costs likely to be high as you will be paying for web hosting, a support and maintenance package from your web designer / developer and possible licenses for add-on functionality.
  • It is absolutely crucial to choose a good web host.
  • Support from the platform itself is likely to be non-existent, especially when you have modified the core product in any way. You will require support from a web developer.

What do I recommend to my clients?

To answer this question, first I would have to get a feel for their products, their budget and their skills. The answer will be either an online marketplace, Shopify, Woocommerce, or perhaps a combination of approaches. It often makes sense to sell through more than one channel and Shopify, for example, makes it very easy to combine selling via your own store with other channels such as Facebook and other online marketplaces.

I would ask the following:

  • What are / will you be selling and to whom?
  • Have you any special design and / or functionality requirements?
  • What’s your setup budget?
  • How tech literate are you?
  • How much time and money can you spend on an ongoing basis?
SituationSolution
Very low budget, low tech skillsOnline marketplace
Dip your toe in the water, test your market and take it to the next level when you’re in profit.
Very low budget, decent tech skills, plenty of timeShopify or your choice of turnkey website without my help, possibly also online marketplace depending on your products and ability to generate traffic to your own site.
Low budget with low tech skills and / or little timeShopify with my help to set up, possibly also online marketplace.
Moderate budget and requiring high quality design and / or particular functionalityShopify with full set up and a custom theme developed by me, possibly also online marketplace.
At this point you will be confident that your sales will soon cover the setup costs, you want things to be done properly and professionally and you expect every stage in the customer’s journey to be carefully managed.
Moderate budget and certain circumstances, such as an existing WordPress site or particular functionality (such as gift vouchers) that is not currently well catered for by ShopifyWoocommerce with full set up and a custom theme developed by me, possibly also online marketplace.
At this point you will be confident that your sales will soon cover the setup costs, you want things to be done properly and professionally and you expect every stage in the customer’s journey to be carefully managed.
High budget (€15k +), large and complex catalogue, complex requirements for customisation, security, etcThis may require a larger web development agency.

The primary reason I recommend Shopify over Woocommerce in most situations is this:

All security and technical functionality is taken care of by the platform

Only with bitter experience will the significance of this point become clear. The stress, expense and damage to sales that a malfunction or security breach can bring to a website owner should never be underestimated. To mitigate against this on a self hosted website requires expertise and some expense and is impossible to guarantee. Of course, problems can befall a platform like Shopify too, but when they do, you can be assured that they will have extensive backup systems in place and a large team of skilled professionals immediately on the case to resolve the problem. Additionally, Shopify is typically quicker to set up, easier to build custom themes for, and requires no ongoing maintenance, making both the initial and ongoing investment smaller than for a self-hosted website.

And finally

No article on e-commerce would be complete without mentioning the vital ground work that must be done before you can hope to make any sales online, and the enormous investment of time and usually money required to reach customers. Shopify provides an exceptional educational resource, full of well researched, well informed articles: https://www.shopify.co.uk/guides

Their blog is also well worth subscribing to, whether or not you choose to subscribe to their services: https://www.shopify.co.uk/blog

If you are ready to embark on the adventure that is e-commerce, or if you’re at the very beginning of your journey and just thinking about creating your brand, get in touch to find out how I can help you to make it all happen.

With just a month now until the GDPR comes in to effect, a lot of very small (and some not quite so small) businesses are still finding the prospect of GDPR compliance overwhelming. One aspect of that compliance where I might be able to shine a little light, is the website privacy policy. Once again, I am merely sharing my thoughts here, based on my own research and interpretation of the GDPR, so please do not take these words as any form of legal advice.

Very simple websites

Many of the websites I work with are very simple in their functionality. They are essentially brochure websites, very much like this one, with perhaps at most a contact form as the only vehicle for handling personal data. In many cases these micro businesses are barely in profit and in no position to employ professional help to assure them that their website is “compliant”. The owners of websites such as these are understandably confused and alarmed by the technical terms ringing in their ears and the threat of astronomical fines for non-compliance. If that sounds like you, my advice (were you to ask it) would be above all, not to panic. If you fall in to this category, in GDPR terms, where you are handling personal data at all, it is likely to be in a way that exposes the data subjects (your website visitors) to very low risk. Frankly if you were to choose to ignore the whole thing, the consequences would be…null. In my opinion. But since you ask, I would not advise you to ignore the whole thing. By taking a little time to create a simple privacy policy, you will achieve a few things:

  • That warm, fuzzy feeling from having Dealt With It!
  • Demonstrate to clients and, who knows, maybe even the data protection police, that you take privacy seriously, have some awareness of the laws, and have made an effort to comply.
  • Going through the process will make you more aware of your own practices and may even reveal that you were processing data in ways you were not aware of.

Copycat

I do not believe in copying verbatim, the privacy policies of other websites. Firstly of course, that is plagiarism, and secondly, it’s highly unlikely that the privacy policy of another website will be a perfect fit for yours. That said, taking inspiration from other people’s well written privacy policies is a great idea. I wouldn’t suggest for a moment that my own privacy policy is a good example, but feel free to use parts of it, preferably reworded, if you would like to.

Anatomy of a basic privacy policy

  1. State the identity of the data controller –  This is a legal entity and should include a registration number where appropriate – in the case of a company, the data controller will be the company. More likely, you are an individual and should state your name. Do not hide behind your business name though unless it is a company in the legal sense.
  2. State how you can be contacted – A link to your contact page or email address is adequate if you don’t want to disclose your telephone number or address.
  3. State how (if) you collect personal data on your website – If you do not collect any personal data in any way shape or form, just say so. If you have a contact form, try to understand what happens to the data when the submit button is clicked. If your website is self-hosted (you have your own hosting package, perhaps with a WordPress website on it), there’s every chance the data is sent straight to you via email. If you have a hosted website with Squarespace or Wix for example, or use a hosted form such as Jotform, ask them for advice as they may process that data before sending it on to you. If this is the case, just arm yourself with the information and state it in simple terms in your privacy policy.
  4. State what you do with that data and why – Very likely it sits in your email archives. Perhaps indefinitely? Just state that you collect whatever you collect (name and email address perhaps) in order to reply to their enquiry. If you want to be all legal about it, your legal basis for doing this is probably legitimate interest*. You may also want to state how long you keep the data before destroying it.
  5. Cookies State very simply what a cookie is (see my policy for suggestions). Try to find out if your website is setting cookies, what they are and what they are for, and list them.** State very simply how cookies can be controlled by the user in their browser (see my policy for suggestions).
  6. Users’ rights under GDPR These are extensive, so my preference is to provide a very brief synopsis, accompanied by a link to more information, and information about how to contact me should they wish to exercise those rights (see my policy for help). This section really is a formality. With a super simple website that does not collect personal data, nobody is going to be exercising those rights!

* You do NOT need a checkbox to record consent on your contact form if all it is used for is to send you a message. If you want to get people to subscribe to your mailing list at the same time, or plan to use their submitted data in any other way, that’s another matter entirely.

**Cookies

This is the trickiest bit for most. I covered cookies in some depth in my previous post, so have a look there if you’re ready to grasp the nettle on this one! If that all sounds too terrifying though, it’s still worth trying to find out what cookies your website uses, and the free Cookiebot tool is very easy. Don’t be alarmed when the result comes back saying NON COMPLIANT – they want you to buy their services. What’s especially helpful about the Cookiebot test is that they categorise the cookies for you.

  • If your site sets no cookies – great – say so!
  • If there are cookies in the “statistics” category, just state that the website uses cookies to provide you with statistical information about how it is being used.
  • If there are cookies listed in the marketing category (apart from Google Analytics), you really ought to dig a little deeper, try to understand where these are coming from and clearly state in your cookies section how your visitors may be being tracked and by whom. Likely candidates are Facebook (do you have a pixel installed?), Google (in various guises), AddToAny and ShareThis (social sharing), etc. Do attempt also to provide links to information about how to manage these cookies. In most cases, the companies in question will have information available for you to link to.

Cookie notification banners & consent

If after using Cookiebot’s free audit tool, it turns out that your website does use cookies, of the sort that require consent (that’s pretty much all except those in the necessary category), you do have an obligation to make people aware of the fact and, technically, to gain their consent before placing those cookies. Now, none of this is actually a new requirement under the GDPR. The EU “cookie law” came in in 2011, at which point, we all started seeing the infuriating and now ubiquitous cookie popup banners everywhere.

A note on consent as applied to cookies

At present, in some EU states (e.g. France and The Netherlands), you are required, not just to notify users of the cookies you use, and to assume their implicit consent from their continued use of your website, but in fact to obtain their explicit consent, through an affirmative action (scroll, button click, etc) before placing the cookies on their browsing device. Under GDPR you are also supposed to retain a record of that consent. This is technically a very difficult thing to achieve, and is typically what is provided by the commercial vendors of cookie consent solutions, such as Cookiebot, OneTrust, etc. The same functionality is also available for free from Civic Cookie Control. It’s worth noting that in very few cases (in France at least) is this actually implemented correctly. Yet despite being more than capable of implementing a super-compliant solution like this, and despite being of rather a conservative nature in these regards, after much research and reflection, I have chosen not to do so on the sites that I maintain. This is partly because I find them to be intrusive to users and to have a detrimental impact on the usefulness of whatever services are setting the cookies, and partly because I have a suspicion that within a year they will be redundant.

If, at this point, you have not implemented any sort of mechanism to notify your visitors of your use of cookies, and if, at this point, it feels like something that would be very difficult to achieve, you might want to sit tight for a bit. At some point next year (2019), the various EU state-specific cookie laws will all be replaced with the uniformly applied, revised e-Privacy Directive, and it looks likely that at last a workable solution might be achieved with the responsibility for cookie management passing from individual website owners, to the browser vendors (Chrome, Firefox, etc). If that turns out not to be the case, at least hopefully the dust will have settled and there will be much greater clarity on our obligations as regards cookie consent.

In conclusion

I hope this slightly irreverent but hopefully pragmatic approach has provided some achievable steps to help you to feel more in control and less daunted by GDPR as applied to your ultra simple website. If your website is not quite so simple however, or if you would like assistance to identify the cookies used by your website, as well as any other potential areas of concern: contact me for a quote.

I started this series with a long, hard look at the implications of privacy laws for websites that use Google Analytics, and came to the conclusion that if the only cookies your website is setting are for Google Analytics, you don’t have too much to worry about (though there are a few small things you can do to be squeaky clean compliant). But what if your website uses other cookies too? How would you even know what cookies your website uses?

Let’s first find out what cookies your website is using

Personally I have been using a combination of several tools:

  • Attacat’s free cookie audit tool is a free Google Chrome extension, made in Scotland just like me 🙂 If you don’t use Chrome, there may be a similar tool available for your browser of choice
  • Cookiebot’s free compliance test will scan 5 pages of your website and then email you a very handy list of all of the cookies it detected, with some useful information about each. As it is limited to 5 pages, it may very well be missing some cookies, but for many small, simple websites, all of the cookies that are going to be set, will be on the first page.
  • I also use my browser’s in-built tools. To find out how to view and manage cookies in your browser, try a search for “view and manage cookies in Firefox”, for example. Here is a great tutorial for Google Chrome. The audit tool simplifies the process, but the principle is always the same:
    1. Delete all cookies from your browser (I would also suggest deleting browser cache first as cached files can set cookies)
    2. Browse your website as any visitor would, making sure to use all available functionality
    3. Check to see what cookies have been set during your browsing session. As you deleted all cookies before you started, any cookies that now exist will have been placed by your own website

    So what to do with that information?

    Now that you have a list of cookies that your website is setting, it’s time to figure out what they all do, if they are really necessary, and if any of them are spying on your visitors! Having this information to hand will allow you to find a way to remove the offensive ones and to document the others in your privacy policy.

    Having been through this process with quite a number of websites now, here are some of the more innocent cookies that I see again and again. These just need a quick mention each in your privacy policy:

    • Various Google Analytics cookies (no surprise, not essential but inoffensive)
    • Google ReCAPTCHA – here’s some information on that
    • Google Fonts and Google Maps – anything that ends in .googleapis.com is probably just serving content, such as fonts and maps. Google state that the data they gather from these cookies is used purely in order to provide the service, and is handled separately from any other data they hold on individual users.
    • Various functional and essential cookies, used by Woocommerce shopping cart
    • Various functional and essential cookies, used by Shopify shopping cart
    • wordfence_verifiedHuman and wfvt_xxxxx, set by Wordfence, inoffensive but easily disabled in Wordfence settings
    • PHPSESSID – various uses, nearly always essential to function
    • __cfduid – essential cookie, set by Cloudflare for security purposes (on websites that use Cloudflare directly, or perhaps use resources that use Cloudflare)
    • DYNSRV – essential cookie, set by the web hosts of some cloud hosted websites, used to manage server load
    • Cookie set by whatever script is used for the cookie popup banner to remember preferences

    And here are a few that will require a bit more explanation to your visitors, and possibly prior consent:

    Anything that includes Addthis, Sharethis, Addtoany, etc

    These caught me by surprise and I’m certain they’ll catch a lot of others out too. If you have social sharing buttons on your website, of the sort that link straight to the social networks to allow visitors to share your content on their accounts, they are probably spying on your visitors. There are some alternatives available that do not set cookies (such as Jetpack for WordPress), but, not being satisfied with any of them, I have ended up creating my own plugin that won’t slow down the website and does not use any cookies. The one that really had me scratching my head was a Google Analytics plugin for WordPress that was installed on 3 of the sites I have checked so far. The plugin was created by Sharethis, but even deleting the plug-in did not remove the cookie. The plugin had to be first set to “disable all functionality” and then deleted. Naughty!

    Facebook

    Have you installed a Facebook pixel on your website to track your visitors and retarget them with Facebook ads?  If so, it should come as no surprise that Facebook are planting cookies on your visitors’ devices. The question is how to disclose this to your visitors in a way that is fair to them, compliant with the law, and without depriving you of a marketing channel. You could:

    • Go the whole hog and use a sophisticated cookie popup banner (like Cookiebot as mentioned above for example, or perhaps Cookie Notice plug-in for WordPress) that will allow you to apply the pixel script only after the visitor has given their explicit consent. You’re likely to find a lot of people will not give consent – why would they?
    • Have the pixel script run regardless, but make it very clear in your cookie popup that they are being tracked, and give clear information in your privacy policy about how you are tracking their behaviour and what they can do to opt out. More on this in another post. Possible arguments in favour of this approach are that the alternative could be very damaging to your marketing, and that it looks likely that the new e-Privacy Directive will make this sort of consent manageable by the user in their browser, rather than on individual websites.

    Google AdWords, AdSense, any sort of Google advertising

    If you are using Google AdWords or AdSense rather than straightforward Analytics, you will find yourself in very similar territory to users of the Facebook Pixel and can expect to see a lot of cookies. Google use many different domains for this, including some that sound nothing like “Google”. Look out for “doubleclick” for example.

    YouTube & Vimeo

    If you have embedded YouTube or Vimeo videos on your website, did you know that they will be placing their cookies on your users’ devices? You may decide that the best you can manage is to mention this in your privacy policy, but if you would like to embed the content without the cookies, here is some information on how to go about it. Frankly, if a privacy policy mention is good enough for the BBC, I think it will be adequate for most of  us, especially where the alternative is so difficult to implement.

    In Conclusion

    I am a web designer, I handle web technology all day, every day, and it has taken me hours and hours of research to gather this information. What that tells me is that the average small business owner is not going to come close to this level of understanding and compliance on their own. Part of the problem is that as things currently stand (5th April 2018), the introduction of the GDPR is quite imminent, and the updated e-Privacy law is lagging probably at least a year behind. By the time that new e-Privacy law does come in to effect, it is widely anticipated that very many of the current cookie related obligations faced by individual website owners, will be passed to the browser vendors (Firefox, Chrome, Edge, et al).

    This is to say that, if you can demonstrate that you have made a reasonable effort to understand and to comply with both the GDPR and existing electronic data laws (PECR in the UK), it’s probably quite safe to sit tight and wait for the e-Privacy law to come in to effect before worrying a great deal about complying to the letter of the law. On the other hand, if compliance is very important to your business, and you would like assistance to identify the cookies used by your website, as well as any other potential areas of concern: contact me for a quote.

The GDPR is coming! You may have noticed. Tasked with bringing 20+ websites in to line with the new legislation by the 25th May, I have been up to my elbows in GDPR recently and have found it astonishingly difficult to find authoritative answers to anything beyond the very broadest of questions. While the quantity of articles already written on the subject is naturally very high, the vast majority simply regurgitate a very high level overview of what the GDPR (General Data Protection Regulation) is, normally seasoned with some shock headlines about the eye watering fines that may be imposed for non-compliance.

And so this is not one of those posts. For an overview of the GDPR, the ICO would be a good start. It does not, sadly, provide all of the answers, but at least avoids the scaremongering and misinformation that is so abundant elsewhere. In this series of posts, I will document whatever information I have found to my more specific questions about the nuts and bolts of how my clients’ websites (and my own when I get around to it) can comply with the new regulations. At the bottom of each post will be a small section (subject to revision) that will show the solution I have arrived at. In this particular post, on Google Analytics, I’m shocked at the volume of information I have had to sift through to come to a reasonable understanding of why the solution really doesn’t require much change, if any. It should be clearly understood that I am not a lawyer and none of this constitutes legal advice. Or any sort of advice!

Google Analytics uses Cookies 🙁

First on the hit list – Google Analytics. I’m pretty sure every single website I manage uses Analytics. Analytics does use cookies, and cookies are frightening people just now. Google Analytics cookies are responsible for the vast majority of those annoying cookie banners we have all become blind to now. Without Analytics, millions of small websites would not use any cookies at all, and would be exempt from displaying the cookie banners.

But the GDPR isn’t really about cookies

But there is an important piece of information that is missing from almost every GDPR overview I have read. Cookies are mentioned just once in the 99 articles that make up the GDPR, and then, only those that store personal data are implicated. Which Google Analytics cookies don’t** (sort of – see caveat below). To comply with the GDPR you probably don’t have to do anything different where Analytics are concerned, because the UK law that governs the placement of cookies on a user’s computer is, and continues to be, the Privacy and Electronic Communications Regulations (PECR –no sniggering), which is derived from the EU e-Privacy Directive.

Things might even get easier

Now the e-Privacy Directive is certainly getting a good shake up, but the revised laws will not be implemented until 2019 and until then, apart from some leaked details, we don’t yet know what to expect, and will just have to continue to comply with the existing laws. However, those leaked details sound very encouraging in that it looks likely that the browser vendors (Chrome, Firefox, Edge, et al) may be expected to be the vehicles to give the user control over their cookies, sparing website visitors countless annoying popups, and website owners and managers the need to implement the banners, and the degradation of the customer experience that results. I certainly hope that will be the case.

But until then

In the mean time, how do websites that use only Google Analytics and nothing more intrusive, comply with the existing laws for the next year or so? I’m afraid you probably ought to hang on to your annoying cookie banner for now, and you will certainly want to get your privacy policy up to scratch. Let’s be clear that in the case of Google Analytics, the question is not one of personal data; the reason you should display the information is because Google Analytics places cookies on the user’s device and then they, a third party, process the (non-personal) data that they receive from it. And that I’m afraid, does require consent, as it has done since 2011.

So how do we get consent?

Well yes that is where it all gets a bit vague, and where the GDPR does get involved a little bit. Under GDPR, consent should be explicit and not implicit, as was the case previously. But explicit consent does not necessarily require the tick of a box or the click of a button – a gesture such as scrolling or browsing to another page on the website are accepted as explicit consent, on condition that the user was informed of the use of cookies, provided with the opportunity to find out more detail about their use, and clearly informed what actions on their part will be taken as consent. All of this can easily be incorporated in to the cookie popup banner.

Should consent be obtained before Google Analytics cookies are placed (prior consent)?

What I have found trickier to navigate is the concept of prior consent, particularly in the context of inoffensive little cookies such as those used in Analytics. In other words are we permitted to place cookies on the user’s device in anticipation of their consent being given? The logical answer of course would be no! If consent is required in order to place cookies, the cookies must not be placed until consent has been obtained. In fact this is only partly a GDPR problem, in that GDPR will apply equally to all EU member states (and the UK). In some countries in the EU, prior consent is already required, though rarely implemented, because it is so difficult and obstructive! There are two problems with this approach:

  1. Prior consent requires a solution that is more technically advanced than most cookie consent banners I have encountered to date. In most cases, it requires that whatever script is responsible for the cookie consent banner, is also responsible for placing the scripts that place the cookies (e.g. your Google Analytics tracking code), only once consent has been obtained. In other words, you can’t just paste your Analytics script and your cookie script in to your web pages separately. They need to work together in some way.
  2. If we do this with Analytics code, our Analytics data will be substantially altered because we will not be able to register first time users who only visit a single page. We will only be able to start collecting data about their visit once they navigate to another page. This will mean we can no longer monitor and address our bounce rate, and could prevent any sort of useful tracking of responses to links in social media for example.

Personally, I feel a little pragmatism is called for. Here are the reasons that I don’t think I will be recommending that people who use Analytics tracking should be forced to obtain prior consent. Of course, once again, I am not a lawyer and this is certainly not legal advice, we all have to find our own solutions:

  1. Analytics cookies are un-intrusive, collect no personal data and pose no risk at all to the user. In short, they are not what the GDPR, PECR, or ePrivacy are there for. In spite of the scaremongering about fines, the ICO themselves have made it very clear that fines will be a last resort, in cases where people’s personal data has been misused or put at risk.
  2. It will be difficult and costly for many small businesses to implement a new solution that does gain prior consent.
  3. If they do so it will degrade the usefulness of their Analytics data.
  4. In 2019, the new ePrivacy directive should hopefully solve this problem once and for all by taking it off your hands and giving it to the browsers to deal with.

**That little caveat about personal data

Standard analytics code and cookies do not process any personal data, with one very marginal, borderline exception. The user’s IP address, although not available to you in your Analytics data, is sent to Google and could, maybe, theoretically be seen by Google employees. IP addresses are used to provide geographical data about your users, so you can see what country people come from, but not their actual IP address. There is a way around this though, if it bothers you, which is to adjust your Analytics tracking code to anonymise the IP address before it is sent to Google. This may have a minor impact on the accuracy of your geographical data, but that’s all. Here is some more information from Google.

Just one last point on personal data – while Google Analytics is not itself set up in a way that processes personal data; in a few rare instances, it is possible to inadvertently send them personal data, and if you are doing so, you need to stop it right now! But you’re almost certainly not. An example scenario may be a custom developed membership website that uses email addresses in the URL strings of publicly accessible pages. It’s bad practice anyway, contravenes Google’s own rules, and would also be in contravention of GDPR.

Finally – my solution where only Google Analytics cookies are used

  1. Because I will be providing this as a service and want to be thorough; because it won’t take me too long and won’t have a detrimental impact, I will be adjusting Analytics code to anonymise IP addresses before sending to Google. Here’s how.
  2. Where no other cookies (at least no intrusive ones) are set by the website, if they are already adequate, I will continue to use whatever cookie popups are already in place, ensuring that they state clearly how continued use of the website will constitute acceptance of cookie use. The same banner will also include a link to the website privacy policy. For WordPress users, Cookie Notice is good and can also be used if necessary for those situations where prior consent really is required.
  3. I will be checking that the privacy policy exists, is easily accessible, that it clearly states that we use Google Analytics cookies to collect website data, and why, and providing a link to more information about cookies and how to disable them. Here is a good example of such a link.
  4. As I will be modifying the Analytics tracking code anyway for IP address anonymisation, I may also implement a direct opt out link in the privacy policy, which also requires some modifications to the tracking code. More information from Google on that. Then again, with this solution, the cookies are still set, but just don’t send any data, so I’m not sure it serves any useful purpose.
  5. Don’t panic. As stated, Analytics tracking is really not what any of this is about. So long as you demonstrate at least some effort to comply, it will almost certainly be adequate where you are not in fact handling personal data, as is the case with Google Analytics.