Server-side tracking is increasingly presented as the new standard for serious web analytics. Many industry articles suggest that businesses still relying on traditional client-side measurement are losing data and exposing themselves to legal risk. That is only half the story. Server-side tracking does solve one technical problem: data lost to ad blockers and browser restrictions.
What it does not automatically solve is the legal question that concerns many website operators: how to obtain reliable figures without a cookie banner or consent flow.
Confusing these two issues leads to poor decisions. A business may implement server-side tracking, assume consent is no longer an issue, and still end up with the same cookie banner—plus an additional server component to operate.
This article takes a realistic look at the drawbacks of server-side tracking and presents an alternative that is often closer to what small and medium-sized websites actually need: privacy-conscious analytics with less reliance on consent-based tracking.
What server-side tracking means in practice
In classic client-side tracking, the browser sends events directly to Google Analytics, Meta, or other providers. Each of these services communicates independently with the visitor's device, making tracking susceptible to ad blockers and browser restrictions like Safari's ITP.
Server-side tracking adds an intermediary step. The browser first sends data to a first-party domain controlled by the website operator, typically through server-side Google Tag Manager or a similar solution.
The data can then be enriched, hashed or anonymised before being forwarded from server to server to the intended platforms. Because the first point of contact is a first-party domain, many blocking mechanisms aimed at third-party domains no longer apply.
The benefits of server-side tracking—and their limits
The technical benefit is real. Organisations that move from client-side to server-side tracking often record more conversions because events previously blocked by ad blockers or tracking prevention reach their destination again. With a properly configured setup, a greater share of data collected lawfully can be processed and delivered to the relevant platforms.
This is also where the main limitation lies—and where many implementations go wrong: server-side tracking does not remove the need for consent. It is a technical architecture, not a legal basis in itself.
Sending analytics or marketing data that requires consent to Google, Meta or another provider without valid consent remains unlawful, even when the data passes through your own server first.
Whether consent is required depends on factors such as the data involved, the purpose of processing, the recipients, the legal basis and the consent configuration. In every case, the website operator remains the data controller and is responsible for a compliant implementation.
Depending on each provider’s role, you may need a data processing agreement, a joint-controller arrangement or other privacy documentation. Hosting the first server in the EU does not automatically solve international transfer issues either. If the processing chain ultimately reaches a US provider, the final step is still a third-country transfer.
One technical detail is often missed. Teams may configure Google Consent Mode v2 in the browser but fail to pass and enforce the consent status on the server. If a visitor refuses consent yet the server container continues forwarding data, the resulting breach can remain unnoticed until an audit reveals it.
The practical cost of implementation
Beyond the legal limitations, server-side tracking introduces operational work that is easy to underestimate when better data quality is the main attraction. A reliable setup usually requires dedicated server infrastructure or a managed provider, expertise in tag servers, a robust connection to the consent management platform and ongoing maintenance at least comparable to an existing client-side setup.
Smaller teams without in-house DevOps expertise therefore tend to use managed services, adding recurring costs.
That investment can make sense for organisations with a complex advertising stack, multiple brands or demanding attribution requirements. For a smaller online shop, service business or agency that mainly wants to understand traffic sources and page performance, the cost and complexity can outweigh the benefit.
The alternative: cookieless client-side tracking
There is another way to address the underlying problem. Rather than securing an increasingly complex data pipeline, cookieless client-side tracking avoids cookies from the outset and limits personal-data processing to what is necessary for analytics.
Tools such as Trackboxx instead identify visits using a hash derived from the IP address and other parameters. According to the provider, the hash is stored for no more than 24 hours and then deleted automatically, while the IP address itself is never stored in plain text.
The legal distinction from server-side tracking lies in the justification, not only the technology. Section 25 TDDDG does not apply only to cookies; it generally covers storing information on a user’s terminal equipment and accessing information already stored there.
Avoiding cookies can significantly reduce the circumstances covered by Section 25 TDDDG, but it does not guarantee that consent is unnecessary. The key question is whether the script also reads information from the user’s device or performs comparable access.
Trackboxx’s hashing method also deserves careful scrutiny. A hash is not automatically anonymous: if it can be linked back to a person under certain circumstances, it is pseudonymous and therefore still personal data. Keeping it for no more than 24 hours and not storing the IP address in plain text can reduce the privacy risk, but does not automatically make the data anonymous.
The processing therefore still needs a defensible legal basis. According to Trackboxx, it relies on legitimate interests under Article 6(1)(f) GDPR. Whether that legal basis applies depends on the specific implementation and does not replace a case-by-case legal assessment.
The practical advantage is simplicity. Instead of running a dedicated server, tag-management infrastructure and ongoing maintenance programme, the website needs only a single script in its header. Depending on the technical design and legal basis, this approach may be used without prior consent and is not dependent on blockable third-party cookies.
A cookieless client-side script is not completely immune to ad blockers, however. Some blockers recognise known analytics scripts or tracking domains regardless of whether they set cookies.
Comparison: server-side and cookieless client-side tracking
Server-side and cookieless describe different layers, not opposing concepts. Server-side tracking describes how data is transmitted; cookieless describes how it is collected. A server-side setup can also be cookieless and privacy-conscious, while cookieless data is ultimately sent to a server as well.
In practice, the comparison usually comes down to two scenarios: complex server-side tracking for advertising platforms and sophisticated marketing stacks, versus privacy-conscious web analytics for essential website metrics.
| Criterion | Server-Side Tracking | Cookieless Client-Side Tracking (e.g. Trackboxx) |
|---|---|---|
| Implementation effort | High: dedicated server or managed provider, tag management and ongoing maintenance | Low: a script in the header |
| Data loss due to ad blockers | Can reduce data loss, depending on the setup, consent status and destination platforms | May be less susceptible, but a client-side script can still be blocked |
| require consent | Depends on the data, purpose, recipients and implementation; server-side tracking alone does not remove the need for consent | Can be used without consent if the specific technical implementation and the chosen legal basis allow it |
| Data processing agreement requirements | Depends on each provider’s role and the specific processing chain | Also depends on the role of the analytics provider and any other service providers involved |
| Best suited to | Complex ads stacks, high attribution requirements, existing DevOps resources | Websites focused on essential metrics without complex advertising-platform integrations |
| Ongoing costs | Server or provider costs in addition to existing tools | Usually a single monthly subscription |
The table highlights one key point: the two approaches answer different questions. Server-side tracking is about reliably transmitting data that may already be collected. Cookieless tracking is about reducing the number of situations that require consent from the outset.
Which Approach Is Right for Whom?
Server-side tracking can justify its complexity for organisations that run campaigns across several advertising platforms, need granular attribution and already have the necessary technical resources. In those cases, the additional data quality may warrant the investment.
A cookieless approach is often a better fit if you mainly need to understand traffic sources, content performance and where users drop off—without maintaining a complex tag-management system.
For agencies, service providers and smaller online shops looking for reliable core metrics without a cookie banner, Trackboxx is one example of this alternative. It is not intended to replace the full attribution capabilities of more complex advertising systems.
FAQ
Does Server-Side Tracking Replace the Cookie Banner?
Not automatically. If analytics or marketing data that requires consent is sent to providers such as Google or Meta, that consent is still required in a server-side setup.
Is cookie-free tracking automatically GDPR-compliant?
No. Section 25 TDDDG covers not only cookies but, more broadly, storing information on terminal equipment and accessing information already stored there. Avoiding cookies can reduce the circumstances in which these rules apply, but it does not automatically remove the need for consent. Whether a specific implementation can operate without consent depends on its technical design and legal basis and should be assessed legally if there is any doubt.
Can Server-Side and Cookie-Free Tracking Be Combined?
Yes. The approaches are not mutually exclusive. A website may use a cookieless tool for its core metrics and add server-side tracking where specific advertising-platform integrations require it.
Why does traditional client-side tracking lose data?
Several factors combine. Ad blockers may block third-party cookies, recognise known analytics scripts, block tracking domains or stop requests that match particular patterns. Safari and other browsers also limit the lifetime of first-party cookies, while many visitors decline tracking through cookie banners. Together, these effects create significant gaps in analytics data.
External sources
- Section 25 TDDDG (statutory text on storing information on and accessing terminal equipment)
- Article 6 GDPR (lawful bases for processing, particularly Article 6(1)(f): legitimate interests)
- Server Side Tracking & GDPR: a compliance guide for businesses, tobiasbatke.com, updated March 2026
- Server-Side Tracking 2026: the complete guide, meixner-tobias.com, updated April 2026
- Advantages and disadvantages of Server Side Tracking, digital-motion.de
- What is server-side tracking?, jentis.com, updated January 2026
Deutsch 
English (UK) 
Français 
Italiano 
Español 
Nederlands 
Polski 
Svenska 