Google Tag Manager Updates (I): Workspaces

Recently, and following a closed beta period, Google has published a new version of Tag Manager that includes a number of significant improvements, such as a total redesign of the management interface.

The main innovation, however, which has been announced with much fanfare, are Workspaces. This new feature promises to improve the way we work with GTM, particularly on those occasions when we do so concurrently, with various users or groups working on the same container.

1. What are Workspaces and what are they used for?

Short version: they allow us to work with various container drafts simultaneously, featuring individual tracking of changes, synchronization between versions and detection/resolution of conflicts.

Basically, it’s a step up from the system of drafts and versions that we’ve had until now.

Previously, for each container we had a draft, which comprised the container we were working on and contained a history of all the changes that had been made; and we had the versions, which comprised a list of “copies” of the container we were creating and were saved sequentially, whether on the basis of the current draft or that of earlier versions. We could publish, preview and restore any version at any time.

However, although this way of working was convenient when there was just one user, it could become problematic when a number of different users, departments or agencies had control over the container in question. Each change was applied simultaneously to the same draft, meaning there was no way to stop changes from overlapping with each other or the container being published at an inopportune moment, and it was generally impossible to carry out parallel development securely without coordination or restriction.

2. Workspaces = several simultaneous drafts

Now, however, for each container there are one or more Workspaces, and each of them functions as an independent draft.

In the GTM interface, when we open the “Container” tab it automatically changes to “Workspace”. If we’ve created more than one Workspace (there’s one already created by default, named – as you might expect – “Default Workspace”), then a panel appears in which we can specify the Workspace we wish to open, as shown below:

Once we’ve opened it, it will become an editable draft.

From the same panel we can also choose to edit (click on the “Info” icon to the right of each option), delete (while editing, you can choose this option from the top menu next to the “Save” button) or create (click on the “+” button in the top right) new Workspaces.

NOTE: When a new Workspace is created, it’s always based on the most recently saved version of the container. This version is not necessarily the one that is currently published, or even the most up-to-date (for example, there may be unpublished changes in another Workspace).

We can return to this panel at any time by selecting the new option (shown below) in the left-hand menu:

From now on, we can work in our chosen Workspace like always, and publish the changes at any time. But what happens in the event of a conflict? What happens to the other Workspaces if we want to publish ours? And what happens to our Workspace if someone creates a new version of the container?

Well, that’s when the new synchronization function comes into play.

3. Publishing and synchronization

Every time the Publish (or Create Version) option is chosen in a Workspace, the following happens:

1) A new publishing interface is displayed:

This new panel is much more than a simple confirmation dialogue. Among other things, it gives us a full summary of the changes made (plus the option to manage them individually – see below!) and a box where it tells us to identify the version to be created by adding a name and description, if we haven’t done so already. In fact, if we don’t identify it, it will give us another reminder prior to publication. Now there’s no excuse!

2) Once the operation has been confirmed, a new version of the container is created (and published, if we’ve specified that option) based on the Workspace, and that Workspace is then automatically deleted, unless it’s the Default Workspace.

3) And now the magic happens: if there are other Workspaces, they are automatically notified that a new version has been created, along with a link to update the Workspace with the new changes:

If we close this notification, it will remain available – along with the link – on the Overview screen:

Even if we ignore it, we can’t get rid of it, because when we go to publish, it’ll notify us again. And if we don’t update manually, it’ll do it automatically as part of the publication process.

In any case, once we’ve chosen to update the Workspace, a panel like the one below will appear:

From here, we can review all of the versions (as there may be more than one) with which the current Workspace needs to be synchronized, and confirm by clicking on Update.

Normally, that’s the end of the process: the changes to each separate version are integrated into the Workspace and we can publish it or continue editing it. But what happens if there are still conflicts? If two versions or Workspaces have made parallel changes to the same tag, trigger or variable, which of them takes precedence?

Fortunately, the update process automatically detects and notifies us of these conflicts and gives us an opportunity to resolve them:

If we click on Resolve (this option is also available in the Overview panel) or on a specific conflict, a new panel will open in which we can view and compare both versions, revise them and make a decision regarding each conflict. We can choose to prioritize one of the versions over the other or even combine them by taking changes from both.

We’ll take a closer look at this panel below.

4. Advanced change tracking

Although this change management feature is especially useful for resolving conflicts, its functionality doesn’t stop there. In fact, anywhere there’s a summary of the changes that have been made (e.g. in the Overview or Publish panels), we have the option to select each change individually and review it or reject it:

If we select the Abandon Change option, the change is undone, as if it had never been made in the first place.

If we select the View Change option, the same version-comparison panel as the one shown for conflicts will appear:

In both instances (conflicting versions, original vs. modified) the two versions are shown side by side, with each change individually highlighted: fields added in green, fields deleted in red, and fields modified in blue.

For each change, we can click on the central arrow and decide whether to Ignore them (i.e. stick with the version in our Workspace) or Copy them (i.e. overwrite the Workspace with the other version).

If we’ve accessed the conflict resolution panel, we also have the option to navigate between conflicts (by using the Previous/Next arrows) and Resolve All, which automatically applies the Ignore option to all of the changes (this also occurs when the Workspace is automatically updated as a result of publication).

Once all of the conflicts have been resolved, we can click on Apply or Save to confirm the changes.

5. Notes and references

Finally, there are a few other things we should point out regarding Workspaces:

• Currently, the number of simultaneous Workspaces is limited to three in the standard (i.e. free) version of GTM; however, this is not the case in Google Tag Manager 360 (the paid-for version included in the Google Analytics 360 suite). At present, this is the only difference between the free and premium versions of GTM… and we hope it remains that way for a while 😉
• For now at least, the new layer of separation introduced by the Workspaces has not been extended to security. No Workspace-level permissions have been added: permissions remain at Container level and any user with the appropriate permissions can view, edit or publish any Workspace. But at least now, if someone starts messing around with something they shouldn’t, it’s easier than ever to detect it – and fix it! 🙂

And of course, the obligatory links:

• The official Google documentation
• The official announcement on the Google Analytics blog
• Google Tag Manager Workspaces by the omnipresent Simo Ahava, always first at the scene of the crime
• Google Tag Manager Updates: Workspaces and User Interface by Lunametrics, another one who’s always quick off the mark 🙂

In the next post we’ll give you the second part with all the other updates!