What the tracking on a link tells them

Two different things get attached to a link

A link that arrives in an email or a group chat usually carries two kinds of tracking, and they are not equivalent. A campaign tag such as utm_source describes the advert, email or post the link was placed in. It is written once, when the campaign is built, and every recipient gets the same value. A click identifier such as fbclid, msclkid or mc_eid is minted for a single click or a single recipient, so your copy of the link and a colleague's copy of the same newsletter carry different values.

Taking a utm_campaign off a link you forward denies somebody's dashboard one row. Taking an mc_eid off it stops you handing four other people an identifier that was issued to you, and that Mailchimp's own API will resolve back to the subscriber it belongs to. Here is an ordinary link with the two sorts marked:

Bold is the link. The rest is a report about how you got there. Run that exact string through SANILINK and what comes back is https://www.example.com/article?id=42.

The UTM family, and what each one is for

UTM stands for Urchin Tracking Module, after the analytics product the convention came from. Five are in common use, and each answers a question about the campaign rather than about you.

utm_source

Where the traffic came from, as a named place: newsletter, google, the name of a partner site.

utm_medium

What kind of channel it was: email, cpc for a paid click, social, referral.

utm_campaign

Which campaign, so a spring sale and an autumn one can be told apart in one report.

utm_term

The paid keyword the click was bought against, in a pay-per-click campaign.

utm_content

Which of several links or creatives inside one campaign was clicked. Two adverts in the same campaign get utm_content=slogan1 and utm_content=slogan2 so they can be compared.

By design none of the five selects content. The page is chosen by the path and by whatever parameters the application itself defines; the UTM tags are read afterwards, by the analytics script. That is why removing them is safe, and why it is worth doing.

Click identifiers, which are about you

These are a different category. They are generated at the moment of the click, or when the message is sent, and the value is what makes the click yours.

gclid

Google Ads. Attached automatically to the destination when somebody clicks an advert.

gbraid, wbraid

Two further Google Ads identifiers, introduced in 2021 for iOS traffic where a gclid could no longer be set.

msclkid

Microsoft Advertising, added by auto-tagging and unique to one ad click. Two clicks on the same advert by the same person produce two different values.

fbclid

Meta's click identifier, generated for a single click on a link in Facebook or Instagram and attached to wherever that link goes.

ttclid

TikTok's equivalent, appended on an ad click.

igshid, igsh

Appended by Instagram when a link is copied out of the app. It identifies the share, which in practice means it identifies the account the link came from.

mc_eid

Mailchimp, unique per subscriber per list. The Marketing API accepts that value as unique_email_id to look up which member it was issued to. The mc_cid beside it names the campaign, and is the harmless half of the pair.

_hsenc

HubSpot's identity tracking value: a hashed string identifying the contact who clicked. _hsmi names the mailing.

The test for which kind you are holding needs no tooling. Compare your copy of the link with somebody else's copy of the same message. Same value, and it describes the campaign. Different value, and it was issued to you, so forwarding the link forwards it.

A shortener is a redirect that logs the click

A short link is not an alias your computer resolves on its own. bit.ly/3xYzAbC is a real request to a real server, which answers with a 301 or 302 and a Location header naming the destination; the browser then makes a second request to that address. To answer at all the shortener has to receive the first request, so it sees which code was asked for, your IP address, your User-Agent and the time. The destination is usually tagged as well, so one click is logged twice, by two parties.

A short link therefore cannot be cleaned, only resolved, and resolving it means making the request you were trying not to make. SANILINK will not do it: https://bit.ly/3xYzAbC comes back as it went in. Wrappers that carry the real address in plain sight are different, and unwrap without touching the network. SANILINK knows five shapes and follows up to five hops: google.com/url?q=, facebook.com/l.php?u=, l.facebook.com/l.php?u=, out.reddit.com/...?url= and safelinks.protection.outlook.com/?url=. An Outlook safelink wrapping a tagged document link comes out as https://docs.example/q, wrapper and mc_eid both gone.

Tracking that is not in the query string

The query string is only the part after the first ?. Everything before it is the path, and a per-recipient token sits there just as comfortably. Given https://example.com/r/AbCd12345/landing?gclid=EAIaIQ, the browser's own parser puts ?gclid=EAIaIQ in search and /r/AbCd12345/landing in pathname. Cleaned, that becomes https://example.com/r/AbCd12345/landing: the gclid is gone, the token in the path is untouched. That is the right behaviour, because the path is how the site finds the page and a cleaner that guessed at segments would break links constantly. It also means a tracking token moved out of the query string survives everything on this page. What is left to go on is the hostname, which is why UNBEACON recognises forty-five bulk-mail hosts by name.

What is safe to take off, and what is not

Campaign tags and click identifiers can go. What has to stay is anything the page reads in order to decide what to show you:

• A video or item selector. ?v=dQw4w9WgXcQ is the video, &t=42 is where to start it. Both survive cleaning. Take the v off and there is no video.
• Pagination, sorting and search. ?page=3, &sort=price, a search query. All survive.
• A signed or session token. A storage link carrying X-Amz-Signature is signed over the literal text of the query, so it has to come back byte for byte. SANILINK puts surviving parameters back as the exact text they arrived as: ?a=hello%20world&flag&b=~x! goes in and the same string comes out. Rebuilt through the browser's own URLSearchParams it would not, because %20 becomes +, ! and ~ get percent-escaped, and a bare flag gains an =. Any of those breaks a signature.
• A one-time share token. If a document reached you as a long random parameter, that parameter is the credential, and nothing can tell it apart from tracking by looking at it.

So the rule is a list rather than a judgement: ninety exact names plus eleven prefixes, utm_, pk_, piwik_, matomo_, hsa_, ml_, vero_, oly_, _ga, ga_ and __cf, matched without regard to case so FBCLID is caught as well as fbclid. Anything not on the list survives. That is the safe direction to fail in and it costs at both ends: Spotify's si share identifier is not on the list, so a shared track link comes back unchanged, while referrer is on it, so a page using ?referrer= for something functional would lose it. Open an important link once after cleaning it.

What to do with a link before you send it on

Paste it into SANILINK, which strips the known trackers and unwraps the redirect wrappers in the tab, without opening the link or contacting anything. It lists what it removed, so the result is checkable rather than magic, and a whole list at once is fine.

If the link came in a newsletter it is not the only thing in the message: UNBEACON finds the beacons beside it, meaning zero-size images, images on known tracking hosts, images with tracking parameters in the source, and CSS background beacons. Forwarding the message forwards those too. If the link came as a QR code, QRSHIELD decodes the image in the tab and flags what matters when reading a domain in a hurry: an @ that turns everything before it into a username, a punycode xn-- host, a bare IP address, and a shortener hiding the destination.