Meta Event Match Quality: What It Is and How to Improve Your EMQ Score

Two Meta ad accounts can spend the same budget and get very different results, and measurement quality is one of the quiet reasons. Event match quality, the score you see in Events Manager, tells you how well each server event connects to a real person. In this guide I explain how the score works, which data moves it and how to improve it without trading away privacy.

Everything here comes from Meta's official developer documentation and from the tracking audits I have run on ad accounts since 2012. You will not find invented benchmark scores or promises that one toggle doubles your sales. Instead, you will see why each step matters and how to check it. That way you can speak the same language as your developer or agency.

What is event match quality in Meta?

Event match quality (EMQ) is a score out of 10 that shows how likely Meta can match an event you send through the Conversions API to a Facebook or Instagram account. It depends on which customer information parameters you send, how clean that data is and what share of events actually match an account.

According to Meta's developer documentation, the score currently applies to web events only. You will not see the same view for app events or offline events. Also, the score belongs to a single event type. A Purchase event can sit at 8 while Lead sits at 4, and that is completely normal. So there is no single "account score"; you need to read each event on its own.

In short, EMQ measures how confidently the ad system can answer one question: who made this purchase? As the answer gets fuzzier, the system receives fewer usable signals. As a result, your reports come up short and the algorithm spends more budget on the wrong people.

Why does the event match quality score matter?

Meta can only credit a conversion to an ad when it can tie that conversion to an account. An unmatched event does not show up in reporting and does not feed the learning process. Therefore a low score can mean the ad system never "sees" a sale, even though the sale happened.

That has three practical effects:

• Reporting: Conversions in Ads Manager fall behind the real number in your store or CRM.
• Optimization: The algorithm learns from fewer examples, so ad sets take longer to exit the learning phase.
• Audiences: Excluding past buyers or finding people like them works from an incomplete list.

The pattern I see most often in audits is simple. A brand says "Meta doesn't sell," yet the real issue is that Meta cannot measure the sales. That said, honesty matters here: a higher EMQ does not create extra sales on its own. It only helps existing sales reach the ad system more clearly. In practice, that gives your budget decisions firmer ground.

How does Meta calculate the match score?

Meta does not publish the exact formula. However, its documentation names three inputs: which customer information parameters arrive from your server, the quality of that data and the percentage of events that match a Meta account.

Not every parameter carries equal weight. Meta's Conversions API best practices page highlights email, IP address, first and last name and phone number as high value fields. On the other hand, city, country, zip code and gender are weak on their own. In fact, Meta treats some combinations made only of these broad fields as invalid.

Quality matters as much as quantity. For example, if you hash an email with capital letters or a trailing space, the parameter looks present but never matches anyone. In other words, the path to a better score is not "more fields." It is more strong fields, sent in the correct format.

Where can you find your event match quality score?

You find the score in Meta Events Manager, on the overview of the relevant dataset (your pixel). Open an event from the list and you will see its match quality details. These include the parameters you send and the share of events that carry each one. Meta changes the interface from time to time, so do not get stuck on menu labels. Look for the match quality section inside the event details.

If you have developers, you can pull the same data from the Dataset Quality API. This endpoint returns the EMQ score, diagnostics, event coverage, data freshness and deduplication rates in one response. Instead of checking the score by hand every week, you can feed it into your own dashboard.

Next to the parameter list you will also see a coverage percentage for each field. That percentage often teaches you more than the score itself. For instance, if email arrives on only half of your purchases, you know to look for a broken checkout flow right away.

Which customer information parameters affect the score?

Meta's customer information parameters reference lists every key and its formatting rule. The table below pulls together the fields that make the biggest difference in practice.

Keep one rule in mind when reading the table. Sending a field once is not enough; it needs to arrive on most events. For example, if phone is optional on your form and most people skip it, Events Manager shows low coverage for that field. So form design and tracking quality belong in the same conversation, and I come back to that below.

Why isn't the Meta Pixel enough on its own?

I cover pixel setup, standard events and the basic Conversions API difference in my Meta Pixel setup guide. Here I focus only on the part that matters for matching.

The pixel runs in the browser. Consequently, ad blockers, browser tracking protection, slow page loads and cookie consent can all stop an event from firing. Even when it fires, the browser rarely holds an email or phone number. The pixel's advanced matching feature can pick up some form fields; still, it does not work reliably on every checkout.

On the server side, things look different. As soon as an order lands in your database, you hold the email, phone, name and address. That is why Meta expects the strongest matching data from your server, not the browser. Moreover, the EMQ score evaluates exactly these server events. Running the pixel and the server together, rather than either one alone, is the redundant setup Meta recommends.

How does the Conversions API strengthen matching?

The Conversions API sends events from your own server straight to Meta. As a result, you recover events the browser lost, and you can attach the customer data you hold at the moment of the order. The biggest jumps in match quality usually come from this step.

The route depends on your stack:

• Hosted e-commerce platforms: Many offer an official Meta integration. First, check in Events Manager which parameters that integration actually sends.
• Server side tagging: A server container in Google Tag Manager lets one data layer feed both Google and Meta events.
• Direct API integration: On custom built sites this is the most flexible option; you send the event from the server as soon as the order saves.

Whichever route you choose, send events in real time or close to it. Meta's documentation states plainly that sharing events as they happen helps campaigns perform. A nightly batch upload may not hurt the score, but it slows down optimization.

How should you normalize and hash customer data?

Hashing turns a value such as an email into a one way string that no one can reverse. Meta expects personal fields hashed with SHA-256, then runs the same process on its side to find a match. Because of that, a single character difference breaks the match.

Apply these normalization steps before hashing:

1. Email: Trim leading and trailing spaces, then convert everything to lowercase.
2. Phone: Remove spaces, brackets, dashes and leading zeros, then add the country code, for example 44 for the UK or 1 for the US.
3. First and last name: Lowercase them and strip punctuation. Keep accented characters in UTF-8.
4. City and zip code: Use lowercase and leave out spaces and special characters.
5. Country: Use the two letter ISO code in lowercase, such as gb or de.

Never hash the IP address, user agent, fbp or fbc. Meta expects those raw. This is the single most common mistake I find: a developer hashes everything "to be safe" and IP and browser matching collapse. To see how normalization changes a hash, try a dummy address in our hash generator; never paste real customer data into any online tool.

How do you keep fbp and fbc values intact?

fbp is the identity cookie the pixel writes to the browser. fbc is the click ID derived from the fbclid value that Meta adds to the URL on an ad click. Together they tie the server event to the browser visit and to the ad click.

The catch is that your server does not know these values by default. You need to read the cookies when the visitor adds to cart or checks out and store them with the order. For example, flows that redirect to a payment provider and back can lose the cookie value. So write the values to your database before the order record exists.

Also protect the URL parameters. Some redirects and link shorteners strip fbclid, and then fbc never forms. Test that the tags you build with our UTM builder do not clash with fbclid or drop it during redirects. Meta also notes that these cookie formats can change. Read the values from the browser instead of generating them yourself, and refresh them regularly.

Why do IP address and user agent matter so much?

IP address and user agent help matching even on events without an email. Meta requires the user agent for website events and lists the IP address among its high value fields. Yet these two fields are the ones most often sent wrong.

The classic error is putting your server's IP into the event instead of the visitor's. This happens a lot on sites behind a CDN or load balancer. The Dataset Quality API examples also list IP quality and mismatched IP addresses among diagnostic warnings. To fix it, read the visitor IP from the correct forwarding header and store it at the moment of the event.

Meta also says it prefers IPv6 over IPv4. If a visitor arrives on IPv6, do not try to convert the address. In short, do not dismiss these fields as technical details. On upper funnel events where you collect no email, they often carry most of the matching.

What does external_id do for matching?

external_id is the customer ID from your own system. Meta does not match this value to a Facebook account directly; however, it helps connect separate sessions and events from the same person. Hashing it is optional but recommended.

Here is the practical value. A logged in customer browses a product on mobile today and buys on desktop two days later. If both events carry the same external_id, the system reads that journey consistently. Additionally, sending the same value on both pixel and server events gives you one of the alternative deduplication methods Meta describes.

Consistency is the key point. If the pixel uses one format and the server another, the two values never meet. So generate the customer ID from a single source. On lead generation sites that source is usually the CRM record. If you already run CRM integrated lead tracking, you can carry the same ID into Meta.

How do deduplication errors distort results?

When the pixel and the Conversions API run together, the same purchase arrives twice. Meta merges browser and server events that share the same event name and event_id within 48 hours and discards the later copy. If the event_id does not match, the sale counts twice.

Double counting may not lower the EMQ score directly, but it inflates reports and makes ROAS look better than it is. Conversely, if you generate event_id badly and give different sales the same ID, real sales disappear. Both errors share one root: the browser and the server each create the ID on their own.

The right approach is to create event_id in one place and pass the same value to both channels. For a purchase, the order number makes an excellent event_id. To check, look at the deduplication details for the event in Events Manager. Then compare purchases in Ads Manager with your store dashboard. Putting both numbers side by side in our ROAS calculator shows the gap quickly.

Why should you watch event coverage and data freshness?

The EMQ score alone does not tell the whole story. When Meta assesses a Conversions API setup, it also looks at two supporting measures: event coverage and data freshness.

• Event coverage: The share of pixel events that the Conversions API also sends. The Dataset Quality API reports it as a 7 day average. In Meta's documented example, one event shows 34.1% coverage against a 75% goal.
• Data freshness: The gap between the moment an event happens and the moment it reaches Meta. Real time sending and hourly uploads are not equal.
• Additional conversions reported: Meta estimates the conversions measured thanks to your Conversions API setup and shows how much specific match keys could add.

Read these three alongside EMQ. A high score with low coverage means only a small slice of events matches well. Therefore chasing the score without raising coverage is only half the job.

What should you consider for privacy and GDPR?

Improving match quality means sending personal data, so it ties directly to legal responsibility. Hashing makes data unreadable, but it does not stop it from being personal data. So do not treat hashing as a legal permission slip.

For a site serving European users, the core questions look like this. Does your privacy notice explain data sharing with Meta? Do you collect valid consent for marketing cookies and data sharing? Have you assessed international data transfers? I cover the broader framework in my GDPR compliant website guide; for the actual wording, always work with a lawyer.

Meta's own position is clear: if you have consent logic that controls pixel data sharing, apply the same logic to the Conversions API. In other words, the server side is not a back door around consent. Meta also offers data processing options, known as Limited Data Use, for certain US states; if you target those markets, review these parameters as well.

What happens with visitors who decline consent?

You do not send events for visitors who decline consent. That means knowingly giving up part of your score and your conversion count. In my view, that loss is always worth paying compared with the legal risk.

Still, there are legitimate ways to shrink the loss. First, write your consent banner in plain language; vague or alarming wording pushes rejection rates up for no reason. Second, send complete events for visitors who do consent, because that group is where you raise match quality. Finally, store the consent status with the order so the server applies the same decision when it sends the event.

One mistake I see often is a consent banner that works correctly for the pixel while the server event never checks it. The site then sends data for people who said no, without anyone noticing. Fixing that kind of gap matters far more than adding a few points to EMQ.

How do forms and checkout flows affect the score?

Match quality is not only about code; it also depends on what data you collect. If guest checkout asks only for an email, you cannot send a phone number. If your lead form has only name and phone, the email field stays empty.

That does not mean adding fields to every form. Extra fields lower conversion rates. Instead, make sure the data you already collect reaches the event in full. For example, if the order holds an address but the purchase event leaves it out, that is a free improvement.

Look at event timing too. On early events such as add to cart, visitors have not identified themselves yet, so those scores stay lower by nature. If a visitor is logged in, you can add the session's identity data to those events as well. In short, judge every event by what its stage can realistically offer, and do not expect purchase level scores from upper funnel events.

How can lead generation sites improve matching?

In service businesses, sales usually start with a form or a phone call. On these sites the Lead event matters most, and the form already holds name, phone and often email. So the data you need is in your hands; what usually goes missing is the handoff to the server event.

Here is the route I recommend. When a visitor submits the form, write the record to your own database or CRM first. Then send the Lead event from the server using that same record, with form fields normalized and hashed. That way the event reaches Meta even if the browser event gets lost.

If you use Meta's own lead ads, store the lead ID from the form. Meta accepts it as a separate customer information parameter called lead_id. When your sales team closes a deal, sending a later stage event with that ID shows which ad actually brought in a customer.

How do you verify changes in the Test Events tool?

After each fix, use the Test Events view in Events Manager instead of waiting for live data. It gives you a unique test code. Add it to your server event temporarily and you see incoming events and their parameters immediately.

Look for answers to three questions. First, do all the parameters you expect arrive? Second, when the same action comes from both browser and server, does it merge into one event? Third, is the IP address really your own connection's address? These three checks catch most of the errors I find in audits.

Remove the test code once you finish. Otherwise live events flow into the test stream and look missing in your reports.

How do you improve event match quality step by step?

When my team and I take over an account, we follow the sequence below. Working in order lets you see how much each change moves the numbers.

1. Baseline: Record the EMQ score, parameter coverage and event coverage for each key event.
2. Set up server events: If there is no Conversions API yet, start with purchase and lead events.
3. Fix required fields: Send the visitor IP, user agent and event source URL correctly on every event.
4. Add strong fields: Normalize and hash email, phone, first name and last name.
5. Carry cookies: Store fbp and fbc with the order and include them in the server event.
6. Verify deduplication: Check in Test Events that both channels send the same event_id.
7. Align consent logic: Make the pixel and the server follow the same consent decision.
8. Monitor: Track the score and coverage over the following days.

Along the way, clear the warnings in the diagnostics tab one by one. Meta's own warnings often point straight at the problem.

Which event match quality mistakes are most common?

The same errors show up again and again in the accounts I audit. Most take only a few hours of development work to fix.

• Hashing an email with capital letters or spaces.
• Sending a phone number without the country code or with a leading zero.
• Hashing the IP address, user agent or fbp as well.
• Sending the server's IP address instead of the visitor's.
• Generating event_id separately in the browser and on the server.
• Leaving the test event code in place after going live.
• Uploading events in bulk hours later.

You can use this list as a checklist. However, verify each item on a real event sample in Events Manager, not just in the code. A field that looks right in code may never arrive because of a plugin conflict.

How should you read results after the score improves?

When match quality improves, conversions in Ads Manager may rise. Part of that rise is not new sales but sales that were invisible before. So keep the week of the change separate in any performance comparison.

For an honest reading, watch two sources together: your store or CRM and your ad account. If real sales stay flat while Ads Manager shows more, measurement improved. If real sales climb too, the algorithm is likely finding better audiences with better signals.

Also remember how your attribution setting shapes the numbers. Click through and view through windows give different results; I explain this in my article on Meta attribution settings. Google works on similar logic, and enhanced conversions likewise use hashed customer data to strengthen matching.

When should you bring in professional help?

If you run a hosted e-commerce platform and your purchase score looks healthy after turning on the official integration, you probably need nothing more. But custom software, several checkout flows, a mix of member and guest checkout or a site behind a CDN make matching problems slow to find alone.

My team and I start this kind of work with a tracking audit. We check what each event really sends, whether consent applies on both channels and whether deduplication works. Then we fix issues in order of impact. If you want us to run the ads too, our social media management service covers Meta campaigns together with the measurement setup. For online stores, the same work fits naturally into our e-commerce consulting.

To sum up, EMQ is a health indicator, not a target. Raise it without bending privacy rules, and focus on sending the right data in the right format at the right time.