Earlier quoted context omitted.
Most projects don't need telemetry. They need better logs. On the backend... Why wouldn't you log every request that hits your server, and why wouldn't you already know what those requests mean? Why would you let your frontend make direct requests to any other server when you can just proxy it yourself and maintain control? On the frontend... What's so hard about wrapping all your event listeners and periodically sen…
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).
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.