Principles - Processes - Categorization - GitLab the Product - Being a PM - Performance Indicators - Leadership
| KPI | Health | Status |
|---|---|---|
| Total Monthly Active Users (TMAU) | Unknown |
|
| Paid Total Monthly Active Users (Paid TMAU) | Unknown |
|
| Monthly Active Users (MAU) | Attention |
|
| Direct signup ARR growth rate | Attention |
|
| Free to paid ARR growth rate | Attention |
|
| Net Retention | Attention |
|
| Gross Retention | Okay |
|
| Stages per User (SpU) | Attention |
|
| Category Maturity Achievement | Attention |
|
| Paid Net Promoter Score (PNPS) | Attention |
|
| Active Hosts | Okay |
|
| New hire location factor | Attention |
|
| Refunds processed as % of orders | Attention |
|
| Acquisition impact | Okay |
|
The sum of all stage monthly active users (SMAU) in a rolling 28 day period. Numbers displayed below for self-managed are for instances with usage ping (enabled). Owner of this KPI is the VP, Product Management.
Chart (Sisense↗)
Status: Unknown
The sum of all paid stage monthly active users in a 28 day rolling period. The license information used to generate this metric is being validated, and the currently displayed data could be incorrect by up to 20%. Numbers displayed below for self-managed are for instances with usage ping (enabled) Owner of this KPI is the VP, Product Management.
Chart (Sisense↗)
Status: Unknown
The number of unique users that performed an event within the previous 28 days. Owner of this KPI is the VP, Product Management.
Chart (Sisense↗)
Status: Attention
Direct signup ARR growth rate is calculated by measuring the difference in actual signup ARR between two consecutive periods (current and prior) and dividing that number by the direct signup ARR of the prior period. Owner of this KPI is the Growth - Acquisition group. The calculation for this metric is (Direct signup ARR in the current period - direct signup revenue in the prior period)/direct signup revenue in the prior period.
This KPI cannot be public.
URL(s)
Status: Attention
Free to Paid ARR growth rate is calculated by measuring the difference in actual free to paid ARR between two consecutive periods (current and prior) and dividing that number by the free to paid ARR of the prior period. Owner of this KPI is the Growth - Conversion group. The calculation for this metric is (Free to paid signup ARR in the current period - free to paid signup revenue in the prior period) / free to paid signup ARR in the prior period
This KPI cannot be public.
URL(s)
Status: Attention
This is a subset of an existing KPI. Please see the definition for the parent KPI.
Owner of this KPI is the Growth - Expansion group.
Target: Our Target net retention rate is 180%.
This KPI cannot be public.
URL(s)
Status: Attention
This is a subset of an existing KPI. Please see the definition for the parent KPI.
Owner of this KPI is the Growth - Retention group.
Target: Our Target gross retention rate is 90%.
This KPI cannot be public.
URL(s)
Status: Okay
Stages per user is calculated by dividing Stage Monthly Active User (SMAU) by Monthly Active Users (MAU). The Stages per User (SpU) KPI is meant to capture the number of DevOps stages the average user is using on a monthly basis. Owner of this KPI is the VP, Product Management.
Target: Our Target SpU is 1.8.
Chart (Sisense↗)
Status: Attention
Percentage of category maturity plan achieved per quarter. Owner of this KPI is the VP, Product Management.
Target: Our Target is 70%.
Status: Attention
Abbreviated as the PNPS acronym, please do not refer to it as NPS to prevent confusion. Measured as the percentage of paid customer "promoters" minus the percentage of paid customer "detractors" from a Net Promoter Score survey. Note that while other teams at GitLab use a satisfaction score, we have chosen to use PNPS in this case so it is easier to benchmark versus other like companies. Also note that the score will likely reflect customer satisfaction beyond the product itself, as customers will grade us on the total customer experience, including support, documentation, billing, etc. Owner of this KPI is Product Operations.
Target: Our Target PNPS is 40.
URL(s)
Status: Attention
The count of active Self Hosts, Core and Paid, plus GitLab.com. Owner of this KPI is VP, Product Management. This is measured by counting the number of unique GitLab instances that send us usage ping. We know from a previous analysis that only ~30% of licensed instances send us usage ping at least once a month.
Chart (Sisense↗)
Status: Okay
This is a subset of an existing KPI. Please see the definition for the parent KPI.
Target: Our Target is 0.72.
Chart (Sisense↗)
Status: Attention
For a month take the number of refunds and divide that by the total amount of orders (including self-managed and sales initiated orders). More details available here
URL(s)
Chart (Sisense↗)
Status: Attention
Acquisition impact measures the number of maturity levels advanced, as a result of acquisitions. The target is 3 per year.
Target: 3 per year
Status: Okay
Stage Monthly Active Users is required for all product stages. SMAU is defined as the specified AMAU within a stage in a 28 day rolling period. Owner of this KPI is the VP, Product Management.
Chart (Sisense↗)
Status: Attention
Paid Stage Monthly Active Users is required for all product stages. Paid SMAU is defined as the count of SMAU (Stage Monthly Active Users) that roll up to paid accounts in a 28 day rolling period. The license information used to generate this metric is being validated, and the currently displayed data could be incorrect by up to 20%. Numbers displayed below for self-managed are for instances with usage ping (enabled) . Owner of this KPI is the VP, Product Management.
Target: TBD
Chart (Sisense↗)
Status: Unknown
In categories where there is not a directly applicable SMAU metric as the category is focused on protecting our customer's customer, other metrics need to be reviewed and applied. An example of a group where this applies is [Defend's Container Security group](/handbook/product/product-categories/#container-security-group) where their categories are designed to protect our customers and by extension their customers who are actively interacting with our customer's production / operations environment. Metrics such as stage monthly active clusters (SMAC) can be used in place of SMAU until it is possible to achieve an accurate metric of true SMAU which may include measurements of monthly active sessions into the customer's clusters.
Target: TBD
Status: Unknown
GMAU is defined as the count of unique users who performed a particular action, or set of actions, within a group in a 28 day rolling period. Each R&D group is expected to have a primary performance indicator they are using to gauge the impact of their group on customer outcomes. Where possible, groups should use Group Monthly Active Users (GMAU) or Group Monthly Active Paid Users (GMAPU) as their primary performance indicator. GMAU should be used when the group is early in its maturity and its primary goal is new user adoption. Paid GMAU should be the primary performance indicator when groups are more mature and have proven an ability to drive incremental IACV. We prefer measuring monthly active usage over other potential measures like total actions taken (eg total dashboard views), as we believe that measuring active usage is a better measure of true user engagement with GitLab's product. Since R&D groups often contain more than one category, picking one category to base the action, or set of actions on, is a recommended simplification as we do not have the data bandwidth to support measuring every category's usage at this time.
Target: TBD
Status: Unknown
Paid GMAU is defined as the count of GMAU (Group Monthly Active Users) that roll up to paid accounts in a 28 day rolling period. When Paid GMAU is the focus area for a group, they should measure actions tied to`Up-tiered features`, which are features that are unavailable in the free tier, as this will ensure we are tracking usage that has a clear tie to incremental IACV.
Target: TBD
Status: Unknown
An action describes an interaction the user has within a stage. The actions that need to be tracked have to be pre-defined. AMAU is defined as the number of unique users for a specific action in a 28 day rolling period. AMAU helps to measure the success of features. Note - There are metrics in usage ping under usage activity by stage that are not user actions and these should not be used for AMAU. Examples include Groups - `GroupMember.distinct_count_by(user_id)`, which is the number of distinct users added to groups, regardless of activity, ldap_group_links - `count(LdapGroupLink)`, which is a count of ldap group links and not a user initiated action, and projects_with_packages - `Project.with_packages.distinct_count_by(creator_id)`, which is a setting not an action.
Target: TBD
Status: Unknown
A GitLab.com user, who is not a MAU in month T, but was a MAU in month T-1.
Target: TBD
URL(s)
Status: Unknown
A GitLab.com user, who is a MAU both in months T and T-1.
Target: TBD
URL(s)
Status: Unknown
A GitLab.com Licensed User.
Target: TBD
URL(s)
Status: Unknown
Target: TBD
URL(s)
Status: Unknown
A GitLab Group, which contains at least 1 project since inception and has at least 1 Event in a calendar month.
Target: TBD
URL(s)
Status: Unknown
A GitLab.com group, which is not a MAG in month T, but was a MAG in month T-1.
Target: TBD
URL(s)
Status: Unknown
A GitLab.com namespace both in months T and T-1.
Target: TBD
URL(s)
Status: Unknown
A GitLab.com namespace created in the last 30 days.
Target: TBD
URL(s)
Status: Unknown
A GitLab.com namespace, which is part of a paid plan, i.e. Bronze, Silver or Gold. Free licenses for Ultimate and Gold are currently included.
Target: TBD
URL(s)
Status: Unknown
Target: TBD
URL(s)
Status: Unknown
This is the conversion rate of customers moving from tier to tier
Target: TBD
URL(s)
Status: Unknown
A lost instance of self-managed GitLab didn't send a usage ping in the given month but it was active in the previous month
Target: TBD
URL(s)
Status: Unknown
Percent of users or groups that are still active between the current month and the prior month.
Target: TBD
URL(s)
Status: Unknown
The opposite of User Return Rate. The percentage of users or groups that are no longer active in the current month, but were active in the prior month.
Target: TBD
Status: Unknown
Stage Monthly Active Namespaces is a KPI that is required for all product stages. SMAN is defined as the highest AMAN within a stage in a 28 day rolling period.
Target: TBD
Status: Unknown
AMAN is defined as the number of unique namespaces in which that action was performed in a 28 day rolling period.
Target: TBD
Status: Unknown
Acquisition success measures how successful GitLab at integrating the new teams and technologies acquired. An acquisition is a success if it ships 70% of the acquired company's product functionality as part of GitLab within three months after acquisition. The acquisition success rate is the percentage of acquired companies that were successful. The target is 70% success rate.
Target: TBD
URL(s)
Status: Unknown
The sourced pipeline includes companies operating in a DevOps segment relevant for GitLab. Companies have developed or are working on product functionality which is either a new category on our roadmap or at a more advanced maturity than our current categories. Target is ongoing monitoring of at least 1000 companies.
Target: TBD
Status: Unknown
| Value | Level | Meaning |
|---|---|---|
| 3 | Okay | The KPI is at an acceptable level compared to the threshold |
| 2 | Attention | This is a blip, or we’re going to watch it, or we just need to enact a proven intervention |
| 1 | Problem | We'll prioritize our efforts here |
| 0 | Unknown | Unknown |
| Value | Level | Meaning |
|---|---|---|
| 3 | Okay | We are correctly capturing and measuring data for GitLab.com and self-managed instances. |
| 2 | Attention | Missing one of: GitLab.com or self-managed data. |
| 1 | Problem | Missing both: GitLab.com and self-managed data. |
| 0 | Unknown | Unknown |
Pages, such as the Engineering Function Performance Indicators page are rendered by an ERB template that contains HTML code.
Other PI Pages sectionThese ERB templates calls custom helper functions that extract and transform data from the Performance Indicators data file.
kpi_list_by_org(org) helper function takes a required string argument named org (deparment or division level) that returns all the KPIs (pi.is_key == true) for a specific organization grouping (pi.org == org) from the Performance Indicators data file.pi_maturity_level(performance_indicator) helper function automatically assigns a maturity level based on the availability of certain data properties for a particular PI.pi_maturity_reasons(performance_indicator) helper function returns a reason for a PI maturity based on other data properties.performance_indicator_target(name) helper function returns the target value from the target property for a specific PI from the Performance Indicators data file.performance_indicators(org) takes a required string argument named org (deparment or division level) that returns two lists - a list of all KPIs and a list of all PIs for a specific organization grouping (department/division).signed_periscope_url(data) takes in the sisense_data property information from the Performance Indicators data file and returns a signed chart URL for embedding a Sisense chart into the handbook.The heart of pages like this is the Performance Indicators data file which is in YAML file. Each - denotes a dictionary of values for a new (K)PI. The current elements (or data properties) are:
| Property | Type | Description |
|---|---|---|
name |
Required | String value of the name of the (K)PI |
base_path |
Required | Relative path to the performance indicator page that this (K)PI should live on |
definition |
Required | refer to Parts of a KPI |
parent |
Optional | should be used when a (K)PI is a subset of another PI. For example, we might care about Hiring vs Plan at the company level. The child would be the division and department levels, which would have the parent flag. |
target |
Required | The target or cap for the (K)PI. Please use Unknown until we reach maturity level 2 if this is not yet defined. |
org |
Required | the organizational grouping (Ex: Engineering Function or Development Department) |
is_key |
Required | boolean value (true/false) that indicates if it is a (key) performance indicator |
health |
Required | has two additional elements/property - level (inclusive value between 0-3) and reasons. This should be updated monthly before Key Meetings by the DRI. |
urls |
Optional | list of urls associated with the (K)PI |
sisense_data |
Optional | contains elements/properties related to Sisense, including chart (numeric Sisense widget ID), dashboard (numeric Sisense dashboard ID), shared_dashboard (Sisense shared dashboard ID), embed (v2) |
public |
Optional | boolean flag that can be set to false where a (K)PI does not meet the public guidelines. |
instrumentation |
Optional | has two additional elements/property - level (inclusive value between 0-3) and reasons. This should be updated monthly before Key Meetings by the DRI. |
shared_dashboard, chart , and the dashboard key-value pairs to the Performance Indicators data file under the sisense_data property: in strings as it's an important character in YAML and will confuse the data parsing process. Put the string in "quotes" if you really need to use a :urls: should be an array (indented lines starting with dashes) even if you only have one urlmaturity.level and health.level display a value between 0 and 3 (inclusive).