Most e-commerce sites running Meta ads lose conversion signal and waste budget because their event match quality scores are lower than they think—even when the Events Manager shows a green checkmark. Meta’s match quality isn’t just a box to tick; it directly affects how many conversions your campaigns actually optimize for, and how much you pay per sale. Many teams assume that passing any customer data is enough, but in practice, missing or malformed parameters quietly drag down match rates and performance.
By the end of this article, you’ll know exactly which user data fields move the match quality score, how to spot and fix the real causes of low match quality, and where most e-commerce tracking setups go wrong. You’ll also be able to prioritize your fixes based on quantifiable impact, not guesswork, and avoid the privacy and implementation mistakes that keep your scores stuck in the yellow.
What Meta Event Match Quality Measures and Why It Matters
Meta event match quality is a score shown in Events Manager for each event source—Pixel, Conversions API, or both. This score quantifies how effectively your event data can be linked to real Meta user profiles for ad attribution and delivery optimization. The score is based on the identifiers you send with each event and how well those identifiers match user data already held by Meta.
The identifiers Meta uses for matching fall into two categories: direct identifiers (such as email addresses and phone numbers) and indirect identifiers (such as IP address, browser user agent, and device IDs). Direct identifiers have a much higher impact on the match quality score. For example, an event with a hashed email and phone number will almost always score higher than one relying only on browser data.
A low match quality score means Meta can’t reliably connect your site events to its users. This leads to underreported conversions, weaker audience building, and less effective ad optimization. For any campaign relying on conversion data—retargeting, broad prospecting, or value optimization—your results depend on Meta’s ability to attribute events to users accurately.
You can view the match quality score for each event in Events Manager. The score is recalculated as Meta updates its matching algorithms and available identifiers, so the same implementation may see its score change without any action on your part. Meta does not publish the exact scoring formula, and the weight given to each parameter can shift. For current details, check the Events Manager interface and Meta’s developer documentation, as both change frequently.
Which Parameters Actually Move the Match Quality Score
Email and phone number are the two parameters that drive the largest increases in Meta event match quality for most e-commerce sites. Meta’s matching engine uses these as primary keys because they are stable, unique, and commonly available across both your events and Meta’s user database. If you must prioritize, send em (email) and ph (phone) on every event where you can collect them—especially purchase, checkout, and lead events.
First name, last name, and zip or postal code add incremental value, but their individual weights are lower. These help Meta confirm a match when email or phone is missing or malformed, but rarely make up for the absence of both. Typical parameter names are fn (first name), ln (last name), and zp (zip/postal code). If you collect these at checkout or account creation, include them.
IP address and user agent are always used if present, but their impact on match quality has declined. Privacy changes—browser restrictions, iOS updates, and network proxies—mean these values are less reliable for persistent identification. They still help in edge cases, but don’t expect large score increases from adding them alone.
Sending every possible parameter does not guarantee a higher match quality score. Meta prioritizes accuracy and completeness over sheer volume. If you send stale, default, or placeholder values, you can reduce your score or even trigger warnings. Validate that each identifier is present, current, and formatted as Meta expects. Hashing errors—double hashing, wrong algorithm, or skipped hashing—often look like missing data from Meta’s perspective, with no difference in the reported score.
Meta’s documentation and Events Manager UI sometimes diverge. If you want to see which parameters actually count toward your match quality score, check the “Event Match Quality” section in Events Manager for the specific event. The UI reflects current weighting more accurately than static documentation pages.
Common Causes of Low Match Quality (and How to Diagnose Them)
Missing key identifiers on high-value events like Purchase and Lead is the most frequent cause of low match quality. If the event payload doesn’t include em (email) or ph (phone), match rates drop sharply. In Events Manager, review the “Event Match Quality” diagnostics for each event type. If you see “Missing customer information” warnings on Purchase events, prioritize capturing and sending these fields.
Hashing errors are common and hard to spot. Meta requires SHA-256 hashing for all user identifiers. Double-hashing (hashing an already-hashed value), using the wrong algorithm, or sending unhashed data all appear the same to Meta: the values simply don’t match. To verify, inspect the payload in your server logs or use a tool like Chrome DevTools Network tab for client-side. The raw value before hashing should look like user@example.com; after SHA-256 hashing, it’s a 64-character hex string. Never hash twice. If unsure, cross-check your implementation against Meta’s documentation and verify with a known test value.
Incorrect mapping in server-side integrations (GTM Server, direct API) can silently drop identifiers. In GTM Server, audit your variables and tags: ensure the email and phone variables are populated and mapped to em and ph in the outgoing request. For direct API calls, confirm field names and structure match Meta’s current documentation—these can change, so check the API reference, not just old code examples.
Data formatting issues—extra spaces, uppercase letters, or missing country codes—reduce match rates. Strip whitespace, lowercase emails, and prepend country codes to phone numbers. In your code, add explicit string normalization before hashing. For example, user@example.com and USER@EXAMPLE.COM must both normalize to user@example.com before hashing.
Client/server event deduplication can suppress identifiers. If deduplication is active but configured incorrectly, the server event may drop identifiers to avoid double-counting, even when the client event is missing them. In Events Manager, check if server events show “Identifiers dropped due to deduplication.” If so, review your deduplication setup to ensure identifiers are preserved where possible.
How to Fix Low Match Quality: Prioritized Checklist
Start in Events Manager. Open the diagnostics and real-time views for your pixel or CAPI events. Confirm which identifiers you’re actually sending with each event, and check for missing or malformed fields. If you see warnings about missing customer information, address those first—Meta prioritizes em (email) and ph (phone) above all other parameters for match quality. Ignore parameters like fbp and fbc for this score; they have little direct impact.
Check that you’re sending email and phone on all purchase and initiate checkout events. In Events Manager, expand an event and look for the em and ph parameters under “Event Data.” If either is missing, or you see a formatting warning, fix your payload. Email addresses must be lowercased, trimmed of whitespace, and hashed with SHA-256 exactly once. Hashing twice or skipping hashing both result in non-matches, but Meta’s UI cannot distinguish between them. The same rules apply to phone numbers: remove formatting, include country code, lowercase, trim, and hash once.
Confirm that each identifier is mapped to the correct parameter name. For example, email must be under the em key, phone under ph. Meta does not infer intent from custom keys. If you use server-side tagging, check your mapping logic.
Test both browser and server events. Inconsistent payloads or missing deduplication keys (event_id) can fragment match rates. Use the “Test Events” tool to verify that both event channels send identical identifiers and deduplication parameters.
After making changes, allow 24–48 hours for Events Manager to reflect the new match quality score. Meta’s backend updates these metrics on a delayed batch process.
Hashing and Privacy: What Meta Can and Can’t See
Meta requires all personally identifiable event parameters—such as email, phone, first_name, last_name, and zip—to be hashed using SHA-256 before transmission. If you send these identifiers unhashed, or hash them incorrectly, Meta’s backend discards or ignores them without warning. The Event Match Quality score in Events Manager does not differentiate between missing, malformed, or improperly hashed values. An empty field, a wrongly formatted hash, or a double-hashed value all look the same to Meta: unusable for matching.
Hashing errors are not flagged in the Events Manager UI or in the diagnostics tab. For example, if you double-hash an email (hashing an already SHA-256-hashed value), Meta cannot recover the original identifier. The result is a silent drop in match quality, with no indication of the root cause. To check for this, inspect your outgoing network requests in your browser’s developer tools. The email parameter should be a 64-character hexadecimal string. If the value is longer, shorter, or contains unexpected characters, you likely have a hashing error. Do not hash non-normalized data; always trim, lowercase, and remove extra spaces before hashing.
Under CCPA, CPRA, and similar state laws, you must disclose to users that you share hashed identifiers with Meta for advertising and analytics. If a user opts out of data sharing, do not send their identifiers to Meta, hashed or otherwise. Respect opt-out flags by filtering identifiers server-side or in your tag manager before any network request to Meta’s endpoints.
Monitoring and Maintaining High Match Quality Over Time
Review event payloads in Events Manager every two weeks. Open the Diagnostics tab and export recent events. Look for missing or malformed parameters flagged by Meta, but also cross-check against your own server logs. For server-side events, compare what you send in the user_data object with what appears in Meta’s interface. If Meta shows “insufficient data” but your logs show complete payloads, investigate encoding or delivery issues.
Document your hashing and mapping logic for each integration point. Store this documentation in your source control or internal wiki, not just in code comments. For example, specify that email is lowercased and SHA-256 hashed before being sent, and show the exact function or library used. Note any fields mapped from CRM, custom checkout, or third-party scripts, so future audits can confirm the data path.
Monitor Meta’s official developer documentation and Events Manager UI for changes to required or recommended parameters. Meta periodically adds or reorders match keys. If a new parameter appears in the “Improve match quality” suggestions, review your data sources and update your payloads as needed. Assign responsibility for these checks to a named team member, not “someone in engineering.”
Re-audit event payloads after any major change to site templates, checkout flows, CRM integrations, or consent mechanisms. Use test transactions and check Events Manager for new errors or drops in match quality. If you use a tag manager or middleware, confirm that mappings and hashes still function as documented.
Keep technical and marketing teams aligned by maintaining a shared document listing every parameter sent, its source, its transformation (if any), and the business reason for its inclusion. Review this document quarterly, and update it whenever your data flows or Meta’s requirements change.
Frequently asked questions
Does sending more parameters always improve match quality?
No. Prioritize accuracy and completeness of high-impact identifiers (email, phone). Extra fields add little if the core data is missing or malformed.
How long does it take for match quality improvements to show up?
Usually 24–48 hours after making changes, but this can vary depending on Meta’s processing and platform updates.
Can I see which parameters are missing or malformed?
Use Events Manager diagnostics and payload inspection to identify missing or incorrectly formatted fields, but Meta does not always specify which are at fault.
What hashing algorithm should I use for Meta event data?
SHA-256, applied once to each identifier, lowercased and trimmed before hashing.
Not sure your tracking is telling you the truth?
Propulse Agency audits e-commerce tracking setups — server-side tagging, Meta CAPI, GA4 and consent — and fixes what is quietly costing you conversions.
Start With Data Quality, Not More Tags
Before you add new tags or push more identifiers, audit the underlying customer data you already collect. Most low match quality issues come from missing, malformed, or poorly mapped fields—especially emails and phone numbers. Check your checkout and account creation flows for incomplete or inconsistent inputs. Validate that the data sent to Meta matches real user submissions, not placeholder or test values.
Prioritize fixing the most common fields first: em, ph, and fn. Don’t waste time sending parameters you don’t reliably collect. If you use third-party apps or middleware, confirm they aren’t stripping or overwriting identifiers. Monitor the Events Manager for changes after each fix. Teams often chase minor optimizations before solving the core data quality problems—don’t repeat that mistake.
Reviewed and updated by fodil on Jul 29, 2026.
