The 5x ROAS that was really 2.5x

Short answer: if two tools on your store both report the same purchase, and neither one tells the platform they are describing the same sale, the platform counts it twice. Your revenue line doubles, your return on ad spend doubles, and not one extra order was placed. The fix is a shared order ID on every event, and you can check whether you have it in about two minutes.

How it shows up

A practitioner posted the whole diagnosis on X in March 2026, in six lines: “5x ROAS on the dashboard. But revenue doesn’t match. Usually, it’s duplicate purchase events. Shopify pixel + GTM both fire the same purchase. Meta counts both. ROAS doubles. Check: Events Manager, Purchase, Deduplication column.”

What that looks like from the owner’s chair is less tidy. A Shopify store owner posted describing the symptom without the cause: Meta said performance had been consistent and purchases looked solid on their end, but in Shopify both total store sales and marketing-attributed revenue were down, and not slightly. There was a clear mismatch between what Meta said it delivered and what the store was showing.

He was looking for a media-buying answer to a plumbing problem. That is the ordinary case. The number is wrong in a way that flatters you, so nothing prompts you to check it.

Why it happens so easily

Nobody installs double tracking on purpose. It accumulates.

• You installed the platform’s own app or plugin, then later added a tag manager, and both are firing purchase.
• Your store platform has a built-in integration that was switched on once and forgotten, and your agency added their own tracking on top.
• You added server-side sending to recover the events browsers were blocking, which is the right move, but nothing links the server event to the browser event.
• An agency changed hands and the new one installed its own stack without removing the old one.

The third case is the cruel one. You do the correct thing, coverage genuinely improves, and the number inflates at the same time, so you cannot tell how much of the lift was real.

What a duplicate actually costs you

The obvious cost is that you are reading a number that is too high, and you will spend against it.

The second cost is worse and slower. The platform optimises toward whatever it counts as success. If one purchase looks like two, the algorithm treats that path as twice as valuable as it is, and pushes budget toward it. You are not only misreading performance, you are actively training the system on inflated feedback.

The third cost is the one that damages relationships. When your platform dashboard says one thing and your bank says another, and nobody can explain the difference, trust in the whole reporting chain goes, including the parts that were accurate.

The fix, in one sentence

Every purchase event carries the same order ID, whichever path it travels, so the platform can recognise two arrivals as one sale.

That is the whole mechanism. The browser event and the server event both say “order 10432”, the platform matches them, counts one, and keeps the richer of the two. Saudi agencies name a missing shared ID as one of the three most common faults on Salla and Zid stores.

Two details decide whether it works in practice:

• The ID has to be the real order ID from your store, not a randomly generated value per event. Two random values do not match.
• It has to be present on both paths. An ID on the server event alone changes nothing, because the browser event still arrives anonymous.

Where MIQAS comes in

MIQAS takes the order from its source, your store or your point of sale, and sends it server to server to Meta, TikTok, Snapchat, X and GA4, carrying your own order ID on every event so each platform can collapse the duplicate itself.

Because the order is read at the source rather than inferred from the browser, the ID is the one your store actually issued, which is the part most setups get wrong.

For the browser side, we give you a ready-made snippet for the order confirmation page, written separately for Shopify, Salla and Zid, so both paths carry the same ID rather than only the one we control.

And the Conversion Check with the Ad Claims Audit tool, on Growth and above, exists for exactly this question: it sets what the platforms claim against the orders your store actually recorded, so a doubled number has somewhere to be caught.

Check yours in two minutes

• Open Events Manager, choose Purchase, and find the deduplication column. If it shows no deduplicated events while you are sending from both browser and server, nothing is being matched.
• Take yesterday’s purchase count in the platform and yesterday’s real order count in your store. A platform number that is close to double is the classic signature.
• List every tool that can fire a purchase on your store: platform plugin, tag manager, store-native integration, your agency’s script, your attribution tool. If that list has more than one entry and no shared ID, you have found it.

Common questions

Should I just remove one of them? Not blindly. Browser and server sending are complementary, and the server path is the one that survives ad blockers and privacy settings. Link them with a shared ID rather than deleting the one that is doing useful work.

My numbers will drop once I fix it. How do I explain that? Say plainly that the earlier number counted some sales twice and the new one counts each sale once. The drop is the correction, not a decline in performance. Keep a screenshot of the before and after so the change is documented rather than argued about later.

Does this apply to leads too, not just purchases? Yes. Any event that two tools can fire, including lead and add-to-cart, can duplicate the same way.

A doubled number is not a small reporting nuisance. It is the difference between a channel you should scale and a channel you should cut, and every week you leave it in place, the algorithm is learning from it.