Consent tool guide · Usercentrics

Meta Pixel and Usercentrics: fire only after cookie consent

For the findings “Meta Pixel fires before cookie consent” and “Meta Pixel does not fire after cookie consent”. See also the general guide.

What goes wrong with Usercentrics and the Meta Pixel

A working setup does two things: the Meta Pixel sends nothing while the Usercentrics banner is waiting for an answer, and it sends a PageView right after the visitor accepts, on the same page. Broken setups usually fail in one of two ways:

  • The pixel fires before consent. The pixel is not linked to Usercentrics at all: its script tag is unchanged, its Google Tag Manager (GTM) tag fires on “All Pages”, or the blocking script loads after it.
  • The pixel stays silent after consent. The pixel is linked to a service name that does not exist in your Usercentrics configuration, or its GTM trigger runs before the visitor has clicked anything.

Usercentrics stores consent per Data Processing Service (for example a service called “Facebook Pixel”), not only per category. Almost every step below depends on using that service name exactly as it appears in your Admin Interface, including capitals and spaces.

In our scan of showcase sites, none of the five Usercentrics sites with a Meta Pixel sent pixel data before the visitor answered the banner. Five sites is far too few to call the problem rare, so test your own setup anyway.

We report technical behaviour only; we cannot tell you whether your setup is legally compliant.

This guide follows the current Usercentrics Web CMP (v3) documentation. If you still run CMP v2 (the Browser UI loader from app.usercentrics.eu), script URLs and some menus differ, so check the documentation for your version.

How to check your site

  1. Open a private (incognito) window, open developer tools (F12), go to the Network tab and type facebook.com/tr into the filter. If your banner only appears in some countries, test from one of them (for example with a VPN).
  2. Load the page and do not touch the banner. Any facebook.com/tr request at this point means the pixel fires before consent.
  3. Accept all. Within a few seconds you should see a request with ev=PageView on the same page. If it only appears after you open another page, you lose the first page view of every new visit.
  4. In the Console tab, type dataLayer and open the latest consent_status entry. The key with your Meta service name should be true after you accept.
  5. In a fresh private window, deny all. No facebook.com/tr requests should appear.

Meta Ads Data Advisor (formerly Meta Pixel Helper), Meta’s Chrome extension, shows the same events if you prefer not to read network requests.

How to fix it

First check that the Meta Pixel service is added in the Admin Interface under Data Processing Services, and note its exact name. Then find every copy of the pixel: search the page source for fbevents.js and fbq(, and check your GTM container, plugins and shop apps. Choose one of the routes below and remove the other copies.

Pixel in Google Tag Manager

Usercentrics documents a variable and trigger setup for non-Google tags:

  1. Create a Data Layer Variable whose Data Layer Variable Name is the exact service name, for example Facebook Pixel. Tick Set Default Value and set it to false.
  2. Create a Custom Event trigger with the event name consent_status.* and Use regex matching ticked, set to fire on Some Custom Events when the variable contains true.
  3. Make this the Meta tag’s only firing trigger and remove All Pages. Usercentrics fires the consent event when the visitor decides and when a returning visitor’s stored consent is restored, so the tag fires on the first page in both cases.
  4. Under Advanced Settings > Tag firing options, choose Once per page, so the tag does not run again on later consent events.

Why not rely on Google Consent Mode? Usercentrics states that Consent Mode only affects Google products, and GTM only checks a tag’s Consent Settings at the moment the tag is triggered. A Meta tag on All Pages is checked once, before the click, and never again on that page. If you add ad_storage under Require additional consent for tag to fire anyway, check in Preview that accepting your Meta service actually grants it, otherwise the tag stays blocked.

Pixel in your site code or a CMS (manual blocking)

If you do not use auto-blocking, change the pixel’s script tag in two ways: set the type to text/plain, and add the data-usercentrics attribute with the exact service name:

<script type="text/plain" data-usercentrics="Facebook Pixel">
  // Meta Pixel base code, unchanged
</script>

Both parts matter. Without the type change, the script runs as normal. Without the attribute, Usercentrics cannot match the script to a service and it never runs, even after consent. Place the Usercentrics script before any third-party scripts that need consent, apply the markup to every copy of the base code, and test that the pixel starts on the same page, without a reload, after the visitor accepts.

Auto-blocking or the Smart Data Protector

Usercentrics offers two automatic options. Use one of them, never both: Usercentrics warns that they interfere with each other.

  • Auto-blocking. Add Usercentrics’s auto-blocker script before the CMP script, as the first script on the page, ahead of everything else. No markup on the pixel is needed. Auto-blocking takes its instructions from scans of your domain, so it is not effective until a scan has run, and the domain should be rescanned after you add or change tags.
  • Smart Data Protector. Add the uc-block.bundle.js script synchronously (no async or defer), before all other third-party scripts. It recognises services from a repository of known technologies, and Facebook Pixel is on that list, but only services that are also added in your Admin Interface are handled.

Either way, a pixel that loads before the blocking script, or a copy injected by GTM without the trigger setup above, can still fire before consent.

Common causes

Pixel fires before consent:

  • The pixel’s script tag has no type="text/plain", and neither auto-blocking nor the Smart Data Protector is active.
  • The auto-blocker or Smart Data Protector script loads after the pixel, or with async.
  • The Meta tag in GTM fires on All Pages with no consent trigger.
  • A plugin or app adds its own browser pixel next to yours.

Pixel silent after consent:

  • The data-usercentrics value or the GTM variable name does not match the service name exactly (for example “Meta Pixel” in the code and “Facebook Pixel” in the Admin Interface). Usercentrics notes that a mismatched variable always returns false, so the tag never fires.
  • The Meta tag requires ad_storage but is only triggered by All Pages.
  • Auto-blocking and the Smart Data Protector are both active and interfere with each other.

How to verify

  1. Repeat the private-window test: no requests before you answer the banner, a PageView within a few seconds after you accept (on the same page), and nothing after you deny.
  2. If you use GTM, open Preview, accept the banner and check that the Meta tag fires on a consent_status event. Then reload: for a returning visitor who already accepted, the tag should fire without any click.
  3. Re-run the check on IsPixelWorking.

Questions people ask

Meta’s counterpart is the pixel’s consent API: fbq('consent', 'revoke') before fbq('init', ...) pauses sending, and fbq('consent', 'grant') resumes it. The routes in this guide block the pixel until consent instead, so you do not need these commands with them.

Usercentrics states that Consent Mode only affects Google products. A Meta Pixel tag has no built-in consent check, so it needs its own control: the consent_status trigger in Google Tag Manager, data-usercentrics markup, or auto-blocking.

Can blocking the Meta Pixel affect ad tracking and performance?

Yes. While the pixel waits, Meta receives no pixel events from that visitor, and visitors who reject send none at all, so reported conversions, retargeting audiences and the data Meta optimizes on are smaller. That is why the setups above release the pixel on the same page as soon as the visitor accepts, not one page later.

Sources