What UTM and click IDs carry when you forward a link

A marketer drops a landing page into a customer Slack channel. Support pastes the “campaign page” into a Zendesk ticket. A coworker copies a social share URL into an internal thread. Almost nobody looks past the question mark first. That long tail in the address bar looks like noise. It is a query string. The browser sends it as part of the request; chat apps, mail, and ticket systems store it as ordinary text.

This is not the same layer as “why a URL # fragment never reaches the server.” A fragment stays in the current tab and never enters the HTTP request line. A query parameter does. The existing piece Why URL hash fragments never reach the server only explains the hash. This article fills in the question mark: what usually walks out on a second hop is not the path, but the searchable, archivable fields after it — fields a downstream host can read again.

Google Analytics’ URL-builder help is blunt about the intended path: when a user clicks a referral link that carries UTM tags, those parameters are sent to Analytics and show up in the Traffic acquisition report. For a campaign team, that is the feature. For the person who forwards the same URL, it becomes something else: you hand the next channel a label for “which campaign this click came from,” plus any click ID the platform appended on its own. That channel does not promise a single, private read for the intended recipient.

The first kind is UTM. Google’s list includes utm_source, utm_medium, and utm_campaign, plus optional fields such as utm_term, utm_content, and utm_id. The values are plaintext you or a tagging tool wrote in — newsletter, email, sep-sale. They describe a campaign, not a user’s account. After a forward, though, the recipient, anyone who joins the channel later, and anyone who can export the thread can see which campaign and which channel the link was built for. Analytics treats case as a different value: utm_source=google and utm_source=Google split into two rows. To a person reading the paste, both are readable labels.

The second kind is a click ID. Ad platforms append it when someone taps an ad. The value is a long token, not meant to be read by a human. gclid comes from Google Ads auto-tagging and joins a click back to a conversion. fbclid is appended by Meta and is often read again by a pixel or a conversions API. The same family includes ttclid, msclkid, and twclid. You did not choose those values, and you cannot recover a campaign name from the string itself. They identify this click, not this campaign. Forwarding an address that still holds fbclid hands over a lookup key for that ad click.

The third kind is a sharer mark. Newsletter tools are the clearest English-language case: Mailchimp’s mc_cid names a campaign, while mc_eid is an encoded subscriber id that can be joined back to a list record. Instagram and Threads share URLs have long carried igshid or a similar private field. Community write-ups and Apple’s own Link Tracking Protection treatment list igshid as a tracking parameter, not a page selector. A check you can do without any reverse-lookup recipe: delete the question mark and everything after it; the post or landing page often still opens, and the sharer mark is gone. This article will not walk through, or repeat, any method for turning a parameter back into an account. The fact you can see on the spot is enough: some share links carry “who tapped Share,” not only “which campaign.”

Chat windows are built so you can find things again. After you paste a full campaign URL into a channel, the message body, the client cache, and the server-side search index each keep a copy. Three months later, a search for utm_campaign or fbclid can still surface that message. Recall rarely deletes the other side’s already-read push or a history that has already synced. This is not about trusting coworkers. They need the landing page. They do not need a token for that ad click.

Tickets and email keep the link as evidence. Once support pastes a user’s “this campaign page will not open” URL into a ticket, agents, escalation queues, and any outsourced viewer open the full address again. A full-page screenshot in a photo roll, or an address bar in a meeting recording, is a second, pixel-level channel. Keys should not go into chat — we covered that in After a cloud env-var leak, why the new key should not go back into chat. Tracking parameters are a milder leak. The residue shape is the same: the channel stores the exact characters you pasted.

Keep the fields that point the page at the right resource. id=128 selects a product. q= is a search term. page=2 is pagination. YouTube’s t= is a timestamp. Those are not campaign labels. Blindly “delete everything after the question mark” often works on a social share URL. On commerce and admin deep links, it drops you on a home page or an error.

Strip the fields that describe traffic source, identify a single click, or point at a sharer. The whole utm_* family, common click IDs, and attribution fields from commerce or content platforms — spm, mc_eid, igshid, refer_share_id — belong here. They do not decide which item opens. They decide who gets credit for this open.

When the call is unclear, start narrow: remove only utm_* and common click IDs, then see whether the page still points at the same resource. Only then decide whether to drop analytics fields and platform attribution. That is not a slogan. It is two settings you can compare by result.