A tag manager container someone can actually maintain
Containers rot in a predictable way: tags nobody can identify, triggers pointing at URLs that no longer exist, three variables reading the same value differently, and an event firing from two places because two people solved the same problem separately. We inventory what's live, remove what's dead, move money events off fragile URL triggers onto backend records, and document it so the next person inherits something readable.
Free30 minutesNo obligation
GTM consulting · what breaks
What a rotted container looks like — GTM consulting
- 01
Tags nobody can identify
Left by previous agencies or developers, still firing.
- 02
Triggers pointing at URLs that changed
Correct tags, conditions that are never true.
- 03
The same event firing twice
Two people solved it separately and neither knew.
- 04
No documentation at all
So every change is archaeology before it's work.
GTM consulting · the fix
What you get out of it — GTM consulting
One firing path per event
Confirmed by inventory rather than assumption.
Money events off URL triggers
Fired from records, so a redesign can't silently break them.
A container someone can read
Named consistently, documented, safe to change.
Dead weight removed
Fewer requests, less to go wrong.
GTM consulting · architecture
Why the numbers were wrong before you got here — GTM consulting
Worth understanding before buying anything, because it decides which tier you need — and for some readers the answer is that you don't need us yet.
- 1
The browser is the weakest link, and it is getting weaker on purpose
Every browser-side tag has to survive the page loading, the visitor staying, the script running and the request leaving. All four are now contested. The order in your database is certain; the browser event reporting it is not.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits JavaScript-set cookies to seven days whatever expiry you set, so a customer who takes longer than a week to decide returns as a stranger. A cookie your own server writes in an HTTP response is not capped — the single largest practical difference between browser-side and first-party server-side.
- 3
Ad blockers remove the tag with no error
A blocked pixel does not warn anyone. The customer buys, the order lands, and no platform hears about it. First-party events from your own subdomain are not a third-party request and are not filtered the same way.
- 4
Consent is enforced by hope, not by architecture
Client-side consent means trusting each vendor script to honour a flag. A server container decides at the container: a denied destination receives nothing. That is a materially stronger position, and it also stops the over-blocking that discards data no law required losing.
- 5
Checkout can end where your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. Sending the purchase from the order record means it arrives whether or not anyone came back.
GTM consulting · diagnose
How we scope the gtm engagement — GTM consulting
Before quoting. Each step narrows what the work actually is, so the price reflects your account rather than an average.
- 01
Inventory every tag, trigger and variable
Including ones outside the container that duplicate it.
- 02
Check which tags have fired recently
Broken or obsolete — different fixes.
- 03
Find duplicate firing paths
Invisible from inside any single interface.
- 04
Check triggers against the live URL structure
Most rot happens here.
- 05
Check variable definitions for conflicts
Three variables reading one value differently is common.
- 06
Verify on live transactions
Preview passes while production fails, routinely.
GTM consulting · prove
How the work gets proven — GTM consulting
A dashboard turning green proves a dashboard turned green. These are what we hand over instead.
Source of truth
Live transactions on your production site
- One firing path per event, confirmed by inventory across every layer.
- Every remaining tag identified and justified, with removals recorded.
- Money events confirmed firing from records rather than URLs.
- Container documented well enough for someone else to change safely.
- Reconciled over a fully closed window, matched on ID rather than on totals — totals hide equal and opposite errors.
- Payload evidence captured from real transactions, saved to your own records.
- The same reconciliation repeated 30 days later, because a setup that works once and drifts is the harder failure.
GTM consulting · free audit
What we check in the free audit
- Inventory every tag, trigger and variable
- Check which tags have fired recently
- Find duplicate firing paths
- Check triggers against the live URL structure
- Check variable definitions for conflicts
- Verify on live transactions
Checked against
Live transactions on your production site
Free30 minutesNo obligation
GTM consulting · when not to buy
When you shouldn't buy this — GTM consulting
We would rather say it now than three weeks into an engagement.
- Your container has fewer than a dozen tags and you built them all. You already know what's in there.
- You're about to replatform. Clean up after, on the new structure.
- Nobody will maintain it afterwards. Documentation only helps if someone reads it.
- You need a specific fix rather than a cleanup. Go straight to the fix.
GTM consulting · what we deliver
What's included in the gtm engagement — GTM consulting
Full container inventory
Every tag, trigger and variable, with what it does and whether anything still needs it.
Dead tags removed
Deliberately, with a record of what was removed and why.
Triggers rebuilt
Off fragile URL conditions where a better signal exists.
Naming and structure standardised
So the container is navigable by someone who didn't build it.
Version control practice
Named versions with real notes, so a bad change can be reversed.
Documentation handover
Written for your team, not as a record of our work.
Written guarantee
95%+ tracking accuracy
Measured against Live transactions on your production site. Miss it and we keep working at no cost.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
The correct browser-side build, done properly and verified on a live transaction. Honest about its ceiling: it will not survive Safari's cookie cap, an ad blocker, or a checkout that ends somewhere your tag isn't. If you spend $1K+/month on paid media, start one tier up.
- Correct events, correct parameters, correct values
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover you keep
1st-party server-side
Recommended$800One-time fee · most popular
The tier that changes the outcome rather than patching it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright, with no monthly SaaS.
- First-party server container on your own subdomain
- Money events sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, plus the offline loop that connects closed revenue back to the click. For advertisers whose spend makes an attribution leak more expensive than the build.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
GTM consulting questions, answered
That's what the inventory is for. Nothing is removed without establishing what it was and who relied on it, and every removal is recorded so it can be reversed.
Not necessarily. A clean web container is worth having on its own. Server-side matters when browser restrictions are costing you conversions — measure that before deciding.
Usually three to five days for a typical container. Longer where several people have built into it over years, which is most of them.
Yes, with versioning so any change can be reversed. We don't rebuild from scratch unless there's a reason.
