anyone knows if something like this is already possible?
As app builder/admin I have very limited visibility to which part of my app are being used by users. (my developer has made a basic page view tracker). Given how plug&play the editor in bubble is I would assume it could be amazing to add to every item/workflow step etc a use count. show the total use, use last 24hr, last month or something like that. And you access it directly in the editor with each item.
Then as app builder I have instant insights on what users trigger. eg which workflow steps are being triggered, how often buttons are pushed, how often pages are loaded etc.
This could also be great as a next step to build a warning system. eg I could create conditional warnings that signal about my app performance. For example if a new user is invited but no email send. Or a page is loaded but the visibility of the items are less. etc. Then I get much earlier signals that part of the app is now performing instead of needing to wait till a user reports an issue (we do test our changes, but it isn’t perfect…)
thanks Animisha!
I know the App metrics section. as far as I see its only basic/generic things like page load times or number of workload units run.
if it is part of the editor mode you can bake it into your development. and it becomes part of how you build in bubble. when you build something you immediately set the guardrails how you expect it to perform and when you want to get triggered.
a very small example: our password reset process broke down at one point (cant remember how). and we found out quite late based on user reports. if I had a trigger that would warn me as soon as the number of times the button was pressed didn’t match the number of emails send then I could act much faster on bugs. and apps always have bugs…
Use something like GA4 and tag manager to put analytics in app actions. This way you can see trends and therefore spot issues when you have enough traffic. This will not cost Workflow Units which might be a big plus depending on your pockets and use case.
Another good idea is to have error emails on important workflows that will send an email with detailed error logs to someone who can fix it. An example could be a workflow with an api call. Send an email when this call returns an error.
