Because browsers keep taking things away. Ad blockers stop tracking scripts loading at all, and Safari limits how long a cookie set by JavaScript survives. Your visitors did not disappear. The mechanism you were using to count them stopped working reliably, and the gap grows every year.
Founders usually notice this as a mismatch. Your ad platform reports 200 conversions, your analytics reports 140, and your actual sales figures say something else again.
Server-side tracking is the most common answer to that problem. It is also frequently oversold, so this article covers what it fixes and what it does not.
Server-side tracking moves the work of collecting and sending analytics data out of the visitor's browser and onto a server you control. The browser sends one request to your own server, and that server decides what to forward to Google Analytics, an ad platform, or anywhere else. The browser stops talking to a dozen vendors directly.
The current mainstream implementation is server-side tagging in Google Tag Manager. Google describes it as a way to instrument your tags to measure user activity wherever it happens, using the same tag, trigger, and variable model people already know from the client-side container.
The shift is architectural rather than conceptual. You still fire tags and you still define triggers. The difference is where the code runs and who the browser is talking to.
Mostly data loss. When tracking runs in the browser, it depends on third-party scripts loading, third-party cookies surviving, and the browser cooperating. None of those are safe assumptions any more. Moving collection to your own server removes several of those failure points at once.
The clearest example is Safari's Intelligent Tracking Prevention. In its March 2020 post announcing full third-party cookie blocking, WebKit stated that cookies for cross-site resources are now blocked by default across the board, and that ITP would cap the expiry of client-side cookies to seven days.
WebKit went further than cookies alone. The same post describes deleting all of a website's script-writable storage after seven days of Safari use without user interaction on the site, covering IndexedDB, LocalStorage, SessionStorage, media keys, and Service Worker registrations and cache.
Read that carefully, because the detail matters. The seven day clock is about Safari use without interaction with your site, so it resets when someone comes back and engages. It still means a returning visitor after a quiet fortnight can look like a brand new person.
Three pieces do the job. A client receives the incoming request from the browser, a server container holds your tags and triggers, and a tagging server runs the whole thing. The browser sends data to your own subdomain, and the server container forwards what you choose to whichever vendors you use.
The custom domain is the part people underestimate. Because collection happens on a subdomain of your own site, the request is first-party rather than a call out to a vendor's domain, which is exactly what browser restrictions are aimed at.
Google documents the deployment options as Cloud Run, App Engine, or a manual setup on a platform of your choosing. Whichever route you take, you have to configure the custom domain and verify the setup before you trust the numbers.
None of this is a five minute job in a settings panel. It is infrastructure, and it needs somebody who is comfortable owning infrastructure.
More than nothing, and more than most people expect. Google's own tagging server guide states that each server costs approximately 40 US dollars a month, and recommends running a minimum of three servers to reduce the risk of data loss if one goes down. That is a real monthly line item before anyone touches a tag.
The capacity figures are documented too. Google says it expects autoscaling three to six servers, which is the default, to handle 50 to 200 requests per second. Each server is described as an App Engine instance with 1 vCPU, 0.5 GB of memory, and 10 GB of disk in the Flexible environment.
For testing, Google notes the setup uses an App Engine F1 instance class in the Standard environment, and that in most cases you will not incur any costs. So you can trial it cheaply, then pay properly when it goes live.
Add the setup time on top. Between the domain configuration, the container build, and the verification work, this is a project rather than a task.
It can, and Google lists improving page performance as one of the stated benefits. The gain comes from removing vendor scripts from the browser, since each one you delete is a script that no longer has to be downloaded, parsed, and executed on your visitor's phone.
The honest version is that the win depends entirely on how bad things were. A site carrying eight marketing scripts will feel a real difference. A site with one analytics tag will not notice.
We would not sell this as a performance project. If speed is the actual goal, auditing what you load is cheaper and faster, and we covered that in our piece on how third-party scripts slow down your website.
Treat the performance gain as a bonus that comes with better data, not as the reason to build it.
No, and anyone selling it that way is doing you harm. Moving collection to your own server changes the technical path the data takes. It does not change your legal obligations, your consent requirements, or the fact that you are processing personal data about a person.
Google frames it the other way round, listing more detailed user privacy controls as a benefit. That framing is fair, because a server container lets you decide exactly which fields get forwarded to which vendor instead of handing everything to a script you cannot inspect.
Used well, that is genuinely better for privacy. You can strip identifiers before forwarding, you can stop sending data to vendors that do not need it, and you can see what is leaving.
Used badly, it is a way of collecting data after someone declined consent, which is both wrong and a liability. Consent still has to gate collection, and we wrote about the practical side of that in our guide to handling cookie consent.
Probably not, if you are a small business running one analytics tool and spending little on ads. The setup cost, the monthly hosting, and the maintenance only pay for themselves when the missing data is costing you real money in misallocated ad spend or bad decisions.
Our rough test is whether the data gap changes what you would do. If your ad platform and your analytics disagree by a wide margin and you are spending enough that the difference matters, the investment makes sense.
If you publish content, get leads through a form, and check traffic monthly, this is an expensive solution to a problem you do not have. Better internal linking will do more for you than better attribution.
For most Webflow sites we build, a clean standard analytics setup is the right answer, and we covered that in our guide to setting up analytics on a Webflow site.
Historical comparisons, mostly. Server-side collection usually captures more events than the client-side setup it replaced, so your numbers jump on the day you switch. That jump is recovered data rather than growth, and someone will present it as growth unless you say otherwise first.
Some vendor features also depend on their script running in the browser. Session recording, heatmaps, and certain personalisation tools cannot be moved server-side, because they need to watch the page.
Debugging gets harder too. A misconfigured client-side tag is visible in the browser console. A misconfigured server container is visible only if you go and look at the server, which nobody does until numbers look wrong.
Plan for a period of running both. Overlapping the old and new setups for a few weeks is the only way to know which differences are fixes and which are mistakes.
Be clear first about what changed in the browsers, because Chrome cancelled the cookie phase-out and retired most of the Privacy Sandbox APIs, which we cover in our piece on what happened to third-party cookies. Then measure the gap rather than assuming it. Compare your analytics conversions against your actual sales or lead records for one month. If the difference is small, spend your money elsewhere. If it is large and expensive, server-side tracking is worth scoping properly.
If you do go ahead, budget for the hosting Google documents, plan for the setup work, and decide up front which fields you will forward to which vendor. That last decision is the one that makes it a privacy improvement rather than a privacy risk.
If you want help working out whether the gap in your data justifies the build, we are happy to walk through it with you. Reach us at phoenix.studio and we will give you an honest read.
Tell us where you want to go. We'll tell you how we'd get you there.