How a server-side purchase event works
Ordinarily a sale is reported by the shopper’s browser: the confirmation page loads, a script runs, and the purchase is sent. A server-side purchase event moves that job to your own backend. When the order is written to the database, the server itself sends the sale to analytics or an advertising platform, without depending on the shopper’s browser at all.
The mechanics differ by destination. Sending to analytics generally means an authenticated request from your server. Sending to Meta means the Conversions API. Some shops route everything through a server-side tag manager container instead, so one server-side event is distributed onwards. What all of them share is that the sale is reported by a machine you control rather than by a device you do not.
Why it matters
Browser reporting fails often, and always in the same direction — downwards. Ad blockers, privacy settings, tracking protection built into browsers, a customer closing the tab the moment payment succeeds, or a slow phone abandoning the script all remove real sales from your reports. Payment redirects are a particular problem: the shopper leaves for a bank or wallet, and whether they come back through your confirmation page is not entirely in your control.
The consequences reach past reporting. Missing purchases make campaigns look worse than they are, and automated bidding trained on incomplete data will underspend on what actually works. A server that knows the order exists can report it regardless, which is why serious shops move the purchase event server-side even when they leave everything else in the browser.
Where it goes wrong
Double counting is the big one. Turn on server-side reporting while the browser tag is still firing and every order is recorded twice. The fix is a shared identifier — the same transaction ID or event ID on both versions — so the platform recognises them as one sale, which is exactly the mechanism that prevents a duplicate transaction.
Missing context is the second. The browser knows things the server does not: the campaign the visitor arrived from, the device, the referring page, the click identifiers stored in cookies. If the server sends a bare purchase, revenue is recorded but attribution collapses and every sale looks direct. Those values have to be captured at checkout and passed to the backend deliberately.
The third is quieter: a server-side event will happily report test orders, staff orders and fraudulent orders, because the backend does not care who placed them.
How to act on it
Treat it as the reliable path for the one event where accuracy pays for itself, rather than as a rebuild of all your tracking. Send the transaction ID, the value, the currency and the item list from the server, and carry the campaign and click identifiers through from the checkout so attribution survives.
Run both versions in parallel while you test, with deduplication in place, and compare recorded sales against the shop’s own order list until the numbers behave. Exclude test and staff orders explicitly, and send refunds and cancellations from the server too — a backend that reports every sale but no returns is accurate in only one direction. Wiring this up is tracking implementation work, not a setting you switch on.