Server-side vs client-side tracking
Client-side tracking is enough when your conversions happen on a page the visitor reliably reaches, your traffic isn't heavily Safari or iOS, and your reported numbers already reconcile against your own records. Server-side earns its cost when one of those stops being true — a checkout that loses the confirmation page, a consideration window longer than seven days, or a measured gap between your orders and what the platforms report. The deciding question isn't which is better; it's whether you have a measured gap.
Free30 minutesNo obligation
Server-side vs client-side · what breaks
What people get wrong about this choice — Server-side vs client-side
- 01
Treating it as an upgrade rather than a fix
Server-side solves specific failures. Without one of them, it's cost without benefit.
- 02
Assuming it makes bad events good
Moving a wrong event to a server produces a wrong server event, delivered more reliably.
- 03
Believing it's a one-way switch
The right setup runs both, deduplicated. Removing the browser path costs you signals you were getting for free.
Server-side vs client-side · the fix
Choose client-side when
Your numbers already reconcile
If orders and reported conversions agree within a few percent, there is nothing here to fix.
Your checkout can't lose the event
A conventional confirmation page the customer reliably lands on.
Nobody owns infrastructure
A server container needs someone who notices when it breaks. Without that, it degrades quietly.
Server-side vs client-side · architecture
Side by side, on the criteria that actually decide it
Six criteria that actually change the decision. Feature lists don't.
- 1
Reliability of the money event
Client-side depends on the page loading, the visitor staying, the script running and the request leaving. Server-side depends on your order record existing.
- 2
Cookie lifetime
Safari caps JavaScript-set cookies at 7 days. A cookie set in an HTTP response from your own subdomain isn't subject to that cap.
- 3
Ad blocker exposure
Client-side requests to platform domains are blocked by common lists. First-party endpoints on your own subdomain generally aren't.
- 4
Control over what leaves
Client-side sends whatever the tag was built to send. Server-side lets you strip parameters before dispatch, which matters in regulated verticals.
- 5
Setup and maintenance
Client-side is faster to stand up and easier for anyone to change. Server-side is infrastructure and needs an owner.
- 6
Cost profile
Client-side has no running cost. Server-side has a build cost plus hosting, which scales with your traffic.
Server-side vs client-side · diagnose
Limitations of both — Server-side vs client-side
Neither option is free of them. These are the ones that change the decision rather than the ones that sound impressive.
- 01
Server-side doesn't fix correctness
A mis-defined event stays mis-defined. Correctness has to be established before durability is worth paying for.
- 02
Client-side signals are still valuable
Browser cookies improve match quality and attribution. Turning the browser path off entirely usually makes things worse, not better.
- 03
Server-side needs an owner
A container nobody monitors degrades. If no one will notice a break, the build's value decays.
- 04
Neither escapes consent
A denied visitor should not be measured either way. Server-side changes where consent is enforced, not whether it applies.
Server-side vs client-side · prove
How to check the choice was right — Server-side vs client-side
Same test either way, run on your own account rather than on a vendor's demo.
Source of truth
your own order, CRM or booking records
- The gap measured and segmented by browser before anything is built.
- First-party cookies confirmed persisting past seven days in Safari on a real device, where server-side was chosen.
- Deduplication verified before any legacy path is removed.
- Consent verified by denying it and confirming nothing leaves.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, because a setup that holds once and drifts is the harder failure.
Server-side vs client-side · free audit
What we check in the free audit
- Server-side doesn't fix correctness
- Client-side signals are still valuable
- Server-side needs an owner
- Neither escapes consent
Checked against
your own order, CRM or booking records
Free30 minutesNo obligation
Server-side vs client-side · when not to buy
Where we're not neutral — Server-side vs client-side
We build server-side setups for a living, so read the next four points knowing that.
- We sell server-side implementations. That gives us an obvious interest in recommending them, and you should weigh what follows accordingly.
- The honest case for client-side: it's free, it's fast to change, anyone on your team can maintain it, and for a store whose numbers already reconcile it is completely sufficient. Plenty of businesses do not need what we sell.
- Our free diagnosis exists partly because of this. We measure your gap first, and if it's small we tell you so — that outcome costs us the sale and it happens regularly.
- The one thing we'd argue regardless of who builds it: measure the gap before deciding. Buying server-side without a measured gap is buying a solution to a problem you haven't confirmed you have.
Server-side vs client-side · what we deliver
Choose server-side when
There's a measured gap
Orders and reported conversions disagree, and the gap is worse in Safari.
Wallet payments skip your confirmation page
Shop Pay and PayPal can be abandoned after payment. Those orders exist and reach no platform.
Your consideration window exceeds seven days
Safari caps JavaScript-set cookies there. Server-set first-party cookies aren't subject to it.
The conversion happens with no browser
A renewal, a refund, a call outcome, a CRM stage change.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies your existing browser-side setup. Honest about its ceiling: it fixes what's broken today, and the browser can still lose events tomorrow.
- Root cause fixed, not worked around
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, so the browser can no longer lose them.
- First-party server container on your own subdomain
- Conversions from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, for advertisers whose spend makes an attribution leak more expensive than the build.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring so the next break surfaces in days
FAQ
Server-side vs client-side questions, answered
Only if you have a measured gap between your own records and what the platforms report, and that gap is worse in Safari. Without that, client-side is doing its job.
You should. Both paths deduplicated on a shared event ID is stronger than either alone — the browser adds match signals the server can't produce.
Requests to a first-party subdomain are generally not on blocklists, so more events arrive. It's an improvement, not immunity — nothing is.
Hosting only, which scales with traffic. Our build is one-time with no monthly fee; hosting is yours, so nobody can hold your data hostage.
Free · 30 min
Find out whether you have a gap worth fixing
WhatsAppFree30 minutesNo obligation
