Event Match Quality: The Score Behind Your Meta Results
You set up the Conversions API, Events Manager gives your Purchase event a score out of ten, and nobody explains what it means. Here's what that number actually measures, why it quietly decides how well your ads perform, and how to improve it on Shopify.
What the Conversions API Actually Is
The Meta pixel is a piece of code that runs in your customer's browser and reports what they do: viewed a product, added to cart, bought something. The problem is that browsers have spent the last few years learning to shut it up. Ad blockers block it, Safari restricts it, and a large share of iPhone users have told Apple they don't want to be tracked at all. A browser-only pixel undercounts, often by a meaningful chunk. I've covered the symptoms of that in why your Meta pixel isn't tracking purchases.
The Conversions API, usually shortened to CAPI, is Meta's answer. Instead of relying only on the customer's browser, your server (or Shopify's, on your behalf) sends the same events directly to Meta. A server-to-server message can't be ad-blocked, and it doesn't care what Apple thinks.
The standard setup is both at once: the browser pixel and server events, covering each other's gaps. Which immediately raises two questions. If both report the same purchase, why isn't everything double counted? And how does Meta know which person a server event belongs to? Those two questions are deduplication and Event Match Quality, and they're what the rest of this page is about.
Deduplication: How One Purchase Stays One Purchase
When the browser pixel and the server both report the same purchase, Meta needs a way to recognise them as the same event. It does this with a shared event ID: a unique reference, generated once per event, that both the browser and the server attach to their copy.
The precise rule matters, so here it is: Meta treats two events as duplicates when they have the same event name (both "Purchase") and the same event ID, arriving on the same pixel. When that happens, Meta keeps one and discards the other, and your reporting shows a single purchase. If the browser copy never arrives, because an ad blocker ate it, the server copy stands alone and the purchase still gets counted. That's the whole design: redundancy without double counting.
It also means the failure modes are predictable. If your browser and server events carry different event IDs for the same purchase, or one side sends no ID at all, Meta sees two distinct purchases and your numbers inflate. If something mangles the event name on one side, same problem. Shopify's native Facebook & Instagram integration handles the IDs for you, which is one of the better arguments for using it rather than stitching your own setup together from apps and snippets.
What Event Match Quality Actually Measures
A server event arrives at Meta saying "somebody bought something for £80". For that to be useful, Meta has to work out which somebody, so it can credit the right ad and feed the right signal back into delivery. Event Match Quality, EMQ, is a score out of ten telling you how well-equipped your events are for that matching job.
The raw material is the customer information attached to each event, what Meta calls identity parameters:
- Email address and phone number, the strongest identifiers, since they map directly to Meta accounts.
- Name, city, postcode, country, weaker individually, useful in combination.
- External ID, your own customer reference, which helps Meta connect repeat events from the same person.
- The fbp and fbc browser cookies. The fbp cookie identifies the browser; fbc captures the click ID from the fbclid parameter Meta adds to ad URLs, tying a purchase back to the specific ad click.
- IP address and user agent, background signals that support the rest.
Personal details like email, phone and name are hashed before they're sent, run through a one-way function that turns them into a fingerprint. Meta compares fingerprints against its own hashed records, so matching works without your customer's email travelling anywhere in readable form. That's not a reason to be careless, but it's worth knowing the mechanism when someone asks what you're sending to Facebook.
More parameters, correctly formatted, on a higher share of events, equals a higher score. That's all EMQ is.
Why the Score Matters
It would be easy to dismiss EMQ as another vanity metric. It isn't, for two reasons.
Attribution. If Meta can't match a purchase to a person, it can't credit the campaign that drove it. Your ads look worse than they are, your cost per purchase looks higher than it is, and you make budget decisions on wrong numbers.
Delivery. This is the one people miss. Meta's delivery system optimises towards people likely to convert, and it learns from matched conversions. Unmatched events teach it nothing. A higher match rate means more training signal, which means the algorithm finds buyers faster and your results improve, not just your reporting. Better matching genuinely is better performance, which is why it's worth an afternoon of anyone's time.
Rough benchmarks: for a Purchase event, a score around 6 is workable, 8 or above is genuinely good, and below about 5 means you're leaving attribution and performance on the table. Meta rates scores as poor, okay, good and great rather than publishing hard thresholds, and typical scores vary by event type, so treat these as working numbers rather than gospel. Purchase events should score highest, since that's where you hold the most customer data.
How to Improve It on Shopify
You'll find the score in Events Manager: open your pixel, pick an event, and look at the Event Match Quality column. Click into it and Meta lists which parameters it's receiving and which it isn't. That list is your to-do list. On Shopify, improving it usually comes down to three things.
1. Check What the Native Integration Is Sharing
The Facebook & Instagram app has a customer data-sharing setting with levels (the naming shifts, but it runs from basic through to maximum). At the lower levels Shopify sends events with minimal customer information; at the top level it includes the identity parameters, hashed, that EMQ feeds on. A surprising number of stores are quietly sat on a conservative setting someone chose during setup years ago. Turning data sharing up to the fullest level, assuming your privacy policy and consent setup cover it, is the single quickest EMQ win available.
2. Send What You Already Know
By the time someone completes checkout, you know their email, name and address, they've just typed it all in. There's no excuse for a Purchase event that arrives with nothing but an IP address. The native integration at full data sharing handles this for purchases; where stores fall down is earlier events (add to cart, begin checkout) and custom setups that never wire the customer data through. If you're running a custom or third-party CAPI setup, check what's actually attached to each event type, not what the app's marketing page says.
3. Make Sure fbp and fbc Survive
The fbc parameter is disproportionately valuable because it links a conversion to the exact ad click. But it only exists if the fbclid from the ad URL gets captured into a cookie and then passed through to your events. Two things break it on Shopify: redirects that strip URL parameters before the landing page, and the custom pixel sandbox, which walls tracking code off from the page and can stop it reading the cookies and parameters it needs. If your EMQ breakdown shows fbc missing on nearly all events despite plenty of ad traffic, that's the trail to follow, and I've written up the sandbox problem in detail: what Shopify's custom pixel sandbox breaks.
When Deduplication Goes Wrong
Two symptoms tell you dedup is broken, and they point opposite ways.
Purchases counted twice. Meta reports roughly double what Shopify does, and in Events Manager you can see Purchase arriving from both browser and server without being merged. Cause: mismatched or missing event IDs, usually because two separate integrations are each doing their own thing. The fix is one integration handling both channels, not two half-setups. Worth saying: Google has exactly the same failure mode, which I've covered in Google Ads counting conversions twice.
Purchases quietly dropped. Rarer, but nastier: if your setup reuses the same event ID across different purchases, Meta deduplicates events that were never duplicates, and real orders vanish from reporting. If Meta consistently reports fewer purchases than the browser pixel alone used to, check whether your event IDs are actually unique per order.
The diagnosis tool for both is the same Test Events screen in Events Manager: place a test order and watch whether the browser and server copies arrive, and whether they merge into one event or sit there as two. Five minutes of looking beats a week of theorising.
None of this is difficult, exactly. It's just precise, and precision is the bit that gets skipped when tracking is treated as a checkbox during store setup. If your EMQ is low, your dedup is questionable, or you've never actually compared Meta's purchase count to Shopify's, that comparison is where I'd start.
Questions People Ask
The Conversions API generates more confusion per install than anything else Meta has shipped. Here are the usual ones.
As a working rule for a Purchase event: around 6 is acceptable, 8 or above is genuinely good, and below about 5 is costing you attribution and performance. Meta labels scores poor, okay, good and great rather than fixed thresholds, and earlier funnel events naturally score lower because you know less about the visitor.
Yes. Meta recommends running both, because the browser pixel supplies signals the server doesn't have, including the fbp and fbc cookies that boost match quality, and it covers on-site events that server setups often skip. The pair, correctly deduplicated with shared event IDs, beats either alone.
Almost always because the browser and server copies of each purchase carry different event IDs, or no IDs, so Meta can't merge them. The usual culprit is two separate integrations running at once, the official app plus an old manual pixel or a third-party tracking app. Consolidate to one setup that manages both channels.
Both the browser and the server attach the same unique event ID to their copy of an event. When Meta receives two events with the same event name and the same event ID on one pixel, it keeps one and discards the other. If only one copy arrives, it counts normally, which is what makes the redundancy safe.
Both. Matched conversions are what Meta's delivery system learns from, so a higher match rate gives the algorithm more signal to find likely buyers with, on top of crediting your campaigns accurately. Improving EMQ is one of the few tracking jobs that directly improves results rather than just the reporting of them.
Three steps: turn the Facebook & Instagram app's customer data-sharing setting up to its fullest level, make sure customer details you already hold are attached to server events, and check the fbp and fbc cookies are being captured and passed through, which redirects and the custom pixel sandbox can silently break.
Want Your Score Sorted?
I'll go through your pixel, your CAPI setup, your event IDs and your match quality breakdown, tell you exactly what's missing and fix it. Start with the tracking health check, or just ask.
More Tracking Guides
If your pixel has bigger problems than its match score, start with why your Meta pixel isn't tracking purchases and the Shopify custom pixel sandbox. Sending events from your own server properly is what server-side tracking is for, the whole setup is checked as part of the tracking health check, and if you want the campaigns run as well as measured, I do Facebook and Instagram ads too.