Facebook CAPI Match Quality (2026): How to Fix a Low EMQ Score

A low Meta Conversions API Event Match Quality score is usually a data-quality problem, not an API-delivery problem. The useful question is not “How do I force EMQ to 8?” but “Which matching signals are missing, malformed, or lost before the server event reaches Meta?”

1. What Meta Event Match Quality Actually Measures

Event Match Quality, or EMQ, is a diagnostic shown in Meta’s Events Manager that reflects how effectively the customer information attached to events can be matched to Meta accounts.

That makes EMQ different from event delivery. A server request can reach Meta successfully while the information attached to that event is too limited or incorrectly formatted to produce a strong match.

Meta’s own Conversions API guidance says that additional customer information parameters can help increase matched events and Event Match Quality. Meta also says the EMQ score uses the most recent 48 hours of event data, so the number is a moving diagnostic rather than a permanent rating of your implementation.

This is why a fixed promise such as “add fbc and your score will jump from 4 to 8” is not technically reliable. The result depends on the event type, the information actually available for those users, how much of the data is correctly formatted, and how much of the recent event sample can be matched.

2. Which Data Signals Matter?

Meta supports a range of customer information parameters for Conversions API matching. The exact fields available depend on the data you legitimately collect and the event context. The goal is not to manufacture identifiers simply to raise a dashboard number. The goal is to send accurate information that already exists in the customer journey and is appropriate to share.

Do not interpret this table as a checklist where every field must exist on every event. If you do not have legitimate access to a value, do not invent one. Missing data is preferable to fabricated data.

3. fbp and fbc: The Two Fields People Commonly Get Wrong

fbp: the browser identifier

fbp is the value stored in Meta’s _fbp browser cookie. If the Meta Pixel is able to run and establish the cookie, that value can be captured on the browser side and forwarded with your server event.

Do not assume every visitor will have _fbp. Consent settings, browser behaviour, blocking, implementation timing, and whether the Pixel actually executed can all affect whether the value exists.

When it exists, the normal approach is simple: capture the complete _fbp value and pass it through as user_data.fbp. Do not hash it.

fbc: the click identifier

Meta advertising links can carry the fbclid query parameter. That click information can become the _fbc cookie value, which is then sent to Meta as user_data.fbc.

The important point is that fbclid and fbc are not interchangeable strings. The raw fbclid is the source value; fbc is the structured value Meta expects.

This is one of the most important corrections to the old implementation on this page: the timestamp embedded in the fbc value is expressed in milliseconds. The separate event_time field in the CAPI event is expressed in Unix seconds.

fb.1.1759000000000.IwAR2_example_fbclid_value

If the landing page receives ?fbclid=..., capture that identifier before the user moves through redirects, forms or a hosted checkout. Then persist it in the data that eventually reaches the server-side conversion event.

4. Normalisation and SHA-256 Hashing

Hashing does not repair dirty data. The sequence is important: first normalise the customer information according to Meta’s documented rules, then hash the normalised value.

Email

• Remove unintended leading and trailing whitespace.
• Convert the value to lowercase before hashing.
• Then apply SHA-256.
• Send the resulting hash in the appropriate email parameter.

Input:
  " Customer@Example.com "

Normalised:
  "customer@example.com"

Then:
  SHA-256("customer@example.com")

Phone

• Normalise the number into the country-aware format required by Meta.
• Remove formatting characters that should not be part of the final value.
• Include the country code.
• Apply SHA-256 after normalisation.

Input:
  +1 (415) 555-0123

Normalised:
  14155550123

Then:
  SHA-256("14155550123")

The same principle applies to other customer parameters that Meta documents as hashable. Do not assume every field uses identical normalisation rules. Check Meta’s current customer-information parameter reference before implementing additional fields.

Also remember that fbc, fbp, client_ip_address and client_user_agent are not customer PII fields that should simply be run through the same SHA-256 function.

5. A Clean Meta CAPI Payload

One reason CAPI debugging becomes confusing is that many examples on the web show only the inner event object. A server request normally contains a data array containing one or more event objects.

For a website purchase, a useful baseline structure looks like this. Replace the illustrative values with values from your own system.

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1759000000,
      "action_source": "website",
      "event_source_url": "https://example.com/thank-you",
      "event_id": "order_12345",

      "user_data": {
        "em": [
          "SHA256_HASHED_EMAIL"
        ],
        "ph": [
          "SHA256_HASHED_PHONE"
        ],
        "external_id": [
          "SHA256_HASHED_CUSTOMER_ID"
        ],
        "fbc": "fb.1.1758999000000.EXAMPLE_FBCLID",
        "fbp": "fb.1.1758998000000.123456789",
        "client_ip_address": "203.0.113.10",
        "client_user_agent": "Mozilla/5.0 ..."
      },

      "custom_data": {
        "value": 997.00,
        "currency": "USD",
        "order_id": "order_12345"
      }
    }
  ]
}

Notice the timestamp difference: event_time is in seconds, while the timestamp embedded inside the fbc value is in milliseconds.

For a website event, also make sure the event’s action_source, source URL and browser context accurately describe what happened. Do not copy a “website” payload unchanged for a CRM, phone, offline or other event source.

6. Pixel + CAPI Deduplication Is a Separate Problem

EMQ and deduplication solve different problems.

EMQ is about whether Meta can match the customer information on an event. Deduplication is about recognising that a browser event and a server event represent the same underlying conversion.

If the same purchase is sent through both Pixel and CAPI, the recommended architecture is to use the same event identity across both copies. In particular, the browser event’s eventID should correspond to the server event’s event_id, alongside the same event name.

Do not confuse fbc, fbp and event_id. They have different jobs. A click identifier identifies advertising context, a browser identifier supplies browser context, and an event ID identifies the conversion instance for deduplication.

7. The Practical Debugging Sequence

When EMQ is lower than expected, do not randomly add fields. Trace one real conversion from the landing page to Meta.

The fastest place to look when fbc disappears

Suppose the customer arrives at:

https://example.com/landing?fbclid=IwAR2_example

But the eventual Stripe or CRM webhook contains only:

{
  "email": "customer@example.com",
  "order_id": "12345"
}

The problem is not the Meta API. The click identifier was lost earlier in your data flow. Fix the capture and persistence layer before changing the CAPI payload.

8. Where Make.com Fits

Make.com does not create a higher EMQ score by itself. It is the orchestration layer between systems such as your website, checkout, CRM or payment processor and the destination API.

That makes Make useful when you need to capture a webhook, retrieve or transform customer fields, carry fbclid or cookie values forward, hash the appropriate PII, construct the CAPI payload and send it through an HTTP request.

The important distinction is between routing and data quality. A perfectly working Make scenario can still send a weak payload. Conversely, a carefully designed payload can be sent through several different server-side architectures.

If you are comfortable managing the mappings yourself, Make gives you a flexible no-code/low-code orchestration layer. If you would rather use a managed attribution product, that is a different trade-off: less infrastructure maintenance in exchange for less direct control over the implementation.

9. Common Questions

10. Related Attribution Guides