upvote
Three angles:

The technical purist: you’re modifying a URL in a way that, while in line with accepted custom, is technically incorrect. URLs should (the least effective type of should) basically be treated as opaque.

Social: it’s tracking stuff, sibling comment trees are good, I won’t reiterate.

Clutter: it’s getting in the way of the bit you should care about, and contributing to normal people no longer caring about URLs because they’re too hard, too complex.

reply
You can read some of the issues people have had with this by reading up on the http referer header: https://en.wikipedia.org/wiki/HTTP_referer

There are a lot of reasons I might not want a site to know where I came from to get to their site. It is basically sharing your browsing history with the site you are visiting.

Because of this, there have been a lot of updates to the http referer header, with restrictions on when it is sent, and an ability to opt out of the feature entirely.

Adding a url parameter with the same information bypasses any of these existing rules and ability to opt out. They should just use the standard.

reply
If I send out an email campaign, I can't use custom http headers to know that a user arrived from the newsletter.
reply
If you are sending out an email, you can use whatever url form you like?

This is talking about links to third party sites, not your own.

reply
use a unique url for each email
reply
As your reader, I might not actually want you to know.
reply
Do you really need to? Basic statistics will tell you if the email campaign had any significant effect on site visits.
reply
If I release a video and send an email newsletter at the same time, which one caused the traffic increase? Should I invest in making more videos of sending more emails?
reply
If you insist on knowing, include a different url in both that goes to the same place and use your damn server logs. You don’t need google analytics and whatever.
reply
Isn't putting in a different query string "including a different url that goes to the same place"?

Isn't this functionally the exact same?

reply
presumably you control the urls you are sending in the email. As a result if you want to use query strings that's fine. The issue only arises when you use query strings to implement tracking on someone else's site instead.
reply
There is no reason at all.

You could simply throw the information away.

It's a ridiculously extreme stance and lacks proper explanation how this will lead to a better web.

reply
It may be ridiculous to some, but Chris is totally right - it’s his website and he can do what he wants with it!
reply
What's interesting is that none of these sites have a "search" feature. Which is an important accessibility feature and a clear and legitimate use case for a query string.
reply
> If I ever start using any query strings, I’ll allow only known parameters.

They aren't saying the concept of query strings are bad, They're saying unsolicited query strings during referal are the issue.

reply
My website has search without a query string: https://www.jeremykun.com/
reply
Oh, I have a couple - the users did not agree on being tracked (these query params are tracking information), and the site administrator does not want incoming traffic to be tracked. I know the latter can be hard to understand, but I for example sure as hell do not want to have any info in my logs that can be used to harm my users.

On a more personal note, I hate it when I go to copy a link to send via a message, and the tracking code glued onto it is twice as long as original URL... I either have to fiddle around with it to clean it up or leave the person I sent it to to wonder wtf am I on about with a screenful of random characters...

So it's violating users' privacy, it's shit UX, and on top of that, nobody asked for it...

reply
>(these query params are tracking information)

Query strings are useful for way more than just tracking. Saving and servicing search queries is a way more common use case. So assuming it's only useful for tracking is very misleading.

Query strings are probably the least invasive tracking. They are transparent, obvious, and anonymous. Users are free to strip out and edit query strings if they don't want them.

More to the point, I can essentially do the same thing with HTTP routing - create an infinite number of unique URLs for tracking purposes. In that regard calling out query strings specifically for essentially the same thing but more transparently seems like splitting hairs.

reply
Yeah I do not see an alternative way to easily copy paste links with things like filter settings saved.

Filters especially make sense as query params as they are non sequential but still visually readable as to what they do.

URL slugs make sense for sequential pages that are hierarchical but make no sense for non hierarchical data/routes.

Services can force tracking into links by encoding the whole url into a shortlink that makes it impossible to just remove the tracking alone as everything is encoded into a shorter non editable string.

reply
Thank you for explaining to me that query parameters can be used for other purposes apart from tracking. The articles in question though, are railing against query parameters being abused for tracking purposes - passing referers (sic) and UTM by adding them to URLs of sites that neither process them, nor want them.
reply
Referral query strings are not for tracking though. The person putting them on the links gets nothing out of them. There is no PII being shared. They are purely added out of courtesy.

If I am handing out maps to your address, letting people know who is publishing the map is generally a good thing.

This is like saying having a return to sender address on mail is an invasion of privacy.

reply