So add telemetry and a request tracker like https://www.productboard.com/. This is not a solo vs team thing.
I don't really need to know how many people use the app. It would be cool to know, but not necessary.
If someone wants a feature, or a fix, they can open an issue.
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 sending those logs back to your server?
That's not even scratching the surface, but even something this simple and easy to implement is already miles ahead of most free-tier telemetry offerings, and you retain full control.
(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).
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.