Design exploration for a user activity dashboard
Problem to solve
We use the Cohorts page in GitLab as a way for users to better understand user activity on their instance. Gaining insight into how active users are in GitLab is a great goal, but Cohorts doesn't fully realize this.
- The retention information we present there isn't particularly useful or actionable. While it's interesting that retention in an older cohort of users may be higher or lower, this doesn't help me understand what I should be doing about it - or if it even matters.
- The way we're presenting the information is hard to parse. We present a table of data that takes some scrutiny to understand, and we should make this as easy as we can on our users.
We also suffer from this information not always being accurate, and should consider how we can improve this page and better solve these problems for GitLab users.
The Cohorts page focuses on historical cohorts of users, and their activity over time. Instead, we should consider how we can provide insight into the activity/engagement levels of an instance's userbase now. Ideally, this page should help an instance administrator answer questions like:
- Am I using my licensed seats effectively?
- Are there users on my instance who have a low level of activity, and who I could consider cutting?
- Are there users on my instance who are heavy users of GitLab? Who are they?
- How does user engagement on my instance compare to other instances?
- For an admin, how does my current level of user engagement relate to my licensed seat count?
The questions here should stop short of what's provided in Contribution Analytics. This analytics board, which I'm thinking of as "Activity Analytics", is showcasing insights on user activity at a high level. For further detail on what, specifically, users are doing, Contribution Analytics should be the source to go a level deeper.
We should be able to answer these questions with the attributes we currently have on
created_at: when the user was created
last_sign_in_at: previous time the user signed into the web interface, might be
last_activity_on: last recorded activity for the user, including git activity
current_sign_in_at: updated each time the user logs into the web interface
Refactor the current Cohorts page into Activity Analytics. Help instances answer the questions above. Initial example:
What does success look like, and how can we measure that?
- Increased engagement with activity analytics vs. cohorts page.