First-party _fbc and _fbp: recovering the click the blocker erased

The two cookies that help Meta attribution most are created by a script a good share of your audience blocks. Both can be built on your side — one of them with a caveat you cannot ignore.

After email, the two fields that move Meta attribution most are cookies: _fbc, which stores the ad click, and _fbp, which identifies the browser. Both are created by Meta's script, which is exactly the file ad blockers drop first.

The good news is that both have documented formats and can be built first-party, by your own code. The bad news is that one of them must not be invented, and confusing the two cases manufactures false data.

The formats

_fbc = fb.1.<timestamp_ms>.<fbclid from the URL>
_fbp = fb.1.<timestamp_ms>.<random number>

  fb  -> fixed prefix
  1   -> subdomain version (domain root)

The difference is in the last part. _fbc carries a value that came from outside — the fbclid Meta put in the URL when the person clicked the ad. _fbp carries a random number, generated locally, whose only job is to stay stable in that browser.

fbp can be generated, and should be

Because the value is random by definition, there is nothing wrong with creating it yourself. And Meta's script respects an _fbp that already exists: if the cookie is there when it loads, it uses it instead of creating another.

That means the browser and the server-side send share one identifier — which is the entire point of the parameter. In one base we measured, _fbp coverage in sends sat at 44% precisely because it depended on the script; _fbc, already built from the URL, was at 93%.

_fbp is only useful if it is stable. Generating a new value on every page load gives you 100% coverage and zero value — every event becomes a different browser.

In practice: generate once, persist for ninety days, write it on the root domain so it works across subdomains, and never regenerate when the cookie already exists.

fbc must not be invented

Here is the line you do not cross. _fbc represents a real click on an ad, and the value inside it is the identifier Meta issued for that click. If no fbclid arrived in the URL, there was no traceable click — and fabricating a value does not create attribution, it creates noise.

What you can do, and it is worth a lot, is build it yourself when the fbclid is present: read the URL parameter, assemble the format above and persist it. That way the click survives even if Meta's script never loads.

• Arrived with fbclid: build _fbc from it and persist for ninety days.
• No fbclid now, but an _fbc from an earlier visit exists: use the existing one.
• There was never an fbclid: do not send fbc. Absence is the correct information.

The subdomain detail

Both cookies need to be written on the root domain, not the specific host. A cookie written on shop.example.com is not read on example.com, and the result is that the same person becomes two people when they change subdomain mid-funnel.

It is a mistake that never shows up in testing, because development almost always uses a single host.

What to expect from the gain

Do not expect the cookies to replace email. They do a different job: email says who the person is, _fbc says which ad they arrived through, and _fbp stitches their sessions to each other.

The concrete gain shows up on conversions where the email exists but the origin does not — which is most of them when the sale happens off-site. Without _fbc, that sale lands as a conversion with no associated click, and the campaign that brought it gets no credit at all.

In CrazyLeads, _fbc is built from the fbclid and _fbp is generated first-party in the exact format Meta's script expects, both persisted for ninety days on the root domain — and both travel in the server-side send, alongside the rest of the identity graph.