Hunor.digital
← All writing
Attribution · Server-side · Tracking

Facebook CAPI vs pixel: do you need both?

Meta built them to run together, not compete. What each actually does, how deduplication keeps counts honest, and when CAPI is worth the plumbing.

Lázár HunorDigital Fixer
The short answer

Run both: Meta designed the Conversions API to work alongside the pixel, with event deduplication preventing double counting. The pixel captures browser context cheaply; CAPI restores events lost to blockers and iOS privacy and enables server-controlled data. CAPI alone is viable but harder; pixel alone leaves measurable money on the table at real ad spend.

The question arrives framed as a versus, and the framing is the first thing to fix: Meta did not build the Conversions API to replace the pixel. It built CAPI because the pixel's world (a browser that reliably runs Meta's JavaScript and carries its cookies) has been shrinking for years, between ad blockers, iOS privacy, and consent. The two are designed to run together, deduplicated, each covering the other's blind spots. So the real questions are: what does each actually contribute, and at what spend does the second one justify its plumbing?

What the pixel still does well

The pixel is Meta's script in the visitor's browser, and the browser is where context lives: the fbclid from the ad click, the fbp cookie, device signals, page behavior. When it works, it delivers rich matching signals at zero infrastructure cost to you, which is why it remains the baseline everyone installs in an afternoon.

When it works. The pixel's failure set is exactly the modern web's privacy machinery: blockers drop its script wholesale, Safari clips its cookies, declined consent (correctly) silences it. For a typical EU store, a real slice of true conversions simply never reaches Meta through the browser, and Meta's bidding optimizes against the partial picture it gets.

What CAPI actually adds

The Conversions API sends events server-to-server: your backend (or a server-side GTM container) tells Meta about the purchase directly, with hashed customer identifiers (email, phone) as matching keys. Three genuine gains:

And the caveat that belongs in the same breath: CAPI is not a consent workaround. A declined banner binds your server exactly as it binds the browser, and wiring consent into the server path is part of any honest setup, verifiable like everything else.

Why both, mechanically

Run in parallel, pixel and CAPI will often report the same purchase. Deduplication solves this: both paths send a shared event ID, and Meta keeps one copy. Done right, you get the union of both channels' visibility with no double counting. Done wrong (no event IDs, mismatched event names), you get inflated conversions and a bidding algorithm confidently optimizing toward noise, which is worse than either path alone. Deduplication is not an advanced option; it is the difference between "both" being an upgrade and a corruption. Test it the boring way: fire a test purchase, watch Events Manager, confirm one event survives.

The decision by spend, honestly

One measurement habit ties it together: track Meta's claimed conversions against your store's orders, before and after CAPI. The delta is your actual recovery, your only honest ROI figure for the project, and a number no platform will compute for you, because it is the one that keeps their homework graded by someone else. If the delta at your spend level would move real budget, the plumbing pays; if you cannot yet say, that baseline measurement is the first afternoon of work, and it costs nothing but honesty.