What “Do Not Track” really does (and what it doesn’t)

SanfordWhiteman
Level 10 - Community Moderator
Level 10 - Community Moderator

Despite instructing a Community member to “search my posts” the other day, I ran a search myself and there wasn’t a one-stop explanation of what Do Not Track (DNT) means in Marketo (on a deeper technical level than you get on the official doc page). So here goes.

As you probably know already, there are 2 DNT options, Ignore and Support:

pastedImage_15.png

We won’t worry about Ignore.

But what does it really mean to choose Support? On a technical level, it means one specific thing:

If a user’s browser sends the DNT: 1 HTTP request header along with a Munchkin-logged pageview or link click, Marketo will not save the activity to the Activity Log database.

So here are some things Do Not Track = Support does not do:

  • it does not stop gathering Clicked Email stats: email clicks are still tracked unless you separately turn off link tracking
  • it does not stop Munchkin JS libraries from loading
  • it does not stop Munchkin from initializing and setting its _mkto_trk cookie
  • it does not stop Munchkin from sending a Visit Web Page (assuming you're using the default configuration which always sends a VWP on startup)
  • it does not stop Munchkin from sending a Clicked Link for <a> links on the page

But again, here's the very important thing it does do:

  • it stops the Marketo platform from storing the Visit Web Page and Clicked Link hits sent by Munchkin

Why not stop Munchkin completely?

It's not that Marketo would not like to be more proactive on the browser side, I'm sure. But the weirdest thing about DNT is there's no programmatic (let alone cross-browser) way to know if the user has set a preference! Ergo, you cannot know if the person would've wanted you to turn off Munchkin downloading/initialization/hit logging. You have to dumbly send the hit in all cases, then the server will discard it if it's accompanied by the “please ignore me” header.

The privacy appeal of having the DNT setting be unreadable in the browser is clear — it's the equivalent of an HTTP-only cookie that can't be seen from JavaScript — but it certainly creates confusion. For example, someone with DNT enabled who’s also running Ghostery or similar will still see that the Munchkin tracking JS was blocked, which is suboptimal: ideally, it wouldn’t show up at all. You might seem like you’re being worse corporate citizens than you actually are. (A link on your Privacy Policy confirming that you honor Do Not Track is useful.)

The browser's-eye view

The browser sending the DNT: 1 header is a prerequisite, of course. Privacy-oriented browsers do this by default; other browsers do it in Private/Incognito/InPrivate mode only; the the rest do it for all pages/tabs/windows when selected. Here's the setting in an older version of Chrome, for one of a zillion examples, which will send DNT: 1 for all pages viewed in this user profile:

pastedImage_0.png

And here’s a screenshot of the HTTP request for the main document, showing the header:

pastedImage_1.png

And Munchkin’s Visit Web Page XMLHttpRequest, showing the same HTTP request header and its acknowledgment in the response:

pastedImage_3.png

5734
7
7 Comments
Robert_McKenzie
Level 2

Great information here, will have to read again!

Josef_Lobotka
Level 1
  • it does not stop Munchkin from initializing and setting its _mkto_trk cookie
  • it does not stop Munchkin from sending a Visit Web Page (assuming you're using the default configuration which always sends a VWP on startup)

Ergo, you cannot know if the person would've wanted you to turn off Munchkin downloading/initialization/hit logging.

Marketo's servers should be able to see the DNT:1 in the HTTP Header when the tracking script is requested (https://munchkin.marketo.net/155/munchkin.js).

Surely, they could return a version of the script that will know that the user does not wish to be tracked (e.g. script that contains a variable signalling DNT is on).

Am I missing something?

SanfordWhiteman
Level 10 - Community Moderator

Surely, they could return a version of the script that will know that the user does not wish to be tracked (e.g. script that contains a variable signalling DNT is on).

Yes, in theory, but the CDN would have to Vary based on that header, and local caching would be disrupted.

And consider that a single Munchkin library can send hits to multiple Marketo instances with different DNT settings.

If browser API support were comprehensive, there would be a way to work with all this without sending extra HTTP requests, but we'll probably never get there.

Josef_Lobotka
Level 1

The Munchkin script (https://munchkin.marketo.net/munchkin.js) is using E-tag based caching and no Cache-Control, so the caching shouldn't be a problem (let's assume user doesn't change their DNT settings between page clicks).

And consider that a single Munchkin library can send hits to multiple Marketo instances with different DNT settings.

Agree - that is a complication, but it is possible to deal with this (e.g. retrieve the setting on initialisation). The main problem was that the script could not access the DNT information in the HTTP Header.

SanfordWhiteman
Level 10 - Community Moderator

eTags don't solve the problem of the intermediate cache. The ability of the cache to differentiate on Vary: DNT is the key (no pun intended).

What you're describing just isn't something that's seen in the wild (GA, Clicky, and Piwik don't do it, for examples). It might be possible but there's a lot more low-handing fruit to enhance/fix in Munchkin.

Josef_Lobotka
Level 1

Any decent CDN can serve different content based on the HTTP Request header's value (and cache it).

Additionally, JS API already does have a DNT flag Navigator.doNotTrack - Web APIs | MDN - and it's reasonably well adopted: https://caniuse.com/#search=doNotTrack (98% of browsers). So even this could be additionally used:

    var DNT = navigator.doNotTrack || window.doNotTrack || navigator.msDoNotTrack || window.msDoNotTrack;

    if ((DNT == "1") || (DNT == "yes")){   

      // Load or initialise script

    }}

Yes, other analytical tools don't do it either and it almost feels like it is intentional.

SanfordWhiteman
Level 10 - Community Moderator

Sure, you can wrap Munchkin initialization in that function if you want, it's harmless and will save extra traffic for affected users.  The API will not be supported in iOS nor Safari/Mac in the next release, though... so much for 98%! (That's why I didn't mention its availability in the blog post, because it's dying off.)

And when you consider static tracking pixels (which can't check JS) and anti-tracking plugins (which can selectively send HTTP headers to certain sites, with no visibility to the library author) the effort would be even more wasted. (ETA: Wasted if added to the library itself, not saying you won't get something out of it on your specific site.)

Yes, other analytical tools don't do it either and it almost feels like it is intentional.

If you mean because the service wants to steal the anonymous data, I doubt it. Open source packages behave the same way.  Just not a priority.