---
title: "Meta Pixel"
description: "Consent grant and revoke for the Meta Pixel, plus Limited Data Use for US opt-out visitors."
url: "https://cookiebeam.com/docs/integrations/meta-pixel"
lang: "en"
---

# Meta Pixel

Consent grant and revoke for the Meta Pixel, plus Limited Data Use for US opt-out visitors.

Two separate mechanisms cover Meta, and they answer to different laws. The consent bridge follows the marketing category the way GDPR expects. Limited Data Use follows the US opt-out record. Running one doesn't give you the other.

## Consent bridge

**What it does.** Tells the Meta Pixel whether it may fire.

**Consent category.** `marketing`, through the collapsed `adStorage` value described in [how bridges work](https://cookiebeam.com/docs/integrations/vendor-consent-bridges).

**How it works.** On each consent update the bridge sends one of:

```js
fbq('consent', 'grant');
fbq('consent', 'revoke');
```

If `fbq` isn't a function yet, the call is queued and flushed once the pixel loads, so a bridge that runs before your pixel tag doesn't lose the signal.

**Setup.** On by default. Toggle it under **Vendor Consent Signals** on the banner's App Integrations page.

## Limited Data Use

**What it does.** Flags a US visitor's events so Meta processes them under its Limited Data Use terms.

**Consent category.** None, same as Google's restricted data processing. It reads the durable US opt-out record: a US visitor who hasn't deliberately opted in to sale and sharing is flagged.

**How it works.** At load, and again on every consent update:

```js
fbq('dataProcessingOptions', ['LDU'], 1, 1000);
```

When the visitor has opted in, or isn't in the US, it sends the clearing form instead:

```js
fbq('dataProcessingOptions', []);
```

The load-time call is the important one. Meta documents `dataProcessingOptions` as belonging before `fbq('init')`, and we don't control when your pixel initializes, so the snippet does two things to get as close as it can. It reads the stored opt-out record at load rather than waiting for a consent event, and it never creates `fbq` itself, because Meta's snippet skips loading the pixel library if `fbq` already exists. Instead it waits for your pixel's own queue and puts the `dataProcessingOptions` call at the front of it, so Meta applies it before `init` and the first `PageView`. Once the pixel library has loaded, the call goes to it directly.

There's a case this doesn't cover. If your pixel loads and fires its first PageView before our script runs at all, that event goes out without the flag. Loading CookieBeam ahead of the pixel is the fix.

**Setup.** Off by default, read from the theme's `customFeatures`:

```json
{
  "usLimitedDataUse": {
    "meta": true
  }
}
```

No dashboard control exists for this yet, so enabling it means a theme update through the API.

## Testing

Filter the network tab to `facebook.com/tr`. On a US visitor with no stored opt-in you should see `dpo=LDU`, `dpoco=1` and `dpost=1000` on the request. For the consent bridge, accept and reject marketing and confirm requests start and stop.

In the console:

```js
window.fbq && window.fbq.queue
```

A queue with entries means the pixel hasn't loaded yet and the calls are waiting, which is expected rather than broken.