Meta Event Match Quality Low on Shopify? How to Fix It
Meta Event Match Quality low on Shopify? See which customer details each event carries, why add-to-cart scores below purchase, and what to fix or ignore.
Quick answer: Event Match Quality (EMQ) is Meta’s score out of 10 for how well the customer details sent with a server event can be matched to a Meta account. On Shopify it is usually lower for add-to-cart than for purchase because the shopper has not given an email, phone number or address yet, and Shopify’s own add-to-cart event data contains none. Fix Purchase first (Meta typically recommends aiming for 6.0 or higher where possible), check your Shopify data-sharing level, consent setup and duplicate pipelines, and treat the upper-funnel scores as diagnostics, not targets. Settings and figures here are as at 31 October 2026.
You open Meta Events Manager and Purchase says one number, while AddToCart and ViewContent, if they appear at all, say lower ones. Meta suggests ways to improve each. If you run Meta ads on a Shopify store, it is easy to spend a week trying to push every number up, buy a tracking app to do it, and still not know whether your ads got any better.
This guide is about what the score actually measures, which customer details Shopify can pass at each step of the shopping journey, why the early events score lower, and how to decide what is worth fixing. It is written for a founder who has a Meta pixel and Conversions API connected through Shopify’s Facebook and Instagram app, or is not sure whether they do.
Two honest limits first. I do not run Meta ads, so this is a measurement guide, not an ad-account guide. And Shopify does not publish a field-by-field list of what its Facebook and Instagram app sends to Meta at each event, so where I infer something from Shopify’s and Meta’s documentation I say so, and I show you how to check it in your own account.
What Event Match Quality measures
Meta’s Business Help Centre says EMQ is available for website events sent through the Conversions API (CAPI) with the action source set to Website. It describes the score as an indication of how effective the customer information parameters sent with your server event may be at matching that event to Meta accounts.
It is a score for server events only. If an event reaches Meta only through the browser pixel, there is no EMQ for it. Meta’s developer documentation also says EMQ is currently available only for web events, not offline, app or conversion lead events.
It is a prediction about matching, not a measure of sales. The word “may” is in Meta’s definition. A high score does not mean your ads work and a low one does not mean they are broken.
It is per event. Meta’s help page says scores are available for standard and custom web events, such as page view, add to cart and purchase. So there is no single “your store’s score”. There is one number per event.
What the score is built from
According to the Help Centre, Meta calculates the score from two things: the quality of the customer information you send with a specific server event, and the percentage of those event instances that are matched to Meta accounts. It uses the last 48 hours of data, which is why Meta says to send events regularly. The developer documentation for the Dataset Quality API describes the calculation as real time. Meta’s two pages describe the timing differently, so do not read anything into a one-day wobble.
Why Meta cares: the developer documentation says only matched events can be used for ads attribution and ad delivery optimisation. Unmatched events can still be used for basic measurement. Meta’s Help Centre says better matching can help deliver your ads to people more likely to take the action you care about and attribute those actions to your ads, which it says can result in better ad performance and lower cost per action. That is “can”, not “will”.
What Meta says a good score is, and what it does not say
The developer page “Verifying Your Setup” says Meta typically recommends that, where possible, you aim for an Event Match Quality score of 6.0 or higher, and to click the score in Events Manager for details and recommendations. The same page describes the scale as 1 to 10, while the Help Centre says 0 to 10. Either way, it is out of ten.
I did not find, on any Meta page I read, a separate target for upper-funnel events such as AddToCart or ViewContent, or a statement that every event should reach the same score. Vendor blog posts quote “normal” ranges for those events. They do not cite Meta, so I have not used them.
Which customer details exist at each step on Shopify
This is the part most guides skip. The score depends on which identifiers are attached to the event, and an identifier can only be attached once it exists.
Meta’s own priority list
Meta’s Help Centre lists the parameters it accepts and a priority for each:
| Parameter | Meta’s priority | Hashed before sending? |
|---|---|---|
| Email address | High | Yes |
| Click ID (fbc) | High | No |
| Facebook Login ID | Medium | No |
| Date of birth | Medium | Yes |
| Country | Medium | Yes |
| Phone number | Medium | Yes |
| External ID (your own unique ID) | Medium | Recommended |
| Browser ID (fbp) | Medium | No |
| First name, surname, town/city, postcode | Low | Yes |
The hashing column comes from Meta’s “Customer Information Parameters” developer documentation. Email, phone, names, date of birth, city, state, postcode and country must be hashed. The click ID, browser ID, IP address and user agent must not be. Meta says its systems are designed not to accept unhashed contact information, and that the Business SDK hashes automatically.
Meta also lists three parameters as required on website events sent through CAPI: action_source, event_source_url and client_user_agent. It recommends sending the client IP address and user agent on all of them, and says doing so may help event matching. For events sent from a server, the IP address and user agent have to be configured manually, whereas Meta adds them automatically for browser events.
What Shopify’s pixel data holds at each step
Shopify’s developer documentation for web pixel standard events shows what a pixel can read at each step. I read the pages for the events below on 31 October 2026.
| Event | Customer details in the event data | Note |
|---|---|---|
product_viewed | None. Product variant details only | Only a browser-side client ID sits outside the data |
product_added_to_cart | None. Cart line (item, price, quantity) only | Same |
checkout_started | Email, phone, shipping and billing address fields | Each can be empty (null) |
checkout_contact_info_submitted | Email, phone, addresses | Each can be null |
checkout_completed | Email, phone, names, addresses | Each can be null |
The email, phone, name and address fields each need a matching protected customer data scope. On 10 November 2025 Shopify announced that from 10 December 2025 it would enforce that for all web pixel extensions: if an app is not approved for a scope, those fields are set to null, and the structure of the event stays the same. Custom pixels were out of scope for that change.
Shopify’s init data also exposes a customer object at page load, typed as possibly null, with the same scope requirements. In plain terms, a logged-in customer can be identified from the first page, and an anonymous first-time visitor cannot.
So why does add-to-cart score lower than purchase?
Put the two tables together. At product_added_to_cart a first-time visitor has typed nothing into your store. Shopify’s event data for that step contains a cart line and nothing about the person. What can travel with it is the technical set: client IP address, user agent, the browser ID (fbp) that the Meta pixel saves in a cookie, and the click ID (fbc) if the visitor arrived on an ad click with an fbclid in the URL. Meta’s documentation describes fbc as generated from that fbclid parameter, so a visitor who arrives from search, email or a direct visit typically does not have one.
At checkout the shopper types an email and, depending on your checkout settings, a phone number and address. By checkout_completed Shopify’s event data holds all of them, subject to the scopes above. Meta’s list puts email at High priority and phone and the other details at Medium or Low, so a purchase event can carry the strongest identifier, and an add-to-cart event from an anonymous visitor cannot.
Meta says the same thing from the pixel side. Its advanced matching guidance says automatic advanced matching does not know who a person is unless they take an action, such as filling in a form or logging in.
Two caveats, so I do not overstate this:
- This is what the documentation implies, not a Shopify statement about its Meta app. Shopify’s data-sharing page says the Conversions API sends the purchase event between Shopify and Facebook, and lists seven pixel events (PageView, ViewContent, Search, AddToCart, InitiateCheckout, AddPaymentInfo, Purchase). It does not say whether events other than Purchase are also sent by server, or which fields go with each one. If an event is not sent by server it has no EMQ at all, which is a different problem from a low score. Check your own Events Manager (step 5 below).
- Logged-in customers may match better. Shopify’s pixel data exposes the customer object for them. I could not find Shopify documenting how its Meta app uses it, so treat that as a reason to compare a guest test with a logged-in test, not as a promise.
The practical conclusion: on a store where most visitors browse as guests, a lower AddToCart score than Purchase score is what the documentation would lead you to expect. It reflects what exists at that moment, and it is not automatically a defect to chase.
Other reasons your score can be low
Timing explains the gap between events. It does not explain a Purchase score that sits well below 6.0. These are the causes I would check, in the order I would check them.
1. Your data-sharing level is Standard. Shopify’s help page says Standard uses the Meta pixel only, and a browser-based ad blocker can stop the pixel sharing data. Enhanced adds the Conversions API alongside the pixel, and Shopify says Enhanced shares the customer’s name, location, email address and phone number to match users on Facebook’s network, along with browsing behaviour. The Maximum description on the same page uses similar wording and adds that the store is updated with Meta’s latest advertising technology. Meta’s Shopify setup page says to select Enhanced or Maximum. If you are on Standard there are no server events from the app and so, by Meta’s definition, nothing for EMQ to score. That is my inference from the two definitions, and it is quick to confirm: no CAPI connection, no score.
2. More than one thing is sending events. The Shopify app, a pixel pasted into the theme years ago, a Google Tag Manager container and a third-party tracking app can all send to the same pixel. Meta’s best-practice page says the browser and server copies of an event need the identical event name plus either the same event ID or a combination of external ID and fbp, and its deduplication page says events are only deduplicated if received within 48 hours. Without that you risk double counting. Our guide to migrating Shopify tracking pixels to GA4 and Meta CAPI covers the clean-up, and the Conversions API setup guide covers the setup itself.
3. A third-party app is sending nulls. If a tracking app sends your Meta events and is not approved for Shopify’s protected customer data scopes, the email, phone, name and address it can read are null. The event still fires. Ask the app’s support whether it is approved for those scopes, since the pixel looks healthy either way.
4. Consent is limiting what is sent. Shopify’s customer privacy settings can show a cookie banner, and in the regions where it is configured, non-essential data is collected only after consent. Shopify’s help says pixels operate based on the consent obtained in those regions. As at 31 October 2026, Shopify says it configures the banner by default for visitors in the UK and EEA if you have active markets there, and does not activate it by default in regions that do not require opt-in consent. If you use a third-party banner, Shopify says to use the same consent regions in both places, or non-essential data can be processed before the visitor consents. Meta’s Overview page also shows events discarded due to consent controls and other policies.
Consent is also where a low score should not be “fixed” at all. If a customer has declined, a lower match rate for that customer is the correct result. This is general information, not legal advice. Shopify’s own page says its automated privacy settings are not a substitute for legal advice, and Meta’s help page says you need lawful rights to collect and share the data and should work with your own legal counsel. For Australian stores, the OAIC’s small business page says “Most small businesses are not covered by the Privacy Act 1988, but some are”. Whether it covers your store, and what Meta’s and Shopify’s terms and your customers’ countries’ laws require of you, are questions for a privacy professional.
5. Placeholder or shared values. As of September 2026, Meta’s Dataset Quality API documentation lists six more diagnostic types, including “email placeholder” and “phone placeholder”, where a large share of events share the same placeholder instead of a real value. A fake address pushed into an email field to satisfy a form cannot identify anyone, and Meta now flags it.
6. IP address problems. The same documentation lists empty IP, relay IP and IPv4 where IPv6 would match better. These are mostly server-side setup issues, relevant if a third-party or custom server sends your events.
7. Click ID coverage is thin. The same diagnostics list the fbc click ID being present on too small a share of events. If most of your traffic is not from Meta ads, that can be normal, since only ad clicks carry an fbclid.
8. Formatting errors in custom code. Hashing and normalising mistakes mean an identifier arrives but cannot match. See the formatting reference below.
How to audit it in about an hour
- Write down the baseline. In Events Manager, open your dataset (Data sources), then Overview. For Purchase, AddToCart, InitiateCheckout and ViewContent, record the EMQ score and the connection method, and note the date. Per Meta’s “Verifying Your Setup” page, Overview shows how many events were received before deduplication, discarded for consent or other policies, or processed, and the channel (browser or server) each came through.
- Check your Shopify data-sharing level. Per Shopify’s help page: Sales channels, Facebook & Instagram, Settings, Data sharing settings. If it says Standard and you run Meta ads, Meta’s guidance for Shopify is to choose Enhanced or Maximum. Decide that with your privacy policy in mind, since Shopify says you are responsible for telling customers how their data is shared.
- List everything that sends to your pixel. Shopify’s Facebook and Instagram app, theme code, Google Tag Manager, any tracking or “server-side” app. If you find two or more, you have a deduplication question to settle before an EMQ one. Test Events (step 5) will show duplicates.
- Check consent settings. In your Shopify admin, open the Customer privacy settings and confirm whether a cookie banner is on, for which regions, and whether a third-party banner uses the same regions.
- Run a test. In Events Manager, use the Test Events tab. Meta recommends using your own customer details for tests because events can be discarded if they do not match a Meta account. Do three runs and compare: (a) as a guest, add to cart, start checkout and buy; (b) as a logged-in customer, if you have customer accounts; (c) arriving from a click on one of your Meta ads. Test information stays in the tool for 24 hours. Note which events appear from the server, and which show up twice.
- Open the score. Meta says to click the EMQ score for details and recommendations. If you or a developer want per-field coverage, the Dataset Quality API returns the share of events carrying each identifier. That is a developer task.
- Decide, using the table below.
What is worth fixing, and what to ignore
Meta’s own documentation gives a prioritisation rule. The Dataset Quality API page says event spend helps you prioritise signal-quality work: an event driving a large amount of spend in sales campaigns may be more urgent to fix than one behind a small test. I use that as the first filter.
| What you see | Worth fixing? | Why |
|---|---|---|
| Purchase below 6.0 and your campaigns optimise for Purchase | Yes, first | Meta suggests aiming for 6.0 or higher where possible |
| AddToCart or ViewContent lower than Purchase | Usually no | The identifiers do not exist yet for guests (see above) |
| Data-sharing level is Standard while you run Meta ads | Yes | No server events from the app, so no EMQ and no CAPI benefit |
| Placeholder email or phone flagged | Yes | Shared fake values cannot match anyone |
| Purchase is sent twice, or deduplication warnings | Yes | Double counting skews ad reporting |
| Score moves a point day to day | No | Meta’s own pages describe a rolling window |
| Low score on an event no campaign uses | No | Nothing downstream depends on it |
| Lower match rate for customers who declined consent | No | That is the choice working as intended |
| A third-party app sending nulls | Yes | Pixel looks healthy while the fields are empty |
A worked example, with illustrative numbers
These numbers are made up to show the reasoning. They are not a benchmark and not a client result.
A store spends A$9,000 a month on campaigns optimised for Purchase and nothing optimised for AddToCart. Purchase EMQ is 5.1 and AddToCart is 4.2. Following the event-spend rule, all the effort goes to Purchase.
Say the store has 500 purchases in a month and its developer finds that a hashed email reaches Meta on 300 of them. Email coverage is 300 divided by 500, so 60%. The other 200 purchases are being matched, at best, on weaker details. The question is why 200 are missing an email: a second sender with nulls, a consent region, a placeholder, a custom-code bug, or a data-sharing level. Each has a different fix, which is why the audit comes before the changes. If the cause is a consent choice, the answer is nothing, and the store has just saved itself a pointless project.
Meta has a similar illustration for coverage. In its Dataset Quality API documentation, if a store sends three events with the pixel (ViewContent, AddToCart and Purchase) but only Purchase by server, event coverage is 33%. The same page refers to a 75% threshold for event coverage.
Formatting reference for custom setups
If you use Shopify’s app or Meta’s Business SDK, hashing and normalising are handled for you. This only matters if someone wrote custom code or a tool asks you to prepare the data. Meta’s rules, applied to Australian values:
| Field | What the customer typed | Meta’s format before hashing |
|---|---|---|
| Sarah.Nguyen@Example.com.au | sarah.nguyen@example.com.au | |
| Phone | 0412 345 678 | 61412345678 |
| Country | Australia | au |
| State | NSW | nsw |
| City | Port Melbourne | portmelbourne |
| Postcode | 3207 | 3207 |
These come from applying Meta’s stated rules to the example values (the examples are mine, not Meta’s): trim and lowercase emails; remove symbols, letters and leading zeros from phone numbers and include the country code; use the lowercase two-letter ISO country code; lowercase state and city with no spaces or punctuation; lowercase postcodes with no spaces or dashes. Then hash with SHA-256. Do not hash the IP address, user agent, fbc or fbp. Meta’s phone rule is worth singling out for Australia, since numbers are normally typed with a leading 0, and a number sent as 0412345678 without the 61 country code does not follow Meta’s rule.
What not to do
- Do not push fake data to lift the number. Placeholder emails and phone numbers are on Meta’s diagnostics list as issues.
- Do not make phone number compulsory at checkout just to raise a score. Treat every extra required field as a conversion test: measure checkout completion before and after. A better Meta score that costs you orders is a bad trade.
- Do not send sensitive information. Meta’s terms prohibit it, and Meta requires you to hash contact information as its documentation describes.
- Do not judge the project by the score. The score is an input. What you care about is whether Meta’s numbers and your Shopify numbers behave sensibly together, and whether campaigns are being optimised on real orders.
- Do not change several things at once. If you change data-sharing level, remove a duplicate sender and update consent in one afternoon, you will not know which change moved anything. Baseline, change one thing, wait, re-read.
Where this sits in the bigger picture
EMQ is one input into a wider question: can you trust the numbers that tell you whether paid traffic is working? Meta and Shopify rarely agree on sales, for many reasons beyond match quality, and the post on why Meta shows more sales than Shopify walks through them. Where Google Analytics and Shopify disagree too, GA4 vs Shopify Analytics explains the usual gaps, and attribution is broken on Shopify in 2026 covers why no single report is the truth.
I will be plain about where Prism3 fits. We do not run ads or email. What we do is look at the store after the click, and at whether the measurement behind your numbers is sound. The CRO service starts with an audit that includes a tracking check, because it is hard to improve conversion on numbers you cannot trust. If your cost per customer is high, match quality is one part of the answer. The other part is how many of the visitors you pay for actually buy.
Key takeaways
- EMQ is Meta’s score out of 10 for how well server-event customer details may match a Meta account. It exists per event, only for web events sent through the Conversions API.
- Only matched events can be used for ads attribution and optimisation, per Meta’s developer documentation.
- Meta says to aim for 6.0 or higher where possible. It gives no separate target for add-to-cart or view-content events on the pages I read.
- On Shopify, the add-to-cart event data holds no email, phone or address, while checkout and purchase events can. Expect upper-funnel scores to sit below Purchase.
- Fix Purchase first and prioritise events by the ad spend that depends on them.
- Check, in order: data-sharing level, duplicate senders, third-party apps sending nulls, consent settings and placeholder values.
- Do not lift a score with fake data, by overriding a customer’s consent choice, or by adding checkout fields without testing the effect on orders.
- This is general information, not legal advice. Settings were checked as at 31 October 2026 and Meta and Shopify change them often, so re-check before acting.
FAQs
What is a good Event Match Quality score on Shopify?
Meta’s developer documentation says to aim for 6.0 or higher where possible. I found no Meta page that gives a separate target for add-to-cart or view-content events, and those usually sit below Purchase on a store with many guest shoppers. Judge Purchase against 6.0 and use the others as diagnostics.
Why is my add-to-cart Event Match Quality lower than purchase?
Because the shopper has not given an email, phone number or address when they add to cart. Shopify’s event data for add-to-cart holds a cart line and no customer details, while checkout and purchase events can hold email, phone and address. What can be sent at add-to-cart is technical, such as IP address, user agent and browser ID.
Can I see Event Match Quality without the Conversions API?
No. Meta’s Help Centre says EMQ is available for website events sent through the Conversions API. If your Shopify data-sharing level is Standard (pixel only), the documentation shows no Conversions API connection from the app, so there is nothing to score. Meta’s setup page for Shopify says to choose Enhanced or Maximum.
Does a low Event Match Quality hurt my Meta ads?
Meta says only matched events can be used for ads attribution and ad delivery optimisation, and that better matching can improve performance and lower cost per action. That is Meta’s statement of what can happen, and I cannot tell you how much a change would help your account. The score is one input, so judge changes by how your orders and Meta’s reported results behave over time.
Should I collect phone numbers at checkout to improve it?
Only if you test the effect on checkout completion. Phone is a Medium-priority parameter in Meta’s list, and email, which is already collected, is High. Adding a required field is a conversion trade-off, and you should measure it before and after rather than assume the match score is worth it.
Does cookie consent change my score?
It can. Where a cookie banner is configured, Shopify says non-essential data is collected only after consent, and pixels operate on the consent obtained. A lower match rate for customers who declined is the correct outcome, not something to fix. This is not legal advice, so check your obligations with a privacy professional.
How long after a fix does the score update?
Meta’s Help Centre says it uses the last 48 hours of data. Its developer documentation describes the calculation as real time. Give a change a few days of normal traffic before judging it, and change one thing at a time.
Keep reading
- Meta ROAS dropped? Diagnose it before cutting budget
- Facebook ads getting clicks but no sales: the Shopify fix
- The three numbers Shopify founders should watch weekly
Is your cost per customer higher than it should be?
A match score tells you how well Meta can match a customer; it does not show whether every order is counted once, or where visitors leave before they order. Book a free 30-minute diagnostic: we look at where your store loses buyers after the click, using your own numbers, and tell you what to fix first. We do not run ads or email. No pitch. No email gate.
If tracking is part of the problem, our Shopify CRO service starts with a six-phase audit whose first phase includes a tracking check.
Free 30-min diagnostic
Seen enough?
Book a free diagnostic.
We'll look at where your store loses buyers after the click and what to fix first. No pitch. No email gate. 30 minutes.
More from Prism3
Afterpay vs Zip vs Shop Pay Instalments: Shopify AU
Afterpay, Zip and Shop Pay Instalments compared for Australian Shopify stores: merchant fees, payouts, approval, checkout placement and a worked margin example.
AI-Referred Orders on Shopify: What Is Real and What Is Hype
What Shopify has disclosed about AI-referred orders, why the 13x headline needs context, how to find AI traffic in GA4 and Shopify, and what to do now.
AI Visibility Tools for Shopify: What They Measure and Miss
What AI visibility tools for Shopify stores really count: mentions, share of voice and citations, where the data is sampled or unstable, and how to use them.