Google Tag Manager One box that holds the lot.

The product itself is free — Google charges nothing for it. What you are paying for is the build: the audit of what is already there, the plan for what counts as a customer, the container itself, consent, testing and documentation. A single site with a form and a phone number is a much smaller job than a store with a checkout and a booking system behind it. For clients we run advertising for it is part of the engagement rather than a separate invoice, and as a standalone project it is a fixed price quoted after a free audit.

A straightforward container — analytics, one ad platform, forms and phone taps — is usually live inside two weeks, including the week spent agreeing what to measure before anything is installed. Migrating scripts that are already hardcoded into a site, or wiring an online store's checkout, takes longer. Nothing is published half-finished. We would rather spend three days proving each path works than publish on the same afternoon and find out from your bank statement.

No long-term lock-in. A container build can be a one-off project: you keep the container, the documentation and the account, whether or not we ever work together again. Where it sits inside an ongoing marketing engagement we ask for enough runway to be fair to the work. The terms are put in front of you in plain English before anything is signed.

You do. The account is created in your name or, if it already exists, stays in it — we are added as a user, not as the owner. If we part ways you keep the container, every version of it, and the documentation that explains what is inside. Measurement is yours outright. Nothing about this build is held hostage, and there is no situation where leaving means starting your tracking again.

We keep going until they do. Someone on our team sits down with the first month of reported conversions and what actually happened in your business, and where the two disagree, that gap is the job. Most of the time it is a duplicate, a tag firing on the wrong page, or a form that submits in a way the container cannot see. Occasionally the honest answer is that part of your funnel genuinely cannot be observed from a website — some phone-only businesses are like this — and we will say so and change how the number is produced rather than defend a figure we do not believe.

A fixed cadence, good news or bad, written in the language you use about your own business. Each report covers what was spent, what it produced, what we changed and why, and what happens next. Alongside it you get the container's documentation: what is installed, what fires when, and what every number on the page actually counts. If a number moves because a tag changed, you find that out from us and not from a spreadsheet six weeks later.

It is a container that sits on your website and holds all your tracking codes in one place. Instead of a developer pasting each new advertising or analytics code into your site, one small piece of code goes on once and everything after that is managed inside the container. Three things live in it: the codes themselves, the moments they should fire, and the details that travel with each one. That is genuinely all it is. The difficulty is never the tool — it is deciding what deserves to be measured and keeping the container honest afterwards.

For the container itself, rarely. Adding a new platform, changing what counts as a conversion, or adjusting when something fires are all done inside the container without touching your site. Two things do still need a developer: getting the container onto the site in the first place, and building the small bridge that lets your website tell the container what just happened — which order, which service, which value. That bridge is worth doing properly once, because everything downstream reads from it.

Because a container installed without a plan is just a tidier way to hardcode scripts. If nobody decides in advance what a lead is called, what it is worth, and what detail travels with it, you end up with three names for the same enquiry and no way to compare one channel to another. Planning first costs about a week. Fixing it afterwards means rebuilding the container and re-teaching every ad platform, and you lose the history in between.

Four, in order of how much they cost. A conversion code left on every page instead of only the thank-you page, which inflates the reported conversions enormously. The same tag installed both in the container and hardcoded in the site, so everything is counted twice. No naming convention, so nobody can safely remove anything. And publishing without ever opening preview mode, which is the one that turns the other three into surprises. All four are found in the first hour of an audit.

Done properly it usually makes a site faster, because a well-built container replaces a pile of scripts that were each loading independently and blocking the page. Done badly it is one of the heaviest things on a site. The difference is what is in it and when things fire: unused tags removed, everything loaded after the page can paint, and nothing running that nobody can explain. Page weight is part of the audit for exactly this reason.

Yes, and it is the most common way this work starts. We audit what is there first — every entry, what it fires on, what duplicates what — and we do not switch off anything that is working while we fix what is not. Most of the time the container does not need replacing, it needs naming, documenting and pruning. Occasionally rebuilding is genuinely faster, and if that is the case we will show you the reasoning rather than assert it.