Two Pieces That Don't Talk to Each Other

Meta rolled out its own Consent Mode in late 2024, and it gives the browser pixel a clean on/off switch: fbq('consent', 'grant') and fbq('consent', 'revoke'). The trap is assuming that switch also controls the Conversions API. It doesn't. The pixel and the Conversions API (CAPI) are separate transports with separate consent handling, and a setup that gates one while leaving the other wide open is worse than useless, because it looks compliant while your server quietly forwards conversions for people who declined. This guide is the consent layer for both. For deduplication and the mechanics of running CAPI through a server container, see Server-Side Conversions API With Consent, which this guide sits alongside.

The Browser Pixel: Revoke by Default

The single most important change to a default Meta Pixel install is to initialize it in the revoked state, then grant only after the visitor accepts. Meta Consent Mode is designed for exactly this. Call revoke before init, and the pixel loads without setting advertising cookies or sending trackable requests. When the visitor accepts marketing, call grant, and the pixel starts writing _fbp, reading _fbc, and sending events normally.

// Revoke BEFORE init, so nothing fires on load:
fbq('consent', 'revoke');
fbq('init', 'YOUR_PIXEL_ID');
fbq('track', 'PageView');   // queued, not sent, while revoked

// Visitor accepts the marketing category:
fbq('consent', 'grant');    // pixel activates, _fbp is written,
                            // the queued PageView now sends

// Visitor withdraws, or a Global Privacy Control signal is present:
fbq('consent', 'revoke');   // stop sending, set no new cookies

Consent for the Conversions API

CAPI runs on your server and posts events straight to Meta with whatever identifiers you attach: hashed email, phone, external ID, IP address, and the _fbp and _fbc cookie values passed through. None of that reads the browser's fbq('consent') state, so you have to build the gate yourself, at the point where events leave your server. Two signals from Google Consent Mode v2 map cleanly onto what you should do, and Meta's own tooling understands them:

ad_user_data governs whether user data may be sent to Meta at all. If it's denied, strip the hashed identifiers (email, phone, external ID) from the CAPI payload, or skip the event entirely.
ad_personalization governs whether the event may feed personalization and retargeting. If it's denied, send the event with a data-use limitation flag rather than for full ad targeting.

The clean rule: no marketing consent means no CAPI event with identifiers. Partial consent means a stripped or limited event. Full consent means the full event with the same event_id you used on the browser side, so Meta deduplicates the two into one conversion.

Server-to-Server Is Still Personal Data

Sending a purchase to Meta with a hashed email and an IP address is processing personal data for advertising. It doesn't matter that it happened on your server instead of in the browser. If a visitor declined marketing, that conversion must not leave your backend, no matter how much the attribution would help. A server that fires CAPI regardless of consent is a compliance liability that's harder to catch than a client-side pixel, because it doesn't show up when someone opens their browser's network tab. Enforce the check once, where events dispatch, so nothing routes around it.

US State Opt-Outs and Limited Data Use

The GDPR world is opt-in: no consent, no tracking. US state laws (California's CCPA/CPRA and the others) are opt-out: you may track until the visitor tells you to stop, and then you must honor it. Meta's mechanism for this is Limited Data Use (LDU). When a visitor exercises a US opt-out, or arrives with a Global Privacy Control signal that your CMP treats as an opt-out, flag their events so Meta processes them in limited mode.

// Browser pixel: enable Limited Data Use for opt-out visitors.
// Signature: (options, country, state)
// 1 = enabled, 1000 = geolocation-based (let Meta infer state)
fbq('dataProcessingOptions', ['LDU'], 1, 1000);

// Or specify explicitly for a California visitor:
fbq('dataProcessingOptions', ['LDU'], 1, 1000);
// country 1 = United States, state 1000 = use geolocation

// Conversions API: send the same intent in the event payload:
//   "data_processing_options": ["LDU"],
//   "data_processing_options_country": 1,
//   "data_processing_options_state": 1000

Withdrawal and GPC Are Part of Consent

Consent you can't withdraw isn't consent. If a visitor changes their mind mid-session, or lands with a Global Privacy Control signal set in their browser, your setup has to react in real time: fire fbq('consent', 'revoke'), expire the _fbp cookie, drop anything queued for CAPI, and apply LDU to any server events that still go out (for opt-out regimes). The failure mode here is a banner that records the withdrawal in your database but keeps the pixel and the server firing because nobody wired the withdrawal event to the actual tags. Treat withdrawal as a first-class path, not an afterthought.

Modeling Is Not a Licence to Forward

Meta's modeling can estimate conversions you don't observe from consenting users, which recovers some measurement without storing identifiers for the people who declined. That's a legitimate feature. It's not permission to send identifiable events without consent. Keep the two ideas apart: model the gap for denied consent, forward real identifiers only for granted consent. Blurring them is how a well-meaning setup drifts into forwarding data it has no basis to send.

Doing It With CookieBeam

CookieBeam blocks the Meta Pixel script until the visitor accepts marketing and drives Meta Consent Mode, so _fbp is never written early. When consent is withdrawn or a GPC signal is present, the banner triggers the revoke path instead of leaving the pixel running. For the Conversions API, CookieBeam's server-side add-on stores the consent decision in a first-party cookie and exposes it inside your server container, so your CAPI tag reads the real choice and gates on it, rather than guessing from a stale client-side flag. Consent enforcement and conversion forwarding end up in the same place, which is the only place the gate reliably holds.

Related Guides and Sources

Continue with Server-Side Conversions API With Consent for deduplication, TikTok Pixel and Events API Consent, and Consent Mode v2 Parameters Reference. Primary sources: Meta's GDPR implementation for the Meta Pixel, the Data Processing Options (Limited Data Use) reference, and the Conversions API documentation.