• Jervis Koo

Google Tag Manager naming convention guide

When working with Google Tag Manager, or any other tag management solution, a well thought out naming convention is a must. Naming your tags, triggers, and variables in a structured, easy to read and informative way really is key and will be super beneficial for anyone working in your GTM container.

In this post, we'll look into how you should name your assets (tags, triggers, and variables) and we'll start by briefly going over the benefits of adhering to a good naming convention.

It's important to always preview and debug the changes made to your workspace before publishing it. A good naming convention saves you time, but it is crucial to always verify and test that the set up generating the right outcomecorrect. Never trust that an asset in GTM is what it says it is based on its name alone.

The benefits of a having naming convention

Saving time

Using a consistent naming convention within your GTM container will save everyone working in it a lot of time. This gives users a basic understanding of how tags, triggers and variables are set up without having to dive deep into them to figure it out.

Properly named assets also allow users to easily search for specific tags, triggers, or variables within GTM. Having good searchability within your container prevents creating duplicate assets by mistake. One of the biggest benefits of having a good naming convention is that it allows users to interpret Custom JavaScript variables that reference other variables easily.

Fewer chances to mess things up

When assets are named well and the setups are easy to understand, team members working in the container will make fewer mistakes. Of course, one should always test (preview and debug) before publishing a workspace, but there will generally be fewer iterations before being able to publish containers.

Reduce clutter

If you're like me and like things tidy, a consistent and standardised naming convention goes a long way! No one likes working in a mess and I'm sure there are studies out there linking productivity to workspace tidiness —don't quote me on that!

How to name your tags, triggers and variables

Let’s start with some general guidelines.

When naming your assets make sure to be;

  • consistent

  • informative

  • and make the names of the assets easy to read


Be consistent in how you name the different types of tags, triggers and variables in GTM. For example, if your Google Analytics event tags start with “GA – Event” then make sure you stick to it for all future tags. This also allows tags to be grouped together when sorted by name.


Make sure to include the most relevant information in the names of your GTM assets so anyone that works in the container has a clear understanding of a particular asset. For example, include tag type, grouping, and action (example: “GA – Event – Subscribed”) in your tag names so it informs users what it does.

Easy to read

Make sure the names of the assets are easy to read. An easy way to keep things tidy would be to use a dash (“-”) as the delimiter for each part of the name. For example, “FB – Event – Purchase”. Try to keep them short too if you can!

Naming conventions


A good way of structuring your tag names is by tag type, grouping and action. This will ensure that the most important information regarding your tags is included in their names.

A few examples:

  • GAds – Remarketing – Checkout

  • UA – Event – Purchase

  • Custom HTML – Hotjar

Let’s dissect the first tag above to get an understanding of how the tag names are constructed. GAds (Google Ads) is the tag type, we then have Remarketing which is the grouping — this could be either be Remarketing or Conversion for Google Ads— and lastly, we have the action which is Checkout. When we read this, the tag us sending data to Google Ads, the data is used for remarketing purposes and the tracked event is checkout. For the tag “Custom HTML – Hotjar”. You may notice that the action label is not present. This is because there is only one Hotjar tag in each container and then there is no need to differentiate with the action label. This will also apply to other tools that require you to install tags to track specific things on your website.


Always remember to include the trigger type and the user action in your trigger names. It's also important to include the scope of the trigger when that makes sense. The scope could be what URL(s) the trigger fires on. For example, the trigger might be set up to fire only on www.mywebsite.com/page but not on the other URLs on your website.

Let's break down a few trigger name examples to get a better picture of this;

  • Page View – Order Confirmation

  • Event – Purchase

  • Scroll – 75 % – NZ

In the first example, the trigger type is Page View and the user action is Order Confirmation. When we read this, a tag with this trigger attached to it fires when a user lands on the order confirmation page.

The second example has the trigger type Custom Event and the user action is Purchase. This trigger fires when a custom purchase event is pushed to the data layer.

The last example has the suffix “NZ” which tells us that this trigger fires when a user in New Zealand scrolls 75% of any page on your website.


It’s always good practice to include the variable type and description when naming your variables. In some cases, a subtype could be added to make things clearer.

Let’s take a closer look at a few examples:

  • GA Settings - Standard

  • URL - Query - Gclid

  • DLV - ecommerce.purchase.actionField.revenue

The first variable has the variable type GA Settings and the description Standard. This variable is added to Google Analytics tags that are not sending Ecommerce data to GA. Tags using variables sending Ecommerce data would use the naming convention “GA Settings – EEC”. EEC = Enhanced Ecommerce The second example has three parts to it, type, subtype, followed by the description. The type (URL) tells us that the variable is a URL variable, the subtype (Query) that we are dealing with is the query string of the URL, and the description (Gclid) tells us that the variable will hold the value of the query parameter called “gclid”. In the final example, we have a variable with the type Data Layer and the description: e-commerce. purchase. actionField.revenue. This reads as; the variable holds the total revenue, which is found in the data layer, of the transactions that occur on the site(s) or app. You might notice that the description for this variable uses a different letter case from what was recommended earlier in the article. This naming convention, however, is quite common practice for data layer variables. We could name the variable “DLV – Ecommerce – Purchase – Revenue” if that is preferred, as long as we're consistent across all other data layer variables.


Ultimately, there's no one perfect naming convention that fits everyone so feel free to make changes that suits you and your business. Hopefully, this article will be a helpful starting point with getting you familiar with naming conventions in Google Tag Manager!