What is server-side tracking?

In a classic setup, the visitor's browser loads each vendor's scripts and talks to them directly. Every tool receives the request on its own domain, runs its code inside the page and writes its cookies from there. Actual control over what leaves the page is spread across vendors that never consult each other.

The server-side model moves the distribution point. The browser sends a single event to infrastructure you control, hosted under a subdomain of your own website. From there the tagging logic lives outside the browser: that is where you decide which fields are kept, which are trimmed and which destinations they go to.

Two things that often get confused deserve to be kept apart. Collection still starts in the browser, because something has to observe the click or the page view. What moves is the processing and the distribution. Talking about measurement without a browser is therefore inaccurate: the browser stays in the circuit, only with less third-party code and with a single counterpart.

The practical consequence is one of governance. With distribution on the server you can audit in a single place what goes to each vendor, which is very hard to prove when every script decides on its own.

The setup has three pieces. First, a subdomain of your website pointing at the tagging infrastructure, with its own certificate. Second, a server container using the same model of tags, triggers and variables you already know from the client side. Third, a component called a client, which listens for incoming requests, claims them and turns them into events the container can read.

A visit then travels like this. The tag in the browser stops calling the vendor's domain and calls your subdomain instead. The container's client claims that request and builds an event out of its parameters. Triggers decide which tags fire, and each tag opens a server-to-server call to the matching destination. In between you can rewrite, mask or discard parameters before they leave.

Hosting is the part most often underestimated. It is not a setting inside the tool but a service running in your cloud account that has to be sized, watched and paid for. The App Engine setup documentation recommends a minimum of three servers in production to reduce the risk of data loss during an outage, and puts each server at roughly 40 dollars a month, on an instance with 1 vCPU, 0.5 GB of memory and 10 GB of disk. There is also a testing configuration that in most cases incurs no cost, meant for test traffic and preview rather than production. Managed providers rent the server at a fixed rate as well.

The decision that hangs on this is not technical, it is operational. Standing up a tagging server means taking on one more production service, with its monthly bill, its monitoring and someone accountable when it stops responding. Anyone who cannot carry that will end up with a worse system than before, because an outage of the tagging server takes down all measurement, not just one tool.

In return you gain two concrete things. One is control over the outgoing data: you can truncate IP addresses, strip identifiers from the query string or stop a vendor from receiving fields it never should have seen. That is nearly impossible to demonstrate in a setup where every script makes its own call. The other is page weight, because much of the third-party code stops loading in the browser.

It also changes the conversation with the business. If leadership expects to recover a hundred percent of the data lost today, lower the expectation before the budget is signed. The improvement is usually real and measurable, but it is partial and depends on the visitor's browser, on the consent they gave and on the quality of the setup.

• Keep consent collection on the client side and make sure its state travels through to the server container. Consent mode is configured in the web container, and the state reaches the server as request parameters.
• Size production before you migrate: at least three instances, availability alerts and a written rollback plan.
• Use a subdomain of your own website with a valid certificate, and document how DNS resolves it.
• Keep a table of which parameter goes to which vendor, and review it every quarter with whoever owns privacy.
• Migrate in stages: run one event in parallel, compare figures against existing measurement for two or three weeks, and only then switch off the old tag.
• Record the real monthly cost in the project file, maintenance time included.

• Selling it as a compliance solution. Moving the processing does not remove the duty to ask permission before reading or writing information on the user's device.
• Promising that loss to blockers disappears. The effect varies by blocker and by how the path is built, and it has to be measured in your own data.
• Taking cookie lifetime for granted. Safari caps at seven days the expiry of cookies set in responses it identifies as CNAME cloaked.
• Leaving the container unmonitored. Without an availability alert, an outage surfaces in the following Monday's report.
• Promoting the testing configuration to production, when it is meant for test traffic and will not hold real load.