Note: Data Team KPI development starts with a handbook Merge Request describing the KPI. The Data Team will use the MR as the basis for an Issue, which will be used to track development progress and presentation in the Data Team KPI Issue Board.
KPIs require varying amounts of data discovery and development prior to final release into the handbook with an automated KPI dashboard. Given a clear business definition and available data, KPIs can be developed and published quickly. Others may take weeks or months if the business definition is not clear, targets are not defined, or data infrastructure is not in place. In general, KPIs which cross functional boundaries, cross subject matter boundaries, uncover source data quality problems, or require new data infrastructure are the most expensive and time consuming to implement.
The CFO will notify investors and relevant external parties if the following KPIs are changed:
OKRs are what initiatives are being worked on in a quarter; things that happen every quarter are measured with KPIs. If you change a KPI, consider making it an OKR.
There are two goals that are tracked on this page:
The goal of Phase 1 is for each KPI to be operational in any system with a link to that data visualization or as an embedded chart in the handbook.
The goal of Phase 2 is to embed a Sisense chart for each KPI that can be operationalized. KPI must be fully defined with the data source available in the Data warehouse for the Data Team to prioritize the KPI. This dashboard shares the progress of operationalizing KPIs in Sisense:
The icons below are relevant for Phase 1 and can be assigned by anyone at GitLab.
📊 indicates that the KPI is operational and is embedded in the handbook next to the definition and shown publicly (can be Sisense or another system).
🔗 indicates that the KPI is operational and there is a link from the handbook to Sisense, GitLab, Bitergia, Grafana, or another system. This may be because the KPI cannot be public or because it isn't possible to embed it yet.
🚧 indicates that the KPI is in a
WIP: work in progress status estimated to be shipped in any system within the month. When using this indicator, an issue should also be linked from this page.
🐔 indicates that the KPI is unlikely to be operationalized in the near term.
GitLab KPIs are duplicates of goals of the reports further down this page. GitLab KPIs are the most important indicators of company performance, and the most important KPI is IACV.
We share a spreadsheet with investors called "GitLab Metrics." The GitLab Metrics Sheet should be a subset of the KPIs listed on this page. Alternatively, the sheet may show variations or subsets of one of those KPIs, such as showing all licensed users and then licensed users by product.
We do satisfaction scope on a scale of 1 to 5 how satisfied people are with the experience. We don’t use NPS since that cuts off certain scores and we want to preserve fidelity. We have the following abbreviation letter before SAT, please don’t use SAT without letter before to specify it:
Since we track retention in a lot of ways, we should never refer to just "Retention" without indicating what kind of retention. We track:
Please see the Data Team Handbook.