How to Capture _fbp and _fbc Cookies for Meta Attribution

You can send Meta a perfectly-formed conversion event and still watch your Event Match Quality sit at "Poor." Usually the culprit isn't the event — it's what's missing from it. Two of the most valuable match signals Meta accepts don't come from a form field at all. They come from cookies: _fbp and _fbc.

They matter most for exactly the visitors that are hardest to track — the anonymous top-of-funnel traffic that clicks an ad, lands on your page, and hasn't given you an email yet. Capture these two cookies and you can tie that person's eventual conversion back to the ad click you paid for. Miss them, and Meta is guessing.

Here's what each cookie actually is, how it gets created, how to capture it without dropping it on the floor, and the mistakes that quietly cost you match quality.

What _fbp and _fbc actually are

Both are first-party cookies — set on your domain, readable by JavaScript running on your domain. Neither contains personal data; they're opaque identifiers Meta uses for matching.

_fbp — the Facebook browser ID. The Meta Pixel base code sets this on a visitor's first page load and reuses it on every subsequent visit. It identifies the browser, and it exists for essentially everyone once the pixel has run — ad traffic or not. Its value looks like this:

fb.1.1720598400000.1834267592

That's four dot-separated parts: the fb prefix, a subdomain index (almost always 1), the creation timestamp in milliseconds, and a random number.

_fbc — the Facebook click ID. This one is the prize. When someone clicks your Meta ad, Meta appends an fbclid parameter to your landing URL:

https://yoursite.com/offer?fbclid=IwAR2xY...

The pixel reads that fbclid and stores it as the _fbc cookie, in the same format:

fb.1.1720598400000.IwAR2xY...

The difference is what's in the last segment: _fbp ends in a random number, _fbc ends in the actual click ID. That click ID is what lets Meta connect a conversion to a specific ad, adset, and campaign — which is why _fbc is the higher-value of the two.

Why they move the needle

Meta scores every event you send on Event Match Quality — how confidently it can tie the event to a real person. More strong parameters, higher score, better attribution and optimization.

Email and phone are great when you have them. But a huge share of ad traffic converts (or half-converts) before handing over any personal detail, and for those people _fbp and _fbc are often the only signals you've got. _fbc in particular carries the click ID, so it's the difference between "a conversion happened somewhere" and "this conversion came from that campaign." Sending both is one of the cheapest ways to lift match quality across your whole funnel.

The catch: the browser is where these cookies go to die

If capturing two first-party cookies sounds trivial, it usually is — right up until the browser deletes them. The same forces that break browser-side pixels are working against _fbp and _fbc:

• Safari's Intelligent Tracking Prevention caps JavaScript-set first-party cookies at a 7-day lifetime (sometimes 24 hours). A visitor who clicks your ad today and converts ten days later has no _fbc cookie left — even though the conversion is 100% attributable.
• Ad blockers and tracking prevention stop connect.facebook.net from loading, so the pixel never runs and neither cookie is ever set.
• Cookie consent, done right, holds the pixel back until the visitor opts in — so early in the session the cookies simply don't exist yet.
• Redirects, link shorteners, and cross-domain jumps strip the fbclid from your URL before the pixel can read it, so _fbc never forms in the first place.

The lesson: don't assume the cookies were captured cleanly at page load and will still be there later. Capture them at the moment of conversion, and have a fallback.

How to capture them reliably

Three moves cover the vast majority of cases.

1. Read the cookies when the visitor converts — not just on landing. On your domain, at submit time, read them straight from document.cookie:

function readCookie(name) {
  const match = document.cookie.match(
    new RegExp("(?:^|;\\s*)" + name + "=([^;]*)")
  );
  return match ? decodeURIComponent(match[1]) : undefined;
}

const fbp = readCookie("_fbp");
let fbc = readCookie("_fbc");

2. Rebuild _fbc from fbclid when the cookie is missing. This is the step most people skip, and it recovers a meaningful slice of click matches. If _fbc isn't set but the URL still carries fbclid, construct the value yourself in Meta's exact format — fb.1.<timestamp>.<fbclid>:

if (!fbc) {
  const fbclid = new URLSearchParams(location.search).get("fbclid");
  if (fbclid) fbc = `fb.1.${Date.now()}.${fbclid}`;
}

For this to work, the fbclid has to survive the trip through your funnel — so keep it in the URL and don't bounce visitors through a shortener that drops the query string.

3. Send them server-side, in plain text. Pass fbp and fbc in the user_data of your Conversions API event. Two rules people get wrong:

• Do not hash them. Email, phone, and name get SHA-256 hashed; fbp and fbc are already opaque and are sent as-is. Hashing them breaks the match.
• Share an event ID between the CAPI event and the browser pixel event so Meta deduplicates and counts the conversion once.

Sending them from your server instead of the browser sidesteps the ITP cookie-lifetime problem entirely: you read the cookie while it still exists and forward the value server-to-server, where no browser can expire it.

The mistakes that quietly cost you match quality

• Hashing _fbp / _fbc. The single most common error. They must be sent raw.
• Capturing only on the first page. SPA funnels and multi-step forms never reload, so a value grabbed at landing can be stale or gone by the time the conversion fires. Read it at submit.
• No fbclid fallback. If you only read the _fbc cookie and never reconstruct from the URL, every visitor whose cookie was blocked or expired loses their click match.
• Losing fbclid to redirects. A "click → shortener → redirect → landing page" chain often arrives with the parameter stripped, so _fbc can never form.
• Firing before consent. Reading cookies that shouldn't exist yet — or setting them before the visitor opts in — is both useless and a compliance risk.

How Collectform captures them for you

Wiring all of this by hand — reading the cookies at the right moment, reconstructing _fbc from fbclid, forwarding both unhashed, deduplicating against the pixel — is exactly the kind of plumbing that's easy to get subtly wrong. In Collectform it's built in:

• Automatic capture at submission. When a respondent submits, Collectform reads _fbp and _fbc from their browser and stores them on the response, so the values are captured while the cookies still exist — not left to expire.
• fbclid fallback. If the _fbc cookie isn't set but the visitor arrived with an fbclid, Collectform rebuilds the value in Meta's format automatically, recovering click matches the cookie missed.
• Forwarded correctly to CAPI. _fbp and _fbc are sent server-side in plain text alongside your SHA-256-hashed advanced matching fields, with a shared event ID so Meta deduplicates against the browser pixel.
• Visible per submission. The captured signals show up right in your submissions table and detail view, so you can confirm they're flowing instead of guessing from Events Manager.
• Consent-aware. Everything sits behind the same GDPR-ready one-click consent gate as the pixel and CAPI events — nothing marketing-related fires until the visitor opts in.

The takeaway

_fbp and _fbc are two of the highest-leverage match signals Meta accepts, and they're the ones you're most likely to be dropping — because the browser expires them, blockers kill them, and redirects strip the fbclid before _fbc can even form. Capture them at conversion time, rebuild _fbc from the URL when it's missing, and forward both to the Conversions API unhashed with a shared event ID.

Do that and you stop leaving attribution on the table for exactly the anonymous ad traffic that's hardest — and most expensive — to track.

Server-side CAPI with automatic _fbp / _fbc capture, fbclid fallback, deduplication, and consent is included on every paid Collectform plan. Explore templates or start building with Collectform.