We’ve always been keen on Google Tag Manager but for many of our enterprise clients GTM has perhaps lacked some of the more advanced workflow and version management tools they have come to expect from their tools. However, Google has now announced a new authorization feature for GTM 360, which is aimed at helping enterprise clients with larger teams manage their implementation.
The authorization feature is an additional level of control that means that some users must ask for approval for changes in order for them to be submitted to a version and published. Apart from unlimited workspaces, this is the first key feature to differentiate GTM 360 from the free version.
However, it’s worth noting that this update has included a minor UI update for all users; as instead of seeing the options to “Create Version”, “Publish” and “Preview”, standard GTM users will now also see the option to “Preview” and “Submit”. For them the “Submit” option opens a pane to publish or create a version.
The authorization feature has subtly changed the functionality of user permissions for GTM 360 users:
- View: This hasn’t changed and users can still only view and preview the container.
- Edit: This lets users create a new workspace and make changes, but users cannot create or publish a new version and can only submit a workspace for approval.
- Approve: This allows users to approve all submitted changed workspaces as well as create a version from them but does not let you publish.
- Publish: This allows users full access to the container.
The eagle-eyed amongst you might have noticed that users with approve permission or above can approve all changes and that includes their own. Enforcing that users must submit changes for approval means that those users making changes to GTM have edit access only.
In an ideal, fully QA-tested world, all users of GTM would not test their own changes and all changes would be thoroughly tested! Currently the approvals feature lacks a way to compel users with Approve and Publish permissions to also seek approval of edits to a workspace.
However, this does give you the option of continuing to use GTM 360 without using this new feature through adjusting user permissions appropriately.
The new workflow begins after users have made any change to their workspace.
Users with edit permission will be able to see a new ‘Submit’ button alongside the existing ‘Preview’ button.
Clicking this button will allow them to request approval from any user with approval permission or higher for their changes.
On clicking the submit button users with approval access or higher will now also have the option to request approval as well as create a version; and users with publish permissions will additionally have the option to publish and create a version.
When a user submits an approval request it can be assigned either to a specific user with approval access through using the dropdown menu or to any user with approval access in general. It is also possible to add annotations to explain the changes that they are submitting for approval. This is perhaps one of the most useful aspects of this feature as it enables a dialogue to be created between the user and an approver around why these changes have been implemented and how.
Once changes have been submitted for approval in a workspace, a gavel will be shown alongside that workspace in the workspace overview.
In addition, any user with approval access will see a blue dot alongside the approvals tab on the main screen if any changes have been submitted but not specifically to them or a red dot if they have been specifically assigned to those changes. In addition to this dot a Pending Approval message will also appear with the name of who has submitted the request with the option to view that request in that workspace. It is also possible to see all submitted requests through selecting the Approvals tab.
Once a user with approval access views the request they will be able to see an overview of all changes made to the workspace. Clicking the specific changes will allow them to see in more depth the changes made. This is similar to how changes between versions are currently displayed in the version history.
If an approver does not approve the change then they can choose to send it back to the user with why the change requires further work. The user can then resubmit further changes for approval.
If the change does pass inspection then they can approve the change and submit the change to create a version or approve the change but leave it unsubmitted in the workspace. If the user has publish permission they will additionally be able to create a version and publish it live.
However, it is worth mentioning that a user can continue to edit a workspace once they have submitted a request for approval. If a user’s request for approval is approved but the workspace is not turned into a version they will not then be able to resubmit another request for approval if further changes are made to that workspace.
This is potentially a weakness in the approvals workflow as it means that further unapproved changes in a previously approved workspace may appear at a casual glance to be approved. This could lead to such changes being submitted into a version at a later date and then ultimately published. I would recommend that the workflow should end with either changes being published or versioned if using the approvals feature, as ideally all changes should be approved if using the feature to its full potential.
The approvals feature gives an additional layer of control and visibility over the changes that users make in a GTM container. In conjunction with the environments feature as well as workspaces it should help larger organizations keep control over their GTM setup and the deployment of new tags. However, ultimately, using this new feature isn’t obligatory and there are still ways in which it could be side-stepped. The approvals feature is less a way to manage the quality assurance process and more a useful way to keep an eye on users with less experience in GTM and a more limited understanding of an organization’s GA setup. It is essentially a tool for communicating changes in GTM – an effective tool – but not one that will replace any existing QA framework.
Remember ‘Quality is not an act, it is a habit’ (Aristotle)!
If you want some advice on how to use this new feature to best assist your QA process, or if you are interested in upgrading to GTM 360, please don’t hesitate to get in touch!