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.
irclickidWhat it does: connects an affiliate or partner-network click to network-side attribution and payout logic.
When to preserve it: keep it through redirects, wrappers, and merchant handoffs whenever affiliate credit or partner reporting matters.
Check before blaming GA4 or UTMs: trace the exact live route and confirm the value survives before treating a GA4 mismatch as a campaign-tagging problem.
ttclidWhat it does: carries TikTok click context so TikTok-side measurement can connect the outbound click to its reporting layer.
When to preserve it: keep it on paid TikTok routes until the landing page and measurement layer have had a fair chance to use it.
Check before blaming GA4 or UTMs: validate the final URL, redirect chain, and UTM naming first; a clean GA4 row does not prove the platform click ID survived.
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.
They give GA4 and your wider reporting model a stable naming contract. Their job is readability and governance, not platform auto-attribution.
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.
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.
Do not strip parameters like gclid, gbraid, wbraid, ttclid, fbclid, msclkid, or irclickid unless you have a very specific and validated reason.
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.
Most “ID problems” are really redirect, consent, landing-page, or QA problems. Diagnose the route and the final URL before you touch the parameters.
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.
What the parameter identifies: a click, a campaign, a platform session, a destination variant, or a payout event.
Who should control it: the ads platform, the affiliate network, or your own campaign governance model.
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.
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.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.
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 group | Default action | Why | Common mistake |
|---|---|---|---|
gclid, gbraid, wbraid | Keep | Needed by Google-side attribution and optimisation flows. | Stripping them because GA4 already has UTMs. |
fbclid, ttclid, msclkid | Keep | Useful 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 IDs | Keep and validate | Affiliate payouts can depend on them even when your analytics system does not surface them prominently. | Optimising for GA4 readability and accidentally breaking payout attribution. |
| UTMs | Govern tightly | They give your own reporting model stable naming and comparable groupings. | Letting them drift because platform auto-tagging exists. |
| Full URL parameter soup | Isolate in diagnostics | Sometimes 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. |
When a campaign looks wrong, do not start by deleting IDs. Start by proving which layer is actually failing.
Confirm which parameters survive the full redirect path and what the destination actually receives. Use the redirect checker when the route is unclear.
Decide whether you are asking a platform question, a GA4 question, or an affiliate payout question. Different systems can be healthy while still disagreeing.
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.
The problem is often not the parameter itself. It is the interpretation wrapped around it.
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.
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.
Different systems measure different boundaries, use different models, and survive different privacy constraints. Exact parity is not the baseline.
Pretty URLs are not a tracking strategy. Keep the route healthy first, then worry about how the URL looks to the human eye.
Use these patterns to decide which supporting page to open next.
irclickid survives the route.gclid.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.
Start with UTMs and attribution explained and cross-platform attribution.
Open do redirects remove UTMs? or test the path with the redirect checker.
Use the governance framework, the naming template, and the QA checker.
Go to UTMs for affiliates, UTMs for paid ads, or where UTMs show in GA4.
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.
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.
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.
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.
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.
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.