Tag Manager Governance (Part 1) – User Management and Naming Conventions

by Peter Adamson

I wanted to write a little about the management part of tag management, and this is the first of a few posts I intend to write on the topic of good tag management governance. I’ve seen too many examples of tag managers be misused, becoming bloated, broken, and beyond saving. This is a problem that usually accumulates slowly over time, and is often exacerbated with each additional user active within the tag management system. 

The irony is tag management systems were originally developed to solve the messy problem of copious tag snippets and pixels polluting a site’s code, creating all sorts of issues and headaches.

The good news is this is easily avoided with a little bit of governance. I will be using Google Tag Manager (GTM) as the TMS in my examples, but these rules of governance should translate to any TMS including Tealium iQ

The Pillars of TMS Governance

These are the critical pieces for enabling good care and maintenance of a TMS over the long-haul:

  • User management
  • Naming and organizing conventions of TMS elements
  • Well-defined workflow and release process
  • Good communication between TMS users
  • Documentation 

While I will be writing about all of these points, this post will cover the first two: user management, and naming and organization. 

User Management to Encourage Best Practice Workflow

The first step in keeping your TMS on the rails is being cautious about user access, and how much power users have. Consider carefully whom within an organization should be responsible for doing what in the TMS. It is possible to do some real damage to a site through a tag manager, and so the safest approach is to limit the number of users that have the highest administrative privileges.  

GTM has two levels of permissions: the account level and container level. An organization should assign at least two users as account admins to ensure there is more than one set of keys to the account, and be very conservative about granting this level of access beyond that. Only account admins can manage user permissions; there is no container-level role that can do this. An account admin also has complete access to all containers within the account.

At the container level, the permission levels available are:

  • No access: The user will not see the container listed in the account.
  • Read: The user will see the container listed and may browse the tags, triggers, and variables in the container, but will not have the ability to make any changes.
  • Edit: The user has rights to create workspaces and make edits but not create versions or publish.
  • Approve: The user has rights to create versions, workspaces, and make edits but not publish.
  • Publish: The user has full rights to create versions, workspaces, make edits, and publish.

Edit, approve and publish are the important ones here, and assigning these roles carefully encourages a responsible workflow. Editors may set up and test work in GTM within ‘workspaces’ but they will need to hand-off that ‘workspace’ to an approver or publisher, who should review the work before saving the version. Only publishers can actually make a version active on a site by publishing it.

So, good user management should lead to good release management when used correctly. As the permission levels rise the number of users assigned to those higher roles should go down, limiting risk and keeping accountability with the right people. Assigning a single user as the designated publisher of a container is good practice. Even when several users have publish-level permissions in GTM, having a single person responsible for clicking the publish button keeps GTM releases manageable.

Google Tag Manager 360 recently added an ‘approvals’ feature, which provides a means of communication between the editor and the approver/publisher within GTM, which otherwise would be handed elsewhere (such as in emails). An editor can indicate a workspace is ready to promote by requesting approval, and provides a place for the editor and approver to comment on the workspace before it is eventually saved to a new version. This feature combined with the 360-only feature of unlimited workspaces allows an organization to grant edit permissions to almost anyone with little risk.

Naming GTM Elements

I cannot overstate the importance of a good naming scheme in the long-term maintenance of any TMS.

A well-considered and consistent naming of GTM elements allows a container to be intuitively navigated and understood with a minimum of confusion. This is especially true as the number of GTM elements and container administrators grows.

Keep in mind the limited character set for element names in GTM. Only a few non-alphanumeric options can be used for naming tags, triggers, variables, workspaces, and folders including the following special characters:

  • Dashes –
  • Underscores _
  • Decimals .
  • Tilde ~

No brackets, commas, colons, or anything else beyond these characters can be used. 

Tag Naming Convention

The components of tag names are these:

[VENDOR].[TYPE] – [Page/Event/Usage/Condition] – [Additional Info (IDs/Unique Values/Owner Info) (if necessary)]

Start with the [VENDOR].[TYPE]

Most vendor tags will be either intended to fire on a pageview or a event, but there are of course exceptions to this. Pageview and conversion tags generally need to be separate. Joining the vendor tag name with tag type is good practice to keep vendor tags sorted together, but still easily distinguished.

Vendor tag names should be consistent. Creating and maintaining a reference document to list vendor tag names to be used in the TMS is worth doing as part of a governance strategy.

Tag Types Abbreviation in GTM
AdWords Conversion AdWords.event
AdWords Remarketing AdWords.page
Bing Event/Conversion Bing.event
Bing Tracker/Retargeting Bing.page
Facebook Pixel Page fb.page
Facebook Pixel Conversion fb.event
Google Universal Analytics Pageview GUA.page
Google Universal Analytics Event GUA.event

Next the [Page/Event Condition]

The second part of a tag name should be information about how and/or where a tag should fire, which is sufficient for most tags.

Common examples of this may be:

  • ‘all pages’
  • ’order confirmation’
  • ‘lead form submission’
  • ‘add to cart’

Last is the Optional [Additional Info (IDs/Unique Values/Owner Info)]

Vendor, type, and firing condition is usually enough for a tag name, but there are cases where a tag name would benefit from additional info to distinguish it.

Putting it all together

Some example tag names following this scheme would be:

  • GUA.page – all pages
  • DCF.event – checkout success
  • AdWords.page – all pages – if ID is not undefined

Trigger Naming Convention

The components of trigger names are:

[Trigger Type].[Type Config] – [Condition(s)]

Start with the [Trigger Type].[Type Config]

Some GTM trigger types, like pageview (Pageview, DOM ready, or window loaded) have some built-in configuration options that combine to form the first part of a trigger name, but in most cases just the trigger type is enough.

So examples of this are:

  • pageview
  • pageview.dom
  • pageview.load
  • customEvent
  • click.link
  • click.element
  • timer.one-time
  • timer.unlimited

Next are the [Condition(s)]

Conditions include brief information about the conditions with which a trigger has been configured, such as page type, paths, or urls (I use decimals in place of slashes). Custom event triggers are often configured on a specific string value, which is sufficient for condition information in most cases.

Trigger conditions can be combined within a single trigger in a number of ways, like an event on a certain page. So, when more than one condition is required to adequately describe the configuration, separate those into different parts of the name as needed. 

For example:

  • all pages
  • all events – path not match .cheese.
  • path contains .coats.winter
  • url match .search
  • gaTrackEvent
  • addToCart
  • removeCart – path match .goatcheese.

Putting it all together

Trigger name examples might be:

  • customEvent – addToCart
  • pageview.dom – path contains .coats.winter
  • customEvent – removeCart – path match .cheese.

Variable Naming Convention

The components of trigger names are:

[Variable Type].[Type Config] – [Tag/Usage Specific Info (if appropriate)] – [Value description]

Variables are the most versatile GTM element is terms of potential usage. Variables can be used within GTM Tags, Triggers, and other Variables.

Start with [Variable Type].[Type Config]

Not all variable types have some obvious and important config options, so joining these where appropriate makes sense.

For example URL and HTML/Auto-Event element-based variables should feature config value:

  • constant
  • lookup
  • dataLayer
  • url.query
  • url.path
  • url.hash
  • referrer.path
  • html.id
  • html.class
  • html.attr

Next [Tag/Usage Specific Info (if appropriate)]

Not always relevant, but variables are often specific functions in GTM that are formatted to a vendor tag spec. If this is the case the established vendor abbreviation should make up the second part of the variable name.

Finally [Value description]

This could be the literal value, or dataLayer key name, or a description of how the value is derived. Make it short and descriptive.

Putting it all together

Variables name examples resulting from this scheme might be:

  • constant – GUA – property ID production
  • constant – random number and time stamp
  • customJs – pinterest – products as line_items array
  • customJs – utility – return undefined
  • dataLayer – user.id
  • dataLayer – ecommerce.actionField.id
  • lookup – AdWords – conversion ID from pageType
  • lookup – GUA – property ID from environment name

Questions or comments? Give us a shout and we’ll be happy to help you establish good governance in GTM or Tealium iQ. My next post will discuss tag management and publishing workflow between Marketing and IT, between development teams, and between businesses and their vendors.

Peter Adamson

Implementation Specialist, and Google Tag Manager Practice Lead

Peter is an Implementation Specialist and Practice Lead for Google Tag Manager. He partners with our enterprise client development stakeholders to help guide them through and assure the quality of their most sophisticated analytics infrastructure requirements.

See more posts from Peter