Hacker News Reader

Comment by zamalek | Hacker News Reader

I don't understand why we have to store the entire dataset in the URL, when something like ?utm_id=1 (mapped to the others in some database) would do. It's stuff like this that prevents average users from "getting" URLs; they don't know what UTM is and assume it is important to get to the information.

This garbage breaks the UX of the internet.

View on HN

You don't have to; GA actually does support precisely the scenario you're proposing - you can use a random campaign key/identifier in a utm_id field, and upload a custom dataset mapping to GA that contains the details to map to the other utm fields. This[1] support article walks through the process.

You just rarely ever see it because marketing execution is already an operational nightmare at most places (even more so at scale), and the centralized coordination required to leverage the campaign key method introduces a lot of friction, overhead, and potential bottlenecks into processes with little perceived gain. The decentralized model (i.e. entire dataset in the url) is far easier to enforce compliance with between all parties, as you can providing tooling (i.e. a link builder spreadsheet) that allows each party to integrate the usage into their workflows with minimal overhead or ongoing coordination required.

[1] https://support.google.com/analytics/answer/6066741?hl=en

Thanks for the explanation. This really does makes sense.

One other thing to note is that there are a few alternatives which tend to be a bit more feasible to implement (and sustain). Namely, using a single campaign key but leverage an encoding scheme for the key/id rather than a randomly generated one. That way it can be parsed at collection time and every permutation doesn't have to be predefined in a dataset ahead of time. Then end users can still self-service link creation with a template provided to them (they input the usual utm parameters they're used to, but it spits out a link with a single encoded key).

Then on the receiving end, you use lookup tables or functions to decode the various aspects of the key, and explicitly define the relevant utm parameters in the call to Google Analytics (which it natively supports as an alternative to implicitly sniffing them from the URL string). Or if your encoding scheme is simple enough, you can send the key directly to GA and use Advanced custom filters[1] to decode the utm parameters there.

[1] https://support.google.com/analytics/answer/1033162?hl=en

I've implemented this approach for my teams before. It's always a giant PITA without lots of effort around tooling to enforce conventions. It's useful though if you're trying to marry analytics tools without reinventing the wheel though because you can take out of the box UTMs and just transform them into some intelligible encoded format that first into some other tool's sole field for user-defined data.

Web analytics as a whole is a giant PITA without lots of effort around tooling. The default approach just has a silent failure state that is harder to detect, and becomes more of a hassle for the analyst that has to cope with the resulting data.

At least with this approach, the PITA becomes more explicit and easier to justify the tooling needs, allowing for it to be addressed and tackled at the outset by the upstream implementation team, rather than cascading to downstream consumers.

There is no need to, but doing it with id numbers would add a lot of friction on the content creator's side so that's why it isn't like that. The 'some database' is the problem - who owns it?

Right now I can add whatever UTM parameters to any links I send without keying it into a database system, submitting a CR to the IT team, submitting it to Google, or any other nonsense. Details will be collected immediately whether through web logs, google analytics, or something else.

If one email that I send has links to multiple domains (some of which I don't control due to SaaS eating the web) then we'd either have to track and manage multiple IDs which change for each link or use a scary looking GUID generated by a centralised system (no thanks). That sounds like a real headache.

Hiding it behind an ID would make it prettier but it also reduces transparency to the end user of what is being collected. I think if it's going to be there anyway, I'd rather see it.

Thank you for explaining the verbosity in more detail.

Most browsers are switching to hiding the full page url from the user anyhow, so although the parameters are making the url ugly, it's not exactly breaking the UX.

The url is not the UX anymore.

This is why building "the obvious next steps" [1] is such an important concept. This is also why apps like Facebook or Pinterest have been so successful. Within this new UX, users are not looking to leave, they just want to find more information that is relevant to them.

[1] https://www.gkogan.co/blog/ridiculously-obvious-next-step/

Reply on news.ycombinator.com