Server-side vs browser tracking
Browser tracking is the baseline and it has to be right before anything else is considered. Server side tracking is the fix for a specific symptom: the ad platforms are recording noticeably fewer orders than your store, and your bidding is being steered by incomplete data.
Run the comparison first. Take a full month, count the orders in your store, and count the purchases each ad platform recorded for the same window. A small gap is normal, because blockers, private browsing and cookie choices always lose some events. A large gap means the bidding is learning from a fraction of what happened, and adding a server side connection usually recovers part of it.
Do not treat this as an upgrade to buy at launch. A store with correct browser tags and modest spend gains little. A store spending seriously on automated bidding, with a visible order gap, gains a lot.
Choose
Browser tracking
when
- You are setting up a store and need conversion data working this week
- Ad spend is modest and the recorded order gap is small
- You need page level behaviour, not just purchases: views, add to cart, scroll
- There is no developer available and the platform app handles the tags
- You are still verifying that order values and currencies are recorded correctly
Choose
Server-side tracking
when
- Ad platforms consistently record far fewer orders than your store did
- Automated bidding is running and poor data is visibly costing you money
- You need to send offline or delayed events, such as a phone order or a refund
- You sell in markets where cookie consent removes a large share of browser events
- You want order values sent from the source of truth rather than from a page script
| Criterion | Browser tracking | Server-side tracking |
|---|---|---|
| Cost | Included with the platform apps and tag manager | Hosting or a paid connector, plus developer time to build and maintain |
| Setup effort | Install, then verify each event fires once with the right value | Server endpoint, event mapping, hashed customer data, and deduplication rules |
| Time to signal | Immediate, events appear as they happen | A week or two to confirm matching improved without double counting |
| Control | Limited by browsers, blockers and consent choices | You choose what is sent, when, and with which identifiers |
| Best for | New stores, modest spend, behavioural analytics | Accounts leaning on automated bidding, or with a large recorded order gap |
| What can go wrong | Blocked scripts silently lose events and bidding degrades without warning | Missing deduplication counts every order twice and flatters every report |
| How we measure it | Recorded purchases against store orders for the same period | Match quality and the size of the gap after the change, plus duplicate checks |
When both apply
Running both is the normal end state, not a choice between them. The browser sends the event, the server sends the same event with a shared identifier, and the platform keeps one of them.
Deduplication is the whole job. Give every purchase one event identifier used by both paths, then check a week of orders against recorded conversions to confirm the totals did not inflate. A setup that quietly doubles your conversions is worse than the gap you started with, because every bid and every report is then built on it.
Questions
Related
Your plan is free.
A person reads it. You keep the plan. No logins, no call first.