Server-side tracking and consent

What is server-side tracking?

With ordinary tracking, the browser does all the work. Your page loads scripts from Google, Meta and other vendors, and each script sends data straight from the visitor's browser to that vendor's servers.

With server-side tracking, the browser sends the data to one place first: a server you control, usually on a subdomain of your own website such as metrics.example.com. That server receives the request, turns it into events and decides what to forward to which vendor. The best-known example is server-side Google Tag Manager: a "server container" that runs in Google Cloud or with a specialised hosting provider, next to the normal web container in the browser. Common uses are GA4 via a server container and the Meta Conversions API, which lets your server send conversions to Meta directly.

The important part: in most setups the visitor's browser still runs a script and still sends the data. The difference is where it goes first.

Does server-side tracking need consent?

Two sets of rules apply, just as with any other tracking (see EU cookie law explained):

1. The cookie rule, article 5(3) of the ePrivacy Directive: storing information on the visitor's device, or reading information from it, needs consent, unless it is strictly necessary for a service the visitor asked for.
2. The GDPR: processing personal data needs a legal basis, transparency and safeguards.

Server-side tracking does not take you outside the cookie rule. The rule is about what happens on the device, not about where the data ends up. It applies to any information, whether or not it is personal data, as the Court of Justice confirmed in Planet49 (2019). In its Guidelines 2/2023 on the technical scope of article 5(3), the European Data Protection Board (EDPB) explains that:

• a website that uses JavaScript to make the browser send information is gaining access to that information, which falls under the rule;
• adding identifiers to URLs or to tracking pixels is an instruction to the device to send that identifier back, and also counts as gaining access;
• collecting a unique identifier, such as a hashed email address, through code in the browser falls under the rule as well;
• even tracking based only on the IP address can fall under it, unless you can make sure the address does not come from the visitor's device.

A server-side setup does exactly these things: the Google tag in the browser sends events to your server, and the server container can place a cookie on your domain to recognise the visitor. So a first-party cookie set through a server container needs consent for analytics or marketing, just like one set by a script. The EDPB adds that the rule applying does not always mean consent is needed: strictly necessary storage is exempt, and some countries allow limited audience measurement without consent. Those exemptions depend on the purpose, not on the technology.

The GDPR still applies on the server

Once the data reaches your server, the GDPR applies to everything you do with it: forwarding it to Google or Meta, enriching it with order or CRM data, building audiences. You need a legal basis for each purpose, and the EDPB's consent guidelines say that where consent is the basis, it must be obtained before the processing starts.

For advertising and profiling, that basis is in practice consent. In Meta Platforms v Bundeskartellamt (C-252/21, 4 July 2023), the Court of Justice ruled that personalised advertising cannot justify Meta's processing of user data as a legitimate interest without the user's consent. A website that sends visitor data to an advertising platform for targeting or conversion measurement will find it hard to argue for legitimate interest where the platform itself cannot.

What server-side tracking does change

Server-side tracking is not a way around consent, but it can make your tracking more privacy-friendly and easier to control:

• Control over what vendors receive. Google says that only you have access to the data in the server container until you choose to send it on. You can remove fields, shorten URLs or drop events before they leave your server.
• IP addresses and identifiers. You can choose not to forward the full IP address, or to replace identifiers before sending data on. This supports data minimisation (article 5(1)(c) GDPR).
• Fewer third-party requests in the browser. Fewer vendor scripts on the page means fewer parties that can read data directly from the visitor's device.
• Transfers outside Europe. If your server runs in the EU and strips data before forwarding it, less personal data reaches vendors outside Europe. The French regulator CNIL describes such a "proxy" for audience measurement under strict conditions: no IP address passed on, the identifier replaced, referrer and URL parameters removed, no cross-site identifiers, and hosting that prevents transfers outside the EU. The CNIL presents this as a way to deal with transfers, not as a reason to skip consent.

Server-side tracking with a cookie banner and Consent Mode

The setup that works is the same as without a server container, with one extra step:

1. Your cookie banner collects the choice and blocks analytics and marketing tags until the visitor consents.
2. Google Consent Mode v2 passes the choice on (see Google Consent Mode v2 explained). Google's documentation says you only need to set up Consent Mode in the web container: the Google tag adds the consent state to each request it sends to the server container.
3. Google's tags in the server container follow that state. In basic mode, Analytics tags are blocked completely and no Analytics cookies are set or read, in the browser or on the server. In advanced mode, Analytics tags send anonymous measurements instead. Without consent, Google Ads conversion tags do not read or write cookies, and Google Ads remarketing and Floodlight requests are blocked.
4. Tags from other vendors need your attention. Google only promises this for its own tags. A Meta Conversions API tag or any other tag in the server container should only fire when the consent state allows it; set that up yourself with triggers or conditions.

A banner such as Cookie Confirm sets the Consent Mode defaults before any Google tag loads and updates them after the visitor chooses, so the consent state reaches the server container with every request.

Meta Conversions API and consent

The Meta Conversions API connects your server to Meta, so you can send website events such as purchases and leads without relying only on the Meta Pixel in the browser. Meta uses those events for ad measurement and optimisation.

That makes it advertising processing. Meta's Business Tools Terms require you to have all necessary rights and a lawful basis for the data you share, and, in countries that require consent for storing or accessing information on devices (the terms name the EU), to obtain verifiable consent from visitors. Under those terms you are the controller for that data in the EU. In practice:

• send Conversions API events only for visitors who accepted marketing in your banner;
• do not use the Conversions API to "recover" conversions from visitors who declined;
• mention Meta and the Conversions API in your cookie and privacy policy.

Meta's "Limited Data Use" option is meant for certain US state privacy laws. It is not an EU consent mechanism.

Common mistakes

• "It's cookieless, so no consent is needed." The cookie rule covers more than cookies: scripts that make the browser send data, tracking pixels, URL identifiers and unique identifiers all fall under it, according to the EDPB.
• "It's first-party now." The rule does not distinguish first-party from third-party, or cookies set by a script from cookies set by a server. The purpose decides.
• Sending data before the choice. If your server container forwards page views or conversions to vendors before the visitor has clicked in the banner, you process data without a legal basis.
• "Hashed email is anonymous." A hashed email address is pseudonymised data, which the GDPR still treats as personal data (recital 26). It is hashed precisely so that a platform such as Meta can match it to a person.
• Forgetting non-Google tags. Consent Mode only steers Google's tags. Every other tag in the server container needs its own consent check.
• Not updating your cookie policy. Visitors must be told which vendors receive their data, also when the data goes through your server first.

The UK

Since February 2026, the UK's PECR has an exception for storage or access used only to produce statistics about how your website is used, in order to improve it. According to the ICO, it covers aggregate analytics only, not tracking individuals, profiling or anything related to advertising, such as measuring ad performance or sharing conversion data with advertising partners. A third-party provider may only act as your processor. Server-side analytics can fall under it if it meets those conditions; server-side advertising tracking, such as the Conversions API, cannot. More in UK cookie law and Google Analytics and the GDPR.

Sources

• ePrivacy Directive 2002/58/EC (consolidated), article 5(3)
• General Data Protection Regulation (EU) 2016/679
• EDPB: Guidelines 2/2023 on the technical scope of Art. 5(3) ePrivacy Directive
• EDPB: Guidelines 05/2020 on consent under Regulation 2016/679
• CJEU: Case C-673/17, Planet49 (1 October 2019)
• CJEU: Press release 113/23 on Case C-252/21, Meta Platforms v Bundeskartellamt (4 July 2023)
• Google: An introduction to server-side tagging
• Google: Implement consent mode with server-side Tag Manager
• Google: Custom domain for server-side tagging
• Meta for Developers: Conversions API
• Meta for Developers: Data Processing Options for US users
• Meta: Business Tools Terms
• CNIL: Audience measurement and data transfers (in French)
• ICO: What are the exceptions?
• Data (Use and Access) Act 2025, Schedule 12