The symptom

A client forwards an article claiming cookies are being phased out and asks why the agency has not "moved to server-side" yet. Or the reverse happens: the agency already runs a server-side container, and a client still sees the same gaps in Google Ads and GA4 as before, with nobody able to explain why the migration did not close them. Both conversations happen because "client-side vs server-side" gets sold as a single switch, on or off, that decides whether tracking works.

It is not a switch. It changes where one part of the pipeline runs and who sets the resulting cookie, and it leaves several things exactly as they were.

Why it happens

Start with what each term names. A client-side tag runs inside the visitor's browser, in a web container such as the standard Google Tag Manager setup on a site. It can only read what the browser hands it: the page's DOM, its own "document.cookie" storage, whatever loaded before the tag fired. A server-side setup adds a second container next to it. Google's own description of server-side tagging puts it plainly: the server "receives web requests from the user's device and transforms those requests into events," running in an environment the operator controls rather than in the visitor's browser. For the full step-by-step trace of one event through that pipeline, see how server-side tracking actually works.

Three things genuinely change once that second container goes live.

Where the request lands. A client-side tag typically calls a well-known third-party domain, Google's or Meta's, directly from the browser. A server-side container gives the browser one destination to call instead, usually a subdomain of the site itself. That moves the request outside most domain-based ad blocker lists, though blocklists also match on request pattern, so this is a shift in odds, not a guarantee, and it does nothing for the share of events ad blockers strip outright, 30-40% by current estimates.

How long the cookie lasts. This is the one difference with a hard number behind it. WebKit's own ITP 2.1 announcement caps any cookie "created through document.cookie" to a seven day expiry in Safari, regardless of what sets it. A server-side container can set a cookie in its HTTP response instead of through JavaScript, and that cookie is not subject to the seven-day rule, up to the platform ceiling: Chrome's own engineering blog confirms no cookie can be set for longer than 400 days. The gain from seven days to 400 is real, but it only fires when the tagging server runs on the site's own domain. Google's documentation on custom domain configuration is explicit that on the default cloud domain the server "can only set Javascript cookies," the same seven-day-capped kind it was meant to replace.

What each destination receives. A server-side container can enrich, filter or forward an event before it reaches Google, Meta or anywhere else, and that part is real. But every destination keeps its own rules on the other side. Meta's documentation on deduplication requires a browser Pixel event and a server Conversions API event to share a matching event_id and event_name before it treats them as one conversion rather than two. Skip that step and a server-side project inflates numbers instead of recovering them.

Now the part most comparisons skip: what stays identical either way. Consent obligations do not move with the processing location. The EDPB's own guidance on the technical scope of Article 5(3) ePrivacy states that a different entity receiving the data than the one that instructed the device to send it "does not preclude the application of Article 5(3)." In practice that shows up as one line in Google's own setup guide for the combination: consent mode is configured in the web container, not the server one, whichever container ends up sending the event onward.

The browser's first request does not disappear either. Server-side tracking moves where that request goes, not whether it has to be sent at all. If a visitor's browser never sends it, a network failure, an extension blocking the request outright, a refused consent choice, no container downstream ever sees that visit. Both architectures sit under the same rough 95% ceiling. Some share of events is always missing, and the 15-40% recovery range agencies see after a correctly configured server-side migration is a gain against today's baseline, not a route to a dataset with nothing missing from it.

One more thing worth correcting directly, since a lot of older comparison content assumes it: Chrome is not phasing out third-party cookies. Google confirmed in April 2025 it would not roll out a new consent prompt for them, and repeated that stance in October 2025 while retiring most of the Privacy Sandbox APIs that were meant to replace them. Safari and Firefox are a different story: Safari's ITP caps client-set cookies regardless of what Chrome decides, and Firefox has partitioned third-party cookies by default since 2022. If a decision is being made on the premise that cookies are going away everywhere soon, that premise is wrong for the browser most clients' traffic runs on.

What good looks like

A correct setup runs both, not one instead of the other. The client-side, web container stays in place, handles consent mode and page-level logic, and the server-side container sits behind it on the site's own domain, receiving the browser's requests and forwarding well-formed, deduplicated events onward. Archon Signal is built for agencies that need this configured and kept correct: the domain, the deduplication keys, and the destination-side rules, rather than a container that runs but was never checked against what each platform actually expects. Whether that investment pays back for a specific account is a separate question, covered in is server-side tracking worth it for your agency.

FAQ

Does server-side tracking fix ad blockers?

Not fully. Moving the destination to a same-domain endpoint takes it off most domain-based blocklists, which recovers some of the share of events ad blockers strip, but a request that never leaves the browser, blocked at the extension level or never sent at all, is lost under either architecture.

Is client-side tracking going away because browsers are killing third-party cookies?

Not in Chrome. Google reversed its cookie deprecation plan in 2024 and confirmed again in October 2025 that Chrome keeps offering third-party cookies. Safari and Firefox already restrict third-party cookies by default and are unaffected by that decision either way.

Do we replace our existing Google Tag Manager setup, or run both?

Both, in the setups that hold up. The web container keeps running the page-level logic and consent mode. The server container is added alongside it, not instead of it, and receives what the web container sends.

Does the 400-day cookie happen automatically once a server container is live?

No. It requires the server to run on the site's own domain. On Google's default cloud domain, the server can still only set the same JavaScript cookies it was meant to move away from, capped exactly as before in Safari.

Does turning on server-side tracking change what counts as GDPR compliant?

No. Consent requirements attach to storing or reading information on the visitor's device, not to which server processes it afterward, and consent mode still gets configured in the web container regardless of what runs behind it.

If a current setup mixes client-side and server-side pieces and nobody has checked whether the domain, the deduplication keys and the consent configuration actually line up, request a free tracking audit and we will tell you plainly what changes and what does not for that specific account.