Category: Education | Reading time: 6 min
When marketers first hear about server-side tracking, a reasonable question surfaces quickly: isn’t this just a way to get around privacy protections?
It’s worth answering directly, because the concern reflects a genuine misunderstanding of how server-side tracking works – and what privacy regulations actually require.
The short answer is no. Server-side tracking, implemented correctly, doesn’t circumvent privacy law, doesn’t capture data from people who haven’t consented and doesn’t do anything your existing client-side setup wasn’t already trying to do. What it does is make the tracking you’re already legitimately entitled to actually work.
Here’s the longer version.
What privacy regulations actually require
GDPR (EU), CCPA (California), Australia’s Privacy Act, PIPEDA (Canada), PDPA (Thailand and Singapore), LGPD (Brazil), POPIA (South Africa), and their equivalents across other jurisdictions share a common structure. They require that businesses:
- Tell users what data is being collected and why
- Obtain meaningful consent before collecting non-essential tracking data
- Give users the ability to withdraw consent or request deletion
- Handle data responsibly and proportionately.
What these regulations do not require is that tracking be technically easy for users to block. The legal obligation is around consent and disclosure – not around whether an ad blocker can intercept your pixel.
This distinction matters. A user who has visited your site, read your cookie notice and clicked “Accept all cookies” has given valid consent for tracking under most frameworks. If an ad blocker then silently prevents that tracking from working, the user’s legal position hasn’t changed – they consented. The tracking just failed technically.
Server-side tracking fixes that technical failure. It doesn’t change who has consented or what you’re permitted to collect. It just makes the collection you’re already legally entitled to perform actually succeed.
Consent still governs everything
This is the most important point and it’s worth being unambiguous about it.
A properly implemented server-side tracking setup honours consent signals exactly as a client-side setup does. If a user declines tracking – through your cookie consent banner, a browser-level global privacy control or any other mechanism – server-side events for that user should not fire. The server receives a consent signal from your consent management platform and acts on it accordingly.
Tiide is designed with this in mind. Consent is respected at the event level. Users who opt out are not tracked. The server-side infrastructure doesn’t create a backdoor around consent – it operates within the same consent framework your site already has in place.
If you have a consent management platform (CMP) like Cookiebot, OneTrust, Usercentrics, or similar, your existing consent configuration continues to control what fires and for whom. Tiide sits downstream of that consent layer, not upstream of it.
The ad blocker distinction
One source of confusion is the relationship between ad blockers and consent.
Ad blockers are not consent mechanisms. They are user-installed tools that block network requests based on known domain lists. They do not communicate a consent signal to websites. They don’t tell your analytics platform “this user has opted out”. They simply intercept and drop certain requests silently, without the site or the user having any clear visibility into what was blocked.
A user who installs an ad blocker may personally prefer not to be tracked – but that preference hasn’t been expressed through any legally recognised consent mechanism. They haven’t clicked “decline” on your cookie banner. They haven’t submitted a data subject request. Their ad blocker has just quietly blocked a network call.
This creates a genuinely ambiguous situation. Some privacy advocates argue that ad blockers represent a meaningful expression of preference and should be respected as such. Others note that the same user may have explicitly accepted tracking cookies on the same site, creating a direct contradiction between their stated consent and what their browser is doing.
Server-side tracking doesn’t resolve that philosophical debate. But it’s worth being clear: implementing server-side tracking for consenting users is not the same as ignoring opt-outs. It is ensuring that the tracking consent you have been given actually works.
What data is actually being collected
Another common concern is about the nature of the data server-side tracking handles. The worry is that moving event collection server-side somehow opens up access to more sensitive data than client-side tracking.
In practice, the opposite is often true.
Client-side tracking – particularly third-party pixels – gives external platforms (e.g. Meta and Google) direct access to browser-level signals: cookies, device fingerprints, browsing behaviour across sessions. Third-party scripts running in the browser have relatively broad access to the browsing environment.
Server-side tracking, by contrast, routes events through your own infrastructure. You control what data is collected, what is hashed before transmission and what reaches the external platforms. This is more privacy-preserving architecture, not less privacy-preserving – because the data pipeline runs through infrastructure you own and can audit, rather than through third-party scripts with broad browser access.
With Tiide, customer data transmitted to platforms like Meta via the Conversions API is hashed using SHA-256 before it leaves your environment. Email addresses, phone numbers and other identifiers are converted to one-way hashes – values that Meta can use for matching purposes but that cannot be reversed to recover the original data. This is the same approach Meta requires and recommends for CAPI implementations.
First-party data is the privacy-friendly direction
The broader trajectory of the privacy landscape points toward first-party data and away from third-party tracking – and server-side tracking is aligned with that direction, not opposed to it.
Third-party cookies – the mechanism that has powered most cross-site tracking and audience building for the past two decades – are being deprecated. Safari blocked them years ago. Firefox followed. Chrome’s deprecation is in progress. The regulatory environment has consistently treated third-party tracking more sceptically than first-party data collection.
Server-side tracking builds on first-party data: identifiers collected on your own domain, stored in your own infrastructure, transmitted through your own server. This is fundamentally how privacy regulators, browser manufacturers and industry bodies have indicated they want the web to work. You have a direct relationship with your customer. You collect data within that relationship, with consent. You use it to understand what’s working.
That’s not a privacy grey area. It’s the model that the entire industry is being pushed toward.
What Tiide doesn’t do
To be concrete about the boundaries:
Tiide does not track users who have declined consent. The consent signals from your CMP are respected. If a user opts out, their events don’t fire – server-side or otherwise.
Tiide does not enable cross-site tracking. Events are scoped to your domain and your customer relationships. Tiide is not a data broker and does not share event data across clients.
Tiide does not store personal data beyond what’s needed to transmit events. The platform functions as a forwarding pipeline. Events are processed and transmitted to your designated platforms – GA4, Google Ads, Meta – and not retained by Tiide as a data store of your customers’ personal information.
Tiide does not give platforms access to data they couldn’t have received with a functioning Pixel. The events transmitted via CAPI are the same events your Pixel was attempting to send. The difference is reliability, not scope.
Final word
Server-side tracking exists to solve a technical problem: the fact that browser-based tracking has become increasingly unreliable due to ad blockers, browser privacy features and cookie restrictions.
It does not exist to circumvent the genuine privacy rights of users who have chosen not to be tracked. Used correctly, it is a more transparent, more controllable and more privacy-aligned approach to measurement than the third-party pixel infrastructure it supplements.
The marketers and businesses using Tiide are not doing anything that wasn’t already permitted. They’re just making sure what was permitted actually works.
If you have a consent management setup, keep using it. If you have a privacy policy that accurately describes your data collection, keep it updated. Those obligations don’t change with server-side tracking. What changes is that your measurement infrastructure becomes more reliable – and more honestly reflects what consenting users are actually doing on your site.
