Sales that lose their click: a stale or altered fbc in the Conversions API

When someone clicks a Meta ad, the landing URL arrives with an fbclid parameter, the identifier of that click. The Pixel stores it in a first-party cookie, _fbc, and the Conversions API sends it in the fbc field of user_data. It’s the piece that ties a conversion to the click behind it. That’s why sending it isn’t enough: it has to be the current value, exactly as it was received.

What a stale or altered fbc looks like

The same user clicks ad A on October 2 and ad B on October 19. The _fbc cookie already holds the ad B click. But the Purchase event the server sends carries:

• the fbc from the October 2 click, stored in the customer profile the first time it was seen; or
• the current fbc, but lowercased: fb.1.1792368000000.pazxh0bgn… instead of fb.1.1792368000000.PAZXh0bgN….

In the first case, the conversion travels with a click that isn’t the latest one. In the second, with an fbclid that matches no click. The API returns no error: the problem only shows up in attribution and match quality.

Why the fbc arrives stale or altered

The fbc format is fb.<subdomain index>.<creation time in milliseconds>.<fbclid>. Two rules from Meta’s documentation explain almost everything: the value changes over multiple browser sessions, so you should always send the most recent one, and the fbclid is case-sensitive, so it must not be modified. The usual causes:

• The fbc is stored once and reused. The backend links it to the customer on their first visit, or stores it in the CRM, and sends it with every later event, even after new clicks.
• It’s normalized as if it were contact information. The same code that lowercases the email before hashing also runs on fbc, or a toLowerCase() runs on the whole URL before reading fbclid.
• It’s hashed. fbc is one of the fields that go unhashed.
• It’s only read on the confirmation page. If the fbclid arrived on the first page and nobody saved it in the cookie, it’s gone by the Purchase. Meta recommends capturing cookies early, not only on down-funnel events.

How to find a stale or altered fbc

1. Click an ad (or open the site with ?fbclid= and a test value). In the developer tools, Application → Cookies tab, copy the _fbc value.
2. Complete a conversion and find the fbc the server sends, in its logs or in the server-side GTM preview. It must be identical, character by character.
3. Repeat with a second click: the cookie changes; check that the fbc sent changes too.
4. Find where the server code reads fbc: if it comes from the customer database instead of the request’s cookie, or goes through a normalization step, that’s the cause.

How to send the right fbc

• Read the _fbc cookie from the request on every event and send it in fbc as is, with no case changes and no hashing. Meta recommends sending fbc with every event.
• If there’s no cookie (for example, because there’s no Pixel on the site) but the request URL has an fbclid, build the value: fb.1.<time in milliseconds when you saw the fbclid>.<untouched fbclid>.
• If you store the value on the server, update it every time a new fbclid arrives and always send the most recent one. Meta also suggests setting the _fbc cookie yourself, with a 90-day expiry, when it doesn’t exist or when the fbclid received differs from the one it holds.
• Meta’s Parameter Builder library handles reading and formatting fbc and fbp in the browser and in several server languages. If you use it, the values carry a suffix added by the library: don’t strip it.

Meta’s documentation: fbp and fbc parameters.

How to check the fbc is the latest click

• In a test conversion, the fbc sent is identical to that visit’s _fbc cookie, case included.
• After a second click with another fbclid, the next event carries the new value.
• In a sample of events, every fbc starts with fb., keeps the fbclid’s upper case letters and none looks like a hash.

The dates, timestamps and fbclid values in the example are illustrative and shortened.