Server-side conversion tracking: why the browser is the worst place to count a sale

Almost every store starts by counting conversions in the browser. A script on the thank-you page fires when the buyer lands there, and that becomes the sale. It is easy to set up and it is wrong more often than most people realise.

The problem is not that browser tracking is inaccurate. It is that it is inaccurate in a *pattern*, and the pattern quietly rewrites your marketing decisions.

A conversion recorded in the browser has to survive a long chain of things going right. Any one of them failing loses the sale from your reporting while the money still arrives in your account.

If browser tracking simply lost a flat share of every channel’s sales, it would be annoying but harmless — every channel would shrink together and the ranking would hold.

It does not work that way. Mobile buyers on messaging apps and UPI drop off far more than desktop buyers paying by card. So the channels that send mobile traffic look systematically worse than they are, and the ones that send desktop traffic look better. Act on that and you cut spend on the thing that was quietly working. An undercount you can mentally adjust for; a *biased* undercount will actively mislead you.

The change is smaller than it sounds. Instead of trusting a script in a browser you no longer control, you record the sale from a system that already knows it happened.

When someone taps your short link, a click identifier is set. It travels with them through checkout and is stored against the order. When your backend — or your payment provider’s webhook — confirms the payment, it sends that identifier back with the sale. The conversion is recorded from your server, where nothing can block it. Razorpay conversion tracking walks through this for one specific gateway.

A server-to-server endpoint is a public URL, so **verify the signature** on every incoming call and reject anything unsigned. Otherwise a stranger can invent sales in your dashboard and you will plan a quarter around fiction.

**De-duplicate on the provider’s own id.** Webhooks retry when they do not get a clean response, so the same payment will sometimes arrive twice. Record against the payment id and ignore repeats, or one sale becomes three.

**Send refunds too.** A channel with many orders and many refunds is not the channel it appears to be, and attribution that only ever counts upward will eventually recommend your least profitable audience.

Third-party cookies are gone, tracking protection is on by default in more browsers every year, and the trend runs one way. A measurement approach that depends on a script executing in someone else’s browser gets less reliable over time; one that depends on your own server confirming your own order does not. The wider shift is covered in first-party versus third-party cookies.

The setup is documented on the server-side conversion tracking page, and it is a one-time job.