GTM and Google Analytics 4 Naming Conventions

Updated: April 4th, 2025

Customizing data collection for Google Analytics 4 is definitely necessary, but reports can quickly get chaotic if you don’t follow any naming rules or practices.

The same issue applies to Google Tag Manager once your projects grow. Naming your tags triggers and variables without adhering to specific guidelines can turn GTM into a hardly manageable Goliath (sans David) that nobody wants to deal with.

Over the years, I have been following formulas for Google Tag Manager and Google Analytics 4 naming conventions that I follow to keep my work more organized. In today’s blog posts, we will go through my suggestions.

Important: These are only suggestions. I’m by no means saying that the examples and tips that I share are the only way to do things. Definitely not.

To this day, I find myself often tweaking my naming conventions because I have learned something new. In fact, I remember looking through a GA4 account and thinking, “What idiot did that?“ I looked at the change history, and it turned out that it was me! I did those stupid things 1.5 years ago.

And I think that in two to three years, my future self will think that some of the naming conventions I’m using today are total rubbish and there’s a better way to tackle certain situations. But on a more positive note, that’s just an example of improvement.

All I want to say is that these naming conventions are the ones I use now, but they will probably change to better ones as GA4 and GTM evolve. If you disagree with some of them or know a better solution, please post a comment. I’m always interested in learning new things.

Table of Contents

Here’s what you will learn in this article

• Two Large Chunks
• Disclaimer
  • #1. Accounts, properties and containers
  • #1.1. Accounts
  • #1.2. Properties and containers
    • #1.2.1. Properties (GA4)
    • #1.2.2. Containers (GTM)
• GA4 naming convention
  • #2. Events and Parameters
    • #2.1. General Tips
      • #2.1.1. Limits
    • #2.2. Planning
  • #3. Campaigns
    • #3.1. Know what UTM parameters mean
    • #3.2. Inconsistent UTM naming conventions
  • #4. Custom dimensions and metrics
  • #5. Explorations
  • #6. Annotations
• Google Tag Manager naming convention
  • #7. Tags
  • #8. Triggers
  • #9. Variables
  • #10. Folders
  • #11. Workspaces
  • #12. Versions
  • #13. Notes
• Final words

Two Large Chunks

This guide can be split into two large chunks: Google Analytics 4 naming conventions and Google Tag Manager naming conventions.

For Google Analytics 4, the areas that you should implement naming conversion improvements for are:

• Accounts and properties
• Events and parameters
• Campaigns
• Custom dimensions, metrics & calculated metrics
• Explorations

For Google Tag Manager, the areas that you should implement naming conversion improvements for are:

• Accounts & containers
• Tags
• Triggers
• Variables
• Folders
• Workspaces
• Versions

Disclaimer

Even though I have already mentioned this (and I can’t stress it enough), this is a guide, not a rule book; you don’t need to follow the exact naming conventions mentioned. The important thing is just to have a system, whatever that may be.

My goal is to make more people (especially those just starting out with GA4 and GTM) aware of the importance of proper naming conversions and provide some examples.

Even if you have been a user of GA4 and GTM for years, it may be worthwhile to review your naming conventions. While it’s never too late to start, the longer you go on, the more tedious it will get, so start as soon as possible.

#1. Accounts, properties (GA4) and containers (GTM)

Let’s start with the foundations of GTM and GA4 – accounts, properties, containers.

#1.1. Accounts

When we reference the “account” in this article, that means “Google Analytics account” or “Google Tag Manager account”.

The general rule I follow (for both GA4 and GTM) is “one business, one account.”

If you are an agency, do not create a single account and add containers for each client or project. Each client should have a dedicated GTM account (with all relevant containers) and a dedicated GA4 account (with all relevant properties).

The best practice here is to ask a client to create an account and then add you as a user to that account (preferably Editor or Admin). Or create an account yourself and then give admin rights to the client.

As for the names of the accounts, I would use the company’s name to keep it simple. If the company’s legal name differs from your only brand name, you can enter the brand name instead.

#1.2. Properties (GA4) and containers (GTM)

If we drill down, the deeper level is a property (GA) or a container (GTM). So, should each website belonging to the company get a property and a container? Not necessarily!

#1.2.1. Properties (GA4)

Here are some tips for Google Analytics 4 properties:

• If separate websites of a business are not connected in any way (e.g. two totally different/unrelated products/brands/etc.), then it’s totally fine to have them separated in unique properties. In this case, the name of the properties could be:
  • [brand name (or domain)] – [environment], for example:
    • Analytics Mania – production or analyticsmania.com – production
    • Analytics Mania – staging or analyticsmania.com – staging
    • Greatest Company in the World – production or greatestcompany.org – production
      

• I no longer use “GA4” in the property names. Universal Analytics is already dead, so it makes no sense to mention “GA4” because, obviously, all properties are GA4. You can easily distinguish that a property is GA4 by looking the property ID below the property name. If it contains only numbers, that’s GA4.
• If websites are thematically connected and are part of a visitor’s single experience (e.g. main website, blog, and support page), then I’d recommend tracking them in a single property. Multiple properties will separate the data, making it hard to work with unless you use a tool outside of GA4, like BigQuery.
  • However, suppose you work for a large organization with many separate websites, but stakeholders want to see everything in a single property. In that case, an additional roll-up property might be an option.
    • In this case, you can base the naming convention purely on the environment: Development, Production, and Staging.
      

Tip: You can prefix your property names with numbers so that the most important (or most used) ones are at the top of the list (otherwise, GA4 will sort them alphabetically).

#1.2.2. Containers (GTM)

As for the Google Tag Manager containers, you should read this guide, which will help you decide how many GTM containers you need. In a nutshell, if two websites are very different (in terms of structure and things you plan to track), then you should use two containers.

If two websites are very similar (perhaps just the language is different) and you want to track similar things, then one container for both websites will work better. Similarly, if you have multiple sites using the same login information, you might want one container for all these sites.

As for the naming convention, I try to use the following: [short name/description] – [domain if one container is for one website], for example:

• Main website – www.example.com
• Blog – blog.example.com
• Landing pages – www.example.com (this is useful when landing pages are hosted on some other platform)

If multiple websites are using the same container, you can skip the hostname, e.g.:

• Online stores
• Main website and landing pages

Google Analytics 4 naming convention

Now, let’s take a closer look at Google Analytics 4.

#2. Events and Parameters

While this article is a guide, there are actual rules for event naming that you need to follow, so you should review these first. These include:

• Case-sensitive event names, e.g. event_name is not the same as Event_Name
• Allowing the use of English and non-English words
• Not using reserves prefixes and event names
• Using only letters, numbers and underscores, no spaces
• Event names must start with a letter

#2.1. General Tips

Google Analytics 4 already has a list of recommended events and their parameters. After looking at that list, you can already say that:

• Events should be named all-lowercase and with underscores (snake case), e.g. view_search_results. Various parameters (mentioned in the official Google Analytics documentation) also follow the same all-lowercase + underscores convention.
  • This is not a hard rule; you can still send custom events and parameters with uppercase letters and spaces. But I would follow Google’s recommendation here to have more standardized reports.
• Looking at the current user interface of Google Analytics 4, using more granular event names sometimes might make sense. For example, instead of “scroll”, you could use “scroll_25” (for a 25% threshold). That way, you will quickly see those scrolling thresholds in the list of events. I have a blog post about it here.

#2.1.1. Be aware of limits!

If you send some parameters to GA4 (e.g. clothing_id) and want to see/use that dimension in GA4 reports (e.g. Free form report), you will need to register them as custom dimensions.

There are limits to the number of custom dimensions you can have in a single property. You can read more about the limits here. These limits will differ based on whether you have a standard or 360 property.

To see the information on your limits, click Quota information on the Custom dimension page.

Imagine a scenario where you send one event (e.g. link_click) with link_url parameter and then another event (e.g. button_click) with button_url. That’s two dimension slots.

In this case, you should reuse parameter names when you have similar parameters for multiple events! Instead of button_url and link_url, you could use just link_url (which, by the way, is one of the recommended parameters).

#2.2. Planning your GA4 event naming convention

The best way to achieve that consistency is – surprise surprise – planning (you’ll notice a theme in this article).

Speaking of actual planning, a spreadsheet is your best friend. I know it feels like the enemy most of the time, but trust me, it will save you. Use this spreadsheet to do the following:

• Write down all the events that you want to track, and then:
  • Check whether they fall under the categories: automatically collected, enhanced measurement, or recommended. Learn more about them here.
  • If yes, check the provided naming convention for the event names and parameters (dimensions). If not, then come up with your own values. Just keep in mind that there are some limitations related to the length.
• If you have an extensive list of event names, be aware of a limitation for app events. You can have up to 500 unique events per app user daily (this doesn’t apply to web events). Suppose you are close to that limit in your spreadsheet. In that case, combining some events under the same event name might make sense, as well as introducing an additional property (currently, you can have 50 event-scoped custom dimensions and 50 event-scoped custom metrics).

Here is an example of a spreadsheet with events you could update for your needs. You can use it as an example/inspiration to create your own spreadsheet.

Let’s take a quick overview of the spreadsheet.

The first sheet:

• In column A, you should enter the same event name you will use in Google Analytics 4. You should pick this name based on the previously described process:
  • Check the automatically tracked events, enhanced measurement, and recommended events.
  • If none of the events match yours, add a custom name, e.g. event_name (all lowercase and connected with an underscore).
• In column B, just briefly describe an event in plain English. This will be especially helpful if you have other people in your company looking at this sheet.
• Column C is for type. Is it Automatically collected, an Enhanced Measurement, Recommended or Custom?
• Column D is for parameters you want/plan to track with particular events. I did not include default parameters automatically tracked with every event: language, page_location, page_referrer, page_title and screen_resolution.

If you are dealing with mobile apps as well, you could include an additional column “Platform” where you could enter “web” or “Android / iOS”.

The second sheet:

• Column A is for the parameter name.
• Column B is for a platform. If you only have a website, feel free to remove this column.
• Column C is the type. Is it Built-in, Recommended, or Custom?
  • Built-in means that automatically tracked events or Enhanced Measurements use it.
  • Recommended parameters are for recommended events.
  • Custom parameters are your own unique events.
• Column D is for a description (in plain English).

IMPORTANT: This spreadsheet is just an example. You don’t have to follow it mindlessly. If you wish, you can take just some parts and adapt them to your needs. For example, adding a “date of implementation” column may be helpful so you know when data would have started collecting for an event.

Once your plan is ready, you can begin tracking events with Google Analytics 4.

Take your time with this process. There is no need to rush. It’s better to take the time now to get things set up than face the consequences in the long run (when you inevitably have to make updates to everything and then cannot fix the data retroactively).

#3. Campaigns

Google Analytics 4 can track and analyze specific marketing campaign details using UTM parameters. This is possible thanks to UTM parameters. There are five parameters, which I refer to as the “classic parameter”:

• utm_source – Tracks the referrer, e.g., youtube.com or a particular newsletter
• utm_medium – Tracks the type of marketing medium, e.g., email or cpc
• utm_campaign – The specific campaign you are running, e.g., black-friday or boxing-day-sale
• utm_term – If you manually tag paid keyword campaigns, use this parameter to identify paid search keywords.
• utm_content – This parameter is helpful when the same campaign is run across multiple locations, leading to the same link to compare which does best. For example, if you have the same email campaign but use different photos in the email, you can use the utm_content parameter to distinguish between the two emails.

Additionally, there are:

• utm_id: Identifies a specific campaign, e.g., you may have multiple Black Friday campaigns that you want to distinguish
• utm_source_platform: The platform or source where a user clicked on the UTM-tagged link
• utm_creative_format: As the name suggests, the creative format used in the campaign, e.g., banner or image
• utm_marketing_format: The tactic used in the campaign, e.g., remarketing or prospecting

However, you cannot currently report on utm_creative_format and utm_marketing_format in GA4.

When working with UTM parameters, I notice two big problems:

• Marketers are unaware of what these parameters represent and how they are connected
• The naming of those parameters needs to be more consistent.

#3.1. Know what UTM parameters mean

Before you begin, read this article on UTM parameters in Google Analytics 4 and review this pyramid (borrowed from the article here).

While there are variations of this pyramid, I prefer this one.

Essentially, this shows the amount of variation in values that you should see in each parameter. So, the medium should contain the least unique values, whereas the content will have the most.

Although this list isn’t exhaustive, here are some examples of mediums that Annie Cushing has used over the years (and you should follow something similar):

• social
• email
• feed
• banner
• cpc
• display
• affiliate
• ebook
• tv
• print
• billboard
• partner
• radio
• qr
• widget

While your campaigns may use mediums that aren’t included (be very selective when doing this), do not create unique mediums for each campaign. You’ll just ruin the dimension and mess with the GA4 Acquisition reports.

Not to mention, having too manu unique mediums, it can also increase the number of Unassigned sessions. So, just keep it simple.

#3.2. Inconsistent UTM naming conventions

As I have mentioned before, Google Analytics is case-sensitive. This means that if one link uses “email” as the utm_medium and another uses “Email”, they will be reported as two separate mediums. Hence, the data quality will be poorer.

This means that you need to work on your UTM management practices. Your job is to make sure that:

• All values in UTMs that you (and your team) use are lowercase.
• In general, all UTM parameters (e.g. campaign and source) follow the same naming convention adopted by your company (but also follow the industry’s best practices).

And the best way to do that is to have a centralized place where you manage all UTM parameters. It can be a tool like UTM builder or a simple Google Sheet.

Whenever you (or someone from your team) need to generate a new link with UTM parameters, you can open the Google Sheet (if you decide to go with that option) and quickly see the patterns that your company/team follows.

Based on what’s in the sheet, anyone can create a new link without breaking things (hopefully).

So, what can you do? Keep your organization’s marketing/analytics people up-to-date with this solution. Instruct them on generating new links and explain the current campaign tracking naming convention.

Also, doing a health check every 3 months is a good practice to see if new weird values have appeared in campaign reports. Go to Reports > Acquisition > Traffic Acquisition. Select the “Session medium” dimension.

#4. Custom dimensions and metrics

For custom dimensions/metrics, name them the same as the parameter name in Google Tag Manager so it will match what you have in your event spreadsheet, making it easy to reference. You can also add a description to clarify things (can’t hurt, right?)

There is a folder for custom dimensions when you add a secondary dimension to a built-in standard report or dimensions/metrics into an Explore, so they are already grouped (no need to add a prefix).

Since calculated metrics are defined in GA4, they won’t be in the event spreadsheet; adding a “CM” prefix to these values may be helpful.

Remember, these are recommendations, not requirements. Some clients/companies might not want to see “CD” or “CM” in their reports. They might think such names are not “pretty.” So it’s ok to not use “CD” and “CM”.

Also, if your clients don’t want to see underscores (e.g., member_level), it’s fine. You can use “Member level”.

#5. Explorations

There is nothing worse than opening Explore in GA4 and seeing a sea of “Untitled exploration”, primarily when you work in a property many people can access and share explorations in.

Even if you are the only one with access to the property, it’s frustrating when you know that you have created a report but need to look through all explorations to find it since you didn’t name it well (or at all)

Depending on how complex your website is, I have two suggestions for how you can name your reports:

• • [Type of exploration] – [Short description of your report], e.g. “Funnel – Add to cart to purchase”
  • [Type of exploration] – [Web or App] – [Short description of your report], e.g. “Free form – App – All users”
    • If your site is split into clear sections or you have different product offerings, then you can change the 2nd element of the name to be one of those, e.g. “Path exploration – Shopping – Pages before checking out”.
  • If your exploration contains multiple tabs, then describe the theme of that exploration. E.g., if you are analyzing checkout performance, then simply name the exploration “Checkout performance” or “Checkout analysis”.

#6. Annotations

Annotations in GA4 are notes that you can add to your reports to provide context to your data. They help you remember important events, changes, or observations directly within the GA4 interface.

Annotations are visible to all users with access to that particular GA4 property. So, if you create an annotation, your colleagues will also see it. And this is helpful for team collaboration because more people will be on the same page.

Also, it can prevent duplicated efforts of troubleshooting data when two different people are investigating the same thing.

To keep your annotations organized and easy to find, I recommend using a consistent naming convention. Start each annotation’s title with the category name, for example:

• “Marketing -” for marketing campaign-related annotations.
• “Website -” for website updates.
• “Configuration -” for configuration changes.

Examples:

• Website – New homepage layout launched
• Marketing – Black Friday sale
• Config – New event tag – form_submission
• Technical – Website downtime due to server maintenance

If you are looking for more annotation ideas, take a look at the blog post here.

Google Tag Manager naming convention

If you are reviewing naming conventions before even installing Google Analytics 4 with Google Tag Manager, firstly, good on you; secondly, check out this article to learn how to install GA4 with GTM.

#7. Tags

Tags are little snippets of code that you can activate on your page based on particular conditions (configured in GTM). It’s pretty easy to work in a container that consists of 10 tags. But once it starts growing, the naming practices of tags begin to matter.

That’s why I always follow naming conventions to keep things as clean as possible. Even though the container only consists of a few tags now, I can’t see into the future (and how things will change).

Here is the rule that I usually apply to tag names: GA4 event – [event_name]. Using the same naming convention as in the event spreadsheet is helpful for easy reference.

A sample result might look like this:

• GA4 Event – cta_clicks (this event might occur on multiple pages, but you can differentiate these events using the auto-tracked page_location).

For the Google Tag, you can use any of these:

• GA4 config
• or GA4 config – [measurement ID]
• Google Tag
• Google tag – [measurement ID]

#8. Triggers

Triggers are conditions that tell when a tag should (or shouldn’t) fire. Based on their nature, triggers can be:

• Regular, or
• Exception (blocking)

The general naming convention for regular triggers is: [type of trigger] – [name_of_trigger]. In the case of custom events, enter the exact key it accesses in the Data Layer. For example:

• custom – comment
• custom – member_level
• link click – menu
• click – blog – register button
• visibility – main popup

Some triggers can just be the type of trigger, e.g.:

• All link clicks
• History change
• DOM Ready

Youtube and Scrolling triggers usually just end up being called “Youtube” and “Scrolling”.

As for blocking triggers, I always add the “Blocking – ” prefix, e.g.:

• Blocking – All link clicks
• Blocking – custom – comment

#9. Variables

All my variables in GTM start with a prefix that tells me the variable type. Here are the abbreviations I’m using:

After the variable type, I either enter a short description (what the variable does) or what item/variable/data point the variable returns. Examples:

• Data Layer Variable: dlv – member_level – enter the key it accesses in the Data Layer.
• 1st part cookie: cookie – isEmailSubscriber – include the name of the cookie being accessed.
• Javascript Variable: js – document.title – include the global JavaScript variable that is returned.
• Custom Javascript Variable: cjs – modified ecommerce object – briefly explains what that variable does.
• URL: url – click hostname – use either a short description or a particular parameter/part that the variable returns.
• Auto-Event Variable: aev – data-brand – I usually enter the name of an attribute I access. But in other cases, describing what that variable does in plain English might also make sense.
• Google event settings – something simple like “GA4 event settings” will do for this variable.
• Regex: regex – [Input variable] to [Output variable], e.g. “regex – Page Hostname to GA ID”

I hope this makes sense.

#10. Folders

When it comes to folders, I’m not 100% sure which naming convention to use. There are three options – each with its pros and cons – that I choose between. So, you can try them out and see which one sticks best.

#10.1. Naming folders based on the vendor’s purpose/type, e.g.

• Analytics (e.g. you can add GA tags here)
• Marketing (e.g. Facebook Pixel tags could go here)
• Utilities (e.g. various Custom Auto-event listeners could go here)
• Other (you can add everything else here, or just keep them as Unfiled items)

#10.2. GTM Folder naming convention based on the vendor

• Google Analytics
• Facebook Pixel
• Bing UET
• Custom HTML
• etc.

#10.3. Naming folders based on a specific implementation/feature

• GA4 E-commerce (put all variables, triggers, and tags that you use in the setup in this folder)
• GDPR cookie consent mechanism
• Login/registration tracking

The problem with this approach is that sometimes an item (e.g. a variable) is used in multiple tags. Unfortunately, you cannot add an item to more than one folder.

Looking at the setup of my most recent containers, I’m using a combination of options #9.2 and #9.3. If it is possible to isolate a group of items into a single feature folder, I do that. Then, I might also create a folder just for a vendor (e.g. Hotjar).

What are your thoughts on this?

#11. Workspaces

Workspaces are essentially a temporary copy of your container where you can make changes without affecting the live version of your container until it’s published. When a workspace is published, it becomes a new container version (and then the workspace vanishes).

When I’m working on a small project, and I know that no other person will be working on GTM at the same time, I usually just create a new workspace and, in the Name field, enter what feature I will implement (or just work in the default environment).

When the job is done, I publish the container, and the workspace’s name becomes the version name (of course, you can edit it). So, in this case, I just try to be precise (but not go into too much detail). For example, “GA4 Ecommerce” or “Login tracking with GA4”.

If you are working in a larger organization, some additional information might be valuable, e.g.

“GA4 Ecommerce – [team member working on it]”. If the organization is large, you can also include the department’s name, e.g. “GA4 Ecommerce – Sales – John Doe”.

In the description of the workspace, it is good practice to briefly describe the goal of the workspace, involved parties (people) and features you are implementing.

#12. Versions

I cannot stress enough how important it is to give names to versions in GTM containers. Forget about specific naming conventions; just document something about the changes you made for your own sake and that of everyone else working with you.

Imagine this: You realize that one of the previous versions broke tracking the implementation of a particular analytics tool. You’re unsure what caused this issue, so you must investigate. Then you open a list of versions, and you see this:

Not very helpful, huh? This situation would have been a lot easier if you (or someone else) had labelled the versions to give you an idea about where to start looking.

The next thing that you should definitely consider is version descriptions. When you click on a GTM container version, the description will give you a quick overview of what was changed. Of course, you can also scroll down and see what container items were added/removed/modified, but reading a quick overview is more convenient.

There are no magic rules here; I just like to enter all the changes as list items:

And suppose you follow the suggestion from above and enter this information while creating a workspace. In that case, you have already completed half of the job needed for the version (because the new version will adopt the name and description of the workspace).

#13. What about notes in GTM?

While they are not as noticeable, I think it’s still worthwhile to add notes if you make any changes to tags, as it can be helpful with debugging if something goes wrong. People may still miss them and ask questions about X or Y in the container, but at least it can be something that you reference.

I recommend adding the date so you know when you made the change and comment on what you changed (you can also add the name of the person who made the change if you work in a bigger organization).

On the other hand, adding comments to the very top of Custom HTML tags worked better for me (I mean, at least more people noticed them).

Google Tag Manager and Google Analytics 4 Naming Conventions: Final words

To reiterate one last time, this. is. not. a. rulebook. The most important thing to take away from this article is to have some sort of system – any system at all.

If you have had Google Analytics and Google Tag Manager for a while and have not set up any naming conventions, then I’m sure you’re knocking yourself for it now, but it’s not too late to start (and it’s best to start as soon as possible).

If you’re just starting, then learn from other’s mistakes and triumphs and set up your Google Tag Manager and Google Analytics 4 naming conventions! Test a few things and determine what works best for you and your business.