Server-Side Tracking

When you measure in the browser, you rely on many things at once: the script has to load, no blocker may catch it, the browser has to keep the cookie, and the service has to accept the request. If one of them fails, the event is missing. How many are missing usually becomes clear only when the orders in the analytics tool stop matching the ones in the shop.

With server-side tracking, the browser sends its events to a server on your own domain. There they are checked, shortened or enriched and passed on to the systems that need them. We use this for analytics and business intelligence. Advertising platforms can be a destination, but they are not why we take on these projects.

When a server of your own pays off

The effort is worth it when the numbers in the analytics tool differ noticeably from the shop or CRM, when the same event has to go to several destinations, or when personal fields have to be removed before data is passed on. A site where a dozen services each load their own scripts is also a good candidate.

For a small website with a single analytics tool, a server of your own is usually too much. A cleanly set up browser implementation with a clear measurement plan does more there.

The server does not replace consent. The consent status travels with every event and applies on the server just as it does in the browser. How that works technically is described under consent tracking.

What browsers block today

Safari is the strictest. Intelligent Tracking Prevention blocks third-party cookies completely and deletes cookies set via JavaScript after seven days without a visit. Even cookies set by a server are capped at seven days in Safari if it classifies the request as hidden third-party access, for instance because the subdomain points to someone else’s infrastructure. That is exactly what happens when a tracking server is connected through a CNAME at an external host. We therefore plan the domain setup from the start.

Firefox blocks known trackers and separates cookies per website with Total Cookie Protection. Chrome has stayed with third-party cookies: Google dropped its plan to phase them out and discontinued several Privacy Sandbox technologies in October 2025. Ad blockers work independent of the browser and mostly recognize known scripts and addresses. Requests to your own domain are caught less often, but not without exception.

A server on your own domain therefore closes part of the gap. What visitors decline or deliberately block stays declined.

How a server container works

Most often we use the server container of Google Tag Manager. The web container on the website no longer sends its events to many services, only to the tracking server. There a client accepts the request and turns it into an event with parameters. Transformations decide which parameters each tag gets to see at all, and the tags send the result to the destinations.

Other vendors and custom builds work on the same principle. Google also offers the Google tag gateway, which serves Google tags through your own domain. It is quicker to set up, but it filters nothing and serves only Google services.

What happens to the data on the server

The real gain is that data is processed before it leaves the company. The IP address is shortened. Email addresses that end up in URLs or form fields by accident are removed. Each destination gets only the parameters it needs, and services without their own consent logic receive events only when consent has been given.

The server can also add to events, for example the product category or the contribution margin of an order. These are values the browser does not know and should not know.

The same event then goes to the analytics tool and to the data warehouse. There are two ways to do that: a tag that writes straight to BigQuery, or an endpoint of your own from which a data pipeline loads the events onward. The second is more work but keeps the warehouse independent of the tag manager. In the warehouse the events are joined with order and customer data, and dashboards calculate with the same data as the analytics tool.

Hosting and running costs

Where the server runs depends mainly on who will look after it later. If you already work in Google Cloud, you will usually choose Cloud Run, which Google documents for the server container. Google recommends at least two instances there so that an outage does not cost data, and that sets the baseline cost. A specialized host takes over operations and bills by request volume, but is one more provider in the data flow. Your own containers in an existing cloud or data center give the most control over location and network, but they take operating experience.

Costs grow with traffic and with the number of instances. A cap on scaling prevents surprises. Operations should include monitoring that compares the number of events with the previous day, in addition to errors and response times. A server that runs without errors and still passes on only half of the orders would otherwise show up only in the monthly report.

Switching over without breaking the data

We do not switch in one step. The browser tracking stays active at first, the server runs alongside it, and we compare page views, orders and revenue from both routes. Most differences can be explained: by blockers, missing consent, or events that arrive twice because they are counted in the browser and on the server. Only when that is settled do we switch off the old setup.

Such migrations most often fail because only the route of the data is moved. Unclear event names and missing definitions simply move to the server with it. That is why we look at the measurement plan first, even when the assignment is just to “set up server-side tracking”.