Meta Event Match Quality: How to Raise Your EMQ Score

Taglinc hosts server-side GTM, so we are not neutral. Many Bangladeshi stores run Meta ads with cash on delivery, where the phone number is often the only customer detail, so this guide pays extra attention to it. This guide follows Meta's own Conversions API parameter rules and shows where each detail comes from in a server-side GTM setup.

Where to see your score

In Meta Events Manager, open your dataset (pixel) → Overview, click an event such as Purchase, and look at Event match quality. Meta shows the score and which customer details it receives, with the share of events that carry each one. It is calculated for server events (Conversions API), and it can take up to 48 hours to update after a change.

What raises the score

Detail	Key	Hash it?	Where it comes from in Server GTM
Email	em	Yes (SHA-256)	Checkout or sign-up form, sent in the event's user_data
Phone	ph	Yes	Checkout form; normalise first (see below)
Browser ID	fbp	No	The _fbp cookie; Meta's server tag reads it
Click ID	fbc	No	Built from fbclid in the ad click address; the tag reads the _fbc cookie
IP address	client_ip_address	No	Taken from the incoming request by the server container
User agent	client_user_agent	No	Taken from the incoming request
Your customer ID	external_id	Recommended	Your shop's customer ID, or a stable visitor ID
Name, city, country, postcode	fn, ln, ct, country, zp	Yes	Checkout address fields

Email, phone and fbc usually matter most. IP and user agent are needed but rarely enough on their own.

The phone number rule (most Bangladeshi stores get this wrong)

Meta's rule: remove symbols, letters and any leading zeros, and always include the country code, even if all your customers are in one country. For Bangladesh (country code 880):

Customer typed	Send (before hashing)
01712-345678	8801712345678
+880 1712 345678	8801712345678
8801712345678	8801712345678

Common mistakes: sending 01712345678 (no country code), 88001712345678 (country code plus the leading 0) or hashing the number with spaces or a + still in it. Each of these produces a hash that matches nobody. A small function in your web container or server container fixes it:

function normalizeBdPhone(raw) {
  var d = String(raw || "").replace(/\D/g, "");   // digits only
  if (d.indexOf("880") === 0) d = d.slice(3);       // drop country code if present
  d = d.replace(/^0+/, "");                          // drop leading zeros
  return d ? "880" + d : undefined;                  // 8801XXXXXXXXX
}

For other countries use their own code: India 91, Pakistan 92, the US 1.

Email and other details

• Email: trim spaces and lowercase before hashing.
• City: lowercase, no spaces or punctuation (dhaka, chattogram).
• Country: two-letter code in lowercase (bd), even if every customer is local.
• Names: lowercase, no punctuation; UTF-8 if written in Bangla script.

Meta's official Conversions API tag for server GTM hashes these values for you if you send them raw, and it reads email_address, phone_number and the address fields from the GA4 event's user_data. Normalise the phone before it reaches the tag; the tag does not add a country code for you.

Five fixes, in order

1. Send user_data with purchase and lead events. Email and phone from the checkout form, normalised as above. Send them only with the customer's consent and as your privacy policy allows.
2. Keep fbp and fbc working. Keep the Meta pixel on the site (with the same event ID as the server, so Meta deduplicates), and tick the option in Meta's server tag that extends the pixel cookies. Serving them from your own subdomain keeps them longer in Safari.
3. Add an external_id. Your customer ID for signed-in buyers. For guests, a stable visitor ID helps: Taglinc's User ID Power-Up gives each visitor an anonymous ID made from IP, user agent and your hostname, which you can map to external_id.
4. Send the address fields you already collect. COD checkouts often ask for the city or district; send it as ct with country = bd.
5. Send customer details on earlier events too. If the customer is signed in, AddToCart and InitiateCheckout can carry the same user_data, which improves their scores.

What a good score looks like

Meta labels scores as poor, OK, good and great. There is no fixed target: a store that only has the phone number will score lower than one with email, phone and a signed-in customer ID, and that is fine. Watch the trend after each change, and look at which details Events Manager says are missing.

FAQ

Does a higher EMQ lower my cost per purchase?

Better matching gives Meta more conversions to learn from and attribute, which usually helps delivery. Meta does not promise a fixed improvement, so judge it by your own results over a few weeks.

Is it safe to send email and phone to Meta?

They are hashed with SHA-256 before they leave your server, and you need the customer's consent where the law requires it. Never send them to GA4.

Why is my EMQ low even with phone numbers?

Almost always the format. Check one event in Events Manager → Test events, or in your server GTM Preview, and confirm the phone was 8801… before hashing.

Do I need server-side GTM for this?

No, any Conversions API setup can send these details. Server-side GTM makes it easier to collect them in one place and to keep fbp/fbc as first-party cookies.

Related reading

• Meta Conversions API for Bangladeshi stores (our tests on deduplication and late COD purchases)
• Meta Conversions API with server-side GTM
• সার্ভার সাইড ট্র্যাকিং কী? সহজ বাংলায় পুরো গাইড

Sources

• Meta: Conversions API customer information parameters (read 11 November 2026)
• Meta Business Help: About event match quality