Meta counts your purchases twice: where the duplicates come from and how to find them in 15 minutes

Key facts (as of 2026-10-29)

• Meta merges Pixel and server events when they have the same name and the same identifier (eventID / event_id) and arrive within 48 hours.
• Without a shared identifier the same order is counted twice or more.
• The alternative method (fbp / external_id) usually works only when the browser event comes first.
• Basketly sends one purchase to one dataset once; duplicates from other routes need a shared identifier or switching one route off.
• Meta accepting an event is not proof of optimisation or of the purchase being attributed to an ad.

The shop has 22 orders and Meta shows 60 purchases. Shop owners describe exactly this: "We’re using the native Shopify integration and the purchase events are massively overblown. Like 3x." (r/FacebookAds, thread). Or, in a Polish agency's words: a simultaneous Pixel, plugin and GTM Server-Side send the same event without a shared event_id, and the result is duplicated conversions and "reports nobody trusts" (KC Mobile, in Polish).

Below: where duplicates come from, how to count them and how to fix them. If your problem is the opposite (Meta shows less than the shop), start with Why does Meta show fewer purchases than my shop.

Four sources of duplicates

1. Several routes sending the same purchase

A Pixel pasted into the shop code, a shop-platform plugin, a tag manager and GTM Server-Side can each send Purchase separately. Meta gets three events for one order. This is the most common case in shops that kept adding tools over time.

2. No shared identifier

Even when you want two channels (Meta recommends the Pixel alongside the Conversions API), two things must match: the Pixel's eventID equal to the API's event_id, and the same event name. When the browser and the server pick the identifier independently, the pair does not match. One Reddit user put it: "constant problem with event deduplication as capi and browser ID are always different" (thread).

3. Refreshing the thank-you page

The purchase code sits on the thank-you page. The customer refreshes it, returns from a tab or opens the link from the email, and the event fires again. Agency guides list this as a separate cause of "double Purchase".

4. Two Pixels at once

An old and a new dataset in the shop code, or a Pixel added once by a plugin and once by hand. Each sends its own event, and deduplication between two Pixels with different identifiers will not work.

How to count whether you have duplicates

1. Pick one full day at least two days ago. Count paid orders in the shop.
2. Open Events Manager, your dataset, the Purchase event, and see how many events were received that day and from which sources (browser, server).
3. Result: clearly more events than orders means duplicates. Fewer than orders is a different problem, covered in the article on missing purchases.
4. The deduplication tab. In the event details Meta shows the share of deduplicated events. Higher is better, and a warning appears when it is too low. Meta describes a low share as "Low Overlap": you send non-unique deduplication keys, or a key from only one source.
5. Inspect the identifiers. For one order, check which event_id the browser event and the server event carry. Different ones, or one missing, is the cause.

The fix in three steps

1. List every route Purchase travels: the Pixel in the code, a plugin, tags, GTM Server-Side, a custom adapter, a tool such as Basketly. For each, note whether it sends from the browser or from the server.
2. Keep one route per event, or join them with an identifier. If you need two channels, set the same event name and the same identifier built from the order number in both, e.g. purchase_ORDER-123. In the Pixel you pass it as eventID, on the server as event_id. Repeats of the same order must get the same identifier. Full description: Pixel and Conversions API event deduplication.
3. Check after a few days. The deduplication tab and the comparison of events with orders. If the shop turns out to have two server integrations, keep one.

Do not try to correct data backwards: duplicates already counted stay in the reports. What matters is that new purchases are counted once from now on.

How to avoid a duplicate at the next change

Duplicates usually return after a new tool is added. Before you switch on another plugin, tag or integration that sends purchases, ask three questions:

1. Does it send Purchase, and if so, from the browser or from the server?
2. Which event identifier does it set, and can it be made the same as on the other routes?
3. Can I switch the purchase off in one of the existing tools instead of adding another channel?

After each such change go back for two days to comparing events with orders. It takes five minutes and saves weeks of reports you would later have to explain to a client or a boss.

How Basketly avoids duplicating purchases

In Basketly one purchase is one send to a given dataset. Two mechanisms guard it:

• The same purchase is accepted once. An event is recognised by source, order identifier and status. An order read a second time (for example at the next shop read) does not create a second purchase.
• The same send is not created twice. The queue will not take the same combination twice: dataset, event name, event identifier and mode (test or production), even from two connections to the same dataset. Retries after a network error use the same identifier, so Meta can deduplicate them.

Shop purchases have a stable identifier built from the order number (e.g. shoper-order-<number>). You see it in System → Events → Send history (an optional column with the event identifier). That makes it easy to compare with what your Pixel sends.

One thing Basketly will not do for you: it does not change the Pixel code or the shop plugin. If the Pixel and Basketly both send the same purchase, Meta will merge them only with a shared name and identifier. If your Pixel does not let you set eventID, it is more honest to send Purchase from one side only: usually from the server, leaving the Pixel for browser events (product view, add to cart).

Useful after the change: Conversions → Purchase balance shows how many purchases Basketly sent and had accepted, day by day, and Self-check → Sending to Meta compares your dataset's statistics (from Meta) with Basketly's sends. Twice as many events at Meta as in Basketly hints that purchases flow through yet another channel. We describe this in the purchase balance article.

What Basketly will not fix

• Duplicates from other people's channels. Basketly deduplicates what it sends itself. Events from a plugin, a tag manager and GTM go alongside it.
• Exactly-once delivery. The queue works on an at-least-once model, and Meta has the last word in deduplication.
• Duplicates already counted. Past reports stay as they were.
• Attribution to an ad. Meta accepting a purchase is not proof of optimisation or attribution.

Next step

Do steps 1 and 2 of the "How to count" list for yesterday. To see Send history with event identifiers, open the demo. To connect your own shop, create an account; plan limits are on the pricing page. How sending from the server works is on the Meta Conversions API page.

Sources

• Meta for Developers: Deduplicate Pixel and Server Events (event_id + event_name, 48-hour window, the fbp / external_id method and its limits)
• Meta for Developers: Verifying Your Setup (deduplication tab, "Low Overlap")
• Meta for Developers: Server Event Parameters (event_id recommended for deduplication)
• KC Mobile: How much the Conversions API costs on Facebook (quote on duplicated conversions, Polish)
• r/FacebookAds: thread on inflated purchases (Shopify), thread on differing CAPI and browser identifiers