Click IDs vs UTM tags: what's the difference?

What UTM tags actually do

UTM (Urchin Tracking Module) parameters were invented in 1996 by Urchin Software Corporation and absorbed into Google Analytics in 2005. The five tags — utm_source, utm_medium, utm_campaign, utm_term, utm_content — are publisher-authored: whoever sets up a campaign decides the values. There's no central authority and no per-user uniqueness.

Their job is to answer one question for the publisher's analytics: “which campaign did this click come from?”. utm_source names the origin, utm_medium names the channel, utm_campaign names the campaign bucket. The values are descriptive strings (“newsletter”, “email”, “spring-launch”) — readable in a dashboard, opaque to anyone else.

Crucially, none of these values are unique to a person. utm_source=newsletter means “this click came from a newsletter” — it could be any subscriber, any forward, any forwarded forward. The publisher learns a count, not an identity.

What click IDs actually do

fbclid, gclid, msclkid, ttclid, yclid — each one is generated by an ad network at click time and is unique per click. The token encodes the ad-account, the campaign, the ad creative, the click event, and (where the network still has a cookie or IDFA) the user identifier on their side.

When the destination page loads, the ad-network's pixel reads the click ID and reports it home. The network now knows: “the impression we served at 12:04:31 from campaign 7821-ad-3, attributed to user-cookie ABC123, did in fact convert into a pageview.” Down to the individual click.

Click IDs aren't designed to identify *you* to the destination site — but they identify the click to the ad network, and the ad network usually has a cookie or other join key on you separately. So joined-up, they're identity-adjacent.

Why both exist on the same link

Different audiences. UTM tags serve the *publisher's* analytics (Google Analytics reading their own outbound links). Click IDs serve the *ad network's* attribution (Meta knows their ad worked).

When you click a Facebook ad: Meta adds fbclid (for their pixel to read). The advertiser had also added utm_source=facebook&utm_medium=cpc&utm_campaign=… in the ad's destination URL (for their Google Analytics). Both ride along to your browser. Both get reported home to two different systems.

What the harm model is

UTM tags broadcast marketing metadata. The risk of forwarding them is that you carry the publisher's campaign attribution into someone else's analytics. Annoying for the publisher's bookkeeping (their forward gets counted as a newsletter click); not particularly harmful to you or the recipient.

Click IDs are stronger. Forwarding fbclid carries Meta's click identifier into someone else's browser — if their browser runs Meta Pixel on the destination page, the Pixel reports a pageview tied to *your* click context. Meta now sees a Pixel hit they can join to your original ad impression. Quietly inflated bookkeeping plus an extra signal back to the ad network.

Both are worth stripping. Click IDs are worth stripping more.

Why LinkClean strips both by default

LinkClean's catalog rule is “vendor-specific names get default-on”. utm_source / utm_medium / utm_campaign / fbclid / gclid / msclkid / ttclid / yclid all qualify — no legitimate URL uses these for anything but tracking attribution. They're stripped on every host with no opt-in needed.

Generic words (ref, source, t, s, q) that double as functional keys on some sites — those stay default-off, with host-scoped exceptions where they're known trackers (si= on YouTube, t/s on x.com).