What is server-side tracking?

Server-side tracking, or server-side tagging, involves routing browsing and conversion data through an intermediary server before it reaches Google Analytics, Google Ads, or Meta, rather than sending it directly from the user’s browser.

 

In practical terms, this means a change in the data’s path. The browser no longer communicates directly with dozens of third-party platforms: it sends the information to a server that you control, which then redistributes it in a filtered and secure manner.

 

This architecture addresses a problem that has become systemic for marketing teams: traditional client-side tracking is becoming less reliable due to the combined effects of the GDPR, ad blockers, and browser restrictions on third-party cookies.

Client-side tracking vs. server-side tracking

To understand the benefits of server-side tracking, we first need to look at how client-side tracking works, which is still the most common approach today.

 

With client-side tracking:

• The user's browser loads a script (Google Analytics tag, Meta pixel, etc.)
• This script sends the data directly to the third-party platform
• Every platform added is one more script that needs to be loaded in the browser

With server-side tracking:

• The browser sends a single request to a server that you host (a Google Tag Manager Server-Side container, for example)
• This server processes the data and then forwards it to Google Analytics, Google Ads, Meta, etc.
• Browsers and ad blockers only see a single request to your own domain, not a multitude of third-party scripts

 

This distinction is not merely a technical matter. It has direct implications for the reliability of measured conversions—and thus for the quality of decisions made based on this data: media budgets, channel allocation, and profitability management.

How does server-side tracking actually work?

The most common architecture is based on Google Tag Manager Server Side (GTM Server Side). The principle is:

1. A customer container, installed on the site, tracks events (page views, clicks, conversions) and sends them to a server container, rather than directly to third-party platforms.
2. A server container, hosted on a cloud infrastructure (most often Google Cloud Run), receives these events.
3. This server container enforces rules: data enrichment, filtering of sensitive information, and distribution to the appropriate platforms.
4. The data is then transmitted to the destination tools (Google Analytics 4, Google Ads, Meta Conversions API) via server-to-server connections, which are less likely to be blocked.

This shift in the data collection process—from the browser to a server you control—is what makes a real difference in three areas: reliability, compliance, and data security.

Why does server-side tracking improve measurement reliability?

Less impact from ad blockers and browser restrictions

Ad blockers and certain native browser features (such as Safari’s Intelligent Tracking Prevention) primarily target third-party domains identified as trackers. A server-side call, hosted on your own subdomain, is harder to identify and block than a typical third-party script. This does not make tracking invisible or «unblockable,» but it significantly reduces the data loss associated with these blocks.

Higher-quality conversions for advertising algorithms

Platforms like Google Ads and Meta use the quality and volume of conversions received to optimize their automated bidding. Fewer lost conversions mean better-informed algorithms, which in turn lead to more relevant media decisions. This is one of the most well-documented use cases for server-side processing, particularly through advanced conversion APIs (Meta Conversions API, Google Ads Enhanced Conversions).

A Stronger Foundation for GDPR Compliance

Server-side tracking does not replace consent management; a visitor who refuses cookies must always be respected, regardless of the technical architecture. However, it allows you to centralize and precisely document what data is sent, to whom, and under what conditions. When combined with Google Consent Mode v2, it offers more granular control than a multitude of third-party scripts scattered throughout the site’s code.

Things to Know Before You Get Started

Server-side tracking is not a magic solution, and it would be dishonest to present it as such.

• It does not circumvent consent. If a user opts out of tracking, the server-side system must not—and legally cannot—continue to collect their data as if nothing had happened.
• It involves infrastructure and maintenance costs. A server container must be hosted, monitored, and updated. It is not a «set it and forget it» configuration.
• It requires genuine technical expertise. An incorrect configuration can introduce new data discrepancies rather than resolve them.
• It does not solve the underlying problems of a poorly structured labeling plan. Migrating a faulty tracking system to a server-side architecture without revising the tagging plan is simply shifting the problem rather than solving it.

That is why a server-side tracking project always begins with an audit, not with implementation.

A concrete example: Octopus Energy

In the project Daware led for Octopus Energy, rebuilding the tracking system and transitioning to a server-side approach were key components of the acquisition strategy, alongside SEO and paid advertising. The goal was not tracking for its own sake, but rather ensuring the reliability of the data transmitted to advertising algorithms, so they could accurately identify the value of acquired users.

This point highlights an important reality: server-side tracking is most effective when it is part of a comprehensive acquisition strategy, rather than a standalone technical project.

How can you determine whether your company should migrate to server-side processing?

A few questions to ask yourself before launching the project:

• Do you notice significant discrepancies between the conversions tracked by your advertising platforms and your actual sales data?
• Is your media budget large enough for the quality of the conversions fed into the algorithms to have a measurable impact?
• Is your current tagging plan documented and understood by your teams, or is it based on legacy configurations that aren't well managed?
• Do you have the internal or external resources to maintain a server infrastructure over the long term?

If the answer to the first or second question is yes, the issue warrants further investigation. If the answer to the third question is no, an audit of the labeling plan must be conducted before any migration takes place.

Does server-side tracking replace Google Analytics or Google Ads?

No. It changes the way data is delivered to these platforms, not the platforms themselves.

Is server-side tracking compliant with the GDPR?

Yes, provided it is configured in accordance with consent management (Consent Mode). Under no circumstances does this exempt you from respecting users' choices.

Is server-side tracking necessary for all companies?

No. It becomes relevant once conversions and media spend reach a certain level, when data quality has a direct impact on campaign performance.

How long does it take to migrate to server-side tracking?

It depends on the complexity of the existing marking plan and the number of platforms that need to be reconnected. A preliminary audit allows us to estimate the actual scope of the project before committing to a timeline.

To assess the reliability of your current tracking system and the feasibility of migrating to a server-side architecture, our tracking agency can perform an initial assessment.

Learn about our tracking services