Synctag Start the check →
TRACKING SPECIALIST — BARIS ASA · LONDON
Synctag
Start the check → TRACKING SPECIALIST — BARIS ASA · LONDON

READING ROOM › SYMPTOM FILES › SYM-011

SYMPTOM FILE SYM-011 FILED 04 NOV 2026 · REVISED 04 NOV 2026

Meta CAPI and Pixel double counting purchases: how to prove it and fix it.

ALSO FILED AS
  • “Meta CAPI and pixel double counting purchases”
  • “Facebook pixel and Conversions API counting purchases twice”
  • “Meta purchases higher than Shopify orders after CAPI”
  • “Meta event deduplication not working”
  • “low deduplication rate Events Manager purchase”
  • “event_id not matching pixel and CAPI”
  • “Shopify Meta app and server-side GTM double purchases”
  • “duplicate purchase events Meta Events Manager”

Baris Asa, tracking consultant, London · Last checked: November 2026

If Meta has shown more purchases than you had orders since the Conversions API (CAPI) went live, the Pixel copy and the server copy of each sale aren’t being merged. Meta merges them only when both carry the same event_id and the same event name, for the same Pixel, within 48 hours of the first copy arriving. The fix is to send the order number as the event ID on both copies, with the event name spelt identically.

On file as F-102 . It usually happens by accident: one tool sends the browser copy, another the server copy, and nobody owns the id that joins them.

A check you can do yourself. In Ads Manager, total Purchases for seven days that ended at least a week ago. Set that against the orders in your shop’s admin for the same days. Meta counts only sales it attributes to an ad, so for most shops its number sits below total orders. At or above total orders is the signal to check further, not proof on its own. The second check confirms it: Events Manager, your Pixel, Purchase, Event Details, Event Deduplication tab. A low-rate warning there, with browser and server both listed, is the fault.

If you can’t read those screens yourself, ask whoever runs your tracking for two things: a screenshot of that tab, and the event ID from one test order as the browser sent it and as the server sent it. Everything below is for them.

Is it really double counting?

Two readings look like double counting and aren’t.

  • The Events Manager Overview. Meta says the Overview shows events received before deduplication. Send every purchase from the browser and the server and the Overview shows roughly twice your orders, even when deduplication works perfectly (Meta: verifying your setup).
  • The last few days in Ads Manager. Ads Manager can date a purchase to the ad click, so recent days keep changing. Judge a closed week.

Meta’s attributed purchases can also differ from GA4 and your shop for reasons that have nothing to do with the Pixel and CAPI, such as view-through credit. That gap is a different question. This note is about one sale reaching Meta twice.

Two readings do point at the fault:

  • The Event Deduplication tab. Events Manager, your Pixel, Purchase, Event Details. Meta says a higher Rate of Events Deduplicated is better and shows a warning when the rate is too low. A warning on Purchase, with both browser and server listed, is the fingerprint.
  • A closed week at or above your orders, starting the week CAPI or a new app went in.

Why does Meta count one sale twice?

Meta matches the copies two ways. Build on the first.

The event ID method: the Pixel’s eventID must equal the server’s event_id, and the Pixel’s event must equal the server’s event_name. Meta keeps the first copy it receives and discards the matching one, provided it arrives within 48 hours of the first (Meta: handling duplicate events).

The fallback: matching on event name plus fbp (Meta’s browser cookie) or external_id (your customer id). Meta says it generally works only when the browser event arrives first. It is not something to build on.

The usual causes are six.

  1. No id on one side. The server sends event_id, the Pixel sends none, or the reverse. A one-sided id matches nothing.
  2. A different id on each side. Each tag generates its own random id, or one side sends order_10482 and the other 10482. Matching is exact. Send the same type as well: the string "10482" on both sides, not a string on one and a number on the other.
  3. The event name differs. Purchase on the Pixel, purchase from the server. Same id, still two sales.
  4. The id isn’t ready when the Pixel fires. The Pixel tag fires before the order number reaches the data layer, so it sends an empty or different id. The signature: some orders count twice, others don’t. This is a timing fault, F-103 , showing up as F-102.
  5. Two senders on the same side. Shopify’s Meta app sending server events while server-side GTM sends them too. Or a Pixel pasted into the theme alongside the app’s. Meta documents merging a browser copy with a server copy. Two copies from the same side are both kept. That is F-101 : switch one sender off.
  6. The server copy arrives late. Meta only merges copies received within 48 hours of the first. A server queue that retries, or a batch that sends purchases days later, falls outside it and counts again.

The reverse also happens: reuse one id across two orders and Meta can merge two real sales into one (setup options). And a high Event Match Quality score doesn’t mean deduplication works. It measures how well Meta matches the event to a person, not whether two copies merged.

Where should the event_id come from on your setup?

From the order, once, and read by both sides. How depends on what sends the copies. If you are still choosing a route, the options are compared in Meta Conversions API setup options.

  • Shopify’s Facebook and Instagram app. Shopify says Enhanced and Maximum data sharing send the purchase through the Conversions API as well as the Pixel (Shopify: Facebook data sharing). Shopify doesn’t document how it sets the event ID, so the Event Deduplication tab is your proof. Don’t add a second server sender on top of it.
  • Server-side GTM. Meta’s guide fires the Pixel tag and the GA4 event tag that feeds the server container on the same trigger, with the same event ID variable in both (Meta: Conversions API for server-side GTM). For a purchase, push the order number to the data layer and read it into that variable. Stape’s guide warns that tags generating their own ids on one trigger can end up with different ones, and says to store the id once and reuse it (Stape: Facebook event deduplication).
  • Your own code. The Pixel takes the id as the fourth argument: fbq('track', 'Purchase', {value: 49.0, currency: 'GBP'}, {eventID: '10482'}). The server sends "event_id": "10482" and "event_name": "Purchase" in the same request as the order.

How do I find the mismatch?

One test order, three places.

  1. The browser copy. DevTools, Network, Preserve log on. Place the order and filter on /tr. Each Pixel hit carries the event ID as eid and the event name as ev. Two /tr Purchase hits with the same Pixel ID (the id parameter) for one order is the two-senders break, not F-102. A second Pixel ID, say an agency’s, is a separate dataset.
  2. The server copy. In server-side GTM Preview, open the Meta tag and read event_id and event_name in the outgoing request. For a direct integration, read your server log or Test Events.
  3. Events Manager, Test Events. In my experience the order shows twice, once from Browser and once from Server, with the same event ID, and one row is marked Deduplicated after a few minutes. Meta generally keeps the copy it received first. No Deduplicated mark means the copies didn’t merge.

The two ids must be the same string. The two names must be the same word, same case.

How do I know it’s fixed?

  • A test purchase shows in Test Events from browser and server with one event ID, one row marked Deduplicated.
  • The Event Deduplication tab shows no warning for Purchase. Meta publishes no target rate, only the warning. Give it a few days of normal orders.
  • For most shops, a full closed week of Ads Manager purchases sits below total orders again.

Sales already counted twice stay counted. The fix shows from the first clean week, not in the history. If server events don’t arrive at all, that’s a different job: Meta CAPI server events not showing.

Common questions

Why does Meta show more purchases than orders after adding the Conversions API?

Because Meta can’t tell the two copies are one sale. It merges a Pixel event and a Conversions API event only when both carry the same event_id and the same event name, for the same Pixel, within 48 hours of the first one arriving. A missing id, a fresh random id on each side, Purchase against purchase, or a second server sender all leave both copies counted.

Events Manager shows twice as many purchases as my orders. Is that double counting?

Not on its own. Meta says the Overview shows events received before they are deduplicated. A healthy setup that sends every purchase from the browser and the server looks doubled there. Read the Event Deduplication tab and compare Purchases in Ads Manager with your orders for a closed week instead.

What should I use as the event_id for a purchase?

The order number, or an id stored once per order and read by both sides. It must reach the Pixel and the server as the identical string. An id generated separately by each tag will differ, and nothing merges.

Does Shopify’s Facebook and Instagram app handle deduplication?

Shopify says Enhanced and Maximum data sharing send the purchase through the Conversions API as well as the Pixel. Shopify doesn’t document how it sets the event ID, so prove it on the Event Deduplication tab. The common break is adding a second server sender, such as server-side GTM, on top of the app.

I fixed the event_id. How long until the numbers look right?

A test order in Test Events confirms it within minutes. Meta says events show within about 20 minutes. The purchase count needs a full week of new orders, because sales already counted twice stay counted.

Who should I hire to fix Meta double counting purchases?

Someone who can read the Pixel request in the browser, the server request in server-side GTM Preview or your server logs, and Events Manager, with access to all three. The job is done when a test purchase shows from browser and server with one event ID, and a closed week of Meta purchases sits below total orders again.

Sources

Read on 4 November 2026:

← back to the reading room