> For the complete documentation index, see [llms.txt](https://docs.edgetag.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.edgetag.io/onboarding/e-commerce/common-pitfalls/meta-emq-diagnostic-guide.md). # Meta EMQ Diagnostic Guide ## What Is This Guide and Why Does It Exist? Meta's Event Match Quality (EMQ) score tells you how well your conversion events - like purchases, add-to-carts, and page views are being matched back to real Meta users. A higher score means Meta can connect more of your events to the right people. That directly improves your ad targeting, reporting accuracy, and Return on Ad Spend (ROAS).\ \ When your EMQ score drops or was never high to begin with it's rarely one single thing. It's usually a combination of missing customer data, incorrectly formatted data, or a mismatch between what your website sends and what your server sends.
| 📖 How to Use This Guide: This guide is written for marketers who want to understand why EMQ is low and what to do about it - without needing a developer nearby. Technical notes are included at the end of each section for developers who want to go deeper. | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ### What a Low EMQ Score Costs You When EMQ is low, Meta has fewer signals to work with. Here's what that looks like in practice: * Your conversion campaigns may underperform because Meta can't identify who converted * Your reported ROAS in Meta Ads Manager appears lower than actual results * Audience targeting for retargeting campaigns becomes less accurate * Lookalike audiences are built on incomplete data, reducing their quality
## How Meta Calculates Your EMQ Score Meta assigns your events a score from 0 to 10. The score reflects how many events it can confidently match to a Meta user profile. The more information you send with each event, the higher the score. | Score Range | What It Means | Action Needed | | ----------- | ------------------------------------------ | -------------------------------------- | | 8.0 – 10.0 | Excellent - Most events are fully matched | No immediate action needed | | 6.0 – 7.9 | Good - Some data gaps present | Review optional fields for improvement | | 4.0 – 5.9 | Fair - Significant matching gaps | Prioritize hashing + field fixes | | Below 4.0 | Poor - High percentage of events unmatched | Urgent: treat as a broken integration | ### What Meta Uses to Match Events Meta matches events using customer identity signals - pieces of information that help it identify a person. These fall into two groups: #### Group 1 - High-Value Identifiers (most impact on EMQ) | Field | What It Is | | ----------------- | --------------------------------------------------------------- | | Email address | The customer's email - the single most powerful matching signal | | Phone number | Mobile number in international format (e.g. +12125551234) | | Facebook Login ID | If your site offers Facebook login, this is a direct match | #### Group 2 - Supporting Identifiers (improve match confidence) First name , Last name , City , State / Region , Zip / Postal code , Country , Date of birth , Gender.
## Step-by-Step Diagnostic Checklist Use this checklist to work through a low EMQ issue systematically. Start from the top — each step builds on the one before it.
#CheckWhere to Look
1Log in to Meta Events Manager. Note the current EMQ score and which events it applies to.Events Manager → Overview
2Click on the Purchase event. Check which customer fields are being received and matched.Events Manager → Purchase → Details
3Look for any warnings Meta has flagged. Common warnings: 'missing email', 'unmatched events'.Events Manager → Diagnostics tab
4Check if both browser and server events are active. Look at event source labels.Events Manager → Event Sources
5Confirm that both event sources send an Event ID for Purchase events.Payload inspection or developer check
6Verify that email and phone fields are present in Purchase event payloads.Test Events tool in Events Manager
7Confirm that event names match exactly between browser and server.Compare event names in both sources
8If data is present but EMQ is still low - escalate to the EdgeTag team to verify.EdgeTag channel or support
\ \ Once you've worked through the checklist above, you'll have a clearer picture of where the signal is breaking down - whether it's missing customer fields, deduplication gaps, or mismatched event names. The good news: if you're running EdgeTag, most of these issues have a direct fix built into the platform. The sections below map each root cause to exactly how EdgeTag's browser SDK and server-side Conversions API layer address it - so you know what's already working for you, and where configuration adjustments may be needed. ## How EdgeTag Handles Each Root Cause If your store is running EdgeTag, the way these EMQ issues surface and are resolved is specific to how EdgeTag's browser SDK and server-side Conversions API layer work together. This section maps each root cause to what it looks like inside an EdgeTag setup.
### Customer Data Fields - How EdgeTag Collects Them EdgeTag's browser SDK is designed to capture customer identity from your checkout automatically. It reads from the page's data layer or from Shopify's checkout events (depending on your integration mode). However, the data is only available if it exists on the page at the time the event fires. | Situation | What to Check in EdgeTag | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Email missing from Purchase events | Confirm the Shopify checkout exposes customer.email at order completion — and that the EdgeTag Shopify integration is using the correct customer object | | Guest checkout data missing | Check whether your EdgeTag setup reads from the checkout/order object (server-side) or relies on a browser-side data layer push that only fires for logged-in users | | Phone number absent | Confirm phone collection is enabled in your Shopify checkout settings and that EdgeTag's customer mapping includes the phone field | | Fields present in browser but not server | Review EdgeTag's server-side CAPI configuration — the field mapping from your order object to the outbound event payload should include all available fields | ### Hashing - What EdgeTag Manages Automatically EdgeTag handles SHA-256 hashing and normalisation automatically for all standard customer fields. For most integrations, hashing is not a manual concern. However, there are specific scenarios where hashing issues can appear: * Custom fields passed outside the standard integration path may not be hashed automatically * If customer data is pre-processed or transformed before reaching EdgeTag (e.g. passed via a custom data layer with non-standard keys), the normalisation step may be skipped * Older versions of the EdgeTag SDK had different hashing behaviour, if the SDK version hasn't been updated in some time, verify the version in use | 🔍 How to Verify: If you suspect a hashing issue in an EdgeTag setup, the fastest check is to use Meta's Test Events tool and look at the 'matched keys' column. If a field is listed as received but shows 0% match rate, contact the EdgeTag team to inspect the raw payload hash against a known-good value. | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ### Deduplication - How EdgeTag Coordinates Event IDs EdgeTag generates and manages Event IDs across both the browser SDK and the server-side CAPI layer as part of its standard setup. When both are active, Event IDs are shared automatically so Meta can deduplicate correctly. * For Purchase events: EdgeTag uses the Shopify order ID (or equivalent platform order identifier) as the Event ID on both sides * For upper-funnel events (ViewContent, AddToCart): EdgeTag generates a session-scoped ID in the browser and passes it to the server at event time * If you see duplicate Purchase events in Meta Events Manager while on EdgeTag: check whether a legacy browser pixel (pre-EdgeTag) is still active on the site alongside EdgeTag's pixel , this is the most common cause | ⚠️ Common Setup Issue: A legacy pixel running alongside EdgeTag is one of the most common sources of duplicates we see. Before investigating the EdgeTag integration, confirm there's only one active pixel ID on the site. | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ## 5Quick Wins by Scenario These are the most common situations seen across EdgeTag-powered stores with the fastest path to improving EMQ in each one. Each scenario assumes EdgeTag is the active tracking platform. #### Scenario A - High Purchase event count but EMQ is low and conversions seem inflated | 📌 Likely Cause: A legacy Meta browser pixel is likely still active alongside EdgeTag. Both are firing Purchase events. The legacy pixel sends bare events with no customer data, pulling down EMQ. Combined with the EdgeTag server events, conversions are double-counted. | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | Fastest fix: Check your Shopify theme's head section and any installed apps for a standalone Meta Pixel snippet. If found, remove it. EdgeTag's browser SDK handles browser-side pixel firing natively. Keep only EdgeTag's pixel ID active. Confirm in Meta Events Manager that the duplicate event source disappears.
#### Scenario B - EMQ was healthy, then dropped after a Shopify theme or checkout update | 📌 Likely Cause: A theme change or checkout extension update modified the page structure or data layer. EdgeTag's browser SDK may no longer be finding the customer fields it previously read from the DOM or checkout events. | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Fastest fix: Contact your EdgeTag team and share the date of the theme change. Ask them to compare event payloads from before and after that date. Focus on whether user\_data fields (email, phone) disappeared from the browser-side Purchase event after the update. If the server-side CAPI events are still intact, the EMQ drop is browser-side. #### Scenario C - EMQ is stuck around 6.0–7.0 despite all fields appearing present | 📌 Likely Cause: Fields are present but some are poorly normalised before hashing, or phone number is present but formatted inconsistently across orders (some have country codes, some don't). EMQ plateaus because a portion of events hash-match and a portion don't. | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Fastest fix: Pull a sample of 10–20 recent Purchase events from Meta Test Events. Look specifically at the phone field, check whether it's consistently formatted with the country code prefix (e.g. 12125551234 not 2125551234). Report the inconsistency to your EdgeTag team with examples; phone normalisation is configurable in the server-side field mapping. #### Scenario D — Server events look good but browser EMQ is still low | 📌 Likely Cause: EdgeTag's server-side CAPI integration is healthy, but the browser pixel component is firing events without customer context because the customer data isn't available client-side at the time the event fires (e.g. it's only read server-side from Shopify's order API). | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Fastest fix: For browser-side events that can't carry customer data (e.g. on pages before checkout), this is expected and acceptable. The key is ensuring the Purchase event specifically carries customer data on the browser side as well. Ask your EdgeTag team whether the Shopify checkout extensibility setup is configured to push customer data into the EdgeTag browser event on the order confirmation step.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.edgetag.io/onboarding/e-commerce/common-pitfalls/meta-emq-diagnostic-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.