Instance Level Analytics (with group level data)

Problem to solve

During customer conversations we have found that engineering and product teams can span multiple groups and projects. At the moment, most of our analytics are on a project level, which makes it very difficult for an EM / PM / Executive to get a sense of where the majority of effort is spent and understand cycle times and bottlenecks across teams (we have received similar feedback from @dhavens). Moreover, our analytics are dispersed across the tool and are not particularly easy to find. We have:

Analytics Type	Branch	Project	Group	Instance
Language Statistics	N	Y	N	N
Contributor Analytics	Y	Y	N	N
Contribution Analytics	N	N	Y	N
CI/CD Charts	N	Y	N	N
Cycle Analytics	N	Y	N	N
Insights	N	Y	Y	N
Coverage	N	Y	N	N
Operations Metrics/Dashboard	N	Y	Y	N
Issue Analytics	N	N	Y	N

Most of these analytics do not contribute to any actionable insights since they are at MVC stage and difficult to connect.

For example, executives would like to be able to have a single view of languages used across the instance (ex: https://gitlab.com/gitlab-org/gitlab-ce/issues/62294), compare productivity and velocity across teams, groups, projects, etc. Currently, managers at different levels of the organization are looking at different information, which is often inconsistently defined between teams and difficult to aggregate.

Intended users

Development Team Lead, Product Manager, Executive

Further details

Implementing analytics at an instance level will allow us to move forward with our vision for VSM and have one place for dashboards, which can be used by developers, managers and executives. Many customers have expressed interest in instance level analytics with customizable dashboards allowing users to drill-down in order to uncover actionable insights. (https://gitlab.com/gitlab-org/gitlab-ce/issues/48807)

Solution

Navigation

We add a new Analytics link to the top bar after Snippets and before the separator.

Empty state

When the user clicks on the Analytics link, they're taken to the Analytics dashboard. The sidebar contains the header (Analytics), and a single navigation item (Cycle Analytics).

The page presents an empty state for Cycle Analytics. The page contains:

• Cycle Analytics header.
• Search bar with a Choose a group primary button (small size). There is a timeframe dropdown next to the search bar.
• Recent activity panel with the empty state message:

Select a group above to get started

• Cycle Analytics panel, where the times have been replaced by -.

Choosing a group

When the user clicks the primary button, it is replaced by a Group token, and the group-selection dropdown opens up. This works the same way as the filters in Issues and Merge Requests. The user will need to click the magnifying glass button or press Enter in order for the search to take effect.

Populated

Once the user submits their search, the Group token is completed and the Cycle Analytics information populates.

Icons

We will use the following icons:

• icn/log for the sidebar header, Analytics.
• icn/repeat for Cycle Analytics.

Original Proposal

1. Given the size of instances like GitLab.com, our MVC here will be starting analytics on a group level.

2. A logged-in PM/EM, who is currently on an instance page, should have an easy navigation to an analytics page. @cperessini, after discussing with Eric and Jeremy, I think it's better to have it as Analytics on the top nav bar, just before the Ops Dashboard icon. We can work on combining with the admin dashboard at a later date. We can actually remove Snippets as no-one uses it and I am not aware of any marketing effort to make it an app important feature deserving space on the nav bar?

3. Given we are putting Analytics on the Nav Bar (in order not to confuse use with discoverability given the feature will move to instance level), let's have an easy way for a user to select a group he is interested in. We can potentially use our existing dropdown for Groups or the selection of projects feature on the Ops Dashboard for that? (cc: @cperessini, what do you think?)

4. Once the user clicks on 'Analytics', a page similar to the below would open and on the left we can have: Productivity Analytics and Cycle Analytics. Each page will have different charts that a user can save in the future as his private view (ex: https://gitlab.com/gitlab-org/gitlab-ee/issues/6019, https://gitlab.com/gitlab-org/gitlab-ce/issues/58435)

5. On the top of each page, we should have a 'global' dashboard filter by group (in the future, for the MVC not), project, milestone, author, assignee (as per your proposal here: https://gitlab.com/gitlab-org/gitlab-ce/issues/48807). I would suggest to have the data range filter separate on the top right like in your proposal but make it an actual calendar range, where people can select the timeframe with a date picker like this one (http://www.daterangepicker.com). The reason for that is that many companies want to look at longer timeframes as they don't release more often than once a month.

Old issues https://gitlab.com/gitlab-org/gitlab-ce/issues/29359 https://gitlab.com/gitlab-org/gitlab-ce/issues/28123

Permissions and Security

The dashboard should inherit the project/ groups permissions of users, i.e. I can only see an aggregation of subgroups, projects I have access to.

Documentation

Testing

What does success look like, and how can we measure that?

Measure: We should include the page in user ping to start with and measure how many people visit and how long they stay on it.

Success: As we develop this further, we expect users to spend a significant time deep diving on the page at least once a week.

Links / references