A click ID is an opaque token an ad platform mints the instant someone clicks its ad, appends to the destination URL, and reads back later at conversion - so it can match a sale or signup to the exact click that produced it. Google's version is gclid. Meta's is fbclid. TikTok's is ttclid. Microsoft Advertising's is msclkid. Run paid campaigns on more than one platform and you'll meet all four, usually while wondering why your URL got so long.
Each does the identical job for its own platform, and none is a label you write. A UTM tag is text you compose so your own analytics can group traffic by campaign. A click ID isn't that - it's a string the platform generates, and only that platform's own pixel or API knows how to use it. You need both. They answer different questions. That's the part most explainers skip.
What a Click ID Actually Is
Think of a click ID as a claim check, not a name tag. When someone clicks a Google ad, Google's server generates a unique string, ties it to the campaign, ad group, and keyword behind the click, and appends it to the URL as ?gclid=.... The string is unreadable to you or anyone else - it's a reference number into Google's own click log. Fbclid, ttclid, and msclkid follow the same pattern: a different mint, the same idea.
The point is closing the loop between "we showed an ad" and "this happened on your site." Without a click ID, a platform can only report campaign-level estimates. With one, it can say: this exact click, three days ago, led to this exact purchase - a level of precision UTMs alone don't give you. That's what powers offline conversion import, Smart Bidding, and CAPI-style server events. UTM parameters explained is the companion piece for the campaign-level tagging most teams run alongside click IDs.
The Four Click IDs You'll Meet
Every major ad platform has its own version, and the differences that matter are who reads it back and how long it stays usable.
| Platform | Parameter | Minted by, read back by | Typical validity window |
|---|---|---|---|
| Google Ads | gclid | Auto-tagging mints it; Google Ads conversion import and Smart Bidding read it back | 90 days from the click |
| Meta (Facebook, Instagram) | fbclid | Stored in the _fbc cookie; the Meta Pixel or Conversions API reads it back at conversion | ~90 days browser-side, longer if forwarded server-side |
| TikTok | ttclid | Auto-added since April 2024; the TikTok Pixel or Events API reads it back | 30 days from the click |
| Microsoft Advertising | msclkid | Auto-tagged onto the URL; the UET tag reads it back for conversion import | 90 days from the click |
Four platforms, four parameter names, one mechanism. Advertise on all of them and a single landing page can carry more than one click identifier at once - a stale gclid from last week's click sitting next to a fresh fbclid from today's retargeting ad.
How a Click ID Differs From a UTM Parameter
This is the confusion behind every "what is fbclid" search: it sits right next to utm_source in the query string and looks like a tracking parameter, yet does something completely different.
A UTM parameter is a label: you choose the value - utm_campaign=spring-sale - and your analytics tool buckets sessions by whatever string you typed. A click ID is a lookup key. You didn't choose gclid's value; Google did, and only Google's own systems can do anything with it. Drop a gclid into a generic analytics report and it just sits there - useful to Google Ads, useless to everyone else.
That asymmetry matters for troubleshooting. When UTMs stop showing up in reports, the fault is usually the browser or a broken link - Firefox and Brave breaking your UTM attribution covers that failure mode. When a click ID stops matching, the fault is almost always that it never reached the platform's own pixel or API in time, or its validity window closed before the conversion happened.
How a Click ID Round-Trip Actually Works
Strip away the platform-specific naming and every click ID follows the same three-stage journey.
Stage one, the mint. The moment a user clicks the ad, before the browser even requests your landing page, the platform generates the identifier and encodes it into the redirect URL.
Stage two, the ride. The identifier travels as a query parameter through whatever hops sit between the ad and your landing page - the platform's redirect, then your domain. Capture it here and write it into a cookie, a hidden form field, or your CRM record for later.
Stage three, the match. When the conversion happens - a purchase, a signup, a form submit - your pixel or server sends the stored click ID back to the platform's API with the event. The platform looks it up in its own click log and, if still inside the validity window, credits the original ad. That's the mechanic behind forwarding conversions to Meta's Conversions API: capture early, hold on, send back later.
Why the Parameter Showed Up Uninvited, and Whether You Can Strip It
Most people meet a click ID by accident. Auto-tagging is on by default in Google Ads and Microsoft Advertising, and TikTok made ttclid automatic in 2024 with no opt-in. Nobody asked for the parameter; the platform just started appending it, because that's how conversion tracking works now.
So yes, you can strip it - but timing decides whether that's harmless housekeeping or a self-inflicted attribution gap. Stripping fbclid from a link before you share it, or scrubbing it from a report's URL column, changes nothing about the conversion data your pixel already captured. Stripping it before your own script or redirect has read it is a different story: you've deleted the one thing the platform needed to credit the click, and no amount of UTM data recovers it. The safest habit is capturing the click ID server-side at the first hop - the approach in server-side conversion tracking - and cleaning the parameter only out of what you display or store downstream of that capture.
See how conversion tracking on Elido captures every click ID automatically → If you're wrangling gclid, fbclid, ttclid, and msclkid by hand across four ad accounts, that's the pain this solves - one redirect layer that logs the identifier before anything else touches the URL.
Where Click IDs Get Lost
A click ID is fragile in exactly the ways a UTM is fragile, plus one or two failure modes of its own.
Four situations account for most of the loss, and each one wants a different fix.
A visitor copy-pastes the landed URL into a group chat. Everyone who clicks that pasted link now carries someone else's click ID. The conversion either matches the wrong click or matches nothing. Store the identifier against the session that first arrived, and stop treating the URL in the address bar as the record.
The click opens inside an in-app browser. Instagram and TikTok hand the tap to a restricted webview that often cannot keep a first-party cookie past that session, so the identifier riding the URL has nowhere to live. Read the parameter server-side on the first request instead of relying on the browser to remember it.
A redirect rebuilds the destination URL and drops the query string. The click ID never reaches the landing page at all. It is gone before your pixel loads, so nothing downstream can save it. Confirm every redirect layer in the path forwards query parameters by default.
The browser strips the parameter before the page loads. Firefox's query parameter stripping names fbclid explicitly in Strict mode. Capture the identifier at the redirect, before the destination page and its scripts ever run.
The copy-paste case is really a dark social problem wearing a click-ID costume - the link travels through a private channel your analytics can't see, and dark social attribution covers that gap in full. For the Safari-specific cookie limits affecting fbclid and ttclid persistence, click attribution after Safari ITP is the dedicated read - I won't rehash it here.
Keeping Conversions Attributed: The Practical Checklist
None of this requires rebuilding your stack. It requires making sure the click ID gets captured once, early, before anything downstream can drop it.
- Capture gclid, fbclid, ttclid, and msclkid server-side at the first redirect hop, not on the landing page after scripts load.
- Store the click ID with the order or lead record in your own database, not only in a cookie that might expire before the sale closes.
- Forward the stored click ID to each platform's API - Conversions API, Enhanced Conversions, Events API, UET offline import - within that platform's validity window.
- Verify your shortener or redirect chain passes query strings through untouched; test with a dummy
?gclid=test123and confirm it survives the hop. - Pair click IDs with UTMs rather than picking one; tracking UTMs end to end covers the parallel setup for the campaign-level view a click ID alone can't give.
Most attribution gaps I've debugged trace back to that second bullet: a click ID that lived only in a cookie, on a domain that changed, or a session that expired before the deal closed. Fixing that one habit closes more gaps than any platform setting does - the kind of fix the tutorials section of the blog is built around.
Related on the Blog
Perguntas frequentes
What is fbclid?
fbclid is the Facebook Click Identifier, a parameter Meta appends to a URL when someone clicks a Facebook or Instagram ad or a Page link. The Meta Pixel or Conversions API reads that value out of the _fbc cookie or the URL and sends it back to Meta with the conversion event, so Meta can credit the exact click. It carries no personal information on its own - just an opaque string plus a timestamp.
What is gclid?
gclid is the Google Click Identifier, appended to a landing page URL through Google Ads auto-tagging whenever someone clicks a Google Search, Display, or Shopping ad. It is required for import-based offline conversion tracking and for Smart Bidding to see which specific click led to a sale. Google treats a gclid as valid for 90 days from the click.
What is the difference between a click ID and a UTM parameter?
A UTM parameter is human-readable text you write yourself, like utm_source=google, so your own analytics can group traffic by campaign. A click ID is an opaque token the ad platform generates and reads back through its own pixel or API to match one specific click to one specific conversion. UTMs describe a campaign; a click ID identifies a single click.
Is it safe to remove fbclid or gclid from a URL?
Yes, once your own tracking has already captured it. Stripping the parameter from a link you share, or from the URL shown in your analytics reports, does not undo the click that already happened. What breaks attribution is stripping it before your pixel, tag, or server has had a chance to read it - do that and the platform has nothing left to match the conversion against.
How long does a click ID stay valid?
It depends on the platform. gclid and msclkid are valid for 90 days from the click, ttclid for 30 days, and fbclid's browser cookie commonly runs around 90 days, though Meta's Conversions API can extend the effective window well past that if you store the value server-side. After the window closes, the platform rejects a conversion tied to that click ID.
What are ttclid and msclkid?
ttclid is TikTok's click identifier, auto-added to a landing page URL since April 2024 and valid for 30 days. msclkid is Microsoft Advertising's equivalent, a 32-character ID auto-tagged onto the URL and matched against UET conversions for up to 90 days. Both work the same way as gclid and fbclid: minted at the click, read back at the conversion.
Experimente Elido
Cole uma URL, obtenha um link curto
Sem cadastro. O link vive 30 dias. Cadastre-se para mantê-lo para sempre.
Grátis, sem necessidade de registo · 2 por dia