EMQ Score Optimisation for Healthcare Meta Ads (India, 2026)

Event Match Quality (EMQ) is the score Meta gives your Conversions API implementation to indicate how well it can match your server-side events to actual Meta users. On the surface it looks like a diagnostic. In practice it is the single most under-optimised knob on most Indian healthcare Meta ad accounts, and lifting it from a typical 5.0–5.5 baseline to 8.0+ is worth 15–25% CPL improvement — durably, once Meta's optimisation re-learns. This piece is the EMQ playbook we run on 23+ healthcare accounts and ₹9.14Cr of monthly spend at ICG. It is technical. It is also short on theory and long on the specific fields you need to send, hash, and verify.

What EMQ actually measures

EMQ is a 0–10 score Meta reports per event type, computed from how many user-identifying parameters you send and how well they match a Meta profile. Higher EMQ means Meta is confident it knows who your converter is, which lets its optimisation credit the right ads, build better lookalikes, and run more efficient auctions. Low EMQ means Meta is guessing, and the auction pays for the guess. EMQ is reported in Events Manager under the Overview tab, per event, updated with a lag of a few days.

The parameters that move EMQ (ranked)

In Indian healthcare context, ranked by measured EMQ contribution:

• Hashed email (em) — the single largest contributor, especially when the email is the primary CRM key
• Hashed phone (ph) in E.164 — nearly identical lift to email in India where phone is the primary identifier
• Hashed first name (fn) and last name (ln) — modest but consistent
• Hashed city (ct) and state (st) — small individual lift, compounds well
• External ID (external_id) — hashed CRM patient ID; helps when Meta can match across other advertisers
• Client IP address (client_ip_address) and User Agent (client_user_agent) — always send; passive parameters
• fbc and fbp cookies — critical for click-through attribution; recovered from the browser

Miss any one of the top four and your EMQ ceiling is capped.

Hashing rules you must follow — get one wrong and the parameter is invalid

Meta requires SHA-256 hashing on personal data before sending. But the pre-hash normalisation is where most implementations quietly break. Rules Meta expects:

• Email — trim whitespace, lowercase, then SHA-256
• Phone — E.164 format only (91XXXXXXXXXX or +91XXXXXXXXXX), strip all spaces, dashes, parentheses, then SHA-256
• First name and last name — trim, lowercase, remove punctuation, then SHA-256
• City — trim, lowercase, remove spaces, then SHA-256 ("New Delhi" becomes "newdelhi")
• State — 2-letter ISO code preferred, lowercased, then SHA-256
• Zip — trim, lowercase, then SHA-256; India: 6-digit pincode

Send the raw ASCII, hex-encoded SHA-256 digest. Not base64. Not double-hashed. Test with a known input like `test@example.com` and confirm the output matches Meta's documented hash.

Phone format — the single most common India-specific fix

Half the CAPI implementations we audit send Indian phones as "9876543210" or "9876 543210" and then hash them. Meta cannot match those, because its user database stores phones in E.164 with the country code. Fix: prepend "91" (no plus, no leading zero), remove all non-digit characters, then hash. Do this once at the ingestion layer, not per event. This single fix has moved EMQ from 5.2 to 6.8 on multiple accounts we have audited — no other change.

fbc, fbp — and the click attribution loop

`fbc` is the click identifier Meta sets when a user clicks a Meta ad; `fbp` is the browser identifier. Both are cookies. Reading them from the browser at conversion time and sending them with the CAPI event closes the loop between click and conversion. Without them, Meta cannot connect the server event to the specific click that drove it, so optimisation degrades. Every backend that receives a CAPI event should also receive `fbc` and `fbp` from the browser at form submit. If your form is a Meta Lead Ad (not on-site), Meta handles this internally — you do not need to send `fbc` or `fbp`.

External ID — the under-used lift

`external_id` is a hashed CRM patient ID. Meta uses it to match across advertisers who share the same user ID system, and to strengthen matching when other parameters are noisy. For healthcare in India, it is under-used because most CRMs do not have a stable, unique patient key exposed to the marketing layer. If your CRM does — patient_id, MRN, or a UUID — hash it and send it. It typically adds 0.3–0.6 to EMQ on accounts that were previously not sending it.

Event time and freshness

Meta prefers events sent within 12–24 hours of the actual action. Beyond 7 days, events are dropped from optimisation contribution. If you batch-send events from CRM once a week, half of them are worth less than they should be. Move to real-time or at least hourly sends. Also: send event_time as a unix timestamp in the exact second of the action, not the timestamp of the CAPI send. Common bug: teams stamp all events in a batch with the batch send time, which collapses attribution windows.

Deduplication so EMQ is not lying to you

If your pixel and CAPI both fire without a shared event_id, Meta double-counts. Worse, the two events may report different EMQ — the pixel event will look strong on `fbp` alone, the CAPI event will look strong on hashed personal data — and neither gets the composite EMQ it deserves. Fix with a shared event_id generated server-side at the moment of the action, passed to the browser for the pixel fire and sent with the CAPI event. Verify in Events Manager that deduplication rate on your events is 90%+ within the 48-hour window.

How to diagnose an EMQ that stopped working

EMQ drops usually have one of five causes. Check in this order:

• Deployment change — a field rename in the CRM broke a parameter map
• Consent library update — a cookie consent tool started blocking fbc/fbp
• Meta API version bump — you are on an old API version and a parameter was renamed
• Hashing bug — a normalisation step (trim/lowercase) got dropped
• Batch-send lag — event freshness slipped past the 24-hour window

Events Manager Diagnostics tab surfaces most of these within days. Check weekly.

Why EMQ improvements make lookalikes better

Every point of EMQ improvement means Meta has a cleaner picture of who your converters are. That improves lookalike quality because the seed shape Meta is searching against is sharper. On accounts where we lifted EMQ from 5.5 to 8.0, lookalike performance measurably improved over the next 30 days as Meta rebuilt the lookalike with better signal. This is a compounding return — the CAPI work you do this month makes next month's audience layer more efficient.

The first 30-day EMQ sprint at ICG

When we take over a new account, the CAPI + EMQ work is the first thing we do. A typical 30-day sprint: week 1 audit and identify the missing parameters; week 2 ship the parameter fixes and verify in Test Events; week 3 roll out and monitor Diagnostics; week 4 measure the EMQ lift and the CPL impact. Over 90 days the compound effect — better EMQ, better lookalikes, better attribution — is the difference between a mediocre account and one hitting portfolio benchmarks.

Powered by Meta Catalyst IQ — the decision engine behind every Meta ad ICG runs

ICG built Meta Catalyst IQ because most Indian healthcare brands running Meta ads waste 30–50% of budget without knowing it. It's the diagnosis + decision layer above Ads Manager — Hygiene Factors 12-point checklist, Naming Intelligence (surfaces conflicts costing ₹50K–₹2L/account/month), Creative Scoring Matrix (Core Performer / Scalable / Getting Started / Review), 2-Day Comparative, SLC Framework, Money Wastage column in ₹.

Meta Catalyst IQ Creative Scoring Matrix — every ad classified into Core Performer, Scalable, Getting Started, or Review with recommended action" loading="lazy" decoding="async" style="width:100%;height:auto;display:block;">

• Master Dashboard — 23+ accounts, ₹9.1Cr+ spend/mo optimised, ₹1,581 blended CPL vs ~₹3,200 market benchmark.
• Diagnose → Optimise → Grow — daily hygiene checks, weekly creative scoring, monthly money wastage cleanup.
• CPQL Engine — cost per qualified lead (not just cost per lead) at ad-set level. Try the interactive CPQL calculator.
• Portfolio benchmarks — IVF ₹632, derm ₹520–1,180, dental ₹620–1,800, aesthetic ₹400–900, hospital cardiac ₹3,200.

Included free with every ICG Meta ads or Performance Marketing engagement (Starter ₹20,000/-/month tier and above). Not sold standalone. Book a free 48-hour Meta ad diagnostic or WhatsApp us.

Frequently asked questions

What is a good EMQ score for a healthcare Meta ad account?

6.5–8.0 is a healthy band. Below 5.0 needs immediate audit. 8.0+ is best-in-class and typically delivers 15–25% CPL improvement over a 5.0 baseline.

What is the single most impactful EMQ fix in India?

Phone number formatting. Convert Indian phone numbers to E.164 (with the 91 country code) before hashing. Most implementations skip this and cap EMQ at 5.2.

Does sending fbc and fbp cookies really matter?

Yes — they close the click-to-conversion attribution loop for on-site conversions. Meta Lead Ads (native) handle this internally, so on-Meta forms do not need it.

Do we need consent to send hashed user data to Meta?

Yes, under DPDP Act 2023. Consent for marketing-analytics processing must be captured, disclosed, and retained. Withdrawal must stop event sending.

How often should we check EMQ?

Weekly. Any drop of more than 0.5 in a week usually signals a broken deployment, consent library change, or hashing bug.

How long before an EMQ improvement shows up in CPL?

Roughly 2–3 weeks for Meta's optimisation to re-learn against cleaner signal. Full impact including improved lookalikes typically lands over 30–60 days.

Related reading

• Meta CAPI setup for healthcare — the technical reference
• DPDP consent form fields for healthcare lead ads
• Lookalike audiences for healthcare Meta ads
• Broad vs narrow targeting
• The 5-zone creative testing framework

Authority reading: Meta's customer information parameters documentation.