Click IDs: what gclid, fbclid, and wbraid do

That ?fbclid=IwAR... string cluttering your address bar is not junk. It's the one thing tying an ad click to the sale it caused weeks later, and a "clean URL" plugin can strip it without erroring anywhere. A click ID is a unique code an ad platform appends to your landing URL at click time (?gclid=..., ?fbclid=...) so a conversion that happens minutes or months later can be matched back to that exact click.

Two consequences follow, and they organize this page: click IDs are the match key of paid-media measurement, and losing one breaks conversion matching silently, with no error to warn you. Below is the whole family (gclid, fbclid, wbraid, msclkid, ttclid, li_fat_id), sorted by what each one actually lets you do, and every point in transit where it gets destroyed. The advice you'll usually find stops at "it's a tracking parameter Facebook adds," which is true and useless.

#The click-ID roster

Every major platform issues one. Same mechanism, different capabilities:

#gclid: Google Ads

Appended by auto-tagging to every Google Ads click. The most capable ID in the family: GA4 resolves it to campaign, ad group, keyword, and creative, and it's the upload key for offline conversion imports. Store it on the CRM lead, upload it when the deal closes, and the revenue credits the click (Offline conversion tracking: send CRM deals back to Google Ads is the full pipeline). One GCLID matches exactly one click: deterministic, no modeling.

#fbclid: Meta

Appended to outbound clicks from Facebook and Instagram since 2018. The Meta pixel captures it into the _fbc first-party cookie (fb.1.<timestamp>.<fbclid>), and Conversions API events that carry fbc match back to the click server-side. That captured fbc is one of the strongest inputs to Meta's event match quality score. No fbclid captured means Meta falls back to weaker identifiers (hashed email, IP + user agent) or fails to match at all.

#wbraid / gbraid: Google on iOS

Privacy-conscious stand-ins for the gclid on iOS traffic after App Tracking Transparency: wbraid on clicks bound for the web, gbraid on clicks bound for apps. They aggregate rather than identify a single user, which is the point. But your capture plumbing must persist them like the gclid, because web conversion measurement on iOS rides on them.

#msclkid: Microsoft Advertising

Bing's click ID, appended by Microsoft's auto-tagging. Functionally the gclid's twin: campaign resolution plus offline conversion imports for CRM-closed deals. If you run Microsoft Ads and import offline conversions to Google only, this is the parameter you're leaving unused.

#ttclid: TikTok

TikTok's click ID, passed back via TikTok's Events API to raise match rates, same pattern as fbclid + CAPI.

#li_fat_id: LinkedIn

LinkedIn's first-party ad tracking ID, used by the Insight Tag and conversion APIs for click-to-conversion matching where third-party cookies can't. Track-A stacks doing LinkedIn conversion tracking for B2B pipelines should persist it alongside the gclid in the same hidden-field pattern.

#What a click ID buys you

Three capabilities, in ascending order of value:

• Click-to-conversion matching. The platform ties a conversion event to the exact click, not a modeled guess, which is what keeps its reported numbers and its bidding signal honest.
• Offline and delayed conversions. The ID outlives the session. A deal that closes in the CRM 40 days after the click still credits the campaign, because the ID was stored and uploaded (Offline conversion tracking: send CRM deals back to Google Ads).
• Event match quality. Server-side events carrying the click ID match at the highest confidence tier. If you run pixel + CAPI, the captured fbclid/_fbc is doing more for your match rate than any other single field (Conversions API vs the Meta Pixel: what actually changes).

#Where click IDs get lost

Every loss point produces the same silent symptom: conversions stop matching, platforms under-report, and nothing errors. This list feeds the discrepancy triage in Why your GA4 and Google Ads conversions don't match:

• Redirects and URL rewrites. Canonicalization hops (http→https, www), vanity-domain redirects, and load balancers that rebuild URLs can drop the query string, and the ID with it.
• "Clean URL" plugins and privacy middleware. Tools that strip tracking parameters treat click IDs as clutter. On your own infrastructure this is self-inflicted measurement damage.
• Consent stripping. Consent platforms configured to block storage before opt-in also block the cookie write that persists the ID; the click lands, the ID evaporates on the next pageview.
• Cross-domain hops. The ID arrives on yoursite.com, but checkout lives on pay.example.com. The ID and the session both die at the border unless they're carried across (Cross-domain tracking: the checkout-domain trap).
• Truncation and case-mangling. CRM fields that cap length or middleware that lowercases produce IDs that look present but never match.

#Should you strip fbclid?

From URLs you publish, yes. From URLs you measure, never. Stripping click IDs when sharing links or setting canonicals is good hygiene: the ID identifies one click, so a shared URL carrying it is stale metadata. But blocking the parameter from arriving, or cleaning it before your pixel and analytics capture it, has a real price: lower Meta event match quality, no offline-import match for Google, and a bigger unattributed bucket. The honest rule is capture first, then clean. Configure analytics to exclude click IDs from URL-based dedup and reporting so they don't fragment your page data. GA4 does this for its own IDs; your reporting tools need telling.

#Click IDs vs UTMs

A click ID is a deterministic match key the platform writes; a UTM is a self-reported label you write. The platform can resolve its own ID to the exact click with everything it knows about it; your UTMs say whatever you typed, including typos. You need both: UTMs for the cross-platform taxonomy you control (UTM parameters: the reference is the reference, utm naming conventions the system), click IDs for the per-click matches no label can do. Neither replaces the other. Auto-tagging plus disciplined UTMs is the standard setup.

#What we do with them: the identity-map walkthrough

Captured click IDs are how anonymous clicks become attributable customers. Buron's first-party pixel reads gclid, fbclid, wbraid, msclkid, and ttclid from the landing URL and stores them first-party, tied to the visitor. In the warehouse, the identity map matches those fragments: the click ID connects the ad click to the session, the session to the form fill's hashed email, the email to the CRM deal, so a closed deal resolves to the campaign that started it, in your own warehouse rather than a platform's black box. How that stitching pass works, including key precedence, conflicts, and failure modes, is Identity resolution: how user stitching actually works's territory.

#Capture is where measurement is won or lost

Every reporting problem downstream of this is really a capture problem. If the click ID never survived to your pixel and your CRM, no dashboard, model, or attribution setting can recover the match it needed. The number you never see is the one that's wrong, which is what makes click IDs the quietest failure in the stack.

So treat them as infrastructure. Inventory which IDs your stack captures today, click your own ads and confirm each one survives to the CRM and the pixel, and treat every redirect, consent change, or "URL cleaner" as a capture regression until you've retested it. Buron's first-party pixel captures the whole family (gclid, fbclid, wbraid, msclkid, ttclid) and its audits watch that capture coverage continuously, because a stripped parameter never announces itself. It just quietly unmatches your revenue until someone thinks to look. [Check your click-ID capture →]

Frequently asked questions

What is fbclid?

fbclid (Facebook click identifier) is a unique per-click parameter Meta appends to every outbound link clicked on Facebook or Instagram. Captured into the _fbc cookie, it lets Meta match later conversion events back to the specific click, raising event match quality for pixel and Conversions API events.

Should I remove fbclid from URLs?

Strip it from URLs you share or canonicalize, but never block it from arriving or prevent its capture. The fbclid is the match key Meta uses to tie conversions to clicks; URL-cleaner plugins and redirects that discard it lower your event match quality and cost you attributed conversions.

What is a gclid used for?

The gclid (Google click ID) is appended by Google Ads auto-tagging to every ad click. GA4 resolves it to the exact campaign, ad group, and keyword, and it is the key for offline conversion imports: store the gclid on a CRM lead and upload it when the deal closes to credit the original click.