In the early days of digital analytics we chipped custom tracking code into stone pages using flint JavaScript knives. As long as you had the code on the page the tracking worked. Analytics carved in stone--unbreakable. Then developers forgot to put the code on pages so it failed anyway.

Stone Tablet with carvings

Tag managers simplified the task of getting more complex code on every page. But as tracking gets even more complex it becomes more fragile. Our stone tablet is now a thin sheet of glass.

Ok, I’ve stretched this analogy as far as I should. I could go further but for the sake of humanity I won’t.
The point is that the analytics implementation that you spent considerable resources and time on is more fragile than you think. The main problem is we depend on the page for the items we need to track the page. This circular dependence breaks if either the tracking code or the page code changes. This becomes a larger issue as sites become more dynamic.

Let’s take an example. Your highly skilled but poorly paid analytics implementer puts tracking in place on your add-to-cart button. This is a critical conversion path action that you want tracked.

Add to Cart button

To trigger on this we use the class name, from the page code:
<bla bla class="blue-button" bla bla> (bla = highly technical stuff what you don't care about anyway)
Basically we tell tracking, "When you see a click on something with class = 'blue-button,' track it."

Joe Genius in Marketing gets the great idea that a red splash would work better. After we convince Joe that he doesn’t need to use the site testing tool to run a test on 3978 different shapes with 476 different colors (just because we don’t like Joe) we change the page to use a red splash.

Add to Cart red button

Joe's never been known for subtlety.
The page code is now:
<bla bla class="red-splash" bla bla> Our tracking looking for the blue-button now finds nothing to track. Our add-to-cart rate falls to zero. Obviously Joe’s red splash just ruined our site and no one is ordering. Or our tracking is broken (We should still blame Joe.). So how do we keep our tracking from breaking?

One simple method is we can add trigger items to the class field. Multiple classes can be added with a space as a separator. For example:

<bla bla class=“blue-button track-me” bla bla> <bla bla class=“red-splash track-me” bla bla>

Now we set the tracking to fire on any “track-me.” Less likely to break but we still need to go further to keep this from shattering (I lied about stopping the glass analogy.).

The first thing that will happen is the site developer won’t know what class=“track-me” means. He will look in the CSS and since this isn’t a real class it won’t be there. So let’s put something there.

In the CSS you’ll see the different classes with their properties:

div.textimage {
float: left;
margin: 0 8px 8px 0;
}

Add one for our tracking class:

.track-me {
/* This class marks analytics tracking elements */
/* doom will fall on whoever removes this from an element */
}

The /*..*/ marks this as a comment so the class won’t affect anything on your page. The comment also tells the developer what this does so they leave it in. Along with a subtle threat for Joe.

For advanced uses you can use different classes to differentiate the event types. For example:

  • .track-me-contact
  • .track-me-productView
  • .track-me-cart

If you don’t want the information in your class structure you can use an alternate HTML5 attribute. For example, we use data-gtm-event.

<bla bla class=“red-splash” data-gtm-event=“contact” bla bla>

This has a couple of advantages:

  • It is in a separate attribute so it doesn’t get confused with regular CSS class structure
  • You can name different types of events in the code

And Disadvantages:

  • There’s no built-in documentation like in CSS class so your developer may just remove it as an item that doesn’t do anything (from their point of view)
  • May not be picked up by older browsers that don’t support HTML5 attributes (IE 7 and 8, not even going to consider IE6 and older)

In either case, class or HTML5 attribute method, your website development process documentation should cover the methods used and inform the developer of what items should be transferred between elements during changes. That will help your analytics implementation be less like glass and more like stone.

Curtis Smith is a Senior Technical Analyst with 6D Global.