Check event names and IDs when a purchase is sent from both browser and server. Distinguish duplicate events from missing data and normal attribution differences.
When Meta Pixel and Conversions API (CAPI) send the same purchase, both submissions must describe the same event. Use the same event name and event ID across browser and server for that purchase, and a different ID for a different purchase. This gives Meta the information needed to recognise the pair. Deduplication does not make advertising-attributed purchases equal all store orders; that comparison is a separate question.
What do the two paths send?
The Pixel sends events from the browser, while CAPI sends them through a server-side integration. Both may send Purchase for one order. Two submissions therefore do not necessarily mean two purchases. Meta’s official Business SDK event definition explains that the event ID is used with the event name to identify identical browser and server events.
Verify three things with a test order
1. Do the event names match?
If the browser sends Purchase but the server sends a differently named custom event, do not assume they form a matched pair. Identify which event actually represents the completed purchase. An add-to-cart event and a purchase event describe different actions and should not be treated as interchangeable.
2. Does the same purchase use the same ID?
In a hypothetical test, the browser could send Purchase with eventID purchase_test_1048 and the server could send Purchase with event_id purchase_test_1048. A different purchase must not reuse that identifier. Generating independent random IDs in the two paths loses the shared link between submissions. If the same real event is retried, preserve its event identifier. Avoid putting an email address, phone number or other personal information into that identifier.
3. When does a purchase event fire?
Firing a new purchase every time an order confirmation page opens can create repeat submissions. Check that refreshing the page does not create a new purchase and that a different test order receives a different ID. Compare value and currency with the expected test order. Use the integration’s testing environment and keep customer details and access credentials out of screenshots or review notes.
Match the symptom to the first check
• Two different Purchase IDs for one order: Check how the ID is passed between browser and server. Independent ID generation is one possible cause.
• Different orders reuse an ID: Confirm that the ID is created per real event. Reuse can contribute to missing measurements.
• Only one path appears: This is not, by itself, evidence of double counting. Investigate the missing path within the integration and consent setup.
• Events look correct but store and ad totals differ: Compare dates, time zones, currency, attribution and reporting scope before diagnosing duplication.
What does a passing test prove?
One successful test checks the scenario you actually exercised. It does not validate every payment method, retry case or reporting delay. Record the date, environment and scenario, and test relevant alternative flows before drawing a broader conclusion. The AdLens analytics overview describes campaign reporting for monitoring trends after a measurement change. Event delivery and matching still need to be checked using Meta’s event and testing tools. For the same checklist in Turkish, see Meta Pixel ve Conversions API.
Keep the decision tied to evidence
A sudden rise in reported purchases after enabling CAPI deserves investigation, but the rise alone is not proof of duplication. Compare the test event identifiers first. Check whether the reporting window or attribution setup changed at the same time. Conversely, a lower count does not automatically mean deduplication is correct: missing events can also reduce totals. Separate these checks so that a cleaner-looking chart does not conceal a measurement problem.
