Tracking Versions

I have seen a lot of different people do the same thing: track some sort of a version of their tracking setup. It makes sense, because it allows you to track down bad choices in your tracking.

Questions like “so when did we lose the site section eVar?” or “Do you remember when we started tracking social clicks?” can be answered if you somehow track your changes.

In the olden days[tm], this meant coming up with some version number yourself, then maintaining it, usually inside the s_code.js file.

Now we have tag management, and that makes things easier. It also makes things more varied. Allow me to demonstrate, using DTM.

Versions – Core

What version, asketh thee, shall I track? What version?

The core Analytics code comes with a version, e.g. “H.27.4” or “JS-1.7.0”, which you can find on the tracking call URL, or on the console like so: s.version. (Or, if you’re using DTM, something like s_c_il[0].version)

DTM Javascript code has a version, e.g. “6I2”, again visible on the tracking call URL (with a prepended “D”, “D6I2”), or on the console like so: _satellite.appVersion

Those two are pretty much independent from your work, in the sense that they are controlled by Adobe. There will be releases every now and again, changing those numbers. All other Javascript is controlled directly by you, in DTM, so it is in your hands.

Versions – DTM

It’s fairly difficult to apply the concept of versions to the code you manage in DTM, but what DTM does for you, is show a history of the changes you published!

That history kind of works like a version, and, better, the date of the last publish is available in Javascript: _satellite.publishDate. On top of that, you can get _satellite.buildDate, which is the date at which DTM finished building the library after you published it.

These two dates are directly linked to your activity in DTM.

Versions – Others

Some people use versioning for their requirements. I have seen Solution Design Reference documents or Tech Specs with a version number. That is obviously a pretty good idea.

And if you want to go full nerd, you can apply versioning to the tracking of versions that you use.

What?

Well, for a specific company in Switzerland, I started tracking publishDate + buildDate. Later, we consolidated Analytics Report Suites, so we needed to add the name of the DTM Web Property to the version in order to tell which DTM property was sending the specific data we were looking at.

Then, I added the requirements version, and at that point, I realised that I should probably track the version of the Data Element that gave me the version string, so I knew which ones were up to date.

While this seems to be over the top (just slightly), it actually serves a purpose: I can now build rules in the Classification Rule Builder that pull my version string apart, no matter what the current version of the version tracking.

Do you do something similar? How?