Does server-side tracking let us track users who refused consent?

No, and anyone telling you otherwise is selling you a liability. Consent obligations attach to the processing of personal data, not to which machine sends the request. Moving collection to your server changes the transport and nothing about the legal position. Server-side does make honouring consent easier to implement correctly, because one place decides what gets forwarded — but that is the opposite of a workaround.

Does Consent Mode v2 let us keep tracking people who said no?

No. In advanced mode, tags still fire for a refusing visitor but send cookieless pings — no identifier, no cookie — and Google uses those to model conversions statistically rather than to attribute them to a person. That modelling is an estimate, not the individual, and reading it as though it were the user is where reporting quietly goes wrong. Consent Mode changes what a tag transmits; it never changes whether you were permitted to identify someone.

Does it get around ad blockers?

Partly, and it is worth being clear-eyed about why. Requests to your own domain are not blocked the way requests to known third-party analytics domains are, so more events arrive. We treat that as recovering measurement you were always entitled to under consent — not as a reason to collect from people who declined. If the goal is to track users who have actively opted out, that is not work we will take.

How much more accurate is the data, really?

Enough to change decisions in some businesses and not enough to notice in others, which is why we would rather look at your numbers before quoting. The gain comes from recovered sessions, longer-lived first-party cookies and server-only events like refunds. If your sales cycle is longer than the browser cookie survives, the attribution improvement is usually the part that matters most.

What does it cost to run each month?

It depends almost entirely on traffic, because you are paying for a server that scales with event volume. At modest traffic it is a small hosting line; at high traffic it is a real one. Add monitoring and occasional maintenance as vendor APIs change. We will give you a written estimate covering both the build and the expected running cost, so the second one is not a surprise.

Can you build and run it for us?

We build it, wire it into your existing analytics and CRM, and hand it over with monitoring in place — that sits inside our lead generation engineering work. We do not resell hosting and we do not manage paid advertising, so we have no incentive to talk you into a bigger setup than your traffic justifies.

Server-Side Tracking, Explained Honestly

Instead of the browser sending data straight to a dozen vendors, it sends one request to a server you control, which forwards what you choose. That fixes several real measurement problems and creates a few new obligations — and it is sold far more often than it is genuinely needed.

Last updated: August 14, 2026

Start your project Get a free estimate

What actually changes

In client-side tracking the browser talks directly to every analytics and advertising vendor you use. In server-side tracking the browser talks to one endpoint on your own domain, and your server decides what gets forwarded where. The data path is the only thing that changes — the collection itself is the same act, with the same legal weight.

One request from the browser instead of a dozen third-party scripts, so the page carries less weight
Your server decides what each vendor receives, so you can forward an order value to one and nothing to another
Cookies set by your own server are first-party, which changes how long they survive
You can enrich events with data the browser never had — order margin, refund status, lead quality from your CRM
You can also fix or drop bad data before it reaches a vendor, instead of after it has polluted a report

The problems it genuinely solves

There are real measurement failures behind the hype, and they are worth naming precisely rather than gesturing at 'better data'.

Short cookie lifetimes: browser-set cookies from third-party scripts are capped aggressively, so a returning visitor looks like a new one and the attribution window is shorter than your sales cycle
Script blocking: a meaningful share of visitors block third-party analytics entirely, and those sessions are simply missing from your reports
Page weight: every vendor tag is another script the browser must fetch and run, which is a Core Web Vitals cost you pay on every page view
Data you only have server-side: refunds, cancellations, offline conversions and lead quality never existed in the browser to begin with
Vendor sprawl: when every tag talks directly to its vendor, nobody can answer what data left the site or where it went

What it does not solve

This is the part most vendor pages leave out, and it is the part that gets companies into trouble. Moving the data path server-side changes where collection happens, not whether you are allowed to collect.

It is not a consent workaround. If a visitor refuses tracking, you still may not track them — the obligation follows the data, not the transport
It does not make personal data anonymous. Forwarding an email or an IP from your server is still processing personal data
It is not a way to hide data collection from users. If your privacy policy would have to change and you would rather it did not, that is a signal to stop
It does not fix bad measurement design. Events that were wrong client-side arrive wrong server-side, just more reliably
It does not remove your responsibility for what vendors do with what you forward

Consent Mode v2, and what it actually signals

Consent Mode is the mechanism Google tags use to be told what a visitor agreed to. Version 2 added two parameters — ad_user_data and ad_personalization — alongside the original ad_storage and analytics_storage, and since March 2024 Google has required it for EEA traffic where advertisers use audience and remarketing features. It is worth understanding precisely, because it is the piece people most often mistake for permission.

Four signals, not one: storage for analytics, storage for ads, whether ad data may be sent, and whether it may be personalised — a visitor can allow some and refuse others
In basic mode the tags do not load at all until consent is given, so nothing is sent from a refusing visitor
In advanced mode tags load and send cookieless pings when consent is denied — no identifiers, no cookie, and Google uses them to model rather than to attribute
Modelled conversions are an estimate Google produces from those pings; they are not the individual user, and treating them as such is where reporting goes wrong
Denied still means denied. Consent Mode changes what a tag transmits, never whether you were allowed to identify someone

What it costs to run

The honest objection to server-side tracking is not technical, it is operational. You are taking on a piece of always-on infrastructure that sits between your website and your revenue reporting, and it needs an owner.

A server or container that must stay up — when it is down you are not collecting, and nothing on the page will tell you
Hosting cost that scales with traffic, modest at low volume and not modest at high volume
Monitoring, because a silent failure looks exactly like a quiet week in the reports
Maintenance as vendor APIs change, which they do
A named owner. The most common failure we see is a server container configured once by someone who has since left

When it is not worth it

We would rather talk you out of this than build you something that quietly rots. Server-side tracking earns its keep when measurement error is costing you real decisions — and at low volume it usually is not.

Low traffic: if a few hundred sessions a month decide nothing, better data changes nothing either
No decision hanging on it: if nobody would spend differently based on the numbers, the numbers are not the bottleneck
No owner: infrastructure without a maintainer is a future outage with your revenue reporting attached
Your real problem is elsewhere: leads arriving untracked, or nobody following up, are cheaper and more valuable to fix first
You want it to avoid consent. That is the one reason we will decline the work

FAQ

Frequently Asked Questions

Does server-side tracking let us track users who refused consent?
No, and anyone telling you otherwise is selling you a liability. Consent obligations attach to the processing of personal data, not to which machine sends the request. Moving collection to your server changes the transport and nothing about the legal position. Server-side does make honouring consent easier to implement correctly, because one place decides what gets forwarded — but that is the opposite of a workaround.
Does Consent Mode v2 let us keep tracking people who said no?
No. In advanced mode, tags still fire for a refusing visitor but send cookieless pings — no identifier, no cookie — and Google uses those to model conversions statistically rather than to attribute them to a person. That modelling is an estimate, not the individual, and reading it as though it were the user is where reporting quietly goes wrong. Consent Mode changes what a tag transmits; it never changes whether you were permitted to identify someone.
Does it get around ad blockers?
Partly, and it is worth being clear-eyed about why. Requests to your own domain are not blocked the way requests to known third-party analytics domains are, so more events arrive. We treat that as recovering measurement you were always entitled to under consent — not as a reason to collect from people who declined. If the goal is to track users who have actively opted out, that is not work we will take.
How much more accurate is the data, really?
Enough to change decisions in some businesses and not enough to notice in others, which is why we would rather look at your numbers before quoting. The gain comes from recovered sessions, longer-lived first-party cookies and server-only events like refunds. If your sales cycle is longer than the browser cookie survives, the attribution improvement is usually the part that matters most.
What does it cost to run each month?
It depends almost entirely on traffic, because you are paying for a server that scales with event volume. At modest traffic it is a small hosting line; at high traffic it is a real one. Add monitoring and occasional maintenance as vendor APIs change. We will give you a written estimate covering both the build and the expected running cost, so the second one is not a surprise.
Can you build and run it for us?
We build it, wire it into your existing analytics and CRM, and hand it over with monitoring in place — that sits inside our lead generation engineering work. We do not resell hosting and we do not manage paid advertising, so we have no incentive to talk you into a bigger setup than your traffic justifies.