Meta Pixel cookie consent that fires only after a visitor accepts

To fire the Meta Pixel only after consent, keep its script from loading until a visitor accepts marketing cookies. You can do that by blocking the script in your consent tool, by gating a Google Tag Manager tag on the ad_storage consent check, or by pausing it with Meta's fbq('consent', 'revoke') call. The Meta Pixel does not read Google Consent Mode itself: ad_storage only matters for the Pixel inside GTM's tag consent checks.

Why the Meta Pixel requires cookie consent

The Meta Pixel sets the _fbp cookie on your domain and sends requests to facebook.com, which carry the fr cookie, as soon as it loads. Both are used to track visitors across websites for advertising. Under Article 5(3) of the ePrivacy Directive, storing or accessing information on a user's device for non-essential purposes requires prior consent.

That single rule makes the Meta Pixel a marketing cookie in every EU country and in the UK under PECR. Loading it before a visitor selects "Accept" on your cookie banner breaks that rule, however valuable the conversion data might be.

Regulators have acted on the Pixel and on Meta's own cookies. On 29 August 2024 Sweden's IMY fined the pharmacies Apoteket SEK 37 million and Apohem SEK 8 million after a Pixel sub-feature they had enabled sent customers' sensitive personal data to Meta, finding their security measures inadequate under the GDPR, according to the IMY's announcement. In January 2022 the CNIL announced a EUR 60 million fine against Facebook over how hard it was to refuse cookies on facebook.com.

Three approaches to consent-based Pixel loading

There are three reliable methods for controlling when the Meta Pixel fires. Each suits a different technical setup.

You can combine CAPI with either of the first two methods. Meta recommends running both the browser Pixel and the Conversions API together for better event matching, but both channels still need to respect the visitor's consent choice.

Method 1: the fbq consent API

Meta's Pixel code includes a consent mechanism. Meta's developer page on GDPR describes fbq('consent', 'revoke') as a way to pause sending Pixel fires to Meta, called before fbq('init') on every page.

Place the standard Pixel snippet in your page, and add the revoke call before the init call:

fbq('consent', 'revoke');
fbq('init', 'YOUR_PIXEL_ID');
fbq('track', 'PageView');

When your consent callback fires after a visitor accepts marketing cookies, call fbq('consent', 'grant'), and the Pixel starts sending its fires to Meta. Meta's page does not say whether events tracked while consent was revoked are sent later, so do not count on them.

This method works without a tag manager. It is straightforward for sites with a single Pixel and a consent tool that exposes a JavaScript callback on consent change. The limitation is that the Pixel script itself still loads before consent, only paused. Stricter readings of the ePrivacy Directive prefer not loading the script at all until consent is given.

Method 2: Google Tag Manager with consent checks

If you already use Google Tag Manager, you can stop the Pixel tag from firing until consent is granted.

Setting up the Pixel tag

Create a Custom HTML tag in GTM containing the full Meta Pixel base code. Fire it on the normal All Pages trigger, or on the custom event your consent tool pushes when the visitor makes a choice. Do not use the Consent Initialization - All Pages trigger for it: Google's GTM consent documentation reserves that trigger for tags that set or update the consent state, such as your consent tool and its defaults, and says it is not for tags that should fire early.

Under the tag's Advanced Settings, open Consent Settings and select "Require additional consent for tag to fire". Add ad_storage as the required consent type. GTM then checks the consent state each time the tag's trigger fires and blocks the tag while ad_storage is denied.

Firing events after consent

Custom events (AddToCart, Purchase, Lead) need their own tags, each with the same ad_storage requirement. A tag that was blocked by its consent check does not fire later on its own. If you want the base tag to run as soon as a visitor accepts, add a second trigger on your consent tool's consent update event, so the tag fires again once consent is granted. Events that happened before the choice are not sent.

Verify the setup in GTM Preview Mode. The Tags tab should show your Meta Pixel tag as "Blocked" when consent is denied and "Fired" after the visitor accepts. Cross-check in the browser's DevTools Network tab: no requests to facebook.com/tr should appear before consent.

Connecting your consent tool to GTM

Your consent tool needs to pass the consent state into GTM. Most consent platforms, including Kukie.io, do this through Google Consent Mode v2: the tool sets ad_storage to "denied" by default and updates it to "granted" when the visitor opts in. GTM reads this state for its tag consent checks. The Pixel's own code does not read Consent Mode, so the check in GTM is what holds it back.

Kukie.io also blocks the Pixel without GTM changes: its automatic blocking recognises the Meta Pixel loader (fbevents.js) and holds it in the marketing category until the visitor accepts.

Method 3: the Meta Conversions API as a server-side alternative

The Conversions API (CAPI) sends events from your server to Meta, without the browser. CAPI sets no cookies in the browser. This gives you precise control over what data leaves your infrastructure and when.

CAPI does not remove the need for consent. If you match events to users with identifiers like email addresses or phone numbers, you are processing personal data under the GDPR. Your server must check the visitor's consent state before sending any event to Meta.

When CAPI helps most

CAPI is most useful when browser-based tracking is unreliable because of ad blockers or Safari's Intelligent Tracking Prevention. For high-value conversions like purchases, server-to-server communication is not affected by browser restrictions.

A common pattern is running the browser Pixel for consented visitors alongside CAPI for the same events. Meta deduplicates them with the event_id parameter. For visitors who decline cookies, do not send identifiable data through either channel.

What data the Meta Pixel collects

Knowing what the Pixel captures helps you explain it to visitors in your cookie banner. When active, the Pixel receives:

• HTTP headers including IP address, browser user agent and referrer URL
• The _fbp first-party cookie (a unique browser identifier)
• The fr cookie from facebook.com, where present (cross-site tracking)
• Button clicks and form field names (not values, unless Advanced Matching is turned on)
• Page URL, page title and any custom event parameters you configure

All of this is personal data under the GDPR. The IP address alone qualifies, and the _fbp cookie is a pseudonymous browser identifier.

Handling visitors who decline consent

When a visitor rejects marketing cookies, your Meta Pixel must stay silent: no _fbp cookie and no network requests to facebook.com/tr.

Your Meta Ads reporting will then show fewer events than your actual traffic. How many fewer depends on your audience and how many visitors accept. The gap is real, and no method recovers individual-level data for visitors who refused.

You can narrow the gap by explaining clearly what the Pixel does, so visitors can make an informed choice, as long as accepting and rejecting stay equally easy.

Testing and verification

After setting up consent-based Pixel loading, check that it works. Open your site in a private browser window, decline all cookies, and check the following:

• Open DevTools (F12), go to the Application tab, and confirm no _fbp cookie appears under your domain
• In the Network tab, filter for facebook.com and confirm no requests appear
• Accept marketing cookies in the banner, then confirm the _fbp cookie appears and a request to facebook.com/tr is sent
• In Meta Events Manager, use the Test Events tool to confirm events arrive only after consent

Scheduled cookie scans can catch regressions when you update your site or change tag configurations.

Common mistakes to avoid

Several implementation errors can undo the work. Loading the Pixel script in the <head> without the fbq('consent', 'revoke') call, or without a blocking rule in your consent tool, means cookies are set before your banner even renders. In GTM, a Pixel tag on the All Pages trigger with no ad_storage consent check does the same.

Another frequent issue is forgetting Facebook's other embeds. Even if you block the Pixel, embedded Facebook social plugins (Like buttons, Share widgets) can set tracking cookies. These need separate consent handling.

Finally, do not assume that using CAPI alone exempts you from consent. Server-side tracking that processes personal data for advertising still needs a lawful basis, and for marketing purposes that basis is almost always consent.

Meta Pixel and consent: quick answers

Check whether your Meta Pixel fires before consent

If you are not sure whether your Meta Pixel fires before consent, start with a scan. Kukie.io lists the cookies your pages set, sorts them into categories and holds the Pixel until visitors accept marketing cookies.

Start free