Meta Pixel and Conversions API: How the Two Actually Connect
Browser tracking and server tracking answer different questions; here is what each one sees, what it misses, and how event_id deduplication actually works.
Two systems, one signal
Two names get used almost interchangeably in Malaysian small-business Facebook groups: "the pixel" and "the Conversions API". They are not interchangeable, and treating them as alternatives — pick one, install it, done — is one of the more common setup mistakes behind conversion numbers that don't add up.
Meta's own developer documentation describes the Conversions API as a way to "create a connection between an advertiser's marketing data...from an advertiser's server, website platform, mobile app, or CRM to Meta systems that optimize ad targeting, decrease cost per result and measure outcomes" (Meta for Developers, Conversions API). Events sent this way are "processed like events sent using the Meta Pixel, Facebook SDK for iOS or Android, mobile measurement partner SDK, offline event set, or .csv upload" — the server-side channel feeds into the same pipeline as the browser-side one, rather than replacing it. Meta treats them as complementary from the start, not as a newer tool meant to retire an older one.
What the browser side actually does
The Meta Pixel is a JavaScript snippet placed on a website. Meta's own setup guide describes it plainly: it "relies on Facebook cookies, which enable us to match your website visitors to their respective Facebook User accounts" (Meta Pixel, Get Started). By default it fires a PageView automatically on every page load; anything more specific — a Lead, a Contact, a Purchase — has to be explicitly coded to fire at the right moment. A pixel that's "installed" but never told to fire a conversion event isn't broken. It's simply never been asked to report anything beyond page views.
The same setup guide notes that placing the code inside a page's <head> tags "reduces the chances of browsers or third-party code blocking the Pixel's execution" — a sentence that only makes sense because blocking is a real, acknowledged risk. Ad blockers, in-app browsers with restricted cookie behaviour, and privacy settings in modern browsers can all interrupt a pixel before it ever fires. None of that is a configuration error on the business's part; it's simply the environment a browser-only tracker now operates in.
What the server side actually does
The Conversions API sends events from somewhere the business controls directly — its own server, CRM, or order system — straight to Meta, tied to a dataset ID. What it knows for certain is whatever your own systems recorded: an order was placed, a form submission passed validation, a lead was marked qualified by a human. It does not automatically know anything about the browser session that produced that outcome. No user agent, no originating page, no click context arrives for free — those have to be captured at the point of the original visit and carried through into whatever eventually fires the server-side event.
That carry-through is the part that quietly fails most often. If a CRM has no field recording which visit or which click produced a given lead, the Conversions API has nothing meaningful to attach the eventual sale to, however correctly the integration itself is built. The API reports outcomes; it doesn't manufacture the record of where those outcomes came from.
Why the same action can get counted twice
Running both channels for the same event is the correct setup, but it creates an obvious risk: a single Purchase or Lead firing once from the browser and once from the server could be counted as two conversions instead of one. Meta's documentation on this is specific about how it avoids that. "We determine if events are identical based on their ID and name" (Meta for Developers, Deduplicate Pixel and Server Events) — meaning the pixel's eventID parameter has to match the server event's event_id parameter, and the event name on the browser side has to match the event_name sent server-side, for Meta to recognise the two as one action rather than two.
There's a fallback method for setups that haven't implemented matching event IDs, based on comparing event_name together with fbp (the browser cookie identifier) or an external_id. Meta's documentation is explicit that this fallback "only works for deduplicating events sent first from the browser and then through the server," and that matching events have to arrive within 48 hours of each other to be reconciled at all. Outside that window, or in the wrong order, deduplication doesn't happen and the event risks being double-counted.
When both a matching ID and a plausible near-duplicate exist, Meta's stated approach is that it "generally prefer[s] the event that is received first" as the version it keeps for reporting. In practice, this means the order events arrive in, and how consistently the identifiers travel with them, matters more than which system — browser or server — a business assumes is "the real one."
What a correct setup looks like
Put together, a working implementation has a few concrete features:
- Both channels running, not one instead of the other. Meta's own architecture treats them as one pipeline; disabling the pixel because the Conversions API is "better" throws away browser context the server side never had in the first place.
- One event ID generated per action, shared by both calls. Whether that's a UUID or another unique string, it needs to be created once for a given Purchase, Lead, or Contact and passed identically to the pixel call and the server call describing that same action.
- Matching event names. A pixel
Leadevent paired with a serverleadevent, or any other mismatch in naming, breaks the matching Meta describes even if the IDs line up. - A verification step. Meta's own guidance around setting this up refers to confirming that "events are deduplicated and matched correctly" rather than assuming it from the code alone — worth checking directly rather than trusting that a correctly written integration is automatically a correctly firing one.
None of this changes how many people actually convert, and it isn't a substitute for a CRM that records where a lead came from in the first place. What it does is stop a business from misreading its own numbers — treating one sale as two, or missing a real one because the browser-side signal alone couldn't see it.
Where JagaWeb fits
We don't run ad accounts, and the current pricing for the work we do quote is published on jagaweb.my rather than repeated here. What sits squarely in scope is the plumbing underneath — checking whether a site's pixel and server-side events are actually configured the way Meta's own documentation describes, rather than assumed to be. If that's the specific question, JagaWeb's Essential System Review (RM1,500, currently RM999 until 16 September 2026) covers a site's tracking setup as part of its eight control points, with a decision-ready report rather than a guarantee attached. Reach us at sales@jagaweb.my or WhatsApp jagaweb.my.
Ready to verify who owns your website?
Replace uncertainty with a decision-ready ownership and access report. The fixed Ownership & Access Review is RM1,500 before SST and includes a 30-day action plan.