How FBCLID works
When someone taps one of your Meta ads, the platform appends a parameter called fbclid to the destination address before sending them onward. The value is a unique string standing for that specific click. It is not a user ID and it carries no personal information — it is a receipt number for one click on one ad.
On arrival, the Meta Pixel reads the parameter and copies it into a cookie under your own domain so the value survives after the visitor moves to another page and the parameter disappears from the address bar. Later, when a purchase or an enquiry is reported, that stored value tells Meta which click to credit. Without it, the conversion has to be matched by weaker signals, or not at all.
Why FBCLID matters
It is the most reliable link between money spent and money earned that Meta advertising has. Browsers have made cross-site tracking unreliable, so a parameter travelling in the URL — carried by the visitor, not by a third-party cookie — has become the sturdiest way to connect an ad to an outcome.
It matters more, not less, when you send conversions from your server. A server-side event built from the order record knows the customer’s email but nothing about the advertising, so the stored click identifier is what turns an anonymous sale into an attributed one. Where it is absent, campaigns optimise on incomplete data and steadily learn the wrong lesson about which audiences and creatives work.
Where FBCLID goes wrong
The main problem is that it gets stripped. Link shorteners, aggressive redirect plugins, security appliances and some CDN configurations drop unknown query parameters, and the parameter vanishes before any script on your site can read it. The ad still delivers the visit; the attribution is simply gone.
The second problem is caching. Because every click carries a different value, some caching layers treat each one as a separate page and serve uncached responses, which makes ad traffic slower than organic traffic to the same page. That is a genuine speed problem worth checking rather than ignoring.
The third is search engines indexing URLs that include the parameter, creating duplicate addresses for a single page. Your canonical tag should always point to the clean URL, without any click or campaign parameters attached.
What to do about it
Click your own ad on a phone and look at the address bar as the page loads. If the parameter is there on arrival but not after the first internal click, that is expected. If it never appears at all, work backwards through every redirect between the ad and the landing page until you find what removed it.
Ask your host or developer to treat the parameter as ignorable for caching purposes so ad visitors get the same fast page as everyone else, and confirm your canonical tags point to parameter-free URLs. Then check that your server-side integration is reading the stored value rather than building events purely from order data — that single omission undoes most of the benefit of a Conversions API setup. If you use UTM tags as well, keep them: they and the click identifier answer different questions, as UTM parameters feed your own analytics rather than Meta’s.