Server-Side Tagging and Cookie Compliance: What You Need to Know

"We moved to server-side tagging, so we don't need to worry about cookie consent anymore." This is one of the most dangerous misconceptions in web analytics today. Server-side tagging changes where data processing happens, but it does not change whether consent is required.

If your organization is evaluating or has already implemented server-side tagging, this guide covers what it actually means for cookie compliance, where the risks hide, and what to watch for in compliance scans.

What is Server-Side Tagging?

In a traditional client-side setup, tracking tags (Google Analytics, Meta Pixel, LinkedIn Insight, etc.) run directly in the visitor's browser. Each tag loads its own JavaScript, sets its own cookies, and sends data directly to the vendor's servers.

Server-side tagging adds an intermediary. Instead of tags running in the browser, the browser sends data to a server you control (or a cloud container you manage), and that server forwards the data to the relevant vendors.

The flow looks like this:

Client-side (traditional):

Browser → Google Analytics servers
Browser → Meta servers
Browser → LinkedIn servers

Server-side:

Browser → Your server container → Google Analytics servers
                                → Meta servers
                                → LinkedIn servers

The browser communicates with one endpoint (your server), and your server handles the fan-out to multiple vendors behind the scenes.

How Server-Side GTM Works

Google Tag Manager (GTM) Server-Side is the most common implementation. Here's how it operates:

The Container

You deploy a GTM server container, typically on Google Cloud Platform, AWS, or another cloud provider. This container runs on a subdomain of your website (e.g., data.example.com), making all requests appear as first-party traffic.

The Client

A "client" in the server container receives incoming requests from the browser. The default web container sends a standard GA4 measurement protocol request. The server-side client parses this request into an event data object.

What the Browser Sees

From the browser's perspective, it makes a single request to data.example.com. It doesn't see the downstream requests to Google, Meta, or anyone else. DevTools shows a clean first-party request, not a web of third-party calls.

This is where compliance confusion begins.

No. Here's why.

The Legal Basis Hasn't Changed

The ePrivacy Directive (and GDPR) requires consent for storing or accessing information on a user's device, unless it's strictly necessary. Server-side tagging doesn't eliminate the cookie or the data collection. It just moves the processing to a different location.

When a server-side setup:

Sets a first-party cookie to identify the user (it does)
Collects the user's IP address, user agent, and page URL (it does)
Forwards that data to third-party analytics or advertising vendors (it does)

...all of these activities still require consent under EU privacy law. The intermediary server doesn't create a new legal basis.

Regulatory Guidance is Clear

Multiple Data Protection Authorities have addressed this directly:

The French CNIL has stated that the use of a proxy server to relay analytics data does not exempt the processing from consent requirements
The Austrian DSB's Google Analytics decision (2022) focused on the data transferred, not the mechanism of transfer
The EDPB's guidelines on consent make no distinction between client-side and server-side data collection

The question regulators ask is: "Is personal data being collected and processed?" If yes, the legal basis requirements apply regardless of the technical architecture.

The "First-Party" Misconception

Server-side setups route traffic through your domain, making cookies appear first-party. Some organizations argue this means the cookies are "strictly necessary" since they're set by the first party.

This argument fails because the cookie's purpose determines its category, not its origin. A first-party cookie used for analytics tracking is still an analytics cookie. A first-party cookie that feeds data to Meta's advertising network is still a marketing cookie. Relabeling the domain doesn't change the purpose.

For more on how Consent Management Platforms (CMPs) should work alongside independent verification, see our guide on why you need both a CMP and a scanner.

Server-side tagging creates a specific compliance challenge: the cookies it sets are genuinely first-party, which makes them harder to detect and categorize.

Detection Difficulty

Client-side tracking cookies from Google Analytics (_ga, _gid) are well-documented and easy to identify. But server-side setups can set custom first-party cookies with arbitrary names. A cookie named _session_id set by data.example.com might actually be a tracking identifier forwarded to Google Analytics.

Standard cookie databases won't recognize these custom cookies. They'll be classified as "unknown" unless the scanner understands what the server-side container is doing.

Browsers have been shortening the lifespan of cookies set via JavaScript. Safari's Intelligent Tracking Prevention (ITP) caps JavaScript-set cookies at 7 days. But cookies set via HTTP response headers from a first-party server (which is what server-side tagging does) can have much longer lifespans, often 1-2 years.

This is a feature that server-side tagging vendors actively promote. It's also a compliance consideration: longer-lived tracking cookies mean more persistent identification of users, which increases the privacy impact and strengthens the case for requiring consent.

Data Minimization Questions

With client-side tagging, you can inspect exactly what data each script collects because it happens in the browser. With server-side tagging, the data collection still happens in the browser (via the measurement protocol request), but the enrichment and forwarding happen server-side, out of the user's view.

This opacity raises questions about data minimization. Are you forwarding the full IP address to vendors? Are you enriching the data with server-side information before sending it? Users have a right to know, and your privacy policy must accurately describe this processing.

Schrems II and Data Transfer Risks

Server-side tagging doesn't eliminate cross-border data transfer risks. In many cases, it makes them more complex.

The Transfer Still Happens

Even with a server-side container, data still ends up on Google's servers in the United States (or Meta's, or any other US-based vendor). The server container is a waypoint, not a destination. The Schrems II concerns about EU-US data transfers apply with full force.

Proxy Server Location Matters

Where your server container runs has compliance implications:

EU-hosted container: Data passes through an EU server before reaching the US. Some DPAs have suggested this could support a "data in transit" argument, but it hasn't been accepted as a safe harbor.
US-hosted container: Data goes directly to a US server, providing no intermediary protection. This is functionally identical to client-side tracking from a transfer perspective.

IP Anonymization Isn't a Silver Bullet

Some organizations configure their server container to strip or truncate IP addresses before forwarding data to vendors. This helps, but:

The full IP address is still received by your server first (which is itself a processing operation)
Other identifiers (client ID, user agent, screen resolution) can still enable identification
The CNIL has stated that IP anonymization alone doesn't eliminate the need for consent for analytics processing

For more on how Google Consent Mode v2 interacts with these requirements, see our technical guide.

How Server-Side Setups Appear in Compliance Scans

Understanding what a compliance scanner sees (and doesn't see) with server-side tagging is essential for accurate assessment.

What Scanners Detect

A pre-consent compliance scan visits your website in a fresh browser and records everything that happens before consent. With server-side tagging, the scanner will typically see:

First-party cookies set by your server container subdomain
A single network request to your container domain (e.g., data.example.com/g/collect)
No visible third-party scripts loading from Google, Meta, or other vendor domains
CMP behavior (whether the consent banner loads and blocks tracking)

What Scanners May Miss

Because server-side processing happens behind the scenes:

Downstream data transfers: The scanner can't see that your server forwards data to Google after receiving it
Server-set cookie purposes: A cookie named _cid from your domain doesn't self-identify as an analytics cookie
Data enrichment: Any additional data added server-side before forwarding isn't visible to the browser

How to Get Accurate Results

For the most accurate compliance picture with server-side tagging:

Classify your server-side cookies correctly in your CMP. Don't mark analytics cookies as "necessary" just because they're first-party.
Block the measurement protocol request before consent. If your server-side container receives data before consent, the downstream processing is non-compliant regardless.
Document your server-side data flows in your cookie policy. Be transparent about what data goes where.
Run regular scans to verify that pre-consent behavior matches your intended configuration. Server-side setups are complex and misconfiguration is common.

The fundamental compliance question remains the same regardless of architecture: Does any non-essential data collection happen before the user gives consent?

With server-side tagging, check:

Does the browser send a measurement protocol request before consent? If yes, data is being collected pre-consent.
Are first-party cookies set before consent? If yes, check their purpose. If they're tracking identifiers, that's a violation.
Does the CMP properly gate the client-side GTM container that triggers the server-side request?

A clean pre-consent scan should show zero analytics or marketing cookies and zero measurement protocol requests before the user interacts with the consent banner. This is true for both client-side and server-side implementations.

To understand what pre-consent tracking is and why it matters, see our foundational guide.

Practical Checklist for Server-Side Tagging Compliance

Whether you're evaluating server-side tagging or already running it, verify these items:

Consent still gates all tracking: The measurement protocol request doesn't fire until the user opts in
First-party cookies are correctly categorized: Analytics and marketing cookies aren't labeled "necessary" just because they're first-party
CMP covers server-side cookies: Your CMP's cookie list includes the cookies set by your server container
Privacy policy reflects the architecture: Your policy describes the server-side processing, data transfers, and vendors receiving data
Data transfers are addressed: Standard Contractual Clauses or other transfer mechanisms are in place for data forwarded to non-EU vendors
IP handling is documented: Whether IPs are forwarded, truncated, or hashed is documented and justified
Cookie lifetimes are proportionate: Server-set cookies with 2-year expiry for basic analytics may be disproportionate
Regular scans verify pre-consent behavior: Automated scans confirm that no tracking data is collected before consent

The Bottom Line

Server-side tagging is a legitimate architectural choice with real benefits: better performance, more control over data flows, and reduced dependency on third-party scripts in the browser. But it is not a consent workaround.

The compliance rules are simple: if you collect personal data, you need a legal basis. If that legal basis is consent, you need it before collection starts. No amount of server-side proxying changes that fundamental requirement.

See how your server-side setup performs in a compliance scan. Enter your URL and check for pre-consent violations. Run a free scan now.