Analytics rollout across multiple websites? Don’t cry, Google Tag Manager is here!

“It lives, Igor!” Or so I wanted to shout out across the cafe as I was sitting working on my laptop. Probably best that I didn’t.

After months of architecture documents and repeating the phrase “from an analytics point of view…” as part of a website rebuild, it was time to put my process to the test.

Part one had gone relatively well; we had implemented Google Analytics and a host of other tools on a brand-new website platform using Google Tag Manager. A modular, flexible, and distinctly accessible solution had largely come to fruition. Though satisfying, the next stage was to do this at scale and roll out the implementation across multiple international websites sharing the same platform. We could have done this by painstakingly going through and manually copying bits of the configuration for each website, but who wants to lose yet more precious life force to such a task?

Although we still have some way to go, we have moved beyond the nighmarish Frankenstein’s monster digital analytics implementations of recent history. You know the ones I’m talking about: spaghetti code of analytics and digital media tags, placed willy-nilly across websites with no maintenance or decommissioning plan. Obscure tags, platforms, and variable names; each successive analyst having to grapple with and understand the mess before admitting defeat and resorting to copy-and-paste and making yet more incremental tweaks.

With Google Tag Manager now mature, hopefully that is now a thing of the past. Furthermore, I was able to use its godsend of an export and import feature to replicate my initial modular tag implementation across multiple websites, with only minimal hacking. The process is devastatingly simple. Any Google Tag Manager container can be exported as a JSON (JavaScript Object Notation) file. Think of this almost like a HTML file that just structures all of the settings for your Google Tag Manager container. If you’re a techie, you can then edit the JSON directly to arrive at a “template” version of your container with the core tracking for all of your websites. Alternatively, just create a template container in Google Tag Manager itself, or export/import your initial website’s configuration to a new container and edit everything in there. This requires virtually zero interaction with code and significantly reduces human error in setting up tags and triggers.

I’ve been around long enough to know that pretty much anything that can go wrong with websites and digital analytics tracking will go wrong at some point. The number of unknowns in website projects can’t be underestimated. No matter how much planning you do, there is always that real sense that you just don’t know how exactly something will work until it happens. Particularly in analytics, where to some extent the nature of the beast is to be reactive to content and functionality. That’s why I was so amazed when this process “just worked”. Perhaps we have finally reached some sort of equilibrium point of modern, reliable content management systems working nicely with tag management and templating.

Of course, the tags, triggers, and variables need to be set up sensibly and hand-in-hand with the platform and content. I’m not going to let Google Tag Manager take all of the credit. But you could do a lot worse than create a robust and replicable tagging architecture leveraging solid understanding of your content management system and Google Tag Manager.

Bonus advice: involve analysts in website projects from the outset and take much of the pain away from tracking the digital data and deriving the insight that you really need.

linkedininstagram

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.