We use cookies. You have options. Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.
We’d like to use cookies on your device. Cookies help us keep the site running smoothly and inform some of our advertising, but how we use them is entirely up to you. Accept our recommended settings or customise them to your wishes.

Google Tag Manager Debug Mode Gets Awesome

A stealthy release yesterday saw massive improvements in Google Tag Manager (GTM) debug mode. Having had a sneak preview at the Google Analytics Summit in late May I was eagerly awaiting this deployment and it hasn't disappointed. In summary: more information, more options and greater clarity on how GTM actually works.

Out with the old and in with the new

GTM users will be familiar with the old, shall we say minimalistic, debug mode which simply listed which tags fired and when:

The user experience has been much improved in the new debug mode with the design closely matching that of the actual GTM configuration suite:

As you can see from the image above, we now have a clean, sharp interface with three tabs: Tags, Macros and Data Layer.

Tag it like it's hot

The Tag tab (not to be said quickly!) gives the user several options and provides much more clarity on how GTM actually functions. In the left hand navigation you can see each event that is fired into the Data Layer plus a 'Summary' link.

At this point it is worth noting that GTM only evaluates its rules/serves tags when a Data Layer event is received. By default GTM creates three Data Layer events: gtm.js, gtm.dom andgtm.load. These events can be seen in the image above in slots 2 (Pageview), 3 (DOM Ready) and 5 (Page Load) and occur as follows:


This is created as the GTM container script is loaded. You can see the code that generates this event within the container snippet itself:

The main point of note about gtm.js is that this is the default event used to evaluate rules. If you do not specifically include an event condition within your rule, GTM will implicitly include event equals gtm.js. It is for this reason that it is given the 'Pageview' name as it is the event used for all rules that are only based on URL properties.


This is created as soon as the Document Object Model (DOM) is ready. Essentially this means as soon the main HTML document has been loaded and parsed and it is safe to be dynamically manipulated.


This is created as soon as the web page has fully loaded. It is different from gtm.dom as it will only fire once all resources (images, iframes etc.) have been loaded and not just the HTML document.

Anyhow, enough techno speak, let's get back to the new features! The Summary link is the default view within the Tag tab and essentially provides an overview of all the tags that have and have not been fired on the page.

Drill Down for More Information!

Clicking on one of the tag boxes enables you to view more information about when that tag was fired. Let's use the 'AdWords - Remarketing - PX - Main Code' tag as an example:

Here you can see that our AdWords remarketing tag was fired on the 'Pageview' event and that a summary of the firing rules is provided. Note that within the GTM configuration suite only the default 'All pages' rule had been applied but the new debug mode makes it more transparent that the event triggering the tag is actually the gtm.js event. The URL based condition is then effectively applied as a further filter if the initial event condition is met.

As well as accessing a tag through the Summary view, you can also click on each of the Data Layer events to specifically view which tags were fired on that trigger. Let's look at the 'homeLoad' event which is a bespoke event fired when one of the pictures on our home page has been randomly selected:

Here you can see that only our two main Google Analytics tags are triggered by the 'homeLoad' event. The reason we fire them on this bespoke event is because the picture content is decided client side and this generally occurs after the gtm.js event has been fired. Consequently if we want to pass the correct data into our tags we need to wait until the content has been determined.

Drill Down Once More

Once you have selected a particular GTM event, you can again click into each tag for more information:

By default, debug mode only displays the macro name within the drill down (macros are indicated by grey boxes). However, if you select the 'Display Macros as: Values' option this changes:

Note that the custom variable value is simply the name of the randomly selected image (i.e. site content) and definitely not linked with the user in any way!

The really cool thing about the using the 'Values' option is that, depending which GTM event you are located within, the information shown could be different for the same tag. This is because the information recorded within the drill down will be set at the point the event was triggered which is particularly useful for things such as Google Analytics events where common macros may be used to populate the Category, Action and Label fields.

Moving on to Macros

The Macros tab provides a one stop shop for reviewing your actual macro values. In this instance the Summary link is redundant as there is no real value in a summary report. Instead, you can again click on each of the different GTM events to view the macro values and how they change at each trigger.

We can use the 'Data Layer - homeLabel' macro as an example:

As described previously (and demonstrated above), the macro is undefined at gtm.js. However, when we progress to 'homeLoad':

Here the 'Data Layer – homeLabel' macro value is populated and you can also see that the '_event' and 'event' macro values have also been updated. Awesome stuff and super useful when trying to check why a rule is not performing correctly!

Dealing with the Data Layer

The final tab within the new GTM debug armoury is the Data Layer tab:

Here the Summary link shows each of the objects that have been set within or pushed to the Data Layer (yes, the automatic events are effectively dataLayer.push() calls too!). There is also a box showing the current Data Layer values.

When reviewing the 'Current values of the Data Layer' box it is important to remember that Data Layer object property values are effectively overwritten if a subsequent push with the same name is completed. For example, if I run the following command to set 'homeLabel' to 'Jeff':


Then the 'Current values…' box updates to:

Here you can see the value from box 6 trumps the one set in box 4. It is worth pointing out that 'Message' is a label that is assigned to all Data Layer updates where the object added does not include an event property. It is also important to understand that tags cannot be triggered by such updates. You can see the evidence for this by referring to the 'event' property within the 'Current values…' box: it has not changed from box 5.

Clicking on a specific event within the left hand navigation brings up information on the exact information pushed to the Data Layer:

The 'Data Layer values after this Message' box shows all the Data Layer values (not just those added) at the point the event had been fired. Stepping through each event i.e. from 1 to 6 will show how the Data Layer information builds up and changes with each addition until it reflects the content within the 'Current values…' box.

Hours of debugging fun

Hopefully this blog has raised your awareness of the fantastic new features that have been added to the GTM debug mode but, as always, the best thing is to start using and experimenting with them yourself. I'm pretty confident you will love them immediately and I believe they should save hours of furrowed looks and head scratching.

Just remember, next time you're sitting there screaming 'why is my tag not firing?' or 'why is the macro value not pulling through correctly?' click on the applicable event in the left hand navigation and start drilling down - all should be revealed within a few clicks!

Join the Discussion