gclid vs fbclid vs UTM Parameters: What's the Difference?

Click IDs (gclid, fbclid) are platform-specific identifiers that Google and Meta automatically append to URLs when a user clicks an ad. They let the platform tie that specific click to a later conversion. UTM parameters (utm_source, utm_medium, utm_campaign, utm_term, utm_content) are manually-set tags that work across analytics tools and CRMs. The two solve different problems — click IDs power platform-side attribution, UTMs power cross-channel analytics — and most setups need both.

The confusion is reasonable: all three live in the URL as query parameters, all three are about “where the traffic came from,” and all three get stripped, lost, or mis-stored in CRMs more often than they should be. This article disambiguates the three, explains when each is used, and covers the storage patterns that keep them attached to the lead through the funnel.

What’s the difference between click IDs and UTM parameters?

The fastest way to see the difference is side-by-side:

Click IDs are machine-readable handles for the platform that issued them. UTM parameters are human-readable labels for your analytics stack. The two are complementary, not interchangeable: a URL with both — ?gclid=abc...&utm_source=google&utm_medium=cpc&utm_campaign=q2-launch — gives Google’s attribution engine the click handle it needs and gives your analytics tool the campaign labels it needs.

What is the Google Click Identifier (gclid)?

The Google Click Identifier (gclid) is a unique string that Google Ads automatically appends to the destination URL when a user clicks one of your search, display, or shopping ads. It looks like this:

https://yoursite.com/landing-page?gclid=Cj0KCQiAtbqdBhDvARIsAGYnX1QABCD123XYZ

The gclid value encodes (in Google’s internal format) the campaign, ad group, keyword, ad creative, and click metadata for that specific click. Google reads it back when the user converts — either via a website conversion event tracked by the Google tag, or via an offline conversion upload that includes the stored gclid — and ties the conversion to the originating campaign.

gclid is set automatically when auto-tagging is enabled in your Google Ads account (it’s on by default for new accounts since 2018). If auto-tagging is off, gclid doesn’t appear and you have to fall back to UTM parameters or manual tagging for attribution.

The gclid is opaque — you can’t decode it client-side. Don’t try to parse it; treat it as a blob. Store it on the lead record so it can be uploaded back to Google Ads when an offline conversion occurs (a phone-call close, a CRM-recorded sale, etc.).

Google offers a sibling parameter, gbraid, for iOS-specific traffic where ATT restrictions affect attribution. Google’s documentation specifies gclid for desktop and Android, gbraid for app-to-web iOS traffic, and wbraid for web-to-app iOS traffic. For most lead-gen pipelines you’ll see gclid most of the time.

What is the Facebook Click Identifier (fbclid)?

The Facebook Click Identifier (fbclid) is Meta’s equivalent of gclid. It’s appended automatically to any link clicked from a Facebook, Instagram, Messenger, or Audience Network ad:

https://yoursite.com/landing-page?fbclid=IwAR0abc123XYZ...

The fbclid value identifies the specific click within Meta’s auction logs. When the Meta Pixel fires on the landing page, it captures the fbclid from the URL and stores it in the _fbc cookie in Meta’s required format: fb.1.<creation_time_ms>.<fbclid>. The _fbc cookie value is then sent to Meta on every subsequent conversion event — via the Pixel directly, or via the Conversions API (CAPI) on the fbc parameter — and Meta uses it to tie the conversion back to the originating ad.

Like gclid, fbclid is opaque. Don’t parse it; capture it from window.location.search when the user lands and store it.

fbclid has a different storage convention than gclid: Meta wants the fbclid wrapped into the _fbc cookie format (with a timestamp prefix), not the raw fbclid value. If you’re capturing fbclid for CAPI, the correct stored value is fb.1.${Date.now()}.${fbclidFromUrl}, not the raw URL parameter. Sending the unwrapped fbclid as the fbc parameter is a common mistake that produces silent match failures.

What are UTM parameters and what do they track?

UTM parameters are a set of five query string tags — utm_source, utm_medium, utm_campaign, utm_term, utm_content — that originated with the Urchin analytics tool in the early 2000s and were inherited by Google Analytics. They’re a published open standard that every analytics platform, CRM, and email tool recognizes.

UTMs are set manually by the advertiser — you build them into the destination URL when you set up the ad, the email, or the social post. They’re plain text and human-readable, which is the source of both their value (analytics tools can group by them cleanly) and their fragility (case-sensitive, typo-prone, inconsistent across teams).

The standard practice: use lowercase, separate words with hyphens not spaces or underscores, and maintain a centralized naming convention document so Facebook, facebook, and FB don’t end up as three different sources in GA4.

UTMs are platform-agnostic. Google Ads doesn’t read them for attribution (Google uses gclid); Meta Ads doesn’t read them either. UTMs serve your analytics stack and your CRM, not the ad platform.

When should you use click IDs, UTMs, or both?

The short answer: both, on every paid ad URL. The click ID tells the ad platform “this click became a conversion.” The UTMs tell your analytics stack and CRM “this lead came from this campaign on this channel.” Skipping either creates an attribution gap somewhere.

A correctly-tagged URL for a paid Meta ad looks like:

https://yoursite.com/landing-page?fbclid=AUTO_BY_META&utm_source=facebook&utm_medium=cpc&utm_campaign=q2-saas-launch&utm_content=video-ad-v1

A correctly-tagged URL for a Google Ads search click looks like:

https://yoursite.com/landing-page?gclid=AUTO_BY_GOOGLE&utm_source=google&utm_medium=cpc&utm_campaign=q2-keywords&utm_term=lead-capture-software

For organic and email traffic where there’s no click ID, UTMs are the only signal — set them consistently and the cross-channel attribution still works inside your analytics tool. For paid traffic without UTMs, the ad platform’s own dashboard still works (because the click ID is enough for the platform), but your GA4 and CRM views lose the campaign-level granularity.

A click ID without UTMs gives the ad platform attribution but blinds your CRM. UTMs without a click ID give your CRM attribution but blind the ad platform. Both, on every URL, every time is the rule.

How long does each identifier stay attributable?

The three identifiers have very different attribution lifetimes:

gclid’s 90-day window is the longest of the three, which is why offline conversion tracking — uploading sales-team-closed leads back to Google Ads weeks after the original click — works for Google in a way it generally doesn’t for Meta. Meta’s 7-day default means the same offline upload to Meta has a much shorter useful window unless you also configure a longer click attribution setting.

UTM parameters are indefinite because they live wherever you store them. If you save utm_source=newsletter on a lead record, you can attribute that lead to the newsletter source two years later. The attribution is a storage question, not a freshness question.

How should you store click IDs in your CRM?

The right pattern: capture every identifier from the URL when the lead lands, persist them to a first-party cookie or localStorage so they survive multi-page sessions, and write them to the lead record alongside email/name/phone when the form is submitted (or captured as a partial lead).

A minimal capture script:

const params = new URLSearchParams(window.location.search);
const tracking = {
  gclid: params.get("gclid"),
  fbclid: params.get("fbclid"),
  utm_source: params.get("utm_source"),
  utm_medium: params.get("utm_medium"),
  utm_campaign: params.get("utm_campaign"),
  utm_term: params.get("utm_term"),
  utm_content: params.get("utm_content"),
};
 
// Persist first non-null values for 30 days
Object.entries(tracking).forEach(([key, value]) => {
  if (value && !localStorage.getItem(`tracking_${key}`)) {
    localStorage.setItem(`tracking_${key}`, value);
    localStorage.setItem(`tracking_${key}_at`, new Date().toISOString());
  }
});

A few storage rules that matter in practice:

• Capture first-touch, not last-touch, by default. If the user clicks a Google ad, browses, then clicks a Meta ad before converting, you usually want both stored — gclid from the first visit, fbclid from the second, and the UTMs from each. Overwriting on every visit loses the first-touch signal.
• Don’t strip click IDs from URLs you redirect through. Some platforms strip query parameters during redirects “for cleanliness” — this breaks attribution on the destination page. Preserve them.
• Map to CRM fields explicitly. HubSpot, Salesforce, and Pipedrive each have native fields for gclid and UTM parameters. Use them; don’t dump everything into a single freeform “source” field.
• Don’t strip click IDs when emailing a recovery link. If a partial lead gets a recovery email with a link back to the form, keep the original click IDs in the URL so the eventual conversion still attributes correctly.

How does PartialLeads capture click IDs alongside the lead?

When PartialLeads’ tag loads on the page, it reads gclid, fbclid, and all five UTM parameters from window.location.search and persists them as first-party cookies. The captured values are attached to every subsequent partial-lead capture and full form submission — so every lead that enters the CRM carries its full attribution context, not just the email and name.

Specifically:

• First-touch capture. The first visit’s gclid, fbclid, and UTMs are persisted and never overwritten. If the visitor returns later through a different channel, the new values are stored separately as last-touch. The lead record carries both, so multi-touch attribution works downstream.
• _fbc cookie management. The fbclid is wrapped in Meta’s required fb.1.<timestamp>.<fbclid> format and written as the _fbc cookie. Every CAPI event PartialLeads dispatches includes the correctly-formatted fbc parameter — which is what Meta actually expects, not the raw fbclid from the URL.
• CRM handoff. When the lead is forwarded to your CRM (HubSpot, Salesforce, Pipedrive, or via webhook to a custom backend), the click IDs and UTMs are mapped to their canonical fields on the contact or deal record. The sales team sees campaign attribution the same way analytics does. The structural benefit: a partial lead captured from email@example.com arriving from a Meta ad shows up in the CRM with fbclid, _fbc, utm_source=facebook, utm_medium=cpc, and the campaign name attached — same data quality as a fully-completed form, recovered before the user even hit submit.

Sources

1. Google Ads Help — Google Click Identifier (gclid): https://support.google.com/google-ads/answer/9744275
2. Google Ads Help — About auto-tagging: https://support.google.com/google-ads/answer/3095550
3. Meta for Developers — fbp and fbc parameters: https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/fbp-and-fbc
4. Google Analytics Help — Campaign URL Builder (UTM reference): https://ga-dev-tools.google/campaign-url-builder/
5. Google Ads Help — About offline conversion imports: https://support.google.com/google-ads/answer/2998031
6. Meta Business Help — About attribution settings: https://www.facebook.com/business/help/2198119873776795