I am no lawyer, and I do not want to go into any legal or even ethical or moral aspects of EU privacy law. Let’s just say this for our American friends: people in the EU do not like to know they’re being marketed to. Mostly. They also fear Google more than their own government, especially if they’re German.
For your friendly marketer, this means that she has to take into account things like legal requirements, cultural feelings, visitors’ fears or assumptions, and even outside events.
A lot of marketers react to that by, or are being forced into going for the “better safe than sorry” approach, which means that a surprising amount of sites in Europe have some sort of a cookie / privacy management layer.
The cookie / privacy layer usually makes sure a user can decide whether and how far they’re being tracked. It is usually implemented by IT as part of the web site, and funny enough, it usually sets a cookie that tells everything else whether tracking is allowed or not.
How you use that cookie is up to you, or rather how you set everything up so your marketer cannot ignore that cookie.
I can think of 4 approaches:
- DTM Analytics Tool built-in functionality
- Explicit Condition in every DTM Rule
- Include/Suppress DTM <script> tags (server-side)
- Include DTM library dynamically (client-side)
Shall we look into these one by one?
DTM Analytics Tool built-in
There is a checkbox in the preferences of the Analytics Tool in DTM, which looks like this:
If you tick that box, approve and publish, you’ll likely notice that all of a sudden, Analytics will not track any data anymore.
This checkbox is the easiest and safest option: it presumes an opt-in scenario and therefore stops tracking until the visitors sports a cookie called “sat_track”, that must contain “true”.
This is pretty easy to “implement”.
Explicit Condition in DTM Rules
Another approach is to create a Data Element (“Tracking allowed”), and to prescribe that this has to be part of the Condition of every single Rule.
The effect of that is that if the DE returns false, not a single Rule will fire, which you can use to effectively disable any marketing tag or code on the site, with the notable exception of Direct-call Rules.
Now you’re thinking about the human element, correct? Your friendly marketer is bound to forget to put that condition on at least some Rules, right?
I’m sure she will.
It is a process issue, but also something you can test quite easily, and you can automate that test.
I feel that is safe enough.
Include/Suppress DTM <script> tags (server-side)
If your opt-in/opt-out cookie is a first-party cookie, you can easily read it server-side.
That means you can make a decision whether to include the DTM library on the server while building the page. If the cookie says no, you don’t include the <script> tag.
As a result, nothing will load, not even DTM itself!
Furthermore, the visitor will not even get a glimpse of what could have been.
This is by far the safest way of doing this, but it comes with a downside: since the server needs to decide on each page, there’ll be more server load. Content will be less cacheable. Depending on your infrastructure, that may or may not be a show stopper.
Include DTM library dynamically (client-side)
The plus side of doing that is that the server can still cache nicely. The down side is that the decision to load takes time (sometimes even user interaction!), and so the result is that DTM is loaded later than usual.
In a lot of cases, this is not too much of a problem, but it will lead to some loss of tracking (people have moved on before DTM has had time to do the needful), and if it really takes long, you might no longer be able to effectively test or target content with this approach.
I am a big fan of option 3 (server-side decision). I guess I’m not in dev so I don’t have to manage it. Option 2 (Data Element + condition) is a good one, provided you have some governance in place around it, or some automated testing.
Option 1 (built-in) is fine as long as you do Analytics only, and option 4 (client-side) is really not an option in my mind at all. Nevertheless, I know people who are doing option 4. I guess in IT and marketing, anything goes.
Do you know any other options? How do other tools handle this?
7 thoughts on “Privacy with DTM”
You could also read if “dot not track” ist set in the Browser:
window.navigator.doNotTrack === 1
So that there is no need to give an extra opt-out per analytics vendor.
Uuh… can of worms.
As far as I can see, industry consensus seems to be that DNT is only for personalised ads, as opposed to site tracking.
But you can, of course, and it is easy to implement.
Please note that DTM has a “hidden” feature that can be switched on by Adobe that can help you with streamlining the privacy management process. It is described in more detail here:
You are absolutely right that the two topics are related but do not fully overlap. As I said, I’m not a lawyer.
I guess a good way of tackling privacy is to follow the “say what you do – do what you say” mantra.