What server-side tracking is – and what it isn't

How does classic browser tracking work?

With client-side tracking, the visitor's browser loads scripts from Google, Meta and other providers. Each script collects data and sends it directly to its provider. The store owner has no intermediate step at which to see or control what the script transmits. At the same time, each of these scripts is a target for ad blockers and browser protections, and each one costs loading time.

What changes with server-side tracking?

With server-side tracking, the browser first sends its measurement data to your own server, which runs under your domain, for example on a subdomain such as data.yourstore.com. A Google Tag Manager server container runs there. It receives the data, checks and cleans it, and forwards it in a controlled way to GA4, Google Ads, Meta, Microsoft and other platforms.

This changes three things fundamentally:

• Control: You decide which data goes to which platform. IP addresses can be truncated, parameters removed and sensitive fields filtered before anything leaves your server.

• Stability: Requests go to your own domain instead of well-known tracking domains. Cookies can be set by the server rather than by JavaScript, which in Safari, depending on the setup, results in considerably longer lifetimes.

• Connection to platform APIs: The server talks directly to the ad platforms' conversion interfaces, such as the Meta Conversions API or Google Enhanced Conversions.

Does the server replace browser tracking completely?

In almost every store setup, no. The usual architecture is a hybrid: a lean web container in the browser captures the events and sends them to the server. Some pixels deliberately keep running in the browser because they read click IDs and cookies there for remarketing audiences. The conversions themselves go via the server, and duplicate reports are filtered out using a shared event ID. Anyone who claims that "not a single script runs in the browser any more" after the switch is describing an edge case.

What is the Google Tag Gateway?

The Google Tag Gateway for Advertisers, formerly known as "first-party mode", loads Google scripts such as gtm.js from your own domain instead of Google's servers. Cloudflare offers it as a one-click integration. This is useful, but it is not server-side tracking: it changes the route by which scripts are loaded and data is sent, not who sends the data to the platforms. Ad blockers with good filter lists recognize Google Tag Manager even under your own domain, and cookies are still set by JavaScript. The gateway only reaches its full effect in combination with a server container.

What do the server connections in store apps do?

Shopify apps such as Google & YouTube or Facebook & Instagram and various Shopware extensions now send purchases to the platforms server-side themselves. For a small store with one ad channel, that can be enough. The limits show as soon as several channels, several domains or custom rules come into play: each app works on its own, the data does not pass through a shared point of control, and double counting caused by an app plus your own tag is a common mistake.

Which solution fits which store?

• One ad channel, small budget: Set up the native app connection properly and check consent. Server-side tracking often adds less here than a solid basic configuration.

• Google Ads as the main channel, Cloudflare in place: The Tag Gateway as a quick first step, with realistic expectations.

• Several ad channels, a four-figure monthly budget or more: A server container with TAGGRS or comparable hosting. This is where server-side tracking plays to its strengths, because all channels are fed from one clean data source.