Versioning Your Tracking

Here comes a good idea: make sure your s_code.js file has a version!

There are three parts to this tip:

1. Put the s_code.js file into your revision control system.
2. Make sure the file has a version on the URL.
3. Track the version of the file into Adobe Analytics.

Let’s go into these one by one.

Revision Control

You might remeber that the s_code.js file contains 4 parts:

1. a section with configuration variables,
2. the definition of a useful callback method called s.doPlugins(),
3. space for defining “plugins“, and
4. the core Javascript code that defines how Adobe Analytics works in the browser.

Of those 4 parts, only the core Javascript code is provided by Adobe. The other 3 are your repsonsibility. You will likely modify and amend the configuration, add plugins and add custom code to the s.doPlugins() method.

That means the s_code.js file is a source file like any other in any of your projects. And as such it should really be under revision control!

Version on URL

When you change something in the s_code.js file and push the change live, you’d ideally like that change to apply to all visitors of the web site from that very moment on.

Unfortunately, caching can play tricks on you.

Usually that doesn’t matter that much, but sometimes you change things in the file that are not working very well in parallel to old versions, like for example if you reassign a “variable” or an event.

So in order to break caching, we recommend that you add a version to your templates, if possible.

Instead of loading the s_code.js file like so:

  <script src="/include/s_code.js></script>

add a URL parameter with a version, like so:

  <script src="/include/s_code.js?v=2.5.4"></script>

There is one drawback — you will have to update all your templates whenever you release a new s_code.js file.

An alternative could be to only add a major release number to the templates so you only have to update them when there is a major release of the s_code.js file, such as a core Javascript update or a big change.

Track the Version

My all-time analytics hero Adam Greco wrote about this 2 years ago: Track Your JS File Version. The tip is still valid.

Adam looks at it from the point of view of an analyst or someone who provides insight or data. Naturally, trust is the main issue as well as the possibility to quickly find the root cause of issues. For you as a developer, the latter is vital.

All you have to do is to agree with your friendly marketer what “variable” to use for this — say prop10. Then you write the current version of the s_code.js into prop10, like so:

  s.prop10 = "2.5.4";

Some people go further and add the release date to the prop, like so:

  s.prop10 = "2.5.4|2013-05-25";

Two advantages:

1. Even easier to spot whether data anomalies in the reports correlate with releases of the s_code.js file.
2. Very easy to see how “old” the core Javascript code is.

Neither of these three tips will save any lives, but they will make everyones lifes easier, especially yours!