A starter guide to google tag manager.

Table of Contents

1. What is a tag management system?

2. How GTM works: tags, triggers, and variables

3. Practical advice for using GTM

1. What is a tag management system?

A tag management system (TMS) is a tool that centralises the process of adding and managing small code snippets, called tags¹, on your website², without editing the site’s source code. In the past, developers manually installed tracking scripts. With a TMS, non-developers (analytics, marketing, product, and growth teams) can:

• Deploy analytics tools, e.g., GA4, Mixpanel, Amplitude, Hotjar.
• Add, update, or remove marketing conversion-tracking pixels, e.g., Meta Pixel, Google Ads, Bing Ads.
• Control when and how data is collected.

While a TMS allows for greater autonomy, developers are still required for the initial installation of the TMS container and to pass backend data into the dataLayer, for example, e-commerce data, user IDs, or metadata that reside in your backend.

Google Tag Manager (GTM) is a popular TMS with a free tier that offers consent-aware tag deployment and seamless integration with the Google ecosystem (Google Marketing Platform). We will explore client-side GTM for web apps in more detail next, but you'll find these concepts are broadly transferable to other TMS.

Tip: To check the GTM container ID running on your site, execute google_tag_manager on your browser console.

2. How GTM works: tags, triggers, and variables

Any implementation in your GTM will rely on these three components:

Tags perform the desired action. You can think of tags as what needs to happen. Here are some examples:

• Sending a page view to Google Analytics
• Sending a purchase conversion event to Meta
• Starting a Hotjar session recording
• Tracking form submissions or CTA clicks

If a tag is not available for your specific use case in the featured or community template gallery, you have the option to either use a Custom HTML tag, which allows you to write ES5 JavaScript, or create a Sandboxed JavaScript template.

Triggers define the firing conditions or logic under which a tag should activate. They specify when, how, and where an action must occur. Tags cannot function without a trigger. The most widely used triggers are:

• Page View triggers come in several types. A Page View trigger can fire on consent initialisation (typically used to instruct consent management tags), when the GTM container loads (corresponds to the GTM gtm.js event), when the DOM is ready (gtm.dom), or after all the page resources have fully loaded (gtm.load).

• Click triggers activate tags when a user interacts with links or other clickable elements.

• Custom Event triggers are used in conjunction with events pushed to the dataLayer along with data points associated with the event. Common use cases include triggering Sign Up or Purchase events.

• Element Visibility triggers fire when a UI component enters the viewport (e.g., 50% visible for 1 second).³ These triggers are useful for counting impressions and calculating click-through rates.

All of these trigger types can be finely tuned to achieve specific firing logic based on rules such as element IDs, CSS classes and selectors, value comparison expressions, or string pattern matching. A tag can be assigned more than one trigger to create OR logical conditions (when X OR Y occurs). To define AND logical conditions (when X AND Y must happen) you can use trigger groups.

Variables store data points used by tags and triggers. Variables come in various categories and data types, including built-in variables, lookup tables, constants, custom JavaScript, and more. Here are some examples of how you would leverage the various types of variables:

Use case	Variable type
Set the GA4 Measurement ID	Constant
Get the User ID	Data Layer
Read the user consent preferences	1st Party Cookie
Override the referrer value	Custom JavaScript

The dataLayer is a central point around tracking and tagging. It is a JavaScript array that functions as an event queue that captures information about actions or events that occur as the user interacts with your site. Its main role is to make backend and contextual data available in the front end for tags, triggers, and variables.

3. Practical advice for using GTM

1. Use workspaces

Workspaces act like branches in Git. Use them to isolate changes, especially when multiple people work in the same container, or should you need to roll back changes.

Tip: Name your workspace after your Jira ticket (or your preferred project management tool), e.g., DEV-12: Add GA4 Page View Event. This will facilitate cross-referencing container versions to a more detailed documentation about the scope, context, and acceptance criteria of the implementation.

2. Use a distinct container per environment

Avoid using the same container for testing and production. This practice can lead to data cross-contamination between environments and cause issues with your ad platforms. Just as developers isolate their staging environments, you should use distinct GTM containers for production, UAT, testing, and development.

Tip: Copy configurations across environments using GTM's export/import JSON feature.

3. Naming conventions

When it comes to naming items around your container, consistency is key to ease readability and help you and your team navigate your setup. Here are some suggestions:

Folders – group by vendor/tool: Google Analytics, Meta, Google Ads, Hotjar

Tags – Use the tool/service abbreviation – event naming convention:

Name	Description
GA4 – page_view	Google Analytics
Meta – PageView	Meta
GAds – purchase	Google Ads

Triggers – Use the trigger type – category__details naming convention:

Name	Description
PV – dom_ready	Page view when DOM is ready
CE – purchase	Custom event when the event is 'purchase'
Click – cta_clicked__sign_up	Click CTA only when text matches 'Sign Up'

Variables – Use the variable type – variable_name naming convention:

Name	Variable Type
CONST – ga4_measurement_id	Constant
CJS – get_referrer	Custom JavaScript
DLV – user_id	Data Layer

4. Data privacy and consent

Both analytics and marketing tags collect data about your users, which may include personally identifiable information (PII). If you operate in territories where data protection regulations apply (such as GDPR, CCPA, CPRA, LGPD, and others), you must ensure that these requirements are fully considered when deploying tags. You are ultimately responsible and accountable for all data collection, transfer, residency, and protection on your site.

Make sure that:

• You use a Consent Management Platform (CMP), and the lawful basis and classification of data collection, as well as users’ options to opt in or out, are communicated fairly and transparently.
• Tags that require consent do not fire until the user has explicitly granted it.
• Your consent logic, cookies, and any collected PII are properly documented and auditable.

5. Use GTM for analytics and marketing tags only

Tags and GTM container loading can be delayed and blocked by ad blockers, CMPs, and browser privacy features. Use GTM only for non-essential elements such as analytics, marketing tags, and lightweight enhancements. Keep all mission-critical functionalities in the application codebase where they are reliable and testable.

6. Use templates

Whenever possible, use tag templates instead of Custom HTML tags. Templates run in sandboxed JavaScript, making them safer, easier to maintain, and far more compatible with strict Content Security Policies (CSP). If your web app enforces strict CSP, Custom HTML tags and JavaScript variables will return undefined.⁴ Templates also offer built-in validation and versioning, reducing the risk of insecure or unstable code while offering a user-friendly UI.

7. Preview, test, publish

Before publishing changes of your workspace, make sure you test your tags using Preview mode. Ideally, you should define clear acceptance criteria with scenarios to validate. While it’s difficult to anticipate every edge case, it is worth validating that:

1. Preview mode loads without errors or warnings
2. No errors appear in the browser console
3. Variables return the expected values
4. Tags abide by consent rules
5. PII is hashed
6. Tags fire following the defined logic without duplication
7. Tags fire across mobile, tablet, and desktop breakpoints
8. Tags do not compete or override global scope variables
9. Tools are deployed solely via GTM and no other means (source code, CDP, other code injectors)
10. Custom HTML tags use compatible code with all major browsers and versions (especially if your code relies on modern Web APIs)

Footnotes

1. A tag in a TMS is a code snippet. This differs from HTML tags like <h1> or <a>.
2. TMS can be used in mobile apps and websites.
3. Impression thresholds as per IAB standards.
4. See Google Security and Privacy Hub for more information.