Google Tag Manager and Google Analytics 4 Naming Conventions

Last Modified on October 23, 2024

Tracking implementations can be tricky in general, especially if there’s no or poor communication between the devs, marketing, and the implementation specialists.

Add to it sometimes the tight deadlines and you have a messy melting pot of different tags, events, and variables quickly thrown into the world of tracking without much thought.

So, while the implementation is marked as ‘done’ on your to-do list, the reporting data for end users and tag management for the next person might not be very helpful if it doesn’t follow any naming conventions.

In this post, we’ll discuss why it is important to have naming conventions along with the following topics:

• Why are Naming Conventions Important?
• Google Tag Manager Naming Conventions
• Google Analytics 4 Naming Conventions
• Best Practices for Google Tag Manager and Google Analytics 4 Naming Conventions

Considering names are used everywhere in both these tools, we have a lot of ground to cover. Let’s start naming!

Why are Naming Conventions Important?

Before we get into the what and hows, it’s important to understand why Google Tag Manager and Google Analytics 4 naming conventions are important. You might have an idea already but let’s go over them:

1. Easy Management – When you have a set naming convention that everyone follows, it makes it easier to understand what each tag, trigger, variable, event, and custom dimension/metric means without digging into each one of them. It also makes it easier to quickly pick up on any obvious errors like spelling mistakes, etc.

2. Better Collaboration – Following consistent naming conventions allows everyone working in GTM and GA4 to understand the setup. It also helps to avoid errors or use names that are already used with some variation and are not very descriptive or helpful for analyses. Overall, it gets everyone on the same page.

3. Consistent Reporting – If the events and/or parameters are not named properly or consistently, e.g., too long, not descriptive, or using different names for similar events, then it can make analyses quite difficult. Using consistent naming makes your data reporting consistent.

4. Helpful for Non-Tech Users – If you’re a frequent GTM or GA4 user, then you would understand the nuances. But, if there are other non-tech users, then they’d be spending a lot more time trying to understand what your names mean. So, easier-to-understand consistent naming will be easier to absorb while dealing with the intricacies of the tool’s UI.

5. Easy to Scale – Once there are ​​well-established naming conventions, it’s easier to scale when your tracking matures. It also future-proofs any conflicts or confusion when the business grows and/or someone new joins the company because they will simply follow what’s already been working.

These are some major reasons why having naming conventions for analytics setup can be quite helpful and important!

Maybe you aren’t thinking about it much if you’ve started your business just now or you only have a few tags/events being tracked. But, it’s not a bad idea to have it established from now on and if you’re already a mature business, it’s never too late!

It’s important to point out that Google does not recommend naming conventions in most cases except in a few areas. More on that later.

These conventions are based on experience and suggestions in the industry which means you can always change and improve if that helps you!

Google Tag Manager Naming Conventions

There are eight places where we can establish naming conventions when using GTM. These are:

1. Accounts
2. Containers
3. Workspaces
4. Tags
5. Triggers
6. Variables
7. Folders
8. Versions

Let’s see how it works for each.

1. Accounts

Accounts are at the top level and generally, one business should have one account. Even if you have several different websites, they can all be covered under the same account.

If you handle other people’s containers, it’s always a good practice that they are under their separate account vs you having their containers in your account, which is a common mistake agencies and consultants make.

The naming convention here is rather simple:

• Business Name, e.g., MeasureSchool or in the case below MeasureSchool Demo Acc

2. Containers

Containers sit inside your GTM accounts. For example, if the account is ‘MeasureSchool,’ it can have multiple containers.

How many containers you have for your business can also give an idea about how you name them.

If you have similar websites then having one container works (including sub-domains). If you have different websites and/or businesses under one company, then having separate containers makes sense.

You can start with the following naming convention:

• Business/Website Name (e.g., MeasureSchool)

You can use the above naming convention if you use the same container for multiple sites.

However, using a single container for multiple sites can make tag management quite challenging and might even increase the container size (remember max size limit is 200kb).

If you have multiple containers for different websites under the same business, then you can name them like this:

• Business/Website Name (www.domain.com)
  • MeasureSchool – www.measureschool.com

You don’t need the hostname if you have multiple containers for the same website’s different areas and name them as follows:

• Business/Website Name – Site area/Section/Purpose
  • MeasureSchool – Main Site
  • MeasureSchool – Measure Masters
  • MeasureSchool – Staging
  • MeasureSchool – Development

You might have noticed one thing – all these conventions are quite telling about what the container is for. So, your names are now clear and easy to understand!

3. Workspaces

In free GTM accounts, you can use up to three workspaces, which is unlimited in GTM 360.

Workspaces are copies of your existing container where you can build up tags or make other changes without affecting the live container unless the workspace is published.

Once the workspace is published, it becomes the live version taking the name of the same workspace and the temporary workspace disappears. You can rename the version later on so don’t worry about that.

However, you might not always need a workspace if you’re working on a quick small change and/or are the only person managing the GTM container.

But when that’s not the case, the following method can be quite helpful

• Company/Person’s Name – What they are working on
  • MeasureSchool – GA4 Ecommerce Tracking
  • Usman – GA4 Ecommerce Tracking
  • MeasureSchool – Usman – GA4 Ecommerce Tracking

If it’s a large organization and there are other people with the same names, you can add the full name and/or the team you work in.

Generally, the names can be self-explanatory. When that might not be the case and you’re working on something more complex, it’s better to add some description as well, so if someone looks at it they can understand what it is you’re working on.

4. Tags

Naming tags work a bit differently depending on the tag type, the vendor as well as what the tag is for.

When you start, the container might have a handful of tags so it might be easier to manage. But as you scale, having many tags with no naming convention can make things confusing pretty easily!

This is why perhaps the most important place to have naming conventions is for the tags because most people opening the container usually go to tags first.

We can follow the following naming convention for Google Analytics 4 tags:

• Vendor’s abbreviated name – Event name/Action – Additional info (optional)
  • GA4 Event – button_click – Sitewide 
  • GA4 Event – Ecommerce – add_to_cart
    You don’t necessarily need to say ‘Event’ because everything GA4 receives is an event now.
  • GA4 – menu_click

For Google Tag or GA4’s base configuration, you can use any of the following:

• GA4 Config
• Google Tag
• GA4 Config/Google Tag – Measurement ID
• GA4 Config/Google Tag – Lookup Measurement IDs
• GA4 Config/Google Tag – No Pageview (if you’ve set the send_page_view parameter to false)

For other tags:

• Meta – Pixel – 859508457409711 (Pixel ID is optional here)
• Meta – Conversion – Lead form
• MAds – UET
• GAds – Conversion – Purchase
• LI – Insight Tag

What about Custom HTML tags? These could follow the following convention:

• cHTML – Vendor/Additional info – Action/Purpose/Event name, e.g.
  • cHTML – Hubspot – Form Listener
  • cHTML – DLP – photoAdded (dataLayer push and the event key name)
  • cHTML – DLP – Filter Selections (for multiple dataLayer events)
  • cHTML – Meta Pixel

You could also add the agency name if you’d like to, so that the tags are distinguishable, but that’s generally not something practiced a lot.

5. Triggers

Triggers can fire the tags or block them. So, naming them in a way that tells what type of trigger it is, any conditions, and/or where it’s being fired can be quite helpful.

When the triggers are regular ones, i.e., they are not blocking any tag, we can follow this naming convention:

• Trigger type – name – additional info (optional)
  • Link Click – Navigation Menu
  • Custom or CE – form_submitted – Demo page
  • Click – CTA Button
  • Visibility – Live Chat

For the Custom Event trigger type, it’s better to use the exact event name as it is in the dataLayer, so it’s easier to tell what event it is right away.

What about blocking aka exception triggers? You can follow the same naming convention but add ‘Blocking’ or ‘Exception’ as a prefix:

• Blocking – Custom – hubspot-form-success
• Exception – Click – CTA Button

Apart from this, some triggers are used globally without any filters and they can be simply named to their type:

• All Pageviews
• DOM Ready
• History Change

6. Variables

Variables can be referenced in other GTM areas, so knowing the type and what a variable does makes it easier when we are using them. The following format can be helpful:

• Abbreviated variable name – What it does/returns/accesses

Let’s explore what it would look like for different variable types:

• URL: url – Query – step (returns the query component with the name of the query key, i.e., step).
• 1st-Party Cookie: cookie or 1pc – isPaidCustomer (mentions the name of the cookie that will return the value).
• Custom JavaScript: cjs – Find closest element (describes that it’s finding the closest element).
• Auto-event: aev – Element Text (returns the text of the element).
• Lookup and Regex: For these two variables, it makes sense to use the name – Input variable to Output Variable/What it does, e.g., lookup – Hostname to GA4 IDs and regex – dlv – financeType to Name of the finance type.
• Google Event Settings: GA4 event settings – container version (shows that it’s for GA4 and what type of settings are there). You don’t need the additional info if there’s only one event settings variable.
• User-Provided Data: If there’s going to be only one variable, then simply using the same name would suffice. However, you can make it more descriptive, i.e., user-provided – name and email or user-provided – automatic (both names tell what it’s collecting along with the method).

Dealing with variables can be a bit cumbersome because there are quite a few of them with different types. It can work out if there’s some method to this madness.

7. Folders

While folders might not be one of the top priorities when using GTM, they can be helpful to further organize things.

There are generally two ways to do it:

1. Name the folders based on the tags’ purpose
2. Name the folders based on vendor/tag type

Let’s see what that would look like.

1. Folder names based on the tags’ purpose

Naming folders based on the purpose of different tags helps to group different tag types for different vendors into one place:

• Analytics or Tracking (GA4 tags, variables, and triggers)
• Marketing (Meta, Bing, LinkedIn tags, StackAdapt, etc.)
• CRO (VWO, Hotjar, etc., and any tags related to conversion rate optimization)
• Consent (CMP and other related tags can go here, although some group them under Analytics or Marketing)
• Utilities (Custom event listeners or dataLayer pushes)
• Misc or Others (Anything else; you could leave them unfiled but it would be more organized to have a generic folder)

2. Folder names based on vendor/tag type

This format will keep things specific. For instance, going by vendor type:

• GA4 (All GA4 tags, variables, and triggers)
• GAds ( Google Ads tags)
• Meta (Pixel and other events)
• Cookie Bot (Consent management tags)
• Other Vendors (If there’s only one tag for a vendor)

There could be a third way to name the folders, where you separate them by your chosen method and further split them by tags, triggers, and variables:

• GA4 – Tags
• GA4 – Triggers
• GA4 – Variables
• Analytics – Tags
• Analytics – Triggers
• Analytics – Variables

But this would lead to three folders for each type of category and beat the purpose of optimizing and organizing the container. It might also make the management a bit more difficult.

8. Versions

You might notice that most containers with even 50+ versions do not have names. This is not helpful, especially if you notice that something is broken and you want to find out what recent changes could’ve caused that.

Apart from this, it’s also generally helpful for anyone looking at previous versions to understand what happened with each one, even more so when you’re not working in that container anymore.

There’s not much of a naming convention here, as long as you have something that explains what the version is doing, and if it’s something too complex, then add notes explaining what, why, and how you did the implementation.

The following format can be helpful:

• Action + any additional info regarding what you did
  • Removed unused variables
  • Adds consent tracking 
  • Modifies triggers for GA4’s purchase event

The action part uses the verb which can be either in past tense (e.g., removed) or continuous where it shows what this version is doing (e.g., adds, modifies, etc.). In the description, you can also add further detail on ‘why’ and ‘how’ you did.

The table below is a quick way to understand how all these components in GTM come together following this top-to-bottom hierarchy: Account → Containers → Tags, triggers, variables, and all other GTM components.

Level 1	Account	For one business
Level 2	Container(s)	One container can be for one brand/website and separate containers for different websites
Level 3	Workspace(s)TagsTriggersVariablesFoldersVersions	All the other components sit inside the containers

So that wraps up some naming conventions for GTM. Next up: GA4’s naming conventions.

Google Analytics 4 Naming Conventions

Just like GTM, there are several places in GA4 where you can implement naming conventions. These are:

1. Accounts
2. Properties
3. Streams
4. Events
5. Parameters
6. Custom Definitions
7. Explorations

Let’s get going!

1. Accounts

Similar to GTM, you have accounts in GA4, and we can follow the same logic. One business should have one account and if it has more than one website then they can all go under that account.

You could have the same name for your GA4 and GTM accounts so things are consistent, e.g., MeasureSchool.

2. Properties

Properties are roughly equivalent to containers, as they are under the accounts and we can apply a similar logic here as well. For example, if the websites are similar or linked in some way with each other, then having them in one property makes sense.

If that’s not the case, and these are completely different websites, like there are generally separate properties for development/testing and product/live, then having two properties makes sense.

Another example would be if you have completely different brands for the same business. Let’s say MeasureSchool has Measure Tools and Measure University, where both websites are different then they should have separate properties.

This is how we can name them:

• Brand or domain name – lifecycle stage/purpose
  • Measure Tools – Staging
  • Measure University – Test (if you don’t want a setup that goes through the lifecycle, i.e., development, staging, production, etc., then you can use something generic like ‘Test’ so anything can go there)
  • www.measureuniversity.com – Live/Production/Main (all these names indicate that this is the property to be used for reporting)

As you go about using this naming convention, it’s important to have two properties for each website, and the name should include whether it’s for testing/staging/development or live/main/production.

One is where you can dump anything and the other that is used for reporting where the name clarifies that. 

If your business wants to have separate properties for all different regions and then one property for all of them together, then you can use the Roll-up property only available in GA 360 (paid version).

This is where the path diverges between GA4 and GTM because now we’ll look at naming conventions that are specific to GA4.

3. Streams

This is perhaps the simplest of all. You can enter the name of the website as a Stream Name because the domain is already added in the Stream URL when you click on the stream.

4. Events

While all other naming conventions are arbitrary, the naming of events for GA4 is different because of how Google has laid out certain rules when it comes to naming them. So, they must be named properly. Here are the rules:

• GA4 event names are case sensitive, i.e., button_click, Button_click, and Button_Click will be counted as three different events.
• Names should only start with letters, so something like 1st_step is not correct vs step_1.
• Words and letters can be in any language.
• Events should not use reserved names and prefixes that are used by Google already when using tag manager. However, if you create or modify events in the GA4 interface, then you can use the names of automatically collected events. Events collected automatically by GA4’s Enhanced Measurement feature can be re-used if you turn off this feature in GA4. You can read more about reserved names and prefixes here.
• Names can have letters, numbers, and underscores, but no other special characters.

That being said, generally, the event naming convention is based on snake_case, i.e., lowercase and with underscores (no spaces).

This is something you will consistently find in Google’s documentation, so it makes it easier to follow this; even though you can use upper case, it just makes sense to follow what’s in the documentation.

Here are a few examples: button_click, generate_lead, popup_viewed, etc.

5. Parameters

Parameters are part of the events, so they follow the same rules and have reserved names and prefixes that shouldn’t be used.

Unlike events, you can set up these in GTM and send them out to GA4. But, when you go to register them as custom definitions in GA4, you will encounter an error as you can see in the screenshot below.

The best course here is to use the same naming convention with snake case, e.g., car_age, button_text.

6. Custom Definitions

Any parameters that you want to use in standard reports have to be registered as a custom definition (dimension, metric, or user property).

The automatically collected ones can be used in Explorations, but they will have to be registered as a custom definition if you want to use them in standard reports and audiences.

There are two ways to how you name custom definitions:

• Use the same name as it’s being collected, e.g., button_text.
• Use a simpler name without any underscore, e.g., CTA Text, Button Text.

How you name them doesn’t affect the reporting or collection of data apart from how they are shown in the reports.

7. Explorations

This might be a little tricky to implement if many people are using GA4 for reporting. Not everyone might use the same naming conventions, which happens when a shared email address is being used to access a GA4 property.

But whether it’s several people or just you, it’s not good when you see several explorations saying ‘Untitled exploration’, ‘Free-form’, or something obscure that even you might forget later on when you’re looking for an exploration you worked on a couple of months earlier.

To keep things more organized, you can follow these naming variations:

• Exploration type – What it is for/reports on
  • Free-form – CTA clicks on homepage.
  • If a shared email is being used among more than one person, you can also add your name or initials to it, e.g., Free-form – CTA clicks on homepage – Usman.
  • If you have multiple tabs in the Exploration (which is quite possible) or a specific segment, then add what’s the overall goal, e.g., Funnel – Application steps or Funnel – Application form on mobile. 
  • If you have web and app streams in the property, then you can also add that for clarity, e.g., Funnel – Application steps – Web.

Here’s what the hierarchical table would look like for GA4:

Level 1	Account	For one business
Level 2	Properties – Min 2 i.e. one for Live and one for Testing	– One property can be for one brand/multiple linked websites and separate properties for different websites
Level 3	StreamsEventsParametersCustom DefinitionsExplorations	All the other components sit inside the properties

We’re not quite done because we are going to look at some best practices next.

Best Practices for Google Tag Manager and Google Analytics 4 Naming Conventions

Some of these practices are universal so they can be applied to both tools, in fact, to any other tool, as well while others are more GA4-specific. Let’s start with the former:

• Consistency – Except for GA4’s event names, all other naming conventions aren’t a rule. So as long as you decide on naming conventions that work for your business and you are consistent with them, it would work perfectly well!

• Collaboration – It’s important that when certain naming conventions are applied, everyone in the team/department is aware of them so it’s not just one person who’s aware and putting out fires by correcting names all the time. Therefore, it should be a collaborative effort.

• Documentation – Having some documentation that helps to first formulate event names, tag names, trigger conditions, etc., makes it easier to manage and track naming conventions. It also allows for consistency across teams and projects.

• Scalability – When naming things you should plan for scalability when your tracking needs grow. So, the event and parameter names, etc., are reusable whenever possible, though sometimes having specific event names is good for granularity.

These practices on their own could be quite helpful! But when it comes to GA4’s naming practices some other tips can set you up for easy reporting life down the road.

1. Be Wary of Limitations

There are two major types of limitations for events in GA4.

The first limitation concerns the length of characters. The event name should not be more than 40 characters; if it’s more then Google won’t be able to append “_c” to mark it as a key event.

User properties, parameters, user IDs, and their values have also their limitations.

The second limitation is how many custom dimensions and metrics you can have depending on the scope and whether you’re using the free version or GA 360 (paid version). 

You can find these by going to Admin → Data display → Custom definitions → Click on the Quota information button in the top right corner.

This means where you can, you should reuse the parameters (regardless of scope) for multiple events, and that means giving them names that can be re-used easily versus being too specific.

For instance, if you track button_text and link_text with buton_click and menu_click events, then you’ll use up two spaces in your custom dimensions.

But if you use only one of them for both events, then you’d be saving space. So, use them sparingly.

On Apps, you also have a limit on collecting 500 distinct events, but they don’t apply to the web streams. You can read more about these limitations by Google here.

2. Balance Between Granular and Generic Names

While generally, it’s good to have generic names as they can be used by other events, sometimes you can favor granularity by opting for more specific names if those events are more important.

For instance, generate_lead could have off-shoot events like generate_lead_vehicle, generate_lead_finance, etc., as it could help to avoid sampling in Explorations.

Why? What you select in an exploration is then queried. With granular names, a query will be simpler than applying event names and specific parameters, especially when the event count is high. Sampling kicks in at 10 million, to be precise.

Granular names can also make it easier to create explorations like paths and cohorts, as you cannot choose parameters for each event in those reports, e.g., generate_lead event that happened on the finance page won’t work.

You can apply a segment, but remember that will be applied to the whole report.

But this doesn’t mean it’s now open season to have super specific event names, e.g., generate_lead_vehicle_hatchback_hybrid_5dr, because this sort of naming will make analysis a painful experience and it will be rather scattered.

Imagine reading such long event names in GA4’s UI.

Remember that the limitation of 40 characters applies here and if it’s marked as a key event, then it won’t be counted as one.

Longer names also affect the size of the network request and if you’re storing data in BigQuery, then it would need more space as well.

What it requires is the balance between using generic names and granular ones based on how you plan to use that event data, and that requires planning.

3. Create or Modify Events in GA4’s Interface

You can create new events from existing events or modify existing events (due to any spelling mistakes or whatnot) right in GA4’s interface. Go to Admin → Data display → Events → Click on the Create button.

So, let’s say we want to fire another event when the ‘Hoodies’ page is viewed on our demo shop.

We can leverage the existing page_view event and say when the event_name equals page_view and the page_location equals https://demoshop.measure.school/product-category/clothing/hoodies/ fire, a separate event is called page_view_hoodies. 

You must maintain the same naming conventions that you are using for other events, as well as follow the name rules Google has specified.

It’s also a nice quick way to create events that provide granularity but were not part of your original tracking plan. Now you can use them in your path and cohort explorations for analyses! However, this feature has some limitations:

• Changes won’t apply retroactively but after you create/modify the event.
• You can modify and create up to 50 events based on existing events.
• Modifications can take an hour to be executed.
• Modifications are calculated client-side, i.e., before any data is sent to Analytics.
• If you’re using gtag.js, then you can’t generate or modify events based on parameters from the items array (e.g., item_category, item_name, item_id, etc.).
• Events sent in a server-to-server setup cannot be modified, e.g., when you’re using Measurement Protocol.

It’s important to understand that these are not the only best practices and there might be more that surface in the future.

However, they can give you a solid base when you’re getting started, and knowing all these limitations can help you plan a better measurement strategy!

Summary

We started with understanding why naming conventions are important and how they can save us pain later on.

Then we hopped on the GTM train and learned all about naming conventions from accounts, and containers to tags, triggers, variables, and more!

After that, we covered naming conventions for GA4, where we learned that there are certain rules to be followed when it comes to events and parameters.

We then looked at the best practices that apply to both tools. Most importantly, as long as we have a naming convention that works for us and we stick to it following Google’s rules, we are good!

Most conventions in this guide are merely ‘suggestions’ not rules that you must follow.

Finally, we learned about some GA4-specific best practices where we explored the limitations, how using generic vs granular names can be helpful, and finally how we can create/modify events in GA4’s interface.

Talking about events, if you want to set up custom events, check out our post on How to set up GA4 Custom Events using Google Tag Manager.

So, what naming conventions do you use and how has it helped you? Let us know in the comments below!