Click ID parameters — GCLID from Google Ads, FBCLID from Meta, MSCLKID from Microsoft, TTCLID from TikTok — are automatically appended to destination URLs by advertising platforms and interact with UTM parameters in ways that can inflate, deflate, or completely misattribute campaign performance in analytics
UTM parameters were designed as a simple, manual tagging system. Click ID parameters were added by platforms seeking more reliable attribution than UTM strings provide. The interaction between the two systems — both trying to solve attribution but using different mechanisms — produces counter-intuitive results that anyone running paid campaigns needs to understand.
What click IDs actually are and why platforms use them
UTM parameters (utm_source, utm_medium, utm_campaign, utm_content, utm_term) are simply query string values — plain text that analytics platforms read and report. Their weakness: they're attached to the click URL and are lost if the user navigates away, clears cookies, or if the referrer is stripped.
Click IDs solve a different problem: they allow the advertising platform to record attribution on their own servers rather than relying on the analytics tool's cookie. When a user clicks a Google Ad with GCLID, Google's servers record the click with that specific GCLID. If a conversion subsequently occurs, Google Ads can match it to the GCLID — independently of whether GA4 also tracked the session.
The attribution difference:
- UTM-based attribution: depends on the GA4 cookie being set, maintained across the session, and correctly attributed to the conversion event
- GCLID-based attribution: depends on the GCLID being present in the URL when the conversion URL is loaded, or being stored in a first-party cookie set by the ads platform's JavaScript
Why both exist simultaneously: different advertising platforms use different click ID systems, and marketers often use GA4 (or another analytics platform) alongside the ad platform's own reporting — comparing the numbers between platforms to validate performance.
How GCLID interacts with UTM parameters in GA4
When a URL has both UTM parameters and a GCLID:
https://example.com/landing?utm_source=google&utm_medium=cpc&utm_campaign=brand&gclid=Cj0KCQIA...
GA4's behaviour:
- If auto-tagging is enabled in Google Ads (the default): GA4 recognises the GCLID and uses it to pull campaign data from Google Ads automatically, potentially overriding the manual UTM values
- If auto-tagging is enabled and UTMs are also present: GA4 may prefer the auto-tagged data from GCLID, causing the manual UTM values to appear inconsistently across sessions
The practical conflict: a marketing team using UTM parameters for cross-platform reporting in GA4 may find that Google Ads traffic is attributed differently in GA4 than the manual UTM structure intended, because GCLID-based auto-tagging takes precedence.
The recommended setup: either use UTM parameters consistently and disable auto-tagging in Google Ads (losing some conversion import capabilities), or use auto-tagging and rely on GA4's Google Ads integration for Google traffic — not both simultaneously for the same traffic.
UTM parameter governance: the naming fragmentation problem
UTM parameter values are free-form text — there's no enforcement of naming conventions. In an organisation with multiple team members tagging campaigns:
One person tags: utm_source=google&utm_medium=cpc
Another tags: utm_source=Google&utm_medium=CPC
Another tags: utm_source=Google Ads&utm_medium=Paid Search
In GA4 (and Universal Analytics before it), these are three different source/medium combinations — Google treats "google" and "Google" as different values. The same Google Ads campaign appears as three separate traffic sources in reports, making it impossible to view consolidated Google Ads performance.
The specific failure this creates: a monthly report shows "google / cpc" traffic at 1,000 sessions, "Google / cpc" at 800 sessions, and "Google Ads / Paid Search" at 600 sessions — what is actually 2,400 sessions from the same source appears fragmented into three lines, each appearing smaller than it actually is, potentially being deprioritised relative to other channels.
The canonical UTM parameter taxonomy
A well-governed UTM taxonomy pre-defines every permitted value for each parameter:
utm_source values (examples):
google(Google Ads, not "Google" or "Google Ads")meta(Meta/Facebook Ads, not "facebook" or "Facebook")linkedin(LinkedIn Ads)newsletter(email newsletters)partner-site-name(referral traffic from named partners)
utm_medium values:
cpc(cost-per-click paid search)display(display advertising)email(email marketing)social(organic social media)paid-social(paid social media)affiliate(affiliate marketing)referral(referral from other sites — typically not used; GA4 auto-classifies referral traffic)
The lowercase rule: enforce lowercase for all UTM values. A single violation creates a permanent split in historical data that cannot be retroactively corrected.
UTM parameters and duplicate content: the canonical issue
A URL with UTM parameters is technically a different URL from the same URL without UTM parameters:
https://example.com/article/ and https://example.com/article/?utm_source=newsletter&utm_campaign=march are different URLs that serve identical content.
The SEO risk: if Google crawls UTM-tagged URLs (through sitemap, shared links, or internal links accidentally containing UTM strings), it may index the UTM-tagged version as a separate page, creating duplicate content — or worse, splitting the page's link equity between the canonical and UTM-tagged versions.
The canonical solution: the page at https://example.com/article/?utm_source=newsletter should have a canonical tag pointing to https://example.com/article/. Many CMS platforms do this automatically (WordPress with Yoast, for example), but it's worth verifying that UTM-tagged URLs are not indexed and are properly canonicalised.
URL normalisation in robots.txt vs canonical: robots.txt blocking UTM-tagged URLs prevents crawling but doesn't pass link equity to the canonical — canonical tags are the correct solution for preventing duplicate content from UTM parameters while preserving link equity.
How to use the UTM Builder on sadiqbd.com
- For taxonomy enforcement: build UTMs through the tool using pre-agreed lowercase source/medium/campaign values from your organisation's taxonomy document — avoiding the free-form typing that introduces capitalisation and spelling variations
- For click ID awareness: when sharing UTM-tagged URLs for paid campaigns, verify whether the advertising platform will append its click ID automatically — if so, check whether the resulting URL (with both UTM and GCLID/FBCLID) behaves as intended in your analytics setup
- For canonical verification: after deploying UTM-tagged campaigns, check Google Search Console to confirm the UTM-tagged URLs are not being indexed — if they appear in the Discovered pages or Coverage report, implement or verify the canonical tag implementation
Frequently Asked Questions
Should UTM parameters be used on internal links between pages of the same website?
No — using UTM parameters on internal links overwrites the original traffic source in analytics. If a user arrives from Google organic search (source: google, medium: organic) and then clicks an internal link tagged with utm_source=homepage-banner, their session is re-attributed to "homepage-banner" in Google Analytics. The organic attribution is lost for that session, and the homepage banner appears to generate conversions that were actually driven by organic search. UTM parameters should only be used for external links pointing to your site — specifically, links you control that appear outside your own domain (email campaigns, social media posts, ads, partner site links). Internal navigation between your own pages should never be UTM-tagged.
Is the UTM Builder free? Yes — completely free, no sign-up required.
Try the UTM Builder free at sadiqbd.com — create correctly formatted UTM tracking URLs for any campaign and channel.
