The below page includes key definitions for the WW Field Team.
We define the number of customers as the number of accounts with a unique account identifier for which we have an active subscription in the period indicated. Users of our free trials or tier are not included in our customer count. A single organization with multiple divisions, segments or subsidiaries is generally counted as a single customer.
We snapshot customer count on business day 4.
A First Order customer is a customer within an Account Family that makes the first subscription order for the Account Family in the period. Any account that has an inactive subscription anywhere within the Account Family for >180 days will also be considered First Order.
A Connected New customer is the first new subscription order with an Account that is related to an existing customer Account Family (regardless of relative position in corporate hierarchy) and the ARR related to this new customer is considered "Connected New".
A Growth Customer is a customer within an Account Family when it is a subsequent subscription (not the first) or when a parent account consolidates new and existing subscriptions together.
| Situation | Marketing View | Sales & Finance View |
|---|---|---|
| First Order | New | New |
| Connected New | New | Growth |
| Add-on Order | Growth | Growth |
First Order and Connected New can be reported on via the Order Type fields in Salesforce. We have iterated on this field so please use the following guide:
| SFDC Field Name | Source of Truth for Time Period | Description |
|---|---|---|
| [LEGACY] Order Type | FY21 | Value stamped at close. |
| Order Type 2.0 | FY22 and Future Looking | Value stamped at close. Includes enhanced logic to filter out Additional CI Minutes and Credits as First Order |
| Order Type 2.0 (Live) | None | Used to track movement of values post deal close. Analysis Field Only. |
Order Type (all iterations) runs on a nightly job, please allow 24 hours after a relevant change for the fields to update. Technical documentation here.
Order Type 2.0 introduced additional values that relate back to our ARR definition framework
| Value | Definition |
|---|---|
| 1. New - First Order | Same as definition above |
| 2. New - Connected | Same as definition above |
| 3. Growth | Same as definition above |
| 4. Contraction | A renewal transaction that closes at a lower value then its prior value |
| 5. Churn - Partial | The inverse of New - Connected. When an Account churns, but the family is still a customer. |
| 6. Churn - Final | The inverse of New - First Order. The final churn in an account family. |
| 7. PS / Other | Non-recurring deals. Currently implemented as any deal value < $48 and is not coded as Pro Serv. |
We define customers in the following categorical level of detail:
Ultimate Parent Account field)Because "customer" can have multiple meanings, whenever customer is used in presenting data it must be qualified by the type of customer.
The default description is Parent. When the default is used, no further description is required.
When Account or Subscription is being reported then the title or field description on the chart must be added to call out the basis for reporting.
Metrics that are based on customer data should also carry a clarifying description. For clarity, Parent will be the only customer type used for external reporting.
Due to the way the parenting of accounts is done at GitLab, many of our Public Sector accounts roll up to only a few primary ultimate parent accounts (ie. United States Army, USN, DoE, Air Force, etc). This model has the following implications:
In all of the above scenarios, there’s a higher likelihood of accounts and opportunities to be flagged as Connect New and/or First Order Available is false even though the individual entities could, in fact, be considered New Logo.
For this reason, New Logos for the PubSec team are defined as opportunities where Order Type 2.0 = New - First Order OR New - Connected
Customer segmentation follows the segmentation as laid out in the Go to Market Handbook at the Parent Account level.
If an account was active at any point in time during the proposed timeframe it is counted as active. For example, an account that is active from March 2019 to May 2019 but is inactive from June 2019-on is counted for CY2019, FY2020 (which runs from February 2019-January 2020), FY20-Q1, and FY20-Q2; it is not counted in FY20-Q3 or FY20-Q4.
Deal Size is a dimension by which we will measure stage to stage conversions and stage cycle times of opportunities. Values are IACV in USD.
Note that we use the same amounts to group customers by ARR.
Value of all bookings from new and existing customers that will result in recurring revenue over the next 12 months less any credits, lost renewals, downgrades or any other decrease to annual recurring revenue.
Excluded from ACV are bookings that are non-recurring such as professional services, training and non-recurring engineering fees (PCV).
Value of new bookings from new and existing customers that will result in recurring revenue over the next 12 months less any credits, lost renewals, downgrades or any other decrease to annual recurring revenue.
For a deep-dive into iACV, including how it is calculated, see the iACV in Practice Page
GitLab defines ARR as the annual run-rate revenue of subscription agreements from all customers in a given month. GitLab calculates ARR by taking the monthly recurring revenue, or MRR, and multiplying it by 12. MRR for each month is calculated by aggregating, for all customers during that month, monthly revenue from committed contractual amounts of subscriptions. ARR and MRR should be viewed independently of revenue, and do not represent GitLab's GAAP revenue on a monthly or annualized basis, as they are operating metrics that can be impacted by contract start and end dates and renewal rates. ARR and MRR are not intended to be replacements or forecasts of revenue. ARR and MRR calculates subscription fees normalized to a monthly value, and does not include one-time or usage fees.
We snapshot ARR on business day 4.
For a deep-dive into ARR, including how it is calculated and the analysis framework, see the ARR in Practice Page
Monthly recurring revenue from subscriptions that are active from all customers in a given month.
IACV per won deal. This metric can be reported against various dimensions (e.g. ASP by customer segment, cohort, sales channel, territory, etc.)
Contract value that is not considered a subscription and the work is performed by the Professional Services team.
Value of all bookings from new and existing customers that will result in revenue less any credits, lost renewals, downgrades or any other decrease (i.e. within 90 days from close of the deal).
If Deal Length is greater than 12 months: Then TCV = ((ACV / 12) * Deal Term in Months) + Professional Services + Other One Time Fees
If Deal Length is less then or equal 12 months: Then TCV = ACV + Professional Services + Other One Time Fees
Lost or lowered contract value that occurs before a subscription renewal or subscription cancellation.
Contract value that results in a lower value than the previous contract value. Downgrade examples include seat reductions, product downgrades, discounts, and customers switching to Reseller at time of renewal.
What is it?
A true up is a back payment for a customer going over their license count during the year.
Why do we use it?
We use the true up model so that the license never becomes a barrier to adoption for the client.
Let's take an example.
A customer takes out a subscription for 100 users. During the year they grow the usage of the server and 200 additional users come on board. When it comes time to renew, they are now up to 300 active users despite the license only being for 100 users.
At this point the customer needs to do two things: they need to renew the license and to add the true up users.
The number of true up users in this case is 200.
It is the difference between the Maximum Users and the Users in License.
This can be found by the customer in their GitLab server by going to the Admin > License area.
It will look like this
There is more information below on the steps you need to take, but in this example you would need to update the number of users for the renewal to 300 and add the True Up product to the renewal quote for 200 users.
This will create a one time only charge to the customer and in a year's time, they will have a renewal for 300 users.
See here more information on the steps to take for the true up
Note that we make provision for true ups in our standard Subscription Terms Section 5 - Payment of Fees.
Annual revenue opportunity of the entirety of GitLab’s market. The potential value of everyone worldwide that could purchase our product. Both TAM and LAM can be scoped globally, by region/market segment, or customer-specific.
LAM is the annual revenue opportunity of the entirety of GitLab's market within our current customer base ("landed accounts"). The market is defined as total developers managed (employees and/or contractors for whom software is purchased and managed). The definition uses "total developers" as the input.
Basic LAM Formula:
Calculation
For territory and business planning, calculation will be automated using multiple data sources including customer verified totals.
The LAM formula has two inputs: Total Developers at the account and price.
The formula calculation algorithm reviews the developer fields to ensure trustworthiness. This is determined by comparing the developer fields to the number of employees and the number of licenses on the account. If the developer data point is validated, the number of developers is reduced by the amount of paid licenses on an account to determine the number of potential developers. If the field fails the validation rules, it is eliminated.
A fifth field based on license usage is added to the surviving data points from above.
5. Product Usage Overage (activated users - paid licenses)
In order to calculate LAM, the MAX surviving data points is multiplied by the average seat price of the account. In the event the average seat price is below the average premium seat price, the result is multiplied by the average premium seat price instead of the actual account seat price.
In circumstances where none of the developers fields are deemed trustworthy and there is no overage on the account, the formula defaults to the following:
Rounding:
LAM for a specific account is always rounded to the nearest thousand dollars and capped at $5M per account.
D500 accounts are any prospect & customer accounts in SFDC that have more than 500 total developers. This is useful when prioritizing high growth potential with high propensity to buy GitLab to ensure long-term growth within accounts. This field is populated by the number of developers used in the LAM calculation.
Given our land and expand model, we need to attribute our sales and marketing expense toward both our acquiring new customers and growing new customers. We allocate sales expense by using number of active customers because the number of active customers operationally drives where sales spends time. It also doesn't underweight sales time spent on first order which tends to be smaller than growth. We divide our customer base into cohorts by the quarter when they had their first active subscription. We then weight sales expense to each cohort by the number of active customers in that cohort. Our marketing expense is allocated between first order business and connected new business based on IACV because those are the key KPIs we use to evaluate marketing. Marketing expense includes the cost of free users of gitlab.com.
Defined as how much we spend in sales and marketing to generate revenue in a period. We calculate this by taking a ratio of the amount of sales and marketing spend (including the cost of free users of gitlab.com) in the prior period compared to the growth in revenue in the current period. The formula is:
(sales and marketing expense over trailing twelve months) / (recurring revenue current quarter * 4 - recurring revenue from same quarter prior year * 4)
While the metric is easy to calculate, its limitation is that the sales and marketing efforts don't have as much impact on revenue in the current period as they do on bookings or future period revenue.
We've seen this definition of CAC Ratio used by companies in their investor presentation. Industry guidance reports that median performance is 1.15, with anything less than 1.0 considered very good.
Customer Life-Time Value is the amount of gross margin contribution on a cash basis from a customer over the life of that customer.
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 and growing that customer. A good LTV to CAC ratio is considered to be > 3.0..
To accurately calculate the LTV to CAC of a customer sum all the cash that a customer has paid GitLab over the life of the customer times the gross margin and divide it by the total sales and marketing cost to acquire and grow this customer. These cash flows are discounted back using the GitLab cost of capital or discount rate. We use 15% for our discount rate. This metric is the most accurate view of our unit economics however given we don't have many customers over 4 years of tenure with us there are assumptions in the numbers. This should be used for internal decision making only.
As we acquire new customers we analyze how long it takes to recoup the investment to acquire a new customer. This is calculated by taking one cohort of customers and plotting the sum of the cash paid to GitLab by new customers over time and then plotting the amount of sales and marketing expense allocated to that cohort. Where the two lines cross is where GitLab breaks even on the customer acquisition.
ATR is the sum of all ARR for subscriptions with a contract term ending in a given time period. For clarity, this excludes all ARR for active subscriptions with contract terms ending in other time periods. For example, if there were only 4 customers and Customer 1 (C1) and C2 have contracts ending in February 2022, C3 has a contract ending in Feb 2023, and C4 has a contract ending in June 2022, then the ATR for Q1 2022 would be the C1 ARR + C2 ARR. It does not include C3 despite the fact that it is on a Q1 contract cycle since the contract does not expire until the following year.
Contract value that is lost at the time of subscription renewals.
Lost Renewals examples include cancellations at or before the subscription renewal date.
If you have a customer who is not renewing, you must mark the Stage as 8-Closed Lost.
(Recurring revenue T-1) - (Recurring revenue T-2)) * 4 / GTM spend T-2
T = current quarter
The thesis is that Go To Market (GTM) spend on marketing and sales in the second to last quarter caused the growth in the last quarter.
Industry guidance suggests a good Magic Number is > 1.0, this means you generate more than $1m in incremental ARR from $1m in Sales and marketing investment). Best in class is > 1.5 (for example Twilio). Atlassian is the best in the B2B SaaS industry > 2.0
This number is also sometimes called 'Magic number'.
ARR divided by number of Licensed Users.
This metric may also be referred to as Average Revenue Per User (ARPU) or Average Revenue Per Account (ARPA).
Ratio of total IACV from closed won, Web Direct opportunities (i.e. customers who purchase via the self-service portal) divided by the total IACV of all closed won opportunities. GitLab's target is greater than 30%. The default measurement is IACV but this can also be calculated and reported for ACV.
The IACV of all open opportunities currently in the stages of 4-Proposal, 5-Negotiating, and 6-Awaiting Signature.
The IACV of all open opportunities.
We measure pipeline generated on a monthly basis for net new customers and existing customers. For KPI measurement pipeline creation vs plan should exceed 1.0.
Renewals ACV plus Growth IACV minus (Lost Renewals + Credits + Downgrades)
The value of the first twelve (12) months of any mid-term upgrade.
Is a classifier model built to identify customers most likely to increasing their ARR by >25% within the next 12 month.
The model works at a parent account level and leverages data from previous periods like: ARR, ARR changes, created contacts, created opportunities, created support tickets, won/lost deals, touchpoints, products per period, # of seats and industry.
The model was created following the iteration value and delivered a working Proof Of Concept for the FY22 planning exercise.
The average amount of annualized IACV a native quota carrying sales rep produces in a given month formula: (IACV / # of native quota carrying reps adjusted for ramp time) * 12 months.
The IACV used in this calculation only includes opportunities owned by quota carrying sales reps (not by a manager, director, or VP). Additionally, opportunities that represent web portal purchases are split out separately.
The primary metric when measuring rep productivity for only for quota attainment but also for compensation is the Gross Incremental Annual Contract Value (Gross IACV). Is is important to remember that while renewals are not a part of comp or quota attainment, renewing customers is still very important aspect of our business.
Rep Productivity is defined as IACV divided by the number of reps of a particular type (i.e. SAL, MM AEs, SMB Customer Advocates). Web portal purchases are split out separately.
Another measured KPI is Rep Productivity (as defined above) divided by On Target Income.
A ramp adjusted sales head count.
The collection of all Salesforce Accounts that roll up to the same Ultimate Parent Account.
A distinct group or organization within a customer which, from a GitLab customer relationship perspective, can be treated and thought of as a separate customer. When determining whether a group is a business unit, factors to consider include whether they have:
A unique deal that is set to Closed Won in SalesForce.
The opportunity owner's primary reason as to why GitLab won the deal.
We also capture Downgrade Reasons when we win a deal but with negative Net ARR (i.e., the customer renews but for less money than they were previously paying). All of the Lost Reasons below can apply to downgrades.
A unique deal that is set to 8-Closed Lost in SalesForce.
The opportunity owner's primary reason as to why GitLab lost the deal.
D300 accounts are any prospect & customer accounts in SFDC that have more than 300 total developers. This is useful when prioritizing high growth potential with high propensity to buy GitLab to ensure long-term growth within accounts.
An opportunity with substantial Net ARR (typically 7 figures) in either the Pipeline or Best Case Forecast Category that creates a wide gap between the same quarters Commit Forecast making it difficult for the business forecast with single digit variance.
The number of contracted users on active paid subscriptions. Excludes OSS, Education, Free and other non-paid users. The data source is Zuora.
All Accounts and Opportunities are owned by a "User" in SFDC (primarily a Sales Users) and each User is assigned a set of User Hierarchy attributes. These attributes allow for "user based" reporting and include the following:
User Hiearchy attributes are determined by Sales Operations, Sales Strategy and Finance and live on the User record in SFDC. Any questions or discrepancies with respect to User Hierarchy should be addressed with Sales Operations
Utilization is defined as Seats currently in use / Seats in license.
When not qualified, referring to "utilization" always refers to license utilization.
All other uses, (e.g. CPU utilization), should be qualified and mentioned specifically.
