fbclid is the Facebook click ID: a parameter Meta adds to your landing page URL when someone clicks a Facebook or Instagram ad. The Meta Pixel saves it in a first-party _fbc cookie, and the Conversions API sends it back to Meta as fbc so a later purchase can be tied to that click.
This guide covers where fbclid comes from, the exact _fbc and _fbp formats Meta documents, what breaks the click ID before the order, and how to keep it for your server events. It builds on our guide to the Meta Conversions API and first-party data.
What is fbclid?
fbclid is Meta's click ID. Meta's developer documentation describes the ClickID as a Meta-generated parameter passed with the URL of an advertiser's website when a user clicks an ad on Facebook or Instagram. A landing URL from an ad looks like this:
https://yourstore.com/products/linen-shirt?utm_source=facebook&fbclid=IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk
It's an opaque string that identifies the click, not the campaign, and it's case sensitive, so Meta's guide says not to modify it in any way. Meta also says ClickID auto-attachment does not impact other custom tracking parameters you have enabled, so UTMs and fbclid arrive together.
Where does fbclid appear?
In landing page URLs, server and CDN logs, analytics reports that show full URLs, and the _fbc cookie once the Pixel has read it. It also travels with links shoppers copy and share, so it can occasionally arrive from someone who never clicked the ad.
What is the _fbc cookie and what format does it use?
_fbc is a first-party cookie on your domain that holds the click ID. Meta's guide says the Pixel stores the ClickID there automatically once it's available, and you send the same value to the Conversions API as fbc. The documented format is:
fb.subdomainIndex.creationTime.fbclid
Meta's example: fb.1.1554763741205.IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk
| Part | What it holds |
|---|---|
fb | Version prefix. Always fb. |
subdomainIndex | The domain level the cookie was set on: com = 0, example.com = 1, www.example.com = 2. When you build the value on a server, Meta says to use 1. |
creationTime | Unix time in milliseconds when _fbc was stored. With no cookie, use the time you first observed that fbclid. |
fbclid | The fbclid value from the landing URL, unchanged. |
Values built with Meta's Parameter Builder Library end with an extra appendix. That's expected; the same documentation says not to override or adjust the _fbc cookie.
What is the _fbp cookie?
_fbp is Meta's browser ID, which the Pixel saves when it uses first-party cookies and none exists. The format is fb.subdomainIndex.creationTime.randomnumber, for example fb.1.1596403881668.1116446470, where the Pixel generates the random number so every _fbp is unique. _fbp identifies a browser on any visit, while _fbc only exists after a visit arrives with an fbclid.
What does the click ID tell Meta?
In the Shopify accounts we audit, the click ID is the single most valuable matching signal an event can carry, because it tells Meta who clicked, which ad they clicked and when. Email is the next strongest identifier, then phone. Meta's own guide puts it more cautiously: "Sharing ClickID can help you attribute more conversions and reach more people."
An email tells Meta who bought, not which ad they saw. Without fbc, Meta relies on the other identifiers in the event, and if those are thin the event may not match anyone. Meta's Conversions API best practices state that unmatched events can't be used for attribution or ad delivery optimization. Our pillar lists what data the Conversions API sends to Meta, and our Event Match Quality reference guide shows how each identifier feeds your match score.
What breaks the Facebook click ID?
The click ID is created in one place (the landing URL) and needed in another (the purchase event, sometimes days later). Anything that separates the two loses it.
Moving from the in-app browser to Safari or another device
Tap an ad in Instagram or Facebook and your store opens inside the app's own browser. Apple's developer documentation notes that on iOS each app has its own data container with a separate cookie store, so the _fbc cookie set in the in-app browser isn't there when the same person opens your store in Safari.
In our experience, most shoppers who tap an Instagram ad don't buy inside the in-app browser. They come back later in Safari, on a laptop, or through search or email, and the original click ID is lost unless it was preserved. More on this in why the Meta Pixel misses conversions.
Safari's limits on script-set cookies
The Pixel writes _fbc with JavaScript. Since ITP 2.1, Safari caps persistent cookies created through document.cookie at a seven-day expiry. ITP 2.2 cuts that to one day on the landing page when a domain classified with cross-site tracking capabilities sends the visitor there and the URL has a query string or fragment. A Safari shopper who returns after the cap has run out arrives with no _fbc.
Redirects and link shorteners
fbclid only reaches your site if every hop between the ad and the landing page keeps the query string. Link shorteners, geo or language redirects, 301s from old product URLs and landing page tools that rebuild the URL can each drop it. To test, add a harmless parameter such as ?qs_test=1 to each ad destination URL and check that it survives to the final page.
Apple's Link Tracking Protection
With iOS 17, Apple announced that tracking information in URLs would be removed from links shared in Messages and Mail, and from links in Safari Private Browsing. WebKit's Private Browsing 2.0 post adds that Safari removes a subset of query parameters used for cross-site tracking before navigation, keeps campaign attribution parameters, and gives third-party scripts the URL without its query string after a cross-site navigation. Users can extend these protections to regular browsing with Safari's advanced tracking and fingerprinting setting.
Apple doesn't publish its parameter list, so we can't confirm from Apple's documentation that fbclid is on it. Plan for a click ID to be stripped in those contexts, or hidden from the Pixel as a third-party script; when the parameter does survive, your own server still sees it in the request. For the wider picture, see our guide to iOS privacy changes for ecommerce.
fbclid vs UTM parameters: what's the difference?
UTMs are labels you add yourself. Google's URL builder documentation says to always use utm_source, utm_medium and utm_campaign, and analytics tools read them to group traffic. fbclid is added by Meta and read by Meta.
| fbclid | UTM parameters | |
|---|---|---|
| Who adds it | Meta, on ad clicks | You, in the ad's URL parameters |
| What it identifies | A specific ad click | A source, medium or campaign you named |
| Who reads it | Meta, through _fbc and fbc | Analytics tools and your reports |
| Used by Meta to match events to people | Yes | No |
You want both: UTMs tell your reporting which campaign a session came from, and fbclid lets Meta tie a conversion to the click.
Should you strip fbclid from your URLs?
Not before you've captured it. There are fair reasons to clean it up:
- Caching. The value is specific to each click, so a cache keyed on the full URL can treat ad traffic as a stream of different pages.
- Analytics. Reports that include the query string split one landing page into many rows.
- SEO. Google's guide to duplicate URLs uses a
?gclid=click ID URL as its example of a non-preferred version and recommends arel="canonical"tag, which covers shared fbclid URLs without stripping anything.
The order matters. If a redirect or edge rule removes fbclid before the page loads, nothing ever sees it. If your CDN ignores fbclid in its cache key, cached responses never reach your server, so a first-party script has to send fbclid to your backend. Clean the address bar (for example with history.replaceState) only after the Pixel and your own capture have read it.
How do you preserve the Facebook click ID?
- Capture fbclid on landing, server-side. Meta's guide says to try to obtain fbclid server-side whenever it's in the URL, and its Parameter Builder documentation says to save
_fbcas early as possible. - Format it once. Build
fb.1.<first-seen time in ms>.<fbclid>and keep the fbclid exactly as received. - Set
_fbcfrom your own server. Meta recommends an HTTP cookie in the response headers with a 90-day expiration, set only when no_fbcexists or the URL's fbclid differs from the stored one. WebKit's tracking prevention documentation caps HTTP-response cookies at seven days when it detects third-party CNAME or IP address cloaking, so a vendor endpoint behind a CNAME may not get the full lifetime. - Store it with the session and the customer. Meta offers backend storage as an alternative to the cookie, as long as it holds the most recent value. Once the shopper identifies themselves (signup, login, checkout), attach it to the customer record, so someone who gave an email in the in-app browser and later buys in Safari with that email still carries the click.
- Send
fbcwith every Conversions API event. Meta's guide says: "We recommend sending the fbc parameter with every event you send to the Conversions API." Send it unhashed, and replace it when a newer click arrives. - Never fabricate a click ID. Only send
fbcfor a person who arrived with an fbclid. Don't generate placeholders, copy one shopper's click ID onto another, or reformat other platforms' click IDs. A made-up value gives Meta a false link between an ad and a sale.
Our server-side tracking guide covers the infrastructure. Upstack Signal does this for Shopify brands: it captures click IDs on landing, ties them to hashed email, phone and a stable external ID, and restores them on later server events.
How do you check your click ID coverage?
Click ID coverage is the share of your events that carry fbc. Our rule of thumb: it should roughly match the share of your traffic that comes from Meta ads.
- From the last 30 days of server events you send to Meta, calculate the share of Purchase events that include
fbc. Repeat for PageView or ViewContent. - From your analytics, find the share of sessions that came from Meta ads, using UTMs or fbclid on the landing URL.
- Compare the two.
| What you see | What it usually means |
|---|---|
| Purchase coverage close to Meta's share of traffic | Click IDs are surviving the journey |
Meta drives most traffic, but only a small fraction of purchases carry fbc | Clicks are being lost between the ad and the order |
Landing events carry fbc, purchases mostly don't | The ID is captured but not carried into later sessions or devices |
| Coverage well above Meta's share of traffic | Check that fbc isn't attached to visitors who never arrived with an fbclid |
| Low coverage, mostly organic or affiliate traffic | Expected: fewer Meta clicks to carry |
Also spot-check the format: values should start with fb., use a millisecond creation time, and end with the exact fbclid from the landing URL. For the rest of a tracking check (which pixels load, which events fire and what Events Manager receives from your server), see our Meta Pixel Helper guide.
Frequently asked questions
Is it safe to remove fbclid from a URL?
For a link you're sharing, yes: the page loads the same without it. On your own store, remove it only after your server or a first-party script has stored it, because once it's gone that click can't be recovered.
How long does the _fbc cookie last?
Meta recommends setting _fbc from your server as an HTTP cookie with a 90-day expiration. When the Pixel writes it with JavaScript instead, Safari caps script-set cookies at seven days, and at one day on the landing page in some cases, so a copy stored on your server lasts longer.
Should I hash fbc before sending it to the Conversions API?
No. Meta's customer information parameters reference marks both fbc and fbp as "Do not hash." Send them exactly as stored, and never change the case of the click ID.
Does Safari remove fbclid?
Apple says Link Tracking Protection removes tracking information from links shared in Messages and Mail and from links in Safari Private Browsing, but it doesn't publish which parameters it removes. Plan as if a click ID can be lost there, and capture it server-side whenever it arrives.
Key takeaways
- fbclid is Meta's click ID, added to your landing URL when someone clicks a Facebook or Instagram ad.
- The Pixel stores it in
_fbcasfb.subdomainIndex.creationTime.fbclid; send it to the Conversions API asfbc, unhashed and unmodified. - In-app browsers, Safari's cookie caps, redirects and Link Tracking Protection all separate the click from the purchase.
- Capture fbclid server-side, store it with the session and customer, and send
fbcwith every event. Never invent one. - Click ID coverage should roughly match Meta's share of your traffic.
Request a demo and we'll check your click ID coverage.