Synctag Start the check →
TRACKING SPECIALIST — BARIS ASA · LONDON
Synctag
Start the check → TRACKING SPECIALIST — BARIS ASA · LONDON

READING ROOM › SYMPTOM FILES › SYM-009

SYMPTOM FILE SYM-009 FILED 03 NOV 2026 · REVISED 03 NOV 2026

Meta Event Match Quality is low: what actually lifts it.

ALSO FILED AS
  • “Meta event match quality low”
  • “how to improve event match quality”
  • “how to increase EMQ score Facebook”
  • “Facebook event match quality poor on purchase”
  • “how to improve Facebook ad signal strength”
  • “tools to improve Meta signal quality”
  • “Conversions API low match quality”
  • “fbc missing Conversions API”
  • “Meta CAPI customer information parameters”
  • “EMQ low after setting up Conversions API”
  • “server-side GTM Meta event match quality”

Baris Asa, tracking consultant, London · Last checked: November 2026

Events Manager shows no metric called signal strength. The closest thing Meta measures for each event is Event Match Quality (EMQ): a 1 to 10 score for how well the customer details on an event match it to a Meta account. What lifts it is the data, not the tool: the customer’s email and phone, cleaned and hashed, the visitor’s real IP address and browser, and Meta’s browser and ad click IDs. Every route to Meta scores on the fields it sends.

If you think yours is low, open the Purchase event in Events Manager. Meta typically recommends aiming for 6.0 or higher. A Purchase well below that, while Meta credits fewer sales than your orders show, is the usual pattern. Ask whoever runs the setup for the Purchase score and the payload (the exact data Meta received) of one test order placed with their own email and phone. A Purchase with no email, no phone and no click ID explains a low score on its own. If nobody can do that check or read the result, it is the first step of a Meta Conversions API fix.

Why it matters: only matched events can be used for attribution and ad delivery optimisation. Unmatched events still count for basic measurement, but they don’t steer your campaigns (Meta: Conversions API best practices). EMQ is one half of event quality. The other half is whether every sale reaches Meta at all, and how quickly; missing events are covered by F-401 .

Is my Event Match Quality actually low?

Read it per event, not per dataset. In Events Manager, open your Pixel (Meta now also calls it a dataset), go to Overview, and click the score next to Purchase for the detail and Meta’s recommendations (Meta: verifying your setup).

  • Purchase and Lead are the ones that count. At checkout you usually have the customer’s email and phone, so a Purchase well below 6.0 is worth a payload check. Guest checkouts without a phone, or a Lead form that only asks for an email, can sit lower with nothing broken.
  • PageView and ViewContent will be lower, and that is normal. A browsing visitor has given you no contact details.
  • EMQ covers web events only. Meta’s docs describe it in terms of server events and don’t say whether Pixel-only events get a score. If yours shows none, that browser-only setup is the pattern behind F-401 .

Which customer details does Meta match on?

Among the highest-weighted fields Meta lists are email, phone, IP address, user agent, fbp, fbc, first name and last name (Meta: Omni Optimal setup guide). fbp is the browser ID and fbc the ad click ID, both stored in Meta’s cookies. The formats are on its customer information parameters page. Hashing turns a value into a fixed code Meta can compare but not read back.

FieldHash?Send it as
Email (em)SHA-256Trimmed, lowercase, then hashed
Phone (ph)SHA-256Digits, country code, no leading zero, then hashed
Name (fn, ln)SHA-256Lowercase, no punctuation, then hashed
City, postcode, countrySHA-256Lowercase, no spaces (postcode m11ae, country gb), then hashed
Customer ID (external_id)AdvisedThe same ID on Pixel and server
Visitor IPNeverThe visitor’s real IP (IPv6 where they have one)
User agentNoRequired on every Conversions API website event
fbp (browser ID)NoAs the _fbp cookie holds it
fbc (click ID)NoAs the _fbc cookie holds it

For a UK mobile, that means 447700900123, not 07700 900123. Two more rules from Meta’s best practices page. An event that carries only weak details, such as city, country, postcode, gender and user agent, is invalid. And stored fbp and fbc values go stale, so refresh them.

Why is Event Match Quality low? The usual faults

These are the faults I check for, in the order I check them. Each one shows in the test order’s payload.

  1. Server events built without the browser’s details. A Purchase sent from the shop’s backend (an order webhook, a plugin, a custom integration) knows the order and the email, but not the visitor’s browser. Unless something captured fbp, fbc, IP and user agent in the browser and passed them through, they are missing, or the IP is the server’s. Meta says it must be the visitor’s real IP.
  2. Email and phone hashed before they were cleaned. [email protected] and [email protected] produce different hashes. So do 07700 900123 and 447700900123. I’ve seen it on UK shops more than once: the leading zero kept, no 44.
  3. The wrong fields hashed, or hashed twice. fbp, fbc, IP and user agent go unhashed. An email hashed by a platform app and then again by a server tag matches nothing. Both look like 64 characters of hex, so hash the test order’s email yourself and compare.
  4. No click ID, because a redirect dropped the fbclid. The Pixel builds fbc from the fbclid on the landing page URL. Lose the parameter and ad visitors match on less. It is the same redirect loss as F-204 . Safari also removes a subset of known tracking parameters in Private Browsing (WebKit doesn’t publish the list), and in normal browsing when Advanced Tracking and Fingerprinting Protection is on for all browsing (WebKit: Private Browsing 2.0).
  5. The Pixel sends no customer details. Advanced matching adds them to browser events. The automatic version is set up in Events Manager. The manual version passes the details in the Pixel’s fbq('init') call, and the Pixel hashes them itself (Meta: advanced matching).
  6. In server-side GTM, the Meta tag has nothing to forward. The Meta tag maps the GA4 event’s data onto a Conversions API event (Stape: Facebook tag). If the web purchase event carried no customer details, there is nothing to map. In server Preview, check the purchase’s Event Data tab for user_data, ip_override and user_agent (Google: common event data, Preview and debug).
  7. Browser-only collection losing the signal. Ad blockers can stop the Pixel request entirely. Safari’s tracking prevention limits how long script-set cookies such as _fbp and _fbc last (WebKit: tracking prevention). With no server events behind the Pixel, that loss is filed under F-401 .

Not a fault: visitors who declined advertising cookies shouldn’t reach Meta at all, so they don’t pull your score down. If they are reaching Meta, the consent gate is the problem, covered in Consent Mode v2 with server-side GTM.

What tools or services improve Facebook ad signal strength?

Each route to Meta scores on the customer fields it sends. Before buying any tool, ask two questions: does it send events to Meta’s Conversions API itself, and which customer fields does it send? A platform that only reads ad data or reports can’t change EMQ.

  • Meta Pixel with advanced matching. The least work for browser events. On its own it is still browser-only.
  • Shopify’s Facebook and Instagram app. At Enhanced or Maximum data sharing, Shopify sends the purchase through the Conversions API and shares the customer’s name, location, email and phone for matching (Shopify Help). Third-party Shopify apps such as Elevar and Littledata do the same job with more settings; they are compared in Shopify server-side tracking compared.
  • Conversions API Gateway. Meta describes it as turning the Pixel’s browser events into Conversions API events (Meta: Conversions API Gateway), so it starts from what the Pixel collected.
  • Server-side GTM (self-hosted or on Stape) or a direct integration. Control over every field, which also means control over getting the IP, the cleaning or the hashing wrong.

On Shopify, the app at Enhanced or Maximum is the least work. Move to server-side GTM or a direct integration when the test order shows fields missing that you hold, or when you need order data the Pixel never sees. Choosing between the routes is covered in Meta Conversions API setup options compared. If the gap is a person who can read a Purchase payload, that is Meta Conversions API work. I have no partnership, affiliate or commission arrangement with any tool on this page.

How do I check the fix worked?

If someone else made the fix, ask them for the test Purchase payload before and after, and the Purchase score a few days later. The steps below are for whoever does it.

  1. Place a test order through Test Events, with an email and a UK mobile you control.
    • 1a. Server-side GTM or a direct integration: copy the code from Events Manager > Data sources > your Pixel > Test Events, and add it to the server event as test_event_code (Meta: using the Conversions API). Meta says test events are not dropped and count towards targeting and measurement, so take the code off afterwards.
    • 1b. Pixel, Shopify’s app or the Gateway: in Test Events, enter your site’s URL, open it from there and place the order in that tab. If the Purchase’s customer details don’t show there, click the Purchase score in Overview and read Meta’s details and recommendations instead.
  2. Read the payload against the table: email and phone present and hashed once, fbp present, fbc present if you arrived with an fbclid, and the IP and user agent belonging to your device, not the server.
  3. Hash the test email yourself (trimmed, lowercase, SHA-256) and compare. A mismatch means cleaning or double hashing.
  4. Wait, then read the Purchase score again. Meta publishes no refresh window for the score; I give it a few days of normal traffic.
  5. Check you haven’t created double counting. A new server route on top of the Pixel needs the same event_name and event_id on both (F-102 ).

Common questions

What is a good Event Match Quality score?

Meta scores it from 1 to 10 and typically recommends aiming for 6.0 or higher. Judge it on Purchase or Lead. A low score on PageView is normal, because a browsing visitor has given you no email or phone.

Why is my Event Match Quality still low after setting up the Conversions API?

Because the Conversions API is the transport, not the data. A server event with no email, phone, fbp or fbc, or with the server’s IP instead of the visitor’s, gives Meta little to match on. Place one test Purchase through Test Events and read its payload before changing tools.

Should I hash fbp, fbc and the IP address?

No. Hash email, phone, name and address with SHA-256 after normalising them. Send fbp, fbc, the IP address and the user agent as they are. A hashed fbp or IP, or an email hashed twice, makes that field unmatchable, so the event loses some of its strongest signals.

Does Shopify’s Maximum data sharing raise Event Match Quality?

It usually helps. Shopify says Enhanced and Maximum send the purchase through the Conversions API and share the customer’s name, location, email and phone for matching. It can’t recover an ad click ID that a redirect dropped before the visitor reached your shop (F-204 ).

What tools improve Facebook ad signal strength?

Any route that delivers the right customer fields: the Pixel with advanced matching, Shopify’s Facebook and Instagram app at Enhanced or Maximum data sharing, the Conversions API Gateway, server-side GTM, or a direct Conversions API integration. An ad-management or attribution platform only changes Event Match Quality if it sends events to Meta itself, and then the same field rules apply.

How long does Event Match Quality take to update after a fix?

Meta doesn’t publish when the score refreshes. New events show in Events Manager within about 20 minutes, but the score takes longer. I give it a few days of normal traffic before judging the change.

Sources

Read on 3 November 2026:

← back to the reading room