The store has one confirmed order, but in Meta's diagnostics you see two Purchase sends. This may be the normal pair from the browser and the server, or real duplication. The difference is established from the events of a specific order, not just from the total count in the ad report.
For one purchase, send the same event name and a shared identifier: the Pixel uses eventID, and the Conversions API uses event_id. Check that both sends go to the correct Pixel/dataset and represent one result. Then test repeated notifications, page reloads and competing integrations that may send extra purchases.
Two sends don't necessarily mean two purchases
The Pixel measures through the browser; CAPI can send the same action from the server. This combination needs deduplication. If the systems use different identifiers for one purchase, Meta may not recognize that the events refer to one action.
Separately, there are differences in attribution, time windows and order status. A higher ad count than the store's doesn't by itself prove a deduplication defect. First check comparable results and specific sends.
Which fields must match
| Element | Browser | Server |
|---|---|---|
| Event name | Purchase | event_name: Purchase |
| Identifier for the same action | eventID: purchase_DEMO_8472 | event_id: purchase_DEMO_8472 |
| Target configuration | The correct Pixel ID | The corresponding Pixel/dataset |
| Value and currency | The agreed value | The same business definition |
The identifier in the table is hypothetical. Meta describes the recommended matching by name and event ID, where the browser eventID must match the server event_id. In the Pixel, eventID is an option in the fourth argument of the call, not just an arbitrary field with a similar name among the purchase data.
The identifier belongs to the action
Generate a stable identifier for one logical purchase and use it in both channels. If the server creates a new random ID on every attempt, a repeated notification looks like a new action. If all orders share the same ID, you risk losing valid results.
Don't use an email or phone number as the purchase identifier. One customer can make several different purchases. With orders from different stores or environments, add safe differentiation so the numbers don't collide.
Map every sender
Check the platform module, GTM, custom code, a server-side container, CAPI Gateway and connected apps. A common cause is an old and a new mechanism running at the same time. The list should show who sends Purchase, when they do it and where they get the event ID.
Don't arbitrarily turn off the whole Pixel to reduce the count. First determine which flow is redundant and what else it measures. After the change, also check the other important events, so you don't fix purchases by losing the whole journey.
A one-order test that reveals the problem
- Choose a test environment or an agreed test order and record its number.
- Check the agreed state for Purchase: created, paid or another real confirmation.
- Trace the browser send and the server payload in the permitted diagnostic tools.
- Compare the name, event ID, target Pixel, value and currency.
- Check how the browser/server events appear and the deduplication diagnostics in Events Manager.
- Repeat with a page reload and a repeated webhook delivery.
- Make a second, different order: it must have a new identifier and remain a separate purchase.
The test must prove two things at once: repeating the first order doesn't create a new result, and the second valid purchase doesn't disappear. A general green checkmark for an active integration isn't enough.
Repeated server notifications need their own control
A webhook can be delivered again after a temporary error. The integration must keep track of the processed action and manage retries. This is idempotency: the same incoming operation doesn't create a new business result on every repeat.
Don't rely solely on browser/server deduplication to fix two independent server integrations. Record the sent event, the delivery result and the reason for the retry. The logs must be available only to the authorized team and must not show unnecessary customer data.
When should Purchase be sent?
Define it according to the store's model. With cash on delivery, a created order isn't the same as finally realized revenue. With online payment, loading the "Thank you" page may not be sufficient proof of success. The platform and the store must use a clearly documented result.
CAPI doesn't override the user's choice or the applicable data limitations. Moving measurement to the server is not a reason to send everything without control.
For general diagnostics, read GA4, GTM and conversion tracking. For online stores DigitaL+ combines Analytics & Tracking with Meta advertising. If the problem lies in the results after correct measurement, the next topic is catalog, creatives and margin.
Frequently asked questions
Does Event Match Quality show that there's no duplication?
No. The match quality of user signals and recognizing a repeated event are different checks.
Should event_id be random?
It can be generated in different ways, but it must be unique to the action and stable on repeats. Both channels must use the same value.
After the fix, will all reports match?
No. You'll remove the specific defect, but differences due to attribution, statuses, timing and permitted measurement may remain.
