Loading tutorials…
Loading tutorials…
Your pixel was working last month. Now Events Manager shows zero. Or it shows events but not the ones you need. This is the diagnostic sequence specialists run.
Who this is forAnyone with a previously-working Meta Pixel that has gone quiet — or a pixel that fires some events but not others. If you've already verified the pixel ID is correct and you're still seeing nothing, this walkthrough covers the next layer of causes.
What you'll need
Step 1
Open the affected page in incognito, install Meta Pixel Helper, click the icon. If you see "No pixel found," the script never loaded.
Install Meta Pixel Helper (Chrome Web Store) if you do not have it.
Open an incognito window. Visit the page where the event should fire.
Click the Meta Pixel Helper icon. Expected: 'One Pixel found' with your pixel ID. Each event fired on the page should appear in the list.
If you see 'No pixel found': the pixel script never loaded on this page. Causes: (a) the install method (theme code, plugin, GTM) is broken; (b) a recent code change removed the pixel; (c) a caching plugin is serving an old cached page without the pixel.
If you see 'Pixel found, no events fired': the pixel loaded but the specific event trigger never fired. Move to Step 2.
Step 2
Events Manager → Test Events → enter your browser test ID. Trigger the event on your site. Watch for it to appear in real time.
Events Manager → select your pixel → "Test Events" tab.
Click "Test Browser Events." A Meta-generated test ID appears (looks like TEST_xxx). Copy it.
Open Meta Pixel Helper on your site. Click the gear icon → set the test ID. (Or pass it manually via &fbclid_test=TEST_xxx in the URL.)
In incognito, visit your site. Trigger the event you expect to fire.
Return to Events Manager Test Events. The event should appear within 60 seconds with status "Received."
If the event appears: pixel is firing — the issue is downstream (CAPI dedupe, AEM priority, attribution window). Move to Step 5.
If the event does NOT appear: pixel is firing for some events but not this one. Move to Step 3.
Step 3
Every event has a trigger condition (page URL match, button click, dataLayer event). Verify the condition is actually true on the page where you expect the event.
For GTM users: open GTM Preview Mode → visit your site → trigger the action that should fire the event. The Preview panel shows which tags fired and which did not, with reasons.
For PixelYourSite users: PixelYourSite → Events → review the event mapping. Confirm the event trigger (URL pattern, WooCommerce hook) matches your site.
For Shopify channel app users: standard events (PageView, ViewContent, AddToCart, InitiateCheckout, Purchase) auto-fire on Shopify-native actions. If a standard event is missing, the channel app is likely misconfigured — reinstall.
For custom event firing (form submits, button clicks): verify the event handler is actually attached. In browser DevTools → Console, you should be able to manually call fbq('track', 'Lead') and see it fire in Pixel Helper. If manual firing works but the handler doesn't, the handler attachment is broken.
Step 4
If your site has a consent banner and the visitor has not consented (or has declined), the pixel will not fire. This is correct behavior but often surprising.
In incognito, visit your site. Look for the consent banner. Reject all cookies/marketing consent.
Open Pixel Helper. Expected: NO pixel events fire (because consent was rejected). This is correct behavior.
Accept consent. Reload the page. Pixel events should now fire.
If pixel still does not fire AFTER accepting consent: your consent manager (Cookiebot, OneTrust, etc.) is misconfigured. The consent state is not propagating to the pixel.
Common fix: in your CMP, ensure 'Marketing' or 'Advertising' consent category is mapped to Meta Pixel. Some CMPs require you to manually associate each tag with a consent category.
For GTM users: each tag has a Consent Settings section. Verify the consent type required (e.g., ad_user_data) matches what your CMP grants.
Step 5
Two pixels can fire and silently break each other — especially if eventID dedupe expects one ID but two are firing. Pixel Helper shows duplicates clearly.
Pixel Helper → if you see "X Pixels found" where X > 1: you have duplicate installs.
Click each pixel ID to see which install method is firing it. Common combinations:
(a) Old theme.liquid code + new Shopify channel app — strip theme code.
(b) Manual pixel in functions.php + PixelYourSite plugin — disable one.
(c) PixelYourSite + GTM both firing pixel — pick one path.
(d) Two pixel IDs (you accidentally created multiple) — pick one as canonical, delete or pause the other in Business Manager.
Step 6
If browser events fire but Server events are missing, your CAPI is offline. Events Manager Overview shows Browser vs Server breakdown.
Events Manager → your pixel → Overview tab.
Look at any event row. You should see counts for both 'Browser' and 'Server' (if CAPI is configured).
If Server column is 0 or missing: CAPI is not firing. Causes:
(a) Shopify channel app set to 'Standard' instead of 'Maximum' data sharing — change in Apps → Facebook & Instagram by Meta → Settings.
(b) Stape sGTM container expired or hit free tier limits — check Stape dashboard.
(c) Direct API access token revoked — check Events Manager → Settings → Conversions API → access tokens.
After fixing, wait 30 minutes and re-check. CAPI events typically appear within 5-15 minutes of firing.
Step 7
If only certain events appear in iOS reporting, AEM priority order may be wrong. Lower-priority events fire but are stripped from iOS attribution.
Events Manager → Aggregated Event Measurement → your domain.
Review the 8 priority slots. Your money event (Purchase, Lead) should be at slot 1.
If PageView or a lesser event is at slot 1: iOS users who fire Purchase AFTER PageView in the same session have Purchase invisibly stripped — only PageView counts on iOS.
Fix: reorder events with money event at slot 1. Note the 72-hour propagation pause after changes.
Also check: is the event you expect to fire even in the 8-slot list? If not, AEM is silently ignoring it on iOS. Add it (cap is 8 events).
Common mistakes
Assuming caching is not the issue
What goes wrong: You test the pixel in incognito (which bypasses cache). It works. You declare it fixed. Production users (cached pageviews) never see the pixel. Your real-world event volume is 10-20% of what you think it is.
How to avoid: Always test in BOTH incognito and a regular browser tab (after clearing cache + visiting fresh). If incognito works but regular doesn't, your caching layer is stripping the pixel.
Not testing on iOS Safari specifically
What goes wrong: Pixel fires fine on desktop Chrome. On iOS Safari, ITP (Intelligent Tracking Prevention) blocks the pixel after 24 hours of inactivity. Your iOS conversion volume drops by 30-50% but you blame iOS 14 in general, not the specific ITP issue.
How to avoid: Test on iOS Safari with a 25-hour gap between sessions. If the second visit shows no pixel, you need Advanced Matching + CAPI to recover iOS attribution. Browser pixel alone is insufficient on iOS.
Confusing "Event not in Test Events" with "Event not fired"
What goes wrong: Test Events shows nothing. You assume the pixel is broken. In reality, Test Events only shows events for the specific browser test ID you set up — your normal browsing isn't being tracked there.
How to avoid: For a pixel-wide health check, use Events Manager → Overview tab (production data), not Test Events tab (test browser only).
Removing legacy pixel code without testing the new install first
What goes wrong: You strip old theme code AND simultaneously install a new channel app. Something breaks. You don't know which change caused it. Rolling back both means losing days of debugging time.
How to avoid: Change ONE thing at a time. Strip legacy code → verify pixel STILL fires from the new install (because it was already running) → THEN make the next change.
Ignoring browser console errors
What goes wrong: The pixel script throws a JavaScript error (e.g., 'fbq is not defined' or 'Content Security Policy blocked Meta'). You don't open DevTools, you don't see the error, you spend 4 hours debugging the wrong layer.
How to avoid: Open DevTools → Console tab on the affected page. Look for any error mentioning 'fbq,' 'facebook,' 'meta,' or 'pixel.' If you see errors, fix them first — they're often the entire cause.
Assuming the issue is platform-side (Meta)
What goes wrong: When you can't find the issue, you conclude 'Meta is having problems' and wait it out. Days pass with broken tracking. Meta is rarely the issue in 2026 — the install layer is almost always the cause.
How to avoid: Check Meta Status (metastatus.com) for any platform outages. If clear, the issue is your install. Walk through Steps 1-7 above systematically.
Recap
Done — what's next
How to set up the Meta Conversions API (and actually deduplicate events)
Read the next tutorial
Hand it off
Pixel troubleshooting one time is a project. Pixel monitoring forever is a job. A Meta Ads specialist on EverestX can audit your install, fix the cause, set up alerts so you catch breaks within hours instead of weeks. Audit + fix typically runs $50-100 at $14-16/hr; ongoing monitoring is part of standard $200-400/mo retainers.
See specialist rates
Three usual culprits: (1) a code deploy or plugin update on your site (check version control); (2) your CMP updated and consent state is being misread now; (3) Meta deprecated your access token (rare but happens with Business Verification status changes). Check site change history first.
Missing or mismatched eventID. The browser fbq() call and the CAPI POST must pass the same eventID string for the same event. If one passes it and the other doesn't — or they pass different IDs — Meta sees two separate events. Generate eventID once on the client, pass to both pixel and CAPI.
Test Events is real-time, Overview is aggregated daily (with a 1-2 hour delay). It is also possible the event is appearing in Test Events but being deduplicated against an existing event with the same ID. Wait 6 hours and re-check Overview. If still 0, check Diagnostics for warnings.
Common causes: (1) legacy theme code from a previous setup is still in place; (2) an app or plugin is injecting a pixel you didn't realize; (3) GTM is firing one AND a plugin is firing another. Click each pixel ID in Helper to see which install method is responsible. Strip the duplicate.
If your homepage is statically generated and product pages are dynamic (or rendered by a different template), the pixel may only be included in the static template. Check whichever template renders product pages and ensure the pixel script is loaded there. For Shopify, the channel app should handle this automatically — for WordPress, your plugin may need an explicit setting to fire on dynamic page types.
Meta Ads
The browser pixel alone loses 20-30% of conversions on iOS. CAPI sends events from your server to Meta, recovering most of it. Three install paths: Shopify-native, server-side GTM, and direct API. We cover all three.
Meta Ads
Shopify deprecated the old pixel-in-theme.liquid path. The modern install runs through the Facebook & Instagram by Meta channel app and pulls in CAPI for free. Here's how to do it without double-counting purchases.
Meta Ads
WordPress is the trickiest pixel install of the major platforms because there's no native channel app. You have two real options: a dedicated pixel plugin or a GTM container. Picking wrong means rebuilding in 6 months.
Meta Ads
Meta's response to iOS 14.5 — Aggregated Event Measurement — caps you at 8 prioritized events per domain and forces you to rank them. Get the order wrong and your most important conversion (Purchase) silently drops out of iOS reporting.