SHARE

New interface and workspaces in Google Tag Manager

Google Tag Manager has recently had quite a revamp to its interface. Not to mention the addition of much talked about workspaces feature.

Google Tag Manager (GTM) is a great tool that saves the development and implementation time, and the new drastic changes in any of Google’s tools can be quite a shock when you’re used to one way of workflow. The latest changes to the interface are radical but as with everything else, it just takes a short while to get used to.

GTM still works the same, though. There’s no change to how your tags, triggers and variables are set up.

So let’s see what’s changed!

Overlays on top of overlays

This is the biggest change in the interface!

Whether you’re creating a new tag or changing an existing one, you’ll be making your updates in overlays that slide in from the right hand side of the screen.

Whilst this may be confusing initially, this is a great improvement on the previous workflow. Before you had to create your variables before the tag, or if creating the tag, save the progress, then create the variable separately, and then return to the tag to add in your variable. Too many steps!

The new overlay doesn’t cover the whole screen and instead, leaves a bit of space on the left so you can see where you started from.

Now that I’ve embraced the workspaces, I’ve realised how great it is to be able to do changes and updates without navigating elsewhere.

Icons replace colours

Previously, when viewing a list of tags all the triggers were colour coded so you could quickly see types of triggers used.

Now, they’re all grey with icons at the beginning.

I’ve previously found the colour coding very handy in quickly determining where the tags have been set to work. I’m not convinced that the icons will do as great of a job, but like with all of the changes – just embrace them and move on.

List of variables

They’ve lost the ‘enabled built-in variables’ section at the top. It used to have checkboxes so you could quickly enable or disable select variables. Now you have a list of built-in variables and for any changes, you have to click ‘configure’ button and then select which ones you want or not.

And of course, you’ll have to do these changes in the overlay that slides over.

The variables you’ve created previously will be in a separate list when you scroll down the page.

If you want to view the details of the variable, then you’ll have to click on the variable and see its setup in the new overlay.

Remember, remember…

Do you tend to forget to specify your container’s name and description?

Now you get reminded to do so when you click to ‘publish’ your container and haven’t set the details.

Timestamps

I love it when a small change can make a big difference! This is that kind of change.

When hovering over any relative timestamps in the triggers, overview or other sections, you will see the exact date and time of the latest change.

What are workspaces?

Workspaces are multiple containers that teams and users can work on without worrying about publishing someone else’s updates that may not be ready to go live.

For someone working within a number of teams, like we do, this is a very welcomed update. After using it for a few weeks, I’ve already seen improvements in the speed of publishing updates. Now, fewer people have been blocked from progressing on their tags, which is really great!

So now you can make your additions or amendments in a separate space and publish them when they’re ready. What really happens when you publish is that anything new in your workspace gets added to the default workspace. This may include any updates to tags, triggers, variables, and any notes you may have added.

If you can, stick to making smaller sets of changes within workspaces so you have a more robust version history, allowing you to trace updates and roll back to previous versions more quickly.

You’ll get 3 workspaces in total so 1 default one + 2 custom workspaces, whilst 360 accounts get unlimited workspaces.

Here’s how they work.

To create a separate workspace click on the ‘Default Workspace’ in the left panel.

In the new overlay click on the + icon in the top right corner.

Now enter the name and description for the workspace so when you choose a workspace you can quickly see what’s being worked on in there, or what the purpose of the workspace is. You can always refer to these for information on what was worked on or published as part of this workspace.

A new workspace will always be created based on the latest GTM version and include the latest tags, triggers, and variables.

If you’re publishing a workspace that has conflicting updates with another workspace, then GTM will let you know and give you the option to resolve conflicts in their very easy to use conflict resolution tool.

Once you publish the non-default workspace, it will be automatically removed.

Better tag management

You know how GTM has a number of tag templates for the most typical tracking needs, for example, AdWords and DoubleClick. These templates are very useful for creating and maintaining tags without codes, allowing to insert only required data, and making the whole process less error-prone.

Well, they’ve expanded their selection with additional templates from vendors such as Bing, Twitter, Hotjar, Nielsen, Yieldify and many many more. I’ve been setting up a number of tags from the new vendors so I’m glad to see they’ve finally caught up with this.

So these are some of the most notable changes. My favourite ones are overlays, timestamps and workspaces for reasons I mentioned above. The overlays don’t seem to have got much love when they were first launched, but it’s definitely a step up on the previous workflow. Got strong feelings about any of the latest updates? Let me know what you love or hate in the comments below.

Violetta

Subscribe to our blog

Related posts

Littledata’s Shopify app is updating to use Google’s latest tracking code library. This will simplify your setup for Google Ads and speed up your site.
Google’s ‘global site tag’ or gtag has been live for a year now and is stable for Littledata to adopt. In version 5 of our tracking script we now use gtag for all the events sent to Google Analytics.
The advantages of gtag are:
Integrates with Google Ads out of the box – no need for separate Google Ads conversion tracker
Smaller Javascript library = faster page load times
Future proof for using Google Optimize
In addition, we are now using the standard 'data layer' format used by Google Tag Manager. This will make it easier for all you hackers to extend Littledata's tracking and use GTM with the enhanced ecommerce data layer, and easily create tags for marketing platforms like: Facebook, Criteo, etc.
[subscribe]
We've also moved to using the default ecommerce event naming recommended by Google. For example, the event category 'Ecommerce' is now 'ecommerce' (lower case) and event action 'Add to cart' is now 'add_to_cart' (snake case). If you have goals or reports based on the old event names you may need to update them.
One final change is that we're only sending page views to GA when the page is not hidden in the browser. Certain advertising campaigns, including SnapChat ads, preload your webpages to provide a faster experience for users, but this skews your analytics with lots of low-grade visits who didn't actually 'see' your landing page.
How to update the script
If your store already has our tracking script installed, just click on the in-app notification to update.
Not a Littledata user yet? If you're struggling with implementing Google Ads conversion tracking or GTM for a Shopify store, check out our Google Analytics connections for Shopify and Shopify Plus stores. Let our app fix your tracking, so you can get back to business!

In two high-profile data breaches this year – at Ticketmaster and British Airways – over half a million credit cards were stolen via a compromised script inserted on the payment pages.
Google Tag Manager is a powerful tool which enables you to insert any script you want onto pages of your website, but that power can used against you by hackers if you're not careful – and below we’ll look at how to stop GTM being a security risk on your payment pages.
Firstly, how did the hackers get the card details from these sites? And how is it relevant to GTM on your site?
Security firm RiskIQ has traced the breach to a compromised Javascript file which skimmed the card details from the payment form. So when a user entered their credit card number and security code on BritishAirways.com (or their mobile app) those details were posted to a third party server, unknown to British Airways or the customer. This is a high-scale equivalent of placing a skimming devices on an ATM, which reads one card at a time.
In Ticketmaster’s hack the script was one loaded from a chatbot vendor on their site, Inbenta. Inbenta claims not even to have been aware the script was used on payment pages. The changes to the script were subtle: not breaking any functionality, and in BA’s case using a domain ‘baway.com’ which looked somewhat authentic.
To protect your site against a similar attack you obviously need to lock down accounts used by your developers to change scripts in the page source code, but you also need to secure GTM – which can be used to deploy such scripts.
We have a few rules at Littledata to help reduce risks in using tag management on payment pages:
1. Use pixels over custom JavaScript tags on payment pages
You probably need a few standard tags, such as Google Analytics, on payment pages but try to avoid any custom scripts which could possibly skim card details. Many non-standard tags use JavaScript only to create the URL of a tracking pixel – and it is much safer (and faster) to call the tracking pixel directly. Contact the vendor to find out how.
(Littledata's Shopify app even removes the need to have any script on the payment pages, by hooking into the order as it's registered on Shopify's servers)
2. Avoid loading external JavaScript files in GTM
Many vendors want you to load a file from their server (e.g. myvendor.com/tracking.js) from GTM, so they can update the tracking code whenever they want. This is flexible for them, but risky for you. If the vendor gets hacked (e.g. with Inbenta above) then you get compromised. It’s less risky to embed that script directly in GTM, and control version changes from there (although a fraction slower to load the page).
Of particular risk is embedding a tag manager within a tag manager – where you are giving the third party rights to publish any other scripts within the one tag. Don’t do that!
[subscribe]
3. Lock down Edit and Publish rights on GTM
Your organisation probably has a high turnover of contract web developers and agencies, so have you checked that only the current staff or agencies have permission to edit and publish? It's OK to have external editors use 'workspaces' for version control in GTM, but ideally someone with direct accountability to your company should check and Publish.
4. Blacklist custom JavaScript tag on the payment pages
You can set a blacklist from the on-page data layer to prevent certain types of tags being deployed on the payment pages. If you have a GTM container with many users, this may be more practical that step 3.
5. Remove tags from old vendors
There are many thousands of marketing tools out there, and your company has probably tried a few. Do you remove all the tags from vendors when you stop working with them? These are most at risk of being hacked. At Littledata we run a quarterly process for marketing stakeholders opt-in tags they still need for tracking or optimisation.
6. Ensure all custom JavaScript tags are reviewed by a developer before publishing
It can be hard to review minimised JavaScript libraries, but worth it for payment pages if you can’t follow rules 1 and 2.
If you’re still worried, you can audit the actual network requests sent from payment pages. For example, in Chrome developer tools, in the 'Network' tab, you can inspect what requests sent out by the browser and to what servers. It’s easy for malicious code to hide in the patchwork of JavaScript that powers most modern web experiences, but what is harder to hide is the network requests made from the browser to external servers (i.e. to post the stolen card information out).
This request to Google Analytics is fine, but if the domain of a request is dubious, look it up or ask around the team.
Good luck, and keep safe with GTM!