It’s been a long time coming! GTM doesn’t usually have massive updates for us. We are constantly asked to refresh our containers with a message saying there’s a new GTM version available, but their release notes are rarely updated. We’d love to see a more frequently updated RSS feed (which we monitor automatically) talking about what these updates are. Nevertheless, a very big change is coming to GTM. Duga has already talked about the highlights in our latest post, but here I want to go through some of the UI updates. What changes, what stays the same, and what you have to do.
Update Process
First things first, know that this is an optional update. Your container will continue to work as it is. This update, if accepted, will change the container behaviour to deploy, with your GTM container, the Google Tag. There are some configurations that will need to be done, but if you’re still in doubt after the explanations below, just let us know and we can go through them together. Once your container is eligible for the update, you’ll be prompted with this banner:
This will lead you to a Setup window, in which you you’be be able to view the settings of you Google Tag and select, if any, which settings you’d like to import to your container:
Once you click to add them to the workspace, Destination tags will be added to your workspace (I’m calling the Destination tags. It’s not in the name in the UI, but the container JSON has their type as dest_ga or dest_aw, so it seems fitting). Let me say that again. Destinations are now easily configured in the workspace! You can edit, test them, roll back, share the updates with other users, all before making a commitment to a change! This is massive!
They are currently created without a trigger, so remember to add the Initialization trigger on them.
If the destination tags are not present, or pause them, the container reverts back to its old functionality. None of the in-UI Google Tag Settings configurations will be applied, you’ll need to add the Google Tags to the container, and the Preview mode updates seen below will not be present.
These destination tags look very similar to the Google Tag, which will be deemed legacy in the new containers. They have the same parameter fields as send_page_view, server_container_url, and even the Configuration and Event setting variables are still called ‘Google Tag settings’ tags. While this isn’t the biggest leap forward in the sense of less configuration, this new tag has clear advantages over the Google Tag, giving you a lot more control over what happens in preview mode, and over the Google Tag itself, which you can now configure in-UI (next topic).
UI Updates
What is really cool though is the new UI. There are at least two, so far, interesting additions.
Google Tag Settings
FINALLY! We, long neglected loyal and ever optimistic GTM users, finally have a straightforward way of editing the Google Tag! And even better, the changes that we make to it here are confined to the current workspace, which means that you can test Automatic event detection, User provided data, and other settings locally in your workspace. They just go live after publishing, and the changes even appear in the Overview tab!
Needless to say (or maybe I really should say it), proper governance becomes even more important now. Being able to edit the Google tag here is a great step up, but if people with different permissions, in different platforms, can do the same, things can get messy. At Duga, we double down on GTM being the one stop governance shop when it’s being used and would love to see Google support this notion. We look forward to Google’s governance recommendations.
Container Overview
Since the container now is responsible to load the Google Tag, we have right on the Overview tab, which destinations are configured in this container, and how many tags with these destinations are present:
A destination should always have a Google Destination tag configured for it, just like before it needed a Google Tag. Now though, you can have both. You can add a Google Tag to the container, and it will add configurations to the specific destination of that Google Tag. We are still exploring what this functionality directly solves and if there are use cases when it’s optimal to have a configuration like this. With the Google Tag appearing as legacy in the container, we imagine this won’t be possible to do in the future.
Preview Mode
Our good old friend Preview Mode also got a massive update. Let’s go through everything:
First, the destination UI is now inbuilt in the GTM tab. Every dataLayer event, message, Google event or gtag update are all in the same tab. Although this may look confusing at first glance, it makes debugging A LOT easier. We can now easily follow the order of events that were triggered by a tag in GTM without having to flicker to multiple tabs trying to find when they fired. For instance, we can see our Destination Tags firing on 2, the resulting Config on 3 and Google Ads hits on 4, which were deferred due to consent, but were sent properly on 8:
With events, we can see the GA4 Page View tag firing on 5, which generates 6 Page View, where we can see the hit sent to GA:
The same happens for a click that triggers both Google Ads and GA4 in 12. It generates the 13 Google Ads Conversion, and the 14 navigation_click GA4 event:
In addition to this update, the Preview Mode also displays the Tag Settings in its UI now. On Summary, as we’ve seen above, we can see all the Tag Settings, but on the individual events we can see them being evaluated and their values:
Seeing some of these configurations here is cool, and we think it’s a good step in understanding what you’re previewing. Having a simple hide button though, like the one that exists to hide all tags that have not fired, would go a long way in keeping the UI tidy if you don’t need to see them, while still being able to access them if wanted.
Verdict so far
Overall, I like the direction Google is taking with GTM, the Google Tag, tracking, UI choices, and governance. Having a unified place to manage your tracking, and having fewer configuration points to implement it is a positive update. Although the configuration of the Google tag and Destination tag are very similar, they provide very distinct functionalities, and exploring and discovering its differences has been really fun.
Being able to see, edit and test the Google Tag Settings locally in your workspace before going live with it is a massive win. We’re really happy with this update.
Lastly, regarding the preview mode, the new event structure makes it really easy to understand the cause and effect of every tag that has fired in the container. This update is also great, and we can’t wait for clients asking us how it all works.
What did you think about this update? Do you think you understood everything it entails and what you have to do?
If you want to start your journey for better data, give us a shout at Duga and we’ll take it from there.