Facebook CAPI Match Quality Fix (2026): Boost EMQ Score Fast
Last Updated: July 8, 2026Question: How do you fix a low Facebook CAPI match quality score?
A low Facebook CAPI match quality score below 6.0 means Meta cannot reliably link your server-side conversion events to real Facebook user profiles.
To fix your EMQ score, you must extract the fbc click ID and fbp browser ID parameters from your funnel, normalise all customer PII before SHA-256 hashing, and transmit a correctly formatted user_data object with every server event.
When all four primary identifiers are present and correctly formatted, EMQ scores of 8.0 to 9.5 are achievable.
Ready to fix your EMQ score? Build it yourself with Make.com, or go managed with Cometly.
Architecture Navigation
Visual Teardown: The video below demonstrates the exact webhook routing and payload extraction process for fixing Meta EMQ scores step by step.
1. Facebook CAPI Match Quality: What EMQ Actually Measures
Event Match Quality is not a measure of whether your CAPI events are reaching Meta — it is a measure of whether Meta can match those events to real Facebook user accounts. You can have 100% event delivery and a 3.2 EMQ score simultaneously.
That combination means every server event you send is arriving at the Graph API, but Meta cannot attribute most of them to an identifiable user in its database.
The practical consequence of low EMQ is that your server-side conversion data does not fully enter Meta’s optimisation loop. The algorithm uses matched conversion events to identify which audience characteristics correlate with purchase behaviour and adjust bid strategy accordingly.
When match quality is low, a significant portion of your server events are effectively invisible to the optimisation engine — producing a situation where you have server-side tracking deployed but the algorithm is still learning from an incomplete dataset.
According to Meta’s Conversions API customer information parameters documentation, EMQ scores are calculated based on the number and quality of matching signals in your user_data object.
Each parameter contributes differently to the match. Hashed email and phone together can produce a score around 5.0 to 6.0. Adding the fbc click ID pushes this to 7.0 to 8.5. Adding fbp, client IP, and user agent on top of that produces scores in the 8.5 to 9.5 range.
At scale, tracking accuracy matters more than ad creatives. If your data is broken, your entire ad account optimisation breaks with it. A campaign running at reported 4x ROAS on low EMQ data may be running at 2.5x in reality — the difference between a profitable scaling decision and a cash flow problem.
2. Decoding fbp and fbc Parameters
When operators open Meta Events Manager and see an EMQ score below 6.0, the diagnostic almost always leads to two missing parameters: fbc and fbp. Understanding what each one is, where it comes from, and why it matters for matching is essential before attempting to fix the score.
The fbp parameter — the Facebook Browser ID — is generated automatically by the Meta base pixel when it fires on any page. It is stored in a first-party cookie named _fbp and remains consistent across all pages a user visits on your domain during the same browser session.
Because it is generated by the pixel without any ad click required, it is present for all visitors including organic traffic, direct traffic, and email click traffic. Your server-side payload should always include fbp because it is always available as long as the pixel fired at some point in the user’s session.
The fbc parameter — the Facebook Click ID — is only generated when a user clicks a Meta advertisement. Meta appends a fbclid value to the destination URL at the moment of the ad click. This value identifies not just the user but the specific ad and click that brought them to your funnel.
When you pass fbc to the Conversions API, Meta can match the server event to both the user profile and the specific ad interaction that preceded it, which is why fbc has the highest individual impact on EMQ scores.
Missing it is the single most common reason for scores stuck in the 3.0 to 4.5 range.
Testing pitfall: If you test your CAPI payload by visiting your own funnel directly rather than by clicking a Meta ad, the fbc parameter will not exist in the URL and therefore will not be available in the webhook payload.
Always test with an actual ad click from a Meta campaign, or manually append a test fbclid to your URL to validate the capture and formatting logic before going live.
| Parameter | Origin | Function | EMQ Impact |
|---|---|---|---|
| Email (hashed) | User Input — CRM or Checkout | Primary user identity match | Critical — largest single contributor |
| Phone (hashed) | User Input — Checkout | Secondary identity match | Critical — adds 0.5 to 1.5 to score when combined with email |
| fbc (Click ID) | Ad Click URL Parameter | Links server event to specific ad interaction | Critical — only present for paid ad traffic |
| fbp (Browser ID) | Meta Pixel Cookie | Tracks browser session across funnel pages | High — present for all pixel-tracked visitors |
| Client IP Address | Server Request Headers | Geographic and network matching | Medium — adds incremental matching signal |
| Client User Agent | Browser Request Headers | Device and browser matching | Medium — complements IP address matching |
| First and Last Name | User Input — Checkout | Additional identity verification | Low — marginal incremental improvement |
3. The fbc Data Extraction Flowchart
The most common point of failure in fbc capture is not the CAPI payload itself — it is the gap between the landing page where the fbclid first appears in the URL and the payment processor where the webhook eventually fires.
If the fbclid is not explicitly captured at the landing page and passed forward through the checkout flow, it is lost before the webhook ever triggers.
To prevent fbclid loss between landing page and checkout, the most reliable implementation stores it in a Stripe payment intent metadata field when the checkout session is created.
This ensures the value is available in the charge.succeeded webhook payload regardless of how many pages the user navigates through between the initial ad click and the completed purchase.
4. Payload Formatting and SHA-256 Normalisation
Capturing the correct parameters is step one. Step two requires formatting them precisely before the payload reaches the Graph API.
Meta’s matching engine applies specific normalisation rules before computing hash comparisons — if your pre-hashing normalisation does not match Meta’s internal normalisation, the resulting SHA-256 hashes will not match Meta’s stored values even when the underlying email address or phone number is identical.
Email Normalisation Rules
- Convert to lowercase —
Customer@Example.commust becomecustomer@example.com - Strip all leading and trailing whitespace
- Do not remove dots or plus signs from the local part —
customer+tag@example.comis a valid distinct email - Apply SHA-256 after normalisation, not before
Phone Normalisation Rules
- Include the country code prefix — US numbers must start with
1 - Remove all formatting characters — no spaces, dashes, parentheses, or plus signs
- Digits only: a US number formats as
14155551234 - Apply SHA-256 after formatting to the digit-only string
fbc Parameter Formatting
The fbc parameter is not the raw fbclid value. It must be formatted as: fb.1.UNIX_TIMESTAMP.FBCLID_VALUE where UNIX_TIMESTAMP is the seconds-since-epoch timestamp at which the click occurred, and FBCLID_VALUE is the raw value from the URL parameter.
In Make.com, you construct this string using the timestamp from the click event or from the _fbc cookie if your landing page stores it.
The complete user_data object in your CAPI payload should follow this structure:
{
"user_data": {
"em": ["SHA256_HASHED_EMAIL"],
"ph": ["SHA256_HASHED_PHONE"],
"fbc": "fb.1.1715000000.IwAR2_FBCLID_VALUE",
"fbp": "fb.1.1714000000.1234567890",
"client_ip_address": "203.0.113.42",
"client_user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)..."
},
"event_name": "Purchase",
"event_time": 1715000000,
"action_source": "website",
"event_id": "ch_3Pxxxxxxxxxxxxx",
"custom_data": {
"value": 997.00,
"currency": "USD"
}
}The Hidden Cost of Low EMQ
A score below 5.0 means Meta is matching fewer than half of your server events to real user profiles. Those unmatched events provide zero optimisation value to the algorithm.
If you are spending $10,000 per month on Meta ads and your EMQ is 4.0, you are effectively funding a campaign where the algorithm is learning from fewer than half your real conversions.
Correcting EMQ from 4.0 to 8.0 can produce measurable ROAS improvement without changing creative or targeting — purely by giving the algorithm more accurate conversion data to work with.
5. Why Most CAPI Setups Still Fail
Operators frequently implement CAPI, verify that events are arriving in Events Manager, and assume the setup is complete. The event delivery confirmation does not validate the payload quality — only the EMQ score does. These are the four failure patterns that produce low EMQ on technically delivered events.
Four Silent EMQ Failures
- fbclid lost between landing page and checkout: If your checkout flow redirects through multiple pages or a hosted payment gateway without explicitly passing the
fbclidforward, it disappears before the webhook fires. The event arrives at Meta with nofbcparameter, limiting the score to what hashed email and phone alone can provide. - PII hashed without normalisation: If your Make.com scenario passes
Customer@Example.comdirectly to SHA-256 rather than first converting tocustomer@example.com, the resulting hash does not match Meta’s stored hash for that email address. The event arrives, the email field is populated, but the matching fails silently. - Batched or delayed events: CAPI events should fire as close to real-time as possible. Batching events and sending them hours after the conversion degrades EMQ because Meta’s deduplication window and session matching signals become stale. The
event_timeshould reflect the actual conversion timestamp, and events should transmit within seconds of the webhook firing. - Missing fbp cookie: If your pixel is deferred by a performance optimisation plugin and does not fire before the user reaches checkout, the
_fbpcookie is never set. Your server payload then has nofbpvalue to include, reducing the available matching signals by one of the more consistent identifiers.
6. Manual Build vs Managed Tracking
Building the CAPI pipeline manually via Make.com delivers full control over every parameter, complete first-party data ownership, and a monthly cost roughly between $9 and $50 depending on transaction volume and billing cycle.
The trade-off is that every failure mode described above requires you to diagnose and fix it yourself. Meta’s API specifications change periodically, and maintaining correct payload formatting is an ongoing operational responsibility.
Managed tracking platforms handle the normalisation, hashing, fbc capture, and payload construction automatically. They typically produce higher out-of-the-box EMQ scores because the implementation is battle-tested across thousands of accounts.
The trade-off is monthly cost and the absence of full data ownership — your conversion data transits a third-party server environment. For an objective cost comparison of managed attribution options, see our Hyros alternative guide covering Make.com DIY vs Cometly vs enterprise platforms.
Choose Your Implementation Path
Both paths deliver server-side CAPI events. The difference is who manages the normalisation, parameter capture, and payload formatting.
Path A: DIY Make.com Build
Use the flowchart and payload structure above to route the fbc parameter manually and apply SHA-256 hashing without a monthly SaaS retainer. Full data ownership. Requires technical capacity for setup and ongoing maintenance.
Path B: Managed Tracking
Deploy a dedicated tracking platform that automatically captures click IDs, normalises PII, and constructs correctly formatted CAPI payloads. Achieves 8.5 to 9.5 EMQ out of the box without manual payload configuration.
Get High EMQ Automatically →Related Attribution Guides
7. Facebook CAPI Match Quality – FAQ
A good Facebook CAPI match quality score is 6.0 or higher on Meta’s 0 to 10 scale. Scores between 7.0 and 9.0 are considered strong and indicate your payload is successfully matching to a high percentage of Facebook user profiles. Scores below 6.0 indicate missing or improperly formatted user_data parameters — most commonly absent fbc or incorrectly normalised email hashes.
The fbp parameter (Facebook Browser ID) is automatically generated by the Meta base pixel for every page visitor and stored in the _fbp first-party cookie. It is present for all visitors regardless of traffic source. The fbc parameter (Facebook Click ID) is only generated when a user clicks a Meta advertisement — it captures the specific ad interaction. Both are required for high match quality, but fbc has the highest individual impact on EMQ score because it links the server event to a specific ad click in Meta’s database.
Email: lowercase and strip whitespace, then SHA-256 hash. Phone: include country code prefix, digits only with no spaces or formatting characters, then SHA-256 hash. The fbc parameter must follow the format fb.1.UNIX_TIMESTAMP.FBCLID_VALUE. The event_time must be a Unix timestamp in seconds. Apply normalisation steps before hashing — if you hash before normalising, the resulting values will not match Meta’s stored hashes for the same customer data.
A score stuck around 3.0 to 4.0 almost always indicates one of two problems. Either the fbc parameter is entirely absent from your server payload because you are not capturing the fbclid from ad click URLs, or your SHA-256 hashing is producing incorrect values because the PII was not normalised before hashing — for example, the email retained uppercase characters or whitespace. Check your Make.com execution logs and inspect the raw payload to confirm which parameters are present and verify the hash values match what you would expect from correctly normalised input.
Yes — CAPI transmits events without fbc and Meta will process them. However, match quality is significantly reduced because fbc is the only signal that links your server event to a specific Meta ad click interaction. Without it, Meta relies on hashed email, hashed phone, fbp, IP address, and user agent to match the event to a user profile. These fallback signals fail for users on VPNs, users with cleared cookies, cross-device journeys, and browsers that block first-party cookies — which in technical B2B audiences can account for 30% or more of conversions.
Once you deploy a corrected payload with properly formatted fbc, normalised and hashed email and phone, and accurate event_time, Meta typically updates the EMQ score in Events Manager within 24 to 48 hours. The score reflects a recent rolling window of data, so partial improvement is usually visible within 24 to 48 hours of the first correctly formatted events arriving, with full stabilisation over several days of consistent correct payloads.
The most reliable method is to capture the fbclid at landing page load using JavaScript, store it in a session variable or localStorage entry, and append it to the Stripe payment intent metadata when the checkout session is created. This ensures the value is available in the charge.succeeded webhook payload regardless of how many pages the user navigates through. An alternative for Shopify operators is to use the checkout URL parameters feature to carry the fbclid through to the order confirmation webhook.
Meta’s documentation indicates scores above 6.0 allow server events to enter the optimisation loop. Scores above 7.5 are considered strong and enable the algorithm to match events to a high percentage of the Facebook user base for audience and bid optimisation. Scores above 8.5 represent near-optimal matching and are typically achievable when email, phone, fbc, and fbp are all present and correctly formatted in every server event payload.