The Google Tag Manager interface was revamped on August 30th, 2016. However, at first glance, it seems that “containers” have simply changed to “workspaces.” However, when you actually try to create tags, rules, and variables, you’ll notice that things have changed a lot.
It’s been about a year and a half since the version of Google Tag Manager changed from v1 to v2 around April 2015, and this is the interface renewal. When upgrading from v1 to v2, the listener tag was abolished and the names of variables and triggers were also changed. squeezed. I think that various sites will cover how to use the interface and workspace function later, so here I would like to think about the use case of the “workspace” function.
What is a “workspace”
From the feeling of using the workspace function, it can be said that the workspace function is “a function to increase the degree of freedom of version control”. If you are an engineer, I think that there are many people who have used Github, but I think it is better to think of a workspace as a “branch” in Github (even though many people who use Tag Manager I’m not an engineer, so this analogy doesn’t quite make sense to me.)
Until now, the version control function of Google Tag Manager did not have the concept of “branch”, and in the setting process, there was only one way forward (advance the setting) or backward (return the setting).
It was difficult for multiple people to add various functions (tags) at the same time. With the addition of the “workspace” function, which corresponds to “branch”, a workspace is created for each function to be developed (set), and when development (set) is completed, it is merged (integrated) into “Default Workspace”.
You will be able to While working in a function-based workspace, you can add, edit, and delete tags, triggers, and variables without worrying about the development (settings) being done in other workspaces, and you can preview ( debugging) can also be done on a workspace-by-workspace basis.
How to use the workspace
workspace features
- If there are many people involved with Google Tag Manager
- When the frequency and volume of changes to tags managed by Google Tag Manager are high
It is considered to be a function that can be used to the maximum in We’ll see how to use it.
Create a workspace for each development (setting) function
This pattern creates a workspace by cutting out each function to be developed (set). Even if only a small number of people are using Google Tag Manager, if “the frequency and volume of changes to tags managed by Google Tag Manager is large”, creating a workspace for each function to be developed (set) is recommended. I think it is desirable.
For example, if you’re trying to make multiple changes to Google Tag Manager, such as “Configure Google Analytics Event Tracking” and “Add Ads Remarketing Tag”, create a workspace for each and apply each change to The image is to do it in each workspace, and finally integrate each one into the Default Workspace in order and publish it.
In this case, I think the advantage of dividing the workspace is that “settings on GTM can be done in parallel, and changes can be published at different times.”
When making the above two changes, depending on the operation flow of the site, “Google Analytics event tracking settings” should be confirmed by the site production company (analysis company) before being published.
I think there are cases where you want to publish the “addition” after having it confirmed by an advertising agency. In such a case, by dividing the workspace, you will be able to “publish the confirmed functions in order”.
Also, even if there is no such flow, if everything is set in one workspace, it is not possible to “extract only some functions and publish them first”. It is recommended to separate the settings with a space.
If you make a diagram, it will look like this:
Create a workspace with the site renewal
When you renew your site, you will need to change the content of the tags you set up. If the scale of the renewal is large, you will encounter cases where you have to set the tags in the development environment. Also, if the setting period is prolonged, it will be necessary to update the current version of the tag before the renewal while proceeding with the setting of the post-renewal tag.
In such a case, if you create a workspace for “site renewal” and set tags related to site renewal in the workspace for site renewal, you can smoothly update tags for the current version.
If you make a diagram, it will look like this:
Utilization method realized by using together with the environment function
I don’t think it’s used much, but Google Tag Manager has an Environment function (environmental function). With this function, by dividing the tags installed on the site into “for development environment”, “for staging environment”, and “for production environment” in one container, it is possible to “publish the set tag only to the development environment”. It is possible to check and develop in the development environment, publish only to the staging environment after development is completed, check in the staging environment, and publish tags for the production environment when the production is released.
Although we have not yet confirmed the specific operation, we believe that by using this “Environment” together with the “Workspace” function released this time, we will be able to see new ways to use it.
at the end
With the free version of Google Tag Manager, it seems that you can only create up to 3 workspaces at the same time with the workspace function introduced this time, so if you are a company that uses Tag Manager on a large scale with a large number of people, the free version There is a possibility that it will be unsatisfactory (I think there are few such companies in Japan at the moment). If it is a paid version provided by Google Analytics 360 Suite, it seems that you can create an unlimited number of workspaces, so if you are using a large number of people or on a large scale, use the paid version together with other 360 Suite products. I think there is also.
