[efromvt]

If you don't have a backend, then it's all telemetry, right? And backend logs don't capture a lot of the UX side of things - how a call got triggered, from where, etc (which yeah you can start to instrument, but then that's telemetry).

[skydhash]

I would say: Never solve problems for people you don’t know. First solve for yourself. Then solve for people in your community. Someone reaching out with a suggestion is more valuable than bazillion of analytics.

[efromvt]

Very much in agreement with this but especially on the UX side I find that 'what is intuitive to me' is not universal because you come with a bunch of contextual priors you can't clear. I wish there was more tooling focused on how to use tools to expand customer empathy past what you can directly experience; that's an inherently audience-limiting approach.

(I admire PMs that can cross that chasm; it's also why they're often bad at infra tooling, because you can just short-circuit the empathy).

[sublinear]

I agree, but my point was there are too many sedimentary layers of vocabulary put there by the marketing and checklist people. If they didn't obscure and paywall basic functionality, they wouldn't have a business.

In my example (assuming a web view, but similar mechanisms exist for native), the event wrapper would give a lot of context if the event target string is logged. That will contain the query selector. It should already be best practice to have unique and human-readable IDs on every interactive element in the DOM anyway.

Sloppy frontend builds are a topic for another time, though.

If there's no server, you should at least still proxy these logs to your own domain. The vast majority of sites are just pasting a generated script tag or cluttering their build. The "right way" is just as easy.