Count the sale once, with the server's truth
Adding server-side tracking without a de-duplication key is worse than not adding it at all. Set the real number of orders and watch four common setups report four different answers.
if (property, dedup_key) already exists → merge, else → insert
Send the purchase from the browser and from your backend, both carrying the same dedup_key (the order id). The pair collapses into one conversion marked confirmed by both sides, with the server's amount as the truth.
Without the key, everything that survives the browser is counted twice — the most common broken server-side setup we see.
—
—
// browser — fast, contextual, blockable
{ "source": "client", "category": "purchase", "name": "purchase",
"value_cents": 12900, "dedup_key": "order_10482" }
// your backend — authoritative, unblockable
{ "source": "server", "category": "purchase", "name": "purchase",
"email": "hello@example.com", "value_cents": 12900,
"dedup_key": "order_10482" }
// result: ONE conversion, source: "both", value from the serverThe key must exist before either event fires, be identical on both sides, and be unique per fact. Order id qualifies; a timestamp does not. Read the de-duplication guide.
Frequently asked questions
What is a de-duplication key?
A string that both the browser and your server can derive independently for the same fact — usually an order id, a subscription id or a submission id. When both events carry it, the attribution system merges them into one record instead of counting two conversions.
Why send the same event twice on purpose?
Because the two sides answer different questions. The client event tells you what the person did and when, in the context of a session. The server event confirms it actually happened and carries information the browser never had. Sending both and de-duplicating gives you accuracy and context at once.
What happens without a dedup key?
Every conversion that survives the browser gets counted twice. Revenue looks inflated, CPA looks excellent, and nothing reconciles against your payment processor. It is the most common broken server-side setup.
What share of client events actually get blocked?
On paid traffic, 20–30% is typical: ad blockers, tracking protection, privacy browsers, corporate networks and in-app webviews. Organic and direct traffic is usually better; paid social is usually worse.
Is server-only good enough?
The count will be right, but you lose the path — no pageviews, no clicks, no landing pages, no sense of what the person did before converting. You will know how many, not why.
What makes a good key?
It must exist before the event fires, be identical on both sides, and be unique per fact. Order id is ideal. A timestamp is not — the two sides will never agree to the millisecond.
De-duplication is built in, not bolted on.
Flowsk merges client and server events on your key automatically, marks the conversion confirmed by both sides, and keeps the server's amount. You send both; we count once.
More free tools
Same deal — instant, no signup.