Meta AdsTrackingAnalytics
Meta Pixel vs Conversions API — What Actually Matters
They are not alternatives. One runs in the browser and gets blocked; the other runs on your server and does not. Here is what each measures, why you need both, and how to set them up without a developer.
By Dukun Ads8 min read
The question is asked as though you have to choose. You do not. Meta Pixel and the Conversions API are two different transports for the same events, and running both is the normal configuration in 2026 — not an advanced optimisation.
What each one actually is
The Meta Pixel is JavaScript that runs in your visitor's browser. When someone lands on a page or buys something, the browser sends that event directly to Meta. It is easy to install and it captures browser context — the click ID from the ad, cookies, device details — automatically.
The Conversions API (CAPI) sends the same events from a server instead of a browser. Your server, or a platform acting on your behalf, makes an authenticated call to Meta describing the event: what happened, when, for how much, and who it was, using hashed identifiers.
| Pixel (browser) | Conversions API (server) | |
|---|---|---|
| Runs in | The visitor's browser | A server |
| Blocked by ad blockers / ITP | Often | No |
| Captures browser context automatically | Yes | Only what you pass to it |
| Can report offline or delayed events | No | Yes |
| Setup effort | Paste a script tag | Needs a token and a server call |
Why browser-only tracking under-reports
A meaningful share of your traffic never reports a pixel event at all. Ad blockers strip the script. Safari's tracking prevention shortens cookie lifetimes to days. Privacy-focused browsers block third-party requests outright. In-app browsers behave unpredictably. Each of these is small on its own; together they routinely remove a double-digit percentage of your conversion data.
That missing data does not just make your reports look pessimistic. It actively degrades delivery, because Meta's optimisation learns from the events it receives. Fewer purchase events means a weaker signal, which means worse targeting, which means a higher cost per result. Under-measurement is not a reporting problem — it is a performance problem.
Deduplication: the part people get wrong
If you send the same purchase from the browser and from the server without telling Meta they are the same purchase, it counts twice. Your ROAS looks great and your budget decisions become fiction.
The fix is an event ID: a unique string generated once per event and included in both the browser call and the server call. Meta matches on that ID plus the event name and discards the duplicate. Any tracking layer worth using generates and pairs this for you — if a tool asks you to install CAPI without mentioning event IDs, be suspicious.
What identifiers to send, and what to send them as
Server events are matched to people using hashed identifiers. The single highest-value one is email, hashed with SHA-256, lowercase and trimmed before hashing. Phone number in international format is second. The click ID captured from the ad URL is invaluable when present, because it is an exact match rather than a probabilistic one.
- Never send raw email addresses or phone numbers to the API. Hash them first.
- Normalise before hashing — trim whitespace, lowercase, strip formatting from phone numbers — or the hashes will not match Meta's.
- Capture the click ID from the landing URL on arrival and persist it for the session, otherwise it is gone by the time the purchase happens.
- More identifiers means a higher match rate. One is usually enough; three is meaningfully better.
Setting it up without a developer
The traditional path involves a server endpoint, an access token from Events Manager, and code to hash and forward events. That is a real project. The shortcut is a tracking layer that does both transports from one script tag.
In Dukun Ads, /sales is where this lives. You register the page you want to track, attach a pixel — either picked from your connected Meta Ads account or entered by ID — and paste one script tag into your page's <head>. That single snippet installs the pixel and the conversion tracking together. When the pixel comes from a connected ads account, server-side CAPI is sent automatically and no access token is required; if you are using a pixel from elsewhere, you paste a CAPI access token from Events Manager instead.
tf('Purchase', {
value: 89,
currency: 'MYR',
email: 'customer@email.com'
});That call fires the browser event and the server event as a matched pair. The full walkthrough, including where to find a CAPI token in Events Manager, is in the Meta Ads guide.
How to tell whether it is working
- Check that events are arriving at all — in Events Manager, and in your own analytics.
- Look at the event match quality score for your server events. Below about 5 means you are sending too few identifiers.
- Compare server event counts against browser event counts. If the server count is far higher, browser blocking is significant — which is exactly why you installed CAPI.
- Check for duplicate counting: if reported purchases are roughly double your actual orders, your event IDs are not pairing.
The short version
Pixel for coverage, CAPI for accuracy, event IDs so they do not collide, hashed identifiers so matching works. Get those four right and your reporting stops lying to you — and your campaigns start optimising against something real.
If you would rather not build it, Dukun Ads installs both from a single snippet and shows conversions split by traffic source, with revenue attributed to paid ads versus free channels. Start free for 3 days.