Why one order gets counted twice, and how to stop it

The same order can be counted twice: once by the script in the shopper's browser and once by your store's server. ROAS then reads better than reality, and nothing in the dashboard says so.

The fix isn't to remove one of the two paths. The fix is a shared event ID between them.

What each path sees

Hybrid tracking sends the event down two deliberate routes. It isn't a primary route with a backup. Each one sees something the other can't.

The browser knows the session: where the visitor came from, the click ID in the URL, and the pages they opened before ordering.

The server knows the order is real, and it knows things that never reach the browser at all: the confirmed total, the payment status, and the customer record behind it.

When both arrive and get matched, you get one event carrying more match data than either path could hold alone. When both arrive unmatched, you get two events.

Where deduplication breaks

The mechanism is simple: both paths stamp the same event ID on the same order. The platform receives two messages, sees one ID, and keeps one event.

And that's exactly where it breaks. If each path generates a different ID, which happens often when one party installs the pixel and another wires up the server, nothing gets deduplicated. The platform has no way to know that Purchase from the browser and Purchase from the API are the same sale.

Illustrative figures.

The third row is the dangerous one, because it looks like the tooling started working better than before.

The check that catches it is quick: take one fresh order and look in the platform's test tools to see whether two events arrived under one event ID or under two. If the IDs differ, every order since you connected the server has been counted twice.

What match quality is measuring

Every platform scores each event on how much match data arrived with it. Meta calls it EMQ, and other platforms have their own names for the same idea.

A low score doesn't mean you did something wrong. It means the event arrived with two or three identifiers when it could have arrived with eight: email, phone, external ID, click ID, IP, user agent, name and city, all hashed before they leave your store.

That score decides whether the platform can tie your sale to a person it recognises. An event it can't match is an event it can't learn from, so it changes nothing about who sees your ads next.

This is where the server path earns its place. The browser sends what the page can see. The server sends what the order record holds, which is more in most cases.

In Flowfy, hybrid delivery and event deduplication are live: the browser event and the server event for one order carry a single ID. On the match quality side, what has shipped is the delivered-events log, where you can see what went out to each platform and what came back, event by event. An aggregated score per destination, tracked over time, hasn't shipped.

Why over-counting is riskier than under-counting

Under-counting is visible. Your store's orders exceed platform conversions, someone notices and asks.

Nobody complains about over-counting. Every campaign beats last month, the account looks healthy, and nobody opens a ticket about good news. Then budget moves toward the campaign that double counts more than the others, which is usually the one running both a pixel and a server connection on the same events.

Common questions

Do I have to remove the pixel to stop double counting? No. Removing it costs you the session signals only the browser sees. The fix is a shared event ID across both paths.

How do I tell whether I'm double counting right now? Compare a full month of your store's orders against the purchase conversions each platform reports. If a platform claims clearly more purchases than you had orders, and you run both a pixel and a server connection, deduplication is the first thing to check.

Does raising match quality change my conversion count? It changes how many of them the platform can tie to a person, which changes optimisation. The number of events you sent stays the same.

Does the customer see any of this? No. Match data is hashed before it leaves your store, and the server path adds no script to the browser.

Check the event ID first

Open your pixel and CAPI setup and confirm both send the same event ID for one order. If they don't, that's the first thing to fix before any budget decision based on ROAS.