GTM Naming Conventions for Tags, Triggers & Variables

Open someone else’s Google Tag Manager container and you can usually tell in ten seconds whether they had a system. Clean containers read like a table of contents. Messy ones have tags called “Tag,” “Tag copy,” and “GA4 event (new) FINAL,” and nobody, including the person who built it, remembers what fires where.

This is the naming convention we use. It is simple on purpose: put the platform first, use one separator, and let the names describe what fires and where. Learn it once and every container you touch stays readable.

The one format to remember

Every tag follows the same shape:

<Platform> - <Type> - <Descriptor> (optional context)

One separator throughout: a space, a hyphen, a space. That is it. Here is the whole system in one screen:

GA4 - Config
GA4 - Event - generate_lead (contact form)
Meta - Base Pixel
Google Ads - Conversion - Lead

Platform first (GA4, Meta, Google Ads) so tags sort by platform automatically. Then the type. Then a plain-English descriptor, with a parenthetical only when the same event fires from more than one place.

Tags

The base tag of any platform is its Config (GA4) or Base Pixel (Meta). It carries no event; it just turns the platform on. Everything else is an Event tag that names the exact event being sent.

Prefer the native tag templates from the gallery. Reach for a custom HTML tag only when there is no template, and prefix it cHTML (lowercase c, uppercase HTML) so it is obvious it contains hand-written code.

Triggers

A trigger’s name should say how it listens. The most common one is the Custom Event trigger, which listens for an event in your data layer. Name it with the data layer event verbatim:

CE - form_submit
CE - cta_click
Click - Outbound link
Scroll - 90%

Variables

Turn on GTM’s built-in variables before you build anything custom. There is no reason to create a “Page Path” variable when {{Page Path}} already exists. Build a custom variable only for values you push yourself.

The key rule: a Data Layer Variable’s name mirrors the real data layer key, dotted path and all. If your site pushes form_location, the variable is DLV - form_location. The name becomes documentation of what is actually in your data layer.

Event names: use what GA4 recommends

This is the rule that keeps your reports clean. GA4 publishes a list of recommended event names, and using them unlocks features and consistent reporting. Send the recommended event when one fits; invent a custom name only when nothing does.

Event names are always lowercase snake_case. When you do need a custom event (say, a generic hero CTA click with no recommended match), keep it clean: cta_click with descriptive parameters. Then register those parameters as custom dimensions in GA4 so they show up in your reports, and mark value events like generate_lead as key events.

Three finishing touches

• Folders. File every tag, trigger, and variable in a folder, organized by platform (GA4, Meta, Google Ads) plus a shared Utilities folder. Nothing loose. The folder list should read like a table of contents.
• Consent. Give every tag its consent settings (GA4 tags require analytics_storage; ad and Meta tags require ad_storage), and turn on the Consent Overview so no tag ships unconfigured.
• Publishing. Name every version YYYY-MM-DD - what changed and write a one-line description of what and why. Your Versions list becomes a changelog you can actually read.

The free template

Put it to work

Naming is only step one; the point is a container anyone can read. If you are still building yours, these walk through the pieces:

• How to install Google Tag Manager
• How to add GA4 through Google Tag Manager
• How to track button clicks with GTM

Name things this way from the first tag, and the container stays readable no matter how big it gets.