Meta Ads Tracking

Meta Pixel vs Conversions API for Shopify

The Pixel and the Conversions API aren't competing options — they're two different routes for the same event, each catching what the other misses. The question isn't which one to use. It's how to run both without counting the same purchase twice.

What the Pixel sees

The Meta Pixel is JavaScript running in the customer's browser. It fires when a page loads or an action happens — a product view, an add-to-cart, a purchase — and sends that event straight from the browser to Meta. It's fast to set up and gives Meta direct browser-side signal, but it only works if the browser actually lets the request through.

Where browser tracking breaks down

Ad blockers stop the Pixel request outright. Safari's Intelligent Tracking Prevention trims how long identifiers survive. A slow connection can mean the customer completes checkout and closes the tab before the purchase event finishes firing. None of these are edge cases — on iOS traffic in particular, browser-side purchase tracking commonly misses a meaningful share of real orders, and that share isn't visible anywhere in Ads Manager; it just looks like the ad performed worse than it did.

What CAPI adds

The Conversions API sends the same kind of event — a purchase, a lead — server-to-server, directly from your backend to Meta, rather than relying only on browser-side delivery. It isn't affected by ad blockers or cookie lifespan, because it never depends on the customer's browser successfully sending the request. It depends instead on your server actually knowing the order happened, which for a Shopify store means firing it from an order webhook or a checkout completion event.

Running both without double-counting

If the Pixel fires for a purchase and the server also fires a CAPI event for the same purchase, Meta will count two sales unless it's told otherwise. The fix is a shared event_id — the same identifier attached to both the browser and server event for that order. Meta uses it to recognize the pair and count the purchase once. Skip this and duplicate purchases in Ads Manager is the most common symptom.

Simplified — illustrative, not literal API payload structure.

CAPI doesn't get around consent

It's tempting to think of server-side tracking as a way past browser-based tracking restrictions. It isn't. CAPI changes the route data travels — server to server instead of browser to server — not whether you're allowed to send it. A customer who declined tracking consent should be excluded from both the Pixel and the server-side event, the same way they would be excluded from any other tracking method.

Common questions

Can I just use CAPI and drop the Pixel?

Technically yes, but Meta's own guidance is to run both — the Pixel still contributes browser-side signals like browsing behavior that CAPI alone doesn't replicate, and having both gives you two independent paths for the same event.

Does CAPI need the customer's consent?

Yes. CAPI changes how an event reaches Meta, not whether you're allowed to send it. If a customer hasn't consented to tracking, the corresponding server event shouldn't be sent either.

What happens if I don't deduplicate?

Meta counts the browser and server events as two separate purchases, inflating your reported conversions and usually confusing automated bidding, which optimizes toward a number that doesn't match reality.

See your Pixel and CAPI coverage

Connect your store and Meta account to see which purchases are landing through the Pixel, the server event, or neither.

Start free trial See how it works