Google Tag Manager is a firm favourite here at SearchStar and we will always recommend it to clients looking for a way to manage their website tracking scripts. However, switching to a tag management system can be a little daunting. A big consideration during any migration is how we ensure that there is only ever one Google Analytics tag running at a time. Multiple tags mean a reduced bounce rate, higher pageviews and therefore higher pages per sessions. On the flip side, no Google Analytics tags running at all results in loss of data. Put simply, it messes up the Analytics. So we set out to find a solution.
We can’t go any further in this blog post without mentioning the team at Upbuild. Mike Arnesen, posted about this exact issue back in November 2015, and came up with a really great solution. But when we started using it in the real world, we stumbled on a couple of issues and added a few of our own tweaks. So, in the spirit of communal knowledge, this post will run through SearchStar’s adjusted solution and hopefully make your transition to GTM a little bit smoother.
Implementation
We’ve neatly packaged everything up in a GTM container to make implementation as simple as possible. To get this running on your website, import the container by following these steps.
1. Download the file searchstar-ga-migration.json
2. In GTM, navigate to the Admin tab of your Account and select Import Container
3. Choose the container file you just downloaded
4. Select either a new or existing workspace depending on your current container set-up
5. Under import option, choose Merge, and select the radio button to rename any conflicts
6. Click confirm to import the container
7. Navigate to variables and replace the value in {{GAID}} with your Google Analytics property ID
When you publish the container, the analytics page view tag will fire on every page, provided a hard-coded tag featuring the same property ID isn’t present.
This means that whilst a hard-coded tag is still present, the GTM container will sit tight and there will be no duplication of data in GA. As soon as your web development team remove the hard-coded tag the GTM container will kick into action and start firing the page view tag. The result is no disruption in GA data through the tracking update.
Under the Bonnet
This solution all hinges on a custom JavaScript variable. This variable checks the source code of a webpage in search of either the classic or universal analytics tag code. If this search turns up trumps the script looks deeper to verify that the analytics tag is actually live on a page and the property ID matches the analytics tag you want to fire.
It does the first of these by searching for single line and multi-line comments. The second check is achieved by searching for the {{GAID}} variable in the hard-coded tag. This is why it’s important to update this constant variable after importing the container.
Once these checks have been made, and a conflicting hard-coded analytics tag has been identified, the script returns the value TRUE. When this happens the trigger in the container will intercept your page view tags and avert any double counting. If the script returns FALSE, we’re good to go and the GA page view tag will be fired, ensuring there is no gap in analytics reporting.
Location Location Location
Whilst the custom JavaScript variable is great at scanning pages in quest of hard-coded analytics tags, it can only find tags that are available on the page when GTM first loads. This basically means it can only find GA tags that are implemented above the GTM container script in the source code of the page. If this isn’t the case on your website, luckily there is a handy loophole.
By changing the trigger types from Page View to DOM Ready, the tags are delayed until the entire DOM of the page has loaded. The JavaScript variable can then check the whole page for hard-coded tags. Remember that the trigger type needs to be changed for both the trigger firing the analytics page view tag, and the trigger being used as an exception.
Because it’s scanning the page, our JavaScript variable also can’t detect any analytics tags being fired from within other tag management tools, including other GTM containers. If you’re in this situation, reach out to a user with access to the tag management tool and ask them to remove the analytics tag from there.
We have already used this script in real life situations with great success. We recently managed the migration to GTM for a charity client, which also included upgrading Classic analytics to Universal. We had tested all tags were working correctly in a stage environment, but we had to ensure that the GA tag within GTM started working at the same time the hard-coded GA tag was removed. The script made the transition seamless and ensured no downtime of tracking and no broken analytics.
If any of this went over your head, or you simply want a hand to hold during the migration to GTM, get in touch with our analytics team and they will be happy to assist!
