Fix guide · Framer · medium · about 30 min

Meta Pixel does not fire after cookie consent on Framer

For the finding “Meta Pixel does not fire after consent”. Not on Framer? See the general guide.

What this means

The Meta Pixel script is on your Framer site, but after cookies were accepted, no events were sent to Meta. As far as Meta is concerned, this page has no visitors.

Why it costs you money:

How sure we are: if our checker found and accepted your cookie banner, this is reported as critical. If we did not find a banner we could operate, it is reported as high: the pixel may be waiting for a banner we did not recognize. Test it yourself before changing anything.

How to confirm it yourself

Our check runs from a browser in the EU. Framer’s Cookie Banner has separate settings for EU visitors and for the rest of the world, and decides which to use from the visitor’s browser time zone and language, not from the IP address. A VPN does not change it; to see the EU version, set your computer’s time zone to a European city before you test.

  1. Open your published site (custom code does not run in the Framer editor preview) in a private (incognito) window.
  2. Open developer tools (F12), go to the Network tab and filter by facebook.com/tr.
  3. Click Accept on the cookie banner and wait about 5 seconds. You should see a request with ev=PageView (in Chrome possibly of type ping). If nothing appears, the pixel does not fire after consent.
  4. Navigate to another page. If events only appear now, the pixel starts one page too late and you lose every ad landing page view.

Meta Ads Data Advisor (Meta’s Chrome extension, formerly Meta Pixel Helper) and the Test events tool in Meta Events Manager (Data sources > your pixel > Test events) show the same thing from Meta’s side.

How to fix

On a typical Framer setup, the chain is: Framer Cookie Banner component, then Google Consent Mode in GTM, then the Meta tag in GTM. Check each link.

  1. Check the Cookie Banner component.

    • Its GTM ID property must contain your container ID, and it must be the same container that holds your Meta tag.
    • The component must be on every page (usually inside the navigation or footer component). If it only exists on the home page, visitors who land on other pages never see it and never send a consent update.
    • Under Regions, check that Marketing is part of what the visitor accepts. The banner maps Marketing to ad_storage, ad_user_data and ad_personalization.
    • Reload after clicking Accept: the banner should not come back.
  2. Check GTM is loading. In the Network tab, filter by googletagmanager.com. You should see gtm.js?id=GTM-... with your container ID. The Cookie Banner loads GTM itself when GTM ID is filled in, so you do not need a GTM snippet in custom code (and should not add one; see “Meta Pixel fires before cookie consent on Framer”). If there is no gtm.js request, the GTM ID is empty or wrong, or the banner is not on this page.

  3. Use GTM Preview mode. Open GTM, click Preview, enter your published Framer URL, then click Accept on the banner. Check:

    • that a consent update appears and ad_storage becomes granted, followed by an event named cookie_consent_update;
    • whether your Meta tag fired. If it shows as blocked by consent, the consent update did not arrive or does not grant ad_storage. If it was not fired at all, its trigger never ran.
  4. Fix the trigger. This is how Framer’s Cookie Banner talks to GTM:

    • First visit: the banner sets the default consent (usually denied), then loads GTM. When the visitor clicks Accept, it sends a consent update and pushes the data layer event cookie_consent_update.
    • Later visits: the stored choice is applied as the default before GTM loads, and no cookie_consent_update event is sent.

    A Meta tag with only a page view trigger is blocked on the first visit (consent is still denied) and never runs again on that page. Give it two triggers: a Custom Event trigger for cookie_consent_update (first visit) and your page view or initialization trigger (later visits). Keep the ad_storage consent requirement, and set the tag’s firing option to Once per page so it cannot send the base code twice, for example if the visitor changes their choice again. Framer switches pages without a full reload; once the pixel has started, it sends PageView on those page changes by itself.

  5. Check the tag’s consent settings. In Advanced Settings > Consent Settings, the Meta tag should require ad_storage (plus ad_user_data / ad_personalization if you use them), and those must be what the banner grants when the visitor accepts marketing cookies.

  6. If you use a tracking plugin (Pixelary, PixelFlow or another tool) instead of GTM: check in its documentation how it learns about consent and whether it reads the Framer Cookie Banner’s choice. Pixelary is built by the same team as IsPixelWorking.

  7. Publish both the GTM container and the Framer site.

Common causes

How to verify the fix

  1. In a fresh private window on the published site: no facebook.com/tr requests before Accept, a PageView request within a few seconds after Accept, on the same page.
  2. Reload the page: PageView is sent once on load, without clicking anything.
  3. Re-run the check on IsPixelWorking. The issue should be gone, and “Meta Pixel fires before cookie consent” should not appear in its place.

Sources