Is server-side tracking GDPR compliant?

You’ve probably heard various opinions on server-side tracking: your agency says moving to server-side tracking solves the consent problem. A tagging vendor’s page implies the same. We work in compliance, and we’re here to bring some clarification.

Is server-side tracking GDPR compliant?

Server-side tracking is GDPR compliant only when the setup around it meets the regulation‘s requirements, not because of the architecture itself. Moving tracking to a server changes where data gets processed. It doesn’t change whether you need a legal basis to process it, or whether you need consent to read a visitor’s device in the first place. You’re still collecting and using user data. Just somewhere else.

Client-side or server-side is an architecture decision. Consent and legal basis are obligations that attach to what you do to a visitor’s device (like installing cookies), and to the personal data you handle afterwards. So there’s no blanket answer for server-side tracking as such.

What server-side tracking changes, and what it doesn’t

Server-side tracking sends events from the browser to a tracking server first, which processes them and forwards what’s needed to destinations like Google Analytics 4 or the Meta Conversions API, instead of the browser calling each vendor directly.

Server-side tracking: what it changes	What stays the same as client-side tracking
Where data is processed: on a tracking server you configure, not in each visitor’s browser	The need for a legal basis under Article 6 of the GDPR
Who decides what leaves your site: your container rules, not each vendor’s script	The need for consent before anything reads or writes on a device
Cookie lifespan and first-party durability, thanks to the first-party subdomain	What the ePrivacy Directive requires of that first read or write, third-party cookies or not
How many third parties reach the browser, and which fields you strip before they do	Your transparency duties: every recipient belongs in your policies

How does server-side tracking work?

Four steps:

• A visitor’s browser sends an event to a first-party subdomain such as analytics.yourdomain.com.
• The tracking server receives it.
• The server applies your rules for filtering and enrichment.
• The server forwards what’s left to the destinations you’ve connected.

Why moving server-side doesn’t remove the need for consent

The obligation attaches to the device, not the destination

The reason the “server-side avoids consent” claim fails has little to do with the GDPR. It sits in the EU ePrivacy Directive, the law behind cookie banners.

Article 5(3) requires that storing information, or gaining access to information already stored, in a user’s terminal equipment can happen only with that user’s consent, after clear and comprehensive information about the purposes. Two narrow exemptions apply: carrying out the transmission of a communication, and what’s strictly necessary for a provider to deliver an online service explicitly requested by the user.

Notice what the provision never mentions: where the information travels afterwards. The obligation attaches to the moment something reads from or writes to the device.

What the GDPR requires for the data you forward

Two obligations run in parallel. The ePrivacy Directive governs the device access, and the GDPR governs what happens to the personal data afterwards.

• Article 6(1) requires a legal basis for processing personal data. Where that basis is consent, it has to be the visitor’s consent to processing for one or more specified purposes. Legitimate interests under Article 6(1)(f) exist as an alternative, but when it comes to forwarding data to advertising platforms, it rarely carries the weight teams hope, because the ePrivacy consent requirement sits upstream of it.

• Article 7(1) requires the controller to be able to demonstrate that the visitor consented, so you need a record you can actually produce, not an assumption that a banner did its job.
• Article 7(3) requires that withdrawing consent be as easy as giving it, so a withdrawal has to reach the container and stop the forwarding.

Where marketing measurement sits under the GDPR and the ePrivacy Directive

Measurement is the one area with any exemption at all. Some regulators treat pure audience measurement differently from marketing analytics. France’s CNIL, for example, exempts audience measurement trackers that serve only that purpose, work for the publisher’s exclusive account, produce anonymous statistics, and respect limits on tracker lifetime and retention. It’s narrow, and it varies between member states.

Everything else marketers run sits outside it: retargeting, conversion tracking, lookalike audiences, cross-device attribution. For those, the device access needs consent, and the processing needs a basis, whether the request leaves from a browser or from a server.

How the consent signal reaches the tracking server

Knowing consent is required is the easy part. In a server-side setup, that signal has further to travel than it did client-side.

The chain is short. Your consent management platform (CMP) captures the visitor’s choice in the browser, the choice travels with each event to the tracking server, and the container decides per destination whether to forward, strip, or drop.

That means you need to make sure your consent setup is strong. A container receiving no consent signal doesn’t become exempt. It keeps forwarding, dashboards keep filling. The first visit is the hardest case, since a visitor’s choice isn’t known yet on their first interaction. Start from a CMP that reliably collects and stores consent, then confirm the server end receives it and acts on it.

Does using server-side tracking have any impact on compliance?

Server-side tracking does affect your compliance posture, and handled well, the effect is a positive one. None of the above makes it a worse choice for privacy. In fact, it can be considered a more privacy-aware tracking method:

• You enforce your rules at the infrastructure level, at one point you own, instead of depending on each vendor’s script to honor them.
• You choose where the tracking server runs, so an EU-hosted setup keeps the first processing step in the EU. Transfers to destinations outside the EEA still need to follow the related GDPR’s Chapter V basis.
• You control which fields leave your site, so you can drop identifiers, or hash them where you can’t. Hashing narrows exposure, but a hashed email or phone number is still personal data, so the same obligations follow it.
• Fewer vendors reach the browser directly, so fewer independent parties read each visitor’s device, and fewer scripts sit in a position to collect information they were never authorized to collect.
• Every flow through the server can be logged, so you can show what was forwarded and why. That’s evidence of enforcement: it sits alongside your consent records under Article 7(1) but doesn’t replace them.

What a compliant server-side setup looks like

Knowing how to set up server-side tracking is one thing. Here’s how to do that so the compliance side holds.

1. Identify the legal basis for each destination, separately. One container can feed six recipients, and they might not all rest on the same basis.
2. Collect consent before any device access, not just before forwarding. The trigger is the browser reading or writing, before your server hears anything.
3. Propagate consent state into the container with every event. A container that can’t see the choice can’t act on it.
4. Drop identifiers before forwarding where you can, like email addresses and phone numbers, and hash them where you can’t. Hashing is minimization, not anonymization: hashed identifiers stay personal data and stay in scope. Treat data minimization as the default.
5. Choose hosting with transfer exposure in mind. EU hosting reduces exposure at the container, but each destination outside the EEA still needs its own transfer basis.
6. Document every destination in your privacy and cookie policy. A recipient that isn’t in the policy is an undisclosed one.
7. Verify what leaves the container, and re-verify after every tag change. Inspect the outbound payload rather than trusting the configuration to describe itself.

Where this leaves you

The final question you need to answer is whether your particular setup does what’s required by the regulations that apply to you, such as: gather consent, have a legal basis, and disclose your activities in your policies.

The strongest setups stop treating measurement and consent as two separate systems. That’s the thinking behind our server-side tracking solution: the tracking pipeline and the consent layer as one system rather than two that you figure out how to wire together yourself.

Events are checked against the visitor’s choice before they move, and the default configuration blocks anything without valid consent.

FAQ