For many, Google Analytics (GA) has become a de facto standard for web stats. It doesn’t cost anything, it’s easy to implement, and it will send you a lovely graph-laden PDF for reading, printing or framing, and to tell your boss how your website is doing.
But GA has some disadvantages:
- GA tracks page-views based on URLs for pages that have the code embedded. If you want to track special activity like video watches or outward link clicks, you either have to place code in the HTML for each item you wanted to track, or use a third party script on the page to add it for you. Generally speaking, you either have:
- configurability — you can be specific about what you track
- scalability — you track everything, everywhere, even if you don’t actually want to.
- On a Content Management System (CMS), making changes to your code may involve changing templates, which means developers. That can be expensive.
Tag Manager to the rescue
Google Tag Manager (GTM) solves these (and other) problems, but should be regarded with a great deal of caution. To explain, let’s have a look at how GA and GTM work and differ.
Usually you’d put your GA code snippet on your page (before the
</head> tag or at the bottom of the page depending on the version) and it would just work: retrieving and sending whatever it needed to and from Google Server Central to fill in the numbers for your monthly PDF. You can leave it alone from that point and take a well-deserved nap.
If you want GA via GTM, you give it a GA tag to manage and tell it to fire that script on every page via a colourful, pointy-clicky interface. Simple. Even better, if Google ever decides to update the tag, that will happen either automatically or you will be able to change it on all your sites via the Tag Manager interface.
If you want to track an event like an outbound link click to see where people go from your handy page of useful links, you give GTM a GA Event Tag to manage and then tell it to trigger, for example, only when the URL is Page-I-Want-To-Track.html and the link
href doesn’t include "mysite.govt.nz". The results show up in your GA Events section.
You can do all this on the GTM interface in the cloud without even logging on to your website. So that’s pretty clever, too.
- Need a third party heat-map snippet on some pages? Set up a tag for the pages you want to track.
- Your SEO company wants to iterate AB testing? You can give them access and let them manage it for you.
- Need multiple GA tags on one site for a needlessly complex reason? GTM can handle that too — as long as they are Universal Analytics style.
Ruh roh! Danger Will Robinson!
When we were first asked about Google Tag Manager (GTM) we could immediately see the advantages. Build and manage tags across multiple sites from a single interface? Sign us up!
But then we looked a bit closer and alarm bells went off. Our reasoning went a bit like this:
- IF: GTM is a cloud based solution, you can log into it from anywhere
- THEREFORE: SO COULD POTENTIALLY ANYONE, ANYWHERE! MASSIVE SECURITY ALERT!!!
Managing the risk
The first thing to do is admit that, yes, it is a risk. There’s no two ways about. But there are methods to mitigate the risk — so when we approached our security and architectural teams, hat in hand, for their blessing, we agreed to manage our GTM account in the following ways.
Like GA, you can grant specific GTM access rights to any Google account. If a third-party vendor wants access, we give it to them, but, for security reasons, we only ever grant them the rights to view, edit, and test tags. Handily, testing tags is done via the browser you’re logged in on — it won’t ever affect normal users.
Publication permission to the live site is limited to one particular account, a master Google account. The password is changed regularly and only circulated within a very limited team. It is never given out beyond the team, let alone outside of our organisation. Everyone within that team is covered by our Code of Conduct to behave responsibly.
GTM helps this process by versioning everything and enabling easy access to each of the changes that have occurred since the last published version of your GTM container.
This mitigates the risk substantially, but there is another step to take to be absolutely sure.
Even if you have a fantastic password, you should set also up 2-step verification on your containers. This limits publications of tags to people whose login has been confirmed via SMS to a particular cell phone. There are a few other methods of authentication available to you, from backup phones to premade authentication codes, to make sure your personal work phone isn’t a bottleneck if you happen to be away that day, but the principle remains the same. Only double-checked logins to the master account have the ability to publish changes to the live site.
Once you’ve authenticated on a particular computer or device, you don’t have to do the login 2-step again on that machine for a while, but you’ll still need the password.
And that’s basically it. Three steps to a secure GTM experience:
- Keep publication rights on GTM to a single, guarded account
- Set up 2-factor verification of logins to that account
- Set up each of your GTM Site Containers to require 2-step verification for publishing under Admin/Account Settings
Nothing is one billion percent secure in this world, but short of catastrophic implosion of your GTM team, those actions should keep you, your GTM Account, and your sites as safe as possible.