Your agency says moving to server-side tracking will "recover" the data your cookie banner is losing. Half of that is true. Server-side can recover requests that ad blockers and browsers drop for visitors who said yes. It can't recover the visitors who said no, and trying to is how a tracking project turns into a legal one.
This is general information about EU guidance, not legal advice. Rules differ by country. Get a privacy lawyer to look at your setup before you rely on it.
Does server-side tracking need cookie consent?
Usually, yes. Server-side tracking changes where data is forwarded, not where it is collected. The browser still runs the code that collects events, and EU consent rules look at what happens on the visitor's device. Visitors who decline still can't be tracked individually. Tools like Trakt respect Google Consent Mode v2, OneTrust and Cookiebot and send nothing without consent.
Consent is usually needed anywhere a client-side setup would need it. In the EU, the rule in Article 5(3) of the ePrivacy Directive is about storing or reading information on the visitor's device, and the browser still does that:
- The browser still runs code that collects the event and the consent choice.
- EU regulators apply the consent rule to pixels, tracking links and locally produced data, not only cookies.
- Even Google's server-side stack treats the browser's consent choice as the control point.
- What you can still measure for a visitor who declines is limited and aggregate.
The visitor's consent choice decides whether the browser collects data; your server then forwards what was collected to ad platforms and analytics.
Two kinds of "lost" data, and which one server-side fixes
If your banner works the way regulators expect, some visitors decline, and for them your analytics and ad tags shouldn't set or read tracking cookies. Your reports show fewer conversions than happened. That's the banner doing its job.
Separately, some requests never arrive even from people who consented, because ad blockers and browser privacy features block requests to third-party domains. That's the problem server-side tracking is actually good at.
| Problem | What causes it | Does server-side fix it? |
|---|---|---|
| Visitor declined consent | A legal choice the visitor made | No. You still have to respect it. |
| Visitor consented, but the request never arrived | Ad blockers, browser restrictions, network failures | Partly. A first-party endpoint loses fewer requests. |
Most vendor pages blur these together. Keep them apart and the rest is simple.
What server-side tracking actually changes
In a client-side setup, the browser loads each vendor's tag (Google Analytics, the Meta Pixel) and each one sends data straight to its vendor. In a server-side setup, the browser sends events to a server you control, often on your own subdomain, and that server decides what to forward.
What it buys you:
- Reliability. Requests go to your own domain, so fewer get lost.
- Control. You can strip fields such as IP addresses or query strings before anything leaves your server.
What it doesn't:
- Data you never collected. A server only sees what reaches it. Clicks, scrolls and on-page journeys still start in the browser, under the same consent rules.
- A legal workaround. See the next section.
What EU regulators say about consent and server-side setups
EDPB: the technique doesn't matter, the device does
The European Data Protection Board adopted version 2.0 of its Guidelines 2/2023 on the technical scope of Art. 5(3) of the ePrivacy Directive on 7 October 2024, to address "emerging tracking tools" beyond cookies. The use cases it analyses include URL and pixel tracking, local processing and IP-only tracking:
- Tracking pixels and links. The guidelines say collecting the identifiers these mechanisms send back counts as "gaining access" under Article 5(3).
- Local processing. Information produced on the device and then sent back over the network still counts. "The fact that this information is being produced locally does not preclude the application of Article 5(3)."
- IP-only tracking. Article 5(3) can apply when the IP address originates from the user's device, and "unless the entity can ensure that the IP address does not originate from the terminal equipment," it has to take all the steps the article requires.
The guidelines also say Article 5(3) applying "does not systematically mean that consent needs to be collected." An exemption may cover your case. In practice, the exemptions are narrow.
The takeaway: the script in the browser that sends events to your server is still accessing the visitor's device. Moving the next hop to your server doesn't change the first one.
CNIL: consent-exempt analytics excludes marketing measurement
France's CNIL publishes a self-assessment tool for consent-exempt audience measurement (July 2025, in French). It lists what has to be excluded for the exemption to apply, explicitly including any marketing-oriented measurement: conversion channel performance, ad campaign performance and acquisition channel measurement.
So in France, the exempt kind of analytics doesn't cover "which ad brought this customer." That's exactly the question attribution answers. Other countries may draw the line differently, so check with the regulator wherever you have visitors.
What Google Consent Mode does in a server-side setup
Google's guide to consent mode with server-side Tag Manager shows how a real server-side stack handles a "no":
- Consent mode isn't a banner. It passes the choice from your consent platform to Google's tags. You still need the banner.
- Consent is collected in the browser. The Google tag adds consent parameters to the requests it sends your server container, and Google's tags in the server adjust what they send. Google says you only need to set up consent mode in the web container.
- Basic implementation: Google tags don't load at all until the visitor consents.
- Advanced implementation: tags load regardless. When Analytics consent is denied, no Analytics cookies are set or read on the client or the server, and Google receives what it calls anonymous, non-identifiable events. When
ad_storageis denied, Google Ads conversion tags send a pixel without cookies instead.
Two conclusions. Google's own server-side stack treats the browser's consent choice as the control point. And cookieless pings aren't full data: they don't let you follow a declined visitor from ad click to closed deal. Whether sending even those is fine without consent in your country is a legal question.
What you can still measure when visitors decline
You aren't left with nothing. You're left with what visitors choose to give you, plus aggregates:
- What people tell you in a form. A lead who fills in your form gave you their details on purpose, and a "How did you hear about us?" field doesn't depend on cookies. More in self-reported attribution.
- Campaign labels on links you publish. UTMs ride in the URL. Whether you can store them against an individual without consent is part of the same legal analysis, so treat them as data for consenting visitors and in aggregate. Build them consistently with the UTM builder.
- Anonymous, first-party aggregate counts, within whatever exemption your regulator recognises.
- Better coverage of the visitors who did consent. This is where server-side earns its keep.
What you can't get back is the individual journey of someone who said no. Plan reporting around that gap instead of engineering around it.
A checklist before you go server-side
- Map every tag to a purpose: analytics, ad conversion, remarketing. Each has different consent rules.
- Confirm your banner blocks tags before consent, and that refusing is as easy as accepting.
- Make sure the consent signal reaches the server. A server container that fires tags without checking consent rebuilds the client-side problem somewhere harder to audit.
- Strip what you don't need (IP address, full query strings) before forwarding.
- Write down which exemption you rely on, if any, and for which country.
- Check the lead side. Server-side or not, leads arrive as Direct when the form doesn't keep the source. The marketing attribution audit walks through the checks, and why leads show as Direct covers the usual causes. To test the server half, use the server-side tracking audit.
If the lead side is what's broken, start free with Trakt.
Why consent gaps hit attribution hardest (and how Trakt fits)
Consent gaps land on the exact number founders care about: which source produced revenue. Server-side tracking can't fix that for people who declined, and it doesn't touch your lead records at all.
Where Trakt sits
Trakt isn't a server-side tracking tool and won't help you measure visitors who said no. Its tracking snippet respects Google Consent Mode v2, OneTrust and Cookiebot, and sends nothing without consent.
For visitors who consent, Trakt remembers the UTMs in a first-party cookie, so a form submission days later in the same browser still carries them (90 days). It records each form submission with its source attached, even when the form has no hidden fields, and credits won deal value to that source in Trakt's leads pipeline.
Server-side setup vs. Trakt, by requirement
| Requirement | Server-side setup | Trakt |
|---|---|---|
| Fewer requests lost to blockers | Yes, via your own endpoint | Not its job |
| Measuring visitors who declined | No | No |
| Source kept on each lead | Not covered | Recorded with each form submission |
| Revenue by source | Not covered | Won deal value credited to the captured source |
| Consent | Your banner decides | Same either way: your banner decides |
What to do first
Before you buy server infrastructure, answer two questions: what share of your visitors decline, and do leads from visitors who accept actually carry their source?
- Read your banner's own reports for the accept and decline split. That number is the ceiling on what any tracking setup can see.
- Send a test lead through a tagged link after accepting cookies, and check the source is on the record. If it isn't, server-side won't help. Fix the form first.
- Decline cookies and repeat. Confirm your tags stay quiet.
- Only then price a tagging server, against the requests you're actually losing from consenting visitors. The server-side tracking audit shows how to check one once it's live.
- Get legal review for each country you sell into before you rely on any exemption.
FAQ
Is server-side tracking GDPR compliant?
Server-side tracking is a technique, so it isn't compliant or non-compliant on its own. What matters is what you collect and on what basis. In the EU, the ePrivacy consent rule still applies to storing or reading information on the visitor's device, and the EDPB's Guidelines 2/2023 apply it to pixels, tracking links, locally produced data and, in many cases, IP-based tracking.
Does server side tracking need consent?
Usually yes, wherever client-side tracking would need it. The browser still runs the code that collects the event, which is what the consent rule looks at. A narrow exemption may cover anonymous audience measurement, but in France the CNIL says that exemption excludes campaign and acquisition channel measurement.
Will server-side tracking recover data lost to ad blockers?
Partly. Requests sent to your own first-party endpoint are less likely to be blocked than requests to a vendor's domain, so you lose fewer events from visitors who consented. It doesn't recover visitors who declined, and it doesn't fix leads that arrive without a source because the form dropped it.
Does Google Consent Mode make tracking legal without consent?
No. Google's documentation says consent mode doesn't provide a banner; it passes the visitor's choice to Google's tags. In the advanced implementation, tags send cookieless pings when consent is denied. Whether those pings are acceptable without consent depends on your jurisdiction, so ask a lawyer.
Does Trakt track visitors who decline cookies?
No. Trakt's snippet respects Google Consent Mode v2, OneTrust and Cookiebot and sends nothing without consent. Trakt also doesn't do server-side tracking. It keeps the source on leads from visitors who consent, and credits won deals to that source.
