About deduplication for Meta pixel and Conversions API events

The Meta pixel and Conversions API let you share standard and custom events with us so that you can measure and optimise ad performance. The pixel lets you share web events from a web browser, while the Conversions API lets you share web events directly from your server.

If you connect website activity using both the pixel and Conversions API, we may receive the same events from the browser and the server. If we know that the events are the same and therefore redundant, we can keep one and discard the rest. This is called deduplication.

We recommend that you deduplicate your events as a best practice for using the Conversions API, but deduplication may not be necessary depending on how you set up your events. If you want to send web events using both the pixel and Conversions API, you have two setup options:

• Share different events from the browser than from the server (deduplication isn't necessary). For example, you share add to cart events from the browser, and purchase events from your server. Deduplication isn't necessary in this instance because you aren't sending redundant events from both the browser and the server.
• Share the same events from both the browser and the server (deduplication is necessary). For example, you send the same purchase events from the browser as you do from the server. This may help recover events that aren't received by the Meta pixel. If your redundant browser and server events aren't deduplicated, you would see two purchases appear in your report (one sent from the browser and one sent from the server) when only a single purchase has actually occurred. Deduplication is necessary in this instance so that the same purchase doesn't show up twice in your reporting.

For events to be deduplicated, you or your developer should add two event parameters that help us determine if the events are the same: the event name (for example, Purchase or AddToCart) and the event ID. Learn more about server event parameters on Meta for Developers.

Once the events are received, we employ a number of strategies to deduplicate between the events which may help improve optimisation and measurement. If server and pixel events do not differ meaningfully in their content, we generally prefer the event that is received first.

For example, we would deduplicate the following events:

1. Redundant pixel events.

   We deduplicate pixel events with identical event and eventID parameters.

2. Redundant server events.

   We deduplicate server events with identical event_name and event_id parameters.

3. Redundant pixel and server events.

   We deduplicate pixel and server events that meet both of the following conditions:

   • The pixel's event matches the Conversions API's event_name.
   • The pixel's eventID matches the Conversions API's event_id.

4. Redundant pixel and server events using fbp and External ID.

   We deduplicate pixel and server events that meet both of the following conditions:

   • The pixel's event matches the Conversions API's event_name.
   • The pixel's external_ID matches the Conversions API's external_ID.

   We also deduplicate pixel and server events that meet both of the following conditions:

   • The pixel's event matches the Conversions API's event_name.
   • The pixel's fbp matches the Conversions API's fbp.

You can check which events are deduplicated using the test events tool in Meta Events Manager.