UTM vs click IDs (gclid, fbclid, msclkid)
UTM parameters are manual labels you write; click IDs like gclid, fbclid, and msclkid are opaque identifiers a platform auto-appends. This page explains how they differ, which tools read which, and why setting conflicting manual and auto-tagged values on one URL causes double-counting.
Two different mechanisms
utm_* parameters are human-written labels: you choose utm_source, utm_medium, and utm_campaign so any tool can group the visit. A click ID — gclid for Google Ads, fbclid for Facebook, msclkid for Microsoft Advertising — is an opaque token the platform appends automatically and reads back inside its own reporting.
The practical split: utm_* is what generic analytics tools understand, while a click ID is meaningful primarily inside the platform that issued it. They solve overlapping but different problems.
- utm_* — manual, human-readable, read by generic analytics
- gclid / fbclid / msclkid — auto-appended, opaque, platform-read
- Neither replaces the other for every tool
Do not double-tag carelessly
You can technically have both on one URL, but if a click ID implies one source while your utm_source says another, two tools can attribute the same click to two different labels — inflating totals. Pick one source of truth per tool: let the platform's click ID feed the platform's own reporting, and use clean, consistent utm_* for everything that reads query parameters.
Where a platform offers auto-tagging, enabling it and also setting conflicting manual UTM is the usual cause of mismatched paid-traffic numbers across tools.
How it appears in analytics and logs
A landing URL may carry utm_* (manual), a click ID (auto-appended), or both. Generic analytics read utm_*; platform reporting reads its own click ID. If both are present and disagree, the same click can be labelled twice.
Diagnostic use case
Decide whether to rely on manual UTM, platform click IDs, or both — and avoid setting conflicting values on the same destination URL.
What WebmasterID can help detect
WebmasterID attributes from utm_* parameters and does not depend on any platform click ID. If you want a paid click to attribute here, add manual UTM; a click ID alone is read mainly by the platform that issued it.
Common mistakes
- Setting manual utm_* that disagree with an auto-appended click ID, double-counting clicks.
- Assuming a click ID alone populates tools that read only utm_*.
- Trying to decode a click ID as if it carried readable campaign data.
Privacy and accuracy notes
A click ID is an opaque platform identifier, not visitor personal data, but treat it as opaque and do not try to decode it. Keep manual utm_* values to generic labels and add no personal data to either.
Related pages
- Google Ads UTM tracking
Google Ads can attach a gclid automatically (auto-tagging) or you can add manual UTM parameters. This page explains how the two interact, why double-tagging a URL with both conflicting schemes causes confusion, and how to keep your utm_* values clean and consistent.
- Microsoft (Bing) Ads UTM tracking
Microsoft Advertising (formerly Bing Ads) can attach an msclkid click identifier or you can add manual UTM parameters. This page explains how the two interact and how to keep utm_medium=cpc consistent so Microsoft paid search groups alongside your other paid channels.
- Attribution analytics
Attribute visits from utm_* without depending on platform click IDs.
Sources and verification notes
- Google Ads Help — Auto-taggingDocuments the gclid auto-tagging mechanism.
- MDN — URL search paramsBoth click IDs and utm_* are query-string parameters.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.