Tag Manager Setup
Google Tag Manager, done once, done well.
Container architecture, data layer design, tag naming conventions, consent-aware triggers, workspace versioning, and the governance that keeps GTM from turning into a hairball of 70 abandoned tags three years later.
Tag Manager · GTM-XY4Z9PQv12 · published
Preview
Tags · 7
GA4 Config
Google Analytics 4
→ All Pages
GA4 · purchase
GA4 Event
→ dataLayer purchase
Meta Pixel · base
Custom HTML
→ All Pages · Consent
Meta · AddToCart
Custom HTML
→ add_to_cart
Google Ads · Conversion
Ads Conversion
→ purchase
TikTok Pixel
Custom HTML
→ All Pages · Consent
LinkedIn Insight
Custom HTML
→ All Pages · B2B paths
Debug · Preview Mode
Event: add_to_cart · 6 tags sequenced
Version history
v12
v11
v10
v9
v8
The four building blocks of GTM
Tags, Triggers, Variables, Data Layer.
Tags
What fires — GA4 events, Meta Pixel, Google Ads conversions, LinkedIn Insight, custom HTML scripts. We keep them atomic, one purpose each.
Triggers
When they fire — page views, clicks, form submits, custom events from the data layer. Consent-aware so nothing fires before consent granted.
Variables
What data they use — page path, item ID, user ID, cart value. Properly-named built-in + user-defined variables prevent copy-paste chaos.
Data Layer
The source of truth — a JavaScript object holding all dynamic values. Tags read from it, not from the DOM. Cleanest, most reliable pattern.
Governance that scales
Naming conventions = future-proofing.
After 6 months a typical GTM container has 30+ tags. Without naming discipline, it becomes unmanageable. Here's the pattern we use and document with every client.
✓ Tags
[Platform] · [Event type] · [Optional qualifier]
Examples: GA4 · purchase · ecom · Meta · Lead · B2B form · Ads · Conversion · phone_call
✓ Triggers
[Type] — [What it matches]
Examples: Custom Event — purchase · Click — cta_primary · Form Submit — newsletter
✓ Variables
DLV — [dataLayer.key] (for data layer vars), JS — [purpose], CJS — [purpose]
Examples: DLV — ecommerce.items · JS — hashed_email · CJS — scroll_depth
✕ What we remove
Tags named "test", "new tag", "GA". Triggers named "Page View" (ambiguous — is it All Pages?). Variables with no prefix.
Our GTM approach
We don't build throwaway containers.
What we avoid
✕ Scraping the DOM for values a data layer should expose
✕ CSS-selector triggers that break on next design iteration
✕ One tag per campaign instead of reusable variable-driven tags
✕ Copying tags to modify them vs. using lookup tables
✕ Publishing without QA via Preview Mode
✕ No documentation of what each tag does or why
What we do instead
✓ Data layer-first — push from app code, not scrape
✓ Custom events in data layer, not selector matching
✓ Variables + lookup tables for campaign-level mapping
✓ One tag per channel, parameterised by variables
✓ Preview Mode QA on every change, real browser validation
✓ Notion documentation keyed to each tag + trigger
Monthly governance
What we do on an ongoing GTM retainer.
Health audit
Container monitored for orphan tags, broken triggers, consent issues. Monthly report shows fire volume trends.
Change log
Every workspace change documented. When + what + why. Reverse-engineering prevented via discipline.
Version hygiene
Old versions pruned. Meaningful version names ('v14 — CAPI deployed'). Workspace merges clean before publish.
New tag requests
Marketing asks for new tracking → we scope, build, QA, document, publish. Typical turnaround 2–4 days.
Frequently asked
Tag Manager questions.
Yes, often. We usually start with a full audit — inventory tags, categorise them, flag orphans, identify duplicates, document what each does. From there we either clean in place or build a parallel container to migrate into. Parallel is safer for large containers.
Related services
Commonly paired with
Get a free GTM audit.
Share container access and we'll return a tag inventory, orphan detection, performance audit, and the top 10 cleanups to run. Free, no commitment.