If you’ve logged into Google Tag Manager recently, you’ve probably noticed two broad changes:
UI Update
The new user interface seems to reflect Material design spec, which was originally developed to foster UI consistency among the great proliferation of Android apps but that has also ostensibly influenced the UI for Google platforms such as GTM, FireBase, and – to a limited extent at least for now – Google Analytics.
The clean new design of GTM does not take long to get accustomed to. The common GTM tasks (creating tags, configuring variables, and applying triggers) are more intuitive than ever before. (Now we just need to get oriented with workspaces…)
Workspaces (!)
Workspaces are a substantial and very welcome update to the processes and tool features that we can consider as the GTM workflow. In this blog post, we’ll explore workspaces and also take a step back to map their relation to accounts, containers, versions, folders, environments, and access rights.
Workspaces are fairly intuitive but may at first require some guidance. E-Nor’s Engineering and Consulting teams share strategies and tips below for optimal use.
Accounts and Containers
Let’s start at the top level: accounts. Similarly to a Google Analytics account, a GTM account usually corresponds to a single organization rather than to a website or mobile app. Each GTM account can include one or many Containers.
The workspaces update doesn’t directly pertain to accounts, and we generally don’t have to concern ourselves too much with the account level day to day: the real action is going to happen from the container level on down.
As the central paradigm of tag management systems, a container houses the tags, triggers, and variables that you can add to your website (or to your mobile app) for countless purposes.
With the arrival of the workspaces feature in GTM, we can say that we no longer work directly within a container. Instead, we now work within a workspace that resides in a container, potentially alongside other workspaces.
The Previous Problem: All-or-Nothing Container Publishing
The new workspaces feature was designed to address a fundamental constraint: container publishing was an all-or-nothing proposition, which meant that every tag, trigger, and variable was published at one time. If multiple people (say, a member of your own marketing team and representatives from an outside marketing or analytics agency) were adding elements to the same container, the person with publish rights to the container had to verify before publishing that everyone’s tags were ready for prime time.
At a minimum, this limitation could be inconvenient. At worst, it could be dangerous if GTM users with publish rights published container elements that should not have been published yet.
Click to enlarge the image.
Before the workspaces feature became available in GTM, you had to publish all tags, triggers, and variables at the same time.
The Solution: Incremental Publishing with Workspaces
Workspaces address the all-or-nothing problem by allowing subsets of new tags, triggers, and variables to be published independently.
Click to enlarge the image.
You can create separate workspaces and publish them independently. In this example, we have separate workspaces for an internal department and an external agency.
Click to enlarge the image.
In this example, the Marketing and Analytics departments are using separate workspaces.
Default Workspace, Plus Two More
As mentioned above, we no longer work directly within a container; there’s another level in the GTM hierarchy. We now add and edit tags, triggers, and container within a workspace.
If you’re using the free version of Google Tag Manager, you can create two workspaces in addition to the default workspace. Tag Manager 360 allows you to create an unlimited number of workspaces per container.
Note that you need Publish or Approve access to the container to create a new workspace within the container.
Click to enlarge the image.
In the free version of GTM, you can have three workspaces per container. In Tag Manager 360, you can create an unlimited number of workspaces.
Strategies for Creating Workspaces
Below are a few possible approaches for your workspace naming and usage. As with so many other aspects of analytics and tag management, you can opt for the strategy that most closely reflects how your organization divides responsibility for tag updates.
Internal and External
In the first workspace example above, we saw workspaces for the internal marketing department and an external marketing agency.
Departments
In the second workspace example above, we saw workspaces for the marketing department and the analytics department.
Individuals
If certain individual are responsible for most of your GTM updates, you can create designate their own workspaces.
Ad Hoc
You might also opt to create workspaces on an ad hoc basis. As we’ll learn below, workspaces are actually temporary, so you can “recycle” your workspace slots indefinitely.
User Access Still Managed at the Container Level
It’s important to note that access rights are still managed at the container level, not at the workspace level. When you create workspaces, use clear naming conventions for your workspaces and provide necessary heads-ups, since anyone with Edit access to the container would be able to make changes to any workspace within the container.
You can deal with this in a straightforward way: if several members of your Business Intelligence team will be making updates, create a workspace called Business Intelligence, and instruct those team members to work only within that container – even if it has disappeared. (More on container disappearance below.)
Should We Use the Default Workspace?
If you’re using the free version of GTM, you can have a maximum of three workspaces total, so you may have the need to use the Default Workspace.
As a possible scenario, let’s say that several people in your organization have Edit rights to the container, but two people – Heather in Marketing and Sonia in IT – are the most active in GTM. You could create designated workspaces for Heather and Sonia and instruct the other team members to use the Default Workspace.
Creating Versions and Publishing from Workspaces
In GTM, we no longer publish containers: we now publish workspaces, individually, and at the right time.
When you publish a workspace, you also create a new container version that includes the latest changes in the workspace that you have open in GTM. You can also create a version without publishing. A version serves as a container snapshot that can be restored if the need for a rollback ever arises.
You now also preview and debug at the workspace level rather than the container level. (For more on debugging in GTM, see Event Tracking Using GTM V2.
Click to enlarge the image.
In GTM, we now publish or create a version of a workspace rather than a container.
Naming Your Versions
When you publish a container (or create a version separately), you can provide a name and description for the version you’re creating. The version name defaults to just the workspace name. It’s helpful keep the name of the workspace in the version name so you can easily tell which individual or team created the version, but it’s also recommended to modify the name to reflect the changes and describe your version in more specific terms.
Click to enlarge the image.
You should provide a meaningful name and description when you create a version (as part of publishing or as a separate step).
Should Different People Publish Different Workspaces?
The short answer is, in most cases, no.
The same caution that has always been prescribed for publishing has probably become even more dire with the advent of workspaces.
Anyone who publishes a container should fully understand the purpose, status, and ownership of every element in the container, which now means each tag, trigger, and variable in every workspace.
Certainly provide Edit access to multiple people, but, as mentioned previously, make sure everyone knows the workspaces they’re supposed to be using.
You can also allow multiple people Approve rights to create versions, but be extremely judicious when it comes to publish rights. Only one person, or perhaps a very small team, within an organization should have publish rights. GTM is indispensable, but, when used without the necessary restraint, it is quite dangerous.
As a note, the Approval Queue accessible directly from the container admin relates to specifically to automated tagging for DoubleClick Floodlight; it does not pertain directly to workspaces.
Click to enlarge the image.
You edit, create versions, and publish at the workspace level, but user rights are assigned at the container level and therefore apply to all workspaces within the container.
Extra Precaution: Tag Naming
If you’re adding many elements to a workspace at one time, and the elements may have different statuses in terms of publishing readiness, you can include an prefix such as PENDING to names of tags (and triggers and variables) until you have confirmed that they are are ready to go.
While workspaces have somewhat diminished the need for precautionary tag naming, this can still be a worthwhile practice if your workspace might experience a lot of editing between versions/publications.
Click to enlarge the image.
You edit, create versions, and publish at the workspace level, but user rights are assigned at the container level and therefore apply to all workspaces within the container.
Folders
You can similarly use a specially designated folder to house GTM elements that are not ready for publishing. In fact, you can use folders to add another level of organization to your container. Note, however, that any container that you create in any workspace will be incorporated into the general container version and then synced with other workspaces, unlike the non-default containers themselves, which go away after publishing or version creation.
Abracadabra, Your Workspace Has Disappeared
Don’t look for your workspace (other than the Default Workspace), once you have created a version of the workspace or published it: the workspace disappears, its changes become incorporated into the latest version of the container. Your workspace changes have gone into the container and no longer reside in a workspace.
As mentioned above, you can “recycle” a workspace an unlimited number of times. For instance, you could create a new workspace, name it Marketing Department, publish or create a version, and repeat this cycle as much as you need to.
Why Are My Other Workspaces Out of Date?
A workspace continually compares itself to the most recent container version (or the version that was restored in the call of a rollback). If there are difference between the latest version and the workspace, an alert – quite inconspicuous – will appear on your workspace dashboard. To synchronize, click UPDATE.
Click to enlarge the image.
Once you create a version of or publish a workspace as the current container version, the other workspaces become out of date.
New Workspaces (with Old Name or New Name) Aren’t Empty
If you have created a container version with any changes from any workspace, new workspaces that you create subsequently will not be empty. As a baseline, they’ll be created with all the tags, triggers, and variables that were saved to the latest container version.
In this way, if you recreate the Marketing Agency workspace that disappeared when you published it, it will contain all your previous changes, plus any additions that went into the version from other workspaces.
Conflict and Resolution
A conflict occurs when there are two tags, triggers, or variables with the same name have been added since the previous sync and you then try to create versions of or publish the containers. These conflicts should probably not arise too frequently; when they do, they will fall under one of two scenarios:
- same name, same purpose: if the userId variable in the screen shot below was intended to serve the same purpose when added to the two different containers, you can remove the userId variable from the container that you’re syncing and publishing later. Since you already have the userId variable that you need in the container, there’s no need to add from two different workspaces.
- same name, different purpose: in this case, you can just rename the element and resynch before creating a version or publishing.
In either case, the resolution should be very straightforward.
Click to enlarge the image.
Workspaces and Environments
As another fairly recent addition to GTM, Environments also offer welcome flexibility. We do, however, want to make sure to clearly distinguish workspaces from environments as concepts. While workspaces relate to container editing, environments relate to container publishing, or, more specifically, where the container is being published to.
Click to enlarge the image.
Custom Workspace to Custom Environment More Likely in Practice
You can publish your workspaces to the Live environment or to any custom environment that you have defined. The most common path might be from a non-default workspace to a custom environment, and then, after testing, from the default workspace to your Live environment.
Workspaces: A Great Enhancement
Workspaces represent a substantial, enterprise-level enhancement to Google Tag Manager. Once you establish your working processes with your team and learn a few of the ins and outs, workspaces will provide much greater flexibility and control in your GTM workflow.
