Fix tracking codes and pixels that aren't firing

If a tracking pixel or analytics script isn't firing, your ad platform sees no conversions even when real sales or leads are happening — which makes campaigns look like they're failing when they're actually working fine. This is usually a placement, timing, or consent-blocking issue, and it's very testable with the right browser tools.

#Symptoms

• Ad platform reports zero or very few conversions despite real leads/sales coming in.
• An analytics tool (like a site analytics dashboard) shows no visits or events at all.
• Events fire inconsistently — sometimes tracked, sometimes not, for what looks like the same action.
• A pixel works on the main page but not after a form submission, purchase, or page transition.
• Tracking worked before but stopped after a page redesign or new custom code was added.

#Where tracking code goes

Before troubleshooting, confirm the code is even placed where it should be — a surprising number of "not firing" reports are actually "never installed in this spot" reports.

• Account or sub-account-level tracking code: applies site-wide across every funnel and website in that account. Found under Settings > Tracking Code (naming may vary slightly).
• Funnel or website-level header tracking code: applies to every step/page within that specific funnel or website, set in the funnel/website's own settings under a Header Tracking Code or Head Tracking Code field.
• Individual page/step code element: a code block placed directly on one page, which only affects that page.
• Event-specific pixels (like a Facebook/Meta pixel event, or a conversion API event): these are often configured through dedicated pixel or conversion settings tied to a specific funnel step (for example, firing on the "Thank You" step after a purchase or form submission) rather than pasted manually as a script.

Placing a pixel in the wrong scope — for example, only on the main landing page's code element when you actually need it firing after checkout — is one of the most common causes of "it's not tracking" that isn't a technical bug at all.

#Likely causes

1. The code is in the wrong scope (page-only instead of funnel-wide, or vice versa) so it never loads on the page where the action actually happens.
2. The pixel is only on the entry page, not the conversion page. A tracking pixel needs to load on the specific step where the event happens — for a purchase or lead event, that's usually the thank-you or confirmation step, not just the landing page.
3. A consent/cookie banner is blocking the script from loading until the visitor accepts, and many visitors don't interact with the banner, or interact with it after the page (and pixel) would have already needed to fire.
4. An ad blocker or privacy browser extension on the visitor's device blocks the tracking script outright. This is expected behavior for a meaningful share of real traffic and isn't something you can "fix" on your end — but it does mean your test browser needs to be clean to diagnose anything else.
5. The code has a typo, is malformed, or references an old/incorrect pixel ID. Copy-paste errors (extra characters, missing closing tags) can silently prevent a script block from executing.
6. A Content Security Policy or other custom header blocks the script's domain from loading, common if custom security headers were added to the page or account.
7. The event condition never actually triggers — for example, a pixel set to fire "on form submission" placed on a page that doesn't contain that form, or a purchase event configured for the wrong funnel step.

#Step-by-step fixes (most common first)

#1. Confirm placement and scope first

Check exactly which level (account, funnel/website, or individual page) the tracking code lives at, and compare that to where the tracked action actually happens. If you need a purchase event, verify the pixel/code is present on the actual confirmation or thank-you step, not just the checkout page before it.

#2. Test with browser developer tools, not just the ad platform's dashboard

Ad platform dashboards can lag by hours. To test immediately:

1. Open the live page in a clean browser profile (no ad blocker, no privacy extension) in incognito/private mode.
2. Open developer tools (F12 or right-click → Inspect) and go to the Network tab.
3. Reload the page and filter for the pixel's domain (for example, filter for "facebook" or "google" or the specific tracking domain).
4. Perform the tracked action (submit the form, complete the purchase flow) and watch for a new network request firing to that domain — that confirms the script executed.
5. Also check the Console tab for JavaScript errors, which can silently stop a tracking script from running even if it's present on the page.

Most ad platforms also offer a browser extension or tag-testing tool (a pixel helper/debugger extension) that highlights exactly which pixels are present on a page and whether they fired correctly, including which specific event parameters were sent — install the one for your ad platform and use it as your primary test method.

#3. Rule out consent and cookie-banner blocking

If your site uses a cookie consent banner that blocks scripts until accepted, test the full flow: load the page, accept consent, then perform the action, and confirm the pixel fires only after acceptance (which is expected and correct). If it never fires even after accepting, the blocking logic itself may be misconfigured to permanently suppress the script rather than release it after consent.

#4. Test in a completely clean browser environment

Ad blockers and tracking-protection browser features are extremely common among real visitors and will always prevent some percentage of pixels from firing — that's expected and not a bug to chase. But when you are testing, use a browser with no extensions and default privacy settings so you're testing the code itself, not your own blocking tools.

#5. Check for typos or malformed code

Open the code element and review it character by character, especially the pixel ID or measurement ID. A single wrong digit sends events to a different (likely nonexistent, from your perspective) property. If you copy-pasted from a document or email, check for smart quotes or invisible formatting characters that can break a script tag.

#6. Check for a Content Security Policy conflict

If custom security headers were added to the funnel/website or the domain, an overly strict Content Security Policy can silently block a tracking script's external domain from loading. Review the CSP header (if one exists) and confirm the pixel's domain is explicitly allowed, or remove the custom header if it isn't needed.

#7. Confirm the event trigger condition matches reality

For event-specific pixels tied to a funnel step (like a purchase or form-submit event), double-check the configuration actually points at the step where that event happens. A pixel configured to fire on "form submitted" but attached to a page without that specific form will simply never trigger.

#How to verify it's fixed

1. Repeat the developer-tools network test from step 2 above, in a clean private browser window, and confirm the request fires at the exact moment the tracked action happens.
2. Use the ad platform's own pixel-testing/debugger tool if available, and confirm it shows the event as received with correct parameters (not just "pixel found on page").
3. Perform a real, complete test conversion (submit the actual form, or run a real low-value test purchase if applicable) and confirm it appears in the ad platform's events manager, which can take a few minutes to reflect even once firing correctly.
4. Check that the event count in the ad platform's dashboard starts increasing again over the following day, confirming it's not just a one-off successful test.

#When to contact support

Reach out if the pixel is correctly placed on the right page/step, fires successfully in your own developer-tools test (a network request clearly goes out), but the ad platform's events manager still shows nothing after 24 hours. Include:

• The exact funnel/website and step the pixel is attached to.
• Which platform the pixel is for (and whether it's a script-based pixel or a server-side/conversion API event).
• A screenshot of the network request from developer tools showing the pixel firing.
• A screenshot of the code as it's currently placed (with the pixel ID visible so support can confirm it matches your ad account).
• Whether the issue is 100% of events missing, or only some.

#Related articles

• Form problems: not submitting or missing notifications
• Changes not showing after publishing
• Broken links, 404s, and redirects after renaming pages

#Frequently asked questions

#Why does my pixel show up in developer tools but not in the ad platform's dashboard?

Ad platform dashboards often have reporting delays of a few hours, and some events are deduplicated or filtered server-side even when the browser-side request clearly fired. Use the platform's own real-time pixel-testing tool for the fastest confirmation rather than waiting on the main dashboard.

#Will an ad blocker on my visitor's browser always block tracking?

Not always, but a meaningful share of visitors run some form of ad or tracking blocker, which is a normal and expected source of under-counted conversions across the industry — not something specific to your setup. Server-side conversion tracking (where supported) is less affected by client-side blockers than a browser-only pixel.

#Should I put tracking code at the account level or the individual funnel level?

Use account-level code for anything you want on every funnel and website (like a general analytics script). Use funnel or page-level code for anything specific to one campaign, like an event pixel that should only fire on a particular offer's thank-you page.

#Can I have more than one pixel or tracking script on the same page?

Yes, multiple scripts can coexist. If adding a new one breaks an existing one, check for duplicate variable names or conflicting script libraries between the two rather than assuming the platform limits you to one.