Server-side tracking is one of the most talked-about fixes for patchy marketing data. Route your GA4, Google Ads and Meta events through a server you control, the argument goes, and you'll recover conversions that ad blockers and browser restrictions would otherwise swallow.
There's a lot of truth in that. But there's also a persistent myth riding along with it: that because the data no longer travels straight from the browser to Google or Meta, the usual consent rules somehow don't apply. A new guide from consent management company iubenda, covered by PPC Land, makes the point bluntly. In iubenda's words, server-side tracking "changes where your data is processed, not whether you need permission to process it."
Here's what that means in practice, and what we'd suggest checking before you make the switch.
What server-side tracking actually changes
In a traditional setup, every tag on your site sends data directly from the visitor's browser to its own platform. Server-side tracking replaces those many direct connections with one. The browser sends events to a tracking server, usually on a subdomain you own, and that server then forwards them to GA4, Google Ads, Meta and other platforms.
The most common way to do this is a server-side Google Tag Manager container, which runs alongside the usual web container on your site. Because the server sits between your site and every platform, it becomes a single checkpoint where you can:
- drop fields a platform doesn't need
- hash or remove personal details before anything leaves
- add useful context, such as order value or margin, from your own systems
- keep a record of what was sent and where
Those are genuine benefits for data quality and for governance. None of them, though, changes the legal question of whether you're allowed to collect the data in the first place.
Why consent still applies
iubenda's guide sets out two separate layers of rules, and it helps to keep them apart.
The GDPR requires a lawful basis for processing personal data. For most marketing tracking, iubenda notes, that basis is consent.
The ePrivacy rules, often called the cookie law, require consent for storing or accessing information on a visitor's device. iubenda points out that this requirement attaches to the moment something reads from or writes to the device, "not to where the data travels afterwards." The guide's companion white paper puts it as: "The rule follows the device, not the data."
That matters because server-side setups still use cookies. iubenda notes that while many third-party cookies become unnecessary, sites still typically set first-party cookies to recognise returning visitors, now set by the server and longer-lasting. As it puts it, "consent requirements for those cookies stay the same."
iubenda's guide refers to the EU GDPR and ePrivacy Directive. In the UK, the equivalent rules sit in the UK GDPR and the Privacy and Electronic Communications Regulations (PECR). This post isn't legal advice, so if you're unsure how the rules apply to your own setup, it's worth checking with a data protection specialist.
The short version: if a tag needed consent when it ran in the browser, it still needs consent when it runs on a server. Sending unconsented events from a server, the guide warns, "is still unconsented tracking."
Where consent fits in a server-side setup
Moving to a server doesn't replace your cookie banner or consent management platform (CMP). If anything, it makes them more important. According to iubenda, a sound setup relies on:
- A CMP that captures each visitor's choice, as it does today.
- Consent signals passed to the server, so it only forwards data the visitor agreed to.
- Clear wording in your banner and privacy policy. Server-side processing is invisible to visitors in a way browser scripts aren't, so iubenda argues that "transparency matters more, not less."
- A logged record of consent, so you can show who agreed to what.
The guide also flags one tricky moment to plan for. On a visitor's very first interaction, their consent status isn't known yet, and getting your consent layer and server to talk cleanly at that point "takes careful setup."
It's also worth knowing that server-side tracking and Google Consent Mode do different jobs. In iubenda's framing, server-side tracking helps you capture as much consented data as possible, while Consent Mode's advanced setup uses limited, cookieless pings to model the gap left by visitors who decline.
A related change: Google Ads Data Manager and hashing
There's a parallel lesson in another recent change. Google has told advertisers that from 16 November 2026, Google Ads Data Manager will no longer require customer data to be hashed with SHA-256 for Customer Match and enhanced conversions uploads, according to PPC Land. Instead, data will be encrypted by default, then decrypted, tidied and matched by Google inside a sealed, hardware-isolated environment.
Google says this should improve match accuracy by cutting formatting errors. But if your data protection assessment for Customer Match was written on the basis that "only hashed data leaves us", that assumption is about to change, and the assessment is worth revisiting.
It's the same principle again. Hashing never made data anonymous; iubenda's guide describes it as pseudonymisation rather than anonymisation. How your data travels, whether hashed, encrypted or routed through a server, doesn't change your underlying obligations.
Your server-side tracking checklist
Whether you're planning a move to server-side tracking or already running one, these are the checks we'd suggest:
- Map your data flows. List every tag, which platform it feeds and what data it sends.
- Check your CMP is connected to the server, not just to your browser tags, so nothing fires before a visitor has made a choice.
- Test the first visit. Confirm what happens to events sent before a visitor has accepted or declined.
- Minimise what you forward. Send each platform only the fields it needs.
- Treat hashed data as personal data. Make sure it has a lawful basis like any other personal data.
- Update your privacy and cookie policy to explain server-side processing and name the platforms receiving data.
- Avoid double counting. If you run a browser pixel and a server connection side by side, set up deduplication.
- Run both setups in parallel for a week or two, as iubenda suggests, and compare the numbers before switching off the old one.
- Review your Customer Match and enhanced conversions paperwork ahead of the 16 November Data Manager change.
- Keep monitoring. Browsers, platforms and rules keep moving, so check consent signals and data flows regularly.
If you're also getting to grips with Google's wider tagging changes, our post on the latest Google Tag Manager updates covers what's changing in Tag Manager itself.
Getting it right
Server-side tracking can give you cleaner data, faster pages and much more control over what leaves your site. But the data it recovers is only usable if consent comes with it. The best setups treat accurate measurement and respect for privacy as the same goal.
If you'd like help reviewing your tracking, planning a move to server-side or checking how consent flows through your setup, take a look at our services and get in touch.
Sources: iubenda, "Server-side tracking: the complete guide for marketers"; PPC Land, "Server-side tracking still needs consent, iubenda tells marketers" (24 October 2026); PPC Land, "Google Ads Data Manager stops requiring hashed customer data November 16" (18 October 2026). iubenda sells consent management software.