Meta Conversions API vs pixel: deduplication, match quality and the system user token

Quick answer

The Meta Conversions API sends events from your server and the pixel sends them from the browser. Run both with the same event_id so Meta counts each purchase once, send normalized email and phone hashed with SHA-256 to raise match quality, and generate the token with one system user per client, assigned only the pixel.

What does the pixel measure and what does the Conversions API measure?

Both measure the same thing, what the customer does after seeing the ad, but through different paths. The pixel is a script that runs in the visitor's browser and sends the event from there. The Conversions API (CAPI) is your server, or your checkout platform's server, sending the event straight to Meta, without depending on the browser.

Meta itself describes the Conversions API as the connection between an advertiser's server, website, app or CRM data and Meta's ad systems, and it processes events received this way just like pixel events. In practice: the pixel sees behavior, the server sees facts. An order placed with a payment method that only confirms later, such as a bank transfer, is a purchase to the pixel; to the server it only becomes a purchase once the money arrives.

Why use both at the same time?

Because each one covers the other's blind spot, and Meta recommends exactly this setup, which it calls redundant: pixel and Conversions API sending the same events. When the browser blocks the pixel, the server still delivers the purchase. When the server integration does not have the click cookie, the pixel still carries the browsing context.

• Pixel only: misses the purchase from anyone using an ad blocker or closing the thank-you page before it loads, and counts orders that were never paid as sales.
• Server only: misses browsing behavior (page views, add to cart) if your backend does not know about it, and usually has fewer cookies to match the event to a person.
• Both, with deduplication: Meta receives the event through two paths and counts it once.

How does event_id deduplication work?

Meta merges two events when they reach the same pixel with the same event name and the same identifier: the pixel's eventID must match the server's event_id, and the pixel's event must match the API's event_name. According to the documentation, if the same combination arrives from the browser and the server within 48 hours, the later events are discarded.

On the pixel, the identifier goes in the fourth argument of the call:

fbq('track', 'Purchase', {value: 49.90, currency: 'USD'}, {eventID: 'order-48213'});

On the server, the same order-48213 goes in the event_id field of the Purchase event. Meta suggests using the order number or transaction ID when one exists. For events without a natural ID, such as a page view, a random number works, as long as it is the same on both sides, which in practice means generating it in the browser and passing it to the server.

What are the most common event_id mistakes?

• ID generated twice: the browser picks one, the server picks another. Nothing matches and everything is counted twice.
• Different event name: Purchase on the pixel and purchase or Order on the server are not the same event.
• ID reused across orders: using the product ID instead of the order ID makes Meta discard the second sale of the same product as if it were a copy.
• Server too late: once the 48 hour window has passed, the server event is no longer recognized as a duplicate.

There is an alternative method, based on fbp or external_id, but the documentation itself limits it: it only works when the browser event arrives first. If you control the code, use event_id.

What is event match quality (EMQ)?

It is the score, from 0 to 10, that Meta gives each server event, showing how well the customer data you sent helps link that event to a Meta account. It appears in Events Manager, in the details of each event, and currently applies to website events.

The logic is simple: Meta can only optimize for and attribute the purchase if it knows who bought. A purchase event with no email, no phone and no cookie is a loose number that teaches the algorithm nothing. Meta does not publish an official minimum score; the practical rule is to compare each event's score with the others in the same account and fix first the event the campaign optimizes for, usually the purchase or the lead.

Which user parameters raise the score?

Beyond the required fields, Meta lists email, IP, full name and phone as recommended. Here is what each one requires:

Two details lower the score without anyone noticing. First, do not hash IP, user agent, `fbp` or `fbc`: they go as they are. Second, fbp and fbc change; read them from the cookie at the time of the event, not from a value stored months ago. For a sale that arrives by webhook days later, store both with the order at checkout time.

Which fields can a website event not leave out?

• event_name, event_time and user_data in every event.
• action_source, required: website for a site, business_messaging for a conversation, physical_store for a physical store, among others. Meta requires it to be accurate.
• event_source_url, required for website events: the URL where the action happened.
• event_time no more than 7 days in the past. One old event in a batch makes Meta reject the whole batch, and the same goes for any invalid event in a batch of up to 1,000.

Meta recommends sending events as soon as they happen, ideally within one hour. To test, use test_event_code in the test events tool and remove it before going to production.

Which implementation path should you choose?

It depends on where the sale happens, not on technical preference:

The Gateway is Meta's no-code option: it runs in the advertiser's own cloud account (AWS or GCP), receives the pixel events and resends them from the server, generating and propagating the event_id on its own. It requires some technical familiarity and cloud costs, but it solves deduplication without touching the site.

In every case, someone will ask for an access token. This is where agencies usually go wrong.

How does an agency generate the CAPI token with a system user?

A system user is a machine account inside Business Manager (the business portfolio): it is not a person, it does not go on vacation, it does not change passwords and it only sees the assets you assign to it. It is the right way to give an integration access to the pixel without using anyone's personal profile.

There are two official paths. The quick one: in Events Manager, in the pixel settings, the option to generate a token under the manual Conversions API setup. Meta automatically creates an app and a system user for the Conversions API. The controlled one, which we recommend for agencies:

1. In the client's business settings, open the system users area and create one, with a name that says what it does, for example capi-example-store.
2. Choose the standard (employee) role, not admin. Meta reserves admin for administrative actions and recommends protecting that token with extra care.
3. Assign this user only the client's pixel, with permission to manage it. No ad account, Page or catalog if the integration only sends events.
4. Click generate token, choose the app and select the minimum permissions the screen asks for. Meta does not require app review for the Conversions API.
5. Choose the expiration. Meta offers a token that never expires and a 60 day token, and calls the 60 day one a security best practice.
6. Copy the token right away and store it in the agency's password vault. Treat it like a password: whoever has the token can send events on the client's behalf.
7. Paste the token into the integration (checkout platform, Gateway or the server's environment variable) and fire a test event with test_event_code.

One system user per client or one for all of them?

One per client, created in the client's Business Manager. Putting every pixel under a single agency system user looks convenient until the day the token leaks: then a single code grants access to every client's pixel. Meta itself recommends creating one system user for each type of access.

• The asset belongs to the client. Pixel, token and system user live in the client's business. If the agency leaves, the client revokes the agency's access and measurement keeps working.
• The damage from a leak stays contained to one client and one pixel.
• Revoking is one click: when the client ends the contract, the agency deletes the token or removes the pixel from the system user.
• Never put the token in browser code, a shared spreadsheet or the team's group chat. It goes into the vault and into an environment variable.

The same logic applies to the team: each person only accesses the accounts they work on. We cover that in how to give access to a Facebook ad account and how to manage multiple Facebook ad accounts.

How do you know the implementation is right?

1. In the test events tool, fire a test purchase and check that both the browser event and the server event arrive, and that Meta marks one of them as deduplicated.
2. In the purchase event details, look at the event match quality score and which parameters Meta says are missing.
3. For one week, compare the purchases in Ads Manager with the paid orders in your store or payment platform. A big gap upward means double counting or unpaid orders; downward means lost events. UTM parameters on your ads give you a third source that does not depend on the pixel or CAPI.
4. Remove test_event_code before releasing to production.