Consent tool guide · CookieYes

Meta Pixel and CookieYes: 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 CookieYes and the Meta Pixel

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

  • The pixel fires before consent. The pixel runs before or outside CookieYes’s blocking: it is added through Google Tag Manager (GTM) on an “All Pages” trigger, a caching plugin delays the CookieYes script, or the banner uses a consent type that does not block anything.
  • The pixel stays silent after consent. The pixel is held back correctly, but its release is tied to the wrong category or to a trigger that ran before the visitor clicked.

In our scan of showcase sites, one of the ten CookieYes sites with a Meta Pixel sent pixel data before the visitor answered the banner. Ten sites is far too few for a rate, so treat this only as a reminder to test your own setup.

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

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 cookies. 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 Application tab, open Cookies and look at the cookieyes-consent cookie. After you accept, its value should contain advertisement:yes.
  5. In a fresh private window, reject all cookies. 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 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.

Whatever route you choose, check the banner settings first: CookieYes only blocks cookies in the Explicit and Implicit consent types. With the Info type, nothing is blocked.

Pixel in Google Tag Manager

  1. Load CookieYes with the CookieYes CMP template from GTM’s Community Template Gallery, on the Consent Initialization - All Pages trigger, with Support GCM enabled in your CookieYes settings. CookieYes warns that also adding its script to the page by hand can conflict with this setup. (CookieYes says this template method does not apply to its WordPress plugin; plugin users should follow the plugin’s own Consent Mode guide.)
  2. Create a 1st Party Cookie variable that reads the cookie cookieyes-consent.
  3. Create a Custom Event trigger with the event name cookie_consent_update, set to fire on Some Custom Events when that variable contains advertisement:yes. If Support GCM is switched off, CookieYes says to use .* (with regex matching) as the event name instead.
  4. Make this the Meta tag’s only firing trigger and remove All Pages. Google Consent Mode only adjusts Google tags with built-in consent checks; a Meta tag has none, so it needs its own consent condition. You can also add ad_storage under Advanced Settings > Consent Settings > Require additional consent for tag to fire (CookieYes maps its Advertisement category to ad_storage), but GTM checks that setting only when the tag is triggered. A tag on All Pages is checked once, before the click, and never again on that page.
  5. Under Advanced Settings > Tag firing options, choose Once per page, so a visitor who changes their choice does not send a second PageView.

Pixel in your site code or added by a plugin

CookieYes blocks well-known third-party scripts, Facebook pixels included, until the visitor consents. The inline base code itself does not need extra markup: CookieYes says its data-cookieyes attribute is only required on external scripts that use a src attribute. The script the base code loads (fbevents.js) comes from connect.facebook.net, so that is the address to target if the pixel still fires before consent:

  • In the Cookie Manager, open the Advertisement category, add (or edit) the Meta cookie and set its Script URL Pattern to connect.facebook.net.
  • If a plugin loads the pixel from its own script file, add the attribute to that script tag, using the advertisement category: data-cookieyes="cookieyes-advertisement".

Alternatively, use Meta’s consent API, which keeps the pixel loaded but paused. CookieYes documents this pattern: call fbq('consent', 'revoke') before fbq('init', ...), then update consent from CookieYes’s events:

document.addEventListener('cookieyes_banner_load', function (e) {
  if (e.detail.categories && e.detail.categories.advertisement) {
    fbq('consent', 'grant');
  }
});
document.addEventListener('cookieyes_consent_update', function (e) {
  fbq('consent', e.detail.accepted.includes('advertisement') ? 'grant' : 'revoke');
});

The category key stays advertisement even if you renamed the category in the banner. These events do not work with the CookieYes WordPress plugin unless it is connected to the CookieYes web app.

CookieYes automatic blocking

Automatic blocking can only hold back scripts that load after the CookieYes script, so:

  • Place the CookieYes script before the pixel and any other tracking code.
  • Exclude CookieYes from caching and optimisation plugins that delay, combine or defer JavaScript. CookieYes has exclusion guides for WP Rocket, LiteSpeed Cache, SG Optimizer and NitroPack.
  • Check that visitors who should get an opt-in banner actually get it: review the consent type (with Info, nothing is blocked) and your geo-targeting settings.

Common causes

Pixel fires before consent:

  • The banner uses the Info consent type, which blocks nothing.
  • The Meta tag in GTM fires on All Pages with no CookieYes condition.
  • A caching or optimisation plugin delays the CookieYes script, so the pixel loads first.
  • A plugin or app adds its own browser pixel from a file CookieYes does not recognise.

Pixel silent after consent:

  • The Meta tag requires ad_storage but is only triggered by All Pages.
  • The GTM condition or event listener checks the wrong category (for example analytics while the pixel’s cookies sit under Advertisement).
  • fbq('consent', 'revoke') is in place, but the grant never runs, for example because the event listeners are used with the WordPress plugin without a web app connection.

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 reject.
  2. If you use GTM, open Preview, accept the banner and check that the Meta tag fires on cookie_consent_update. Then reload: for a returning visitor who already accepted, the tag should fire without any click. If it does not, check which event CookieYes pushes on page load in Preview and add it to the trigger.
  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. CookieYes calls its support for this “Meta Pixel Consent Mode”: it is the event listener example above.

Google Consent Mode passes the visitor’s choice to Google tags, which adjust their own behaviour. A Meta Pixel tag has no built-in consent check, so it needs its own control: the cookie_consent_update trigger with the advertisement:yes condition in Google Tag Manager, CookieYes’s script blocking, or Meta’s consent API.

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