The short answer
The Meta pixel sends events from the visitor’s browser; the Conversions API sends them from a server. Send the same event from both only with the same event name and event_id, so Meta keeps one. fbp identifies the browser, fbc carries the ad click. Server side earns its cost when outcomes happen off the website.
What is the difference between the pixel and the Conversions API?
The pixel is JavaScript on your pages. It fires in the visitor’s browser, reads Meta’s cookies, and sends an event such as PageView or Lead directly to Meta. It only sees what happens in that browser, and only when the browser lets it run.
The Conversions API is a server-to-server connection. Your server, a server-side tag manager, or a CRM sends the event to the same Meta dataset. It can report things the browser never sees, such as a booked appointment in a scheduling system or a sold job in field service software, and it lets you decide exactly which fields leave your systems.
- Pixel only: simplest, and blind to anything after the website.
- Conversions API only: possible, but you lose the browser context the pixel collects for free.
- Both: the setup Meta recommends for website events, provided each event is deduplicated.
How does deduplication with event_id work?
When the same action is reported by the pixel and by the server, Meta receives two events. It treats them as one when they carry the same event name and the same event ID. An event without an ID cannot be deduplicated, so both copies count.
Create one ID per real action, on the page
When the visitor submits the form, generate a unique ID once, for example a random string or the form submission’s own ID.
Give it to the pixel
The pixel takes it as eventID in the options argument of the track call.
Give the same value to the server
Pass it along with the form data, so the server event carries it as event_id.
Use the identical event name on both
Lead and lead are different names. So are Lead and a custom event that means the same thing.
Check it in Events Manager
Events Manager reports how well browser and server events are being deduplicated. Meta only merges events received within a limited time of each other; check its current documentation for the window.
fbq('track', 'Lead', {}, { eventID: 'lead-8f2c41' })What are fbc and fbp?
They are the two identifiers that let a server event be tied to a browser and an ad click. The pixel stores both as first-party cookies, _fbp and _fbc. A server event has no cookies of its own, so it has to be given them.
fb.<subdomainIndex>.<creationTime>.<randomNumber>fb.1.<creationTime>.<fbclid>- fbp identifies the browser. It exists whenever the pixel has run.
- fbc carries the fbclid from a Meta ad click. It only exists when the visit came from an ad.
- If the _fbc cookie is missing but the landing URL had an fbclid, fbc can be built from it. Keep the fbclid exactly as it arrived.
- Send them unhashed, alongside the hashed contact fields. Contact details such as email and phone are normalized and hashed with SHA-256 first.
When is server side worth it?
The Conversions API is not a fix for a pixel that measures the wrong thing. It is worth building when at least one of these is true.
The outcome that pays happens off the website
A booked consultation, a signed case or a sold job is recorded in a CRM or practice system. Only a server event can report it. This is the strongest reason.
You need to control the payload
On health and legal sites, a server path lets you send only approved fields instead of whatever a browser tag can read.
Browser events are going missing
Ad blockers and browser privacy features stop some pixel events. A server copy of the key events recovers some of them, within the limits of what the visitor consented to.
It is usually not worth it yet if the conversion itself is undefined, if the pixel is firing on the wrong page, or if nobody will maintain a server path once it is built. Fix the definition first. A server-side copy of a bad event is still a bad event.
How we scope a server path, and when we recommend against one.
How do you run both without double counting?
List every event and choose its source
For each event, write down whether it is sent by the pixel, the server or both. Off-website outcomes are server only.
Add event_id to every event sent from both
Generated once in the browser, passed to both sides, as described above.
Fill the server event properly
Event name, event time, event_id, the action source Meta asks for, and for web events the page URL, IP address and user agent, plus fbc, fbp and hashed contact fields.
Test before going live
Events Manager has a test events tool. Send a test through both paths and confirm one event is kept.
Watch the quality signals
Deduplication coverage, and Event Match Quality, Meta’s score for how well server events match to Meta accounts. Low match quality usually means missing fbc, fbp or contact fields.
Does the Conversions API make sensitive data safe to send?
No. A server event can carry exactly the same health detail or case detail as a pixel, and Meta filters data it categorizes as potentially sensitive health information on its side regardless of the channel. What a server path gives you is control: you choose each field, and you can document the choice.
Common mistakes
- 01
Generating the event ID twice
If the browser and the server each make their own ID, they never match and every event counts double.
- 02
Different event names on each side
Lead from the pixel and a custom SubmitForm from the server are two different events to Meta.
- 03
Hashing fbc and fbp
They are identifiers, not contact details. Hashed, they match nothing.
- 04
Sending server events a week late
Meta rejects a request containing an event more than seven days old, so batch jobs lose data without much warning.
- 05
Treating a gateway as a strategy
A managed server connector moves events. It does not decide which events matter or check what they carry.
Questions
Do I need the Conversions API if the pixel is working?
If every outcome you care about happens on the website, the pixel may be enough for now. If the outcome that pays is a booked appointment, a signed case or a sold job recorded in a CRM, only a server event can report it.
Does the Conversions API get around consent or iOS restrictions?
It should not be used to. It changes how events travel, not what you are allowed to collect. Consent choices the visitor made still apply to the server event.
What is a good Event Match Quality score?
Meta scores it out of 10 and publishes its own guidance. Rather than chase a number, raise coverage: send fbc, fbp and hashed email and phone on every event where you have them.
Should fbc and fbp be hashed?
Meta’s documentation treats them as identifiers sent as they are, while contact details such as email and phone are hashed. Confirm against Meta’s current parameter documentation before shipping.