| A | B | C | D | |
|---|---|---|---|---|
1 | Name | Description | Target | Category |
2 | Sales Pipeline Coverage | Net ARR of pipeline with close dates in a given period (quarter) divided by Net ARR target. | On day five of the current quarter, total pipeline coverage should be 2.4X, total pipeline for the following quarter should be 2.2X, and total pipeline for 2 quarters out should be 1.0X. On day five of the current quarter, stage 3+ pipeline coverage should be 1.5X and stage 3+ pipeline for the following quarter should be 0.8X. | Sales KPIs |
3 | Sales Capacity | Deployed street capacity (Sales quota) / company Net ARR Financial Target | greater than 100% | Sales KPIs |
4 | ProServe Deal and Dollar Attach Rate | Deal Attach Rate is the number of Professional Services closed won opportunities divided by the number of total closed won opportunities during a given month (by opportunity close date). Dollar Attach Rate is the Professional Services Value of closed won opportunities divided by the Net ARR of closed won opportunities during a given month (by opportunity close date). | 13% for Deal Attach Rate, 6% for Dollar Attach Rate | Sales KPIs |
5 | Net ARR vs Plan | The year-to-date cumulative sum of Net ARR divided by the year-to-date plan for Net ARR. Details on Net ARR can be found in the sales handbook page. | greater than 1 | Sales KPIs |
6 | New Logos | Count of new customers by month (excluding SMB) | Monthly targets set by Sales & Marketing | Sales KPIs |
7 | Channel Sourced Net ARR | Sum of Net ARR from opportunities that are channel sourced (where sales_qualified_source = 'Channel Generated'). | Monthly targets set by Sales & Finance | Sales KPIs |
8 | ARPU | The number of contracted users on active paid subscriptions. Excludes OSS, Education, Core and other non-paid users. The data source is Zuora. | 1.5% increase per month | Sales KPIs |
9 | Percent of Ramped Reps at or Above Quota | A Rep is considered ramped if their tenure in a particular role is more than the duration of their assigned quota ramp schedule. The percentage of attainment calculation is the net ARR from closed won opportunities in a particular month divided by the quota. Industry average is 45%-65% of reps achieving 100% of quota. Details on quota ramp schedule can be found in the sales handbook page. | greater than 55% | Sales KPIs |
10 | Percent of Ramping Reps at or Above 70% of Quota | A Rep is considered ramping if their tenure in a particular role is less than the duration of their assigned quota ramp schedule. The percentage of attainment calculation is the net ARR from closed won opportunities in a particular month divided by the quota. Details on quota ramp schedule can be found in the sales handbook page. | greater than 70% | Sales KPIs |
11 | Churn and Contraction / ATR | Sum of Net ARR of Churn and Contraction Opportunities (where order type = Contraction, Churn Partial, or Churn Full) divided by the amount of Net ARR that was available to renew in a specified time period (sum of ARR Basis of opportunities with renewal dates in specified time period) | Quarterly target set by Sales & Finance | Sales KPIs |
12 | Net Retention | Net Retention Calculation is extensively explained in the Customer Success's Vision page. | Above 145% | Sales KPIs |
13 | CAC Ratio | Sales and Marketing expenses (including the cost of free users of gitlab.com) over trailing twelve months divided by rolling three months ARR minus ARR from the same period in the prior year multiplied by four (for four quarters in the year). Details on CAC can be found in the sales handbook page. | Monthly target set by Finance | Sales KPIs |
14 | Net New Business Pipeline Created | The combined IACV of the net "New Business" opportunities. This data comes from a sheetload file. | vs Plan > 1 | Marketing KPIs |
15 | Pipe-to-spend per marketing activity | Pipeline (IACV on Opportunities) divided by the total marketing program spend, broken down by marketing activity. | 5 | Marketing KPIs |
16 | Marketing efficiency ratio | Marketing efficiency for a given month is calculated as the ratio of IACV from closed won opportunities for the current month and the 2 preceding months vs the Marketing Operating Expenses (IACV / Marketing Operating Expenses) for the same time period. GitLab's target is greater than 2. | 2 | Marketing KPIs |
17 | Opportunities per XDR per month created | The net number of unique opportunities that are created and have a "sales development representative" assigned/attached to the opportunity segmented by xDR and by month. This data comes from Salesforce. | TBD | Marketing KPIs |
18 | LTV / CAC ratio | The customer Life-Time Value to Customer Acquisition Cost ratio LTV:CAC measures the relationship between the lifetime value of a customer and the cost of acquiring that customer. A good LTV to CAC ratio is considered to be > 3.0. | greater than 3.0 | Marketing KPIs |
19 | Social Media Followers | Follower growth across social channels is a good indicator or resonating with a wider audience or deeply connecting within a niche. Follower growth is defined as all net-new followers, across all GitLab-branded social media channels in a given period. This KPI is tracked by exporting reports and data from our social media management tool, Sprout Social. This data is then manually ingested into Sisense via a formatted Google Sheet. This KPI will evolve further as more data becomes available. | 0 | Marketing KPIs |
20 | New Unique Web Visitors (about.gitlab.com) | New Users in Google Analytics, or the number of first-time users during the selected date range. Note, there is ongoing work in finalizing this KPI chart in Sisense (WIP); please reference the DataStudio chart, which is also accessible by the url below | Marketing KPIs | |
21 | Total Web Sessions (about.gitlab.com) | Total number of sessions in Google Analytics within the selected date range. These are visits to the web site that may include multiple pages. Note,there is ongoing work in finalizing this KPI chart in Sisense (WIP); please reference the DataStudio chart, which is also accessible by the url below | Marketing KPIs | |
22 | New hire location factor - Marketing | This is a subset of an existing KPI. Please see the definition for the parent KPI. The average location factor of all newly hired team members within the last rolling 3 month as of the end of the period. (eg. If the current month is 2019-09-01 then the calculation pulls months 2019-06-01 to 2019-08-31). Each division and department has their own new hire location factor target. | < 0.72 | Marketing KPIs |
23 | Pipeline coverage | IACV of pipeline with close dates in a given period (quarter) divided by IACV target. | On day one of the current quarter, total pipeline coverage should be 2.2X, total pipeline for the following quarter should be 1.8X, and total pipeline for 2 quarters out should be 1.0X. On day one of the current quarter, stage 3+ pipeline coverage should be 1.5X, stage 3+ pipeline for the following quarter should be 1.0X, and stage 3+ pipeline for 2 quarters out should be 0.5X. | Marketing KPIs |
24 | Lead follow-up response time | The amount of time (Days, hours, minutes) it takes for a Lead/Contact to move from MQL to another status - this indicates how long it took for a sales rep/xDR to respond to the record becoming a MQL. | Marketing KPIs | |
25 | Qty. of Case Studies published per month | The amount of time (Days, hours, minutes) it takes for a Lead/Contact to move from MQL to another status - this indicates how long it took for a sales rep/xDR to respond to the record becoming a MQL. | Marketing KPIs | |
26 | 50% or more SOV compared to most published competitor | The comparison of the GitLab share of voice (SOV) percentage to most published competitors’ SOV percentage. SOV is the number of media mentions compared to the media mentions received by a competitor and then the percentage is calculated out of 100%. The SOV percentages are tracked via a media service called TrendKite by our PR agency. | greater than 50% | Marketing KPIs |
27 | Increase partner focused media coverage by 25% in FY21 | The amount of media coverage/articles focused on partner and channel related topics in FY21 compared to FY20. Increasing the percentage of coverage increases GitLab’s brand awareness on the specific topic. | greater than 25% in FY21 | Marketing KPIs |
28 | Increase amount of remote work focused media coverage by 50% in FY21 over FY20 | The amount of media coverage/articles focused on remote work topics in FY21 compared to FY20. Increasing the percentage of coverage increases GitLab’s brand awareness on the specific topic. | greater than 50% in FY21 over FY20 | Marketing KPIs |
29 | Total number of MQLs by month | Total number of Marketo Qualified Leads per month. This data comes from a sheetload file. | TBD | Marketing KPIs |
30 | Product Downloads | Total downloads by installation method (Omnibus, Cloud native helm chart, Source, etc). This chart is populated with the versions.gitlab.com data. | TBD | Marketing KPIs |
31 | Meetups per month | A GitLab Meetup is defined as a meetup with a presentation given by a GitLab team member or a wider community member about GitLab or a tangential topic. It does not include meetups without GitLab content where GitLab only provides support. This KPI is tracked by counting the number of issues in the GitLab.com data with the Meetups label in the Marketing group. | 20 | Community Relations Department KPIs |
32 | Wider Community merged MRs per release | The Wider community contributions per milestone metric reflects the number of merge requests (MRs) merged from the wider GitLab community for each milestone from our GitLab.com data. To count as a contribution the MR must have been merged, have the Community contribution label, have a GitLab milestone set (e.g 11.11, 12.0, etc.) and be against one of the monitored gitlab-org group projects. | 500 | Community Relations Department KPIs |
33 | Developer Evangelism Monthly Impressions | The Developer Evangelism team aims to build thought leadership accross several mediums, primarily through content while exploring various other means. We track impressions of content generated to understand the reach of the generated content, currently we are tracking Twitter impressions, while exploring ways to track other mediums in subsequent iterations. | 600000 | Community Relations Department KPIs |
34 | GitLab for Education Quarterly Active Seats | The GitLab for Education team aims to facilitate and drive adoption of GitLab at educational institutions around the world and build an engaged community of GitLab Evangelists in the next generation of the workforce. We track the number of active seats in the GitLab for Education Program on a quarterly basis as a gauge of program enrollment and rentention. The number of active seats is determied by the number of seats from New Business, Add-ons, and Renewals. | 1000000 | Community Relations Department KPIs |
35 | Diversity - Women at GitLab | This is calculated as the percent of team members that identify as women through the EEOC Survey on the last day of the calendar month. | We aim for a target of 40% | People Success KPIs |
36 | Diversity - Women in Management | This is calculated as the number of women who are people managers at GitLab, at all levels of our org structure, divided by the the total numbers of people managers at GitLab, at all levels of our org structure, on the last day of the calendar month. It is measured as the percent of women in BambooHR with a Job Grade of 8+ and have at least one direct report. | We aim for women to be 40% of management | People Success KPIs |
37 | Diversity - Underrepresented Ethnicity | This is calculated as the number of underrepresented ethnicity team members that are at GitLab | We aim for 30% of team members to be from an underrepresented ethnicity. | People Success KPIs |
38 | Diversity - Women in Senior Leadership and Executive Roles | This is calculated as the number of women in Senior Leadership roles, which are Senior Directors and VPs, and Executive roles divided by the the total numbers of Senior Leaders and Executives on the last day of the calendar month. It is measured as the percent of women in BambooHR with a Job Grade of 11+ or CXO who are not on leave and have at least one direct report. | 30% of our Senior Leadership is female | People Success KPIs |
39 | Offer Acceptance Rate | The number of offers accepted divided by the number of offers extended in a given month. In other words, if 50 offers were extended in June, the offer acceptance rate is the total number of those offers accepted divided by fifty. If an offer is extended June 30 but accepted July 1, it is presented in June's offer acceptance rate. This means that last month's numbers may change slightly as offers are accepted in the beginning of the next calendar month. | The offer acceptance rate target is > 0.9. | People Success KPIs |
40 | Team Member Retention (Rolling 12 Months) | Team Member Retention = (1-(Number of Team Members leaving GitLab/Average of the 12 month Total Team Member Headcount)) x 100. GitLab measures team member retention over a rolling 12 month period, as well as over a calendar month. (The default period is over a rolling 12 month period.) In order to achieve the rolling 12 month team member retention target, the monthly team member total turnover target is < 1.3% (16/12). | Greater than 84% | People Success KPIs |
41 | Team Member Voluntary Retention (Rolling 12 Months) | Team Member Voluntary Retention = Retention + Involuntary Turnover. GitLab measures team member voluntary retention over a rolling 12 month period, as well as over a calendar month. (The default period is over a rolling 12 month period.) In order to achieve the rolling 12 month team member voluntary retention target, the monthly metric must be >90%. | Greater than 90% | People Success KPIs |
42 | Voluntary Team Member Turnover (Rolling 12 Months) | Voluntary turnover is any instance in which a team member actively chooses to leave GitLab. GitLab measures voluntary turnover over a rolling 12 month period, as well as over a calendar month. (The default period is over a rolling 12 month period). In order to achieve the rolling 12 month voluntary team member turnover cap, the monthly voluntary team member turnover cap is < 0.83% (10/12). Rolling Voluntary Team Member Turnover = (Number of Team Members actively choosing to leave GitLab/Average Total Team Members Count) x 100. Industry Standard Turnover is 22% overall:15% voluntary and 7% involuntary for software companies. | Less than 10% | People Success KPIs |
43 | Onboarding Satisfaction (OSAT) | New team member feedback of the onboarding experience in a given month. The Onboarding Satisfaction target is > 4.5. Read more about how we measure satisfaction at GitLab. | Greater than 4.5 | People Success KPIs |
44 | Discretionary bonuses | The number of discretionary bonuses given divided by the total number of team members, in a given period as defined. | Greater than 0.1 | People Success KPIs |
45 | Promotion Rate | The total number of promotions excluding SDRs over a rolling 12 month period divided by the month end headcount excluding SDRs. The target promotion rate is 12% of the population with an average of a 10% OTE increase. The 12% promotion rate does not apply to SDRs who have a higher rate. In addition, to understanding company level promotion rate, we look at promotion rates by gender. | 12% | People Success KPIs |
46 | Pay Equality | Pay Equality is [measured](/handbook/people-group/people-group-metrics/#compensation) by percentage "compa ratio" (+/- 2 points within 100%) for underrepresented groups at GitLab as defined in [Diversity, Inclusion & Belonging](/company/culture/inclusion/#pay-equality). | People Success KPIs | |
47 | Percent of team members outside compensation band | This metric is manually calculated by the Total Rewards Team, and will be moved over once we start using Compass. The Total Rewards Analysts will analyze against how many team members in a division or department are compensated outside the bands specific by our Global Compensation policy. The weights being used are 0.25 for % outside top end of comp band between 0.01% to 4.9%; 0.5 for band between 5% to 9.9%; 0.75 for band 10% to 14.9%; 1 for anything 15%+. The purpose of weighting how far over someone is from compensation band is to ensure if there are those outside of comp band slightly, they are not held at the same level as those hired well over rang | <=1% | People Success KPIs |
48 | Compliance, data retention and implementation | 100% accuracy of data held in BambooHR for all team members where we have an entity or PEO. Not capturing currently, but plan once the team member is hired for this role. | People Success KPIs | |
49 | Candidates Sourced by Talent Acquisition Department vs. Candidates Hired | How many candidates were sourced by the Talent Acquisition Department out of those who we hired in a given month. | The candidates sourced versus candidates hired target is greater than 0.50 | Talent Acquisition KPIs |
50 | Candidates hired from an underrepresented group | Number of hires that contribute to GitLab's diversity | 65% of hires contribute to GitLab's diversity | Talent Acquisition KPIs |
51 | Headcount vs. Plan | The number of team members based on start date divided by the number of hires in a given month. Hires comes from BambooHR. This KPI is tracked and reported on a monthly basis but year to date (headcount v plan) is also measured. | greater than 0.9 | Talent Acquisition KPIs |
52 | Time to Offer Accept (Days) | The median number of days from when a candidate is active in Greenhouse (applied, referred, or sourced) to accepting an offer in a given month. | The Time to Offer Accept (Days) target is < 45. | Talent Acquisition KPIs |
53 | Interviewee Satisfaction (ISAT) | The answer to the ‘Interviewee Satisfaction (ISAT) Score’ question, “Overall, my interviewing experience was a positive one,” is greater than 4.1 across all departments in a given month (1 - 5 response scale). | Greater than 4.1 | Talent Acquisition KPIs |
54 | Cost Per Hire | Cost per hire is calculated by taking the total monthly expenses incurred in the Recruiting department and other monthly expenses related to the hiring process and dividing by the total number of hires in that month. Besides the expenses incurred in the Recruiting department (i.e. salaries, travel expenses, recruiting software etc.) other expenses related to recruiting are agency fees and referral bonuses. These expenses are incurred in departments outside of Recruiting but hit their own GL accounts. These GL accounts will be what is included in Cost Per Hire, along with the total Recruiting Department expenses. This is calculated on a rolling three month average. | The cap is less than $14,000. | Talent Acquisition KPIs |
55 | Team Member Referrals | The percentage of Offer Accepts whose source was “Referral” in a given calendar month. This is calculated by taking the number of “Referral” Offer Accepts and dividing that by the total number of Offer Accepts for a given calendar month. “Referrals” are tracked in Greenhouse. | tbd | Talent Acquisition KPIs |
56 | Recruiting Operations & Insights Average Time to Project Completion | On average, the time it takes to complete one Recruiting Team project. | tbd | Talent Acquisition KPIs |
57 | Recruiting Operations & Insights Project Completion Rate | How many Recruiting Team projects have been completed versus projects that are currently open in a given period of time (e.g. per quarter) | tbd | Talent Acquisition KPIs |
58 | Recruiting Operations & Insights Service Desk Vendor Support Tickets | Analysis of the number of submitted internal support tickets, the number of resolved tickets, and the average time to resolution. | tbd | Talent Acquisition KPIs |
59 | Sourced Offers | The number of Offers sourced by a Sourcer. | tbd | Talent Acquisition KPIs |
60 | Sourced Candidates Moved to the Reference Check | The number of sourced candidates moved to the Reference Check stage. | tbd | Talent Acquisition KPIs |
61 | Sourcer Hires Conversion Rate | The number of candidates submitted by Sourcer that were Hired. | tbd | Talent Acquisition KPIs |
62 | Sourcer Offer Conversion Rate | The number of candidates submitted by Sourcer that received an Offer. | tbd | Talent Acquisition KPIs |
63 | Sourcer Interview Conversion Rate | The number of candidates submitted by Sourcer that successfully passed the screening call. | tbd | Talent Acquisition KPIs |
64 | Phone Screens Scheduled by a Sourcer | The number of candidates scheduled to speak with a Recruiter on a screening call. | tbd | Talent Acquisition KPIs |
65 | Sourced Prospects Submitted | The number of Prospects submitted to a Recruiter and/or a Hiring Manager by one Sourcer. | tbd | Talent Acquisition KPIs |
66 | Social Referrals | The percentage of Offer Accepts whose source was “SocialReferral” in a given calendar month. These candidates applied via links shared on social media sites (e.g. LinkedIn, Twitter, and the like). This is calculated by taking the number of “SocialReferral” Offer Accepts and dividing that by the total number of Offer Accepts for a given calendar month. “SocialReferrals” are tracked in Greenhouse. | tbd | Talent Acquisition KPIs |
67 | Recruiting or Hiring Manager LinkedIn Seat | The percentage of the company that has a recruiting or hiring manager seat on LinkedIn. This is calculated by taking the total number of recruiting and hiring manager seats divided by total employees on a calendar month basis. | tbd | Talent Acquisition KPIs |
68 | Candidate Time per Stage | Average number of days a Candidate spends per stages in the [interview plan](/handbook/hiring/talent-acquisition-framework/coordinator/#step-14c-schedule-team-interviews). | tbd | Talent Acquisition KPIs |
69 | Active Users with a Recruiting or Hiring Manager LinkedIn Seat | The percentage of team members that have a *Recruiter* or *Hiring Manager* seat and at least 1 active day of use per month. This is calculated by taking the total number of team members with at least 1 active day of use and dividing it by the total number of team members that have a seat. | tbd | Talent Acquisition KPIs |
70 | Interviewer Effectiveness | Interviewer Effectivess demonstates how well an Interviewer has predicted future performance in a prospective team member. The objective of this KPI is to identify the best Interviewers, distill their interviewing methodolgy, and update the Interviewer Training Issue accordingly. | tbd | Talent Acquisition KPIs |
71 | Average Days Sales Outstanding (DSO) | DSO=(Total Ending AR / Total Credit Sales (billing - defined as what has actually billed in the period by month based on the "accounting period" in Zuora.) x Number of Days in the Period | the median DSO for SAAS companies is 76 days. Our target at GitLab is 45 days. | Finance KPIs |
72 | Rule of 40 | The rule of 40 in SaaS is a financial framework that balances revenue growth versus free cash flow margins. | GitLab's target is to be at or above 40. | Finance KPIs |
73 | Gross margin | Gross margin is defined as total revenue less cost of revenues as defined by GAAP and reported in the Company's financial statements. | Our long term gross margin target is 85% but is dependent on the revenue mix between products - self managed and gitlab.com and professional services. | Finance KPIs |
74 | Runway | Runway is defined as the number of months based on cash balance plus available credit divided by average cash burn. The analysis can be found on the Finance Dashboard. Cash data is sourced from Netsuite. | Our target is that this metric is always greater than 12 months. | Finance KPIs |
75 | ARR by Annual Cohort | ARR can be sliced many different ways for analysis. In the ARR by Cohort analyses, we look at ARR by the Fiscal Year Cohort. That analysis can be found on the Finance Dashboard. The data for ARR by Annual Cohort is sourced from SFDC and Zuora. | tbd | Finance KPIs |
76 | Accounts Receivable Aging Greater Than 90 Days | Accounts Receivable Aging Greater Than 90 Days is tracked in two ways. It is tracked as the number of invoices with an Accounts Receivable balance that is greater 90 days. It is also tracked as the Accounts Receivable balance in dollars for those invoices that are greater than 90 days. | The cap is 2% of Accounts Receivable. | Finance KPIs |
77 | Average days to close | The number of business days required to report final monthly financial results. As a private company our target is 10 business days moving to 5 business days as a public company. This analysis can be found on the [Finance Dashboard](https://app.periscopedata.com/app/gitlab/483606/Finance-KPIs?widget=6500157&udv=780777). The days to close is sourced from the accounting close checklist. | 10 | Finance KPIs |
78 | Scalable Employment Solution | GitLab has contracted team members in multiple countries and is instilling a scalable employment solution for 100% of its team members. A scalable employment solution may include hiring through a PEO, hiring through a contractor's entity or, where possible, a direct contract. The percentage is calculated as a percentage of contractors covered by a scalable employment solution in relation to the total workforce. | 100% | Finance KPIs |
79 | Deliver Quantified Savings | Cost savings are achieved through the procure to pay process. Savings are calculated as the savings achieved by comparing the initial vendor proposal price to the final purchase price. In the event of a contract renewal, in addition to the above, savings can also be calculated as the savings achieved by comparing the previous cost per unit (eg. user, business metric, etc.) to the final cost per unit. Savings negotiated at the cost per unit level are also cost savings to be calculated as savings. Note these savings are not directly tied to budget. This aligns with the following core business objectives, control spend and build a culture of long-term savings on procurement costs, streamline the purchasing process, and minimize financial risk. | greater than 3,000,000 over a rolling 12 month period. | Finance KPIs |
80 | New hire location factor - Finance Team Inherited | This is a subset of an existing KPI. Please see the definition for the parent KPI. | < 0.73 | Finance KPIs |
81 | Estimated Combined Monthly Active Users (CMAU) | The estimated sum of all stage monthly active users (SMAU) in a rolling 28 day period for Self-Managed and SaaS. We extrapolate estimated CMAU based on the percentage of self-managed instances that report this data (not all self-managed instances do). Therefore the recorded number is not the same as the estimated or even the actual number. The chart currently reflects recorded CMAU. We plan to change this to estimated CMAU [soon](https://gitlab.com/gitlab-data/analytics/-/issues/6000). Numbers displayed below are for self-managed instances with usage ping (enabled), including the self-managed instance hosting the SaaS product. Data for (CMAU for SaaS) is available separately using GitLab.com Postgres Database Import. Owner of this KPI is the VP, Product Management. | TBD | Product KPIs |
82 | Paid Combined Monthly Active Users (Paid CMAU) | The sum of all (paid stage monthly active users ) in a 28 day rolling period. The license information used to generate this metric from usage ping is being validated, and the currently displayed data could be incorrect by up to 20%. Numbers displayed below are for self-managed instances with usage ping(enabled). Data for (Paid CMAU for SaaS ) is available separately using GitLab.com Postgres Database Import. Owner of this KPI is the VP, Product Management. | TBD | Product KPIs |
83 | Unique Monthly Active Users (UMAU) | The number of unique users that performed an event within the previous 28 days for Self-Managed and SaaS. Numbers displayed below are for self-managed instances with usage ping (enabled) and GitLab.com. Data for ( Paid Self-Managed (EE) Unique Monthly Active Users (UMAU) (28-day trailing window) ). Data for ( SaaS GitLab.com Unique Monthly Active Users (UMAU) (28-day trailing window) ) is also available using GitLab.com Postgres Database Import. UMAU calculation is the same using both data sources (usage ping and GitLab.com Postgres Database Import). Owner of this KPI is the VP, Product Management. | TBD | Product KPIs |
84 | New Group Namespace Trial to Paid Conversion Rate | The conversion rate of a new group namespace on a trial to a paid namespace. This is calculated by dividing the number of eligible new group namespaces that were on a trial and converted to paid within 40 days of creation by the total number of eligible new group namespaces that were on a trial within 40 days of creation. Eligible namespaces are top-level namespaces, excluding personal namespaces. The data source is GitLab.com Postgres Database Import. The owner of this KPI is the Director of PM, Growth. | See notes in Key Review slides | Product KPIs |
85 | New Group Namespace Create Stage Adoption Rate | The adoption rate of a new group namespace adopting features on the Create stage . This is calculated as the % of eligible new group namespaces the have at least one Create SMAU action within the first 7 days of creation. Eligible namespaces are top-level namespaces, excluding personal namespaces. The data source is GitLab.com Postgres Database Import. The owner of this KPI is the Director of PM, Growth. | 42% | Product KPIs |
86 | New Group Namespace Verify Stage Adoption Rate | The adoption rate of a new group namespace adopting features on the Verify stage . This is calculated as the % of eligible new group namespaces the have at least one Verify SMAU action within the first 90 days of creation. Eligible namespaces are top-level namespaces, excluding personal namespaces. The data source is GitLab.com Postgres Database Import. The owner of this KPI is the Director of PM, Growth. | SaaS is TBD (FY21 Q4 focus). | Product KPIs |
87 | New Group Namespace with at least two users added | The percentage of a new group namespace with at least two users added within 7 days of namespace creation. Eligible namespaces are top-level namespaces, excluding personal namespaces. User counts for top level namespaces can come from multiple avenues including sub-groups or projects. The data source is GitLab.com Postgres Database Import. The owner of this KPI is the Director of PM, Growth. | See notes in Key Review slides | Product KPIs |
88 | Stages per User (SpU) | Stages per user is calculated by dividing Stage Monthly Active User (CMAU) by Monthly Active Users (UMAU). SpU is now calculated using solely Usage Ping Data Source. As Stages add new SMAU counters and instances upgrade to newer versions, this KPI will keep on increasing artificially and will stabilize beginning of Q2 2021. The Stages per User (SpU) KPI is meant to capture the number of DevOps stages the average user is using on a monthly basis. This metric is important, as each stage added triples paid conversion. Owner of this KPI is the VP, Product Management. | Our Target SpU is 1.8. | Product KPIs |
89 | Stages per Organization (SpO) | Stages per Organization is calculated by dividing the sum of Stage Monthly Active Organizations (with a Stage Monthly Active Organization being defined as an instance for Self-Managed or a Namespace for SaaS with at least one Stage Active User on a given month) by the number of Unique Monthly Active Organizations (with UMAO being defined as an Organization with at least one UMAU). The Stages per Organization (SpO) KPI is meant to capture the number of DevOps stages the average organization is using on a monthly basis. This metric is important, as each stage added triples paid conversion. Owner of this KPI is the VP, Product Management. | undefined | Product KPIs |
90 | Category Maturity Advancement | Number of category maturity advancements per quarter. We have a three year goal of having half of our categories at lovable maturity. It's important that we see steady advancement of maturity each quarter in order to achieve the larger goal. Owner of this KPI is the VP, Product Management. | 5 category maturity advancements per quarter | Product KPIs |
91 | Paid Net Promoter Score (PNPS) | PNPS is the primary measurement of customer satisfaction with the GitLab product. 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. | Our Target is 0.72. | Product KPIs |
92 | New hire location factor Inherited | This is a subset of an existing KPI. Please see the definition for the parent KPI. | Our Target is 0.72. | Product KPIs |
93 | Acquisition impact | Acquisition impact measures the number of maturity levels advanced, as a result of acquisitions. The target is 3 per year. (Advancements by acqusition can be seen here) | 3 per year | Product KPIs |
94 | Percentage of transactions through self-service purchasing | Total transactions processed through the webstore, compared to transactions processed outside the webstore. This measure includes SaaS and self-managed subscriptions, additional CI minutes, storage, upgrading tiers and adding users. Driving adoption of self-service purchasing allows us to redirect manual sales efforts towards higher return activities. | 85% | Product KPIs |
95 | Active Hosts | 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. We are planning to update the methodology to track opt-in rate more accurately. once a month. | Product KPIs | |
96 | Refunds processed as % of orders | For a month take the number of refunds and divide that by the total amount of orders (including self-managed and sales initiated orders). This does not include Internal Refunds which are results from when a web direct opportunity from a closed month is not credited to the correct sales person. Internal Refunds are not refunds to customers, therefore not meaningful when analyzing refunds processed as orders from GitLab's revenue system, Zuora. | Product KPIs | |
97 | Stage Monthly Active Users (SMAU) | Stage Monthly Active Users is required for all product stages. SMAU is defined as the count of unique users who performed a particular action, or set of actions, within a stage in a 28 day rolling period for Self-Managed and SaaS. Numbers displayed below are for self-managed instances with usage ping (enabled), including the self-managed instance hosting the SaaS product. All (SMAU for SaaS) is available separately using GitLab.com Postgres Database Import. Owner of this KPI is the VP, Product Management. | TBD | Product KPIs |
98 | Paid Stage Monthly Active Users (Paid SMAU) | 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 instance for Self-Managed using Usage Ping data or a paid namespace for SaaS using GitLab.com Postgres Database Imports 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). (Paid SMAU for SaaS) is available separately using GitLab.com Postgres Database Import. Owner of this KPI is the VP, Product Management. | TBD | Product KPIs |
99 | Stage Monthly Active Clusters (SMAC) | 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 [Protect's Container Security group](/handbook/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. | TBD | Product KPIs |
100 | Group Monthly Active Users (GMAU) | 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. | TBD | Product KPIs |