Sep 11, 2026 · Germán Muñoz Moreno, Co-founder
How to tell if the same purchase is being counted twice
I think my conversions are being counted twice. How do I check, and how do I prove it?
Double counting is the suspicion everyone arrives at eventually, usually after adding up what the platforms claim and finding a number larger than the sales they made. The suspicion is often right. What makes it hard to act on is that three genuinely different problems share the name, and each needs a different check, in a different place, with different evidence.
Three problems that look the same on a chart
The first is one platform counting your event twice, because you send the same purchase from the browser and from the server and it could not tell they were the same. The second is two platforms each claiming the same order, which is not an error by either of them. The third is your own reporting filing one order under two channels.
They produce the same symptom, an inflated total, and they have nothing else in common. Working out which one you have is most of the job.
One: the same platform counting your event twice
This is the one that is genuinely a defect, and the good news is that the platform will usually tell you.
It happens because sending purchases twice is correct practice. The browser event is lost whenever an ad blocker, tracking protection or an off-domain checkout gets in the way, so most stores also send the purchase server-side from the order webhook. What makes the redundancy safe rather than harmful is that both events carry the same event ID, which is the key the platform uses to collapse them into one.
When the two sides generate their IDs independently, or one omits it, the platform receives two purchases with no way to know they are the same. In Meta, look at the Purchase diagnostics in Events Manager for redundant purchase events, and read the deduplication feedback, which reports what share of events were actually collapsed and on which key. That second one is the stronger check: it confirms the mechanism is working rather than just flagging when it did not.
Google has no equivalent event-ID safety net for offline conversion uploads, but it does reject a repeated order id, and those rejections appear in the upload diagnostics. A run of duplicate-order-id errors is your latch failing, which usually means order webhooks are retrying and nothing is recording that the sale was already sent.
Two: two platforms claiming the same order
A buyer clicks a Google search ad on Tuesday, sees a Meta ad on Thursday, and buys on Friday. Both platforms have a defensible claim on that one order, and both report it as one conversion. Neither can see the other's touch, so neither is capable of adjusting for it.
This is not a bug to be fixed on either platform. It is a property of how the platforms are built, and it becomes a counting error only at the moment you add them together. That moment happens constantly, in every spreadsheet that lists platforms as rows and totals the column.
Three: your own report splitting one order into two
This is the easiest to miss, because nothing rejects it and no diagnostic exists for it. Two ways it happens: a multi-touch model assigns fractional credit and something downstream rounds or reads the fractions as whole orders, or a channel taxonomy puts the same order under two labels because it matched two rules.
The check is arithmetic and it takes a minute. Your per-channel order counts must sum to your total order count, with an explicit line for the orders that could not be attributed to anything. If there is no such line, that is worth investigating on its own, because unattributable orders exist in every dataset and a report that never shows them is hiding them somewhere.
The test that proves the second kind
The first and third kinds are found by inspection. The second cannot be, because both platforms are reporting correctly and neither has the information that would reveal the overlap. It needs an outside reference, and there is exactly one available.
A platform can legitimately resolve a buyer you never saw: someone who blocked your pixel, someone who converted from a view without ever clicking. So a platform claiming more than you measured is not by itself evidence of anything. But no platform can resolve an order that does not exist. Your store's settled order count for a window is a hard ceiling on what every platform combined can truthfully claim about it.
Take a window. Total what every connected platform claims for it. Compare against the orders your store actually settled in the same window. Below the ceiling, nothing is proven and the honest description is that part of the claim is unverifiable. Above it, the excess is arithmetic that cannot be true, and it is provable without knowing which platform caused it.
Four things that will break the test
Each of these produces a confident wrong answer, which is worse than no answer.
Use the purchase action, not a platform's total conversion count. Google's conversions metric sums every configured conversion action, so comparing it to orders measures your configuration and can show several hundred percent on a perfectly healthy account.
Pair each ad account with the stores it actually advertises for. Comparing a whole ad account against one brand out of several is the most common cause of a ceiling that looks broken without being broken.
Do not run it on a window whose last days are still open. Settlement lag alone will manufacture impossible sales, because the platform has already claimed conversions for orders your store has not finished recording.
Turn off any new-customer filter. It narrows your side of the comparison to first-time buyers while the platform side stays whole, which manufactures a gap out of nothing.
What to do with the answer
If you find the first kind, fix the event ID and the latch, and expect your reported conversions to fall. That fall is the correction, not a loss.
If you find the second kind, you have proven that the sum of your platform reports is not a sales figure. The fix is not to argue with a platform. It is to stop summing them and anchor your reporting on the orders instead, so every platform number is read as a claim about a list that exists rather than as a row to be added up.
Common questions
Where do I find redundant purchase events in Meta?
In Events Manager, open the dataset, go to the diagnostics for the Purchase event, and look for the redundant purchase events entry. It appears when Meta received a browser event and a server event it could not collapse. Meta also publishes deduplication feedback per key, which tells you what share of your events were actually collapsed and on which identifier, and that is the stronger signal because it confirms the mechanism rather than just flagging the symptom.
Is it double counting if Meta and Google both claim the same order?
Not on either platform's part. Each one saw a real touch inside its own window and reported it correctly; neither can see the other. It becomes a counting error only when you add their numbers together and read the sum as total sales, which is exactly what a spreadsheet that lists platforms in rows invites you to do.
My platform claims are below my order count. Does that mean nothing is wrong?
It means nothing is provably wrong. Under the ceiling, over-counting and honest reporting look identical from the outside, because a platform can legitimately resolve a buyer you never saw. What you can say is how much of the claim is verified against a real order and how much is not, which is a more useful sentence than a verdict either way.
Can the same order be counted twice inside my own dashboard?
Yes, and it is the easiest kind to miss because nothing rejects it. It happens when a multi-touch model assigns fractional credit and something downstream reads those fractions as whole orders, or when a channel taxonomy files one order under two labels. The check is arithmetic: your per-channel counts must sum to your total order count, with an explicit line for whatever could not be attributed.
Does the ceiling test work on a single day?
No, and running it that way is the most common way to get a false positive. Platforms report on the date of the click or impression while your store reports on the date of the order, so a single day compares two different bases and can break a ceiling the whole window does not break. Use a window long enough to absorb the lag, and exclude days that have not settled yet.