Open jon-betts opened 2 years ago
What resolution do we need to know this at? We could log every single login, but alternatively we could group logins by a user by day, week or semester etc.
If we did this it would bound the length of the table to time_periods * users
regardless of the number of individual logins. So for example at a semester resolution we'd only have two entries per user per year.
What do we need to know other than the user about the login? Do we need to know which group they logged into, or is the application instance enough?
If we include group, then our entries would rough bound would be time_periods * users * groups
rows.
Could we get the exact report people would like, and then see what's required to produce it? My feeling is we want to replace the "annotated in a group" as the mark of active for "logged into a group" in the Hubspot report.
If this was the case it would immediately answer some of the questions above:
However, if there are other requirements then we'd need to know them as 6 monthly might not be enough.
I need to rewrite this around the reports we'll use it for a la https://github.com/hypothesis/private-issues/issues/122 and its siblings.
Report on who and when users "sign into" the LMS app.
We bill by user. Today we define billable as signing in. This way we can charge for:
We need to be able to answer in near real-time questions like:
In the LMS context, we are currently happy using the app launch as sign-in.
Places where this data shows up:
Constraints
Notes
Related
Related to https://github.com/hypothesis/private-issues/issues/135
Related to https://github.com/hypothesis/private-issues/issues/128