The symptom
You have seen the diagram. The browser sends the event to your own server, your server sends it on to Google and Meta, better numbers come back. It is on every vendor page, it is not wrong, and it leaves out the parts that decide whether it works for a specific client.
So the project ships and the results are uneven. One account picks up the recovery it was promised. Another, same tool and same tags, barely moves, and Safari still looks like a slab of traffic that arrives and never converts. Nobody on the call can say why, because the diagram has two boxes and the difference lives inside them.
Before scoping this for a client, follow one conversion the whole way and be honest at each hop about what changes.
Why the two-box diagram misleads
The first hop is still a request from the browser
Google's own description of a server container starts on the device, not on the server: the server "receives web requests from the user's device" and turns those requests into events. Something in the browser still fires, and that request still has to leave the machine.
That is where a large share of today's loss already happens. Ad blockers strip 30 to 40% of events, and a request that never leaves is a lost event whether it was addressed to Google's domain or to yours. Moving the destination onto your own domain changes what a filter list has to recognise. It does not take the browser out of the chain. Anyone selling a server setup as immunity is selling something the architecture does not provide.
Durability comes from the cookie, not from the server
The identifier is the part that genuinely changes, and the reason is narrower than most write-ups suggest. Safari has capped cookies written by page JavaScript since February 2019: WebKit's own note says "persistent cookies created through document.cookie, are capped to a seven day expiry", and only those. When WebKit later extended the seven-day rule to other script-writable storage, it listed IndexedDB, LocalStorage, SessionStorage and service worker registrations. Cookies set in an HTTP response by a server are a different category, and can be given a long life, up to the 400 days that Chrome has enforced as the ceiling since version M104.
So the gain is not "the processing happens on a server". It is that a host on your own domain gets to set the cookie in a response. Google is specific about the condition: "your tagging server and your website have to run on the same domain" to get more durable cookies, and on the cloud provider's default domain the same container runs in a third-party context and can only set JavaScript cookies. Same container, same tags, different cookie lifetime, decided by DNS.
There is a condition underneath that condition, and it explains most of the disappointing Safari results. Safari looks at how the subdomain resolves. Since November 2020, WebKit "detects third-party CNAME cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days", where that means a first-party subresource resolving through a CNAME that points somewhere other than the site's own domain and other than whatever the main site itself resolves through. Point the client's measurement subdomain at a hosting vendor with a CNAME and Safari treats those cookies the old way. Resolve it to infrastructure the site genuinely uses and it does not.
Which makes "will this fix Safari" an honest it depends: on how one DNS record is configured, which is a choice somebody makes during setup, not a property of going server-side.
Each destination receives its own version of the event
The outbound side is not one pipe either. Every platform has its own API with its own rules, and Meta is the clearest illustration of why this is work rather than a checkbox. Meta expects a redundant setup, browser and server both reporting, and then deduplicates the pair. Meta's documentation is blunt about the keys: the pixel's event ID must match the Conversions API event ID, and the event names must match too. Its fallback matching method carries a window, server events are not discarded if no browser event arrived in the previous 48 hours.
Get those keys wrong and two reports of one purchase are read as two purchases. A project meant to recover conversions inflates them instead, which is worse than the problem it replaced because it survives review. So the figure landing in the client's report after a migration is not automatically truer. It is differently produced, and it has to be reconciled against something the client already trusts before it goes in a slide.
The consent obligation does not move to the server
The last assumption worth retiring is that processing on your own infrastructure means less to ask permission for. The regulator's text does not read that way. In Guidelines 2/2023 on the technical scope of Article 5(3), adopted in October 2024, the EDPB states that "the fact that the receiving entity might not be the entity instructing the sending of information does not preclude the application of Article 5(3)". Reading something from the visitor's device is the trigger. Which server ends up holding the result does not change that.
Google's own product reflects it. Consent mode is configured in the web container, with a banner on the site as a prerequisite, because that is where the choice is made. The server inherits the decision, it does not get to reopen it.
What good looks like
Read end to end, a setup that performs comes down to three things rather than a tool. The collection endpoint sits on the client's own domain and resolves in a way Safari accepts as first-party. Each destination gets one agreed event definition with deduplication keys that hold, so recovery does not become double counting. Consent is captured at the front and carried through, so the compliance position is unchanged.
That is the work Archon Signal does: the routing, the domain and cookie configuration, the per-platform event definitions, and the reconciliation afterwards so the client's report can be defended. Done properly it typically brings back 15 to 40% more conversions than the browser-only setup it replaced, against a baseline where 15 to 30% of conversions are consistently uncaptured.
It does not arrive at everything, and nobody should promise it will. Refused consent stays refused, a first hop that gets blocked stays blocked, and networks drop requests. A strong setup lands somewhere around 95% of events, and that is a ceiling rather than a target. Whether the remaining gain justifies the project for a particular client is a different question, which we answered separately in whether server-side tracking is worth it.
Frequently asked
Does server-side tracking get past ad blockers?
Partly, and not by design. The browser still has to reach your endpoint, so anything blocking that request blocks the event as before. What changes is that the request goes to a host on the client's own domain rather than a widely recognised third-party one, which a generic rule catches less easily. Treat it as a reduction in loss, not an exemption.
We already run a tagging server. Why is Safari still thin?
Usually the domain, not the tool. If the measurement subdomain resolves through a CNAME to the hosting vendor, WebKit's rule caps those cookies at seven days, which puts you back where you started for returning Safari visitors. It is a DNS and hosting question, and it is worth checking before anyone concludes the migration failed.
Will the client's numbers jump the day we switch?
They will move, and not upward on every metric. Recovered events push conversions higher, while deduplication and stricter event definitions can push a previously inflated number down. Agree beforehand which figure is the reference, and report the change as a correction rather than growth.
Does this let us collect data we could not collect before?
No, and it should not be sold that way. The consent decision is made in the browser and applies regardless of where the processing happens. What a server-side setup improves is how much of the consented traffic actually gets measured, which is a different thing and an easier one to defend.
Is this more expensive than what we run now?
Hosting is rarely the deciding line, the ongoing ownership is. We broke the components down in what server-side tracking really costs, including the part most quotes leave out.
If you want to know what a specific client setup would actually recover before committing to a migration, that is what the free tracking audit measures.