Consent and server-side tracking: what still applies

Server-side tracking is sometimes described as a way around privacy rules. It is not. Moving a request from the browser to your server changes where it is sent from, not whether you are allowed to send it. If a visitor in a region with consent requirements has not agreed to marketing tracking, the rule applies to your server as much as to the pixel. This guide explains how to build tracking that respects consent and still gives you useful data.

This is general information, not legal advice. Check the rules that apply to you and your visitors.

Server-side does not remove the need for consent

Consent laws such as the GDPR and the ePrivacy rules in Europe, and similar laws elsewhere, concern what you do with personal data and when you set identifiers on a device. They do not care which machine makes the HTTP request. A purchase event carrying a hashed email and an ad click ID is personal data whether it leaves the browser or your server.

So the question to design around is simple: what did this visitor agree to?

Record the choice, then act on it

A workable setup has three parts:

1. A consent banner that asks clearly, offers a real "no", and stores the visitor's choice.
2. The choice travels with the event. When the browser tag sends an event to your server, include the consent state, for example marketing allowed or denied.
3. The server enforces it. If marketing consent is denied, do not forward the event to ad platforms, or forward only what your setup and the law allow.

Doing the check on the server is the safer place for it, because a page can be edited or misconfigured but the server applies one rule to every request.

Google Consent Mode

Google's Consent Mode lets your tags adjust their behaviour according to consent signals. Version 2 added two signals for advertising: ad_user_data, which covers sending user data to Google for advertising and measurement such as enhanced conversions, and ad_personalization, which covers personalised advertising and remarketing. Google's guidance says that to keep using measurement, personalisation and remarketing features, you must collect consent from users in the European Economic Area and pass the signals to Google. Its current verification guidance also lists the United Kingdom and Switzerland.

The effects of denial are specific. If ad_personalization is denied, remarketing stops receiving that visitor's data. If ad_user_data is denied, sending click-ID based conversion data to Google Ads is limited. Since March 2024, Customer Match lists in the EEA need both signals granted. Google describes two ways to implement it:

• Basic: Google tags stay blocked until the visitor answers the banner, so nothing reaches Google before that point. Conversion modelling then relies on a general model.
• Advanced: tags load when the page opens with consent set to denied, and send cookieless pings while it stays denied. Full measurement starts only after the visitor grants consent. Google says this allows a more detailed, advertiser-specific model, because it uses data from before the choice was made.

Whichever you pick, set the defaults deliberately, and call an update when the visitor grants consent so the new state takes effect on that page. Whether cookieless pings are acceptable for your visitors is a legal question for your adviser, not a tag setting.

What to do for each type of event

• Strictly necessary or first-party analytics you are allowed to run can follow your own policy and the rules where you operate.
• Ad-platform conversions (Meta, TikTok, Google Ads) are marketing use. Send them only for visitors who agreed, unless your legal advice says otherwise.
• Data minimisation helps everywhere. Send only the fields you need, hash identifiers, and truncate IP addresses stored for analysis.

Be careful with cross-site identifiers

Linking one person across several sites is a heavier use of data than counting a sale. Disclose it in your privacy notice, give people a way to object or ask for deletion, and honour those requests in every place the data lives, including the server and any copies sent to vendors.

A short checklist

• Show a banner with accept and reject choices of equal weight.
• Store the choice and attach it to every event.
• Gate ad-platform sending on marketing consent, on the server.
• Pass the ad_user_data and ad_personalization Consent Mode signals if you use Google ads for visitors in the EEA, UK or Switzerland.
• Hash personal data and send only what a destination needs.
• Document what you collect and for how long, and keep your privacy notice current.
• Support deletion and opt-out requests end to end.

Where this leaves server-side setups

Consent will reduce the number of events you can send, and that is the correct outcome. The gain from server-side tracking is reliability for the visitors who did agree: fewer events lost to blockers and browser limits. For that side of the problem, see server-side Google Tag Manager. To set the whole thing up in PixelFox, follow the step-by-step consent setup guide.