Maintenance

The cool thing about Analytics, from the point of view of a developer: once you have set it up, it is completely maintenance-free! Fire and forget! Or is it?

The truth is that a) “once you have set it up” is not the way I would describe Analytics (or other things like targeting, personalisation, testing, …), as it is highly flexible and changes quite a lot over time. Essentially, every data point that you collect can be an answer to something, or it can raise more questions and therefore a desire for more data. Even if your friendly marketer leaves you alone with more requirements, there is b) normal maintenance to do, such as updates.

Let’s concentrate on the latter, today, and let me walk you through the things you should do to keep your friendly marketer and her team of analysts happy.

Updates

I follow @SwiftOnSecurity on Twitter. That person posts a lot of security-relevant stuff, very interesting, and very useful.

In our world, security is slightly less of an issue, which is probably at least in part due to browser manufacturers efforts to make their environments safe. Thanks, browser manufacturers!

But while updating your analytics code might not be as much “self-defense” as updating your Windows or iOS is, you should still do it. No matter what “that computer bloke” says about switching off automatic updates, updating is important, and it should ideally be automated.

If your site uses DTM, chances are your friendly marketer is able to update on her own. All it takes is to log into DTM, click the settings icon next to each Tool, then update them all in turn, approve, and publish.

For some Tools, this is extremely straight-forward, like the Marketing Cloud ID Service Tool:

Don’t forget to hit the save button!

For Analytics, it can be straight-forward:

If you have a small screen, clicking that “Update” link seems to do nothing, but scroll down to the “Library” section, and you’ll see it has been opened and the library setting has been updated.

Now, if you are among those who customise their library (rather than using “Customize Page Code”), you’ll have to update manually, and you won’t even see the notification. This is one of the reason I don’t like that.

If you use a different tag management system, or no tag manager at all, you’ll have to manually update your code. Why not take the opportunity to actually switch to a TMS?

Target doesn’t have a notification or anything. You have to go into the Tool, find the “Library Management” section and hit that “Check for Updates” button.

If there is a more recent version, you’ll see a popup. Click “Yes”.

Similarly, Audience Manager doesn’t notify, either. Just go into the Tool, open up the “General” section, then check whether there are more recent versions under the “Code Version” drop down.

My hope is that Launch will improve on this.

First, I would expect the update notification to be in my face on the home screen of my web property, or even my home screen. Better: put it on every screen! With a button, that just updates everything as needed. One-click updates. And the icing on the cake, for me, would be automated updates, i.e. Launch just automatically always replacing all libraries when new versions come out.

Once you are done with updates, check your site to see they went through. The Debugging Helpers page has all the stuff you need, or use the “Inofficial Adobe Marketing Cloud Debugging Cheat Sheet” (letter or A4).

Good.

Other Updates

I actually spent 2 minutes pondering whether this part should be called “Other Updates” or simply “More Updates”. The latter has more potential to make you groan, dear reader, but this time I chose accuracy over impact.

The thing is: the libraries we just updated are not the only libraries on your site. Chances are your site uses some framework like Foundation or Bootstrap, some libraries like jQuery, and of course there is custom code on it, too, which you or another developer might have changed since you last checked.

All of this can have an impact on Analytics and other Marketing-related tools on your site.

In an ideal world, you would test for this. You’d use the Site Infrastructure Tests framework, or maybe a commercial tool like datatrue. If you do, then congrats, you’re done with this chapter.

Your friendly marketer might also use a tool like ObservePoint or Hub’Scan, in which case she’d likely have noticed issues by now.

Everyone else — time to check all your tracking!

Just to give you an idea of what that implies:

• open the browser console, browse the site, look for JS errors
• using the browser network console, check all pages send tracking
• talking with your friendly marketer or analytics person to see whether they have noticed anything unusual

I’m sure you will be able to handle the first of those, but for the second, there is an aspect of not only checking that tracking works, but also how it works, or rather what data is being sent. This is why you need the third, or a tool that does it for you.

I think I will at some point write a (theoretically and ideally pointless) article about how to manually do all the things that ObservePoint or Hub’Scan (or others) can do, but not today. Those are powerful tools, and that article will be long.

Pro tip: if someone tells you you broke tracking of something, and you figure out that yes, you did indeed, but that happened like 15 months ago — that’s a prime opportunity for pruning!

Pruning

With that, we come to my favourite analytics activity: pruning, otherwise known as “removing things from your setup every now and again, because things go stale over time”.

Pruning helps with a couple of really very crucial things in analytics:

• The simpler your setup is, the easier it is for people to understand the data it generates.
• The simpler your setup is, the easier it is to document it, and to keep the documentation maintained.
• The simpler your setup is, the smaller the risk that you (dev) will break something when you work on the site.
• And last but not least: the simpler your setup is, the easier all the maintenance.

A good example for that last point: if you manage to prune away things that formerly forced you to use custom Javascript code in the Analytics Tool, you can switch to Managed, which will make updating soooo much easier.

New Things

Sometimes, maintenance means changing the way things are currently setup because there’s a new, better way of doing it.

The best example for that happened at some point before 2009, when “Dynamic Variables” were introduced. Among other things, they help keep the tracking call URL short, and lots of people went and implemented them, yours truly included.

(I’m writing “at some point before 2009” because I can’t find the release notes for anything before 2013, and I frankly don’t remember when they were introduced. Earliest mention I found was the Trimming the fat with dynamic variables blog post by Ben Gaines.)

Another good example is the Marketing Cloud ID Service, aka Visitor.js. It is a foundation for integrations, plus it handles visitor IDs in a more modern way, so off we all went, implementing it everywhere.

Or think about how AppMeasurement.js superseded s_code.js, and at.js supersedes mbox.js.

These things happen, and depending on how involved you are with the marketing infrastructure on the site, you will sometimes notice and drive changes yourself, sometimes you’ll react to your friendly marketer prodding you. That’s fair enough.

Cha-Cha-Cha-Changes

The biggest thing to keep you on your toes, though, is going to be analytics itself.

Your marketing and analytics folk will never be satisfied with the data they get, they will always thirst for more, or different data. (If they are satisfied, I would be suspicious.)

Technically, this is not maintenance, but rather an aspect of the fact that there is no traditional “implementation phase” in analytics.

If you read this blog, you’re probably used to that by now, and so I wish you happy maintenance and thanks for helping your friendly marketer! I’m sure she appreciates it.