Check Your CRO Toolbox for GDPR Compliance

Check Your CRO Toolbox for GDPR Compliance

Dennis van der Heijden has researched the implications of GDPR compliance on a variety of tools that we use everyday to optimize websites. He covers conversion rate optimzation (CRO) tools that include workflow, digital analytics, form analytics, heatmap, session recording, on-site surveys, QA, performance optimization, and A/B testing tools.
Sure, GDPR is complicated—but here’s one thing that is clear:
GDPR affects you.
(Assuming, that is, you collect any personal data, from any EU citizen, at any point, ever).
The General Data Protection Regulation is ambitious. It expands the scope of what counts as “personal data.” It creates new standards for how we ask for “consent” to process personal data. And it remaps who are held to these new rules.
These things taken together mean: if you collect EU email addresses, or have cookies on your site tracking EU web visitors, or use any tools that hold on to any personal data, of any EU citizen—you now should be complying with GDPR.
And so should every piece of data processing software you rely on.
It sounds overwhelming. But it’s more manageable than you think. Here we’ll break down the common types of CRO tools you may be using—and how to ensure they’re ready for GDPR’s May 25th enstate-date.

A quick note on personal data

Personal data is intuitive–but it might not mean what you think it means.
You may be familiar with PII (Personally Identifiable Information), the North American standard for data that identifies a person, and requires special consideration.
GDPR’s definition of Personal Data includes quite a few things that PII doesn’t cover. Here’s a full breakdown:

Personal Identifiable Data (PII) Personal Data
  • Full name (if not common)
  • Home address
  • Email address
  • National identification number
  • Passport number
  • Vehicle registration plate number
  • Driver’s license number
  • Face, fingerprints, or handwriting
  • Credit card numbers
  • Digital identity
  • Date of birth
  • Birthplace
  • Genetic information
  • Telephone number
  • Login name, screen name, nickname, or handle
  • Full name (if not common)
  • Home address
  • Email address
  • National identification number
  • Passport number
  • Vehicle registration plate number
  • Driver’s license number
  • Face, fingerprints, or handwriting
  • Credit card numbers
  • Digital identity
  • Date of birth
  • Birthplace
  • Genetic information
  • Telephone number
  • Login name, screen name, nickname, or handle
  • IP-address
  • Unique identifiers like Device IDs, UserID, TransactionID, CookieID
  • Pseudonymous data (that’s unrecognizable data + key on different spot to make it readable again)

The big shocks here, if you’re used to the scope of PII, are cookies, and IP-addresses: both of which a readily collected by a number of our favorite marketing tools.
As we start to walk through the programs in your standard, marketing toolkit, we suggest you look at how your marketing software, gets you the information it collects, and whether or not, in doing so, it collects personal data.  

Moving personal data outside of Europe

Transferring EU personal data, outside of the EU, can be a mess.
It’s easiest done when it’s transferred to a country that the EU has deemed have an “adequate” level of personal data protection.
That list is here.
It is short.
And the US is not on it.
Except, for entities that have participated in the Privacy Shield agreement.
Basically, a Privacy Shield company is a company that meets EU standards for adequate data protection. If you’re dealing with a company that is Privacy Shield compliant, facilitating data transfers is no problem.
But if you’re not, you have a few (exhausting) options: model contracts, and binding corporate rules. It’s too much to go into here, but the ICO has a great overview of what that looks like.
All this is to say: if you store any of the above mentioned personal data, in any of the tools you use for your CRO program, make sure the program is Privacy Shield Certified, hosted in Europe, or hosted in an “adequately” protected country.
Otherwise, you’re transferring data out of EU borders, and have to be ready to contend with some lengthy, bureaucratic headaches.
You can find a list of Privacy Shield countries here. And a list of marketing tools we’ve vetted based on GDPR compliance here.

Conversion Process Workflow Tools

Workflow tools like Podio and Asana, and the more specialized tools like Effective Experiments and Growthhackers Northstar may contain personal data that is covered under GDPR compliance.
For example, your European employees’ details can be stored there, which, in and of itself, is personal data. But also, you’d be amazed by how easily companies can store customer data in their workflow tools without realizing it.  
It’s recommended to use links to your CRM when talking about customers in your workflow tools. Don’t use full names and email addresses. you might need to erase everything stored in there now that would be considered personal data, as all comments might not be editable.
Most of the workflow tools specifically designed with CRO in mind have an integration with A/B testing tools. Keep integrations like this in mind when you pull in any data that may contain personal data (like IP’s and orderID’s).
Whenever you store user information—you need a legal basis for doing so.
Your customer data might be alright, as long as you have a well written privacy policy. If your customers have opted into that privacy policy when they completed a transaction, they’ve opted into a contract, which can give you the legal grounds for storing their personal data.
Data like IP’s, and orderID’s, on the other hand, cannot be stored unless the website visitor gave consent. Or, your privacy policy states why legitimate interest was chosen as a legal basis.
In addition, check where the servers are located, depending on the country the tool might need a Privacy Shield certification.

Digital (Web) or Mobile Analytics

We’ve got amazing tools out there that analyze, and even predict what user might do. They automatically profile, categorize, and store a massive amount of data.
And that’s how we tend to use them. We store as much as we can about our user’s behavior—since we never know what segments, we, or our machine learning tools, will find to be profitable.
This is a problem.
GDPR compliance mandates data minimization, meaning that processed data is “adequate, relevant, and limited to what is necessary to fulfill a data subjects purpose (Article 5).
Processes that automatically profile, and make decisions, are explicitly mentioned in the law. You should be storing only the data you need to fulfill your audience’s purposes, or you should find a legal basis for which to store it (like consent).
For example, if your site’s sells clothes, and your visitors come to your site to buy clothes, combining their browsing patterns with third-party data to create consumer profiles doesn’t help them fulfill their purpose. It just adds to your data stockpile. This means, you require a legal basis—most commonly, asking for consent—in order to use those tools.
You should also make sure that automated profiling and decision making does not discriminate European users from seeing and receiving the same opportunities as others.
Tools like Google Analytics can be made compliant.  We documented the process here. However, massive analytics storage tools like Heap, or predictive analytics tools will need a very close look over. If you’re going to continue to use them, it’s best to hire a legal professional to analyze your setup and its use.

Form Analytics

Form analytics are useful. They’re key to discovering the optimal number of forms, and the order of form fields. They also can expose and store personal data.
For GDPR compliance, set your form analytics tools to mask all content and make sure you don’t store and analyze niche segments.
Here’s why niche segments can be a problem: if, when you combine all the data you collect, you have enough data to identify an individual—you are storing personal data.
Country data isn’t necessarily personal data. Neither is a company name. But if you’ve isolated the fact that I’m a team member of the company Convert, and you’ve stored my country, you’ve stored personal data. I’m the only one in the company working from Spain.  
If you don’t setup these tools correctly, you might lose then from your toolbox with European sites.
You will also want to make sure that all scripts and data are stored and loaded from Europe, or you are transferring data outside Europe and the tool needs a data transfer agreement.

GDPR Compliance and ePrivacy

Let me interrupt discussion of the tools for a moment and share a little bureaucracy with you. GDPR is the law everyone writes about, and that is the one that actually becomes enforceable on May 25, 2018.
But there’s another law that works with it, hand in hand. It’s called the ePrivacy Directive, it’s a bit more specialized, it deals with all things digital (like cookies) and it’s already in place in Europe.
Most tools used in CRO and installed on your website are subject to the laws spelled out in the ePrivacy Directive. Their cookie use is regulated and, generally, the rules follow “opt-out” requirements. Basically, you should let your users know you’re tracking cookies, so they can decide to restrict it.
The problems we face as CRO experts are that GDPR changes these standards. Cookie identifiers and IP’s are now personal data (according to GDPR) and therefore require a legal basis to process, like consent, or legitimate interest.
So the ePrivacy Directive says cookies are opt-out and GDPR says they require a legal processing basis.
To make things even more complicated, new ePrivacy Regulations are coming, to replace the ePrivacy directive. These new regulations were supposed to be in place by May 25th as well but got delayed, and it may be a year or two before they get instantiated.
For now, there’s the draft legislation, which clarifies that cookie identifiers and IP’s need a legal basis.
There are, however, exceptions, like analytics tools. You can install these without consent and as long as they’re mentioned in the cookie notice or privacy policy.
So when you see vendors of CRO tools trying to tell you analytics tools are exempt from GDPR, they may be referring to a law that’s not in place yet (ePrivacy Regulations), or by using the existing “opt-out” precedent set in the ePrivacy Directive.
But know that when GDPR and ePrivacy Regulations are both in place this gap in clarity will be sorted.

Mouse Tracking / Heatmaps and Session Recording Tools

I think by now you can start guessing what I’m about to say. I don’t want to send the CRO market back to the middle ages because of compliance issues. But, in 2018, privacy matters, and you need to consider it as a CRO expert.
The easiest tools in this stack to make compliant are heatmaps and mouse tracking. Make sure you don’t track the mouse details or have your scroll depth set to one person. Don’t combine data from other sources to zoom into one user.
I don’t expect your mouse tracking to store personal data, but understand what is being used to track visitors, and double check the table on top of this article.
Session recording tools make me a bit more nervous. It feels more invasive—but if it’s being done without IP address, country data, or user data—you might be okay. Check the tools you are using and a legal professional.
Here’s why I’m doubtful, and I suggest you’d get consent before you use session recording.
It’s literally storing individual, personal, actions online. Trying to explain to an authority that “it’s not personal data” seems like a bit of a stretch.
It’s scary to admit, but this data may require opt-ins to use. Being fined for lack of GDPR compliance is a scary, too.

This isn’t Just About GDPR. This is About Your Brand.

What if you don’t ask for consent for some of these tools? Let’s say that you find a legal way to rely on the legitimate interests condition. And you hide this data usage in your privacy policy.
What if you’re hacked?
How do you explain to your customers, your users, or a journalist that individuals have their session recordings published online. And that technically, sure. It’s in the policy. People should’ve expected that.
Then replace “session recordings” with any of the other tools and see how you feel.
I’m not saying you couldn’t defend it in court, or with the privacy authorities. But ask yourself this: can you defend it in public? GDPR says you need to report breaches of personal data affecting users within 72 hours. So your contingency plan here should include the idea of defending this breach on TechCrunch.
It’s a great idea to apply this gut feeling and TechCrunch check when selecting the tools you use. We killed a lead generation method that we found hard-to-defend because of this check.

Quality Assurance Tools

You shouldn’t really face any roadblocks to improving customer satisfaction.
Once someone is a customer, they’ve likely signed a contract with you . They’ve acknowledged your terms and your privacy policy.
So they should already have given you the legal basis you need to process their data. Just make sure you add your tools, and your purpose for using them, in your privacy policy—so when customers opt-in, and begin a relationship with you, it’s clear what they’re getting into.

Qualitative surveys and polling tools after GDPR

If you use pop-up surveys which ask random people a few questions about your site, we don’t anticipate there being any compliance problems.  
But if you survey people based on IPs, or country information, or more specific audience filtering, then your tool here might be storing personal data. It may even fall under audience profiling.
So when you use personal data to select who you will poll or survey, you’d need a legal basis first, before your survey ever pops up. You can’t just ask for consent with your pop up. That would be too late.  
For customers, a simple NPS question can fall under the legal basis of a contract. You might be able to get away with using the legitimate interests condition, for people on the payment page who have already (legally) given you their personal data.
In contrast, you would have a hard time defending “legitimate interest” as a legal processing basis for a web visitor that browsed, say, five pages, over a three-day period. Here, you’d have dropped a cookie (personal data), stored a country (personal data), or an IP address (personal data), and held onto their browsing data — potentially, in conjunction with this other information, personal data.
Here, asking for consent to survey, is best.

Site Speed Analysis

Since these tools look from the outside to your website, there should no personal data (but your own) stored in the speed analytics tool. It shouldn’t cause a problem for your website visitors.
When, however, you have a system that stores website visitor, country, state, city, and device type—or maybe things like device ID, or multiple locations of the same device—then again we start talking about personal data, and you need to consider your legal processing basis.

Testing Tools

This is my bread and butter. To be transparent: I’m the CEO of We make A/B testing software and have been investing pretty heavily in GDPR compliance.
So I know more than a little on how tools like this need to adjust to comply with the law.
A/B testing tools can fall under “profiling” and automated decision making, for which GDPR compliance requires a legal basis. This fits the bill when you use third-party cookies to determine what pages users visited, or connect to services that share personal interest from other websites (for example: “person lives in rich zip code area”).
If you’re using your A/B testing platform this way, you are definitely going to need consent. And you need to make sure the consent was given at the time of the third-party data collection. So keep this in mind if you’re using testing and personalization enriched with third-party interest data.
When your A/B testing tools collect IP addresses, or zip codes, or city level data, and stores that data with the record of the visitor, you need consent. If you use segmentation or universal user IDs across sessions, and for a long period of time (months), I would suggest you get consent.
Accounting for this, we’ve made a lot of adjustments at Convert. If you’re A/B testing with another provider, ask them if they can answer “yes” to these questions.
Can you use the tool in the default settings without requiring consent? At Convert, we’ve stripped out all the personal data from our tool. We made everything work without transactionIDs, orderIDs, IPs, or modified cookies, so that anything GDPR would call a unique identifier, wouldn’t be stored.
Do they bucket data? At Convert, when a web a visitor enters an experiment, it is placed in the bucket “123”, which stands for variation A, of experiment 101, on a Chrome browser.
The buckets have a benefit that they pass the “gut feeling and brand damage” check. If a customer database were to end up in public, all that is accessible are buckets with visitor counts, never full visitor flows and visible paths.
Are their servers located in the right place? All of Convert’s servers are located in Europe, so we don’t have to worry about data flow outside of the EU.
Does the tool warn users if they want to segment based on the personal data mentioned above (IP addresses, or zip codes, cities, etc)? Convert will warn that these features require consent.
It took six months of development effort, but we’ve ensured customers can rely on legitimate interest and can use our tool in the default setting, without requiring consent.
With Convert, you can still capture 100% of your traffic for testing.
When you have to ask for consent to A/B test, that percentage can drop dramatically. A recent study from PageFair showed that, when consent is required, only 21% of users would opt-in to tracking.
So unless you can afford to test only a fifth of your traffic, we suggest you have a serious chat with your experiment software providers.
We’ve yet to see another company make the necessary changes, which would allow for use under the legitimate interests condition.

In Short

Any CRO tool can be redesigned to strip out all possibilities of storing personal data. Couple this with the mention of legitimate interests in your privacy policy, and you should be able to keep your traffic intact for testing, without breaking the trust of your web visitors.
If the CRO tools you select only place a temporary cookie, you store NOTHING of personal data, the legitimate interest basis might be an option for you.
If you then verify where all data is stored—and in the case of the U.S., check Privacy Shield certification—only then you can feel safe.
Now in case you’re wondering if the European Privacy Authorities will really come after you, I suspect yes, if you are collecting large volumes of data and/or you are a well-known brand. As the law is fighting to get itself taken seriously, there are bound to be companies used to set an example.
If you’re a small website, I don’t think that, come May 25th, you’ll be the first on the stack of on investigator’s desk. But I do think trust is something that you can optimize for. If you’re working in the European market, as CRO professionals, there is no excuse to be sloppy with your tool stack.

Latest posts by Dennis van der Heijden (see all)
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *