Skip to main content

Tracking

Conversion API vs Pixel

Quick Answer

The Meta Pixel tracks conversions from the browser (JavaScript + cookies). The Conversions API (CAPI) sends the same conversions from your server, independent of the browser. They aren't either/or — Meta recommends running both, with event deduplication so nothing double-counts. The Pixel adds context; CAPI adds durability as browser tracking degrades.

Last verified July 2026 against Meta's developer documentation.

Browser vs server, at a glance

Meta Pixel versus Conversions API comparison
Meta Pixel Conversions API (CAPI)
Where it runsVisitor's browser (JavaScript)Your server
Relies onCookies (_fbp), fbclidServer-to-server request; independent of cookies
Blocked byAd blockers, ITP, cookie restrictionsNot blocked by browser tools
StrengthRich in-session/browser contextDurable, complete event coverage
Best usedTogether — same events through both, deduplicated

Why Meta says run both

It's tempting to read "server-side is better" and drop the Pixel. Don't. Meta's guidance is a redundant event setup: send the same conversion events through both the Pixel and CAPI.

  • The Pixel captures browser context you can't easily reconstruct on the server.
  • The CAPI recovers the events the browser loses — to ad blockers, dropped connections, and privacy restrictions like Safari ITP and third-party cookie deprecation.

Run only the Pixel and you leak conversions as browsers tighten. Run only CAPI and you lose browser signal and complicate setup. Run both and you get the widest coverage and the best match quality — which is why the Pixel is not deprecated; it's one half of the recommended pair.

How deduplication keeps it honest

If you send the same purchase from both the browser and the server, won't Meta count it twice? No — as long as you deduplicate correctly:

  • Meta deduplicates on event_name + a shared event_id. Send the same event_id from the Pixel and CAPI for the same event, and Meta counts it once while enriching from both sources.
  • The match applies when the two events arrive within a 48-hour window.
  • fbp (from the _fbp cookie) and fbc (derived from the fbclid click ID) are user-matching signals — not the primary dedup key. event_id is. And fbp/fbc must be sent unhashed.

The one thing to get right: generate a single event_id per event and pass the identical value through both paths. Skip that and you either double-count or fail to merge.

What this means for affiliates

If you run paid traffic to a bridge page, the Pixel alone will under-report as browser signals decay. Add the Conversions API, preserve the click ID so CAPI can match on the ad click, and share one event_id across both. Most affiliate trackers (Voluum, RedTrack, and others) can fire server-side events for you; a custom stack has to handle the event_id and click-ID plumbing explicitly.

This browser-tag-plus-server-API pattern isn't Meta-only — Google, TikTok, Microsoft, and LinkedIn all do the same. See the click ID reference for each platform's identifier, and the tracking-setup playbook for the end-to-end build.

Frequently asked questions

What is the difference between the Conversion API and the Pixel?

The Meta Pixel is browser-side: JavaScript on your page fires events from the visitor's browser, relying on cookies and the fbclid click parameter. The Conversions API (CAPI) is server-side: your server sends the same events directly to Meta, independent of the browser, cookies, and ad blockers. The Pixel captures rich in-session context; CAPI is resilient when browser signals are lost. Meta recommends running both.

Do I need both the Pixel and the Conversions API?

Meta recommends a redundant setup — send the same conversion events through both the Pixel and CAPI. The browser Pixel adds session context; the server CAPI recovers events lost to ad blockers, network issues, and cookie/tracking restrictions like Safari ITP. Together they improve event coverage, match quality, and optimization, while deduplication ensures conversions aren't counted twice. The Pixel is not deprecated.

How does event deduplication work?

When you send the same event from both the Pixel and CAPI, Meta deduplicates on event_name plus a shared event_id: if a browser event and a server event carry the same event_name and event_id, Meta counts them once while enriching from both sources. Meta matches them as duplicates when received within a 48-hour window. The fbp and fbc parameters are user-matching signals, not the primary deduplication key — event_id is.

Does this only apply to Meta?

The head term "conversion API vs pixel" is usually about Meta, but the pattern is industry-wide. Google (Enhanced Conversions / Google Ads API), TikTok (Events API), Microsoft, LinkedIn, and others all pair a browser tag with a server-side conversion API. The strategy is the same everywhere: run the browser tag for context, add the server API for durability, and pass the platform's click ID so conversions match.

Related terms

Put it to work

Set up Pixel + CAPI without double-counting

The tracking-setup playbook covers the full browser-tag + server-API build, including sharing one event_id and preserving click IDs.