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:
- Meta cannot see page views or conversions from this page, so campaigns optimize without data and reported results are too low.
- Retargeting audiences stop growing.
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.
- Open your published site (custom code does not run in the Framer editor preview) in a private (incognito) window.
- Open developer tools (F12), go to the Network tab and filter by
facebook.com/tr. - Click Accept on the cookie banner and wait about 5 seconds. You should see a request with
ev=PageView(in Chrome possibly of typeping). If nothing appears, the pixel does not fire after consent. - 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.
-
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_dataandad_personalization. - Reload after clicking Accept: the banner should not come back.
-
Check GTM is loading. In the Network tab, filter by
googletagmanager.com. You should seegtm.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 nogtm.jsrequest, the GTM ID is empty or wrong, or the banner is not on this page. -
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_storagebecomesgranted, followed by an event namedcookie_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.
- that a consent update appears and
-
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_updateevent 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 thead_storageconsent 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 sendsPageViewon those page changes by itself. - 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
-
Check the tag’s consent settings. In Advanced Settings > Consent Settings, the Meta tag should require
ad_storage(plusad_user_data/ad_personalizationif you use them), and those must be what the banner grants when the visitor accepts marketing cookies. -
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.
-
Publish both the GTM container and the Framer site.
Common causes
- The Cookie Banner points to a different GTM container from the one with the Meta tag (for example an old test container).
- The Meta tag in GTM has a page view trigger only, so it never re-runs after consent. It has no trigger for
cookie_consent_update. - The Cookie Banner component is not on every page.
- The tag requires a consent type that the banner never grants (for example the banner’s marketing option is turned off, so
ad_storagestays denied). - GTM changes were saved but not published, or the Framer site was not republished after changing custom code.
How to verify the fix
- In a fresh private window on the published site: no
facebook.com/trrequests before Accept, aPageViewrequest within a few seconds after Accept, on the same page. - Reload the page:
PageViewis sent once on load, without clicking anything. - 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
- Framer Academy, Add a fully functional Cookie Banner to your Framer site: https://www.framer.com/learn/cookie-banner/
- Framer Academy, Add a Cookie Banner to your site in Framer: https://www.framer.com/academy/lessons/cookie-banner-component
- Framer Updates, Cookie Banner component: https://www.framer.com/updates/cookie-banner-component
- Sourcepeak Studio, Framer Cookie Banner & Google Tag Manager: common implementation mistakes (third-party guide;
cookie_consent_updateevent, GTM loaded by the component): https://sourcepeak.studio/blog/framer-cookie-banner-google-tag-manager-common-implementation-mistakes-to-avoid - Google Tag Manager Help, Tag Manager consent mode support: https://support.google.com/tagmanager/answer/10718549
- Meta for Developers, Meta Pixel implementation for single page applications (automatic
PageViewon history changes): https://developers.facebook.com/docs/meta-pixel/implementation/tag_spa - Meta for Developers, General Data Protection Regulation (consent API): https://developers.facebook.com/docs/meta-pixel/implementation/gdpr
- Meta Business Help Center, Test events tool: verify app and web browser events for Meta: https://www.facebook.com/business/help/2040882565969969
- IsPixelWorking live test, 2026-10-01: on a published Framer site with the Cookie Banner and a GTM ID, the data layer showed
consent defaultbefore Accept andconsent updatefollowed by{ event: "cookie_consent_update" }after Accept;gtm.jswas requested by Framer’s site script. Internal links changed pages with the History API, without a new page load.