Why is my Facebook Pixel being blocked by Tag Manager?

Tag Manager itself rarely blocks the Facebook Pixel: it is usually held back by consent, by your site’s Content Security Policy (CSP) or by an ad blocker in the visitor’s browser. If you find the Facebook Pixel blocked, Tag Assistant and the browser’s Network tab show you within minutes which of the three applies.

Blocking is not always a fault: a pixel that waits for consent does what your banner promises. It becomes a problem when visitors cannot consent at all, or when the pixel fires although they declined. If far fewer phone users than desktop users accept, read why consent rates differ between desktop and mobile.

How do you find out in five minutes why the Facebook Pixel is blocked?

1. In GTM, click Preview, enter your URL and click Connect. If Tag Assistant reports “Could not connect”, Google names a blocked container as a possible reason.
2. Before you touch the banner, select the pixel tag and open the Consent tab in its output. The On-page Default column should read denied. Accept marketing cookies, then check On-page Update and whether the pixel tag has now fired.
3. Look at Page issues in Tag Assistant. According to Google’s CSP guide for Tag Manager, resources blocked by your CSP appear there, and View issue lists all of them.
4. In Chrome DevTools, open Network and filter for “facebook”. A request marked net::ERR_BLOCKED_BY_CLIENT was stopped by an extension, not by GTM; Chromium defines it as “The client chose to block the request.” Console messages starting with “Refused to load” come from your CSP.

Why are consent settings the most common blocker?

Every web tag in GTM has Advanced Settings → Consent Settings. Under Additional Consent Checks you choose between “Not set”, “No additional consent required” and “Require additional consent for tag to fire”. With the last option the tag only fires if all selected consent types are granted “when the tag is triggered”.

A pixel on a page view trigger is checked when the page loads; if the visitor accepts a second later, the trigger has already run. Test in Tag Assistant whether the pixel fires on the page where you click accept. If it only fires from the next page on, add a trigger for the event your consent tool pushes when consent is given, then check in Preview that every page still sends exactly one PageView.

The reverse error is common too. An online shop had its pixel and a Meta lead tag set to “No additional consent required”, so both fired before the visitor had made any choice. We switched them to require ad_storage and ad_user_data; since then the pixel only loads after acceptance. The Consent Overview (enable it under Admin → Container Settings, open it from the Tags list) shows every tag under “Consent Not Configured” or “Consent Configured”.

What must your CSP allow for Google Tag Manager?

• The container. Google recommends a nonce generated by your server for every response, placed in the script-src-elem directive and in the nonce attribute of the GTM snippet. “Tag Manager will then propagate the nonce to any scripts that it adds to the page.” The source to allow is https://www.googletagmanager.com.
• Custom JavaScript variables. Without 'unsafe-eval' they “evaluate to undefined”. Pixel data read from them stays empty. Google suggests custom templates instead.
• Meta. Meta’s pixel documentation says you should allow JavaScript from https://connect.facebook.net. In our tests the events themselves went to facebook.com/tr, so check your image and connection rules (img-src, connect-src) as well.

A full console is not proof of a blocked pixel. At a service business the CSP rejected several secondary Meta endpoints and filled the console with errors, yet the PageView arrived.

What if ad blockers block the pixel (“blocked by client”)?

Some blockers stop googletagmanager.com itself. Then no tag fires, the pixel included. You cannot change that on your visitors’ devices, but you can size the gap by comparing ad clicks with measured sessions per device. Meta’s server-side Conversions API is a separate project with its own consent questions.

What did three client cases with hidden banners and a false alarm show?

A retail client added a CSS rule in early June to hide the cookie icon on phones. The selector also hit the consent dialog on screens narrower than 768 pixels. Phone users never saw a banner, so GTM held back every marketing tag. Mobile GA4 sessions fell from 1,275 in May to 84 in June and to zero from 24 to 27 July. We narrowed the rule on 28 July and replaced the banner on 29 July. Mobile sessions rose to 18 that day and 31 the next.

A second retail client lost its mobile data the same way: an external developer hid the banner on mobile and tablet so it would not lock the screen. Mobile sessions dropped by 87 % from 12 June; the fix went live on 16 June. At the service business, a status report claimed the pixel had been “silent” since 0:58. The timestamp was stale: our test showed no request to Facebook without consent and a PageView with consent, exactly as intended.

Check in this order: consent, CSP, blockers. Test on a real phone in a private window: the banner must be visible, the pixel silent before consent and the PageView sent after acceptance. Give the pixel “Require additional consent for tag to fire” with the consent type your banner maps to marketing cookies, and review every third-party tag in the Consent Overview.

Sources

• Tag Manager Help: Consent mode support
• Google for Developers: Use Tag Manager with a Content Security Policy
• Google for Developers: Consent mode overview

Is your pixel silent, or firing too early? We check consent settings, CSP and your banner on desktop and mobile and fix what blocks the data. Book a free initial call or see how we handle Google Ads and conversion tracking.