This meme is just too true. What was once in vogue is now dangerous to touch. Handled carefully and competently, though, it’s of course pure gold! Data, I mean. Not asbestos. That’s only bad.

Technical GDPR and privacy compliance, the TL;DR version

Some tips to GTFO 🏃 of the worst “privacy dumpster fires” 🔥 🚒

To keep this as short as the TL;DR title promises, I cut out a section that was originally slated for this article. If you like this, then you may also like my short and slightly snarky piece “Some dumb objections I have heard when discussing privacy in the context of analytics”!

Note: Being the author of this article, I represent only myself. I am not a lawyer so don’t see anything here as strictly legal advice. However, being a professional in IT and software development, this is a question I’ve dealt with for a range of clients, small and large, some familiar and others less so with the legal side of GDPR. My expertise is primarily technical, so some of the “softer parts” including processes around DPOs will not be covered here. The perspective I represent is therefore from my own background and experience based on what I’ve gathered and learned. Always verify any claims and plans with your own legal representation!

It’s still hard to get things right when it comes to privacy and data today. Paradoxically — while laws and regulations are actually now becoming firmer and more widely discussed — niche interests, such as marketing and data brokering, combined with the threat of legal enforcement seems to stress people out, to the point of no — or inconsequential — action being taken.

I will assume that you are confused by all of the laws, abbreviations, tools and services being thrown around in the privacy and analytics space.

The below situation is a paraphrase of something I’ve witnessed several times:

  • You run—or work for—a company (or similar legal entity) so you have a vested interest in being legally compliant. You’re pretty sure you aren’t 100% kosher, since you fire away a ton of scripts that the marketers didn’t want to turn off in 2018.
  • You use Google Analytics. GA is your primary personal data entry-point today, except for orders or other contractually obligated items. An article at CPO Magazine brings up many of the good reasons it’s probably high time to dump Google Analytics. You’re maybe even here because you’ve considered those points already.
  • You are scared that your company will be next to be featured on have i been pwned 😱
  • You’re not clear on the similarities or differences between GDPR, CCPA and all the other similar laws.
  • You would like to please your marketers and analysts (or whoever does the number crunching and funnel-crystal-balling).
  • You are not quite sure about who implemented GA once upon a time, or what data has been collected.
  • You fear the day a customer wants a record of their personal data.
  • Honestly, you just want to do the right thing and get this over with.

But, let’s first get one Big Thing® out:

If you don’t collect personal data—including such ephemera as IP addresses—or store non-necessary data (“cookies” etc.) on a user’s device, then you are pretty much out of scope for GDPR…and most likely other similar laws too. Your life will be significantly easier. This fact, if anything, is what you should take home from the new privacy laws.

For fun and profit, spend some time filling out the GDPR checklist and see how well you are aligned today before embarking on your quest for change.

An approach for reaching compliance

Below I’ve drawn the inverse of the first list, to give you an idea how the above “should” be solved. The rest of the article will fill in some of the padding information for most of the steps.

Not covered in this article:

OK, so let’s look at some of the above in more detail!

1. Data minimization should be priority number one

Before I write more: With data minimization I primarily mean personal data, and especially within the context of consent-given circumstances. The rote collection of data from any random visitor is the issue at heart, not that you keep security logs, access logs and contracts and legally obligated documents. With that said—

The driver behind compliance should be to minimize the amount of personal data you collect in the first place. That’s right. Zip, nada, zilch, zero, niet. Privacy by design, in short, could help you do the Right Thing®, long before you have to clean up any mess. You start shaving off “problems” in equal measure so it’s probably well worth it. From a purely analytical perspective, tracking events happening in your apps and sites is not the problem. Keep doing that! But any attached data—like which exact user fired a certain event—has to go.

Again, refer to what personal data is and avoid patterns in which one could cross-reference pieces of data to build a compound identity (real person) from the individual pieces.

2. Implement privacy-focused analytics

When you start using more more privacy-focused offerings, some of the very rich data will (or may be) lost compared to GA. But that’s the entire point, paradoxically. The fact that you hold (and give to Google and their third parties) personally identifiable data is the reason you are even facing problems with GDPR (etc.) compliance.

Your marketers and/or analysts will need to adapt. Do try out some different services to see how they work and what (if anything) the software services change in how you currently work. For example: One of my own key findings has been that events tend to allow for fewer dimensions (1–2?) than Google Analytics supports (3?). Information like this will help you adapt without making too many compromises.

Without further ado, you’ll also need to pick a high-level technical approach:

  • Analytics on the server-side, inferred from requests to the server, or
  • Analytics on the client-side (GA-style), where you push events and data to a “first-party processor” service.

Server-side analytics

First-party server-side analytics are a purposely less invasive option and should be sufficient for coarse-grained information, like number of unique users, most requested assets/pages and such. No scripts need to be added to your site/app.

This category seems to be taking off as they are very fast, easy to use, hosted and sometimes free solutions. They do currently lack the depth of heavier analytical tooling like GA.

Client-side solutions

This is the category dominated by Google Analytics, which makes its own use of the data you collect and the real reason it’s free. The solutions I list below do cost a small bit of money per month but give you 100% ownership and portability of your data.

Read Carl Cassar’s benchmark for most of the above products.

This is Fathom on a testing domain I set up. This is really it. If you’ve seen the above you’ve seen it all! Under “Goals” you’ll see the events we are tracking, for which you can also add an optional conversion value.
Simple Analytics on a testing domain.
Simple Analytics does also give you a separate, basic overview of events that you are tracking (“click_button” in this case).

Considerations for a client-side library include performance (library size, and maybe some latency to establish connection). At least Fathom and Simple Analytics are both really good on those aspects. I don’t know how many projects I’ve been part of, where I’ve had to do technical performance recommendations and found GA and GTM to be chiefly responsible for the bad results 🛑 So if you’re looking for fast sites with good technical SEO, that should be reason enough to chuck GA out the window.

Recommended paths for compliant analytics, in ranked order

1. Use a privacy-focused alternative to Google Analytics.

2. Use “more private” analytics on the server side.

  • If you are already on Netlify (Netlify Analytics) or Cloudflare (Cloudflare Analytics), consider their platforms.
  • Server-side analytics could be seen as being very similar to the old kind of traffic analytics you got on old or legacy hosting platforms. Modern counterparts snazz these up a bit so they are less raw and ugly, but in general you are looking at fairly basic capabilities. If that does the trick for you, then by all means, fire it up!

3. Use Google Analytics if there is no other option, but brace for hard changes.

Refer to some of the additional resources below for guidance on how to make Google Analytics GDPR-compliant:

Custom solutions

Yes, you could build an analytics solution on your own. Don’t do it unless you really know what you do.

It’s not too hard to technically build your own solution, as you can see at https://adwise.ch/blog/minimal-cookieless-web-analytics/. You will need to think hard and deep about how you ensure compliance regarding PII etc still, though. What you gain is a much greater degree of insight into what happens and you can control all the individual pieces making compliance (possibly) logistically easier. What you lose is that you have a much bigger surface area to cover. If you are reading this article, I am suspecting that maturity hasn’t yet been reached to fully implement a completely custom solution.

3. Implement a Consent Management Platform if needed

Remember that there are six legal bases for processing: consent, performance of a contract, a legitimate interest, a vital interest, a legal requirement, and a public interest — no other reasons are valid, and all listed bases are regulated.

As Cookiebot writes,

“Although cookies are mentioned only once in the GDPR, cookie consent is nonetheless a cornerstone of compliance for websites with EU-located users. This is because one of the most common ways for personal data to be collected and shared online is through website cookies.”

— Source: GDPR and cookie consent

Tip: I advise you to also read Precis Digital’s article “Getting valid cookie consent as part of ensuring compliance in the collection of data” as a follow-up to this section.

What this means in practice is that the only cookies you can set/use without explicit consent are “technical cookies” (see reference), which also tend to go under the moniker “necessary cookies”. These are strictly functional, like keeping a cart in your browser’s memory, remembering your password or anything that’s minimally needed to drive a typical web/app experience. Necessary must always implicate a fully functional and complete experience—this can never be used as a factor to segregate users. A user must never be pushed out because they did not allow non-necessary cookies.

Continuing on what consent entails—

If your website has visitors from inside the EU and you use cookies that process personal data, you must –
* Ask for consent before activating cookies and trackers that process personal data,
* Enable users to give clear and affirmative consent to the processing of their personal data,
* Make sure that user consents are granular, i.e. users must be able to consent to some cookies rather than others,
* Inform users of how you use cookies and the purposes of why your website processes personal data,
* Document all obtained consents,
* Consent must be renewed annually. However, some national data protection guidelines recommend more frequent renewal, e.g. 6 months. Check your local data protection guidelines for compliance
— Source: Cookie control — stronger cookie control in EU and US

If you need to choose a Consent Management Platform or solution, keep the above in mind when picking one! You would ideally have a product that allows category selections, clear descriptions of what goes into a category, clear ”deny” possibility and a detailed list of any and all cookies present on the site/app, and a user-facing widget to update their consent. One of the core items that a CMP has to do right is to block scripts and cookies until relevant consent has been given. Unfortunately not all solutions are very good at this. The ones I’ve listed below should all do just that, though.

While a lot of solutions exist, you should balance good taste and judgment toward any product’s statements of compliance. I personally think it’s clear that some products are vastly better at presenting information according to the GDPR article’s requirements.

This category is also where you will find big name products like OneTrust and Quantcast. I would recommend against them as they are big (library size), bloated, often very expensive, not very user-friendly, and (according to me) “corporate-y” to an intolerable degree.

The below is a personal shortlist of products that I think strike a good balance between price (or even being free!), GDPR-readiness, and UX:

Custom solutions

Yes, you could build it yourself.

Creating your own consent solution is not too hard when it comes to the basics: load scripts conditionally, inform about cookies etc. The hard parts can be the detailed info on every single cookie and erasing personal information from your collection systems.

I’ve built several script-blocking modals and functionalities myself, but what I found out going deeper into this area (as you are doing now!) is that there a lot more things you need to factor in. Because of the messiness, I recommend you don’t build this on your own. If it were only the loading of scripts, this would be trivial of course.

4. Write/generate and publish your privacy (and cookie) policies

This one is probably most well-known as many organizations have implemented these policies by now. Also, this happens to be one area my competence does not cover quite as well as the topics above.

Anyway: It’s required that you have a privacy policy, if you collect user data. So, what is it?

According to the GDPR, organizations must provide people with a privacy notice that is:
* In a concise, transparent, intelligible, and easily accessible form
* Written in clear and plain language, particularly for any information addressed specifically to a child
* Delivered in a timely manner
* Provided free of charge
— Source: Writing a GDPR-compliant privacy notice (template included)

Hint: Obviously, use the template from the above link if you need!

I’ve seen several times that some of these “boilerplates” you can easily find are just copy-pasted and are effectively meaningless: that won’t cut it. If you (for example) generate a policy, then at the very least make sure the details and required crispness around cookies and what is stored (etc) is absolutely correct! By the way: Some CMPs can generate these policies for you.

There are of course plenty of solutions, most of which offer some functionality for free:

Custom solutions

Yes, you could write these completely on your own. Given a lawyer that would probably be just fine.

However I—surprise, surprise—recommend you don’t, as there may be frequent updates (technical changes etc), and the bulk of the documentation outline seems to be standard-issue anyway. It would probably be more efficient to have a service lay out the foundation, and update it with any additional clauses or formulations together with your legal representation once needed. This would keep the process smooth and fast when changes are needed rather than starting from nil.

Ending notes

The sharp-eyed might have noted that there are no sections on DPO and data removal/portability. This is simply because those things I know less, and because those will depend a lot on your specific circumstances, technology and processes. I can’t give wholesale recommendations as easily as for analytics platforms and such.

This has been a pretty hard article to write as I keep thinking of angles, caveats, gotchas and additions all the time. However, in keeping with the “TL;DR” idea, this will have to be it though! If you follow the recommendations you should be—if not 100% compliant—then at least on a pretty solid grounding. If nothing else, I really hope I’ve managed to light a way forward for you, and that you can fill in the areas missing from your own circumstances.

If you filled out the GDPR checklist before making changes, don’t forget to do an A/B comparison with how you “score” after implementing them 😅

Best of luck on your compliance journey!