Why does my purchase event fire again when the page is refreshed?

Purchase fires again on refresh · architecture

Why your conversion data was wrong in the first place — Purchase fires again on refresh

Fixing this specific fault is worth doing. But it is worth understanding why it happened, because the same underlying weakness produces a different symptom every few months — and the reason your conversion data is wrong is almost never the tag itself.

1. 1

   Your conversion depends on a browser that is being restricted on purpose

   A browser-side tag has to survive the page loading, the visitor staying, the script executing and the request leaving. Every one of those is now contested. The order in your database is certain; the browser event reporting it is not, and that gap is where wrong numbers come from.

2. 2

   Safari caps the cookie your attribution depends on

   Intelligent Tracking Prevention limits cookies written by JavaScript to seven days, whatever expiry you set. Any customer who takes longer than a week to decide comes back as a stranger, so the sale is recorded and credited to nobody. A cookie your own server writes in an HTTP response is not subject to that cap — which is the single largest practical difference between browser-side and first-party server-side tracking.

3. 3

   Ad blockers remove the tag before it can run

   A blocked pixel does not error, retry or warn anyone. The visitor buys, the order lands in your store, and no platform ever hears about it. First-party events sent from your own subdomain aren't filtered the same way, because they are not a third-party request.

4. 4

   Consent banners stop tags, sometimes when they didn't need to

   Where consent is genuinely required, losing the event is correct. What is not correct — and what we find repeatedly on US-majority accounts — is an EU-style prior-consent banner applied to every visitor, discarding conversions no law asked you to discard. A server container enforces the real decision at the container rather than hoping each vendor script honours a flag.

5. 5

   The checkout can end somewhere your tag isn't

   Wallets and hosted payment pages can be abandoned after the money moves. The customer paid; the confirmation page never rendered; the browser event never fired. Sending the purchase from the order record instead means the conversion arrives whether or not anyone came back to your site.

6. 6

   What that adds up to

   Each of these is a separate route to purchase fires again on refresh, and they compound. First-party server-side tracking doesn't patch them one at a time — it moves the money event off the browser entirely, so the order in your backend is what gets reported. That is why we reconcile against your own order records and put 95%+ accuracy in writing: with the event sourced from the order, the number is checkable rather than hopeful.