Digital Marketing
Google Tag Manager
Free software, a day’s work to set up properly, and the single most common place inherited tracking is quietly wrong.
Google Tag Manager is the container deciding which tracking scripts run, when, and for whom. The Nexclick builds it so every tag fires once, on the correct trigger, with consent checked first — and documents it, so the next person can change something without breaking measurement.
Is this you?
What usually prompts the call
- Your container holds tags nobody can explain, added by an agency you no longer use.
- Conversions started double-counting after a deployment and nobody knows which tag did it.
- Marketing scripts fire before the cookie banner has been answered.
- Every tracking change needs a developer and waits for the next release.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Audit the existing container
- Every tag, trigger and variable, and whether any of it still has an owner. Inherited containers routinely carry scripts for tools the client cancelled years ago.
- Remove what is dead
- Each deleted tag is a request the browser no longer makes. On a heavy container the effect shows up in Core Web Vitals as well as in clarity.
- Rebuild triggers so nothing fires twice
- Deduplication is the most common fix. A conversion tag on both a form-submit event and the thank-you pageview inflates every downstream number, including the ones budget decisions rest on.
- A data layer worth having
- Structured values pushed by the site rather than scraped out of the DOM with CSS selectors. Selector-based tracking breaks silently the next time somebody edits the page.
- Consent gating at container level
- No non-essential tag runs before a choice is made, and consent state is available to every tag as a variable rather than reimplemented inside each one.
- Environments and versions used properly
- Workspaces, preview and named versions with change notes, so a publish can be tested and reverted rather than made hopefully on a Friday afternoon.
- Naming, folders and documentation
- A convention applied consistently, plus a written note of what each tag is for and who asked for it. The point is that the next person inherits something legible.
- Access reviewed
- Who holds publish rights, and the removal of those who should not. Former agencies with live publish access are common and nobody discovers it until something changes.
Checklist
The container audit you can run without us
Open your own Tag Manager container and work down this list. Anything you cannot answer is a script running on your visitors that nobody in your business is accountable for.
- 01Can you state the purpose of every tag in the container?
- 02Is there a tag for a tool you no longer pay for?
- 03Does any conversion fire on both an event and a thank-you pageview?
- 04Do any triggers rely on CSS selectors that a redesign would break?
- 05Is anything scraping values from the page that the data layer should supply?
- 06Does every non-essential tag carry a consent condition?
- 07Do the container versions have change notes, or are they all named "publish"?
- 08Are tags in folders under a naming convention, or is it a flat list of sixty?
- 09Does anyone outside your business still hold publish rights?
- 10Is there a custom HTML tag containing code nobody has read?
- 11Are tags paused rather than deleted, with no note saying why?
- 12Does the container publish straight to live, or is preview genuinely used?
- 13Is the container in an account your business owns?
- 14If the person who built it left tomorrow, could someone else safely change it?
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1
Container audit
Export and review every tag, trigger and variable. Produces a list of what stays, what goes and what nobody can account for.
- 02Week 1–2
Data layer specification
What the site should push and with what values, written down — because it needs developer time, and developers need a specification rather than a conversation.
- 03Week 2
Rebuild and preview
New triggers, consent gating, naming and folders, tested in preview against real interactions before anything is published.
- 04Week 2–3
Publish and verify
Published as a named version, then verified against live submissions. The most common failure is a tag that works in preview and not in production.
What you get
Reporting and ownership
- A container with nothing firing twice and nothing nobody can account for.
- A written data layer specification your developers can implement against.
- Consent gating held at container level rather than repeated inside every tag.
- Named versions with change notes, so any publish can be reverted in seconds.
- Documentation of what each remaining tag does and who asked for it.
- The container in an account your business owns, not ours.
Tools and platforms
- Google Tag Manager
- Server-side containers where justified
- Google Tag Assistant
- Consent management platform
- Browser devtools and data layer inspection
Timeline
How long this actually takes
Two to three weeks, most of which is waiting on developer time for the data layer rather than work in the container itself. One honest note on scope: Tag Manager is free, and a competent person can configure a simple container in a day. If you run three scripts and have no plans for more, you do not need this service and arguably do not need Tag Manager — hardcoding three tags is simpler and one fewer system to maintain. The case for it begins when tags change often, when marketing needs to make changes without waiting for a deployment, or when consent has to be enforced consistently across a dozen scripts. An agency billing a monthly retainer purely to hold your container should be asked what changes in it each month.
Pricing model
Fixed-price project
Fixed price for the audit and rebuild. Ongoing container changes normally sit inside a wider retainer rather than being a line of their own — if someone charges monthly for container access alone, ask what changed.
Questions
Google Tag Manager questions
Do we actually need Tag Manager at all?
Not always. With three stable scripts and no plans to change them, hardcoding is simpler and one fewer system to maintain. Tag Manager earns its place when tags change often, when marketing needs to make changes without a deployment, or when consent must be enforced consistently across many scripts.
What is a data layer and do we need one?
It is a structured object the site pushes values into — order value, form type, logged-in state — which tags then read. The alternative is scraping the page with CSS selectors, which breaks silently whenever anyone edits the layout. If you track anything beyond pageviews, you need one.
Why would a tag fire twice?
Usually because two triggers both match: a form-submit listener and a thank-you pageview, or a tag inherited in the container alongside the same code hardcoded on the site. It is the most common problem we find, and it inflates every figure downstream of it.
Can Tag Manager slow the site down?
The container itself is small. What slows sites is what people put in it — chat widgets, heatmap tools, four remarketing pixels and a survey script nobody has removed. Tag Manager makes adding those easy, which is a genuine risk, and it also makes finding and deleting them easy.
Who inside our business should have publish access?
As few people as possible, and all of them nameable. Publish rights let someone inject arbitrary JavaScript into every page of your site, which is a security question as much as a tracking one. Editors can work in a workspace and have changes reviewed before they go live.
Is a custom HTML tag a security risk?
It can be. A custom HTML tag runs whatever code it contains on every page it triggers on, with full access to the page. Any container we inherit gets every custom HTML tag read before it stays. Where nobody can say what one is for, it goes.
What happens to the container if we stop working with you?
Nothing. It lives in your Google account, we hold access at your invitation, and that access is removed when you ask. The documentation is written on the assumption that somebody else will maintain it, because that is the normal outcome rather than an awkward one.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.