Switch off DTM server-side

There’s a monster hiding under our beds right now, called “GDPR”. Since I am not a lawyer, I will not write about GDPR, but I’ll happily use it as bait. 😉

Seriously, though, GDPR is a great reminder that in our business (analytics, optimisation, but actually the web in general), privacy is a topic, and sometimes we need technical solutions for aspects of it.

I wrote about respecting privacy some time ago, and I stated at the time I was in favour of a server-side solution that simply disables DTM, rather than a Javascript-based approach.

Let me be more specific.

Shapeless, formless

The fairly easy (but wrong) answer to how to do this would be to just not include the DTM library when a visitor decides she doesn’t want to be tracked.

You could do this either by omitting the link in the <head> of your pages, or maybe by having some reverse proxy deliver an empty file.

Problem is, you have to either put try/catch blocks around everything in your pages that uses or calls _satellite, or your visitors will see Javascript errors (if they look for them, or if they break other functionality).

I therefore suggest you do not actually switch off, completely, but rather that you load a specially prepared, fresh, and highly customised version of the satelliteLib instead of the original.

One way of doing that would be via a proxy.

The proxy would usually deliver the Javascript as it is, straight from assets.adobedtm.com. But if you flipped a switch, it would deliver an alternative satellitelib.js file.

Now that switch could be a user preference (“don’t track me!”), or it could be a site-wide kill-switch, used by the webmaster team.

Become like water

So, instead of switching DTM off, or simply not loading it, you deliver the “Chef’s Special”, a minimal file that has one purpose: make sure there are not JS errors on your site.

This is what the file has to look like:

_satellite = {};
_satellite.pageBottom = function() {};
_satellite.track = function(id) {};

As simple as that.

If in your code you use other functions, which is relatively unlikely, then you can use the following Javascript, which includes all officially sanctioned functions the _satellite object has:

_satellite = {};
_satellite.pageBottom = function() {};
_satellite.notify = function() {};
_satellite.track = function() {};
_satellite.getVar = function() {};
_satellite.setVar = function() {};
_satellite.getVisitorId = function() {};
_satellite.setCookie = function() {};
_satellite.readCookie = function() {};
_satellite.removeCookie = function() {};
_satellite.isLinked = function() {};

If you deliver that file – and by all means test using Charles, “Map local” or “Replace” both work – your site will work exactly as usual, minus all the Marketing pixels, tracking and testing managed in DTM.


3 thoughts on “Switch off DTM server-side

  1. Not as easy as that for everybody though. Adobe specific stuff is not the only thing many companies serve up with DTM. Not only do we sometimes put other functionality in it, we also have “patches” and work-arounds; not ideal or “best practices”, but the reality for many of us. So for these situations you can still use this method, but it means you would need to manage these “extras” in two separate DTM Properties and keep them in perfect sync. That is not always an easy task.

    Maybe a more workable solution for some would be to have the server include a GDRP variable in the dataLayer, and have any GDRP sensitive tag include that variable in their Conditions, and the same in your Adobe Analytics code? Couple ways to make that a little easier to manage than it may sound, but there is risk depending upon how many people you have in DTM and your dev/publish processes. But the basic idea is a compromise between doing nothing and your more extreme method.


    1. Hi Cleve,

      I think with Launch, that will be the way to go. DTM Tools are not quite ready, though. The ID Service, for example, doesn’t use any Rules, and therefore can not be driven / restricted by conditions.

      If I wanted to productize something that would answer your use case, I would probably build a processor that downloads all DTM files, strips out everything GDPR-relevant, then puts the rest into some static files, and serve those up for people who say no, or in a kill-switch situation.

      Not easy, agreed.

      I think you will have fun with Launch!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.