Meta Pixel Consent Mode with CookieBeam: How the Bridge Signals Consent

Meta Pixel Consent Mode: What CookieBeam Actually Sends

Meta Pixel consent mode is Meta's built-in mechanism for gating the browser-side Pixel behind a visitor's cookie consent choice. The Pixel exposes exactly one consent API: fbq('consent', 'grant') to allow full tracking, and fbq('consent', 'revoke') to stop it. When revoked, the Pixel stops setting its _fbp and _fbc cookies and stops sending event data to Meta's servers. When granted, it operates normally. CookieBeam's Meta bridge automates this: it listens for cookiebeam:consentUpdate and cookiebeam:consentRestored events, reads the resolved consent mode state, and calls fbq('consent', ...) based on whether any of ad_storage, ad_user_data, or ad_personalization is granted. All three map from your banner's marketing category. If the Pixel script hasn't loaded when the consent decision fires, the bridge queues the signal and flushes it once fbq becomes available, so no consent decision is lost to a loading race.

How Meta's Own Consent Mechanism Works

Meta's Pixel exposes a two-command consent API. fbq('consent', 'revoke') suspends the Pixel: no _fbp or _fbc cookies, no events sent to Meta. fbq('consent', 'grant') resumes normal operation. This is separate from Limited Data Use (LDU), which controls server-side data processing for US state privacy laws via fbq('dataProcessingOptions', [...]). The consent command controls whether the Pixel collects at all; LDU controls what Meta does with data it already has. See Meta's GDPR implementation guide.

How CookieBeam Maps Categories to Meta's Signal

CookieBeam's consent mode resolves your banner categories into Google Consent Mode v2 keys. The Meta bridge then reads those keys and derives the signal. The marketing banner category maps to three keys: ad_storage, ad_user_data, and ad_personalization. If any one of them is granted, the bridge treats the Meta signal as granted. In practice, all three are granted or denied together when a visitor accepts or rejects marketing, so the OR logic rarely matters. But if you've configured a regional rule that grants only some ad keys, the Pixel will still receive grant.

Behavior at Each Stage

Before consent (first visit, banner untouched): The bridge hasn't fired any signal yet. If you've tagged the Pixel script as marketing in CookieBeam, it's blocked entirely until the visitor accepts. If the Pixel loads independently (e.g., via GTM's advanced consent mode), it runs in its default active state until the bridge fires.

Visitor accepts marketing: CookieBeam dispatches cookiebeam:consentUpdate with ad_storage: 'granted'. The bridge calls fbq('consent', 'grant'). The Pixel sets _fbp and begins sending events.

Visitor rejects marketing: The bridge calls fbq('consent', 'revoke'). No cookies, no events.

Returning visitor: On later page views, the runtime re-announces the stored explicit choice as cookiebeam:consentRestored, and the bridge re-applies grant or revoke without the banner reappearing. A consent change on the current page fires cookiebeam:consentUpdate. This restatement ships with the runtime release that includes the vendor bridge fix. Machine-written defaults (such as US opt-out auto-grants) are not restated.

Consent withdrawal: Revoking marketing in the preferences panel fires fbq('consent', 'revoke') immediately on the same page view.

The Queue: When the Pixel Loads After CookieBeam

If fbq isn't available when the consent event fires, the bridge queues the command and polls every 200ms until the Pixel loads, up to 50 attempts (10 seconds). This covers the common case where the Pixel script is tagged as marketing and loads only after acceptance. In practice, the Pixel loads well within that window.

What the Bridge Does Not Do

Two things to be clear about. First, the bridge does not send Meta's Limited Data Use (LDU) signal. LDU is a separate API (fbq('dataProcessingOptions', ['LDU'], 0, 0)) that tells Meta to restrict data processing under US state privacy laws like the CCPA. If your US visitors need LDU enforcement, you'll need to configure that separately. The bridge handles GDPR-style consent (should the Pixel collect data at all), not US-style processing restrictions (what should Meta do with data it already has).

Second, the bridge does not manage the Meta Conversions API (CAPI). CAPI runs server-side, outside the browser, so your server-side setup needs its own consent gating.

Common Mistakes

Relying on the bridge alone without script blocking. The bridge only fires after the visitor interacts with the banner. If the Meta Pixel is hard-coded in your <head> without being tagged as marketing, it tracks every visitor from page load onward, before the bridge has a chance to send revoke. Tag the Pixel script as marketing (type='text/plain' data-category='marketing') so CookieBeam blocks it until consent. The bridge then confirms the signal once the Pixel loads.

Confusing consent with Limited Data Use. fbq('consent', 'revoke') stops collection entirely. fbq('dataProcessingOptions', ['LDU'], 0, 0) allows collection but restricts processing. Different regulations, different API calls.

Expecting modeled conversions. Meta does not model conversions from denied-consent visitors (unlike Google's Advanced Consent Mode). Your reported conversions will drop by your rejection rate. See improving consent rates without dark patterns.

Next Steps

The Meta bridge is one of eight vendor consent bridges CookieBeam supports. For the broader picture, see the vendor bridge overview and Meta Pixel and Conversions API consent gating.