FBC FBP Construction: Building _fbc and _fbp by Hand

In server-side funnels, fbc fbp construction is the buyer's substitute for a browser: a pixel on your own site would collect Meta's _fbc and _fbp cookies automatically, but a server-side funnel never sees a browser at the conversion moment - so the values must be constructed from what the click captured. The format is documented and simple; the mistakes are quiet. A malformed fbc does not fail the request - it simply matches worse, and the optimization quietly absorbs the loss. This guide covers the cookie formats, the fbc-from-fbclid construction, the hashing rules, and the format mistakes that break matching.

Why server events need these values at all - matching quality and its scoring - is in the complete Meta CAPI guide; this page is the construction manual.

What the Two Cookies Look Like

Meta's cookies are underscore-prefixed in the browser and travel - without the underscores - inside the user_data of a Conversions API call:

For affiliate funnels the distinction matters: fbc is about the click - reconstructable from the ad URL - while fbp is about the browser on a specific domain - and when the conversion domain is outside your control, it never arrives. Meta documents that server events carry these as fbp and fbc in user_data, and that _fbc can be constructed from the fbclid URL parameter (fbp and fbc parameters). Each value pairs with the click through its click ID, which is why capture timing dominates the construction.

Constructing fbc From fbclid

Per the documented format, the construction recipe runs:

1. Capture the raw fbclid parameter from the ad's destination URL at click time, before any redirect can trim it (where click IDs get lost).
2. Record the moment of the click as a timestamp.
3. Then join the parts in the versioned shape: fb.1.<timestamp>.<fbclid>.

ad URL:      your-tracker.example/landing?fbclid=IwAR0abc123
stored fbc:  fb.1.1790000000000.IwAR0abc123

Keeping the constructed value usable takes two rules. First, the timestamp precision and the fbclid must be exactly what the click carried - trimming, URL-decoding, or re-encoding the fbclid produces a value Meta cannot pair with the click. Second, construct once at click time and store the result with the click row; rebuilding it later from memory invites drift.

What Travels Hashed - and What Does Not

The hashing rules are explicit and asymmetrical:

Meta documents the never-hash list explicitly, and it includes exactly the fields this guide constructs (fbp and fbc parameters). The single most classic mistake is applying a hash-everything helper to the whole user_data object - which destroys the very values the construction just built.

The Mistakes That Break Matching

1. Underscores in the payload. The browser cookies are _fbc/_fbp; the user_data fields are fbc/fbp. Sending the underscore names in the JSON is the most common format error.
2. Mangled fbclid. URL-decoding or truncating the captured parameter - fbclid values can contain characters that survive only verbatim.
3. Hashed identity fields. fbc and fbp hashed "for consistency" stop matching entirely; the hash rules are per-field, not per-object.
4. Timestamp drift. Constructing fbc with a different timestamp than the click's own - the value pairs with the click, not with the send moment.

All four are caught by the verification loop: send one constructed event through Meta's Test Events, then check the match-quality signals in Events Manager (get started). The per-field rules sit inside the wider matching picture of the Meta CAPI guide, and the click-side losses behind a missing fbclid are in the prelander loss map.

Building _fbc and _fbp: Frequently Asked Questions

Sources