_fbp and _fbc cookies explained: the browser half of Event Match Quality

When Meta receives a conversion event, it has to answer one question: which person was this? Hashed email and phone are the durable half of that answer. The other half is two first-party cookies — _fbp and _fbc — and they punch far above their weight in Event Match Quality. They are also the most fragile identifiers you send.

What is the _fbp cookie?

_fbp is a browser identifier the Meta Pixel sets as a first-party cookie the first time it loads on your domain. It looks like fb.1.1725000000000.1234567890 — a version, a domain depth, a timestamp, and a random number.

It identifies a browser, not a person. But Meta has seen that browser across every site running a Pixel, so _fbp lets Meta connect your conversion to a rich behavioral profile even when the visitor never typed an email. For anonymous upper-funnel events — ViewContent, AddToCart — it is often the only identifier you have.

What is the _fbc cookie?

_fbc stores the click ID. When someone clicks your Meta ad, the landing URL carries an fbclid parameter; the Pixel captures it into the _fbc cookie, formatted like fb.1.1725000000000.IwAR2xExampleClickId.

This is the strongest single signal for attribution: it ties the conversion directly to a specific ad click. An event carrying a valid _fbc is about as unambiguous as matching gets — Meta knows exactly which click, which ad, which person. That is why _fbc coverage moves EMQ more than almost anything else on paid traffic.

How do they raise match rates?

Hashed email matches a person who is in Meta's graph under that address; _fbp and _fbc match the browser session and the ad click itself. Together they cover each other's blind spots: email works when cookies are gone, cookies work when the buyer used a different email or none at all. Events that carry email, phone, _fbp, and _fbc give Meta multiple keys to the same person, and match confidence rises with each one.

Why are they fragile?

Because everything in the modern browser is working against them:

• ITP caps their lifetime. Safari's Intelligent Tracking Prevention limits script-set first-party cookies to 7 days — and 24 hours when the landing URL carries link decoration like fbclid. A Safari visitor who buys a week after clicking has no _fbc left, and often no stable _fbp.
• Blockers stop them from existing. Ad blockers and privacy tools that block the Pixel script mean the cookies are never set at all.
• Cross-domain checkout drops them. Cookies are scoped to a domain. If checkout happens on a different domain than the landing page — or in a sandboxed context that partitions storage, as on modern Shopify checkouts — the purchase event fires without the cookies the storefront set. The purchase still arrives; it just arrives anonymous.

The pattern to internalize: _fbp and _fbc are excellent while they exist and prone to not existing exactly when the conversion happens.

How do server events handle this?

Server-side Conversions API events can include fbp and fbc as fields whenever the values are available — and when they are not, the event still matches through hashed email and phone. That is the resilience argument for server-side in one sentence: the browser identifiers are opportunistic, the hashed identifiers are dependable, and a good sender ships both.

json{
  "event_name": "Purchase",
  "event_id": "order_84712",
  "user_data": {
    "em": ["<sha256 of normalized email>"],
    "ph": ["<sha256 of normalized phone>"],
    "fbp": "fb.1.1725000000000.1234567890",
    "fbc": "fb.1.1725000000000.IwAR2xExampleClickId"
  }
}

An event like this survives every failure mode above. Cookies present: maximum match confidence. Cookies gone: email and phone still land the match.

Practical advice

Capture fbclid server-side on landing. Do not rely on the Pixel's cookie alone — read the fbclid query parameter when the visitor arrives, store it in your own session or database keyed to the visitor, and construct the _fbc value yourself (fb.1.<timestamp>.<fbclid>) at conversion time. Your server-side copy is immune to ITP's 24-hour cap.

Pass it through checkout. Whatever crosses the domain or sandbox boundary — a cart attribute, a session record, an order note — carry the click ID and the _fbp value with the order so the server event can include them. On Shopify's sandboxed checkout this continuity is exactly what breaks by default; it is cause number seven in our missing-Purchases checklist.

And always send hashed email and phone alongside. They are the floor that holds when the cookie half falls through.

This is the tedious plumbing Caply exists to own: the https://trycaply.com/v1.js snippet captures fbclid, _fbp, and _fbc when they exist, and our managed servers send each Purchase and Lead to CAPI with those identifiers plus SHA-256-hashed email and phone, deduplicated by event_id against your browser Pixel. The per-event Match Forecast score shows how recognizable each buyer was — so you see, per event, whether the cookie half made it through. Details on pricing; 14-day trial.