Server-side tracking sends event and identity data to a server you control, which then forwards it to your analytics and marketing tools, instead of the browser sending it straight to each vendor. Moving collection off the browser keeps it out of reach of ad blockers and some browser privacy limits.
Category
Tracking architecture, Safari ITP
Also known as
SST; server-side GTM
Two flows stacked. Top, client-side: browser sends directly to GA4, ad platform, and Bloomreach, with ad-blocker and Safari-7-day icons cutting two of the arrows (Pink). Bottom, server-side: browser sends one request to a server you own (Teal), which forwards clean to all three vendors.
Example
On Safari, the default client-side setup loses data two ways. Browser privacy (ITP) caps JavaScript-set first-party cookies at seven days, so returning visitors look new. And ad blockers drop requests to known vendor domains before they ever send.
A server-side move addresses both. A Custom Tracking Domain is the targeted version for Bloomreach: the tracking request goes to a subdomain you own, the server sets the cookie over HTTP rather than from JavaScript, and Safari treats it as a genuine first-party cookie. A full server-side container, such as server-side GTM, generalizes the idea: the browser sends one request to your endpoint, and your server fans the data out to GA4, ad platforms, and the rest.
Same principle in both. The browser talks to you, and you talk to the vendors.
What it fixes, and what it doesn’t
It fixes: cookie lifetime on Safari, since HTTP-set cookies aren’t capped at seven days the way JavaScript-set ones are; resilience against ad blockers that match vendor domains; and a single controlled point where you decide what data leaves and to whom.
It doesn’t: remove the need for consent. Moving collection server-side changes where data is processed, not whether you’re allowed to process it, so consent still gates everything. It also isn’t free, because it adds infrastructure to run and monitor, and a server endpoint that breaks quietly takes your tracking down with it.
When it’s worth it
Server-side tracking earns its place when a meaningful share of traffic is Safari or ad-blocked, when you need backend events like refunds or subscription renewals that never happen in a browser, or when you want one place to govern outbound data.
For a single tool like Bloomreach, a Custom Tracking Domain is often enough and far less work than a full server-side container. The broader setup pays off once several tools need the same treatment.
In practice
For a single tool like Bloomreach, reach for a Custom Tracking Domain first. It solves the Safari problem with a DNS change rather than a new server to run and monitor. A full server-side container earns its place only when the same data has to reach several tools, not before. And treat it as a control point, not a privacy workaround: consent still has to be enforced server-side.