Turning on the Conversions API is not the same as setting it up. Most UAE Shopify stores AdGrow audits have it enabled and still report badly, because the browser pixel and the server events are not being matched to each other. The result is double counted purchases, which looks like better performance and is actually worse data.
The short version
- Enabling the Conversions API without deduplication makes reporting worse, not better. Each purchase gets counted twice.
- Deduplication depends on the event ID matching between the browser event and the server event. That is the whole mechanism.
- Customer data quality drives match rate. Email, phone and country sent properly are worth more than any setting in the ad account.
- Payment redirects are where UAE and Gulf stores lose the most events, because the customer leaves the site at the moment that matters.
What problem is the Conversions API actually solving?
The browser pixel is unreliable and getting more so. Ad blockers remove it, browser privacy settings restrict it, and iOS limits what it can retain. So Meta sees fewer purchases than actually happened, attributes fewer sales to your ads, and optimises on an incomplete picture.
The Conversions API sends the same events from the server instead, where none of that interference applies. Both channels report the same purchase. That is the point, and it is also the trap.
Why does turning it on sometimes make things worse?
Because if Meta cannot tell that the browser event and the server event describe one purchase, it records two.
Your reported conversions rise. Your reported return on ad spend rises with them. Nothing in the interface warns you. The first sign is usually that Meta is claiming substantially more orders than Shopify, in a pattern that looks like the ordinary discrepancy every store has but is arithmetically different, because it is close to a clean multiple.
We wrote about how to tell a normal gap from a broken one in why your Shopify numbers do not match Ads Manager. Double counting is the version of that problem people create for themselves.
How does deduplication actually work?
Every purchase generates one event ID. The browser sends it. The server sends the same one. Meta sees two events carrying an identical ID and understands them as one purchase reported twice.
If the IDs do not match, or the server event omits the ID entirely, deduplication fails silently.
| Check | What good looks like | What it costs you if wrong |
|---|---|---|
| Event ID present on both | Identical ID, browser and server | Every purchase counted twice |
| Event name matches | Purchase on both sides | Deduplication never attempts |
| Customer data sent | Hashed email, phone, country | Low match rate, weak attribution |
| Event Match Quality | Reported as good in Events Manager | Meta cannot connect the sale to a person who saw the ad |
| Single source of truth | One integration, not app plus theme code | Duplicate pixels firing alongside each other |
What breaks specifically on Gulf stores?
Two things, repeatedly.
The first is payment redirects. When a customer is sent to a bank page or a split payment provider to authorise, they leave your site. If they close the tab after paying, the browser event never fires. The server event still does, which is exactly why the Conversions API matters more here than in a card first market.
The second is cash on delivery, which is not a tracking failure but a definition problem. The order exists. The money may not arrive. If you send a purchase event when the order is placed, you are telling Meta to find more people who place orders rather than more people who pay for them. The full version of that argument is in how cash on delivery breaks your reporting.
What changes once it is right?
Attribution gets more complete, which usually means Meta claims more of the sales it was already producing. That is not new revenue on day one. It is the account finally seeing what it did.
What follows from that is real. With reliable purchase data the algorithm optimises against actual buyers, and audiences built from purchase events stop being polluted with people who abandoned. On the UAE store where our tracking is cleanest, a single quarter returned AED 478,539 with 51.6 percent of it coming from customers who had bought before. You cannot see a number like that, let alone act on it, if half your purchase events never arrive.
A mistake we made: we once installed the Conversions API through a Shopify app on a store that already had pixel code pasted into the theme by a previous developer. Both fired. Neither knew about the other. Reported purchases jumped by roughly two thirds overnight and we spent a week congratulating ourselves before someone reconciled against the bank. Now the first thing we do on any new account is search the theme for hardcoded pixel IDs before installing anything.
If Meta is reporting noticeably more orders than your store is, we can tell you within an hour whether that is normal attribution or double counting. Book a growth call, or see how we set up tracking.
Frequently asked questions
Yes. Meta expects both, and running them together with correct deduplication gives better coverage than either alone. The browser event supplies signals the server does not have, and the server event fills the gaps the browser misses.
Compare Meta reported purchases against Shopify orders for the same window. Ordinary attribution differences look untidy. Double counting looks close to a clean multiple. You can also check the deduplication status directly in Events Manager.
It scores how well Meta can connect an event to a real person using the customer data you send. It matters a great deal, because an event Meta cannot match to a user who saw your ad contributes almost nothing to attribution or optimisation.
Not at the point the order is placed, if you can avoid it. Sending the event on order creation teaches the algorithm to find people who place orders rather than people who pay. Firing on confirmed delivery gives a truer signal, at the cost of some delay.
Not directly. It makes Meta aware of sales it was already generating but could not see, and better data then improves optimisation over time. Expect reported performance to improve first and actual performance to follow, rather than the other way round.