FBCLID, short for Facebook Click Identifier, is a code Meta adds to the end of a link when someone clicks it on Facebook, and on many links from Instagram, so that a later action on your website can be connected back to that click. It shows in the address bar as ?fbclid= followed by a long string of letters and numbers.
How fbclid works
Meta appends the parameter to links that leave its apps, whether the click came from an ad or an ordinary post. When the visitor lands on a page running the Meta Pixel, the Pixel reads the fbclid from the address and stores it, with a timestamp, in a first-party cookie called _fbc. Later events on the site, such as a lead or a purchase, carry that value back to Meta, which uses it to match the conversion to the click.
The same value can be sent from your server through the Conversions API as the fbc parameter. It is one of the stronger signals for matching server events to the people who clicked, so including it usually improves your Event Match Quality.
Google Analytics does not use fbclid to classify traffic. Visits from Facebook ads without tracking tags show in GA4 as organic social referrals from facebook.com or one of Meta’s link domains, unless you add UTM parameters to the ad’s URL. Google Ads has its own equivalent, the GCLID, and Microsoft Advertising uses the MSCLKID.
Why it matters
For a UK business advertising on Facebook and Instagram, the click identifier is part of what lets Meta report conversions and optimise campaigns towards them. Since browsers began restricting third-party cookies and Apple introduced App Tracking Transparency, Meta has leant more heavily on first-party signals such as _fbc. If the fbclid is lost before the Pixel reads it, conversions from that visit are harder to attribute, and campaigns have less to learn from.
Consent plays its part. On a UK site, the Pixel should run, and so set _fbc, only after the visitor accepts marketing cookies, as PECR requires. A visitor who declines leaves no stored click identifier. That is one reason Meta reports fewer conversions on sites with a proper consent banner, and it is the cost of following the law, not a fault to engineer around.
Common mistakes
- Stripping it too early. Some caching plugins, CDNs and redirect rules remove unfamiliar query parameters or redirect to a “clean” address before the page loads. If the Pixel never sees the fbclid, it cannot store it.
- Losing it in a redirect. An ad pointing at an http:// address, or at a URL missing its trailing slash, may pass through a redirect that drops the query string.
- Treating fbclid addresses as separate pages. Tools that report full URLs show every click as a different page. In GA4, use Page path, which leaves out the query string.
- Worrying about duplicate content. A self-referencing canonical tag on each page tells Google which address is the real one; there is no need to block fbclid in robots.txt.
- Relying on it instead of UTMs. fbclid helps Meta; it tells GA4 nothing about which campaign a visit came from.
- Passing it without consent. Capturing fbclid on the server and sending it to Meta for a visitor who refused marketing cookies overrides the choice they made.
How to act on it
- Click one of your own Facebook ads or post links and check the landing page address still contains fbclid once the page has loaded.
- With marketing cookies accepted, check in your browser’s developer tools that an _fbc cookie has been set.
- If you use the Conversions API, confirm in Events Manager that server events include the fbc parameter, and only for consenting visitors.
- Add UTM parameters to every ad URL so GA4 can credit the right campaign.
- Confirm your caching and redirect rules leave query strings intact on landing pages.
Click identifiers, cookies and server events are all checked when I set up tracking for Facebook and Instagram ads management, because Meta’s reporting and optimisation depend on them.