### 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](https://gitlab.com/gitlab-org/gitlab-ce/graphs/master/charts) | N | Y | N | N | | [Contributor Analytics](https://gitlab.com/gitlab-org/gitlab-ce/graphs/master) | Y | Y | N | N | | [Contribution Analytics](https://gitlab.com/groups/gitlab-org/-/analytics) | N | N | Y | N | | [CI/CD Charts](https://gitlab.com/gitlab-org/gitlab-ce/pipelines/charts) | N | Y | N | N | | [Cycle Analytics](https://gitlab.com/gitlab-org/gitlab-ce/cycle_analytics) | N | Y | N | N | | [Insights](https://gitlab.com/gitlab-org/gitlab-ce/insights) | N | Y | Y | N | | [Coverage](https://gitlab.com/gitlab-org/gitlab-ee) | N | Y | N | N | | Operations Metrics/Dashboard | N | [Y](https://docs.gitlab.com/ee/user/operations_dashboard/) | [Y](https://gitlab.com/gitlab-org/gitlab-ce/environments/11480/metrics) | N | | [Issue Analytics](https://gitlab.com/groups/gitlab-org/-/issues_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`](https://gitlab.com/gitlab-org/gitlab-ce/issues/62385) and [`Cycle Analytics`](https://gitlab.com/gitlab-org/gitlab-ce/issues/45304). 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 <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> 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 <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> 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 <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->