I have an application which can be considered an LMS or portal. The application is used by a corporate training company and its users are employees from various companies.
I’m wondering how to put in place the following analytics:
List of learners who signed in, sorted by company with dates, times, duration of their last connection, and cumulative duration since the beginning.
List of most visited modules (with count) and most consulted by learner (duration).
List of learners that consulted “page XYZ”, who used the M1 and M2 features (number of clicks) on that page, and number of updates used.
Monthly table of updates consumed by learner
Some of these I could build, especially the use of features that entail a button click. But I don’t really see myself as being in the business of building analytics that will be wobbly (using a +1 increment to the Users table when a user clicks on a button feels improvised).
Can we track sign-ins per user: count, dates and times, session duration, path, duration per page?
To what extent could I rely on PostHog for some or all these stats (realistically)?
No idea on any of this since I have hardly ever configured analytics stuff in my apps. I recall they have duration, but not sure if they track to a screen level (or just a session level, though my experience was with Google Analytics like 3 years ago).
I would do as much as I can using button actions (that’s the clearest way though you might hate them).
This would be straightforward, except for perhaps AI stuff, where you have to take into account the difference in pricing between input and output tokens, recording them as they are sent/generated to calculate the “cost” of an AI-related action.
I’ve set up onboarding flows and then button clicks that remove these screens. I know these button clicks can dissimulate other actions such as incrementing counters or clearing data. I understand it, and I know that one is supposed to find creative solutions to get the job done.
But. I would prefer to avoid this for three reasons:
I prefer tracking a screen load than a button click to not mix UX with tracking. These are two different aspects in an app and I would prefer keeping them separate. Implementing a dependency by design doesn’t feel right.
Related to this, I don’t want to change the UX of the app for tracking purposes, and currently there is no onboarding flow. And there doesn’t need to be one.
And finally I don’t find tracking via actions all that easy to set up (in fact that’s why analytics companies exist, it’s tricky to track all this).
If an action is inside the app anyway, then sure it doesn’t hurt to add a click counter. But I’m loathe to have to build anything beyond that.
I’ll do some digging into what PostHog can achieve.
For user-only numbers, I’m putting them in the Users table.
For month-only numbers (YYYYMM), I’m thinking of putting them in a Monthly Numbers (YYYYMM) tables and incrementing values as users will be triggering actions.
Finally, for month and user numbers (for example “Number of clicks on abc button in yyyymm month by xyz user”), I’m thinking of creating a joint “YYYYMM - User ID” table and incrementing values in there.
That sounds kind of ok, as long as you’re adding rows in advance for the month-only numbers, and add new rows for the month and users table when there’s a new user.
Though, yeah, for these kind of stuff, it’s complex to set everything up.
