Pixel, Conversions API, or both? A plain explanation of what breaks and what fixes it.

What each method can and cannot see

The browser pixel

A snippet of JavaScript in the shopper's browser. When somebody views a product or completes checkout, it reports the event to Meta from the shopper's own device. It has been the default since 2015 and it works well, right up until the browser stops it.

Three things now stop it routinely: Apple's App Tracking Transparency prompt, which most iOS users decline; Intelligent Tracking Prevention in Safari, which limits how long identifiers survive; and ad blockers, which are widespread among younger and more technical audiences. None of these are failures of your setup. They are the browser doing what its user asked.

The Conversions API

The same events, sent from a server instead of a browser. Because the event originates from your own systems rather than the shopper's device, it is unaffected by ad blockers and by browser tracking restrictions. For a Shopify store, this is available without custom development.

It is not a loophole around consent. Server-side events still carry consent state, and a shopper who has opted out should not have events sent about them. The gain is recovering the signal that browsers drop for technical reasons rather than privacy choices.

Running both without counting every sale twice

If both methods report the same purchase and Meta cannot tell they are the same purchase, your conversion count doubles and your reported ROAS becomes fiction. Deduplication is what prevents this, and it is where most broken setups break.

Meta matches a browser event and a server event as the same event when both carry the same event_name and the same event_id. Both fields, on both events. A server event sent with a freshly generated ID will never match its browser twin, no matter how identical everything else is.

Event match quality: the score nobody looks at

Sending an event is only half the job. Meta then has to work out which person it belongs to. It does that by matching the customer information attached to the event — hashed email, phone number, name, city, IP address, browser identifier — against its own records.

Events Manager scores this as Event Match Quality, roughly 1 to 10. A purchase event carrying only an IP address matches poorly. One carrying hashed email, phone, name and address matches well. The score matters because it directly determines how many of your conversions get attributed at all, and how well the delivery system can find more people like your buyers.

This is the highest-leverage tracking fix available to most stores, and it is almost always ignored in favor of more exotic explanations for poor performance. If your purchase event match quality is below about 6, fix that before you rebuild your campaign structure.

• Send hashed email on every purchase event — it is the single strongest matching signal
• Send phone number where you collect it, which for most Indian and Southeast Asian stores is every order
• Send first name, last name, city, state, zip and country from the order
• Include the browser identifiers (fbp and fbc) on server events, not just browser events
• Send the external ID you already have — your own customer identifier, hashed

The quarterly tracking check, in order

Tracking does not fail loudly. It fails when a theme is updated, an app is uninstalled, a checkout extension changes, or a consent banner is reconfigured — and the first symptom is a performance decline that looks like a media problem.

1. Is the purchase event still firing? Place a real test order and watch it arrive.
2. Is it firing exactly once per order, from each source?
3. Is deduplication collapsing the browser and server pair?
4. Is the reported purchase value in the same currency as the ad account?
5. Is event match quality above 6 on purchase, and above 5 on add-to-cart?
6. Are the events arriving within minutes, rather than hours late?
7. Does the daily count of purchase events roughly track your daily order count, allowing for the attribution gap?

None of these require a developer. All of them are visible in Events Manager. The reason they go unchecked is not difficulty — it is that nothing prompts anyone to look until revenue has already fallen.