In recent years some fantastic content management and publishing platforms, both commercial and free, have come to market. I’m using one right now to publish this post: WordPress. Hopefully you use one for your site as well. (Side note: If you don’t use one, talk to your tech folks – you really should be. We may be able to help you choose one, and measure its use effectively too.)
The most interesting of them integrate a variety of other services, including social media and discussion features, analytics and remarketing, and lots of other tools. Sometimes these are supported by way of third-party plugins, and in other cases they’re built into the core functionality of the platform.
Tag Management: The Good
If you’ve paid any attention to the Tag Management space over the last couple years, you know that Google Tag Manager is winning. Organizations who recognize the simultaneous needs of governance, manageability, and rapid flexibility in analytics and marketing technologies (especially on the web) are adopting tag management solutions. Tag management (generally) remains especially important for the biggest sites, but we’re recommending it to all of our clients. We see it as simply the most effective approach, and since Google Tag Manager is free, anyone and everyone should consider adopting it.
Tag Management: The Bad
Unfortunately some of the content management and publishing platforms actually make life harder for emerging standards; they lock you into certain template structures, and limit your capacity to install third-party tools. Today’s example: Google Tag Manager (of course).
What complicates things with Google Tag Manager is its requirement for two separate snippets: one in the HEAD for the datalayer, and one directly in the BODY for the container loader, preferably at its top. Admittedly this pair of tags is a bit more rigid than Google Analytics has been, but the complete inability to support one or both of these components is extremely frustrating for us and our clients.
Recently we began using Hubspot for a variety of reasons, including the ability to wrap our social, email and web into one tool. Their tool has been very impressive in a wide variety of ways – but very disappointing in the fact that it does not have native support for tag management.
A few of our clients have actually migrated away from HubSpot due to its lack of support for Google Tag Manager’s installation model. They wanted to use Google Tag Manager, and couldn’t make HubSpot effectively support it, so they moved on to use other CMS/publishing platforms.
Tag Management: The Ugly
During the Hubspot evaluation process we talked with their sales engineers at length, trying to find a way to get GTM installed per Google’s recommendations. There may be a really convoluted way to make custom templates and install GTM properly within them by editing the HTML directly. Unfortunately you can’t just swap out global parts of the templates though: if you need to update your blog theme, every single post would have to be updated to use a different (newly customized) template. We can’t really take this approach seriously, it’s just not sustainable for companies that also apply A/B testing and related optimization techniques, as we’re making regular changes.
There’s Still Hope
Time for some good news; it can be made to work.
Among others who’ve worked with GTM extensively, this may not be so surprising: all you have to do is remove the <NOSCRIPT> block and its <IFRAME> to let the container loader tag run in the <HEAD> of the page. This it comes with a caution though: we’re customizing our GTM container loader, and Google’s developers test against their specific recommendations for compatibility, so there’s a chance that future updates in GTM may cause unexpected behaviors. Some kinds of tracking and some tagging might get interference from this change.
We also have needed, in some of our client cases, to load multiple containers simultaneously against the same DataLayer. Typically running two GTM container snippets on a page causes the “gtm.js” event to be triggered twice; in many configurations this causes duplication of the tracking code oriented to each page (and in some cases even greater multiplication). To support the handling of multiple containers, we further customized the GTM loader tag as well. The draft you’ll see below can now support any number of containers simultaneously. Realistically though, running several containers on a page will become a maintenance problem, so we recommend keeping it to a minimum. One is generally sufficient – two covers the majority of the most advanced cases.
All that’s needed now is for you to install it. Just copy the snippet below into the <HEAD> of your pages. On HubSpot, that means opening the “Content Settings” option from the “Content” menu, and in the “Page Publishing” options, paste the snippet into the “Site Header HTML” field.
Lastly, if you need any help with your platforms, Analytics Pros would be happy to help you get set up with GTM. May the data be with you!
The code is available as a gist on this link.
* Note that other platforms may require alternate instructions, as the specifics above are targeted at HubSpot.