Meta Conversions API: Why the Pixel Misses Conversions and How to Connect It Properly

A store owner sees more orders in the Salla or Zid dashboard than Meta reports, concludes the campaign is weaker than it is, or pauses an ad that was selling. The algorithm itself learns from incomplete events, so it searches for buyers using a partial picture of who actually bought.

Part of that gap is normal and can't be closed entirely. But a large part comes from hanging all tracking on the customer's browser. That's where Conversions API comes in.

Why doesn't the Meta pixel record every purchase?

The pixel is code running in the visitor's browser. When a customer buys, the browser sends the purchase event to Meta. That was enough a few years ago, but several things now cut the line between the browser and Meta:

• iOS privacy restrictions: when users decline app tracking, less data arrives from Meta's in-app browser and from apps.
• Browsers that restrict cookies and shorten their lifetime, such as Safari, so the link between click and purchase is lost if the purchase comes days later.
• Ad blockers and privacy extensions that block the pixel code so it never loads.
• Thank-you pages that don't fully load, customers who close the page before the send completes, or payment through an external gateway the customer never returns from.

The result: a real purchase happened and was recorded in your store, but Meta never heard about it. The campaign that drove it gets no credit.

What is Conversions API?

It doesn't replace the pixel. Meta itself recommends running both: the pixel captures browsing and add-to-cart activity in detail, and the server makes sure important events, especially purchases, arrive even when the browser fails.

And don't think of it as a reporting fix only. Its bigger effect is on performance: an algorithm learning from more complete events knows more precisely who buys, and steers spend toward people like them.

How do I stop events being counted twice between pixel and server?

This is the most common mistake I see. With the pixel and server both running, both send the same purchase. If Meta doesn't know they're one event, it counts two purchases, your numbers double, and the campaign looks better than it is.

The fix is for the event from both sides to carry the same event name (such as Purchase) and the same event_id. The best value for that ID on a purchase is the order number itself, because it's unique and available in both the browser and the server. Meta merges the two if they arrive with the same ID within 48 hours.

What is Event Match Quality?

When an event arrives from the server, Meta needs to know which of its users it belongs to. Event Match Quality is a rating shown in Events Manager for each event, and it reflects how well Meta can connect your events to real accounts.

The score rises the more, and the more accurate, customer information you send with the event:

• Email and mobile number, hashed with SHA-256 before sending.
• The browser ID fbp and click ID fbc, which link the purchase to the ad click. Sent as they are, not hashed.
• The customer's IP address and user agent, not hashed.
• Your store's customer ID (external_id) if available.

Don't send data the event doesn't need, and never send sensitive data. Show visitors a clear privacy notice that explains measurement. That's what I apply in practice; it isn't legal advice.

How do I connect Conversions API on Salla, Zid and Shopify?

The good news is that most Saudi stores don't need custom code. The big platforms offer a ready connection; your job is to switch it on correctly and then verify it:

Platform interfaces change with updates, so don't rely on a particular button's location. What matters is knowing what's needed: the pixel ID, the access token you generate in Events Manager, and server events switched on.

The most common problem I see in hosted stores isn't a missing connection but a duplicated one: the platform's official integration is on, and on top of it someone else installed the pixel by hand through Google Tag Manager or a code field. Each event then arrives from three sources. Before connecting anything new, find out what is already installed.

How do I confirm in Events Manager that it works?

1. 1Open Events Manager and select your store's dataset (pixel).
2. 2In the overview, select the Purchase event and check that the connection method shows both browser and server.
3. 3Use the Test Events tool and place a test order at the lowest possible value.
4. 4Confirm the purchase appears once, marked as deduplicated from both sources, not twice separately.
5. 5Check the Event Match Quality score for Purchase after a few days of data, and see what information Meta suggests adding.
6. 6After a week, compare purchases in Meta with orders in your store for the same period, remembering that Meta counts by attribution window, not just by order date.

The two numbers won't match exactly, and that's expected: not every order came from Meta ads, and some orders won't be linked to any user. But the gap should be explainable, not double and not half.

When is Conversions API not worth the effort yet?

If the pixel itself isn't installed correctly, start there. Adding the server on top of a broken pixel doubles the problem instead of solving it. And if you don't advertise on Meta, or spend very little with no purchase event on the site, the priority is basic measurement in GA4 first.

If your sales close on WhatsApp rather than in the store, a server-side purchase event won't cover most of your sales. You need a way to connect conversations to ads first.

If you want to know whether your pixel and Conversions API are working correctly or duplicating events, message me on WhatsApp. I start with an audit of what's installed and what's missing before changing anything.