Reference page

Tracking IDs glossary for click IDs, braids, affiliate IDs, and UTMs

Use this page when a platform adds IDs like gclid, gbraid, wbraid, fbclid, ttclid, msclkid, or irclickid and you need to know what each one actually does before you start removing parameters blindly.

This is a reference page, not a deletion guide. The goal is to separate platform-owned click IDs from team-owned UTMs, then diagnose attribution problems in the right order so you do not misread normal parameter behaviour as broken reporting.

By Dean DownesLast updated 25 Mar 2026Part of the Shortlinkfix 5-Layer UTM Governance Model
Click IDs are platform-owned

They help the ad or affiliate platform connect the click to its own reporting and optimisation logic. They are not a replacement for your campaign naming system.

UTMs are team-owned

They give GA4 and your wider reporting model a stable naming contract. Their job is readability and governance, not platform auto-attribution.

Most problems are elsewhere

If attribution looks wrong, the failing layer is usually redirects, consent, landing-page changes, missing QA, or weak naming discipline, not the mere presence of IDs.

The quick rule

Tracking IDs do different jobs, so do not judge them by one reporting view

A click ID tells a platform something about the click it generated. A UTM tells your analytics stack how your team wants traffic grouped. Neither is wrong just because the other system reports differently. The safe move is to preserve what the platform needs, keep your UTM naming stable, and diagnose each layer in sequence.

Preserve platform IDs by default

Do not strip parameters like gclid, gbraid, wbraid, ttclid, fbclid, msclkid, or irclickid unless you have a very specific and validated reason.

Keep UTMs governed

Let your own campaign naming system stay readable and predictable. A healthy setup supports both click IDs and UTMs without letting them overwrite each other’s job.

Blame the route before the parameter

Most “ID problems” are really redirect, consent, landing-page, or QA problems. Diagnose the route and the final URL before you touch the parameters.

Use this page for: decoding what the parameters mean and deciding what to inspect next.
Do not use this page for: trying to force GA4, ad platforms, and affiliate dashboards to report identical numbers. That is a cross-platform attribution problem.

What this page actually owns

This glossary is useful when people are mixing together platform-owned IDs, analytics-owned naming, and route-level failures. It helps you restore clean definitions before you troubleshoot.

Identity

What the parameter identifies: a click, a campaign, a platform session, a destination variant, or a payout event.

Ownership

Who should control it: the ads platform, the affiliate network, or your own campaign governance model.

Boundary

What the ID can and cannot explain. Most click IDs cannot tell you whether your naming policy is clean, and most UTMs cannot tell the ad platform which click to optimise against.

Practical shortcut: if your question starts with “what does this parameter actually do?”, stay on this page. If your question starts with “why are the reports different?”, go to UTMs and attribution explained or why GA4 and affiliate data disagree.

The glossary

These are the IDs most teams run into. The safest reading order is: who adds it, which system needs it, and what breaks if it disappears before the final destination loads.

gclidGoogle Ads click ID used for Google’s own attribution and optimisation logic. Keep it intact unless your final route cannot preserve it.
gbraidGoogle’s privacy-aware click identifier used in certain consent-sensitive contexts. It exists to support attribution where traditional click handling is restricted.
wbraidAnother Google braid parameter used in privacy-constrained environments. Treat it as platform-owned and do not assume it behaves exactly like gclid.
fbclidMeta click identifier appended to outbound links from its properties. It is there for Meta’s click understanding, not to replace your reporting taxonomy.
ttclidTikTok click ID used to connect the outbound click to TikTok’s own measurement layer. Preserve it if TikTok reporting matters to the campaign.
msclkidMicrosoft Ads click ID. Same principle as other platform IDs: platform-owned, useful to the platform, not a substitute for your own naming contract.
irclickidImpact’s click identifier used to connect referral traffic to affiliate tracking and payout logic. If this disappears, affiliate attribution can break even when GA4 still sees UTMs.
UTMsYour controlled analytics naming layer: utm_source, utm_medium, utm_campaign, and optional fields like utm_content or utm_term.

The presence of more than one parameter is normal. A healthy URL can contain both a platform click ID and your own UTMs at the same time.

Keep, isolate, or stop blaming?

This is the decision table most teams actually need. The goal is not to micromanage every parameter. The goal is to know which IDs must survive, which should stay in their own lane, and which issues belong somewhere else entirely.

ID or groupDefault actionWhyCommon mistake
gclid, gbraid, wbraidKeepNeeded by Google-side attribution and optimisation flows.Stripping them because GA4 already has UTMs.
fbclid, ttclid, msclkidKeepUseful to the originating ad platform and generally harmless when the route is healthy.Blaming them for duplicate reporting that is really caused by weak naming or URL-level exports.
irclickid and network IDsKeep and validateAffiliate payouts can depend on them even when your analytics system does not surface them prominently.Optimising for GA4 readability and accidentally breaking payout attribution.
UTMsGovern tightlyThey give your own reporting model stable naming and comparable groupings.Letting them drift because platform auto-tagging exists.
Full URL parameter soupIsolate in diagnosticsSometimes the right move is not deletion but inspecting the final landing URL and report configuration more carefully.Trying to “clean” the URL before you prove which layer failed.
Keep: platform IDs that the originating system needs.
Govern: your UTMs and naming contract through policy, taxonomy design, and pre-launch QA.

The safe diagnosis order

When a campaign looks wrong, do not start by deleting IDs. Start by proving which layer is actually failing.

1

Check the final landing URL

Confirm which parameters survive the full redirect path and what the destination actually receives. Use the redirect checker when the route is unclear.

2

Check the reporting boundary

Decide whether you are asking a platform question, a GA4 question, or an affiliate payout question. Different systems can be healthy while still disagreeing.

3

Check your own governance layer

Validate UTMs, naming consistency, and log hygiene before blaming the click IDs. Weak governance creates fake “ID problems” all the time.

Best pairing: this page plus do redirects remove UTMs? and UTMs vs auto-tagging usually gets teams to the right answer faster than staring at raw URLs in a spreadsheet.

Where teams usually misread tracking IDs

The problem is often not the parameter itself. It is the interpretation wrapped around it.

“GA4 already has UTMs, so we can drop click IDs”

That only makes sense if you do not care about the ad platform or affiliate network understanding its own click. In most real setups, you need both layers alive.

“The extra parameters are causing duplicates”

Sometimes the duplicate feeling comes from report configuration, raw-URL exports, or inconsistent campaign naming. The parameters expose the mess; they did not create it.

“The platform should match GA4 exactly”

Different systems measure different boundaries, use different models, and survive different privacy constraints. Exact parity is not the baseline.

“We should shorten the URL for cleanliness”

Pretty URLs are not a tracking strategy. Keep the route healthy first, then worry about how the URL looks to the human eye.

Common failure patterns this page should help you spot

Use these patterns to decide which supporting page to open next.

Affiliate payout missing, GA4 looks fine

GA4 says direct or unassigned

  • Validate UTMs and redirect survival first.
  • Then check consent and landing-page behaviour.
  • Open GA4 direct / unassigned.

Too many parameters, nobody knows which matter

  • Use this glossary to assign ownership.
  • Then document the route and lock the naming layer.
  • Open tracking automation if the problem keeps repeating.

Use the right page for the right problem

This page tells you what the IDs mean. These pages tell you what to do next once you know the failing layer.

If the team keeps blurring tagging with attribution logic, read UTMs and attribution explained before you keep comparing unlike signals.

FAQs

Tracking ID glossary FAQs

What is the difference between a click ID and a UTM?

A click ID is usually added by an ads or affiliate platform for its own attribution. A UTM is added by your team so your analytics stack can group traffic consistently. A healthy setup supports both without letting them replace each other’s job.

Should I strip gclid, ttclid, msclkid, or irclickid from my links?

Usually no. Those IDs exist because the originating platform or network may need them. The safer move is to validate the final landing URL, reduce avoidable redirect problems, and keep your own UTM naming controlled.

Can click IDs replace UTMs?

No. Click IDs help the platform understand the click it generated. UTMs help your own analytics and reporting model keep campaign naming readable and governed. They solve different problems.

What should I check first if attribution looks wrong?

Check the final landing URL, confirm the important parameters survive the route, validate your UTMs, and then compare what the originating platform needs versus what GA4 needs to read.

Why do gbraid and wbraid exist?

They are Google parameters used in more privacy-constrained attribution contexts. Treat them as platform-owned signals and avoid assuming they should behave exactly like gclid in every environment.

Next routes

Keep the IDs that matter. Fix the layer that is actually failing.

The best tracking systems do not panic when a URL gets long. They know which parameters belong to the platform, which belong to the governance layer, and which route checks have to pass before anyone trusts the reports.