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

[Screenshot]

Analytics Tracking Call with Versions

[Screenshot]

Browser Console with Versions

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!

[Screenshot]

History of Changes in DTM

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.

[Screenshot]

Version Data Element

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?

About

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Posted in Automation, DTM, Javascript, Tips
5 comments on “Tracking Versions
  1. Lukáš Čech says:

    We do something very similar, but it depends on the project.

    Mostly I try to track:
    * DTM Version – we recently experienced a bug in DTM itself and needed to monitor if the newer version will solve the issue
    * AppMeasurement.js Version (similarly to what you mentioned here) – to see when particular features (i.e. the new Activity Map Plugin) became available
    * Some alternative to our own versioning (property-ID + build version) – we maintain parts of the custom code in GIT and there we do a pretty standard version tags generated to the code by build scripts
    * Build/Publish date I only use in Properties served from the Cloud

    Like

  2. Pedro Monjo says:

    I’ve done it a few times with some customers. However, I must say that I have not always seen a benefit in doing it.

    Like

  3. Sebastian Damm says:

    Great article!

    Another versioning option that we use in app tracking is to write the (integer) build-number of the app into a numeric event with every hit. This enables us building a segment checking “greater than version XY”. It’s very useful, e.g. if a feature was poorly implemented and tracking only has valid values from a specific version on. Dates would not help here, as people still might use older versions of the app and with checking for a specific version, we would need to change the segment every time a new version appears.

    Like

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: