Inherited a Google Tag Manager setup nobody wants to touch?
Google Tag Manager is meant to make adding and managing tracking straightforward. Instead, many businesses end up with a container full of old agency pixels, half-built workspaces and fragile triggers that break the moment a developer updates a page. - Old agency pixels, paused scripts and duplicate tags are still sitting in the workspace. - Website updates break your tracking because triggers are tied to button text or page URLs. - Multiple tags or platform integrations are firing on the same checkout or form and skewing your numbers. - You're replatforming or launching a new feature and need a proper data layer specification for your developers. Agentix provides Google Tag Manager audits, setup and container repairs for UK eCommerce, B2B and trade businesses. We bridge the gap between your website code and your marketing tools so every tag has a clear purpose, a dependable trigger and a documented version history.
Why Tag Manager gets messy over time
Tag Manager sits right between your developers and your marketing teams. In our experience, nobody owns that gap. In our experience, paid agencies we work alongside have to work with whatever container they inherit. When a campaign needs to go live quickly, a trigger can get hooked onto whatever button or URL is available that day. When a designer later changes that button or a developer updates the form, the trigger can stop working without anyone noticing. And because nobody wants to risk breaking a live campaign by deleting a tag they didn't set up, older tags can stay running alongside the new ones. Before long, you have duplicate tags firing on the same checkout or enquiry, leftover scripts adding weight to your pages, and an unpublished workspace that someone started months ago and left half-finished.
Moving from fragile page clicks to a proper data layer
The biggest difference between a flaky GTM setup and a dependable one is **what the triggers listen to**. If your container relies on watching button clicks, CSS classes or thank-you page URLs, it is vulnerable whenever the site changes. A click on "Submit" or "Pay Now" tells you someone pressed a button. The form may still have failed validation, or the payment may have been declined. We replace fragile click and URL triggers with structured **data layer events**. Instead of guessing from the page design, your website code explicitly tells Tag Manager when an order is confirmed, what the basket value and transaction ID were, or when a trade enquiry has genuinely been received. | Commercial situation | What goes wrong with a click or URL trigger | What it costs your reporting and ad spend | | -- | -- | -- | | A customer pays for an order | Tag fires when the Pay button is clicked, even if the card is declined | Failed payment attempts get counted as completed sales, inflating revenue and ROAS | | A trade or B2B buyer sends a quote request | Tag fires on a Submit click before the form passes validation | Marketing reports dozens of leads that never actually reached your sales tea
How duplicate tags distort your numbers
When two separate tags send the same purchase event without a shared deduplication setup, the same commercial action can be counted twice. Here is an illustrative example with invented round numbers (not a client result) showing how GA4 handles purchase events when two tags fire on the same store: | Tracking setup on the store | Real orders placed | Purchases reported in GA4 | Why | | -- | -- | -- | -- | | Single purchase tag active | 50 | 50 | One tag sends one event per completed order. | | Two tags active, sending the same `transaction_id` on a web stream | 50 | 50 | Google documents that GA4 deduplicates web purchase events that share the same transaction ID. | | Two tags active, sending different `transaction_id` values | 50 | 100 | With different transaction IDs on each event, GA4 counts them as separate purchases, doubling the purchases GA4 reports. | Whether a store is doing this is something we verify in Tag Assistant against real test journeys rather than assuming. Google also documents a clear threshold for container health: on the Versions screen inside Google Tag Manager, if the container **Size indicator is above 70%**, Google advises taking steps to optimise your
What our Google Tag Manager work covers
Depending on where your setup is today, we step in on four areas of work: ### 1. GTM container audits and clean-up We go through every tag, trigger and variable in your container to separate what is actively needed from what is obsolete. We check your website source code at the same time to catch hardcoded scripts that are duplicating GTM tags, remove redundant items, and publish a clean, documented version with a clear rollback point. ### 2. Data layer design for eCommerce, B2B and trade We design and test the `dataLayer` events your marketing and analytics platforms need. For eCommerce stores (including Shopify and Magento), that means accurate product views, basket actions, checkout steps and deduplicated purchase values. For B2B and trade sites, it means capturing genuine quote requests, account applications and phone leads rather than noisy page clicks. ### 3. Consent settings and third-party pixels Every extra script inside GTM adds weight to your site and creates another place for data to go wrong. We configure Google Consent Mode and per-tag consent checks inside GTM so your analytics and ad pixels respond properly when a visitor accepts, declines or changes their cookie
Frequently asked questions
### When do we need Google Tag Manager work versus a GA4 audit? Think of Google Tag Manager as the wiring on your website and GA4 as one of the places that data ends up. If the problem is only in how GA4 reports or groups your traffic, that sits in GA4. If your triggers aren't firing on the site, your data layer is missing order values, or your Google Ads, Meta and GA4 tags are all getting bad signals at the same time, the fix starts in Tag Manager. ### Why are our eCommerce sales being counted twice when we use GTM? In our experience, double counting happens when a platform integration (such as a native eCommerce analytics app or hardcoded `gtag.js` script in the theme header) fires alongside a Google Tag Manager purchase tag without a matching transaction ID, or when an order confirmation page fires again on refresh. We inspect both your website source code and your GTM container so each transaction has a clear, deduplicated route. ### What if removing an old tag in GTM affects a live ad campaign? That's the risk we plan around. Before pausing or removing anything, we trace which ad accounts and properties each tag feeds and test the affected journeys in Preview mode. Because G
Speaking to us about your container
Whether you have an inherited GTM container that needs untangling, a specific conversion trigger that has stopped working, or a website launch on the horizon, we can take a look. We start with a short access review of your container and website, show you what is currently firing, and give you a clear scope and quote for the work.