Conversions API vs Meta pixel: do you need both?

You set up the Meta pixel years ago. Now every guide, agency and app is telling you to add the Conversions API too. So which is it: Conversions API vs Meta pixel? Does the new one replace the old one, or are you supposed to run both and somehow not count every sale twice?

Short answer: run both. They aren't competing tools. They're two messengers carrying the same news by different roads, and each one reaches places the other can't. The rest of this post explains what each one actually does, where each one falls short, and how to make them work together without doubling your numbers.

The one-minute version

• The Meta pixel is code that runs in your shopper's browser. It sees what the shopper does on your site and knows a lot about the browser itself. But anything that blocks or interrupts the browser stops it.
• The Conversions API (CAPI) sends events from a server, a computer behind the scenes that the shopper never touches. Ad blockers and browser settings can't stop it. But it only knows what you hand it.
• Together, Meta gets the pixel's rich browser details and the server's reliability. A shared ID on each event lets Meta keep one copy of each sale.

If that's all you needed, you're done. If you want to understand why, and avoid the mistakes that make people regret the setup, keep reading.

What the Meta pixel does

The [Meta pixel](https://developers.facebook.com/docs/meta-pixel) (it used to be called the Facebook pixel) is a short piece of JavaScript you add to your website. When a shopper loads a page, the pixel loads too and sends Meta small messages called events: "someone viewed this product," "someone added to cart," "someone bought, for $64."

Because it runs inside the browser, the pixel picks up details for free:

• Meta's cookies. A cookie is a small note a website leaves in the browser so it can recognize it later. The pixel sets one called _fbp (a browser ID) and, when someone arrives from an ad, stores the click ID from the link in a cookie called _fbc.
• The shopper's IP address and device. The IP address is roughly the internet address of their connection. The user agent is a short description of their browser and device.
• What they did on the page. Which product, which variant, what was in the cart.

Those details are exactly what Meta needs to match a purchase to a person and to the ad they clicked. That matching is what lets Meta report results and, more importantly, learn who to show your ads to next.

Where the pixel falls short

The browser is a fragile place to send data from:

• Ad blockers stop the pixel script from loading. No script, no events.
• Browser privacy features, like Safari's tracking prevention , can shorten how long cookies last. A shopper who clicks today and buys next week may no longer carry the click.
• Shoppers leave early. If the order confirmation page never finishes loading because the shopper closed the tab or lost signal, the purchase event never fires.
• Slow or broken pages. A script error or a theme change can quietly knock the pixel out for days before anyone notices.

None of these show up as errors. Sales just go missing from Meta's view.

What the Conversions API does

The Conversions API is Meta's way of receiving the same events from a server instead of a browser. Your store, or a tool working on its behalf, sends a message straight to Meta: "order #1047, $64, here's who bought."

Because the server isn't on the shopper's device, nothing in the browser can block it. A purchase that the shopper paid for is a purchase the server knows about, whether or not the thank-you page ever loaded.

Where the Conversions API falls short

The server only knows what you give it. It doesn't automatically have:

• The shopper's cookies (_fbp, _fbc), because those live in the browser.
• The shopper's real IP address and device. If you don't pass them along, Meta sees your server's address, which is the same for every order and useless for matching.
• Browsing activity like product views, unless something on the site recorded it and passed it to the server.

A purchase sent by CAPI with no customer details is a purchase Meta knows happened but can't connect to anyone. It counts, but it teaches the algorithm very little.

Conversions API vs Meta pixel, side by side

Read that table down each column and the pattern is clear. Each one is strong exactly where the other is weak.

Why Meta recommends running both

Meta's own guidance is to send events through both the pixel and the Conversions API. This is called a redundant setup: each event is reported twice, by two different routes, so if one route fails the other still gets through.

Here's how that plays out for a few real situations:

• Sarah has no ad blocker and buys normally. Both the pixel and CAPI report her purchase. Meta keeps one copy, enriched with the cookies and device details the pixel sent.
• Jamal uses an ad blocker. The pixel never loads. CAPI still reports his purchase, and if your setup captured his details server side, Meta can still match it.
• Priya pays, then closes the tab before the confirmation page loads. The pixel misses it. CAPI, triggered by the order itself, does not.

With only the pixel, you lose Jamal and Priya. With only CAPI, you may lose the rich details on Sarah's purchase that help Meta match her. With both, you keep all three.

"Can't I just use CAPI and drop the pixel?"

You can, technically. But you'd have to rebuild in your server setup everything the pixel was doing for free: capturing the browser ID and click ID, the IP address and device, and every product view and add to cart. Most stores that drop the pixel end up with fewer, poorer events than they started with. The pixel costs nothing to keep, so keeping it is almost always the better trade.

The part that makes or breaks it: deduplication

If the pixel and CAPI both report Sarah's purchase, Meta now has two messages about one sale. Unless it can tell they're the same, it counts two sales. Your purchases double, your ROAS (return on ad spend: revenue divided by ad spend) looks fantastic, and none of it is real.

Meta prevents this with [deduplication](https://developers.facebook.com/documentation/ads-commerce/conversions-api/deduplicate-pixel-and-server-events): it compares two labels on each event and throws away the duplicate.

1. The event name. Both copies must use exactly the same name, like Purchase. Capital letters matter.
2. The event ID (event_id). A reference you attach to each event. If the pixel's copy and the server's copy carry the same event ID, Meta treats them as one.

The best event ID for a purchase is your order ID. Both the browser and the server know it, it never changes, and every order has a different one.

A worked example

Say your store took 200 orders last week, and Meta attributed $10,000 in revenue to your ads on $4,000 of spend. That's a ROAS of 2.5.

Now imagine you add CAPI but the event IDs don't match. The pixel uses a random number, the server uses the order ID. Meta sees two different events per order for every purchase both routes caught. If the pixel caught 170 of the 200 and CAPI caught all 200, Meta now counts 370 purchases. Reported revenue jumps toward $18,500, and ROAS appears to climb toward 4.6, with no change in what actually happened.

These numbers are made up for illustration, but the shape is what you'd see: a sudden jump in purchases right after "improving" tracking. That jump is the warning sign.

Common deduplication mistakes

• Generating a random ID on each side. Two random numbers never match.
• Different event names. Purchase from the pixel and purchase or Order Completed from the server.
• Two separate integrations sending CAPI. For example, Shopify's Meta app and a separate server setup both sending purchases with different IDs. Now you have three copies, not two.
• Sending the server event days later. Meta deduplicates within a time window, so a server copy that arrives much later than the browser copy may not be matched. Send server events promptly.

How to check your current setup

You don't need to be technical to spot most problems. Open [Meta Events Manager](https://www.facebook.com/business/help/898185560232180) (the part of Meta's business tools that lists the events you send) and look at your Purchase event.

1. Check which routes are active. Events Manager shows whether an event is arriving from the browser, the server, or both.
2. Look at the deduplication details. Meta shows whether browser and server events are being matched.
3. Compare to your store. Count orders in your store for a day and compare to purchases Meta received. Close to double means deduplication is broken. Far fewer means one route is failing.
4. [Check Event Match Quality](https://www.facebook.com/business/help/765081237991954). This score, from 0 to 10, grades how well Meta can match your events to people. A low score on server events usually means the customer details aren't being passed along.
5. Use the Meta Pixel Helper. It's a free browser extension from Meta that shows whether the pixel fired on a page and what it sent.

A checklist for running both well

1. Keep the pixel installed on every page, including checkout and the order confirmation page where your platform allows it.
2. Send purchases through CAPI from the order itself, not from the confirmation page, so a closed tab doesn't lose the sale.
3. Use the order ID as the event ID on both the pixel and server copies.
4. Spell event names identically on both routes.
5. Pass the shopper's details to the server: browser ID, click ID, IP address, device, and hashed email and phone. Hashing scrambles a value like an email into a code that can't be reversed, and Meta compares it to its own hashed records.
6. Make sure only one tool sends CAPI events for each event type.
7. Watch Events Manager for a week after any change, and compare against your store's real order count.

For a step-by-step walkthrough of the server side on Shopify specifically, see how to set up the Meta Conversions API on Shopify .

How Soran handles it

Soran records purchases on the server, so ad blockers, tracking prevention and closed tabs don't lose them. It creates your site tracker for you, and setup shows how many events arrived in the last 24 hours, so you can see tracking is working before you trust it.

Conversions then go back to Meta through the Conversions API with duplicate removal built in, and you can view and edit the fields that are sent. You connect Meta once. The same purchases also feed Soran's own attribution reports, so you see which ads earned each sale with credit split across every visit, not just Meta's version of events. If you want the bigger picture on that, what is multi-touch attribution is a good start.

Frequently asked questions

Is the Conversions API better than the Meta pixel?

Neither is better on its own. The pixel captures rich browser details but gets blocked; the Conversions API can't be blocked but only knows what you send it. Meta recommends using both, with matching event IDs so each sale counts once.

Will using both double my conversions in Ads Manager?

Not if deduplication is set up correctly. Ads Manager (where you create and review your Meta ads) reports one purchase per sale as long as Meta can match the two copies. Both copies of an event need the same event name and the same event ID. If your purchases suddenly double after adding CAPI, your event IDs almost certainly don't match.

Do I need a developer to set up the Conversions API?

Not necessarily. Shopify's Facebook & Instagram app can send server events at its higher data-sharing levels, Meta offers a no-code option called the Conversions API Gateway , and server-side tracking tools handle it for you. A developer is mostly needed if you build it yourself.

Does the Conversions API get around iOS privacy settings or consent?

No. It recovers events the browser would lose for technical reasons, like a blocked script or a closed tab. If a shopper has declined tracking, that choice still applies to events you send from the server.

Is the Facebook pixel the same as the Meta pixel?

Yes. It's the same tool, renamed when Facebook's parent company became Meta.

Want the pixel and the Conversions API working together without babysitting them? Book a demo and we'll walk through your setup.