Meta doesn't know which sale came from you

The classic Meta Pixel is a piece of JavaScript running in the browser. Whether a purchase event reaches Meta depends on the user's browser sending that request — and browsers have spent recent years being redesigned to restrict exactly this kind of request.

WebKit, the engine behind Safari, announced in 2020 that cookies for cross-site resources are blocked by default, and in the same update capped all script-writable storage — LocalStorage, IndexedDB, SessionStorage and Service Worker registrations among them — at seven days, deleting that data if the user doesn't interact with the site (WebKit, 2020). Add ad blockers, network failures and checkout flows that never land on a thank-you page.

The result: purchases measured in the browser are always a subset of purchases that actually happened. Meta's answer is the server-side Conversions API — sending the event from your own server instead of the user's browser. A correct setup today isn't "Pixel or CAPI"; it's both, working together and aware of each other.

Setup isn't a yes/no state, it's a quality scale. Meta's Dataset Quality documentation defines several independent metrics for the health of a dataset — all visible in Events Manager (Meta for Developers). In practice it breaks at these five points:

1. The Purchase event arrives without a value

Meta's Pixel reference lists currency and value as required for the Purchase event (Meta for Developers). If they're empty, Meta knows a sale happened but not how large it was — your ROAS math and value optimization have no ground to stand on. The same reference makes contents/content_ids required for Advantage+ catalogue ads on AddToCart and ViewContent; if you run catalogue ads, missing those fields means the format simply can't work.

2. Server-side event coverage is low

"Setting up" the Conversions API isn't sending a single event from your server. Meta measures this as event coverage: the 7-day average percentage of Pixel events covered by Conversions API events sharing deduplication keys. The documentation's own example is clear: if an advertiser has ViewContent, AddToCart and Purchase but only sends Purchase from the server, event coverage is 33%. The same document treats 75% as the threshold (Meta for Developers).

3. Match keys are weak

Event Match Quality (EMQ) is a score out of 10 indicating how effective the customer information sent from your server may be at matching event instances to a Meta account. Meta states it is calculated by looking at which customer information parameters are received, the quality of that information, and the percentage of event instances matched to a Meta account — and that high quality event matching may improve ads attribution and performance (Meta for Developers). Note the wording: Meta writes "may improve", not "will improve", and so do we.

4. Events arrive late

Data freshness measures the delay between when an event occurred and when Meta received it. The Pixel defaults to real time; server-side setups that batch uploads daily are common. Meta recommends sharing events in real time or as close to real time as possible, and notes that events sent with a delay may impact how effectively ads can be delivered to the right audiences (Meta for Developers).

5. Your server sends mismatched IP addresses

One of the diagnostics examples in the documentation is exactly this: a server sending client IP addresses that don't match those from the Meta Pixel — which, in Meta's own words, may impact the attribution and optimization of your ad campaigns. The recommended fix is to send the client_ip_address retrieved from customer interactions in your server payload. It's one of the details most often skipped when server-side setup is handed to a developer as a one-off task.

If you use the Pixel and the Conversions API for the same events, Meta receives the same purchase through two channels. Collapsing them into one requires deduplication — without it, you see inflated purchases that never happened.

For an event to be deduplicated: a Facebook Pixel's eventID must match the conversion API's event_id, and a Facebook Pixel's event must match the conversion API's event_name.

— Meta for Developers, Deduplicate Pixel and Server Events

Three mechanics are worth knowing (Meta for Developers):

• If the same event_id + event_name combination reaches the same pixel ID a second time within 48 hours, the subsequent events are discarded. A copy arriving after that window counts as a separate event — so a server integration that uploads in a nightly batch can turn into double counting if the delay stretches.
• If the server and browser events arrive at approximately the same time (within 5 minutes of each other), Meta favours the browser event.
• Sending different events through different channels is also a legitimate setup: if you send Purchase via the Pixel and AddToCart via the Conversions API, you don't need to think about deduplication at all. The decision is which event goes through which channel.

On the Pixel side, eventID is passed as a fourth parameter to fbq('track', ...); Meta recommends including it in any setup running alongside the Conversions API (Meta for Developers). The deduplication key feedback section in Events Manager shows what percentage of your browser and server events actually carry those keys — a low percentage there points straight back at the setup.

Meta has a dedicated metric for this: Additional Conversions Reported (ACR). It's defined as a metric that helps you understand how much your business benefits from using the Conversions API alongside the Meta Pixel; Meta adds that more reported conversions can help decrease your cost per result and show your ads to people who find them relevant (Meta for Developers).

Here's where honesty matters, because this is the most distorted metric in marketing content: ACR measures the increase in reported conversions. Sales that were already happening but that Meta couldn't see now become visible. That's less blindness, not more revenue. Seeing your purchase count rise after fixing measurement is the expected outcome — the money in your account that night hasn't changed.

The benefit is real but indirect: a more complete signal means the delivery system learns better whom to target. Whether and when that shows up in performance is neither immediate nor guaranteed.

Even with measurement working perfectly, one question remains open: would the sale Meta attributes to your ad have happened anyway? Attribution and incrementality are not the same thing.

The best-known academic evidence on this gap comes from Facebook's own data. Gordon, Zettelmeyer, Bhargava and Chapsky used 15 US advertising experiments at Facebook — 500 million user-experiment observations and 1.6 billion ad impressions — to contrast randomized controlled trial results with those from multiple observational models. The finding: the observational methods often failed to produce the same effects as the randomized experiments, even after conditioning on extensive demographic and behavioural variables (Gordon et al., 2019).

What that means in practice: fixing your measurement infrastructure makes the number you see counted correctly; it doesn't prove that number is the difference your ads made. At the point where you scale budget seriously, what you need isn't a better pixel — it's an experiment design (holdout tests, geo splits, branded search controls). On the creative side, we cover how to build that experiment and when to believe the winner in our piece on testing five hooks.

An audit you can run in Events Manager in half an hour:

• Place a test order with the Test Events tool: does the whole ViewContent → AddToCart → InitiateCheckout → Purchase chain fire?
• Are value and currency populated on Purchase — and does the value match the real cart total, or is it a fixed number with shipping and tax baked in?
• Deduplication key feedback: what percentage of your browser and server events carry event_id?
• Event coverage: how many events have a server-side counterpart, and where do you sit against the 75% threshold?
• EMQ: what's your score for Purchase, and which match keys are missing?
• Data freshness: are your server events real_time, or hourly/daily?
• Diagnostics: have the warnings — especially IP mismatch — been resolved?

Most of this belongs before you spend on ads. For the wider picture on the ads side, our starter guide to Instagram advertising for beauty brands puts this setup in context; and since half of measurement breaks on the store side, see the Shopify store setup guide for cosmetics brands and our web & e-commerce service.