Friday, March 29, 2024
No menu items!
HomeData Analytics and VisualizationGoogle Analytics and Google Tag Manager Naming Convention

Google Analytics and Google Tag Manager Naming Convention

Updated: May 12th, 2021

Google Analytics reports can get a mess really quickly once you start customizing data that is sent to GA. If you don’t follow certain rules/practices, they can eventually become a hot mess.

The same curse applies to Google Tag Manager once you start using it for larger projects. If you name your tags, triggers, variables without using certain patterns, GTM will become a hardly manageable juggernaut no one wants to work with.

In today’s blog post I want to talk about Google Analytics and Google Tag Manager naming conventions (at least what I try to follow while working with these tools). I want to share my thoughts and things I’ve learned over the years.

Important: I don’t mean that the examples and tips I’ll share below are the only truth you should follow. Definitely not. To this day, I find myself quite often tweaking my naming conventions because I find/learn something new or better.

In fact, I remember opening some GA account and thinking “what kind of 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-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 a result of improvement.

All I want to say is that these naming conventions are the ones I use now but I can definitely guarantee that they will/might change in the future to better ones. If you disagree with some of them or know a better solution, please, PLEASE, post a comment. I’m always interested in learning some new stuff.

 

Table of contents

+ Show table of contents +

#1. Accounts, properties, views, and containers
#1.1. Accounts
#1.2. Properties (GA) and containers (GTM)
#1.3. Google Analytics views

#2. Google Analytics Filter Naming Conventions
#3. Google Analytics Segments
#4. Universal Analytics (GA3) Events
#4.1. The incorrect (IMHO) way
#4.2. A better way to name events
#4.3. Other tips/ideas for Google Analytics event naming convention
#4.4. All event values – lowercase values
#4.5. Planning your Google Analytics event naming convention

#5. Google Analytics 4 events
#5.1. General tips
#5.2. Planning your GA4 event naming convention

#6. Google Analytics Campaigns
#6.1. Not being aware of what UTM tags mean
#6.2. Inconsistent UTM naming practices

#7. Custom dimensions and metrics
#8. Google Analytics annotations
#9. Tags
#10. Triggers
#11. Variables
#12. Folders
#13. Workspaces
#14. Versions
What about notes in GTM?
Final words


Two large chunks

This guide can be split into two large chunks, naming conventions of 1. GA and 2. GTM.

As for Google Analytics naming conventions, here are the key areas you can improve:

Accounts, properties, views
Filters
Segments
Events
Campaigns
Custom dimensions, metrics, calculated metrics
Annotations

As for Google Tag Manager naming conventions, here are the key areas that can be improved:

Accounts and containers
Tags
Triggers
Variables
Folders
Workspaces
Versions

 

Disclaimer

Even though I have already briefly mentioned that in the introduction of this blog post, I cannot stress this enough. This is not a definitive guide that tells the only truth you should follow about naming conventions in GA and GTM. If you find some other tactics working for your needs, that’s great.

My goal here is to make more people (beginners) aware of the dangers of not having proper naming conventions and also give examples for those who are willing to improve.

 

#1. Accounts, properties, views, and containers

#1.1. Accounts

When I say “account” in this article, I mean “Google Analytics account” or “Google Tag Manager account”.

I follow the rule that one account is for one client/company. If you are an agency, DO NOT create a single account for your company and then add containers to each individual client/project. Your client must have a dedicated GTM account and all the containers within it.

The best practice here is to ask a client to create an account and then add you as a user to that account.

The same applies to the Google Analytics account. It should be a company/business. One business -> one account.

So when I want to create a new Google Analytics or Google Tag Manager account, I just enter the name of the company. If your company’s legal name is different from your only brand name, you can enter the brand name here instead.

 

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

If we drill down, the deeper level is a property (GA) or a container (GTM).  Logically, each website that belongs to the company should get a property and a container? Well, not necessarily.

Here’s what I try to follow (regarding Google Analytics 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
Analytics Mania – staging
Greatest Company in the World – production
analyticsmania.com – production
analyticsmania.com – staging
greatestcompany.org – production

If websites are thematically connected and are a part of a visitor’s/user’s single experience (e.g. main website, blog, and support page), then I’d recommend tracking them in a single property. Separate properties will put all the data into separate buckets and if you’re not working with the data outside of GA, you’ll have a hard time. However, if you are working for a large organization that has many websites separated but stakeholders also want to see everything in a single property, an additional rollup-property might be an option. There’s also possible a workaround (learn more here).
In this case, the naming convention could be purely based on the environment:
Production
Staging
Development
If you have more additional properties (but they are not used that often), you can add numbers to the most important ones that are commonly used). That way, they will appear at the top of the property list, e.g.:
01 – Production
02 – Staging
03 – Development

As for the GTM containers, you should read this guide that will help you decide how many GTM containers do you need. In a nutshell: if two websites are very much different (in terms of structure and things you plan to track), then two different containers should be used.

If two websites are very similar (maybe just a language is different) and you want to track similar things, then one GTM container for both websites will work better.

As for the naming convention, I try to use the following thing: [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

 

#1.3. Naming convention for Google Analytics views

The view is the 3rd level in the hierarchy of a Google Analytics account. It allows you to view a certain subset of data (or all data) of a particular property. If you want to learn more about the best practices on how to set views up in GA, read this guide.

As for the naming convention, thanks to David Hermann who suggested his naming convention for GA views. I liked his option more so I removed mine and added this one.

Here are the rules to apply in a naming convention for Google Analytics views:

Use numbers/digits to distinguish the most important views and their order
Use property name in the view name
In the end, add the name/purpose of the view

Combine everything and it will look like this — [number (double digits)] – [property name] – [name of the view], for example:

01 – Analytics mania – main view (or you can call it master view)
02 – Analytics mania – test view
03 – Analytics mania – raw view

The first two are the most commonly used in my Google Analytics setup, therefore, I use them in this exact order.

Or another tip can be this: the most important views get the numbers (like the ones I’ve mentioned above). The rest of the view can remain without double digits. Just make sure that they clearly describe their goal/contents and GA will sort all of them in the alphabet order, e.g.

01 – Analytics mania – main view
02- Analytics mania – test view
03 – Analytics mania – raw view
Analytics mania – desktop traffic
Analytics mania – mobile traffic
etc.

Blindly assigning double digits to every view can also do harm because eventually you’ll end up with more-or-less random order and it will not be convenient for newcomers to navigate. So:

The most important views should have the number in the beginning
The rest of them can remain without numbers

Why is it a good practice to include a property name in the view name? One of the possible reasons is managing filters at the GA Account level. If you want to apply a filter to multiple views at the same time, you must be able to distinguish which view belongs to which property. Otherwise, you might end up with something like this:

 

#2. Google Analytics Filter Naming Conventions

When I work with filters in GA, I usually follow this rule when giving a proper name: [type of the filter] – [what that filter does], for example:

Include – office IP address
Exclude – office IP address
Advanced – show full URL
Lowercase – campaign source
Search and replace – remove “/pages/content/” from URL

You might be asking – what is the point of adding a filter type if you can already see it clearly in the filter list? That’s a good point. However, if you want to apply an existing filter to the view, you’ll see only this.

Imagine this, you have two filters, both called “Internal IP address”. One of them includes your internal traffic, the other one excludes. Without seeing the type of filter in the title, you will not know which one to add.

 

 

#3. Naming convention for Google Analytics Segments

If you are new to this feature, you can start by reading this guide. I’d rather skip the introduction (because this naming convention guide is already quite large) and just go straight to the tip on how to better name your segments.

This time, it’s pretty simple (at least how I approach this). Segment name should start with some category (I use either [client name] or [general]) and then I briefly describe what that segment is all about, e.g.:

[Analytics mania] – first-time visitors who converted
[Some other client] – sessions with transaction and coupon code
[General] – sessions with error

If you’re working with clients (e.g. as an agency or freelancer), then the aforementioned naming convention will definitely be useful. If on the other hand, you’re an in-house specialist, [client name] might be redundant in the segment name.

If you want to go to the next level, you can be more specific in the segment name. For example, also include whether this is based on sessions or users, etc.

[client name] – sessions – purchase with coupon
[client name] – users – premium plan

Of course, segments might be much more complex and can be a mix of various conditions. But if you can apply this rule to at least some of your segments, that might help you with navigation in the long term.

But before you jump and start implementing this right away, read one more thing.

Google Analytics segments can be applied on different scales:

To all GA views that you have access to (default). Only you will see it.
To one particular view (that you’re currently working on).  Only you will see it.
To on particular view (that you are currently working on) and other users of that GA view will see it too.

The default is the first one. However, it’s also the most dangerous one if you’re working with various clients (and there is a chance that some of those clients are competitors). Imagine this: you’re doing a presentation/screencast to your client and they notice in your segment list the name of their competitor.

If you always create segments in GA and leave the visibility as default, things might get awkward. That’s why you should create client-specific segments and apply them only to that particular view, use the 2nd or the 3rd option (see below).

 

 

#4. Universal Analytics (GA3) event naming convention

Actually, this chapter is the reason why I eventually decided to write the guide. I started with a little rant here. This part will be about the Universal Analytics event naming convention, not the new Web+App.

 

#4.1. The incorrect (IMHO) way

First of all, I think that the category-action-label concept is misleading and people often enter names that bring no real value.

What happens most often among beginners/intermediate GA users is that people take “Event Action” for granted and way too literally. Here’s an example. A person wants to track button clicks and send them as events to Google Analytics. He/she used the following values:

Category: button
Action: click
Label: {{some click URL}}

What’s wrong here you say? IMHO, the action is useless here. Imagine this: you see a GA report where only the event category is displayed. There is a bunch of events, like videobuttonform, etc.

You’re interested in learning more about buttons. What buttons were clicked? You click the button event category in the report to learn more and all you see is click. Just one row — click. That did not bring me any value whatsoever.

When I click on a dimension in the report (Event Category is a dimension), I expect to drill down and split the numbers into some smaller buckets (e.g. which buttons were clicked?). But now all I see is click.

If you say “but click is an action and this is exactly what I entered”, I ask this: what else can you do with a button? What are other options that you can possibly see in the Event Action?

Yes, I know that it’s possible to track mouse hovering on a button but most businesses don’t do that. So they just end up with a report where there is only one row — click. And the numbers are the same. There were 314 button events and if I drill down, I see 314 events with click action.

Then you click the action and see the table or URLs where that click redirected (a.k.a. Click URL).

To sum up, a wasted dimension.

 

#4.2. A better way to name events

I understand that Event Action implies that you should enter some action there but this is absolutely unnecessary. Follow a different rule: every time you drill down in event reports, it must provide some additional value. Here is a couple of examples.

A new lead is captured:

Category: lead
Action: {{form type}} (if you have multiple types like popup, landing page, embedded form, etc.)
Label: {{form name}}

In this case, I see that there is a certain number of captured leads. If I click the lead event category, I can see which types of lead generation forms work the best. And once I click a certain form type, I can learn which exact forms are performing the best.

An outbound link is clicked:

Category: outbound link click
Action: {{Click Hostname}} (this is a custom variable)
Label: {{Click URL}}

Much better right?


 

#4.3. Other tips/ideas for Google Analytics event naming convention

This is the list of most common events I use in GA. When something (below) is displayed like {{this}}, it means that this is a Google Tag Manager variable (most likely, Data Layer Variable) that returns a particular value.

Category: login
Action: {{login method}} (e.g. “login via email”, “login via google”, “login via linkedin”, etc.)
Label: (not set)

 

Category: signup (or registration):
Action: {{signup method}} (e.g. “login via email”, “login via google”, “login via linkedin”, etc.)
Label: {{signup step}} (e.g. “step 1” (or “registration started”),  “registration complete”, etc.). By tracking each signup step as an event, the data will be able to see drop-offs (like a not-so-sexy-looking funnel reports in a table).

 

Category: error
Action: {{error type}} (e.g. “page not found”, “login error”, “signup error”, “checkout error”, etc.)
Label: {{error info}} (e.g. “passwords don’t match”, “credit card declined”, “xxxxxx page not found”, etc.)

 

Category: lead
Action: {{lead source}} (how was that lead captured? e.g. “embedded form”, “popup”, “whitepaper download”, etc.)
Label: {{lead source name}} (e.g. “newsletter subscription form”, “[XXX] webinar popup”, “[name of the whitepaper] download”, etc.)

 

Category: file download
Action: {{name of a file}} (e.g. “some-brochure.pdf”, etc.)
Label: {{Page URL}} or {{Page Path}}

 

Category: video
Action: {{video status}} (e.g. “play”, “progress: 50%”, etc.)
Label: {{video ID}} – {{video title}}

 

Category: outbound link
Action: {{Click Hostname}} (e.g. “www.example.com”)
Label: {{Click URL}} (e.g. “https://www.example.com/file.pdf”)

 

Category: scroll
Action: scroll distance: {{scroll threshold}}%
Label: (not set) or {{Page URL}}

 

Category: call to action
Action: cta – {{button ID}} (e.g. “cta – signup button in menu bar”, “cta – signup button hero image”, etc.)
Label: {{Click Text}} (optionally, {{Click URL}} might be useful, e.g. “get started now!” or “get started now! –

Of course, the list is not complete. There might be some events that are unique to a certain organization model, but let’s keep those aside. In the end, I end up with 20-30 event categories and I try to keep things at that scale (I usually work with smaller businesses so the scope seems to be right).

Sometimes when I don’t have anything valuable to enter in the Event Label, I just insert {{Page URL}} or {{Page Path}}. And people ask me why? What’s the point of doing that when you can just use Page as a secondary dimension in Google Analytics.

While you can definitely use the Page as a secondary dimension in your GA reports, sometimes you want to create a goal that tracks an interaction only on certain page or maybe a group of pages.

Unfortunately, you cannot add a secondary dimension in your goal settings, therefore, having a Page URL as the Event Label helps.

 

#4.4. All event values – lowercase values

If you follow me for some time, you’ll notice that older blog posts are showing different principles on how to name events. One thing to mention – randomly used uppercase letters.

In one blog post, I use “Outbound links” event category, in other — “Outbound Links”, etc. Over time, this becomes a problem, because Google Analytics is case sensitive.

So if you don’t follow the precise naming convention (including uppercase and lowercase letters), you’ll end up with a mess. And from my experience, the easiest naming convention to remember is always lowercase. And I recommend you do the same thing.

 

#4.5. Planning your Universal Analytics event naming convention

Every time before I start implementing event tracking in GA, first I create a spreadsheet of events that I will track. Even if the tracking of a certain event will be implemented only after 3 months, I start thinking about it as soon as possible.

I create a new spreadsheet with at least 4 columns:

Short event description
Event Category
Event Action
Event Label

Then I start writing down all the events that I think will be valuable to track (obviously, they should align with business goals and should be actually meaningful).

When you write down the list down, then you can start filling in the event category column. When you see the full list of event descriptions, you will naturally start noticing how some events can be grouped under the same category

For example, you have multiple places where a visitor can leave his/her email address.

Why not move them to a single category called lead. Once you fill in all the event categories, you can drill down and start thinking about the Event Action. E.g. all lead events could use the type of form as an event action.

This spreadsheet is your draft and it’s totally ok to redo it several times until you feel that all the events belong to categories they are supposed to be in.

Pro tip: the spreadsheet you have just created is not a one-time job. Keep it updated. When a new event must be tracked, open the sheet and enter that event and match the existing naming convention. If the event is unique (compared to others that already exists), introduce a new event category, action, and label. Share the document with your team and make sure that they always follow the same process.

 

#5. Google Analytics 4 event and parameter naming convention

As Google Analytics 4 is still not very old, I haven’t decided on the best naming convention for myself. Maybe in the future, I will update this part of the blog post but here are my current observations.

 

#5.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, e.g. view_search_results. At first, this looked weird but now, I kinda like it. It’s cleaner, more standardized. If you want, you can still use spaces and uppercase letters, but I would recommend following the recommended naming convention
Looking at the current user interface of Google Analytics, it sometimes might make sense to use more granular event names. For example, instead of “scroll”, you could use “scroll_25” (for 25% threshold).  That way, you will quickly see in the list of all events those scrolling thresholds. I have a blog post about it here.
Various parameters (mentioned in the official Google Analytics documentation) are also following the same all-lowercase + underscores convention). This is not a hard rule and you can send custom parameters with uppercase letters and spaces. But I would follow Google’s recommendation here to have more standardized reports.

If you are sending some parameters to GA4 (e.g. link URL) and you want to see/use that dimension in GA4 reports (e.g Analysis Hub), you will need to register them as custom dimensions. The problem here is that the limit of registered dimensions is 50, so if you send one event (e.g. link_click) with link_url parameter, and then another event (button_click) with button_url, that’s two dimension slots.

So if you plan to send parameters that are very related, you should use the same name for them. Instead of button_url and link_url, you could use just link_url (which, but the way, is one of the recommended parameters).

 

#5.2. Planning your GA4 event naming convention

The best way to achieve that consistency is… surprise surprise… planning.

Speaking of actual planning, I would say that a spreadsheet is your best friend.

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 their naming convention of 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 a huge list of event names, be aware of another limitation. Currently, you can have up to 500 unique events per client id (user). If you are close to that limit in your spreadsheet, maybe it would make sense to combine some events under the same event name and introduce an additional property (currently, the limit of registered custom properties are 50 text properties and 50 numeric properties. More about registered properties – later in this post).

Here is an example of the spreadsheet with events that you could prepare yourself and then try to pick the right naming convention. You can use it as an example/inspiration to come up with your own spreadsheet. Let’s take a quick overview of the spreadsheet.

There are two sheets:

The first one is for the list of events and what kind of parameters do you want to track together with them
The second one is a list of parameters with their explanations

The first sheet:

In column B, you can just briefly describe an event in plain English
In column A, you should enter the name of the event that 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, then add a custom name. It looks pretty clean to use this principle to name the event, e.g. event_name (all lowercase and connected with an underscore). Event names like “Submitted the Form” will also work, but the all-lower-case-with-underscore looks cleaner (I believe that the term snake-case applies here).
Column C is for type (is it Automatically collected, Enhanced Measurement, Recommended or Custom?).
Column D is for parameters that you want/plan to track with particular events. I did not include default parameters that are automatically tracked with every event: language, page_location, page_referrer, page_title, 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 are working just with the website, feel free to remove that column.
Column C is the type (is it Built-in, Recommended, or Custom). Built-in means that it is used by automatically tracked events or Enhanced Measurement. Recommended parameters are for recommended events. Custom parameters are your own unique events.
Column D is for description (in plain English).

IMPORTANT: This spreadsheet is just an example. You don’t have to blindly follow it. If you wish, you can take just some parts and adapt it to your needs.

Once you prepare the plan, then you can track events with Google Analytics 4. Don’t rush too soon. Otherwise, you might face the consequences in the long run.

 

#6. Google Analytics Campaign naming convention

Google Analytics lets you track the source from which a visitor came to your site (e.g. search engine, social network, etc.). But if you are running a campaign and want to see it as a separate traffic source in your GA reports, campaign tracking features allow you to do that.

This is possible thanks to 5 parameters called UTM tracking parameters:

utm_medium. It identifies the medium from which a visitor/user landed on your site (e.g. email, organic, affiliate)
utm_source. This is a more specific source compared to the medium. If the medium is email, the source could be “newsletter”, “automated email”, etc.
utm_campaign. Here we go even one level deeper. This parameter should contain the name of the campaign, e.g. “summer 2019 promotion”, “black friday 2019 launch”, etc.
utm_term. This parameter is usually used to track keywords that drive traffic to your website (especially useful for paid advertising)
utm_content. If the same keyword is targeted with several ads, then the name of each ad could be defined with help of utm_content.

To learn more, head over to Online Metrics.

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

Marketers are not fully aware of what medium, source, etc. actually mean and how are they connected
The naming of those parameters is inconsistent.

 

#6.1. Not being aware of what UTM tags mean

To address the first issue, you should read this guide and memorize this pyramid (taken from Online Metrics as well).

Even though there are other variations of this pyramid, I prefer this one.

Medium is the broadest of all UTM parameters and you should not have many unique values here.  Imagine them as buckets. The reason you want these buckets to be big is it allows you to slice and dice your data by source and campaign name when all that data comes in.

Although this list isn’t exhaustive and your campaigns may warrant mediums that aren’t included, here are some good mediums Annie Cushing used over the years:

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

And you should follow something similar. Don’t create unique mediums for each campaign. You’ll just ruin the dimension and mess with the GA channel reports (for example, this is an example of how I would not recommend doing — every campaign’s medium is the date when that campaign was launched).

The best way to fight this is to educate yourself and your team. Read this and this guide to be more familiar.

 

#6.2. Inconsistent UTM naming practices

As I have mentioned before, Google Analytics is case-sensitive. This means that if one link uses “email” as utm_medium and the other one is using “Email”, they will be reported as two separate medium, 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. As a safeguard, you can also implement GA filters for that purpose.
the source and campaign name are consistent as well throughout different mediums
In general, all UTM parameters follow the same naming convention that is adopted by your company (but also follows the industry’s best practices).

And the best way to do that is to have a centralized place where all UTMs are managed. 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 UTMs, you open a sheet (if you decide to go with that option) and you can already notice patterns that the company/team follows.

Based on them, you will be able to create a new link without breaking things. Annielytics offers a free spreadsheet example of what you (or your team) could adopt. You can copy it here.

And keep all the marketing/analytics people in your organization up-to-date with this solution. Instruct them on how to generate new links, explain the current campaign tracking naming convention.

Also, it’s a good practice to do a health check every 3 months to see if new weird values have appeared in campaign reports. For example, a good indicator is Acquisition > All Traffic > Channels report. Go there, click the (other) channel and you will see custom mediums that might require fixes.

 

#7. Custom dimensions and metrics

When I create custom dimensions or metrics in GA, I like to add a prefix “cd -” (custom dimension) or “cm -“ (custom metric).

The reason why I do that is it’s easier to find when I want to add a secondary dimension or build a custom report.

For example, whenever you want to include a custom dimension, you just enter the “cd” in the search field and the list of all custom dimensions is at your fingertips. A small improvement but makes the work smoother.

As for calculated metrics, you can add “calc” to the name.

 

#8. Google Analytics annotations

Even without a consistent naming convention, you HAVE to use annotations in GA. They will help you keep track of changes/events/etc. that might have an impact on your data collection process.

A website redesign? That should be mentioned in GA annotations as well.
A new campaign was launched? Create an annotation for that.
Something was misconfigured and you fixed it? Yup, one more annotation.

While I will not dive deeper into the actual functionality, here are several tips on how can you make your list of annotations a bit more readable. Because if you start utilizing this feature more often, the list might get a bit too clunky over time.

That’s why adding a prefix might become valuable. Just keep in mind this process is still manual in Universal Analytics. If you want to create an annotation, you will do that on the view-level and manually. API is still not available (after 10 years of waiting).

Anyway, so here’s the tip. Add a prefix – “what type of change was made?”

[config] – some configuration in Google Analytics or Google Tag Manager was made that may have an effect on your numbers in GA
[marketing] – a new marketing campaign was launched
[tech] – some technical non-product-related change was made, e.g. website relaunch, website’s loading speed optimized, etc.
[product] – new product feature was released, a new category of products was added, etc.
[bug] – a bug that has an impact on data collection (e.g. a certain GA feature was incorrectly implemented)

Examples:

[marketing] – black friday launch
[config] – new GA filter: include traffic to www.example.com hostname

Some parts of the naming convention above were based on Paul Koks’ blog post.

The first batch of tips was related to Google Analytics. Now let’s move to the realm of Google Tag Manager.

 

Google Tag Manager naming conventions

Just before we jump right into GTM naming conventions, I have a quick disclaimer. If you are super new to Google Tag Manager, enroll in my free Google Tag Manager Fundamentals course to get started.

 

#9. Tags

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

That’s why I always follow naming conventions to stay as clean as possible. Even if I know that the container will consist only of several tags now, I cannot be sure of what will happen after 12 or 24 months.

Here is the rule that I usually apply to tag names:

[type of the tag/vendor] [additional type (if needed)] – [short description about what the tag does].

And a sample result might look like this:

GA Event – Homepage – CTA clicks (in this case, I also included the location of where the tracking is happening).
GA Event – Document file downloads (if tracking occurs on every page, then just simply describe what is being tracked).

Here are a few more examples of Tag Naming Conventions to give you some ideas on how to name your tags:

GA Pageview – All pages
GA Pageview – Optin thank you page
GA Event – Outbound link click
GA Event – EE – Checkout
FB – Lead
FB – Purchase
Hotjar – Pageview
cHTML – AJAX form listener

cHTML stands for Custom HTML. Sometimes it makes sense to split the short description into several items (to give more context or mention a location), e.g.:

GA Event – Click – Document links
GA Event – Click – Outbound links
GA Event – Form – Newsletter
GA Event – Form – Whitepaper


#10. Triggers

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

Regular
Blocking

For regular triggers, I use the following naming convention:

[trigger type] – [what does that trigger do]. If it makes sense, I also mention a location where that trigger applies. For example:

Link click – Outbound link
Click – Register button – menu bar
DOM Ready
Visibility – Main popup
Custom – login (for custom event triggers, I enter the actual name of the targeted custom event)
Custom – checkoutStep
History Change

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 – Link click – Outbound link
Blocking – Custom – Login

 

#11. Naming Convention for Google Tag Manager Variables

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

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

dlv – postData.postAuthor – in Data Layer Variables, I enter the actual key that it accesses in the Data Layer
cookie – isEmailSubscriber – 1st party cookie variable’s name includes the name of a cookie that is being accessed
js – document.title – here the name includes the global JavaScript variable that is returned by this GTM variable
cjs – customTask – prevent duplicate transactions – Custom JavaScript Variable’s name usually contains a short explanation what does that variable do
url – click hostname –  in case of the URL variable, I use either a short description or a certain parameter/part that the variable returns
aev – data-brand – in Auto-event variables, I usually enter the name of an attribute that I am accessing. But in other cases, it might also make sense to just describe what that variable does in plain English.
GA settings variable – if only one GA Settings Variable is used in the container, then I just simply name the variable “Google Analytics Settings Variable”. But if there is a slight chance of having multiple, then the name of a variable could be this:  GA settings variable – UA-XXXXXXX-XX.
Regex – [Input variable] to [Output variable], e.g. Regex – Page Hostname to GA ID

I hope this makes sense.

 

#12. Folders

When it comes to folders, I’m not 100% sure which naming convention to use. I usually choose from 3 options that have pros and cons. So I guess, you can try them all and see which one sticks better.

#12.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 (everything else can be added here. Or just keep them as Unfiled items

 

#12.2. GTM Folder naming convention based on the vendor

Google Analytics
Facebook Pixel
Bing UET
Custom HTML
etc.

 

#12.3 Naming folders based on a certain implementation/feature

GA Enhanced Ecommerce (all variables, triggers, and tags that are used in the setup are added to 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 features. Unfortunately, you cannot add an item to more than one folder.

Looking at the setup of my most recent containers, I’m doing a mix of #11.2 and #11.3 options. If it is possible to isolate a group of items in 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?

 

#13. Workspaces

Workspaces are temporary places where you can work on your setup. When a workspace is published, it is turned into 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 am I going to implement.

When the job is done and I initiate the publishing of the container, workspace’s name becomes a version name (of course, you can edit it).

So in this case, I just try to be clear (but not go too much into details). E.g. “GA Enhanced Ecommerce” or “Signup/Login tracking with GA”.

If you are working in a larger organization, some additional information might be valuable, for example:

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

In the description of the workspace, it will be a good practice to briefly describe the goal of the workspace, involved parties (people), features to be implemented, e.g.:

 

#14. Versions

I cannot stress enough how important it is to give names to versions in GTM containers. I’m not even talking about some naming conventions/rules.

Imagine this. You realize that one of the previous versions broke tracking the implementation of a certain analytics tool. You’re not sure what exactly caused this issue so you need to investigate. Then you open a list of versions and you see this:

Not very helpful, huh? The situation would have been a lot easier if those versions had some short names that could give you clues on where to look first.

The next thing that you should definitely consider is version descriptions. The reason why they are useful is that when you open a certain GTM Container version, you will have a quick overview of what was changed. Of course, you can scroll down and see what container items were added/removed/modified, but reading a quick overview is more convenient.

No magic rules here. I just like to enter all the changes as list items:

And if you properly enter information while creating a workspace (enter both name and description), then you have already completed half of the job needed for the version (because name and description are reused).

 

What about notes in GTM?

Currently, I don’t use them very actively.

The main reason: their visibility is quite poor. I have dealt with multiple situations where people just missed my notes and were still asking questions about X or Y in that container.

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

 

Google Analytics and Google Tag Manager Naming Conventions: Final words

Whew! That was a lot of information! Naming conventions definitely changed the way I organize my Google Analytics and Google Tag Manager accounts. They brought more logic and structure to my setups.

Even though it would be great if you applied all the tips in your practice, you are not obliged to. See what fits your organization’s needs the most. Try several things and see if they stick.

Also, if you know something better than what I shared here, please let me know. This topic is constantly evolving in my stack and I keep tweaking things.


The post Google Analytics and Google Tag Manager Naming Convention appeared first on Analytics Mania.

Read MoreAnalytics Mania

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments