Diagnostic Playbook with EdgeTag
Events not firing · Identity not stitching · DNS / CNAME issues · Low EMQ · Old data after switching to 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
Events sent, but channels show 0 matches / unknown users
EdgeTag dashboard says DNS not verified or SSL pending
Meta Events Manager shows EMQ less then 6 / “Low quality”
Seeing duplicate / old data — is EdgeTag the only source?
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.
Open the page in a browser.
Open DevTools (F12 or right-click → Inspect) and switch to the Console tab.
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 to codify the page (it walks through domain verification, DNS, channels, and snippet installation). For implementation gotchas to avoid, see Common Pitfalls.
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.
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.
Cross-domain stitching is different
All subdomains under the same root (e.g. 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 support@blotout.io - they will set it up.
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 and the 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.
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.
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 covers score bands, how Meta matches events, deduplication, and Shopify-specific scenarios in depth. Also see the EdgeTag Meta channel 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.
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.
Last updated
Was this helpful?