Server-Side Tracking and GDPR: What It Changes, and What It Does Not

Server-side tracking is often sold to European marketing teams as three benefits at once: ad blockers stop blocking, data stops leaking to vendors, and the consent problem goes away. The first is largely true. The second is true only if you configure it that way. The third is a misunderstanding, and it is the one that tends to end up in a DPO's inbox.

This piece separates the technical change from the legal questions. It is not legal advice, and conclusions about a real deployment belong with your DPO and your national authority's guidance. The broader legal test for analytics is set out in our GDPR and ePrivacy assessment.

What server-side tracking actually is

In a client-side setup, tags in the browser send data straight to each vendor. In a server-side setup, the browser sends data to a server you run, usually on a subdomain of your own site, and that server decides what to forward to which vendor. Google's server-side tagging works this way: a server container processes incoming events and routes them to collection servers.

Two things do not change. There is still code running in the browser that collects and sends the data. And unless you strip it, the data that arrives at your server — IP address, user agent, cookies, URL parameters — is the same data that used to go to the vendor directly.

Three legal questions a server container does not answer

1. Is anything stored on or read from the device?

Article 5(3) of the ePrivacy Directive requires consent for storing information on a user's device, or accessing information already stored there, unless an exemption applies. The EDPB, citing the Court of Justice in Planet49, states that this protection applies to any information stored in the device, regardless of whether it is personal data. Where the data is processed afterwards is irrelevant to this step.

Server-side setups frequently keep a first-party cookie, often set by the server container itself so that it survives browser limits on script-set cookies. It is still stored on the device. And in its Guidelines 2/2023, adopted in their final version in October 2024, the EDPB goes further: JavaScript that instructs the browser to send asynchronous requests with the targeted information falls within Article 5(3), as do tracking pixels, tracking URLs and, in some cases, tracking based on the IP address alone. The same guidelines recall that applicability does not systematically mean consent must be collected: exemptions still have to be assessed.

2. Is personal data processed, and on what basis?

GDPR applies whenever personal data is processed, on your server or anyone else's. IP addresses, client IDs and user IDs arriving at a server container are processed by you as controller, and anything forwarded makes the vendor a recipient. A server-side architecture needs the same legal basis, records and contracts as the client-side one it replaced.

3. Does data leave the EU?

Hosting the container in the EU does not change what happens next. If it forwards personal data to a vendor that processes it outside the EU, that is a transfer, and it needs a transfer mechanism. Server-side only prevents the transfer if it forwards nothing personal, or forwards to no one outside the EU.

What server-side can genuinely change

Used deliberately, a server in the middle is a good place to minimise. The clearest public example is the CNIL's 2022 guidance on audience measurement and data transfers, which described a proxy for Google Analytics that could reduce transfer risks only with a set of measures:

• No transfer of the visitor's IP address to the analytics tool's servers.
• The user identifier replaced by the proxy server.
• Deletion of any parameter contained in collected URLs.
• Removal of the external referrer, and reprocessing of user agents.
• No cross-site collection, and removal of any data that could lead to re-identification.
• Hosting in conditions that avoid transfers to countries without essentially equivalent protection.

The CNIL added that changing the tool's IP settings alone is not enough. Beyond minimisation, server-side can also move processing to an EU location you choose, reduce the number of third-party scripts running on your pages, and make requests far less likely to be blocked when the endpoint is your own subdomain.

The attribution cost of doing it properly

Read the CNIL's list again as a marketer. Deleting URL parameters removes the UTMs and click IDs every campaign report is built on. Removing the external referrer removes the signal that separates search from social from referral. Replacing the identifier cuts the history that user-level attribution models need. A proxy configured to those conditions keeps an analytics tool running and leaves it with little to say about which channels produced the revenue.

That is the real trade-off behind “server-side for compliance”: the more personal and identifying data you strip, the less of the attribution you bought the tool for survives. It is the same tension, from another angle, as the one described in Consent Mode: what GA4 measures and what it models.

Five claims to check before you sign off a server-side project

A review checklist for the DPO

1. Device: list every cookie, storage key and script-initiated request, including those set or triggered by the server.
2. Inbound data: list the fields that reach the server — IP, user agent, identifiers, full URLs, referrer.
3. Outbound data: for each vendor, the fields forwarded after processing, and whether any of them identifies a person.
4. Location: where the container runs and where each recipient processes the data.
5. Retention: how long raw events and logs are kept on the server.
6. Consent gating: which forwarding rules depend on the visitor's consent state, and how that state reaches the server.

Where Sealmetrics fits, and where it does not

Sealmetrics is not a server container for other vendors. A small script in the browser sends each hit to Sealmetrics, optionally through a subdomain of your own, and processing happens on servers in Dublin; on Shopify, purchases arrive server-side through the store's webhook. It sets no cookies and uses no local or session storage. It does not persist IP addresses — they are used in memory only — or user identifiers; a session marker lives in memory for about two hours; the country comes from the browser's timezone; and event-level rows are purged after a day. The details are in demonstrate compliance.

Because it forwards nothing to advertising vendors, it keeps the landing page's UTMs and referrer, which is what campaign attribution needs. It does not escape the analysis above, though. Under the EDPB's reading, a script that sends information from the browser can fall within Article 5(3), so the question for any analytics tool — ours included — is whether an exemption applies to that configuration in your market. Several authorities, the CNIL among them, publish criteria for audience measurement that can be used without consent; whether a deployment meets them is for you and your DPO to assess. The concept is explained in consentless analytics.