> 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/diagnostic-playbook-with-edgetag.md). # Diagnostic Playbook with EdgeTag #### About this playbook EdgeTag handles most of the tracking complexity for merchants, but occasionally something can look off : events stop flowing into ad channels, the EdgeTag dashboard shows DNS as not verified, Meta Event Match Quality drops, or reports start looking inflated after a pixel transfer. This playbook covers the five issues merchants are most likely to run into when using EdgeTag, and how to diagnose them with minimal code or developer-tool work. Each section describes the situation in plain language, walks the reader through what to check inside the EdgeTag dashboard, and points to the right documentation or support channel for next steps. If the right starting point isn't obvious, the maps common symptoms to the right section.\ \ Which issue is this? Each of the five issues below is a separate problem a merchant can run into — they're not sequential steps. Match the symptom to the issue, and if two symptoms match, work through them in the order suggested. Some issues cascade in a predictable direction, so order matters.


Signal	What it tells you
Nothing in DevTools → Network when an event is triggered	See Issue 1: Events not firing on the site
Events sent, but channels show 0 matches / unknown users	See Issue 2: Customers showing up as anonymous
EdgeTag dashboard says DNS not verified or SSL pending	See Issue 3: DNS / CNAME setup not verified
Meta Events Manager shows EMQ less then 6 / “Low quality”	See Issue 4: Low EMQ score on Meta
Seeing duplicate / old data — is EdgeTag the only source?	See Issue 5: Old data after switching to EdgeTag
Events fire, get 200, but channels still empty	See Issue 1 and Issue 2
Works in some regions but fails for users in EU / UK	See Issue 1 and Issue 2

## Issue 1 : Events not firing on the site **Common symptoms of this issue:** * The EdgeTag Analytics dashboard is empty or showing a sudden drop in events. * Meta Events Manager isn't receiving recent activity for the pixel, or it's reporting the event source as inactive. * Google Ads conversions or GA4 events have gone silent. * TikTok Events Manager shows no incoming signals. * Reported conversions, ROAS, and audience sizes look lower than expected, or are simply flat. If any of these symptoms apply, this is the right section to start with. In technical terms: an event is triggered (PageView, AddToCart, Purchase) and either nothing appears in DevTools, or it appears but does not arrive at EdgeTag. This section should be worked through top-to-bottom; no steps should be skipped. #### Step 0 : Is EdgeTag even on the page? Before anything else, confirm EdgeTag is installed on the exact page where events are not firing. This single check eliminates roughly half of all “events not firing” tickets in under five seconds. 1. Open the page in a browser. 2. Open DevTools (F12 or right-click → Inspect) and switch to the Console tab. 3. Type \`edgetag\` and press Enter. #### Reading the result If the console returns a function (for example ƒ edgetag()) — EdgeTag is present on the page. Skip to step 1 of the diagnostic below. If the console returns Uncaught ReferenceError: edgetag is not defined or undefined — EdgeTag is NOT on this page. The page needs to be codified before any of these issues apply. Follow the EdgeTag [Getting Started guide](https://docs.edgetag.io/overview/getting-started) to codify the page (it walks through domain verification, DNS, channels, and snippet installation). For implementation gotchas to avoid, see [Common Pitfalls](https://docs.edgetag.io/onboarding/e-commerce/common-pitfalls). {% hint style="info" %} **Also: read the console errors** When EdgeTag IS present but events still aren't firing, the Console tab is the most useful surface. Any error thrown when an event fires (bad payload, network failure, consent rejection, CSP block) will print there. Keeping the Console open while triggering the event usually reveals the root cause -- most errors name themselves. {% endhint %} #### Step-by-step diagnostic

## Issue 2 : Customers showing up as anonymous to ad channels **Common symptoms of this issue:** * Repeat customers look like new visitors to Meta or Google. * Lookalike audiences are much smaller than the actual customer base. * Retargeting audiences are tiny compared to the traffic the site receives. * Meta flags event match quality as low even though events are being sent. * Customer reports show the same person counted as multiple users. * Email or SMS campaigns can't reconnect a known customer with their browsing activity. If any of these symptoms apply, this is the right section to start with. #### What's happening Identity stitching is how EdgeTag connects an anonymous visitor to a real customer. When someone first lands on the merchant's site, EdgeTag assigns them a unique ID and tags every action they take with it. The moment they hand over their email, phone, or name on any form — newsletter popup, account signup, login, checkout — EdgeTag links that information to the same ID, and every past and future action by that visitor rolls up into one identified customer. Identity not stitching is almost always a coverage problem: the site is collecting customer information on a form, but that information isn't being passed to EdgeTag. The visitor stays anonymous to Meta, Google, and every other channel — even when they hand over their email at checkout. {% hint style="info" %} **Cross-domain stitching is different** All subdomains under the same root (e.g. [www.abc.com](http://www.abc.com), shop.abc.com, checkout.abc.com) are stitched automatically - no extra setup. Different root domains (e.g. abc.com → xyz.com) cannot be stitched in the browser. If the funnel spans multiple root domains, EdgeTag offers a backend mapping that stitches these users on the server side. It needs to be configured. For any cross-domain stitching, contact the EdgeTag support team at - they will set it up. {% endhint %} #### What to do Identity stitching is a coverage exercise, not a debug exercise. The merchant should walk through every form on the site and confirm with the EdgeTag implementation team or their developer that the customer information captured on that form is being passed to EdgeTag: * Newsletter popup * Account signup * Login * Checkout * Contact form * Loyalty program * Wishlist or any other form that asks for email, phone, or name For implementation details, see the EdgeTag [Getting Started guide](https://docs.edgetag.io/overview/getting-started) and the [Common Pitfalls](https://docs.edgetag.io/onboarding/e-commerce/common-pitfalls) page. For cross-domain stitching, raise a ticket with the EdgeTag support team.
## Issue 3 : EdgeTag DNS / CNAME setup not verified for the domain Common symptoms of this issue: * The merchant just signed up for EdgeTag and no events are being received at all. * The EdgeTag dashboard shows a warning that DNS is not verified. * The dashboard shows SSL as pending and won't proceed. * Tracking stopped working after a recent DNS provider change. * Setup completed but the dashboard never moved past “waiting for DNS”. If any of these symptoms apply, this is the right section to start with. #### What's happening EdgeTag runs on the merchant's own domain — that's what makes it first-party and able to bypass ad blockers, Safari, and Firefox tracking restrictions. To set this up, EdgeTag provides two DNS records (a CNAME and a TXT record) that need to be added at the merchant's DNS provider. Until those records are added and verified, EdgeTag cannot deploy on the site and no events will flow. For the rationale behind first-party tracking, see [Why EdgeTag](https://docs.edgetag.io/overview/why-edgetag). #### How to check if DNS mapping is in place You don't need a long debug session for this — EdgeTag exposes the DNS status directly in the dashboard. For the full DNS setup walkthrough (TXT + CNAME records, verification flow, provider-specific quirks), see the [Getting Started guide](https://docs.edgetag.io/overview/getting-started). * Log in to EdgeTag and open the relevant domain. * Scroll to the bottom of the page — the DNS mapping panel sits there and shows whether the CNAME and TXT records are detected and verified. * If verified: infrastructure is good — move on to Issue 1 (Events not firing) or Issue 2 (Identity). * If missing, not verified, or SSL pending: the records have not propagated correctly, or were never created. Copy the exact CNAME and TXT values shown in EdgeTag and confirm them in the DNS provider's zone editor. * If the dashboard still shows the records as missing 24 hours after they were added: raise a ticket with the EdgeTag support team — they'll verify what the DNS is actually serving versus what the dashboard expects. ## Issue 4 : Low Event Match Quality (EMQ) score on Meta **Common symptoms of this issue:** * Meta Events Manager flags the Event Match Quality as low or “needs improvement”. * Cost per result on Meta has gone up without an obvious reason. * Conversion volume in Meta Ads Manager doesn't match what Shopify reports. * A lookalike audience build fails or shows “limited data”. * Meta-reported ROAS is much lower than the actual ROAS. * A campaign that worked well before is suddenly performing worse. If any of these symptoms apply, this is the right section to start with. #### What's happening EMQ — Event Match Quality — is a score from 1 to 10 that Meta assigns to a merchant's event source. It reflects how confidently Meta can match incoming events to real Meta users. A higher score directly improves ad targeting, attribution accuracy, lookalike audience quality, and reported ROAS. Low EMQ almost always comes down to one thing: not enough customer information is being sent to Meta per event. Either the data is being collected on the site but never reaching EdgeTag, or it's reaching EdgeTag but formatted in a way Meta can't match against. #### Expected EMQ by event type * PageView: a low score (2–4) is normal — most visitors are anonymous on first contact. * AddToCart / InitiateCheckout: 5–7 is healthy. * Purchase: should be 9–10. Email is captured at checkout, so nearly every event should match. A Purchase EMQ below 7 is the strongest signal that something is wrong. #### What to do * Walk through every form on the site (newsletter, signup, login, checkout) and make sure customer information is being passed to EdgeTag — Issue 2 covers this in detail. Identity stitching and EMQ are the same problem in different clothes. * Capture email earlier in the funnel, not just at checkout. * If a customer database exists, pass the customer ID to EdgeTag once the user logs in. * After making changes, wait 48–72 hours before re-checking EMQ — Meta recalculates on a delay. For a detailed reference: the [EdgeTag Meta EMQ Diagnostic Guide](https://docs.google.com/document/d/19VRqJrXGYoWnspV5mz83AviLjQEjkaWwSg0tljRul9Y/edit?tab=t.0) covers score bands, how Meta matches events, deduplication, and Shopify-specific scenarios in depth. Also see the EdgeTag [Meta channel FAQ](https://docs.edgetag.io/channels/meta/faq) for Meta-specific setup questions. If EMQ is still low after these steps, raise a ticket with the EdgeTag support team. ## Issue 5 : Old data after switching to EdgeTag Common symptoms of this issue: * Pixel ownership has just been transferred to EdgeTag, and more events than expected are showing up. * Meta or Google reports more conversions than Shopify actually shows. * Meta Events Manager lists two event sources for the same pixel. * It's unclear whether the old marketing agency's pixel was removed from the site. * A Shopify app removed earlier may have left tracking code behind. * Reports look inflated and something seems to be double-counting. If any of these symptoms apply, this is the right section to start with. In technical terms: the merchant has switched over to EdgeTag (the Blotout pixel) but still sees old or duplicate data flowing into channels. The question is whether EdgeTag is actually the only source now, and how to confirm the previous tracker has stopped. #### What's expected When EdgeTag does the pixel transfer, all the previous sources feeding the same pixel are stopped as part of the cutover. Legacy data should NOT continue to flow. If duplicate or old data is still appearing, it means a legacy snippet or container is still firing on the site somewhere — find it and remove it. #### Quick diagnostic to find the legacy source in DevTools Open the site in a browser, open DevTools, switch to the Network tab, then trigger a page navigation or conversion event. Filter the Network tab by the channel-specific keyword below. If requests show up, that channel still has a legacy source firing alongside EdgeTag. * Meta: search the Network tab for facebook. Any requests to facebook.com or connect.facebook.net indicate a legacy Meta pixel still on the page. * Google: search for google — or, if you know the GTM container ID or tag name, search by that. Requests to google-analytics.com, googleadservices.com, or googletagmanager.com indicate a legacy Google source. * TikTok: search for analytics.tiktok.com. Any matches mean a legacy TikTok pixel is still firing. #### How to remove the legacy source * Audit the site for the snippet: Shopify theme head section, installed apps, GTM containers, hard-coded script tags. Remove it — EdgeTag's browser SDK handles the channel pixel firing natively. * Reload the page and run the Network tab search again. The legacy requests should be gone. If they aren't, the snippet wasn't fully removed — search the site again. * In EdgeTag, open Analytics and start the Real-time Logger to confirm events are flowing through EdgeTag and being routed to the channel as expected. {% hint style="info" %} **Most common cause** A legacy Meta pixel left behind in the Shopify theme head or in a GTM container is the #1 cause of duplicate / old data after switching to EdgeTag. Always check there first. {% endhint %} --- # 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/diagnostic-playbook-with-edgetag.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.