My love/hate relationship with Google Tag Manager

SEO & Marketing companies love Google Tag Manager because they are given free reign over their client's site (or Document Object Model at least) and developers despise GTM for that exact reason.

As developers, we are the ones responsible for the website's performance and reliability, but we can't guarantee any of that while 3rd party's are dropping in custom scripts which they found on stackoverflow.

I've seen some awful things happen inside GTM instances so you would think that would drive me to hate the platform, it but it's not the case!

I think there is a lot of miss-use of Tag Manager from a implementation and management point of view as of a result of the amazing level of flexibility which the product gives you. I strongly believe that the actual management of GTM account needs to remain with the web development team and communication still needs to exist between the 3rd party's when it comes to adding tags. Just because the responsibility for tag management can be handed over to a 3rd party doesn't mean that it's a good idea to do so.

So if the developers are to manage the tags then why not just stick to embedding them in the page source and deploy them as we've doing for years? There's still plenty of merit to using GTM even if you keep access to it on a tight leash.

Separation of concerns

Tags are indented for capturing and sending analytical data back to 3rd party tools in a relatively crude manor. To elaborate on this, a typical conversion tag is designed to fire on a confirmation page. The intention is to track conversions of the form, however this implementation requires the tag to be embedded in the actual thank you/confirmation view. This is main reason that physical thank you pages are still so commonly found in existence. Being forced to use a physical thank you page and maintain tags in the view to suit the provider's implementation doesn't make sense to a developer.

The way we need to think about tags is that they are event driven and that they are an optional, non dependent layer on top of the website.

This is what GTM really exists for. Firstly you can reduce your 3rd party tracking scripts to one single GTM container. On every website I develop I always wrap the GTM code in a global setting to enable/disable 3rd party scripts so that it can be turned off completely. If you do run into a situation where a tag is failing and breaking your site, it's handy to be able to switch the whole thing off and on quickly to temporarily resolve the production issue.

A common mistake which I see in GTM implementations is to take the old fashioned approach of creating rules based off physical page URLs. This is a good starting point if you have migrated from embedding your tags in your html/views to housing them into GTM, but it's only a starting point. Creating dependencies on physical page URL's is not a reliable approach for large CMS driven websites.

The proper way to approach this is by defining events in Tag Manager and triggering them from the website. Tag Manager then receives the event and outputs the appropriate tags based on rules which you have set up against this trigger.

Custom variables and events

Within GTM's interface you will see that you can create custom variables and custom events. These are defined in GTM and triggered from the website via the Data Layer. So you define an event such as "Order Complete" and the website triggers the events through JavaScript.

In addition to events, there's custom variables. You can push up page level variables for example - category, channel, brand etc as well as sending up variables with an event itself, for example you can send up an event of "purchase" with some variables such as "sku" and "price". With the combination of events and variables you can create conditional triggers for tags aswell as injecting the variable values into the tag output itself. This can greatly reduce the number of tags required and it changes your entire approach from being dependent on specific pages to being completely rules based.

Debugging

One of the best things about GTM is the debugging console. When you get into scenarios when you have complicated rules and multiple tags firing on different events and at different times it can become difficult to debug and confirm if everything is working correctly. The debug console is a popup that appears over your site on every page load which allows you to see what data is being pushed up to GTM in real time. You can see which tags have been fired on the current page, which tags haven't fired, the custom variable data that has been pushed up aswell as your custom events when they fire.

In my next blog I'll post a the specifics of how to set up a data layer in GTM and how to trigger events for asynchronous JavaScript calls.