Nobody publishes measurement pricing, which is why every quote feels arbitrary and why "it depends" has become an acceptable answer.
It does depend. But it depends on specific, nameable things, and a consultant who can't tell you what those are before quoting is guessing. Here's what actually drives the number.
The market ranges
These are independent 2026 market figures — not my rates — quoted so you have something to sanity-check any proposal against, including mine.
| Work | Typical range |
|---|---|
| GA4 + GTM implementation (client-side) | Smaller than the below; scales with event count and platform integrations |
| Server-side tagging implementation | $8,000 – $18,500 |
| Ongoing managed support | from ~$150/month |
| Server hosting, 50k–100k monthly sessions | ~$50–100/month |
| Server hosting, 100k–500k monthly sessions | ~$150–400/month |
Two things worth noticing.
First, hosting is the small number. People fixate on it because it's recurring, but a $75/month server is not what makes measurement projects expensive.
Second, the implementation range is nearly 2.5x wide. That spread is the actual subject of this post.
What drives the number up
1. The number of platforms needing conversion endpoints
Each destination — GA4, Google Ads, Meta, LinkedIn, TikTok, a CRM webhook — is its own integration, with its own payload requirements, its own deduplication logic, and its own QA.
Going from two destinations to six is not 3x the config work. It's 3x the config work plus the combinatorics of making sure they all agree.
2. Whether an event model already exists
This is the single biggest swing factor.
If your site already fires structured events with consistent naming, the work is architecture and plumbing. If your tracking accreted over four years — a Tag Manager container with sixty tags, half of which nobody can explain, firing on CSS selectors that reference a design system you replaced in 2024 — then the first third of the project is archaeology.
Archaeology is billable, and it's rarely scoped honestly up front.
3. Whether the site emits a dataLayer at all
Tracking scraped from page structure (click a .btn-primary, fire a conversion) is cheap to build and breaks on every redesign. Tracking instrumented in the application source is more work up front and survives.
If the source-code route requires developer time you don't have, that constraint changes the project shape — and the cost.
4. Compliance scope
Consent Mode v2 done properly — signals propagated to the server, tags actually gated, modelling eligibility checked against Google's documented thresholds — is real work. Multi-region requirements multiply it.
5. Reconciliation depth
"It fires" is cheap. "It fires, and the number matches the CRM within a defined tolerance, and we can explain the remaining delta" is the expensive part.
It's also the only part that makes the data usable for budget decisions, which is presumably why you're doing this.
What drives it down
- A clean starting point. Fewer legacy tags, clearer existing naming.
- Fewer destinations. Be honest about which platforms you actually optimise against, versus which ones are there because someone added them in 2023.
- Developer availability. A dev team that can implement a dataLayer spec removes the most awkward constraint in the project.
- A narrower first phase. Fixing the three things that are actually wrong beats a full rebuild, and is frequently the correct diagnosis.
- Not doing it. See below.
The most expensive mistake
Paying for infrastructure to solve a configuration problem.
The most common finding in measurement work is not that a business needs a server-side container, a BigQuery pipeline, and a warehouse. It's that the existing client-side setup is misconfigured in two or three specific places — a conversion firing twice, a key event that never fires on mobile, a cross-domain link decorator that was never configured — and fixing those recovers most of the missing accuracy for a fraction of the cost.
Server-side tagging is genuinely valuable when you can measure the loss it recovers. It's an expensive answer to the wrong question when you can't.
This is why any competent engagement starts by quantifying the gap, and why that first phase should be priced so it stands on its own. If the diagnosis says you don't need the big project, that finding is the deliverable — and you should be able to take it elsewhere.
How to read a quote
Four checks:
- Are the cost drivers named? A quote that can't decompose into scope items is a guess with a confidence interval you can't see.
- Is there a diagnostic phase, priced separately? If discovery is bundled into a fixed implementation price, the implementation was decided before anyone looked.
- Is hosting modelled, or hand-waved? Your traffic volume determines it. Someone should have asked for that number.
- Is QA a line item? If reconciliation isn't scoped, it won't happen, and you'll find out in six months.
A quote that passes all four might still be too expensive for you. But it won't be arbitrary, and you'll be able to compare it against another one.
Full detail on the server-side side of this — architecture, hosting routes, and the five-phase framework whose first phase exists to talk you out of the project — is on the server-side tagging consultant page. How engagements run, and what I don't take on, is on How I Work.