The URL is meant to be a unique string to identify the location of a resource, it can have quite a bit of extra information encoded that only the server called knows what to do with, so its trivially possible to encode the URL of the resource a user wants to access into a completely different URL. The server at that location decodes the information and redirects the user to the location they are actually looking for.

This is why URL minifiers like tinyurl.com are considered harmful but much more impactful is googles amp project which is also noticed less.

I hope I understood you correctly.

Edit: to expand on the threat scenario you posted, a 3rd party can create a URL that goes to a server they control. Encoded in that string can be identifiers to see where/who a user got the link from and where they should be redirected to. When a user clicks that URL that information plus the standard metadata of a browser request get transmitted to the server. The server then can serve a webpage that reads and/or places cookies, calls some JavaScript function to phone more information about the user home and then redirects the user to the location that was encoded in the URL the user originally clicked.

See https://www.amiunique.org/ for more information on browser fingerprinting.

This is more noticeable to the user who might see a blank page for a split second before their browser processes the redirection request. A less noticeable option would be to send a redirection command instead of a webpage, the attacker still gets the browser metadata of the initial request plus any identifiers in the URL and the user might not notice since the only change visible to them is in the address bar of their browser. But the attacker can’t place cookies or read extra information of the browser.