Do fbc and fbp improve Event Match Quality?

Yes. Alongside email and phone, fbc and fbp are among the parameters Meta uses to match events. Sending them consistently — especially through the Conversions API — is one of the quickest EMQ wins after hashed email and phone.

Why does fbp disappear on Safari?

Apple's Intelligent Tracking Prevention caps the lifetime of cookies set client-side via JavaScript (as short as 7 days, or 24 hours in some cases). The _fbp cookie expires, so returning Safari shoppers show up without it. Setting the cookie server-side as a genuine first-party cookie extends its life.

fbc and fbp Are Missing — Why Your EMQ Stays Low (and the Fix)

Q: What are _fbc and _fbp?

_fbp is the Facebook browser-pixel cookie set on every visitor by the Meta Pixel — a stable first-party ID. _fbc is the click cookie, set only when a shopper arrives from a Meta ad carrying an fbclid URL parameter. Both are sent with events to help Meta match the event to a person, so they directly lift Event Match Quality.

Q: Why is _fbc always empty?

_fbc only exists when the visitor arrived via a Meta ad link containing fbclid. Organic, direct and non-Meta paid visitors never have one — so a low _fbc coverage rate is partly expected. It becomes a problem when shoppers who DID click an ad still lose it, usually because fbclid wasn't captured and persisted.

If your Meta Event Match Quality is stuck in the 4–6 band and you’ve already added email and phone, the next place to look is almost always _fbc and _fbp. These two parameters are quiet but powerful match signals — and on Shopify they go missing more often than store owners realize.

What fbc and fbp actually are

_fbp (browser ID). The Meta Pixel drops this first-party cookie on every visitor the first time it loads. Format: fb.1.<timestamp>.<random>. It’s a stable identifier for the browser, sent with both Pixel and CAPI events.
_fbc (click ID). Set only when a shopper lands from a Meta ad whose URL carries an fbclid parameter. Format: fb.1.<timestamp>.<fbclid>. It ties the event back to the exact ad click — a very strong match signal.

Both are sent alongside hashed email/phone to help Meta decide which person an event belongs to. Missing them means weaker matching, lower EMQ, and worse attribution — the same problem iOS and cookie loss create from the other direction.

Set expectations first: fbc is supposed to be partial

Before you “fix” anything: _fbc will never be near 100%. It only exists for visitors who clicked a Meta ad. Organic, direct, email and non-Meta paid traffic legitimately have no fbc. So a low overall fbc rate isn’t automatically a bug.

The real problem is when ad-clickers lose it. That’s what’s worth fixing.

Why they go missing on Shopify

Cause	Which one it hits	What happens
ITP / Safari cookie caps	`_fbp` (and `_fbc`)	JS-set cookies expire in ~7 days (sometimes 24h); returning shoppers show up without them
Pixel loads too late	`_fbp`	The event fires before the pixel set the cookie, so nothing is attached
fbclid not captured/persisted	`_fbc`	Ad-clicker lands, but the id is never read from the URL and stored, so checkout has no `_fbc`
CAPI-only, browser values not forwarded	both	Server event is sent without the `fbp`/`fbc` the browser had — a very common server-side gap
Ad blocker blocks the pixel	`_fbp`	Cookie never set at all
Domain/subdomain mismatch	both	Cookie set on one host isn’t readable on the checkout host

The fix, in order of payoff

Load the Pixel early, and send both parameters with CAPI. Your Conversions API events must include the fbp and fbc your browser captured. In a properly wired Pixel + CAPI setup, the browser passes fbp/fbc to the server, and the server includes them in the matching payload. If you only send server events without these, you’re leaving match quality on the table.
Capture and persist fbclid yourself. When a shopper arrives with ?fbclid=..., read it, build the fb.1.<timestamp>.<fbclid> value, and store it (cookie or storage) so it survives to checkout — even if the native cookie is later capped. Many server-side templates and apps do this for you; verify yours actually does.
Set the cookies server-side (first-party). A cookie written by your server in an HTTP response survives ITP far better than one written by JavaScript. This is a core reason server-side tracking lifts EMQ: it extends _fbp/_fbc lifetime and makes them harder to block.
Keep everything on one domain. Make sure the pixel and your checkout run under the same first-party domain so the cookies are in scope end-to-end.

How to verify

In Events Manager → Test Events, place a test order and inspect the Purchase event: confirm fbp and (for an ad-click test) fbc appear in the parameters.
In Events Manager → your event → Event Match Quality, check the per-parameter breakdown — Meta shows coverage for fbc, fbp, email, phone and the rest. Chase the parameters with low coverage that you can control.
Full method: how to raise EMQ, parameter by parameter.

Want a coverage read on your match parameters without digging through Events Manager? The free Tracking-Health Mini-Audit flags weak EMQ signals and the fastest fixes in ~10 minutes.

FAQ

What are _fbc and _fbp? _fbp is the browser-pixel cookie set on every visitor; _fbc is the click cookie set only when someone arrives from a Meta ad with fbclid. Both are match signals sent with events.

Why is _fbc always empty? It only exists for ad-clickers. Non-Meta traffic never has one — but ad-clickers losing it (unpersisted fbclid) is a real, fixable problem.

Do they improve EMQ? Yes — after email and phone, sending fbc/fbp consistently through CAPI is one of the quickest EMQ wins.

Why does _fbp vanish on Safari? ITP caps JS-set cookie lifetimes; setting the cookie server-side as first-party extends it.

Sources

Meta — Conversions API: customer information parameters (fbc, fbp)
Meta — About Event Match Quality (Business Help)
WebKit — Intelligent Tracking Prevention & the 7-day cap