Deduplicate Purchase Events: Use the same order number as event ID in browser and server events; Meta merges events if ID and name match within 48 hours; Verify deduplicated count in Events Manager and match to commerce system
Image: Paid Social Guide

Conversion Tracking

Part of Social conversion tracking

Deduplicating purchase events from two data sources

Deduplication solves a specific problem: the same purchase reaches an ad platform from both browser and server and must count once.

Deduplication solves a specific problem: the same purchase reaches an ad platform from both browser and server and must count once. It does not fix two real purchases being assigned the same ID, or a page firing the purchase event repeatedly before the order is final.

Give one purchase one identifier

Create the event ID from the confirmed business transaction and pass the same value through both routes. Keep the event name consistent. Platforms generally require a shared identifier and a matching event name before they will merge overlapping conversions, and each platform applies its own accepted time window, so confirm the rule for every network in use.

For Meta, set eventID on the browser Meta Pixel event and event_id on the server Conversions API (CAPI) event to the same value. Send event_name as Purchase in both. Meta merges the copies when both the event ID and event name match and the events arrive within 48 hours.

Use the confirmed order number as the ID if both routes can access it; otherwise, generate one unique ID once and pass it through both routes. For example, the browser Pixel and server CAPI events for the same order should carry that same order number in their respective ID fields and both use Purchase.

Do not generate a fresh random ID separately in the pixel and the server job. Do not recycle an ID for different orders. Check retry behaviour: a server queue should resend the same ID for the same purchase. If an order is edited later, decide whether that change is a distinct event or a correction to the original, and document the platform's supported approach.

Verify the final count

Run a controlled transaction and inspect browser, server and platform diagnostics. For Meta, open Events Manager and check the per-event deduplicated count; confirm the browser and server copies use the same ID and event name. Then reconcile against the commerce system: one confirmed order should not become two platform purchases merely because two routes delivered it. Check value and currency at the same time; a deduplicated but wrong-value event is still wrong.

Monitor the ratio of browser-only, server-only and deduplicated events after launch. A sudden shift can indicate a pixel outage, API failure, consent change or ID mismatch. Interpret the diagnostic with platform processing delays in mind and investigate before changing bidding or declaring a campaign improvement.

Key Deduplication Metrics to Monitor Post-Launch

Browser-only events
Indicates no server delivery — check API health or consent settings
Server-only events
Suggests pixel failure or tracking delay — investigate browser-side issues
Deduplicated events
Expected outcome: one purchase counted once despite dual delivery
Event count ratio shift
Sudden change may signal outage, consent change, or ID mismatch

More from Conversion Tracking