Server-side tagging and cookies: impact on consent

TL;DR

Server-side tagging moves data collection from the user's browser to a server you control. This allows you to filter, anonymize, or block data before sending it to third parties (Google, Facebook, etc.), bypass ad blockers and browser restrictions (Safari ITP, Chrome third-party cookie deprecation), and extend first-party cookie lifespans. However, server-side tagging does not remove the consent requirement: if you collect personal data, the GDPR and ePrivacy Directive apply, whether tracking is client-side or server-side.

What is server-side tagging?

Server-side tagging is a data collection method that moves tag execution (tracking scripts) from the user's browser to a server container managed by your organization. Instead of the user's browser sending data directly to Google Analytics, Facebook, or other third-party services, data first flows through your server, which then decides what to transmit, to whom, and in what form.

In the traditional client-side model (the dominant model until now), each third-party tag loads in the user's browser. This means Google, Facebook, and all other third-party services receive data directly from the browser, without you being able to precisely control what is transmitted.

With server-side tagging, the browser only sends data to your server (typically a subdomain of your own domain, such as analytics.yoursite.com). Your server then processes this data and redistributes it to third-party services via server-to-server connections. This gives you full control over the data that leaves your infrastructure.

Why is server-side tagging gaining traction in 2026?

Several factors are converging to make server-side tagging the new standard for data collection.

Browser restrictions

Safari (ITP) limits JavaScript-set cookies to 7 days and has blocked third-party cookies since 2020. Firefox Enhanced Tracking Protection blocks known tracking scripts by default. Chrome began restricting third-party cookies in 2025. These restrictions reduce the lifespan and reliability of client-side cookies, degrading analytics and advertising data quality.

Ad blockers

Over 40% of tech audiences in Europe and North America use ad blockers. These tools block client-side tags (GTM, GA4, Meta Pixel) based on lists of known domains. Server-side tagging deployed on a first-party subdomain is invisible to these blockers because requests appear to come from your own domain.

Data control

Server-side tagging allows you to filter, anonymize, or remove data before sending it to third parties. For example, you can remove the user's IP address before sending data to Google Analytics, or hash email addresses before transmitting them to Facebook for conversions. This control is a key element of GDPR compliance (data minimization principle).

Site performance

Each client-side tag loads a script in the browser, slowing page load. By moving processing to the server, the number of browser scripts decreases, improving load speed and, by extension, SEO and user experience.

Does server-side tagging remove the consent requirement?

No. This is the most widespread and dangerous myth. Server-side tagging does not remove the consent requirement under the GDPR and ePrivacy Directive.

The ePrivacy Directive (Article 5(3), transposed by Article 82 of the French Data Protection Act) requires consent for any access to or storage of information on the user's terminal, except for strictly necessary cookies. If your server-side implementation places first-party cookies to identify users, consent is required.

The GDPR applies to all processing of personal data. IP addresses, client identifiers, user agents, and other information transmitted in HTTP requests constitute personal data under the GDPR. Even if you remove cookies, the mere act of collecting and processing this data on your server constitutes processing that requires a legal basis (consent, legitimate interest, etc.).

In summary: server-side tagging changes the "where" and "how" of collection, not the "whether." You still need a compliant cookie banner and a CMP to collect consent before gathering non-essential data.

What server-side tagging actually changes for consent

While server-side tagging does not remove the consent requirement, it significantly changes how consent is technically enforced.

Server-side consent enforcement

In client-side mode, tag blocking relies on the browser: the CMP must prevent scripts from loading before consent. If a script loads anyway (configuration error, timing, cache), the cookie is placed. In server-side mode, consent can be verified on the server before transmitting data to third parties. This constitutes an additional verification layer, more reliable than client-side blocking alone.

Data filtering and anonymization

The server can remove or anonymize personal data before transmitting it. For example: removing the IP address before sending to GA4, hashing emails for conversion APIs (Facebook CAPI, Google Enhanced Conversions), or removing URL parameters containing personal identifiers.

First-party cookies with extended lifespan

Cookies set by the server (via HTTP Set-Cookie headers) are not subject to the same restrictions as JavaScript-set cookies. Safari ITP limits JavaScript cookies to 7 days, but server-side cookies (set from a first-party subdomain) can have a longer lifespan. This improves tracking quality for returning visitors, but does not change the consent requirement for these cookies.

How to integrate server-side tagging with Consent Mode

Consent Mode v2 works in both client-side and server-side modes. In a server-side architecture, the flow is as follows.

The CMP collects consent on the client side (in the browser). The consent state is transmitted to the GTM server container with each event. The server container checks the consent state before transmitting data to third-party services. If consent is "denied," data is not transmitted (basic mode) or is transmitted as anonymized pings (advanced mode).

This architecture provides dual verification: the CMP blocks scripts on the client side, and the server verifies consent before each transmission. This is the most robust configuration for ensuring data does not leave your infrastructure without consent.

Common mistakes (and how to avoid them)

Believing server-side tagging eliminates the need for consent. This is false. The GDPR and ePrivacy Directive apply whether tracking is client-side or server-side. Fix: maintain your consent banner and CMP, even with a server-side architecture.

Using server-side tagging to bypass blockers without consent. Deploying tracking on a first-party subdomain to bypass ad blockers is technically possible, but doing so without consent means collecting data in violation of the GDPR. Fix: bypassing ad blockers is only legal for users who have consented.

Forgetting that server-side cookies also require consent. A cookie placed by an HTTP Set-Cookie header from your server is still a cookie under the ePrivacy Directive. If it is not strictly necessary, consent is required. Fix: include server-side cookies in your cookie policy and CMP configuration.

Not auditing data transmitted by the server. Server-side tagging gives you control, but that control is useless if you do not verify what is actually transmitted. Fix: regularly audit outbound data flows from your server container to verify personal data is properly filtered or anonymized.

Underestimating technical complexity. Server-side tagging requires a server (typically Google Cloud Run or AWS), DNS configuration (first-party subdomain), and ongoing maintenance. It is not a one-click plugin. Fix: plan for the necessary technical resources or work with a specialized provider.

Thinking server-side solves the missing data problem. Server-side tagging improves coverage (less ad blocker interference, longer-lasting cookies), but users who refuse consent remain invisible. Fix: combine server-side tagging with optimized consent rate and conversion modeling to maximize coverage.

Checklist: server-side tagging and cookie compliance

1. The consent banner is maintained even with a server-side architecture.
2. Consent state is transmitted from client to server container with each event.
3. The server container verifies consent state before any transmission to third parties.
4. Server-side cookies (first-party) are declared in the cookie policy.
5. Personal data (IP, email, identifiers) is filtered or anonymized on the server before sending to third parties.
6. The first-party subdomain is configured (e.g., analytics.yoursite.com) with correct DNS records.
7. Consent Mode v2 is implemented and its signals are propagated to the server container.
8. A cookie audit confirms non-essential cookies are not placed before consent, including server-side cookies.
9. Outbound data flows from the server are audited regularly.
10. Technical architecture documentation is up to date in the processing register.

Conclusion

Server-side tagging is a major evolution in data collection that offers better control, better resilience against browser restrictions and ad blockers, and better capability to filter personal data. But it does not change the fundamental consent rules: the GDPR and ePrivacy Directive apply whether tracking is client-side or server-side.

The ideal architecture combines server-side tagging with a compliant CMP and Consent Mode v2 to ensure consent is verified on both the client and server sides. This is the most robust configuration for reconciling compliance and data quality.

To verify that your site does not place cookies before consent, including server-side cookies, run a free scan with FlowConsent.