Meta Conversions API deduplication: how pixel and server events are matched

The Meta Conversions API sends conversion events from your server to Meta, alongside the Meta Pixel in the browser. Meta counts the same conversion once when the two copies share an event name and an event ID. Deduplication only works when both sides send those values consistently.

What is the Meta Conversions API?

The Conversions API is an interface for sending events from your own server to Meta. The Meta Pixel sends events from the visitor’s browser. Meta’s overview says that if you already have a Meta Pixel on your website, you can also set up the Conversions API for website events from Events Manager, so the two often run side by side.

Two copies of the same purchase or lead are the reason deduplication exists. Without it, a single conversion could be counted twice. Each copy also needs enough detail to be matched to the right person and ad click.

How does deduplication work?

Meta decides that a browser event and a server event describe the same action by comparing two fields. The event name must match, and the event ID must match. In Meta’s terms, the pixel’s eventID must equal the server event’s event_id, and the pixel’s event name must equal the server’s event_name.

On the pixel side, the event ID goes in the options object, which is the fourth argument to the fbq track call. The server side sends it as event_id on the event. Meta says that the event ID “can be any unique string chosen by the advertiser,” so generate it once per conversion and reuse it on both sides, for example from your order or lead record ID.

Meta gives a time limit. Its deduplication guidance says events are deduplicated when they are received within 48 hours of when we receive the first event with a given event_id. A server copy that arrives after that window is not matched to the browser copy, so check your timing if you batch server sends.

Meta documents a second, less exact approach. It says you must use event_name, fbp, and/or external_id consistently across browser and server events, and that this method generally only works for events sent first from the browser and then through the server. Meta presents it as a separate method rather than a fallback for a missing event ID. If your setup cannot share an event ID, check the results in Events Manager before relying on them.

What is Event Match Quality?

Event Match Quality (EMQ) is the score in Events Manager for how well the customer information your server sends can match events to a Meta account. Meta describes it as a score out of 10, calculated in real time. The score reflects which customer information parameters you send, their quality, and the share of events that match. Meta’s documentation says that EMQ is currently available only for web events.

Customer information parameters are the fields you add to each server event’s user_data. The main ones are em (email), ph (phone), fn and ln (names), db (date of birth), ge (gender), ct, st, zp, and countryfor location, external_id for your own customer ID, client_ip_address, client_user_agent, fbp, and fbc. The documentation does not name a single parameter that raises the score, so send the fields you have, correctly formatted.

Which customer data must be hashed?

Hashing rules are the part most often done wrong. Meta’s customer information page says the contact and profile fields must be normalized and then hashed with SHA-256 before sending. For email, trim leading and trailing spaces and convert to lowercase before hashing. For phone, remove symbols and letters, drop leading zeros, and include the country code. Meta also recommends hashing external_id.

After any change to the server payload, check EMQ and the event details again, because a formatting mistake changes the match without changing the event name.

What do action_source and event_time do?

action_source tells Meta where the conversion happened. Its allowed values include website, app, email, phone_call, chat, physical_store, system_generated, business_messaging, and other. For a website event, set it to website. Meta notes that by using the Conversions API you agree the value is accurate to the best of your knowledge, so do not label offline or CRM events as website events.

event_time is a Unix timestamp in seconds for when the event actually occurred. Meta says it can be up to 7 days before you send the event. Send the time of the conversion, not the time of the batch job. A batch that sends old conversions with fresh timestamps can fall outside that window.

How do you set up the server side?

Meta’s documentation says the integration options differ in effort, cost, and features. The two it names are partner integrations, from partners that offer Conversions API functionality, and direct integrations, which connect your server to the Conversions API endpoint. Server-side tagging is another route to the same endpoint and needs the same event name, event ID, and user data. For that approach, read the beginners guide to server-side tag management. Whichever route you choose, the test steps below are the same.

Consent still applies. Where a visitor’s consent is required under your consent policy or local law, do not send browser or server events for them until consent allows it. Confirm that your server events follow the same consent decision as the pixel.

How do you check that deduplication works?

Use three checks, in this order.

1. 1Open Test Events under Events Manager > Data Sources > your pixel. Send a server request with the test_event_code parameter and confirm it appears.
2. 2Trigger the same action in the browser and confirm the pixel event shows the same event name and the same event ID as the server event.
3. 3After live traffic arrives, open the event in the Events Manager overview and confirm that browser and server copies of the same conversion are counted once.
4. 4Review the Event Match Quality score in Events Manager after live traffic has arrived.
5. 5Remove test_event_code from the production payload before you turn the server send on.

The Test Events tool shows server events once the request reaches Meta, so it confirms the request format rather than long-run counts. The overview and event details are where you see whether live events are deduplicated. If the numbers still differ from your own system, compare them against your order or lead records. Differences between Meta and GA4 totals are a separate question, covered in why Meta ads and GA4 numbers don’t match.

Meta also has a setting that affects which conversions it can measure on a device. The on-device conversion measurement setting is covered separately, so this article does not repeat it.

If your conversions come from a CRM or an offline process, the setup is different. The GoHighLevel offline conversions guide for Google and Meta walks through that flow. For a review of your current tags and events, a Free Tracking Scan can show what the website sends from the browser, which is the first half of the match.