# GASP Standard (Generally Accepted SaaS Principles). Full text. > Canonical definitions, formulas and benchmarks for SaaS metrics across 13 departments, > plus the ontology, event model (CEL) and attribution layer (ATL) behind them. > Site: https://gaspwiki.com. Index: https://gaspwiki.com/llms.txt. > Machine-readable data: https://gaspwiki.com/api/standard.json. > MCP server for agents: npx -y gasp-standard-mcp (https://www.npmjs.com/package/gasp-standard-mcp). > License: content CC BY 4.0, code Apache 2.0. ## Contents - Standard Overview: https://gaspwiki.com/v1/overview - Canonical Definitions: https://gaspwiki.com/v1/definitions - MRR, ARR, NRR, GRR, CAC, LTV, Rule of 40: Standard Definitions: https://gaspwiki.com/v1/metrics/core - SaaS Sales Metrics: Pipeline, Win Rate, ACV, Quota Attainment: https://gaspwiki.com/v1/metrics/sales - SaaS Marketing Metrics: MQL, SQL, CAC, Funnel Conversion: https://gaspwiki.com/v1/metrics/marketing - SaaS Customer Success Metrics: NRR, Health Score, Churn: https://gaspwiki.com/v1/metrics/customer-success - SaaS Support Metrics: CSAT, CES, First Response Time: https://gaspwiki.com/v1/metrics/support - SaaS Onboarding Metrics: Time to First Value, Activation: https://gaspwiki.com/v1/metrics/onboarding - SaaS Product Metrics: DAU/MAU, Feature Adoption, Stickiness: https://gaspwiki.com/v1/metrics/product - SaaS Engineering Metrics: DORA, Uptime, Deploy Frequency: https://gaspwiki.com/v1/metrics/engineering - SaaS Finance Metrics: Gross Margin, Burn Rate, Magic Number: https://gaspwiki.com/v1/metrics/finance - SaaS RevOps Metrics: Forecast Accuracy, DSO, Quote-to-Cash: https://gaspwiki.com/v1/metrics/revops - SaaS People Metrics: Turnover, eNPS, Revenue per Employee: https://gaspwiki.com/v1/metrics/people - SaaS Partnership Metrics: Partner Revenue, Channel Attribution: https://gaspwiki.com/v1/metrics/partnerships - SaaS Professional Services Metrics: Utilization, Margin: https://gaspwiki.com/v1/metrics/professional-services - Metric Relationships: https://gaspwiki.com/v1/relationships - Commercial Event Ledger (CEL): https://gaspwiki.com/v1/cel - Attribution Taxonomy Layer (ATL): https://gaspwiki.com/v1/atl --- # The GASP Standard ## The Unified SaaS Reporting Standard **GAAP for SaaS.** Just as Generally Accepted Accounting Principles standardized financial reporting for both management and investors, the GASP Standard establishes consensus definitions for SaaS metrics. One set of definitions. One way to calculate. No ambiguity. --- ## Foundation The GASP Standard provides canonical definitions for SaaS metrics across all departments, informed by industry best practices from sources like the [SaaS Metrics Standards Board](https://www.saasmetricsboard.com/), SaaS Capital, KeyBanc and others. **The standard includes:** - Core financial metrics (ARR, NRR, GRR, CAC, etc.) with precise formulas and benchmarks - Operational metrics across all departments (Support, Engineering, Product, HR, etc.) - Relationships between metrics showing cause and effect - The One Page. A standard view of business health - Practical implementation guidance Where industry consensus exists, we follow it. Where gaps exist, we define using practitioner input and published research. --- ## The Problem Every SaaS company measures "churn" differently. Ask five companies for their NRR and you'll get five different formulas. Boards, investors and operators waste time debating definitions instead of acting on insights. The GASP Standard ends this. It codifies how the industry actually measures performance - the consensus that already exists but hasn't been written down. --- ## What This Standard Provides - **Canonical definitions** for every metric. Ops through board room - **Exact formulas** - no "it depends" - **Industry benchmarks** for context - **Relationships** between metrics - the system, not just the numbers - **The One Page** - the standard view of business health It is opinionated by design. These are not suggestions. This is the standard. --- ## From Ops Dashboard to Board Deck Most SaaS metrics frameworks serve either operators or investors. The GASP Standard serves both. The dual-lens framework provides two forms for key metrics, Operating (O) and Market (M), computed from the same underlying data via the [Commercial Event Ledger](https://gaspwiki.com/v1/cel) and [Attribution Taxonomy Layer](https://gaspwiki.com/v1/atl). - **O-form** metrics reflect the internal economic truth: what ops teams need to run the business - **M-form** metrics match investor-comparable definitions: what boards and investors benchmark against peers One set of data. Two perspectives. No reconciliation spreadsheet. --- ## Scope **This standard covers:** Subscription-based SaaS with recurring revenue. The universal building blocks that apply to all SaaS businesses. **This standard does not cover:** - **Usage-based/consumption pricing** - Product-specific, cannot be universalized - **Implementation edge cases** - Downstream concerns for individual businesses - **Industry-specific variations** - Vertical SaaS may have additional metrics The goal is foundational metrics that any SaaS business can adopt. Daily is the atomic unit; weekly, monthly and annual views are derived. --- ## Principles 1. **Consensus over custom.** These definitions reflect industry standard practice. Your business is not special enough to need different definitions. 2. **Precision over flexibility.** Each metric has one formula. Not "it depends." 3. **Outcomes over activity.** We measure what matters to the business, not what's easy to track. 4. **Connection over isolation.** Metrics exist in relationship to each other. Understanding the system matters more than any single number. --- ## Structure ### Layers | Layer | Purpose | Audience | |-------|---------|----------| | **Core Metrics** | Define overall business health | Board, Executives | | **Departmental Metrics** | Function-specific performance | Department leaders | | **Diagnostic Metrics** | Investigate problems | Analysts, Operators | ### Documents | Document | Purpose | |----------|---------| | [Definitions](https://gaspwiki.com/v1/definitions) | Canonical definitions for all terms - the source of truth | | [Relationships](https://gaspwiki.com/v1/relationships) | How metrics connect and influence each other | | [The One Page](../wireframes/one-page.md) | Standard view of business health | --- ## Departments Covered | Department | File | Focus | |------------|------|-------| | **Core** | [core.md](https://gaspwiki.com/v1/metrics/core) | MRR, ARR, NRR, CAC, LTV - the fundamentals | | **Sales** | [sales.md](https://gaspwiki.com/v1/metrics/sales) | Pipeline, win rate, quota, deal velocity | | **Marketing** | [marketing.md](https://gaspwiki.com/v1/metrics/marketing) | Funnel, MQLs, CAC, demand generation | | **Customer Success** | [customer-success.md](https://gaspwiki.com/v1/metrics/customer-success) | Health scores, retention, expansion | | **Support** | [support.md](https://gaspwiki.com/v1/metrics/support) | Tickets, CSAT, resolution, efficiency | | **Onboarding** | [onboarding.md](https://gaspwiki.com/v1/metrics/onboarding) | TTFV, completion, activation | | **Product** | [product.md](https://gaspwiki.com/v1/metrics/product) | Usage, adoption, stickiness, delivery | | **Engineering** | [engineering.md](https://gaspwiki.com/v1/metrics/engineering) | Uptime, DORA metrics, incidents | | **Finance** | [finance.md](https://gaspwiki.com/v1/metrics/finance) | Margins, burn, cash, profitability | | **RevOps / Order to Cash** | [revops.md](https://gaspwiki.com/v1/metrics/revops) | Billing, collections, revenue recognition | | **People (HR)** | [people.md](https://gaspwiki.com/v1/metrics/people) | Turnover, eNPS, hiring, engagement | | **Partnerships** | [partnerships.md](https://gaspwiki.com/v1/metrics/partnerships) | Channel revenue, partner performance | | **Professional Services** | [professional-services.md](https://gaspwiki.com/v1/metrics/professional-services) | Utilization, project delivery, margins | --- ## Metric Categories | Category | What it covers | |----------|----------------| | Revenue | Money coming in: MRR, ARR, growth, expansion, contraction | | Retention | Customers staying: churn, NRR, GRR | | Acquisition | Customers arriving: CAC, conversion, pipeline | | Engagement | Customers using: adoption, stickiness, health | | Efficiency | Doing more with less: margins, payback, LTV:CAC | | Operations | Running the business: support, uptime, delivery | | People | The team: retention, engagement, capacity | --- ## Hierarchy ``` ┌─────────────────┐ │ Business Health │ │ (Score) │ └────────┬────────┘ │ ┌────────────────────┼────────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌───────────┐ ┌───────────┐ │ Revenue │ │ Retention │ │ Efficiency│ │ Health │ │ Health │ │ Health │ └────┬────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ ┌────┴────┐ ┌─────┴─────┐ ┌────┴────┐ │MRR, ARR │ │NRR, Churn │ │Margin, │ │Growth │ │GRR, NPS │ │CAC, LTV │ └─────────┘ └───────────┘ └─────────┘ ▲ ▲ ▲ │ │ │ [Sales, Mktg] [CS, Support] [Finance] dept metrics dept metrics dept metrics ``` --- ## How to Use This Standard 1. **Read the Core Metrics first.** Understand the numbers that define business health. 2. **Map your data sources.** For each metric, identify where the input data lives in your systems. 3. **Implement exactly as defined.** Do not modify formulas. Do not add caveats. 4. **Use the One Page.** Let the standard surface what matters. 5. **Investigate with Departmental Metrics.** When something is off, drill into the relevant domain. --- # Canonical Definitions Single source of truth for all terms used in the GASP Standard. When a term appears in multiple departmental metrics, this is the authoritative definition. Departmental files reference this document; they do not redefine. --- ## Foundational Entities The SaaS data model is built on a three-level hierarchy. All metrics must be understood in context of which level they measure. See the [interactive diagram](https://gaspwiki.com/v1/relationships) for a visual representation. ### Customer (Account, Organization) A distinct billing entity with one or more subscriptions. The "who" of your business relationship. - **Attributes:** Legal entity, billing contact, payment methods, contract terms - **Key metrics at this level:** Logo count, Logo churn rate, Customer LTV, NPS - **Industry equivalents:** Account (Stripe, Zuora, Salesforce), Organization (many B2B tools) ### Subscription (Contract, Agreement) A billable agreement between a customer and your product, with defined terms, pricing and status. The "what and when" of the relationship. - **Attributes:** Plan/tier, term (monthly/annual/multi-year), status, billing schedule - **Key metrics at this level:** MRR, ARR, Subscription churn, Plan distribution - **Industry equivalents:** Subscription (Stripe, Chargebee), Contract (Salesforce CPQ) ### License (Entitlement, Access, Quota) A specific capability, quantity or configuration granted by a subscription. The "how much" of the relationship. - **Types:** - **Feature Gates.** Binary access (on/off): SSO, API access, advanced analytics - **Quantity Limits.** Numeric caps: seats, storage, API calls - **Configuration.** Behavioral parameters: data retention, SLA tier - **Key metrics at this level:** Seat utilization, Feature adoption, Usage vs quota - **Industry equivalents:** Entitlements (Stripe), Licenses (Salesforce, Microsoft), Rate Plan Charges (Zuora) ### Hierarchy Principles 1. **Customers own subscriptions, not the reverse.** A customer churns when *all* their subscriptions end. 2. **MRR lives at the subscription level.** Expansion and contraction are measured by subscription changes. 3. **Licenses are derived from subscriptions.** The subscription is the source of truth; licenses are computed. 4. **Metrics must specify their level.** "Churn rate" is ambiguous. Specify logo churn (customer), MRR churn (subscription) or seat churn (license). --- ## Revenue Terms ### MRR (Monthly Recurring Revenue) The total predictable revenue from active subscriptions, normalized to a monthly value. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#mrr-monthly-recurring-revenue) - **Used in:** Core, Finance, Customer Success ### ARR (Annual Recurring Revenue) MRR × 12. The annualized value of recurring revenue. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#arr-annual-recurring-revenue) - **Used in:** Core, Finance, Sales, Customer Success, People ### New MRR MRR added from newly acquired customers in the period. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#new-mrr) - **Used in:** Core, Sales ### Expansion MRR Additional MRR from existing customers (upgrades, add-ons, seat increases). - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#expansion-mrr) - **Used in:** Core, Customer Success ### Churned MRR MRR lost from customers who cancelled. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#churned-mrr) - **Used in:** Core, Customer Success ### Contraction MRR MRR reduction from existing customers who downgraded (but didn't churn). - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#contraction-mrr) - **Used in:** Core, Customer Success ### Carry MRR MRR from existing customers that renewed unchanged. No expansion, contraction or churn. - **Formula:** Beginning MRR − Churned MRR − Contraction MRR - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#carry-mrr) - **Used in:** Core ### Net New MRR The net change in MRR after all movements. - **Formula:** New MRR + Expansion MRR - Churned MRR - Contraction MRR - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#net-new-mrr) - **Used in:** Core ### Revenue (GAAP) Recognized revenue according to ASC 606 accounting standards. - **Canonical definition:** [Finance Metrics](https://gaspwiki.com/v1/metrics/finance#revenue-gaap) - **Used in:** Finance, RevOps ### Bookings Total contract value signed in a period. - **Canonical definition:** [Finance Metrics](https://gaspwiki.com/v1/metrics/finance#bookings) - **Used in:** Finance, Sales ### ACV (Annual Contract Value) The annualized value of a contract, normalizing multi-year deals to a single year. When aggregated, represents average deal size on an annual basis. - **Canonical definition:** [Sales Metrics](https://gaspwiki.com/v1/metrics/sales#acv-annual-contract-value) - **Used in:** Sales, Finance ### ARPA (Average Revenue Per Account) Average monthly recurring revenue per customer account. - **Formula:** MRR / Active Customers - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#arpa-average-revenue-per-account) - **Used in:** Core (LTV, CAC Payback), Finance --- ## Retention Terms ### NRR (Net Revenue Retention) Percentage of revenue retained from existing customers over a period, including expansion, contraction and churn. Two methods are widely used: cohort method (preferred) and formula method. Recommended: trailing 12 months, annualized if using shorter periods. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#net-revenue-retention-nrr) - **Used in:** Core, Customer Success - **Adjusted variant:** Filter CEL events by [`change_nature`](https://gaspwiki.com/v1/cel#change-nature) to compute Adjusted NRR excluding temporary revenue movements. ### GRR (Gross Revenue Retention) Percentage of revenue retained from existing customers, excluding expansion. Cannot exceed 100%. Two methods are widely used: cohort method (preferred) and formula method. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#gross-revenue-retention-grr) - **Adjusted variant:** Filter CEL events by [`change_nature`](https://gaspwiki.com/v1/cel#change-nature) to compute Adjusted GRR excluding temporary revenue movements. - **Used in:** Core, Customer Success ### Logo Churn Rate Percentage of customers lost in a period. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#logo-churn-rate-customer-churn) - **Used in:** Core, Customer Success ### Revenue Churn Rate Percentage of MRR lost to churn and contraction in a period. Gross (losses only, not netted against expansion). - **Formula:** (Churned MRR + Contraction MRR) / Beginning MRR × 100 - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#revenue-churn-rate) - **Used in:** Core ### Renewal Rate Percentage of contracts renewed at term. - **Canonical definition:** [Customer Success Metrics](https://gaspwiki.com/v1/metrics/customer-success#renewal-rate) - **Used in:** Customer Success, RevOps --- ## Efficiency Terms ### CAC (Customer Acquisition Cost) Total cost to acquire a new customer. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#cac-customer-acquisition-cost) - **Used in:** Core, Marketing, Finance ### Marketing CAC Marketing-only portion of CAC (excludes sales costs). - **Canonical definition:** [Marketing Metrics](https://gaspwiki.com/v1/metrics/marketing#marketing-cac) - **Used in:** Marketing ### LTV (Customer Lifetime Value) Total profit expected from a customer over their lifetime. Calculated with gross margin. - **Formula:** (ARPA × Gross Margin) / Revenue Churn Rate - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#ltv-customer-lifetime-value) - **Used in:** Core, Finance ### LTV:CAC Ratio Ratio of customer lifetime value to acquisition cost. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#ltvcac-ratio) - **Used in:** Core, Finance ### CAC Payback Period Time required to recover customer acquisition cost. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#cac-payback-period) - **Used in:** Core, Finance ### Gross Margin Revenue minus cost of goods sold, as percentage of revenue. - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#gross-margin) - **Used in:** Core, Finance ### Rule of 40 ARR Growth Rate (YoY %) + EBITDA Margin (%). - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#rule-of-40) - **Used in:** Core, Finance ### Magic Number Sales efficiency metric: QoQ ARR growth divided by prior quarter S&M spend. - **Canonical definition:** [Finance Metrics](https://gaspwiki.com/v1/metrics/finance#magic-number) - **Used in:** Finance ### Burn Multiple Capital efficiency metric: Net burn divided by net new ARR. Popularized by David Sacks. - **Canonical definition:** [Finance Metrics](https://gaspwiki.com/v1/metrics/finance#burn-multiple) - **Used in:** Finance --- ## Customer Terms ### Customer An entity (company/account) with a paid subscription. - **Not:** Trial users, free tier users - **Counting:** One customer = one billing entity, regardless of users - **In formulas:** Unless otherwise specified, "Customers" means Active Customers ### Active Customer A customer in good standing at a point in time. - **Criteria:** Not churned, not suspended, payment current - **Used for:** MRR counts, ARPA calculations, denominator in retention metrics ### User An individual person using the product within a customer account. - **Distinct from:** Customer (account level) ### Active User A user who performed a qualifying action in the defined period. - **Canonical definition:** [Product Metrics](https://gaspwiki.com/v1/metrics/product#daily-active-users-dau) - **Qualifying action:** Defined per product; must be intentional engagement ### Lead A contact who has expressed interest (form fill, signup, etc.). - **Canonical definition:** [Marketing Metrics](https://gaspwiki.com/v1/metrics/marketing#leads) ### MQL (Marketing Qualified Lead) A lead meeting criteria indicating sales-readiness. - **Canonical definition:** [Marketing Metrics](https://gaspwiki.com/v1/metrics/marketing#marketing-qualified-leads-mqls) ### SQL (Sales Qualified Lead) An MQL accepted by sales as worth pursuing. - **Canonical definition:** [Marketing Metrics](https://gaspwiki.com/v1/metrics/marketing#sales-qualified-leads-sqls) ### Opportunity A qualified sales prospect in the pipeline. - **Distinct from:** Lead, MQL, SQL (earlier funnel stages) --- ## Satisfaction Terms ### NPS (Net Promoter Score) % Promoters (9-10 rating) minus % Detractors (0-6 rating). - **Canonical definition:** [Core Metrics](https://gaspwiki.com/v1/metrics/core#nps-net-promoter-score) - **Used in:** Core, Onboarding, Partnerships, Professional Services - **Note:** Same formula everywhere, but measured for different populations (customers, project completions, partners) ### CSAT (Customer Satisfaction Score) Percentage of positive ratings on satisfaction survey. - **Canonical definition:** [Support Metrics](https://gaspwiki.com/v1/metrics/support#customer-satisfaction-score-csat) - **Used in:** Support, Customer Success, Onboarding, Professional Services - **Note:** Same formula, different contexts (ticket, relationship, project) ### CES (Customer Effort Score) Average rating on ease of experience (typically 1-7 scale). - **Canonical definition:** [Support Metrics](https://gaspwiki.com/v1/metrics/support#customer-effort-score-ces) - **Used in:** Support ### Health Score Composite score predicting likelihood of retention or churn. - **Canonical definition:** [Customer Success Metrics](https://gaspwiki.com/v1/metrics/customer-success#customer-health-score) - **Used in:** Customer Success, Product --- ## Time Terms ### Period A defined time interval for measurement. Always specify: - Daily - Weekly - Monthly (calendar month) - Quarterly (calendar quarter) - Annual (trailing 12 months or calendar year - specify which) ### Cohort A group of customers/users defined by a shared characteristic, typically signup date. - Example: "January 2026 cohort" = customers who signed up in January 2026 ### Trailing / Rolling A period ending at the current date. - Example: "Trailing 12 months" = past 365 days from today ### YoY (Year over Year) Comparison to same period in prior year. - Example: "Q1 2026 vs Q1 2025" ### MoM (Month over Month) Comparison to prior month. ### QoQ (Quarter over Quarter) Comparison to prior quarter. --- ## Financial Terms ### COGS (Cost of Goods Sold) Direct costs to deliver the product/service. - **SaaS COGS includes:** Hosting, support team, payment processing, third-party software - **SaaS COGS excludes:** Sales, marketing, R&D, G&A ### Operating Expenses (Opex) Costs of running the business (excluding COGS). - **Categories:** S&M, R&D, G&A ### EBITDA Earnings before interest, taxes, depreciation and amortization. - **Formula:** Net income + Interest + Taxes + Depreciation + Amortization ### Burn Rate Net cash consumed per month. - **Canonical definition:** [Finance Metrics](https://gaspwiki.com/v1/metrics/finance#cash-burn-rate) ### Runway Months until cash runs out at current burn rate. - **Canonical definition:** [Finance Metrics](https://gaspwiki.com/v1/metrics/finance#cash-runway) ### DSO (Days Sales Outstanding) Average days to collect payment after invoicing. - **Canonical definition:** [Finance Metrics](https://gaspwiki.com/v1/metrics/finance#days-sales-outstanding-dso) - **Used in:** Finance, RevOps (same definition) ### Bad Debt Rate Percentage of revenue written off as uncollectable. - **Canonical definition:** [Finance Metrics](https://gaspwiki.com/v1/metrics/finance#bad-debt-rate) - **Used in:** Finance, RevOps (same definition) --- ## Reliability Terms ### Uptime / Availability Percentage of time service is operational. - **Canonical definition:** [Engineering Metrics](https://gaspwiki.com/v1/metrics/engineering#uptime-availability) ### SLA (Service Level Agreement) Contractual commitment for service levels (uptime, response time, etc.). ### Incident An unplanned interruption or degradation of service. - **Severity levels:** SEV1 (critical), SEV2 (major), SEV3 (minor) ### MTTR (Mean Time to Resolve/Recover) Average time from incident start to resolution. - **Canonical definition:** [Engineering Metrics](https://gaspwiki.com/v1/metrics/engineering#mean-time-to-resolve-mttr) - **Note:** DORA uses "Mean Time to Recovery" - same concept ### Error Rate Percentage of requests resulting in errors. - **Canonical definition:** [Engineering Metrics](https://gaspwiki.com/v1/metrics/engineering#error-rate) - **Product variant:** User-facing error rate (per user action) --- ## Pipeline Terms ### Pipeline Total value of active sales opportunities. - **Canonical definition:** [Sales Metrics](https://gaspwiki.com/v1/metrics/sales#pipeline-value) ### Pipeline Coverage Ratio of pipeline value to quota. - **Canonical definition:** [Sales Metrics](https://gaspwiki.com/v1/metrics/sales#pipeline-coverage-ratio) ### Win Rate Percentage of opportunities closed as won. - **Canonical definition:** [Sales Metrics](https://gaspwiki.com/v1/metrics/sales#win-rate) - **Used in:** Sales, Partnerships (partner win rate) ### Sales Cycle Time from opportunity creation to close. - **Canonical definition:** [Sales Metrics](https://gaspwiki.com/v1/metrics/sales#sales-cycle-length) --- ## Engagement Terms ### Session A period of continuous user activity in the product. - **Ends:** After defined inactivity period (typically 30 minutes) ### DAU / WAU / MAU Daily / Weekly / Monthly Active Users. - **Canonical definition:** [Product Metrics](https://gaspwiki.com/v1/metrics/product) ### Stickiness DAU/MAU ratio - how often users return. - **Canonical definition:** [Product Metrics](https://gaspwiki.com/v1/metrics/product#daumau-ratio-stickiness) ### Feature Adoption Percentage of users using a specific feature. - **Canonical definition:** [Product Metrics](https://gaspwiki.com/v1/metrics/product#feature-adoption-rate) ### Activation Moment when new user experiences core product value. - **Definition:** Product-specific, must be explicitly defined - **Canonical framework:** [Product Metrics](https://gaspwiki.com/v1/metrics/product#activation-rate) --- ## Time-Based Metrics ### TTFV (Time to First Value) Time from signup to achieving first meaningful value. - **Canonical definition:** [Onboarding Metrics](https://gaspwiki.com/v1/metrics/onboarding#time-to-first-value-ttfv) ### FRT (First Response Time) Time from ticket/request to first human response. - **Canonical definition:** [Support Metrics](https://gaspwiki.com/v1/metrics/support#first-response-time-frt) ### Resolution Time Time from request to final resolution. - **Canonical definition:** [Support Metrics](https://gaspwiki.com/v1/metrics/support#resolution-time-time-to-resolution) ### Lead Time for Changes Time from code commit to production deployment. - **Canonical definition:** [Engineering Metrics](https://gaspwiki.com/v1/metrics/engineering#lead-time-for-changes) --- ## Percentile Conventions When reporting distributions: - **Median (P50):** Middle value, use for "typical" experience - **P95:** 95th percentile, use for "almost everyone" experience - **P99:** 99th percentile, use for tail/worst case **Never use averages** for latency or time metrics - outliers skew results. --- ## Counting Conventions ### Point-in-Time vs Period - **Point-in-time:** Value at a specific moment (e.g., "Customers as of Dec 31") - **Period:** Activity during an interval (e.g., "Customers acquired in Q4") ### Beginning vs Ending - **Beginning of period:** Value at start (for retention calculations) - **End of period:** Value at end (for current state) ### Unique vs Total - **Unique:** Deduplicated count (e.g., unique users) - **Total:** All occurrences (e.g., total sessions) --- ## Measurement Period Conventions Standard measurement frequencies by metric type. Always specify the period used. ### Revenue Metrics | Metric | Typical Period | Notes | |--------|---------------|-------| | MRR | Monthly | Point-in-time, end of month | | ARR | Monthly | MRR × 12, point-in-time | | MRR Growth Rate | Monthly | Month-over-month comparison | | New/Expansion/Churned/Contraction MRR | Monthly | Activity during the month | ### Retention Metrics | Metric | Typical Period | Notes | |--------|---------------|-------| | NRR | Annual (trailing 12 months) | Monthly for operational tracking; annualize if using shorter periods | | GRR | Annual (trailing 12 months) | Same as NRR | | Logo Churn Rate | Monthly or Annual | Always specify which; monthly × 12 ≠ annual | | Revenue Churn Rate | Monthly | Annualize for comparison: (1 - monthly rate)^12 | ### Efficiency Metrics | Metric | Typical Period | Notes | |--------|---------------|-------| | CAC | Quarterly | Lag 1-2 months for long sales cycles | | LTV | N/A | Lifetime calculation, not periodic | | CAC Payback | Quarterly | Result in months | | Gross Margin | Monthly or Quarterly | Aligns with financial reporting | | Rule of 40 | Annual | YoY growth + trailing margin | ### Engagement Metrics | Metric | Typical Period | Notes | |--------|---------------|-------| | DAU/WAU/MAU | Daily/Weekly/Monthly | Rolling windows | | NPS | Quarterly or Annual | Avoid survey fatigue | --- ## GASP Framework Terms The terms below describe the GASP standard itself. How metrics are classified, how events are captured, how access is scoped, how the twin is assembled. They are distinct from the SaaS business concepts above. You will see these terms in the MCP server output, the ontology, the adapter schema and the governance framework. ### CEL (Commercial Event Ledger) The atomic, immutable event layer from which all GASP metrics derive. Every metric in the standard traces back to CEL events. If an event is not in the CEL, it does not exist for metric purposes. - **Canonical definition:** [CEL](https://gaspwiki.com/v1/cel#commercial-event-ledger-cel) - **Used in:** All revenue, retention and cost metrics ### ATL (Attribution Taxonomy Layer) The tagging layer that classifies CEL events by lifecycle stage, expansion type and cost function. ATL is what enables dual-lens metrics (Operating form vs Market form). - **Canonical definition:** [ATL](https://gaspwiki.com/v1/atl#attribution-taxonomy-layer-atl) - **Used in:** Core metrics with dual-lens forms (ARR, NRR, CAC, LTV, Gross Margin, Churn) ### Adapter The JSON mapping file that connects GASP's canonical field names to your warehouse columns. Each field declares its `schema.table.column` reference plus optional owners for the definition and the pipeline. The adapter is the only file a consuming organization writes. - **Reference:** [Adapter Guide](https://gaspwiki.com/v1/adapter) ### Digital Twin The combination of the GASP standard (metrics, relationships, ontology), your adapter (warehouse mapping) and an MCP server (agent access layer). Together they form a read-only semantic model of how a SaaS business operates. Agents read from the twin, not from source systems directly. - **Reference:** [SaaS Digital Twin](https://gaspwiki.com/v1/digital-twin) ### Ontology The structured representation of GASP's entities, concepts, fields, source categories, temporal semantics and validation rules. The ontology sits below the metric layer and provides the canonical vocabulary that adapters, queries and agents reference. - **Reference:** ontology.json in the GASP repository ### Signal Type A classification that describes what kind of signal a metric provides. Every GASP metric has exactly one primary signal type; some carry a secondary. - **Outcome.** A result that matters on its own (ARR, NRR, Gross Margin). - **Leading.** Predicts a future outcome (Pipeline Value, Health Score, NPS). - **Efficiency.** A ratio measuring productivity (CAC Payback, LTV:CAC, Magic Number). - **Operational.** Operational health or throughput (Uptime, MTTR, Ticket Volume). - **Reference:** [Taxonomy](https://gaspwiki.com/v1/taxonomy) ### Sensitivity Tier GASP's recommended data sensitivity classification for each metric. Aligns with ISO 27001 and OSSA `data_classification` conventions. - **`public`.** Shareable externally with no restriction (rare for internal SaaS metrics). - **`internal`.** Shareable across the organization. Default for most operational metrics. - **`confidential`.** Cross-functional but sensitive. Typically restricted to managers and above. - **`restricted`.** Highly sensitive. Executive and finance-leadership only by default. - **Reference:** [Governance](https://gaspwiki.com/v1/governance#sensitivity-tier) ### Access Scope GASP's recommended filtering pattern for each metric. Describes whether the metric is naturally filterable by user context. - **`unscoped`.** Same value for everyone with access (e.g. company-wide ARR). - **`department-scoped`.** Filtered by the viewer's department context. - **`owner-scoped`.** Visible only for records the viewer owns or manages. Interpretation (individual, team, territory, book, segment) lives in the adapter. - **Reference:** [Governance](https://gaspwiki.com/v1/governance#access-scope) ### Change Nature Optional CEL field that captures the intent behind a revenue movement. Does not alter metric calculations. Enables downstream analysis of revenue quality (e.g. Adjusted NRR). - **`permanent`.** Durable shift in the customer relationship (default when omitted). - **`temporary`.** Expected to reverse within a defined period. - **`scheduled_reversal`.** Reverses a prior `temporary` event. - **Reference:** [CEL change_nature](https://gaspwiki.com/v1/cel#change-nature) ### Structured Formula A decomposed representation of a metric's formula: explicit references to other metric nodes (with roles like numerator, denominator, addend) and the raw fields required. Enables agents to walk the dependency tree without parsing formula text. - **Reference:** ontology.json structuredFormulas in the GASP repository ### Metric Owner The named team or person responsible for a metric definition in an organization's adapter. Ownership is a required adapter field. When a metric value is disputed, the owner resolves the dispute. GASP provides the canonical definition; the owner decides whether their organization follows it or deviates, and documents the deviation. - **Reference:** [Adapter Guide](https://gaspwiki.com/v1/adapter#metric-owners) ### Temporal Semantics GASP's structured description of a metric's time grain, aggregation method and reporting frequency. Each metric has a mapping (e.g. MRR = End-of-month snapshot, Daily sync). - **Reference:** ontology.json temporalSemantics in the GASP repository --- ## Null Handling When data is missing: - **Exclude from calculations:** Don't impute or assume - **Report coverage:** What percentage of records have data - **Flag uncertainty:** If sample size is too small, note it --- ## Benchmark Sources When benchmarks are cited in this standard, they are drawn from: - [SaaS Metrics Standards Board](https://www.saasmetricsboard.com/) - core metric definitions - [KeyBanc Capital Markets SaaS Survey](https://www.key.com/businesses-institutions/industry-expertise/saas-resources.html) - annual survey of private SaaS companies - [SaaS Capital](https://www.saas-capital.com/research/) - retention and growth benchmarks - [OpenView/High Alpha SaaS Benchmarks](https://www.highalpha.com/saas-benchmarks) - comprehensive annual report - [Benchmarkit](https://www.benchmarkit.ai/2025benchmarks) - CAC, payback, efficiency metrics - [Bessemer Cloud Index](https://cloudindex.bvp.com/) - public SaaS company performance tracking - [ICONIQ Growth](https://www.iconiqcapital.com/growth/insights) - SaaS scaling and efficiency research - [McKinsey](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/saas-and-the-rule-of-40-keys-to-the-critical-value-creation-metric) - Rule of 40 analysis - [DORA State of DevOps Report](https://dora.dev/research/) - engineering metrics - [Gainsight](https://www.gainsight.com/resource/the-customer-success-index-2024/) - customer success metrics - [Mixpanel](https://mixpanel.com/benchmarks/) - product metrics Benchmarks are general guidance. Your targets may differ based on business model, market and stage. --- # Core Business Metrics These are the metrics that define SaaS business health. Every SaaS business should track these. **Foundation:** Core metric definitions follow industry consensus, informed by sources including the [SaaS Metrics Standards Board](https://www.saasmetricsboard.com/), SaaS Capital and KeyBanc. --- ## Revenue Metrics ### MRR (Monthly Recurring Revenue) **Definition:** The total predictable revenue from active subscriptions, normalized to a monthly value. **Formula:** ``` MRR = Sum of (Monthly subscription value for all active customers) ``` For annual contracts: ``` MRR contribution = Annual Contract Value / 12 ``` **Include:** - Recurring subscription fees - Expansion and upgrade revenue - Discounts (use discounted amount, not list price) **Exclude:** - One-time fees (setup, implementation, professional services) - Trial accounts and free users - Variable/usage-based fees (unless contractually guaranteed) - Non-recurring charges **Inputs:** - Active customer list - Subscription/contract value for each customer - Contract term (monthly/annual) **What it tells you:** The current run rate of your recurring revenue engine. **Important:** MRR is a business insights metric, not a GAAP/FASB accounting term. It is representative of, but not identical to, recognized revenue. **Common mistakes:** - Including one-time fees (setup, professional services) - Including usage/consumption revenue that isn't guaranteed - Double-counting customers during plan changes - Not normalizing annual contracts to monthly - Treating MRR as an accounting figure **Related metrics:** ARR, MRR Growth Rate, New MRR, Expansion MRR, Churned MRR **Sources:** - [Baremetrics: MRR Definition](https://baremetrics.com/academy/saas-calculate-mrr) - [Maxio: Monthly Recurring Revenue Defined](https://www.maxio.com/saaspedia/monthly-recurring-revenue-defined-for-a-saas-business) - [ChurnZero: Monthly Recurring Revenue](https://churnzero.com/churnopedia/monthly-recurring-revenue-mrr/) --- ### ARR (Annual Recurring Revenue) **Definition:** The annualized value of recurring revenue. ARR represents the yearly run rate of subscription revenue. **Note:** ARR is used to mean two things in the industry: 1. **Annualized Run Rate** = MRR × 12 (common for monthly-billing companies) 2. **Annual Recurring Revenue** = Sum of annualized contract values (common for annual-contract companies) Both are valid. The GASP Standard uses **MRR × 12** for consistency across business models. **Formula:** ``` ARR = MRR × 12 ``` **Include:** Same inclusions/exclusions as MRR, annualized. **What it tells you:** The scale of the business on an annual basis. Used for valuation, planning and investor reporting. **Common mistakes:** - Calculating from annual contracts directly without normalizing (leads to timing mismatches) - Treating ARR as cash (it's a run rate, not collected revenue) - Mixing definitions without declaring which one you're using **Sources:** - [SaaS Metrics Standards Board: ARR](https://www.saasmetricsboard.com/annual-recurring-revenue) - [ChartMogul: ARR Definition](https://chartmogul.com/saas-metrics/arr/) - [Maxio: Annual Recurring Revenue](https://www.maxio.com/saaspedia/arr) #### Operating Form: ARR-O ARR-O measures organic recurring revenue by excluding MRR changes that come from mechanical pricing or contract restructuring rather than genuine customer expansion. **CEL Source:** `Revenue_Event`, `Amendment_Event` **ATL Inclusion:** All `expansion_classification` values **except** `Pricing_Adjustment` and `Recontracting` **Formula:** ``` ARR-O = MRR × 12 ``` Where MRR excludes changes tagged with `expansion_classification` ∈ (`Pricing_Adjustment`, `Recontracting`). **What it tells you:** The run rate of revenue driven by real customer adoption and organic expansion. The durable portion of ARR. #### Market Form: ARR-M ARR-M is total reported ARR including all sources of recurring revenue change. This is the number investors see and public comparables use. **CEL Source:** `Revenue_Event`, `Amendment_Event` **ATL Inclusion:** All `expansion_classification` values included **Formula:** ``` ARR-M = MRR × 12 ``` All MRR sources included. **What it tells you:** The scale of the business as reported to the market. The number used in valuation multiples and investor benchmarks. #### Bridge: ARR-O ↔ ARR-M **Reconciliation:** ``` ARR-M = ARR-O + Pricing_Adjustment_MRR × 12 + Recontracting_MRR × 12 ``` **Diagnostic:** The delta (ARR-M − ARR-O) is the **Durability Gap.** How much of reported ARR growth comes from mechanical pricing and contract changes rather than organic customer expansion. A growing gap signals ARR growth that may not be durable. Tracked implicitly by KeyBanc in their annual SaaS survey. Public SaaS companies report total ARR (ARR-M) while internal planning teams strip pricing actions to assess true product-led growth. --- ### ARPA (Average Revenue Per Account) **Definition:** Average monthly recurring revenue per customer. **Formula:** ``` ARPA = MRR / Active Customers ``` **What it tells you:** The average value of a customer on a monthly basis. Used in LTV and CAC Payback calculations. **Note:** Some companies use ARPU (Average Revenue Per User) for user-based pricing. ARPA is account-level; ARPU is user-level. --- ### MRR Growth Rate **Definition:** The month-over-month percentage change in MRR. **Formula:** ``` MRR Growth Rate = (MRR this month - MRR last month) / MRR last month × 100 ``` **Benchmarks:** - Early stage (pre-$1M ARR): 15-20% MoM - Growth stage ($1M-$10M ARR): 5-10% MoM - Scale stage ($10M+ ARR): 2-5% MoM **What it tells you:** The velocity of revenue growth. **Sources:** [Baremetrics](https://baremetrics.com/academy/saas-calculate-mrr), [Chargebee](https://www.chargebee.com/resources/glossaries/what-is-net-mrr-growth/) --- ### New MRR **Definition:** MRR generated from brand new customers acquired in the period. **Formula:** ``` New MRR = Sum of (first month MRR from customers acquired this period) ``` **Example:** 5 new customers × $60/month plan = $300 New MRR **What it tells you:** The output of your acquisition engine. **Sources:** [Drivetrain](https://www.drivetrain.ai/strategic-finance-glossary/mrr-in-saas), [SaaS Academy](https://www.saasacademy.com/blog/what-is-mrr) --- ### Expansion MRR **Definition:** Additional MRR from existing customers through upgrades, add-ons, seat increases or price increases. **Formula:** ``` Expansion MRR = Sum of (MRR increase from existing customers this period) ``` **Includes:** Upsells, cross-sells, add-ons, seat expansion, plan upgrades **What it tells you:** Your ability to grow revenue without acquiring new customers. The most efficient growth. **Key insight:** Expansion MRR rate should exceed churn rate for negative net churn. **Sources:** [Wall Street Prep](https://www.wallstreetprep.com/knowledge/expansion-revenue-mrr/), [Drivetrain](https://www.drivetrain.ai/strategic-finance-glossary/mrr-in-saas) --- ### Churned MRR **Definition:** MRR lost from customers who cancelled their subscriptions. **Formula:** ``` Churned MRR = Sum of (MRR from customers who churned this period) ``` **What it tells you:** The leakage in your revenue bucket from customer attrition. **Sources:** [Drivetrain](https://www.drivetrain.ai/strategic-finance-glossary/mrr-in-saas), [Baremetrics](https://baremetrics.com/academy/saas-calculate-mrr) --- ### Contraction MRR **Definition:** MRR reduction from existing customers who downgraded but didn't churn. **Formula:** ``` Contraction MRR = Sum of (MRR decrease from existing customers who remain active) ``` **Includes:** Plan downgrades, removed seats, dropped add-ons **What it tells you:** Revenue pressure from customers reducing usage/commitment. **Sources:** [Drivetrain](https://www.drivetrain.ai/strategic-finance-glossary/mrr-in-saas), [SaaS Academy](https://www.saasacademy.com/blog/what-is-mrr) --- ### Carry MRR **Definition:** MRR from existing customers that renewed at the same amount. No expansion, contraction or churn. **Formula:** ``` Carry MRR = Beginning MRR - Churned MRR - Contraction MRR ``` **Also known as:** Base MRR, Retained MRR, Renewal MRR **What it tells you:** The stable foundation of your revenue. High carry relative to beginning MRR means your base is healthy. Carry MRR expressed as a percentage of Beginning MRR equals GRR. **Key insight:** Carry MRR is GRR in dollar terms. If carry is declining while expansion masks it, you have a retention problem hiding behind growth. **Sources:** [Baremetrics](https://baremetrics.com/academy/saas-calculate-mrr), [ChartMogul](https://chartmogul.com/blog/mrr-movements/) --- ### Net New MRR **Definition:** The net change in MRR after accounting for all movements. **Formula:** ``` Net New MRR = New MRR + Expansion MRR - Churned MRR - Contraction MRR ``` **Example:** $50,000 starting + $2,500 new + $5,000 expansion - $1,000 churned - $500 contraction = $56,000 ending **What it tells you:** The bottom line of your revenue engine's performance. Positive = growing. Negative = shrinking. **Sources:** [Baremetrics](https://baremetrics.com/academy/saas-calculate-mrr), [Chargebee](https://www.chargebee.com/resources/glossaries/what-is-net-mrr-growth/) --- ### Bundle Pricing and MRR Allocation **Definition:** When a subscription is sold as a bundle (a single SKU containing multiple products, features or services at one price), individual line items within the bundle have no explicit price. MRR must still be allocated to each component for accurate reporting of expansion, contraction and churn at the item level. **The problem:** A customer pays $500/month for a "Growth Bundle" containing CRM, Analytics and Support. If they later remove Analytics, what was Analytics worth? Without allocation, you can't measure contraction MRR or product-level revenue. **Industry standard method: Relative Standalone Selling Price (SSP)** This is the method prescribed by ASC 606 / IFRS 15 for revenue recognition and used by Stripe, Zuora and Chargebee for bundle allocation: ``` Item MRR = (Item SSP / Sum of all item SSPs) × Bundle Price ``` **Steps:** 1. **Determine standalone selling price (SSP)** for each item. The price you would charge if the item were sold individually 2. **Calculate the allocation ratio.** Each item's SSP as a percentage of the total SSPs 3. **Apply the ratio to the bundle price.** This gives each item its allocated MRR **Example:** | Item | Standalone Price | Allocation % | Allocated MRR | |------|-----------------|--------------|---------------| | CRM | $300/mo | 50% | $250 | | Analytics | $200/mo | 33% | $167 | | Support | $100/mo | 17% | $83 | | **Total SSP** | **$600/mo** | **100%** | **$500** | The bundle discount ($100) is distributed proportionally across all items. **When SSP is not observable:** If an item has never been sold individually, ASC 606 provides three estimation methods: - **Adjusted market assessment.** Estimate what the market would pay - **Expected cost plus margin.** Cost to deliver + target margin - **Residual approach.** Allocate known SSPs first, remainder to the unknown item (use only when SSP is highly variable or uncertain) **What this enables:** - Accurate contraction/expansion MRR when bundle components change - Product-level revenue attribution - Meaningful churn analysis per product line - Consistent reporting between finance (ASC 606) and operations (MRR) **Common mistakes:** - Allocating equally across items regardless of value - Using cost as a proxy for value (low-cost items may have high customer value) - Not updating SSPs when standalone pricing changes - Treating the entire bundle as a single unit (hides component-level movements) **Note:** MRR allocation for operational reporting should align with your ASC 606 / IFRS 15 revenue allocation where possible. Divergence between operational MRR and recognised revenue creates reconciliation problems. **Sources:** - [Stripe: Standalone Selling Prices](https://docs.stripe.com/revenue-recognition/standalone-selling-price) - [Chargebee: Standalone Selling Price](https://www.chargebee.com/docs/revrec/revenue-recognition/standalone-selling-price) - [Zuora: Fair Value / SSP in Multiple-Element Arrangements](https://www.zuora.com/resource/fair-value-standalone-selling-price-multiple-element-arrangements-revpro/) - [Maxio: SaaS Revenue Recognition and ASC 606](https://www.maxio.com/blog/saas-revenue-recognition-asc-606) --- ## Retention Metrics ### Net Revenue Retention (NRR) **Definition:** The percentage of revenue retained from existing customers over a period, including expansion, contraction and churn. Also known as Net Dollar Retention (NDR). **Calculation Methods:** Two methods are widely used. The **cohort method is preferred** for accuracy. **1. Cohort Method (Preferred):** Compare the MRR of a specific group of customers from one year ago to the MRR of those same customers today. New customers acquired during the period are excluded. ``` NRR = MRR of cohort today / MRR of same cohort 12 months ago × 100 ``` **2. Formula Method:** ``` NRR = (Beginning MRR + Expansion MRR - Contraction MRR - Churned MRR) / Beginning MRR × 100 ``` **Time period:** Typically measured annually. The GASP Standard recommends **trailing 12 months** for board/investor reporting, as it smooths seasonality. **Annualization:** If calculating over a shorter period, annualize by raising to the appropriate power: - Monthly NRR annualized: `(Monthly NRR / 100) ^ 12 × 100` - Quarterly NRR annualized: `(Quarterly NRR / 100) ^ 4 × 100` **Does NOT include:** New customer revenue. NRR measures existing customer behavior only. **Benchmarks (per KeyBanc 2024, SaaS Capital 2025):** - Below 90%: Leaky bucket. Growth requires constant new acquisition. - 90-100%: Stable. You keep what you have. - 100-110%: Good. Existing customers grow. (Median for VC-backed SaaS: 101-106%) - 110-120%: Great. Strong expansion motion. - 120%+: Exceptional. Top quartile performance. **Segment-specific benchmarks (per SaaS Capital 2025):** - SMB-focused: 90-105% typical - Mid-market: 105-115% typical - Enterprise: 115-125% typical **What it tells you:** Can you grow without adding new customers? NRR is a critical indicator of SaaS sustainability because it measures whether your existing customer base is expanding or contracting. High NRR reduces dependence on new customer acquisition for growth. **Common mistakes:** - Calculating over inconsistent time periods - Including new customer revenue (that's not NRR) - Excluding small customers or segments - Confusing with Gross Revenue Retention (GRR) **Sources:** - [SaaS Metrics Standards Board: NRR](https://www.saasmetricsboard.com/net-revenue-retention) - [Wall Street Prep: Net Revenue Retention](https://www.wallstreetprep.com/knowledge/net-revenue-retention-nrr/) - [ChurnZero: Net Revenue Retention](https://churnzero.com/churnopedia/net-revenue-retention/) #### Operating Form: Cohort NRR (NRR-O) NRR-O uses the cohort method and includes only organic expansion. Growth from the same product and usage realisation. It excludes expansion from new modules, new buying centres, reactivation and pricing actions. **CEL Source:** `Revenue_Event` **ATL Inclusion:** - `lifecycle_attribution` ∈ (`Retention`, `Expansion`) - `expansion_classification` ∈ (`Same_Product`, `Usage_Realisation`) - Excludes: `expansion_classification` ∈ (`New_Module`, `New_Buying_Centre`, `Pricing_Adjustment`, `Recontracting`) and `lifecycle_attribution` = `Reactivation` **Formula:** ``` NRR-O = MRR of cohort today (organic only) / MRR of same cohort 12 months ago × 100 ``` **What it tells you:** True product-market fit signal. Are customers expanding because the product delivers more value, independent of commercial motion? #### Market Form: Account NRR (NRR-M) NRR-M uses the account-level formula method and includes all expansion types. Only net-new logo acquisition is excluded. This matches what public SaaS companies report and what investors benchmark. **CEL Source:** `Revenue_Event` **ATL Inclusion:** - All `expansion_classification` values included - Only `lifecycle_attribution` = `Acquisition` excluded **Formula:** ``` NRR-M = (Beginning MRR + All Expansion MRR − Contraction MRR − Churned MRR) / Beginning MRR × 100 ``` **What it tells you:** The total revenue retention and expansion picture that investors use for benchmarking and valuation. #### Bridge: NRR-O ↔ NRR-M **Reconciliation:** ``` NRR-M ≈ NRR-O + Reactivation + Cross-Module + New Buying Centre + Pricing Adjustment + Recontracting expansion ``` (Expressed as percentage-point contributions to the NRR rate.) **Diagnostic:** The delta (NRR-M − NRR-O) is the **Expansion Integrity Gap.** How much of reported NRR comes from commercial motion (cross-sell, reactivation, pricing) versus organic product expansion. A wide gap means NRR depends on sales execution rather than product-led growth. Not inherently bad, but the board should know which engine drives retention. SaaS Metrics Standards Board recommends the cohort method. Public SaaS companies report account-level NRR (NRR-M). --- ### Gross Revenue Retention (GRR) **Definition:** The percentage of revenue retained from existing customers, excluding expansion revenue. Also known as Gross Dollar Retention. **Calculation Methods:** Two methods are widely used. The **cohort method is preferred** for accuracy. **1. Cohort Method (Preferred):** Compare the MRR of a cohort, using the lesser of beginning MRR or current MRR for each customer (this mathematically eliminates expansion while capturing shrinkage and churn). ``` GRR = Sum of min(Beginning MRR, Current MRR) per customer / Beginning MRR × 100 ``` **2. Formula Method:** ``` GRR = (Beginning MRR - Contraction MRR - Churned MRR) / Beginning MRR × 100 ``` **Time period:** Typically measured annually. **Annualization:** If calculating over a shorter period, annualize by raising to the appropriate power: - Monthly GRR annualized: `(Monthly GRR / 100) ^ 12 × 100` - Quarterly GRR annualized: `(Quarterly GRR / 100) ^ 4 × 100` **Critical:** GRR **cannot exceed 100%**. Unlike NRR, it does not include upsells, cross-sells or expansion. Maximum GRR = 100% (zero churn). **Benchmarks (per SaaS Capital 2025):** - Below 80%: Severe retention problem - 80-85%: Below average for most segments - 85-90%: Average for SMB-focused businesses (Median for bootstrapped SaaS: 92%) - 90-95%: Good, typical for mid-market - 95%+: Excellent, typical for enterprise (90th percentile: 98%) **Segment-specific (per SaaS Capital 2025):** - SMB: 85%+ is good - Mid-market/Enterprise: 90%+ is good - High ACV Enterprise: 95%+ expected **What it tells you:** The baseline health of your customer relationships, independent of upsell. Investors examine GRR alongside NRR because strong expansion can mask high churn. **Sources:** - [SaaS Metrics Standards Board: GRR](https://www.saasmetricsboard.com/gross-revenue-retention) - [Wall Street Prep: Gross Revenue Retention](https://www.wallstreetprep.com/knowledge/gross-revenue-retention/) - [ChartMogul: GRR](https://chartmogul.com/saas-metrics/grr/) #### Dual-Lens Note GRR measures revenue retained from existing customers, excluding expansion. Because expansion is already stripped out, the Operating/Market distinction that drives dual-lens treatment for other metrics does not apply. There is no expansion classification to filter. GRR is GRR: the same calculation serves both internal planning and investor reporting. The existing definition is the standard for both lenses. --- ### Logo Churn Rate (Customer Churn) **Definition:** The percentage of customers lost in a period. Also called customer churn or logo churn. **Formula:** ``` Logo Churn Rate = Customers lost in period / Customers at start of period × 100 ``` **Time period:** Monthly or annual basis. Always specify which. **Benchmarks (Monthly, per OpenView/High Alpha 2024):** - <1%: Good for established SaaS - 1-2%: Acceptable - 2-3%: Concerning - >3%: Requires attention **Benchmarks (Annual):** - <5%: Excellent - 5-7%: Good - 7-10%: Average - >10%: High churn **By segment (per SaaS Capital 2025):** - SMB: Higher churn is normal (3-5% monthly). SMB churn is ~8x higher than enterprise. - Mid-market: 1-2% monthly typical - Enterprise: <1% monthly expected **What it tells you:** How many customers are leaving, regardless of their value. Important for understanding customer experience separate from revenue impact. **Logo vs Revenue Churn:** Logo churn counts customers equally. Revenue churn weights by value. Losing a few high-value customers may show low logo churn but high revenue churn. **Sources:** - [ChartMogul: Customer Churn](https://chartmogul.com/saas-metrics/customer-churn/) - [ChurnZero: Churn Rate](https://churnzero.com/churnopedia/churn-rate/) - [Maxio: Calculating Churn](https://www.maxio.com/saaspedia/calculating-churn-in-a-saas-business) --- ### Revenue Churn Rate **Definition:** The percentage of MRR lost to churn and contraction in a period. Also called MRR Churn Rate. **Formula:** ``` Revenue Churn Rate = (Churned MRR + Contraction MRR) / Beginning MRR × 100 ``` This is gross revenue churn - it measures losses only, without netting against expansion. This is the canonical formula because it isolates the leakage problem. **Note:** "Net Revenue Churn" (which subtracts expansion) can be calculated but conflates two distinct dynamics. Use NRR for the net view instead. **Benchmarks (Monthly, per OpenView 2024):** - <2%: Good - 2-5%: Average - >5%: High (average annual churn ~4.9% for B2B SaaS) **What it tells you:** The revenue impact of churn. If revenue churn is lower than logo churn, you're losing smaller customers (often acceptable). If higher, you're losing larger customers (concerning). **Sources:** - [Wall Street Prep: Revenue Churn](https://www.wallstreetprep.com/knowledge/revenue-churn-mrr/) - [ChartMogul: Revenue Churn](https://chartmogul.com/saas-metrics/revenue-churn/) - [Maxio: MRR Churn](https://www.maxio.com/saaspedia/mrr-churn) #### Dual-Lens: Revenue Churn (Churn-O) and Logo Churn (Churn-M) Revenue Churn Rate and Logo Churn Rate (defined above) are the Operating and Market forms of the same underlying phenomenon: customer attrition. **Operating Form: Revenue Churn Rate (Churn-O)** MRR-weighted churn captures the economic impact of attrition. The formula is defined above: `(Churned MRR + Contraction MRR) / Beginning MRR × 100`. **CEL Source:** `Revenue_Event` where `event_type` ∈ (`churn`, `contraction`) **What it tells you:** The operating metric because it reflects actual economic damage. Losing a $50K customer hits harder than losing a $500 customer. **Market Form: Logo Churn Rate (Churn-M)** Customer-count churn treats every logo equally. The formula is defined in the Logo Churn Rate section above: `Customers lost / Customers at start × 100`. **CEL Source:** `Revenue_Event` where `event_type` = `churn` (full churn only. Contraction is not logo churn) **What it tells you:** The market metric because it is simple, comparable and what investors benchmark. **Bridge:** Revenue Churn and Logo Churn are not additive. One measures dollars, the other measures logos. The diagnostic compares the two signals: - **Churn-O high, Churn-M low →** Losing few but high-value customers (concentration risk) - **Churn-M high, Churn-O low →** Losing many small customers (long-tail churn) - The pattern tells you where to focus retention efforts and which customer segments need intervention. --- ### NPS (Net Promoter Score) **Definition:** A measure of customer loyalty based on likelihood to recommend. **Origin:** Developed by Fred Reichheld, Bain & Company and Satmetrix (2003). Based on Harvard Business Review article "The One Number You Need to Grow." **The Question:** "How likely are you to recommend [product/company] to a friend or colleague?" (0-10 scale) **Customer Categories:** | Category | Score | Behavior | |----------|-------|----------| | Promoters | 9-10 | Loyal, enthusiastic, will refer, drive growth | | Passives | 7-8 | Satisfied but vulnerable, may switch to competitors | | Detractors | 0-6 | Unhappy, high churn, 80%+ of negative word-of-mouth | **Formula:** ``` NPS = % Promoters - % Detractors ``` Passives are not included in the calculation. **Score Range:** -100 to +100 **Benchmarks (per Bain & Company, CustomerGauge 2025):** - Below 0: More detractors than promoters - 0-30: Average (B2B SaaS average: 36-41) - 30-50: Good - 50-70: Excellent (top performers) - 70+: World class **What it tells you:** A leading indicator of retention and growth. NPS can signal churn risk before it manifests in revenue metrics, making it useful for early intervention. Bain & Company research links NPS to organic growth through referrals and reduced churn. **Common mistakes:** - Low response rates (<20% makes data unreliable) - Survey fatigue from over-asking - Not closing the loop with detractors - Comparing across industries (benchmarks vary significantly) **Sources:** - [Bain & Company: Measuring Your Net Promoter Score](https://www.netpromotersystem.com/about/measuring-your-net-promoter-score/) - [Wikipedia: Net Promoter Score](https://en.wikipedia.org/wiki/Net_promoter_score) - [Qualtrics: Net Promoter Score Guide](https://www.qualtrics.com/en-au/experience-management/customer/net-promoter-score/) --- ## Efficiency Metrics ### CAC (Customer Acquisition Cost) **Definition:** The total cost to acquire a new customer. **Formula:** ``` CAC = (Sales + Marketing spend in period) / New customers acquired in period ``` **Include:** - Sales salaries and commissions (for new customer acquisition) - Marketing salaries - Advertising spend - Marketing tools and software - Events and content costs - Trial/POC costs (hosting, implementation support) **Exclude:** - Customer Success costs (retention, not acquisition) - Costs for existing customer expansion - General overhead (unless investor requires) **Allocation:** If a salesperson splits time between new and existing customers (e.g., 70/30), allocate only the acquisition portion (70%) to CAC. **Timing:** For long sales cycles, consider lagged CAC: spend from 60-90 days ago / customers acquired today. **What it tells you:** The investment required to acquire each customer. **Benchmarks (per First Page Sage 2025):** - SMB SaaS: $300-$1,000 - Mid-market: $1,000-$5,000 - Enterprise: $5,000-$50,000+ - Target LTV:CAC ratio: 3:1 or higher (see LTV:CAC Ratio) **Common mistakes:** - Excluding salaries (they're a real cost) - Using wrong time period (customers acquired may not align with spend timing) - Including Customer Success costs - Mixing paid and organic (calculate separately for channel efficiency) **Sources:** - [Wall Street Prep: Customer Acquisition Cost](https://www.wallstreetprep.com/knowledge/customer-acquisition-cost-cac/) - [Maxio: CAC Customer Acquisition Cost](https://www.maxio.com/saaspedia/cac-customer-acquisition-cost) - [Paddle: Customer Acquisition Cost](https://www.paddle.com/resources/customer-acquisition-cost) #### Operating Form: Fully Loaded CAC (CAC-O) CAC-O includes all costs to make a customer productive: go-to-market spend plus implementation and onboarding. It reflects the true economic cost of acquiring a revenue-generating customer. **CEL Source:** `Cost_Event` **ATL Inclusion:** `lifecycle_attribution` ∈ (`Acquisition`, `Activation`) **Formula:** ``` CAC-O = Total Cost (Acquisition + Activation lifecycle) / New Customers Acquired ``` **What it tells you:** The full investment required to get a customer generating value. The number you need for true unit economics. #### Market Form: GTM CAC (CAC-M) CAC-M includes only go-to-market costs: sales and marketing spend. This matches the investor-comparable CAC used by KeyBanc, Benchmarkit and public SaaS benchmarks. **CEL Source:** `Cost_Event` **ATL Inclusion:** `lifecycle_attribution` = `Acquisition` AND `cost_function` = `GTM` **Formula:** ``` CAC-M = S&M Spend / New Customers Acquired ``` **What it tells you:** The market-comparable acquisition cost used in LTV:CAC ratios and investor benchmarks. #### Bridge: CAC-O ↔ CAC-M **Reconciliation:** ``` CAC-O = CAC-M + Implementation_Cost_per_Customer + Onboarding_Cost_per_Customer ``` **Diagnostic:** The delta (CAC-O − CAC-M) is the **Activation Delta.** The hidden cost of making customers productive that does not show up in S&M-based benchmarks. A large Activation Delta signals that investor-comparable CAC understates true acquisition economics. Driven by implementation complexity, onboarding duration and services intensity. SaaS Metrics Standards Board defines the Blended CAC Ratio as S&M-only (CAC-M). SaaS Capital and a16z recommend tracking fully loaded CAC (CAC-O) alongside for unit economics. --- ### LTV (Customer Lifetime Value) **Definition:** The total revenue (or profit) expected from a customer over their lifetime. Also known as CLV (Customer Lifetime Value) or CLTV. **Formula:** ``` LTV = (ARPA × Gross Margin) / Revenue Churn Rate ``` Where: - **ARPA** = Average Revenue Per Account (monthly) - **Gross Margin** = typically 70-85% for SaaS - **Revenue Churn Rate** = monthly churn rate **Why gross margin is included:** LTV measures profit contribution, not just revenue. Using gross margin reflects what you actually retain after delivery costs. This is the canonical formula. **What it tells you:** The upper bound of what you should spend to acquire a customer. **Limitations:** - Basic formula is optimistic (assumes linear churn) - Doesn't account for expansion revenue (understates for high-NRR companies) - Requires sufficient sample size for accuracy - Consider applying 0.75x discount for conservatism **Sources:** - [ChartMogul: Customer Lifetime Value](https://chartmogul.com/saas-metrics/ltv/) - [Baremetrics: Calculating LTV](https://baremetrics.com/academy/saas-calculating-ltv) - [Wall Street Prep: Customer Lifetime Value](https://www.wallstreetprep.com/knowledge/lifetime-value-ltv/) #### Operating Form: Contribution LTV (LTV-O) LTV-O uses contribution margin. Revenue minus all variable costs including implementation, onboarding, support and customer success. It reflects the true profit contribution over a customer's lifetime. **CEL Source:** `Revenue_Event`, `Cost_Event` **ATL Inclusion for costs:** All variable `cost_function` values per customer **Formula:** ``` LTV-O = (ARPA × Contribution Margin) / Revenue Churn Rate ``` Where Contribution Margin = Revenue − COGS − Implementation − Onboarding − Support − Success Engineering costs. **What it tells you:** The realistic lifetime profit from a customer after all variable delivery costs. The number to use for pricing and unit economics decisions. #### Market Form: Gross Margin LTV (LTV-M) LTV-M uses SaaS gross margin. Revenue minus COGS only. This is the formula already defined above and matches investor benchmarks (the 3:1 LTV:CAC threshold uses this form). **CEL Source:** `Revenue_Event`, `Cost_Event` **ATL Inclusion for costs:** `cost_function` = `Infrastructure` only (COGS) **Formula:** ``` LTV-M = (ARPA × Gross Margin) / Revenue Churn Rate ``` **What it tells you:** The investor-comparable lifetime value. The number used in LTV:CAC ratios reported to the board and in fundraising materials. **Note:** The formula defined above in this section is LTV-M. The Operating Form (LTV-O) substitutes Contribution Margin for Gross Margin. #### Bridge: LTV-O ↔ LTV-M **Reconciliation:** ``` LTV-M − LTV-O = Variable Service Costs per Customer × Customer Lifetime ``` The gap is the lifetime profit consumed by variable service costs (implementation, onboarding, support, CS). **Diagnostic:** The delta (LTV-M − LTV-O) is the **Contribution Leakage.** The lifetime profit that gets consumed by variable service costs. Large leakage means the business model depends on services that erode unit economics, signalling opportunities for services productisation and self-serve onboarding. The canonical LTV formula in investor contexts uses gross margin (LTV-M). This is what a16z, Bessemer and SaaS Capital reference. Contribution margin LTV (LTV-O) is recommended by growth equity investors for deeper unit economics analysis. --- ### LTV:CAC Ratio **Definition:** The ratio of customer lifetime value to acquisition cost. Measures the return on investment from sales and marketing spend. **Formula:** ``` LTV:CAC = LTV / CAC ``` Express as ratio (e.g., "3:1" or "3.0x"). **Benchmarks (per Optifai 2025, Wall Street Prep):** - Below 1:1: Losing money on every customer - 1:1 to 2:1: Breaking even or marginal, concerning to investors - 3:1 to 4:1: Industry standard, healthy sustainable growth (Median B2B SaaS: 3.2:1) - 4:1 to 5:1: Strong business model - Above 5:1: Under-investing in growth; could be growing faster **What it tells you:** Unit economics health. Are customers worth more than they cost to acquire? **Important:** Higher is not always better. A very high ratio (5:1+) suggests you're leaving growth on the table by not investing enough in acquisition. **Sources:** - [Wall Street Prep: LTV/CAC Ratio](https://www.wallstreetprep.com/knowledge/ltv-cac-ratio/) - [SaaS Capital: LTV/CAC Benchmarks](https://www.saas-capital.com/blog-posts/ltv-to-cac-ratio/) - [Corporate Finance Institute: LTV/CAC](https://corporatefinanceinstitute.com/resources/valuation/ltv-cac-ratio/) --- ### CAC Payback Period **Definition:** The number of months required to recover the cost of acquiring a customer. Also called "Months to Recover CAC" or "Time to Recover CAC." **Formula:** ``` CAC Payback = CAC / (ARPA × Gross Margin) ``` Result in months. **Why include Gross Margin:** Using gross margin (not just revenue) reflects actual profit recovery. Without it, payback appears shorter than reality. **Benchmarks (per Benchmarkit 2025, KeyBanc 2024):** - Under 12 months: Good, investor-friendly target (best-in-class) - 12-18 months: Acceptable (Median 2024: 18-20 months) - 18-24 months: Concerning for most segments - Over 24 months: Requires attention **By segment:** - SMB: 8-12 months typical - Mid-market: 14-18 months typical - Enterprise: 18-24 months typical (longer sales cycles) **What it tells you:** How quickly customers become profitable. Critical for cash management and determining sustainable growth rate. **Sources:** - [Wall Street Prep: CAC Payback Period](https://www.wallstreetprep.com/knowledge/cac-payback-period/) - [Maxio: CAC Payback](https://www.maxio.com/saaspedia/cac-payback) - [Corporate Finance Institute: CAC Payback Period](https://corporatefinanceinstitute.com/resources/valuation/cac-payback-period/) --- ### Gross Margin **Definition:** Revenue minus cost of goods sold (COGS), as a percentage of revenue. Measures profitability after direct delivery costs. **Formula:** ``` Gross Margin = (Revenue (GAAP) - COGS) / Revenue (GAAP) × 100 ``` **Note:** Use GAAP-recognized revenue, not MRR/ARR. Gross Margin is a financial statement metric. **Include in COGS:** - Hosting/infrastructure costs (AWS, Azure, etc.) - Customer Support team (fully burdened: salaries, benefits, tools) - Customer Success team (if retention-focused, not sales) - DevOps team costs - Payment processing fees - Third-party software for product delivery - Capitalized software amortization **Exclude from COGS:** - Sales & Marketing expenses - R&D (product development) - G&A overhead **COGS Test:** "Can customers still access and use the application if I don't pay this expense?" If no → include in COGS. **Fully burdened:** COGS departments should include all costs: wages, bonuses, payroll taxes, benefits, travel, training, internal tools. **Benchmarks (per CloudZero 2025, industry surveys):** - Below 60%: Low, may indicate infrastructure-heavy or services-heavy business - 60-70%: Moderate (Seed/Series A acceptable while scaling) - 70-80%: Good, typical for SaaS (Most VCs require 70%+ for investment) - 75-80%: Series B+ expected, attractive to investors - 80-85%: Best-in-class (commands valuation premium) **What it tells you:** How much of each dollar of revenue is available after delivery costs. Higher margins = more scalable business. **Sources:** - [The SaaS CFO: How to Calculate SaaS Gross Margin](https://www.thesaascfo.com/how-to-calculate-saas-gross-margin/) - [CloudZero: SaaS Gross Margin](https://www.cloudzero.com/blog/saas-gross-margin/) - [Drivetrain: SaaS Gross Margin](https://www.drivetrain.ai/strategic-finance-glossary/saas-gross-margin) #### Operating Form: Contribution Margin (GM-O) Contribution Margin is revenue minus all variable costs per customer. It shows true per-customer profitability after all costs that scale with the customer base. **CEL Source:** `Revenue_Event`, `Cost_Event` **ATL Inclusion for costs:** `cost_function` ∈ (`Infrastructure`, `Support`, `Success_Engineering`, `Implementation`, `Onboarding`) **Formula:** ``` GM-O = (Revenue − COGS − Support − CS − Implementation − Onboarding) / Revenue × 100 ``` Typical range: 50-70% for SaaS. **What it tells you:** The operating metric because it shows how much profit each customer actually generates after all variable delivery costs. #### Market Form: SaaS Gross Margin (GM-M) SaaS Gross Margin is revenue minus COGS only. Hosting, infrastructure and payment processing. It matches financial statement reporting and investor benchmarks. **CEL Source:** `Revenue_Event`, `Cost_Event` **ATL Inclusion for costs:** `cost_function` = `Infrastructure` **Formula:** ``` GM-M = (Revenue − COGS) / Revenue × 100 ``` Typical range: 70-85% for SaaS. **What it tells you:** The market-comparable gross margin that investors expect at 70%+ for SaaS businesses. **Note:** The existing Gross Margin definition above includes Support and CS in COGS. The conservative allocation approach, which sits between pure GM-O and pure GM-M. Both extremes have industry support. The dual-lens framework makes the choice explicit rather than implicit. #### Bridge: GM-O ↔ GM-M **Reconciliation:** ``` GM-M = GM-O + (Support + CS + Implementation + Onboarding costs) / Revenue × 100 ``` **Diagnostic:** The delta (GM-M − GM-O) is the **Services Drag.** The cost of running a human-intensive customer operation. Declining delta over time signals increasing automation and self-serve adoption. SaaS Capital 2025 guidance on COGS allocation supports both approaches. VCs typically expect 70%+ SaaS gross margin (GM-M) while internal teams should track contribution margin (GM-O) for pricing and unit economics. --- ### Rule of 40 **Definition:** A heuristic that balances growth and profitability. A healthy SaaS company's growth rate plus profit margin should equal 40% or more. **Formula:** ``` Rule of 40 = ARR Growth Rate (YoY %) + EBITDA Margin (%) ``` Where: - **ARR Growth Rate** = (Current ARR - ARR 12 months ago) / ARR 12 months ago × 100 - **EBITDA Margin** = EBITDA / Revenue (GAAP) × 100 **Component definitions:** - **ARR Growth Rate:** Year-over-year percentage change in ARR. Use ARR (not MRR or GAAP revenue) for consistency with SaaS valuation standards. - **EBITDA Margin:** EBITDA as a percentage of GAAP revenue. EBITDA is the most common choice; FCF margin is an acceptable alternative but must be disclosed. **Origin:** Coined by Brad Feld (2015), heard from a late-stage investor. **Applicability:** Use when company reaches ~$1M MRR / $12M ARR. Not meaningful for early-stage startups. **Examples of hitting 40%:** - 60% growth + (-20%) margin = 40% (high growth, investing) - 20% growth + 20% margin = 40% (balanced) - 5% growth + 35% margin = 40% (mature, profitable) **Benchmarks (per McKinsey, Meritech Capital 2024):** - Below 20: Struggling (Median public SaaS Q1 2025: 12-15%) - 20-40: Developing (Median mid-2024: 34%) - 40+: Healthy balance of growth and profitability - 60+: Elite (top quartile: 45%+ growth component) **What it tells you:** Whether you're balancing growth and profitability appropriately. You can grow fast and lose money, or grow slow and be profitable, but the sum should hit 40. **Limitations:** - The "40" is arbitrary, not scientifically derived - Should not be used as pass/fail - Context matters (vertical vs horizontal, market conditions) **Sources:** - [Wall Street Prep: Rule of 40](https://www.wallstreetprep.com/knowledge/rule-of-40/) - [The SaaS CFO: Rule of 40](https://www.thesaascfo.com/rule-of-40-saas/) - [Corporate Finance Institute: Rule of 40](https://corporatefinanceinstitute.com/resources/valuation/rule-of-40/) #### Dual-Lens Note The Rule of 40 is a composite metric. Its dual-lens behaviour is inherited from its inputs: - **Rule of 40-O** = ARR-O Growth Rate + Contribution Margin (GM-O) - **Rule of 40-M** = ARR-M Growth Rate + EBITDA Margin A company with 30% ARR growth and heavy implementation costs might report Rule of 40-M = 45 (healthy) while Rule of 40-O = 32 (below threshold). The gap reveals whether growth-profitability balance holds when true operating costs are included. No separate O/M inclusion rules are needed. Use the ARR and Gross Margin forms defined above. --- ## Summary Table | Metric | Category | Primary Indicator Of | |--------|----------|---------------------| | MRR | Revenue | Business scale | | MRR Growth Rate | Revenue | Growth velocity | | NRR | Retention | Revenue sustainability | | GRR | Retention | Customer relationship health | | Logo Churn | Retention | Customer loss rate | | NPS | Retention | Customer loyalty (leading) | | CAC | Efficiency | Acquisition investment | | LTV:CAC | Efficiency | Unit economics | | CAC Payback | Efficiency | Cash efficiency | | Gross Margin | Efficiency | Delivery efficiency | | Rule of 40 | Efficiency | Growth/profit balance | --- ## Dual-Lens Reference The GASP Standard recognises that core metrics serve two audiences with different needs. Operating forms reflect internal economic truth. Market forms match investor-comparable benchmarks. Both derive from the same [Commercial Event Ledger](../cel.md) using [Attribution Taxonomy Layer](../atl.md) tags. | Metric | Operating (O) | Market (M) | Bridge Diagnostic | |--------|--------------|------------|-------------------| | ARR | ARR-O (excl. pricing/recontracting) | ARR-M (total reported) | Durability Gap | | CAC | Fully Loaded CAC (CAC-O) | GTM CAC (CAC-M) | Activation Delta | | NRR | Cohort NRR (NRR-O) | Account NRR (NRR-M) | Expansion Integrity Gap | | LTV | Contribution LTV (LTV-O) | Gross Margin LTV (LTV-M) | Contribution Leakage | | Churn | Revenue Churn Rate (Churn-O) | Logo Churn Rate (Churn-M) | Concentration vs Long-Tail | | Gross Margin | Contribution Margin (GM-O) | SaaS Gross Margin (GM-M) | Services Drag | | GRR | No O/M distinction. Uniform | n/a | n/a | | Rule of 40 | Inherited from ARR-O + GM-O | Inherited from ARR-M + EBITDA | n/a | For full CEL event classes and ATL tag definitions, see [Commercial Event Ledger](../cel.md) and [Attribution Taxonomy Layer](../atl.md). --- # Sales Metrics Metrics for measuring sales team performance and pipeline health. --- ## Pipeline Metrics ### Pipeline Value **Definition:** Total value of all active sales opportunities. **Formula (weighted):** ``` Pipeline Value = Sum of (Deal value × Stage probability) for all open opportunities ``` **Formula (unweighted):** ``` Pipeline Value = Sum of (Deal value) for all open opportunities ``` Always specify whether weighted or unweighted. **Weighted vs unweighted:** - **Weighted:** More realistic, accounts for deal stage. A $100K deal at 50% stage = $50K weighted value. - **Unweighted:** Simpler, shows total potential. Useful for capacity planning. **What it tells you:** The potential revenue if deals close at expected rates. **Sources:** [Clari](https://www.clari.com/blog/pipeline-coverage-best-practices/), [Salesforce](https://www.salesforce.com/blog/sales-velocity/) --- ### Pipeline Coverage Ratio **Definition:** The ratio of pipeline value to quota for the period. **Formula:** ``` Pipeline Coverage = Total Pipeline Value / Quota for Period ``` Express as multiple (e.g., "3x" or "3:1"). **Why 3x-4x works:** The math is 1 / Win Rate. If you win 25% of deals, you need 4x coverage (1 ÷ 0.25 = 4). If you win 33%, you need 3x. **Benchmarks:** - Below 2x: Insufficient pipeline, high risk of missing quota - 2-3x: Light, acceptable for high win rate teams - 3-4x: Healthy for typical 25-33% win rates - Above 4x: Strong, but may indicate pipeline hygiene issues or low win rates **By segment:** - SMB/high-velocity: 2-3x may suffice - Mid-market: 2.5-4x typical - Enterprise: 3-5x (longer cycles, more stakeholders) **What it tells you:** Whether there's enough pipeline to hit targets given historical conversion rates. **Calculate your ideal:** Use your actual win rate, not generic benchmarks. **Sources:** - [Clari: Pipeline Coverage Best Practices](https://www.clari.com/blog/pipeline-coverage-best-practices/) - [Outreach: Sales Pipeline Coverage Ratio](https://www.outreach.io/resources/blog/sales-pipeline-coverage-ratio) - [Mosaic: Pipeline Coverage Ratio](https://www.mosaic.tech/financial-metrics/pipeline-coverage-ratio) --- ### Pipeline Velocity **Definition:** The speed at which pipeline converts to revenue. Also called Sales Velocity or Deal Velocity. **Formula:** ``` Pipeline Velocity = (# Opportunities × Win Rate × Average Deal Size) / Sales Cycle Length ``` Result is revenue per day (or per period). **The four levers:** 1. **Opportunities** - Number of qualified opportunities in pipeline 2. **Win Rate** - Conversion rate from opportunity to close 3. **Deal Size** - Average deal value (ACV) 4. **Cycle Length** - Days from opportunity to close **Example:** 50 opportunities × 35% win rate × $2,500 deal size ÷ 28 days = **$1,562/day** **What it tells you:** The theoretical throughput of your sales engine. Improving any component improves velocity. **How to use:** Identify which lever is the bottleneck. Not enough leads? Improve opportunities. Deals stuck in negotiation? Reduce cycle length. **Sources:** - [HubSpot: Sales Velocity](https://blog.hubspot.com/sales/sales-velocity) - [Salesforce: Sales Velocity](https://www.salesforce.com/blog/sales-velocity/) - [Drivetrain: Sales Velocity in SaaS](https://www.drivetrain.ai/strategic-finance-glossary/sales-velocity-in-saas-what-it-is-why-its-important-and-how-to-calculate-it) --- ## Conversion Metrics ### Win Rate **Definition:** The percentage of qualified opportunities that close as won. **Formula:** ``` Win Rate = Deals Won / (Deals Won + Deals Lost) × 100 ``` Exclude open deals and deals disqualified before reaching qualified stage. **Overall Benchmarks:** - Below 15%: Low, investigate qualification or competitive issues - 15-25%: Average (industry average ~22-25%) - 25-35%: Good - 35-50%: Strong/top performer **By deal size:** - <$10K ACV: 28-35% - $10K-$50K: 20-28% - $50K-$100K: 15-22% - >$100K: 12-18% **By segment:** - SMB: 30-40% - Mid-market: 25-35% - Enterprise: 20-25% **What it tells you:** How effective the sales team is at closing qualified opportunities. **Common mistakes:** - Including unqualified leads (inflates denominator, deflates rate) - Not specifying stage (win rate from MQL vs SQL vs Qualified Opp will differ dramatically) - Comparing across deal sizes without adjusting expectations **Key insight:** Focus on improvement over time, not hitting arbitrary targets. **Sources:** - [Walnut: B2B Benchmarks for SaaS Sales](https://www.walnut.io/blog/sales-tips/saas-and-b2b-sales-benchmarks-what-to-measure-and-how/) - [Outreach: Win Rate vs Close Rate](https://www.outreach.io/resources/blog/win-rate-vs-close-rate) - [Kixie: SaaS Win Rate Benchmark](https://www.kixie.com/sales-blog/saas-win-rate-benchmark-proven-sales-strategies/) --- ### Lead-to-Opportunity Rate **Definition:** The percentage of leads that become qualified opportunities. **Formula:** ``` Lead-to-Opportunity = Opportunities created / Leads received × 100 ``` **Benchmarks:** - 5-15%: Typical for inbound leads - 1-5%: Typical for outbound/cold leads - Varies significantly by lead source and ICP fit **What it tells you:** Lead quality and SDR/qualification effectiveness. **Sources:** [HubSpot](https://blog.hubspot.com/sales/sales-velocity), [Databox](https://databox.com/b2b-sales-cycle-length) --- ### Opportunity-to-Close Rate **Definition:** The percentage of qualified opportunities that close as won. Also called Close Rate. **Formula:** ``` Opportunity-to-Close = Closed Won / (Closed Won + Closed Lost) × 100 ``` **Note:** This is essentially Win Rate measured from the opportunity stage. **What it tells you:** AE effectiveness at converting qualified pipeline. **Sources:** [Outreach](https://www.outreach.io/resources/blog/win-rate-vs-close-rate) --- ## Deal Metrics ### ACV (Annual Contract Value) **Definition:** The annualized value of a contract, normalizing multi-year deals to a single year. Also used to describe average deal size when aggregated. **Formula (single contract):** ``` ACV = (Total Contract Value - One-time fees) / Contract term in years ``` **Formula (average across deals):** ``` Average ACV = Sum of ACV for all deals / Number of deals ``` **Example:** A 3-year contract worth $150K (excluding setup fees) = $50K ACV. For monthly contracts, annualize: Monthly value × 12 **Excludes:** One-time fees (setup, implementation, training) **ACV vs ARR:** - **ACV** = Value of a single contract, annualized - **ARR** = Total recurring revenue across all customers at a point in time **Typical ranges:** - SMB: <$5K - Mid-market: $25K-$100K - Enterprise: $100K+ **What it tells you:** Deal size and customer segment. Important for CAC analysis and go-to-market strategy. **Sources:** - [Paddle: Annual Contract Value](https://www.paddle.com/resources/annual-contract-value) - [ChurnZero: Annual Contract Value](https://churnzero.com/churnopedia/annual-contract-value-acv/) - [Chargebee: ACV vs ARR](https://www.chargebee.com/resources/glossaries/acv-vs-arr/) --- ### Average Deal Size **Definition:** The average total value of closed deals (total contract value, not annualized). **Formula:** ``` Average Deal Size = Total contract value of closed deals / Number of deals ``` **Difference from ACV:** Average Deal Size uses total contract value (TCV). ACV annualizes multi-year deals. **Example:** A 3-year, $150K deal = $150K deal size, but $50K ACV. **What it tells you:** Raw deal size. Useful when contract lengths vary significantly. **Sources:** [Paddle](https://www.paddle.com/resources/annual-contract-value), [ChurnZero](https://churnzero.com/churnopedia/annual-contract-value-acv/) --- ### Sales Cycle Length **Definition:** The average time from opportunity creation to close. **Formula:** ``` Sales Cycle = Average of (Close date - Opportunity created date) for won deals ``` Measured in days. Use median rather than average to reduce outlier skew. **Benchmarks by segment:** - SMB: 14-40 days - Mid-market: 60-90 days - Enterprise: 90-180+ days **Benchmarks by ACV:** - <$2K ACV: ~14 days (1-2 call close) - <$5K ACV: ~30-40 days - $5K-$25K ACV: ~60-90 days - $25K-$100K ACV: 90-180 days - >$100K ACV: 170+ days (often 6-12 months) - >$500K ACV: 6-18+ months (annual budget cycles) **Overall median:** ~84 days across B2B SaaS **What it tells you:** How long deals take to close. Longer cycles require more pipeline coverage. **Recent trends (2024-2025):** - Cycles 22% longer since 2022 due to budget scrutiny - Average B2B deal involves 6.8 stakeholders (up from 5.4 in 2020) - CFO involvement in software purchases up 40% - Negotiation → Close accounts for 35-40% of enterprise cycle time **Sources:** - [SaaStr: B2B Sales Cycle Benchmarks](https://www.saastr.com/dear-saastr-whats-a-good-benchmark-for-b2b-sales-cycles/) - [Databox: B2B Sales Cycle Length](https://databox.com/b2b-sales-cycle-length) - [Drivetrain: Sales Cycle Length](https://www.drivetrain.ai/strategic-finance-glossary/sales-cycle-length-scl) --- ## Productivity Metrics ### Quota Attainment **Definition:** The percentage of quota achieved by a rep or team. **Formula (individual):** ``` Quota Attainment = Revenue Closed / Quota × 100 ``` **Formula (team):** ``` Team Attainment = Total Team Revenue / Total Team Quota × 100 ``` Or: Average of individual rep attainment rates. **Reality check:** Industry data shows most reps don't hit quota: - Average individual attainment: 43-50% - Only 24% of reps exceed annual quota - 69% of B2B reps fall short of quota **Benchmarks (individual rep):** - Below 50%: Below average - 50-80%: Average range - 80-100%: Strong performer - 100%+: Top performer / exceeding **Benchmarks (team/company):** - 50%: Average (median rep at quota) - 60-70%: Good - 80-90%: Strong - 90%+: Exceptional (or quotas may be too low) **What it tells you:** Sales rep and team performance against targets. **Quota setting rule of thumb:** Quota = 5x rep OTE (ranges from 3x to 8x depending on company stage). **Sources:** - [Forrester: Quota Attainment](https://www.forrester.com/blogs/your-companys-quota-attainment-is-probably-around-50-and-thats-not-a-bad-thing/) - [Wall Street Prep: Quota Attainment](https://www.wallstreetprep.com/knowledge/quota-attainment/) - [QuotaPath: Quota Attainment Rate](https://www.quotapath.com/blog/quota-attainment-rate/) --- ### Revenue per Rep **Definition:** Total revenue generated divided by number of quota-carrying reps. **Formula:** ``` Revenue per Rep = Total New Revenue / Number of Quota-Carrying Reps ``` **Benchmarks (Annual, New Business):** By company stage: - Seed: $250K-$400K - Series A: $400K-$600K - Series B+: $600K-$1M+ By segment: - SMB: $400K-$600K - Mid-market: $600K-$800K - Enterprise: $800K-$1.5M+ **Median B2B SaaS:** $500K-$700K quota capacity **Top performers:** $1M+ annually **What it tells you:** Sales team productivity and efficiency. **Factors affecting output:** - ACV (higher = more per rep possible) - Sales cycle length (longer = less per rep) - Market maturity and brand recognition - Sales support infrastructure (SDRs, tools) **Sources:** - [Optifai: Revenue Per Sales Rep Benchmark 2025](https://optif.ai/learn/questions/revenue-per-sales-rep-benchmark/) - [Revenue.io: Revenue per Rep](https://www.revenue.io/inside-sales-glossary/what-is-revenue-per-rep) --- ### Ramp Time **Definition:** Time for a new sales rep to reach full productivity (carrying full quota). **Formula:** ``` Ramp Time = Time from start date to consistently achieving quota ``` **Common calculation:** Average sales cycle + 90 days (for onboarding/training) Measured in months. **Benchmarks by role:** - SDR: 2-3 months - Inside Sales/SMB AE: 3-4 months - Mid-market AE: 4-6 months - Enterprise AE: 6-9 months **Industry averages:** - Average SaaS ramp: 3.2-5 months - 41% of companies report 5+ months - Top performers target 3-4 months **Ramp quota structure (typical):** - Month 1: 25% quota - Month 2: 50% quota - Month 3: 75% quota - Month 4+: 100% quota **What it tells you:** How quickly new hires become productive. Impacts hiring planning and capacity forecasting. **Sources:** - [Mosaic: Sales Rep Ramp](https://www.mosaic.tech/financial-metrics/sales-rep-ramp) - [Revenue.io: Sales Ramp Time](https://www.revenue.io/blog/heres-how-long-it-should-take-for-your-sales-reps-to-be-at-fully-ramped-quota) - [Everstage: Sales Ramp Time](https://www.everstage.com/blog/how-to-determine-the-right-sales-ramp-up-time-for-reps) --- ### Activity Metrics (Diagnostic) These are inputs, not outcomes. Track for diagnostics, not reporting. | Metric | Definition | |--------|------------| | Calls per day | Outbound calls made | | Emails per day | Outbound emails sent | | Meetings booked | Discovery/demo meetings scheduled | | Demos delivered | Product demonstrations completed | --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | Pipeline Value | Pipeline | Total opportunity | | Pipeline Coverage | Pipeline | Risk to hitting quota | | Win Rate | Conversion | Sales effectiveness | | Lead-to-Opportunity | Conversion | Lead quality + qualification | | ACV | Deal | Deal size, segmentation | | Sales Cycle | Deal | Time to revenue | | Quota Attainment | Productivity | Rep performance | | Revenue per Rep | Productivity | Team efficiency | --- # Marketing Metrics Metrics for measuring marketing performance, demand generation and brand health. --- ## Funnel Metrics ### Visitors **Definition:** Unique visitors to owned properties (website, app). **Formula:** ``` Visitors = Unique visitors in period ``` **What it tells you:** Top of funnel awareness and reach. --- ### Visitor-to-Lead Rate **Definition:** Percentage of website visitors who become leads. **Formula:** ``` Visitor-to-Lead = Leads captured / Visitors × 100 ``` **Benchmarks:** - Below 2%: Below average, optimize capture - 2-3%: Average for B2B websites - 3-7%: Good (majority of SaaS market) - 7-12%: Excellent / top performers **By channel:** - Referral traffic: ~2.9% - Organic search: ~2.6% - Email: ~2.4% - Paid search: 1.5-3.2% - Social: ~1% or less **Free trial impact:** - With credit card required: ~2% - Without credit card: ~10% **What it tells you:** Website and content effectiveness at capturing interest. **Sources:** - [First Page Sage: B2B SaaS Funnel Benchmarks](https://firstpagesage.com/seo-blog/b2b-saas-funnel-conversion-benchmarks-fc/) - [Userpilot: B2B SaaS Funnel Conversion](https://userpilot.com/blog/b2b-saas-funnel-conversion-benchmarks/) --- ### Leads **Definition:** Contacts who have expressed interest (form fill, signup, etc.). **Formula:** ``` Leads = Total new leads captured in period ``` Break down by source: organic, paid, referral, direct, events. --- ### Marketing Qualified Leads (MQLs) **Definition:** Leads that have demonstrated sufficient engagement and intent to warrant sales attention, based on criteria established between marketing and sales. **MQL criteria (typical):** - **Behavioral:** Demo requests, pricing page visits, content downloads, webinar attendance - **Firmographic:** Company size, industry, role matches ICP - **Engagement:** Lead score threshold reached **High-intent signals (prioritize these):** - Demo/trial requests - Pricing page visits - Buying guide downloads - Contact sales form fills **Formula:** ``` MQLs = Leads meeting MQL criteria in period ``` **What it tells you:** Volume of potentially sales-ready prospects. **Key distinction:** MQLs show engagement but not confirmed buying intent. SQLs pass sales qualification (BANT: Budget, Authority, Need, Timeline). **Sources:** - [Gartner: MQL vs SQL](https://www.gartner.com/en/digital-markets/insights/marketing-qualified-lead-vs-sales-qualified-lead) - [MetricHQ: MQL to SQL](https://www.metrichq.org/marketing/mql-to-sql-conversion-rate/) --- ### Lead-to-MQL Rate **Definition:** Percentage of leads that become MQLs. **Formula:** ``` Lead-to-MQL = MQLs / Total leads × 100 ``` **Benchmarks:** - Below 15%: Low quality leads or strict MQL criteria - 15-30%: Average - 30-50%: Good quality leads - Above 50%: May indicate loose criteria --- ### Sales Qualified Leads (SQLs) **Definition:** MQLs accepted by sales as worth pursuing. **Formula:** ``` SQLs = MQLs accepted by sales in period ``` **What it tells you:** Marketing and sales alignment on lead quality. --- ### MQL-to-SQL Rate **Definition:** Percentage of MQLs accepted by sales as qualified. **Formula:** ``` MQL-to-SQL = SQLs / MQLs × 100 ``` **Benchmarks:** - Overall average (all industries): ~13% - B2B SaaS average: 20-30% - B2B SaaS top performers: 40%+ - Website leads: ~31% - Referral leads: Highest conversion **By lead scoring approach:** - Basic demographic scoring: ~20% - Behavioral scoring models: 39-40% **Speed-to-lead impact:** - Response within 1 hour: 53% conversion - Response after 24 hours: 17% conversion **What it tells you:** Quality of MQLs from sales perspective and marketing-sales alignment. **Sources:** - [MetricHQ: MQL to SQL Conversion Rate](https://www.metrichq.org/marketing/mql-to-sql-conversion-rate/) - [Geckoboard: MQL to SQL](https://www.geckoboard.com/best-practice/kpi-examples/mql-to-sql-conversion-rate/) - [Data-Mania: MQL to SQL Benchmarks](https://www.data-mania.com/blog/mql-to-sql-conversion-rate-benchmarks-2025/) --- ### SQL-to-Opportunity Rate **Definition:** Percentage of SQLs that become pipeline opportunities. **Formula:** ``` SQL-to-Opp = Opportunities created / SQLs × 100 ``` **Benchmarks:** - Below 30%: Low conversion - 30-50%: Average - Above 50%: Good --- ### Lead Velocity Rate (LVR) **Definition:** Month-over-month growth in qualified leads. Considered by many to be the most important leading indicator in SaaS. **Formula:** ``` LVR = (Qualified leads this month - Qualified leads last month) / Qualified leads last month × 100 ``` **Origin:** Popularized by Jason Lemkin (SaaStr), who calls it "the most important metric in SaaS" because it predicts future revenue 12-18 months out. **Why it matters:** Revenue is a lagging indicator (tells you about the past). LVR is real-time and predicts the future. **Benchmarks (per Jason Lemkin):** - 10%/month: Target after $1M ARR - 8%/month: Target after $3M ARR (supports 100%+ YoY growth) **Critical:** Must use **qualified** leads (MQLs), not raw leads. Otherwise it becomes a vanity metric. **What it tells you:** Pipeline growth momentum. If LVR is consistently positive, you have the raw ingredients for growth. **Limitation:** Doesn't measure conversion quality. Track alongside MRR growth. **Sources:** - [SaaStr: Why LVR Is The Most Important Metric](https://www.saastr.com/why-lead-velocity-rate-lvr-is-the-most-important-metric-in-saas/) - [Wall Street Prep: Lead Velocity Rate](https://www.wallstreetprep.com/knowledge/lead-velocity-rate-lvr/) - [Corporate Finance Institute: LVR](https://corporatefinanceinstitute.com/resources/valuation/lead-velocity-rate-lvr/) --- ## Efficiency Metrics ### Customer Acquisition Cost (CAC) See [Core Metrics](https://gaspwiki.com/v1/metrics/core#cac-customer-acquisition-cost) for full definition. Marketing typically owns a portion of CAC (marketing spend / new customers). --- ### Marketing CAC **Definition:** Marketing-only portion of acquisition cost. **Formula:** ``` Marketing CAC = Marketing spend / New customers acquired ``` **What it tells you:** Marketing efficiency at generating customers. --- ### CAC by Channel **Definition:** Customer acquisition cost broken down by marketing channel. **Formula:** ``` Channel CAC = Channel spend / Customers acquired via channel ``` **Channels:** Paid search, paid social, organic, content, events, referral, partner. **What it tells you:** Which channels are most efficient. --- ### Cost per Lead (CPL) **Definition:** Cost to acquire a lead. **Formula:** ``` CPL = Marketing spend / Leads generated ``` **What it tells you:** Top-of-funnel efficiency. --- ### Cost per MQL **Definition:** Cost to acquire a marketing qualified lead. **Formula:** ``` Cost per MQL = Marketing spend / MQLs generated ``` **Benchmarks (B2B SaaS 2025):** - Average range: $30-$120 - SMB-focused: $50-$150 - Mid-market: $150-$400 - Enterprise: $400-$1000+ **Cost per Lead (CPL) for context:** - B2B SaaS paid channels: ~$310 - B2B SaaS organic: ~$164 - Blended average: ~$237 - Demo request leads: $600-$800 **By channel:** - Google Ads: $150-$250 - LinkedIn: $100-$200 - Bing: $80-$180 - SEO/Organic: Significantly lower **What it tells you:** Lead generation efficiency and channel performance. **Sources:** - [SaaS Capital: Spending Benchmarks 2025](https://www.saas-capital.com/blog-posts/spending-benchmarks-for-private-b2b-saas-companies/) - [Martal: B2B Marketing ROI Benchmarks](https://martal.ca/b2b-digital-marketing-benchmarks-lb/) --- ### Marketing Sourced Pipeline **Definition:** Pipeline value attributed to marketing efforts (first-touch attribution). **Formula:** ``` Marketing Sourced Pipeline = Sum of opportunity value where first touch = marketing ``` **Benchmark:** Strong programs generate 30-50% of sales pipeline from marketing. **What it tells you:** Marketing's contribution to sales pipeline. --- ### Marketing Sourced Revenue **Definition:** Closed revenue attributed to marketing efforts (first-touch attribution). **Formula:** ``` Marketing Sourced Revenue = Sum of closed won revenue where first touch = marketing ``` **What it tells you:** Marketing's contribution to actual revenue. --- ### Marketing Influenced Pipeline/Revenue **Definition:** Pipeline or revenue where marketing touched the deal at any point (multi-touch attribution). **Formula:** ``` Marketing Influenced = Pipeline/Revenue where any touch = marketing ``` Typically 2-3x higher than sourced (multiple touches on most B2B deals). **Note:** B2B buyers average 6-8 touches before purchase, so influenced is often more representative than sourced. **Sources:** - [SaaS Capital: Spending Benchmarks](https://www.saas-capital.com/blog-posts/spending-benchmarks-for-private-b2b-saas-companies/) - [Digital Bloom: Pipeline Performance Benchmarks](https://thedigitalbloom.com/learn/pipeline-performance-benchmarks-2025/) --- ## Channel Metrics ### Organic Traffic **Definition:** Visitors from unpaid search. **Formula:** ``` Organic Traffic = Visitors where source = organic search ``` **What it tells you:** SEO effectiveness and brand awareness. --- ### Paid Media Efficiency (ROAS) **Definition:** Return on ad spend. **Formula:** ``` ROAS = Revenue attributed to ads / Ad spend ``` Express as ratio (e.g., "3:1" or "3x"). **B2B SaaS Benchmarks:** - Below 2x: Below average, but may be acceptable if LTV is high - 2-3x: Average for mid-market SaaS - 3-4x: Good - 4x+: Strong / top quartile **By segment:** - Enterprise: 2-3x typical (long sales cycles) - Mid-market SaaS: 2.6x average, 4.1x top quartile - SMB: Higher ROAS expected **By channel:** - Google Ads (Search): ~2.8x average - LinkedIn: ~2.2x average - Facebook: ~1.9x average - Branded search: Very high (captures existing intent) **Important:** Lower ROAS can be acceptable if customer LTV is high. Always consider LTV:CAC alongside ROAS. **Sources:** - [Varos: Google ROAS for B2B SaaS](https://varos.com/benchmarks/google-roas-for-b2b-saas) - [Directive: B2B ROAS Benchmarks 2025](https://directiveconsulting.com/blog/b2b-roas-benchmarks-high-performing-campaigns-in-2025/) --- ### Email Metrics | Metric | Formula | B2B SaaS Benchmark | |--------|---------|-----------| | Open Rate | Opens / Delivered × 100 | 25-40% | | Click Rate (CTR) | Clicks / Delivered × 100 | 2-4% | | Click-to-Open Rate | Clicks / Opens × 100 | 5-7% | | Unsubscribe Rate | Unsubscribes / Delivered × 100 | <0.3% | | Bounce Rate | Bounces / Sent × 100 | <2.5% | | Spam Complaint Rate | Complaints / Delivered × 100 | <0.1% | **Cold email/outbound (SaaS SDRs):** - Open rate: 38-42% - Reply rate: 3-8% (good: 5-10%) - Meeting booked rate: 1-2% **Important:** Apple Mail Privacy Protection (46% of email clients) inflates open rates by preloading images. Treat opens as directional only; focus on replies and conversions. **Sources:** - [HubSpot: Email Marketing Benchmarks](https://blog.hubspot.com/sales/average-email-open-rate-benchmark) - [GetResponse: Email Marketing Benchmarks 2024](https://www.getresponse.com/resources/reports/email-marketing-benchmarks) - [SalesHive: B2B SaaS Email Benchmarks 2025](https://saleshive.com/blog/b2b-benchmarks-email-marketing-saas-you-need-know-2025/) --- ### Content Performance | Metric | Formula | |--------|---------| | Downloads | Content pieces downloaded | | Engagement Rate | Engaged visitors / Total visitors × 100 | | Content-to-MQL | MQLs from content / Content engagements × 100 | --- ## Brand Metrics ### Brand Awareness **Definition:** Percentage of target market aware of brand. **Measurement:** Survey-based or search volume proxy. --- ### Share of Voice **Definition:** Brand mentions relative to competitors. **Formula:** ``` Share of Voice = Brand mentions / (Brand + Competitor mentions) × 100 ``` --- ### NPS (Marketing context) **Definition:** Net Promoter Score for prospects/market (vs customers). **What it tells you:** Brand perception in broader market. --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | MQLs | Funnel | Marketing output | | MQL-to-SQL Rate | Funnel | Lead quality | | Lead Velocity Rate | Funnel | Pipeline momentum | | Marketing CAC | Efficiency | Marketing cost efficiency | | Cost per MQL | Efficiency | Lead generation efficiency | | Marketing Sourced Pipeline | Attribution | Marketing contribution | | ROAS | Channel | Paid media efficiency | | Organic Traffic | Channel | SEO and brand strength | --- # Customer Success Metrics Metrics for measuring customer health, retention and expansion. **Note:** NRR and GRR definitions are defined in [Core Metrics](https://gaspwiki.com/v1/metrics/core). --- ## Retention Metrics ### Net Revenue Retention (NRR) See [Core Metrics](https://gaspwiki.com/v1/metrics/core#net-revenue-retention-nrr) for full definition. Customer Success owns NRR as the primary outcome metric. --- ### Gross Revenue Retention (GRR) See [Core Metrics](https://gaspwiki.com/v1/metrics/core#gross-revenue-retention-grr) for full definition. GRR isolates the retention component, removing the influence of expansion. --- ### Logo Retention Rate **Definition:** The percentage of customers retained over a period. **Formula:** ``` Logo Retention Rate = (Customers at end - New customers) / Customers at start × 100 ``` Or simply: ``` Logo Retention Rate = 100% - Logo Churn Rate ``` **What it tells you:** Customer retention independent of revenue. Are you keeping relationships? --- ## Health Metrics ### Customer Health Score **Definition:** A composite score predicting likelihood of retention or churn. **Formula:** ``` Health Score = Weighted average of health indicators ``` **Core indicators (choose 5-10):** | Indicator | Typical Weight | What it measures | |-----------|----------------|------------------| | Product usage frequency | 25-35% | Are they using it regularly? | | Feature adoption depth | 15-25% | Are they using key features? | | Support sentiment | 10-20% | Are support interactions positive? | | Engagement/responsiveness | 10-15% | Do they respond to outreach? | | Contract/renewal status | 5-15% | How long until renewal? | | Payment health | 5-10% | Do they pay on time? | | Onboarding completion | 5-10% | Did they fully onboard? | **Important:** Weights should be customized based on correlation with actual churn in your business. Usage and adoption typically carry the most weight. Segment customers (by size, industry, lifecycle stage) for more accurate scoring. **Scoring:** - 0-40: At risk (red) - 40-70: Needs attention (yellow) - 70-100: Healthy (green) **What it tells you:** Which customers need attention before they churn. **Industry adoption:** Only ~42% of CS teams track health scores, despite evidence that AI-enhanced scoring can predict churn 3-6 months in advance with 85%+ accuracy. **Sources:** - [Gainsight: Customer Health Score](https://www.gainsight.com/blog/customer-health-score/) - [Vitally: Customer Health Score Guide](https://www.vitally.io/post/how-to-create-a-customer-health-score-with-four-metrics) - [Custify: Customer Health Score Guide](https://www.custify.com/blog/customer-health-score-guide/) --- ### Health Score Coverage **Definition:** The percentage of customers with a health score calculated. **Formula:** ``` Health Score Coverage = Customers with health score / Total customers × 100 ``` **Target:** 100% of managed accounts, or all accounts above a revenue threshold. **What it tells you:** Whether you have visibility into customer health. --- ### At-Risk Customer Rate **Definition:** The percentage of customers flagged as at-risk. **Formula:** ``` At-Risk Rate = Customers with health score < 40 / Total scored customers × 100 ``` **Benchmarks:** - Below 5%: Healthy portfolio - 5-10%: Normal, requires attention - 10-20%: Elevated risk - Above 20%: Portfolio in trouble --- ## Engagement Metrics ### Quarterly Business Review (QBR) Completion Rate **Definition:** The percentage of eligible accounts that completed a QBR. **Formula:** ``` QBR Completion = QBRs completed / QBRs scheduled × 100 ``` **Target:** 90%+ for enterprise/strategic accounts **What it tells you:** Are you maintaining strategic relationships? --- ### Executive Sponsor Coverage **Definition:** The percentage of accounts with an identified and engaged executive sponsor. **Formula:** ``` Exec Sponsor Coverage = Accounts with active exec sponsor / Total managed accounts × 100 ``` **What it tells you:** Do you have senior relationships? Predicts resilience during renewals. --- ### Contact Coverage **Definition:** Average number of engaged contacts per account. **Formula:** ``` Contact Coverage = Total engaged contacts / Number of accounts ``` **Target:** 3+ contacts per account **What it tells you:** Are you single-threaded? Multi-threading reduces churn risk. --- ## Expansion Metrics ### Expansion Revenue Rate **Definition:** Expansion MRR as a percentage of beginning MRR. **Formula:** ``` Expansion Rate = Expansion MRR / Beginning MRR × 100 ``` **Benchmarks:** - Below 10%: Limited expansion motion - 10-20%: Moderate, typical for early-stage - 20-30%: Strong, solid benchmark for growth stage - 30-40%: Excellent, typical at $15M+ ARR - 40%+: Exceptional, common in usage-based or high-ARPA models **By company stage:** - Early stage (<$1M ARR): ~10% from expansion (90% new customers) - Growth stage ($1M-$20M ARR): 20-30% from expansion - Scale stage ($20M+ ARR): 35%+ from expansion - Mature ($200M+ ARR): Up to 66% from expansion **What it tells you:** Are you growing existing customers? As companies mature, expansion becomes the dominant growth driver. **Sources:** - [Ordway: New vs Expansion ARR](https://ordwaylabs.com/blog/new-versus-expansion-arr/) - [High Alpha: 2025 SaaS Benchmarks](https://www.highalpha.com/saas-benchmarks) - [ChartMogul: SaaS Benchmarks Report](https://chartmogul.com/reports/saas-benchmarks-report/) --- ### Upsell Rate **Definition:** The percentage of eligible customers who upgraded. **Formula:** ``` Upsell Rate = Customers who upgraded / Customers eligible for upgrade × 100 ``` **What it tells you:** Upgrade conversion effectiveness. --- ### Cross-sell Rate **Definition:** The percentage of customers who purchased additional products. **Formula:** ``` Cross-sell Rate = Customers who bought additional product / Total customers × 100 ``` **What it tells you:** Multi-product adoption and stickiness. --- ## Renewal Metrics ### Renewal Rate **Definition:** The percentage of contracts renewed at term. **Formula (by logo):** ``` Renewal Rate = Contracts renewed / Contracts up for renewal × 100 ``` **Formula (by value):** ``` Renewal Rate = ARR renewed / ARR up for renewal × 100 ``` Always specify logo or value basis. **Benchmarks:** - Below 85%: Concerning, indicates retention problem - 85-90%: Below average - 90-95%: Good (90% is the industry norm per 2025 data) - 95%+: Excellent, top-quartile performance **By segment:** - SMB: 85%+ is good (higher churn expected) - Mid-market: 90%+ is good - Enterprise: 95%+ expected **Sources:** - [Maxio: 2025 B2B SaaS Benchmarks](https://www.maxio.com/resources/2025-saas-benchmarks-report) - [Recurly: Churn Rate Benchmarks](https://recurly.com/research/churn-rate-benchmarks/) --- ### Renewal Forecast Accuracy **Definition:** How accurately renewals were predicted. **Formula:** ``` Forecast Accuracy = 1 - |Forecasted renewals - Actual renewals| / Actual renewals ``` **Target:** >90% **What it tells you:** Can you predict revenue? Important for planning. --- ### Days to Renewal **Definition:** Average number of days until upcoming renewals. **What it tells you:** Renewal workload distribution. If clustered, capacity may be strained. --- ## Productivity Metrics ### Accounts per CSM **Definition:** The number of accounts assigned to each Customer Success Manager. **Formula:** ``` Accounts per CSM = Total managed accounts / Number of CSMs ``` **Benchmarks by touch model:** | Model | Accounts per CSM | Typical ACV | |-------|------------------|-------------| | High-touch Enterprise | 10-50 (median ~22) | $100K+ | | Mid-touch | 50-100 (median ~49) | $25K-$100K | | Low-touch/SMB | 100-250 | $5K-$25K | | Tech-touch/Digital | 300-500+ | <$5K | **By account value:** - <$25K ACV: Up to 200 accounts - $25K-$100K: 100-150 accounts - $100K-$500K: 50-100 accounts - $500K+: 10-25 accounts (high-touch required) **Important:** There's no universal standard. The right ratio depends on product complexity, customer needs and engagement model. Calculate based on capacity: reserve ~2/3 of CSM time for customer-facing work. **Sources:** - [Gainsight: CSM Ratio Benchmarks](https://www.gainsight.com/blog/gainsight-horizon-ai-labs-what-is-the-right-csm-to-customer-ratio/) - [Vitally: CSM to Customer Ratio](https://www.vitally.io/post/what-is-the-golden-ratio-of-customer-success-managers-to-customers) - [ChurnZero: CSM Coverage Ratio](https://churnzero.com/blog/customer-success-manager-coverage-ratio-arr/) --- ### ARR per CSM **Definition:** Total ARR managed by each CSM. **Formula:** ``` ARR per CSM = Total managed ARR / Number of CSMs ``` **Benchmarks:** | Segment | ARR per CSM | |---------|-------------| | Enterprise | $2M-$5M (69% manage >$2M) | | Mid-market | $2M-$5M (spread across more accounts) | | SMB | $1M-$2M | **Distribution (Gainsight data):** - Median (50th percentile): $1.4M - Top quartile (75th percentile): $4.2M **Common rule of thumb:** Hire 1 CSM per $2M ARR. **CS team cost benchmark:** Customer Success should cost 5-15% of ARR (under 10% for companies >$100M ARR). **What it tells you:** CSM productivity and capacity planning. **Sources:** - [Gainsight: CS Team Planning & Cost Benchmarks](https://www.gainsight.com/blog/customer-success-team-planning-cost-benchmarks/) - [ChurnZero: CS Capacity Planning](https://churnzero.com/blog/customer-success-capacity-planning-and-budget-guide/) - [Tomasz Tunguz: How Much ARR Can a CSM Manage?](https://tomtunguz.com/how-much-arr-can-a-csm-manage/) --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | NRR | Retention | Revenue sustainability | | GRR | Retention | Baseline retention health | | Customer Health Score | Health | Churn risk prediction | | At-Risk Rate | Health | Portfolio risk level | | Expansion Rate | Growth | Upsell/cross-sell effectiveness | | Renewal Rate | Retention | Contract renewal success | | Accounts per CSM | Productivity | Team capacity | --- # Customer Support Metrics Metrics for measuring support team performance and customer service quality. **Benchmark context:** B2B SaaS companies typically spend ~8% of ARR on support and success combined. --- ## Volume Metrics ### Ticket Volume **Definition:** Total number of support tickets received in a period. **Formula:** ``` Ticket Volume = Count of tickets created in period ``` Track by channel: email, chat, phone, self-service. **What it tells you:** Support demand. Trend matters more than absolute number. --- ### Tickets per Customer **Definition:** Average tickets created per active customer. **Formula:** ``` Tickets per Customer = Total tickets / Active customers ``` **Benchmarks:** - Below 0.5/month: Low touch, efficient product - 0.5-1.0/month: Typical - Above 1.0/month: High touch, may indicate product issues **What it tells you:** Support burden relative to customer base. Rising ratio signals product or onboarding issues. --- ### Ticket Backlog **Definition:** Number of open tickets awaiting resolution. **Formula:** ``` Backlog = Count of open tickets ``` **What it tells you:** Current support debt. Should be stable or declining. --- ### Ticket Distribution by Type **Definition:** Breakdown of tickets by category. **Categories (typical):** - How-to / Usage questions - Bug reports - Feature requests - Billing inquiries - Account issues - Outage/incident related **What it tells you:** What's driving support volume. High "how-to" suggests onboarding or documentation gaps. --- ## Response Metrics ### First Response Time (FRT) **Definition:** Time from ticket creation to first human response. **Formula:** ``` FRT = Median of (First response timestamp - Ticket created timestamp) ``` Use median, not average (outliers skew averages). **Benchmarks:** | Channel | Target | Reality | |---------|--------|---------| | Chat | < 1 minute | Best channel for speed | | Email (B2B) | 4-6 hours | Industry average is 12+ hours | | Email (Enterprise) | < 1 hour | Premium SLA expected | | Phone | < 30 seconds (80% within 20 sec) | "80/20 rule" standard | **Customer expectations:** 52% expect email responses within 1 hour, 32% within 30 minutes. **What it tells you:** How quickly customers get acknowledged. Impacts satisfaction. **Sources:** - [Zendesk: Customer Service Benchmark](https://www.zendesk.com/blog/first-contact-resolution-friend-foe-frenemy/) - [Freshworks: Customer Service Benchmark 2024](https://www.freshworks.com/resources/customer-service-benchmark-report-2024/) --- ### First Response SLA Adherence **Definition:** Percentage of tickets meeting FRT SLA target. **Formula:** ``` FRT SLA Adherence = Tickets meeting FRT target / Total tickets × 100 ``` **Target:** >95% --- ## Resolution Metrics ### Resolution Time (Time to Resolution) **Definition:** Time from ticket creation to final resolution. **Formula:** ``` Resolution Time = Median of (Resolution timestamp - Ticket created timestamp) ``` **Benchmarks:** - Simple issues: < 4 hours - Moderate issues: < 24 hours - Complex issues: < 72 hours **What it tells you:** How quickly problems are actually solved. --- ### First Contact Resolution (FCR) **Definition:** Percentage of tickets resolved in a single interaction. **Formula:** ``` FCR = Tickets resolved without reopening or follow-up / Total tickets × 100 ``` **Benchmarks:** - Below 60%: Low, investigate agent training or issue complexity - 60-70%: Below average - 70%: Industry average (SQM Group 2024 data) - 70-80%: Good, competitive for SaaS - 80%+: World-class **Industry variation:** Retail/simple products achieve 73-75%. Complex tech support often 50-65%. **Impact:** FCR improvements reduce churn by up to 67% (research shows it's the #1 support driver of retention). **What it tells you:** Support efficiency and agent capability. **Sources:** - [SQM Group: FCR Benchmark 2024](https://www.sqmgroup.com/resources/library/blog/call-center-fcr-benchmark-2024-results-by-industry) - [Geckoboard: FCR Rate](https://www.geckoboard.com/best-practice/kpi-examples/first-contact-resolution-rate/) --- ### Resolution SLA Adherence **Definition:** Percentage of tickets resolved within SLA timeframe. **Formula:** ``` Resolution SLA Adherence = Tickets meeting resolution target / Total tickets × 100 ``` **Target:** >90% --- ### Reopen Rate **Definition:** Percentage of resolved tickets that are reopened. **Formula:** ``` Reopen Rate = Tickets reopened / Tickets resolved × 100 ``` **Benchmarks:** - Below 5%: Good - 5-10%: Acceptable - Above 10%: Investigate resolution quality **What it tells you:** Resolution quality. High reopen rate means problems aren't actually being solved. --- ## Quality Metrics ### Customer Satisfaction Score (CSAT) **Definition:** Customer rating of support interaction. **Formula:** ``` CSAT = Positive responses / Total responses × 100 ``` Typically 5-point or 3-point scale. "Positive" = top 1-2 ratings. **Benchmarks:** - Below 70%: Poor, requires immediate attention - 70-80%: Below average (B2B SaaS average is ~68-78%) - 80-90%: Good - 90%+: Excellent - 95%+: World-class **By channel:** - Live chat: 87% average (highest) - Email: 61% average - Phone: 44% average **Segment variation:** Enterprise customers typically rate 72-75% (dedicated support), SMB customers 60-65%. **What it tells you:** Customer perception of support quality. **Common mistakes:** - Low response rates (<10% makes data unreliable) - Survey fatigue - Not following up on negative feedback **Sources:** - [Retently: CSAT Benchmarks 2025](https://www.retently.com/blog/customer-satisfaction-score-csat/) - [Fullview: CSAT Benchmarks by Industry](https://www.fullview.io/blog/csat-benchmarks-by-industry) --- ### Customer Effort Score (CES) **Definition:** How easy it was for the customer to get help. **Formula:** ``` CES = Average rating on "How easy was it to resolve your issue?" (1-7 scale) ``` Or as percentage (when using agree/disagree scale): ``` CES % = Respondents who agree it was easy / Total respondents × 100 ``` **Benchmarks (1-7 scale):** - Below 4: High effort, frustrating - 4-5: Moderate - 5-6: Good - Above 6: Easy, effortless **Benchmarks (percentage):** - Below 70%: Needs improvement (per Gartner) - 70-90%: Good - Above 90%: Excellent, strong position **Why CES matters:** CES is 1.8x more effective than CSAT at predicting customer loyalty. Reducing friction drives repeat business more than satisfaction. **What it tells you:** Support friction. Lower effort correlates with retention. **Sources:** - [Gartner: Customer Effort Score](https://www.gartner.com/en/customer-service-support/insights/customer-effort-score) - [Userpilot: Customer Satisfaction Benchmarking](https://userpilot.com/blog/customer-satisfaction-benchmarking/) --- ### Escalation Rate **Definition:** Percentage of tickets escalated to higher tier or engineering. **Formula:** ``` Escalation Rate = Escalated tickets / Total tickets × 100 ``` **Benchmarks:** - Below 5%: Well-handled at Tier 1 - 5-15%: Normal - Above 15%: May indicate training gaps or product issues **What it tells you:** Issue complexity and Tier 1 capability. --- ## Efficiency Metrics ### Tickets per Agent **Definition:** Average tickets handled per support agent. **Formula:** ``` Tickets per Agent = Total tickets handled / Number of agents ``` **Benchmarks:** - Chat: 300-500/month - Email: 400-600/month - Phone: 200-400/month **What it tells you:** Agent productivity and capacity planning. --- ### Cost per Ticket **Definition:** Total support cost divided by tickets handled. **Formula:** ``` Cost per Ticket = Total support team cost / Total tickets resolved ``` **Benchmarks:** - Chat: $3-8 - Email: $5-15 - Phone: $10-25 **What it tells you:** Support efficiency. Target: decrease over time. --- ### Self-Service Rate (Ticket Deflection) **Definition:** Percentage of support needs resolved through self-service. **Formula:** ``` Self-Service Rate = Self-service resolutions / (Self-service + Tickets) × 100 ``` Requires tracking help center views, chatbot resolutions, etc. **Benchmarks:** - Below 20%: Low self-service adoption - 20-40%: Moderate - 40-60%: Good - Above 60%: Excellent **What it tells you:** Documentation and tooling effectiveness. --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | Ticket Volume | Volume | Support demand | | Tickets per Customer | Volume | Product/support burden | | First Response Time | Response | Initial responsiveness | | Resolution Time | Resolution | Problem-solving speed | | First Contact Resolution | Resolution | Efficiency | | CSAT | Quality | Customer satisfaction | | Escalation Rate | Quality | Issue complexity | | Cost per Ticket | Efficiency | Support economics | | Self-Service Rate | Efficiency | Deflection effectiveness | --- # Customer Onboarding Metrics Metrics for measuring customer onboarding effectiveness and time to value. **Key insight:** Effective onboarding reduces churn by up to 67% (Wyzowl research). Time to First Value and Activation Rate are the two most predictive onboarding metrics. --- ## Time Metrics ### Time to First Value (TTFV) **Definition:** Time from customer signup/contract to achieving first meaningful value. **Formula:** ``` TTFV = Median of (First value milestone date - Contract start date) ``` **First value milestone (examples):** - First successful transaction processed - First report generated - First integration completed - First core workflow executed **Benchmarks (per Userpilot 2024 data):** | Model | TTFV Target | |-------|-------------| | PLG/Self-serve | ~1.5 days (median: 1 day 2 hours) | | SMB with implementation | 1-2 weeks | | Mid-market | 2-4 weeks | | Enterprise | 4-12 weeks | **By industry:** - CRM/Sales tools: Faster (simpler onboarding) - Insurance/Martech: Longer (complex products) **By growth model:** - Sales-led: Slightly faster (paid upfront, motivated) - Product-led: Longer (free trials attract less committed users) **What it tells you:** How quickly customers realize value. Directly impacts retention. **Sources:** - [Userpilot: Time-to-Value Benchmark Report 2024](https://userpilot.com/blog/time-to-value-benchmark-report-2024/) - [Userpilot: SaaS Product Metrics](https://userpilot.com/saas-product-metrics/) --- ### Time to Go-Live **Definition:** Time from contract to production deployment. **Formula:** ``` Time to Go-Live = Median of (Go-live date - Contract start date) ``` **What it tells you:** Implementation efficiency. --- ### Time to Full Adoption **Definition:** Time from contract to using all purchased features/modules. **Formula:** ``` Time to Full Adoption = Median of (Full adoption date - Contract start date) ``` **What it tells you:** How long until customers are fully utilizing what they paid for. --- ### Onboarding Duration **Definition:** Time spent actively in onboarding process. **Formula:** ``` Onboarding Duration = Median of (Onboarding complete date - Onboarding start date) ``` **What it tells you:** Length of onboarding program. --- ## Completion Metrics ### Onboarding Completion Rate **Definition:** Percentage of customers who complete the onboarding program. **Formula:** ``` Completion Rate = Customers completing onboarding / Customers starting onboarding × 100 ``` **Benchmarks:** - Below 70%: Low, investigate friction points - 70-85%: Average - 85-95%: Good - Above 95%: Excellent **What it tells you:** Onboarding program effectiveness. --- ### Milestone Completion Rate **Definition:** Percentage of customers completing each onboarding milestone. **Formula:** ``` Milestone Completion = Customers completing milestone / Customers reaching milestone × 100 ``` Track for each milestone to identify drop-off points. **Typical milestones:** 1. Kickoff completed 2. Data import completed 3. Configuration completed 4. Integration completed 5. Training completed 6. Go-live achieved **What it tells you:** Where customers get stuck. --- ### On-Time Completion Rate **Definition:** Percentage of customers completing onboarding within target timeframe. **Formula:** ``` On-Time Rate = Customers completing on time / Total customers completing × 100 ``` **Target:** >80% **What it tells you:** Predictability of onboarding timeline. --- ## Engagement Metrics ### Onboarding Engagement Score **Definition:** Level of customer engagement during onboarding. **Components:** - Attendance at scheduled sessions - Response time to onboarding team - Completion of assigned tasks - Login frequency during onboarding **Formula:** ``` Engagement Score = Weighted average of engagement indicators (0-100) ``` **What it tells you:** Customer investment in onboarding success. --- ### Session Attendance Rate **Definition:** Percentage of scheduled onboarding sessions attended. **Formula:** ``` Attendance Rate = Sessions attended / Sessions scheduled × 100 ``` **Target:** >90% --- ### Task Completion Rate **Definition:** Percentage of assigned onboarding tasks completed by customer. **Formula:** ``` Task Completion = Tasks completed / Tasks assigned × 100 ``` **What it tells you:** Customer follow-through on their responsibilities. --- ## Quality Metrics ### Onboarding CSAT **Definition:** Customer satisfaction with the onboarding experience. **Formula:** ``` Onboarding CSAT = Positive ratings / Total ratings × 100 ``` Surveyed at onboarding completion. **Benchmarks:** - Below 80%: Investigate pain points - 80-90%: Average - Above 90%: Good - Above 95%: Excellent --- ### Onboarding NPS **Definition:** Net Promoter Score specifically for onboarding experience. **Formula:** ``` Onboarding NPS = % Promoters - % Detractors ``` **What it tells you:** Onboarding experience quality. --- ### Implementation Quality Score **Definition:** Assessment of implementation completeness and correctness. **Components:** - Configuration accuracy - Data quality post-migration - Integration health - User setup completeness **What it tells you:** Whether implementations are set up for success. --- ## Efficiency Metrics ### Onboardings per Resource **Definition:** Number of onboardings handled per implementation resource. **Formula:** ``` Onboardings per Resource = Completed onboardings / Implementation headcount ``` **What it tells you:** Team capacity and efficiency. --- ### Cost per Onboarding **Definition:** Total onboarding cost divided by customers onboarded. **Formula:** ``` Cost per Onboarding = Total onboarding team cost / Customers onboarded ``` **What it tells you:** Unit economics of implementation. --- ### Time Spent per Onboarding **Definition:** Total hours invested per customer onboarding. **Formula:** ``` Hours per Onboarding = Total onboarding hours / Customers onboarded ``` **Benchmarks:** - Self-serve/digital: 0-2 hours - SMB: 5-15 hours - Mid-market: 20-50 hours - Enterprise: 50-200+ hours --- ## Outcome Metrics ### Onboarding-to-Active Rate (Activation Rate) **Definition:** Percentage of onboarded customers who become actively engaged. **Formula:** ``` Activation Rate = Active customers post-onboarding / Customers completing onboarding × 100 ``` Active = meeting defined usage thresholds (product-specific "aha moment"). **Benchmarks (Userpilot 2024 data):** - Average across SaaS: 37.5% - PLG companies: 34.6% - Sales-led companies: 41.6% **By company size:** - $1-5M ARR: 41.6% - $5-10M ARR: 36.9% - $10-50M ARR: 17.6% - $50M+ ARR: 43.1% **Target:** Varies by model. For managed onboarding (enterprise), aim for >90%. For PLG/self-serve, 40%+ is strong. **What it tells you:** Does onboarding translate to actual product usage? **Sources:** - [Userpilot: User Activation Rate Benchmark 2024](https://userpilot.com/blog/user-activation-rate-benchmark-report-2024/) - [Userpilot: Activation Metrics for SaaS](https://userpilot.com/blog/activation-metrics-saas/) --- ### 30-Day Retention (Post-Onboarding) **Definition:** Percentage of customers still active 30 days after onboarding completion. **Formula:** ``` 30-Day Retention = Customers active at day 30 / Customers completing onboarding × 100 ``` **Target:** >95% **What it tells you:** Near-term stickiness after onboarding. --- ### Onboarding Cohort Churn **Definition:** Churn rate segmented by onboarding characteristics. **Analysis dimensions:** - Onboarding duration (fast vs slow) - Onboarding completeness (full vs partial) - Engagement level during onboarding **What it tells you:** How onboarding experience predicts retention. --- ### Feature Adoption at Go-Live **Definition:** Percentage of available features being used at go-live. **Formula:** ``` Feature Adoption = Features in use / Total features available × 100 ``` **What it tells you:** Are customers set up to use the product fully? --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | Time to First Value | Time | Speed to value realization | | Time to Go-Live | Time | Implementation speed | | Onboarding Completion Rate | Completion | Program effectiveness | | On-Time Completion | Completion | Timeline predictability | | Onboarding CSAT | Quality | Experience quality | | Cost per Onboarding | Efficiency | Unit economics | | Onboarding-to-Active Rate | Outcome | Activation success | | 30-Day Retention | Outcome | Post-onboarding stickiness | --- # Product Metrics Metrics for measuring product usage, adoption and delivery. --- ## Usage Metrics ### Daily Active Users (DAU) **Definition:** Unique users who performed a meaningful action in the product on a given day. **Formula:** ``` DAU = Count of unique users with qualifying activity in 24-hour period ``` **Qualifying activity:** Defined per product. Must be intentional engagement, not passive (e.g., not just logging in, but performing a core action). **What it tells you:** Daily engagement level. --- ### Weekly Active Users (WAU) **Definition:** Unique users who performed a meaningful action in the product within a 7-day period. **Formula:** ``` WAU = Count of unique users with qualifying activity in 7-day period ``` --- ### Monthly Active Users (MAU) **Definition:** Unique users who performed a meaningful action in the product within a 30-day period. **Formula:** ``` MAU = Count of unique users with qualifying activity in 30-day period ``` **What it tells you:** Monthly engagement breadth. --- ### DAU/MAU Ratio (Stickiness) **Definition:** The ratio of daily to monthly active users, indicating how often users return. **Formula:** ``` Stickiness = DAU / MAU × 100 ``` **Benchmarks:** - Below 10%: Low stickiness, investigate product-market fit - 10-13%: Average for B2B SaaS (Mixpanel data: 13% median) - 13-20%: Good for B2B SaaS - 20-25%: Strong engagement - 25%+: Exceptional (top-quartile products) - 50%+: World-class (communication/collaboration tools like Slack) **Important context:** DAU/MAU is misleading for products not designed for daily use (accounting tools, signature apps, seasonal products). For B2B tools used weekly, WAU/MAU is more appropriate. **What it tells you:** How habit-forming the product is. Higher = users come back more frequently. **Sources:** - [Mixpanel: Product Benchmarks 2024](https://mixpanel.com/blog/product-benchmarks/) - [Gainsight: DAU/MAU Guide](https://www.gainsight.com/essential-guide/product-management-metrics/dau-mau/) --- ### WAU/MAU Ratio **Definition:** Weekly to monthly active user ratio. **Formula:** ``` WAU/MAU = WAU / MAU × 100 ``` **Benchmarks:** - Below 40%: Infrequent use - 40-60%: Moderate use - Above 60%: Regular weekly use --- ### Active Accounts **Definition:** Customer accounts with at least one active user in the period. **Formula:** ``` Active Accounts = Count of accounts with ≥1 active user in period ``` **What it tells you:** Account-level engagement (vs user-level). --- ### Activation Rate **Definition:** Percentage of new users/accounts that reach the activation milestone. **Formula:** ``` Activation Rate = Users reaching activation / New users × 100 ``` **Activation milestone:** Product-specific moment when user has experienced core value. Define explicitly. **Benchmarks:** - Below 20%: Low activation, onboarding issue - 20-40%: Average - 40-60%: Good - Above 60%: Strong activation **What it tells you:** Is the product delivering value to new users? --- ## Adoption Metrics ### Feature Adoption Rate **Definition:** Percentage of users/accounts using a specific feature. **Formula:** ``` Feature Adoption = Users using feature / Total active users × 100 ``` Track for each key feature. **What it tells you:** Which features are being used, which are ignored. --- ### Core Feature Adoption **Definition:** Percentage of users using the core features that define the product. **Formula:** ``` Core Feature Adoption = Users using all core features / Total active users × 100 ``` Define 3-5 "core" features that represent full product usage. **Benchmarks:** - Below 30%: Users not fully utilizing product - 30-50%: Moderate adoption - 50-70%: Good - Above 70%: Strong full-product adoption --- ### Feature Depth **Definition:** How extensively users engage with features (not just whether they use them). **Formula:** ``` Feature Depth = Average feature actions per user per period ``` **What it tells you:** Intensity of usage, not just breadth. --- ### Time to Feature Adoption **Definition:** Time from signup/activation to using a specific feature. **Formula:** ``` Time to Adoption = Median of (First feature use date - Signup date) ``` **What it tells you:** Feature discovery and adoption speed. --- ### Breadth of Adoption **Definition:** Average number of features used per account. **Formula:** ``` Breadth = Total features used across all accounts / Active accounts ``` **What it tells you:** How much of the product is being utilized. --- ## Engagement Metrics ### Session Frequency **Definition:** Average number of sessions per user per period. **Formula:** ``` Session Frequency = Total sessions / Active users ``` **What it tells you:** How often users return. --- ### Session Duration **Definition:** Average time spent per session. **Formula:** ``` Session Duration = Total session time / Total sessions ``` **Benchmarks:** Highly product-dependent. Track trend over time. **What it tells you:** Depth of engagement per visit. --- ### Time in Product **Definition:** Total time spent in product per user per period. **Formula:** ``` Time in Product = Sum of session duration per user ``` **What it tells you:** Overall engagement intensity. --- ### Actions per Session **Definition:** Average number of meaningful actions per session. **Formula:** ``` Actions per Session = Total actions / Total sessions ``` **What it tells you:** Productivity per session. --- ### Product Qualified Accounts (PQAs) **Definition:** Accounts that have demonstrated product engagement indicating sales-readiness. **Formula:** ``` PQA = Accounts meeting product engagement threshold ``` **Threshold criteria (examples):** - Used product X times - Activated Y features - Added Z users - Reached usage limit **What it tells you:** Product-driven sales signals. --- ## Retention Metrics (Product) ### User Retention (Day N) **Definition:** Percentage of users who return on day N after signup. **Formula:** ``` Day N Retention = Users active on day N / Users who signed up N days ago × 100 ``` Common intervals: Day 1, Day 7, Day 14, Day 30. **Benchmarks (Day 30 for B2B SaaS):** - Below 20%: Poor - 20-40%: Average - Above 40%: Good --- ### Cohort Retention **Definition:** Retention tracked by signup cohort over time. **Formula:** ``` Cohort Retention (Week N) = Active users in week N / Users in cohort × 100 ``` **What it tells you:** How retention evolves, and whether it's improving for newer cohorts. --- ### Resurrection Rate **Definition:** Percentage of churned/dormant users who return. **Formula:** ``` Resurrection Rate = Reactivated users / Dormant users × 100 ``` **What it tells you:** Can you win back lost users? --- ## Delivery Metrics ### Release Frequency **Definition:** How often new releases are shipped to customers. **Formula:** ``` Release Frequency = Releases per period ``` **What it tells you:** Product development velocity. **Note:** Related to Engineering's Deployment Frequency, but measured at feature/product level vs code deployment level. --- ### Feature Delivery Rate **Definition:** Percentage of planned features delivered on schedule. **Formula:** ``` Delivery Rate = Features shipped on time / Features planned × 100 ``` **What it tells you:** Roadmap predictability. --- ### Roadmap Completion **Definition:** Percentage of roadmap items completed in the period. **Formula:** ``` Roadmap Completion = Roadmap items completed / Roadmap items planned × 100 ``` --- ### Time to Market **Definition:** Time from feature concept to production release. **Formula:** ``` Time to Market = Median of (Release date - Concept approval date) ``` **What it tells you:** How quickly product can respond to market needs. --- ## Quality Metrics (Product) ### Error Rate (User-Facing) **Definition:** Percentage of user actions that result in errors. **Formula:** ``` Error Rate = Error events / Total user actions × 100 ``` **Target:** <1% **Note:** Related to Engineering's Error Rate, but measured from user action perspective. --- ### Bug Escape Rate **Definition:** Bugs found in production vs found in testing. **Formula:** ``` Bug Escape Rate = Production bugs / (Production bugs + Bugs caught in QA) × 100 ``` **Target:** <10% --- ### User-Reported Issues **Definition:** Number of bugs/issues reported by users. **Formula:** ``` User-Reported Issues = Count of user-submitted bug reports ``` **What it tells you:** Quality as perceived by users. --- ### Feature Request Volume **Definition:** Number of feature requests received. **Formula:** ``` Feature Request Volume = Count of feature requests per period ``` Track by theme/category to identify patterns. --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | DAU/MAU (Stickiness) | Usage | User engagement frequency | | MAU | Usage | User engagement breadth | | Activation Rate | Adoption | New user success | | Core Feature Adoption | Adoption | Full product utilization | | Session Frequency | Engagement | Return rate | | PQAs | Engagement | Product-driven sales signals | | Day 30 Retention | Retention | User stickiness | | Release Frequency | Delivery | Development velocity | | Error Rate | Quality | Product reliability | --- # Engineering & Platform Metrics Metrics for measuring platform health, reliability and engineering productivity. **DORA Framework:** Delivery metrics follow the [DORA (DevOps Research and Assessment)](https://dora.dev/) framework, the industry standard for measuring software delivery performance. DORA research shows that high-performing teams are 2x more likely to exceed profitability targets. --- ## Reliability Metrics ### Uptime (Availability) **Definition:** The percentage of time the service is operational. **Formula:** ``` Uptime = (Total time - Downtime) / Total time × 100 ``` **Benchmarks (Monthly):** - 99.0%: ~7.3 hours downtime (unacceptable for most SaaS) - 99.9%: ~43 minutes downtime (three nines) - 99.95%: ~22 minutes downtime (typical SLA) - 99.99%: ~4.3 minutes downtime (four nines, high reliability) **What it tells you:** Basic platform reliability. **Common mistakes:** - Excluding "scheduled maintenance" (customers don't care why it's down) - Measuring only core service, not dependencies - Not weighting by traffic/usage --- ### SLA Adherence **Definition:** Percentage of time SLA commitments were met. **Formula:** ``` SLA Adherence = Periods meeting SLA / Total periods × 100 ``` **Target:** 100% (SLA breaches have contractual and trust implications) --- ### Error Rate **Definition:** Percentage of requests that result in errors. **Formula:** ``` Error Rate = Error responses (5xx) / Total requests × 100 ``` **Benchmarks:** - Below 0.1%: Excellent - 0.1-0.5%: Good - 0.5-1%: Acceptable - Above 1%: Needs attention **What it tells you:** Service reliability from user perspective. --- ### Latency (Response Time) **Definition:** Time taken to respond to requests. **Formula:** ``` P50 Latency = Median response time P95 Latency = 95th percentile response time P99 Latency = 99th percentile response time ``` Always report P95 or P99, not averages (averages hide tail latency). **Benchmarks (API):** - P50: < 100ms - P95: < 500ms - P99: < 1000ms **What it tells you:** User experience. Slow responses impact satisfaction and conversion. --- ## Incident Metrics ### Incident Count **Definition:** Number of incidents in a period. **Formula:** ``` Incident Count = Total incidents reported ``` Categorize by severity: - SEV1/P1: Critical, full outage - SEV2/P2: Major, significant degradation - SEV3/P3: Minor, limited impact **What it tells you:** System stability. Trend matters. --- ### Mean Time to Detect (MTTD) **Definition:** Time from incident start to detection. **Formula:** ``` MTTD = Average of (Detection time - Incident start time) ``` **Target:** < 5 minutes for critical services **What it tells you:** Monitoring and alerting effectiveness. --- ### Mean Time to Acknowledge (MTTA) **Definition:** Time from alert to human acknowledgment. **Formula:** ``` MTTA = Average of (Acknowledgment time - Alert time) ``` **Target:** < 15 minutes **What it tells you:** On-call responsiveness. --- ### Mean Time to Resolve (MTTR) **Definition:** Time from incident start to resolution. **Formula:** ``` MTTR = Average of (Resolution time - Incident start time) ``` **Benchmarks:** - SEV1: < 1 hour - SEV2: < 4 hours - SEV3: < 24 hours **What it tells you:** Incident response capability. --- ### Change Failure Rate **Definition:** Percentage of deployments that cause incidents. **Formula:** ``` Change Failure Rate = Deployments causing incidents / Total deployments × 100 ``` **Benchmarks (DORA):** - Elite: 0-15% - High: 16-30% - Medium: 31-45% - Low: 46-60% **What it tells you:** Deployment quality and release process health. --- ## Delivery Metrics (DORA) The four key DORA metrics measure software delivery performance. In 2024, DORA added a fifth metric (Rework Rate), though benchmarks are still emerging. **Sources:** - [DORA: Metrics Guide](https://dora.dev/guides/dora-metrics-four-keys/) - [Google Cloud: Four Keys](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance) ### Deployment Frequency **Definition:** How often code is deployed to production. **Formula:** ``` Deployment Frequency = Deployments / Time period ``` **Benchmarks (DORA):** - Elite: On-demand or multiple times per day - High: Once per day to once per week - Medium: Once per week to once per month - Low: Less than once per month **What it tells you:** Ability to deliver value quickly. --- ### Lead Time for Changes **Definition:** Time from code commit to production deployment. **Formula:** ``` Lead Time = Median of (Deploy time - Commit time) ``` **Benchmarks (DORA):** - Elite: Less than 1 day - High: 1 day to 1 week - Medium: 1 week to 1 month - Low: 1 month to 6 months **What it tells you:** Development and release pipeline efficiency. --- ### Mean Time to Recovery (MTTR) **Definition:** Time to restore service after a failure. **Formula:** ``` MTTR = Average of (Recovery time - Failure time) ``` **Benchmarks (DORA):** - Elite: Less than 1 hour - High: Less than 1 day - Medium: 1 day to 1 week - Low: More than 1 week **What it tells you:** Resilience and recovery capability. --- ## Capacity Metrics ### Infrastructure Utilization **Definition:** Percentage of provisioned capacity being used. **Formula:** ``` Utilization = Actual usage / Provisioned capacity × 100 ``` Measure for CPU, memory, storage, network. **Targets:** - Below 40%: Over-provisioned, wasting money - 40-70%: Healthy headroom - 70-85%: Efficient, monitoring needed - Above 85%: At risk, scale soon --- ### Infrastructure Cost per Customer **Definition:** Total infrastructure cost divided by active customers. **Formula:** ``` Cost per Customer = Total infrastructure cost / Active customers ``` **What it tells you:** Unit economics of delivery. Should decrease or stay flat as you scale. --- ### Headroom **Definition:** Available capacity before scaling is required. **Formula:** ``` Headroom = (Max capacity - Current usage) / Max capacity × 100 ``` **Target:** Maintain 20-30% headroom for traffic spikes. --- ## Security Metrics ### Vulnerability Count **Definition:** Number of known vulnerabilities in systems. **Categorize by severity:** Critical, High, Medium, Low **Targets:** - Critical: 0 (fix immediately) - High: < 10 (fix within days) - Medium: < 50 (fix within weeks) --- ### Time to Patch **Definition:** Time from vulnerability disclosure to patch deployment. **Formula:** ``` Time to Patch = Average of (Patch deploy time - Disclosure time) ``` **Targets:** - Critical: < 24 hours - High: < 7 days - Medium: < 30 days --- ### Security Incident Count **Definition:** Number of security incidents in a period. **Target:** Zero breaches. Track and reduce attempted attacks. --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | Uptime | Reliability | Platform availability | | Error Rate | Reliability | Service quality | | P95 Latency | Reliability | User experience | | Incident Count | Incidents | System stability | | MTTR | Incidents | Recovery capability | | Deployment Frequency | Delivery | Release velocity | | Lead Time for Changes | Delivery | Pipeline efficiency | | Change Failure Rate | Delivery | Release quality | | Infrastructure Cost per Customer | Capacity | Delivery economics | --- # Finance Metrics Metrics for measuring financial health, efficiency and operational performance. --- ## Revenue Metrics ### Revenue (GAAP) **Definition:** Recognized revenue according to accounting standards. **Formula:** ``` Revenue = Recognized revenue in period (per ASC 606) ``` **Note:** Different from bookings or billings. Revenue is recognized as service is delivered. **What it tells you:** Actual earned revenue for the period. --- ### Bookings **Definition:** Total contract value signed in a period. **Formula:** ``` Bookings = Sum of total contract value for deals signed in period ``` **Types:** - New Bookings: From new customers - Expansion Bookings: Upgrades from existing customers - Renewal Bookings: Contract renewals **What it tells you:** Sales output and future revenue committed. --- ### Billings **Definition:** Amounts invoiced in a period. **Formula:** ``` Billings = Total invoiced amount in period ``` **What it tells you:** Cash coming in (or expected). --- ### ARR / MRR See [Core Metrics](https://gaspwiki.com/v1/metrics/core) for full definitions. --- ### Deferred Revenue **Definition:** Cash received for services not yet delivered. **Formula:** ``` Deferred Revenue = Billings collected - Revenue recognized ``` **What it tells you:** Future revenue already paid for. A liability on balance sheet. --- ### Revenue per Employee **Definition:** Total revenue divided by headcount. **Formula:** ``` Revenue per Employee = ARR / Total employees ``` **Benchmarks:** - Below $100K: Early stage or overstaffed - $100K-$200K: Growing - $200K-$300K: Efficient - Above $300K: Highly efficient **What it tells you:** Overall company productivity. --- ## Profitability Metrics ### Gross Margin See [Core Metrics](https://gaspwiki.com/v1/metrics/core#gross-margin) for full definition. --- ### Operating Margin (EBIT Margin) **Definition:** Operating income as a percentage of revenue. **Formula:** ``` Operating Margin = Operating Income / Revenue × 100 ``` Operating Income = Revenue - COGS - Operating Expenses **Benchmarks:** - Below -50%: Heavy investment phase - -50% to 0%: Growth mode - 0-20%: Path to profitability - Above 20%: Profitable and efficient --- ### EBITDA Margin **Definition:** Earnings before interest, taxes, depreciation and amortization as a percentage of revenue. **Formula:** ``` EBITDA Margin = EBITDA / Revenue × 100 ``` **What it tells you:** Operational profitability before non-cash charges. --- ### Net Income Margin **Definition:** Net income as a percentage of revenue. **Formula:** ``` Net Income Margin = Net Income / Revenue × 100 ``` **What it tells you:** Bottom line profitability. --- ### Rule of 40 See [Core Metrics](https://gaspwiki.com/v1/metrics/core#rule-of-40) for full definition. --- ## Cash Metrics ### Cash Burn Rate **Definition:** Net cash consumed per month. **Formula:** ``` Burn Rate = (Cash at start of period - Cash at end of period) / Months in period ``` **What it tells you:** How fast cash is being consumed. --- ### Cash Runway **Definition:** Time until cash runs out at current burn rate. **Formula:** ``` Runway = Current cash / Monthly burn rate ``` Measured in months. **Targets:** - Below 6 months: Critical, fundraise immediately - 6-12 months: Urgent attention needed - 12-18 months: Planning window - Above 18 months: Comfortable --- ### Free Cash Flow (FCF) **Definition:** Cash generated from operations minus capital expenditures. **Formula:** ``` FCF = Operating cash flow - Capital expenditures ``` **What it tells you:** Cash available for growth, debt repayment or distribution. --- ### Free Cash Flow Margin **Definition:** FCF as a percentage of revenue. **Formula:** ``` FCF Margin = Free Cash Flow / Revenue × 100 ``` **Benchmarks:** - Below -20%: Heavy investment - -20% to 0%: Growth mode - 0-10%: Cash flow positive - Above 10%: Strong cash generation --- ## Efficiency Metrics ### CAC Payback Period See [Core Metrics](https://gaspwiki.com/v1/metrics/core#cac-payback-period) for full definition. --- ### LTV:CAC Ratio See [Core Metrics](https://gaspwiki.com/v1/metrics/core#ltvcac-ratio) for full definition. --- ### Magic Number **Definition:** Sales efficiency metric measuring revenue generated per dollar of sales and marketing spend. **Formula:** ``` Magic Number = (QoQ ARR growth) / (Prior quarter S&M spend) ``` **Benchmarks:** - Below 0.5: Inefficient, fix before scaling - 0.5-0.75: Acceptable - 0.75-1.0: Efficient (2024 median: 0.90) - Above 1.0: Very efficient, invest more aggressively **What it tells you:** Whether sales and marketing investment is generating sufficient returns. **Sources:** - [Benchmarkit: 2025 SaaS Metrics](https://www.benchmarkit.ai/2025benchmarks) - [Drivetrain: SaaS Magic Number](https://www.drivetrain.ai/strategic-finance-glossary/what-is-magic-number-saas-companies) --- ### Burn Multiple **Definition:** Net burn divided by net new ARR. Popularized by David Sacks. **Formula:** ``` Burn Multiple = Net burn / Net new ARR ``` **Benchmarks:** - Below 1x: Excellent (top 10% of Series A companies) - 1.0-1.5x: Strong (top quartile) - 1.5-2x: Median, acceptable - 2.0-3x: Concerning, especially above $20M ARR - Above 3x: Critical, requires immediate attention **Scale expectations:** Burn multiple should decrease as company scales. Target <1.0x by $25M-$50M ARR range. **What it tells you:** How much cash is being burned to generate each dollar of new ARR. **Sources:** - [CFO Advisors: 2025 Burn Multiple Benchmarks](https://www.cfoadvisors.com/blog/2025-burn-multiple-benchmarks_-how-series-a-saas-startups-can-prove-capital-efficiency) - [Benchmarkit: SaaS Performance Metrics](https://www.benchmarkit.ai/2025benchmarks) --- ## Operating Expense Metrics ### Opex Ratio **Definition:** Operating expenses as a percentage of revenue. **Formula:** ``` Opex Ratio = Operating expenses / Revenue × 100 ``` --- ### S&M as % of Revenue **Definition:** Sales and marketing spend as percentage of revenue. **Formula:** ``` S&M % = Sales & Marketing expense / Revenue × 100 ``` **Benchmarks:** - Early stage: 80-120% - Growth stage: 40-60% - Mature: 20-40% --- ### R&D as % of Revenue **Definition:** Research and development spend as percentage of revenue. **Formula:** ``` R&D % = R&D expense / Revenue × 100 ``` **Benchmarks:** - SaaS typical: 15-25% --- ### G&A as % of Revenue **Definition:** General and administrative spend as percentage of revenue. **Formula:** ``` G&A % = G&A expense / Revenue × 100 ``` **Benchmarks:** - SaaS typical: 10-15% --- ## Collections Metrics ### Days Sales Outstanding (DSO) **Definition:** Average days to collect payment after invoicing. **Formula:** ``` DSO = (Accounts receivable / Revenue) × Days in period ``` **Benchmarks:** - Below 30 days: Excellent - 30-45 days: Good - 45-60 days: Average - Above 60 days: Collection issues **What it tells you:** Collection efficiency and customer payment behavior. --- ### Collection Rate **Definition:** Percentage of invoiced amounts collected. **Formula:** ``` Collection Rate = Cash collected / Amount invoiced × 100 ``` **Target:** >95% --- ### Bad Debt Rate **Definition:** Percentage of revenue written off as uncollectable. **Formula:** ``` Bad Debt Rate = Bad debt expense / Revenue × 100 ``` **Target:** <1% --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | ARR | Revenue | Business scale | | Gross Margin | Profitability | Unit economics | | Operating Margin | Profitability | Operational efficiency | | Rule of 40 | Profitability | Growth/profit balance | | Burn Rate | Cash | Cash consumption | | Runway | Cash | Financial sustainability | | Magic Number | Efficiency | Sales efficiency | | Burn Multiple | Efficiency | Capital efficiency | | DSO | Collections | Payment collection speed | --- # Revenue Operations / Order to Cash Metrics Metrics for measuring the revenue lifecycle from quote to cash collection. --- ## Pipeline Operations ### Pipeline Hygiene Score **Definition:** Quality assessment of pipeline data and process adherence. **Components:** - Opportunities with required fields complete - Opportunities updated within SLA - Opportunities with valid close dates - Opportunities with accurate stage assignment **Formula:** ``` Hygiene Score = (Complete opps + Updated opps + Valid dates + Accurate stages) / 4 ``` Each component scored as percentage meeting criteria. **Target:** >90% **What it tells you:** Can you trust your pipeline data? --- ### Forecast Accuracy **Definition:** How closely forecasted revenue matched actual revenue. **Formula:** ``` Forecast Accuracy = 1 - |Forecasted - Actual| / Actual ``` **Benchmarks:** - Below 70%: Poor forecasting - 70-85%: Average - 85-95%: Good - Above 95%: Excellent **What it tells you:** Predictability of revenue. Critical for planning. --- ### Commit Accuracy **Definition:** Percentage of committed deals that close. **Formula:** ``` Commit Accuracy = Deals closed from commit / Deals in commit × 100 ``` **Target:** >80% --- ### Stage Conversion Rates **Definition:** Conversion rate between each pipeline stage. **Formula:** ``` Stage Conversion = Opportunities advancing to next stage / Opportunities in stage × 100 ``` Track for each stage transition. **What it tells you:** Where deals get stuck or leak. --- ## Quote-to-Order ### Quote Volume **Definition:** Number of quotes generated in a period. **Formula:** ``` Quote Volume = Count of quotes created ``` --- ### Quote-to-Order Rate **Definition:** Percentage of quotes that convert to orders. **Formula:** ``` Quote-to-Order = Orders / Quotes × 100 ``` **Benchmarks:** - Below 20%: Low conversion - 20-40%: Average - 40-60%: Good - Above 60%: Strong --- ### Quote Cycle Time **Definition:** Time from quote request to quote delivery. **Formula:** ``` Quote Cycle Time = Median of (Quote sent date - Quote requested date) ``` **Target:** <24 hours for standard quotes **What it tells you:** Speed of quote generation process. --- ### Quote Accuracy **Definition:** Percentage of quotes requiring no revision. **Formula:** ``` Quote Accuracy = Quotes with no revision / Total quotes × 100 ``` **Target:** >90% --- ### Discount Rate **Definition:** Average discount applied to deals. **Formula:** ``` Discount Rate = (List price - Sold price) / List price × 100 ``` **What it tells you:** Pricing discipline and competitive pressure. --- ## Order Processing ### Order-to-Activation Time **Definition:** Time from signed order to customer activation/provisioning. **Formula:** ``` Order-to-Activation = Median of (Activation date - Order signed date) ``` **What it tells you:** How quickly customers get access after buying. --- ### Order Processing Time **Definition:** Time to process an order through internal systems. **Formula:** ``` Processing Time = Median of (Order complete in system - Order received) ``` **Target:** Same day for standard orders. --- ### Order Error Rate **Definition:** Percentage of orders with processing errors. **Formula:** ``` Order Error Rate = Orders with errors / Total orders × 100 ``` **Target:** <2% **What it tells you:** Process quality and system reliability. --- ## Billing Operations ### Billing Accuracy **Definition:** Percentage of invoices generated correctly on first attempt. **Formula:** ``` Billing Accuracy = Invoices without correction / Total invoices × 100 ``` **Target:** >98% **What it tells you:** Billing process reliability. --- ### Invoice Cycle Time **Definition:** Time from billing event to invoice delivery. **Formula:** ``` Invoice Cycle Time = Median of (Invoice sent - Billing trigger date) ``` **Target:** <5 business days --- ### Billing Disputes **Definition:** Percentage of invoices disputed by customers. **Formula:** ``` Dispute Rate = Invoices disputed / Total invoices × 100 ``` **Target:** <1% **What it tells you:** Invoice accuracy and customer alignment. --- ### Credit Memo Rate **Definition:** Percentage of invoices requiring credit memos. **Formula:** ``` Credit Memo Rate = Credit memos issued / Total invoices × 100 ``` **Target:** <2% **What it tells you:** Billing errors and adjustments. --- ## Collections ### Days Sales Outstanding (DSO) **Definition:** Average days to collect payment after invoicing. **Formula:** ``` DSO = (Accounts Receivable / Revenue) × Days in period ``` **Benchmarks:** - Below 30 days: Excellent - 30-45 days: Good - 45-60 days: Average - Above 60 days: Collection issues **Note:** Also defined in [Finance metrics](https://gaspwiki.com/v1/metrics/finance). Same definition. --- ### Collection Effectiveness Index (CEI) **Definition:** How effective collections are at collecting receivables. **Formula:** ``` CEI = (Beginning AR + Credit sales - Ending AR) / (Beginning AR + Credit sales - Ending current AR) × 100 ``` **Benchmarks:** - Below 70%: Poor - 70-80%: Average - Above 80%: Good --- ### Aging Buckets **Definition:** Distribution of receivables by age. **Buckets:** - Current (0-30 days) - 31-60 days - 61-90 days - 90+ days **Formula:** ``` Bucket % = AR in bucket / Total AR × 100 ``` **Targets:** - Current: >80% - 31-60: <15% - 61-90: <4% - 90+: <1% --- ### Bad Debt Rate **Definition:** Percentage of revenue written off as uncollectable. **Formula:** ``` Bad Debt Rate = Write-offs / Revenue × 100 ``` **Target:** <1% **Note:** Also defined in [Finance metrics](https://gaspwiki.com/v1/metrics/finance). Same definition. --- ### Payment Method Distribution **Definition:** Breakdown of payments by method. **Methods:** - Credit card - ACH/Direct debit - Wire transfer - Check **What it tells you:** Collection risk and processing costs by method. --- ## Revenue Recognition ### Recognized vs Billed **Definition:** Ratio of recognized revenue to billed revenue. **Formula:** ``` Recognized/Billed = Recognized revenue / Billed revenue ``` **What it tells you:** Revenue recognition timing vs cash collection. --- ### Deferred Revenue Balance **Definition:** Total revenue collected but not yet recognized. **Formula:** ``` Deferred Revenue = Cumulative billings - Cumulative recognized revenue ``` **What it tells you:** Future revenue already paid for. --- ### Unbilled Revenue **Definition:** Revenue recognized but not yet invoiced. **Formula:** ``` Unbilled Revenue = Recognized revenue - Billed revenue (where recognition > billing) ``` **What it tells you:** Revenue owed but not yet invoiced. --- ### Revenue Recognition Accuracy **Definition:** Percentage of revenue correctly recognized per ASC 606. **Formula:** ``` Recognition Accuracy = Revenue recognized correctly / Total revenue × 100 ``` **Target:** 100% --- ## Renewal Operations ### Renewal Notification Rate **Definition:** Percentage of renewals where customer was notified on time. **Formula:** ``` Notification Rate = Renewals notified on time / Total renewals × 100 ``` **Target:** 100% --- ### Auto-Renewal Rate **Definition:** Percentage of renewals processed automatically. **Formula:** ``` Auto-Renewal Rate = Auto-renewed contracts / Total renewals × 100 ``` **What it tells you:** Renewal process efficiency. --- ### Renewal Processing Time **Definition:** Time to process a renewal from trigger to completion. **Formula:** ``` Processing Time = Median of (Renewal complete - Renewal trigger) ``` --- ## Systems & Data Quality ### System Sync Accuracy **Definition:** Data consistency across RevOps systems (CRM, billing, ERP). **Formula:** ``` Sync Accuracy = Records matching across systems / Total records × 100 ``` **Target:** >99% --- ### Data Completeness **Definition:** Percentage of required fields populated in RevOps systems. **Formula:** ``` Completeness = Fields populated / Required fields × 100 ``` **Target:** >95% --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | Forecast Accuracy | Pipeline Ops | Revenue predictability | | Quote-to-Order Rate | Quote-to-Order | Sales process efficiency | | Billing Accuracy | Billing | Invoice reliability | | DSO | Collections | Cash collection speed | | Bad Debt Rate | Collections | Collection effectiveness | | Deferred Revenue | Recognition | Future revenue liability | | Auto-Renewal Rate | Renewals | Process automation | --- # People (HR) Metrics Metrics for measuring workforce health, engagement and organizational effectiveness. --- ## Headcount Metrics ### Total Headcount **Definition:** Total number of employees. **Formula:** ``` Headcount = Total active employees at end of period ``` Include: Full-time, part-time employees Exclude: Contractors (track separately) --- ### Headcount Growth Rate **Definition:** Percentage change in headcount over a period. **Formula:** ``` Growth Rate = (Headcount end - Headcount start) / Headcount start × 100 ``` **What it tells you:** Organizational scaling velocity. --- ### Headcount by Department **Definition:** Distribution of employees across functions. **Typical breakdown for SaaS:** | Department | % of Headcount | |------------|----------------| | Engineering | 25-35% | | Sales | 20-30% | | Customer Success/Support | 15-25% | | Marketing | 5-10% | | G&A (Finance, HR, Legal, Ops) | 10-15% | | Product | 5-10% | **What it tells you:** Resource allocation and organizational structure. --- ### Revenue per Employee **Definition:** ARR divided by total headcount. **Formula:** ``` Revenue per Employee = ARR / Total headcount ``` **Benchmarks:** - Below $100K: Early stage or overstaffed - $100K-$200K: Growing - $200K-$300K: Efficient - Above $300K: Highly efficient **What it tells you:** Overall workforce productivity. --- ## Retention Metrics ### Employee Turnover Rate **Definition:** Percentage of employees who left in a period. **Formula:** ``` Turnover Rate = Employees departed / Average headcount × 100 ``` Calculate monthly or annually. Annualize for comparability. **Benchmarks (Annual):** - Below 10%: Excellent retention - 10-15%: Good - 13-20%: Average for tech (tech runs higher than other industries) - 20-25%: High for tech, investigate - Above 25%: Critical **Context:** US voluntary turnover averaged 13.5% in 2025 (down from 17.3% in 2023). Tech sector runs 13-25% due to competitive demand for specialized skills. Average tech tenure is 2-3 years vs 4.1 years overall. **Sources:** - [BambooHR: Turnover Benchmarks 2025](https://www.bamboohr.com/resources/guides/turnover-benchmarks) - [Mercer: 2025 US Turnover Survey](https://www.imercer.com/articleinsights/workforce-turnover-trends) --- ### Voluntary Turnover Rate **Definition:** Turnover due to employee choice (resignations). **Formula:** ``` Voluntary Turnover = Voluntary departures / Average headcount × 100 ``` **What it tells you:** Employee satisfaction and competitiveness of employment. --- ### Involuntary Turnover Rate **Definition:** Turnover due to company decision (terminations, layoffs). **Formula:** ``` Involuntary Turnover = Involuntary departures / Average headcount × 100 ``` **What it tells you:** Hiring quality and performance management. --- ### Regrettable Turnover **Definition:** Voluntary departures of high performers. **Formula:** ``` Regrettable Turnover = High performer departures / Total high performers × 100 ``` **Target:** <5% **What it tells you:** Are you losing your best people? --- ### Average Tenure **Definition:** Average length of employment. **Formula:** ``` Average Tenure = Sum of employee tenure / Total employees ``` Measured in months or years. **What it tells you:** Workforce stability and institutional knowledge. --- ### 90-Day Turnover **Definition:** Percentage of new hires who leave within 90 days. **Formula:** ``` 90-Day Turnover = Departures within 90 days / New hires × 100 ``` **Benchmarks:** - Below 5%: Good onboarding and hiring - 5-10%: Average - Above 10%: Hiring or onboarding issues **What it tells you:** Hiring quality and onboarding effectiveness. --- ## Engagement Metrics ### Employee Net Promoter Score (eNPS) **Definition:** Likelihood of employees recommending the company as a place to work. **Formula:** ``` eNPS = % Promoters (9-10) - % Detractors (0-6) ``` Based on: "How likely are you to recommend [company] as a place to work?" (0-10) **Benchmarks:** - Below 0: Poor engagement (investigate immediately) - 0-10: Below average - 10-30: Average (overall benchmark ~12-27) - 30-50: Good, leading companies - Above 50: Excellent **Tech industry:** Average eNPS is 26, but top tech companies score 50-75+. **Company size effect:** Smaller companies (0-250) average 30; larger companies (5000+) average 9. **What it tells you:** Employee satisfaction and advocacy. **Sources:** - [AIHR: Employee Net Promoter Score Guide](https://www.aihr.com/blog/employee-net-promoter-score-enps/) - [Perceptyx: eNPS Guide](https://blog.perceptyx.com/employee-net-promoter-score) --- ### Engagement Score **Definition:** Composite score from engagement survey. **Measurement:** Typically annual or quarterly survey covering: - Job satisfaction - Manager relationship - Growth opportunities - Company direction - Work-life balance **Benchmarks:** - Below 60%: Low engagement - 60-70%: Average - 70-80%: Good - Above 80%: High engagement --- ### Survey Participation Rate **Definition:** Percentage of employees completing engagement surveys. **Formula:** ``` Participation Rate = Surveys completed / Surveys sent × 100 ``` **Target:** >80% **What it tells you:** Trust in feedback process and engagement with company. --- ## Recruiting Metrics ### Open Positions **Definition:** Number of unfilled roles. **What it tells you:** Hiring backlog and growth plans. --- ### Time to Fill **Definition:** Days from job opening to accepted offer. **Formula:** ``` Time to Fill = Average of (Offer accepted date - Job posted date) ``` **Benchmarks:** - Below 30 days: Fast - 30-45 days: Good - 45-60 days: Average - Above 60 days: Slow, may impact growth --- ### Time to Hire **Definition:** Days from candidate application to accepted offer. **Formula:** ``` Time to Hire = Average of (Offer accepted date - Application date) ``` **What it tells you:** Candidate experience and process efficiency. --- ### Offer Acceptance Rate **Definition:** Percentage of offers accepted. **Formula:** ``` Acceptance Rate = Offers accepted / Offers extended × 100 ``` **Benchmarks:** - Below 70%: Low, may indicate compensation or culture issues - 70-85%: Average - Above 85%: Strong employer brand --- ### Quality of Hire **Definition:** Performance rating of new hires after defined period. **Formula:** ``` Quality of Hire = Average performance rating of hires at 6-12 months ``` Or: Percentage of new hires meeting/exceeding expectations. **What it tells you:** Recruiting effectiveness at finding good candidates. --- ### Cost per Hire **Definition:** Total recruiting cost divided by hires made. **Formula:** ``` Cost per Hire = (Internal recruiting costs + External recruiting costs) / Total hires ``` **Benchmarks:** - IC roles: $3,000-$7,000 - Technical roles: $7,000-$15,000 - Executive roles: $20,000-$50,000+ --- ### Source of Hire **Definition:** Where successful candidates came from. **Channels:** - Employee referrals - Job boards - LinkedIn/direct sourcing - Agencies - Career page - Internal transfers **What it tells you:** Most effective recruiting channels. --- ## Compensation Metrics ### Compa-Ratio **Definition:** Employee salary relative to market midpoint. **Formula:** ``` Compa-Ratio = Actual salary / Market midpoint × 100 ``` **Interpretation:** - Below 90%: Below market - 90-110%: At market - Above 110%: Above market --- ### Pay Equity Ratio **Definition:** Pay comparison across demographic groups for same role. **Formula:** ``` Pay Equity = Average pay (Group A) / Average pay (Group B) ``` **Target:** 0.98-1.02 (within 2%) **What it tells you:** Fairness in compensation practices. --- ## Diversity Metrics ### Diversity Representation **Definition:** Percentage of workforce from underrepresented groups. **Dimensions:** - Gender - Race/ethnicity - Age - Disability status - Veteran status Track overall and by department/level. --- ### Diversity in Leadership **Definition:** Representation at manager+ levels. **Formula:** ``` Leadership Diversity = URG in leadership / Total leadership × 100 ``` **What it tells you:** Pipeline to leadership for underrepresented groups. --- ### Diversity Hiring Rate **Definition:** Percentage of new hires from underrepresented groups. **Formula:** ``` Diversity Hiring = URG hires / Total hires × 100 ``` **What it tells you:** Progress on diversifying the workforce. --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | Headcount | Size | Organizational scale | | Revenue per Employee | Productivity | Workforce efficiency | | Employee Turnover | Retention | Workforce stability | | Regrettable Turnover | Retention | High performer retention | | eNPS | Engagement | Employee satisfaction | | Time to Fill | Recruiting | Hiring velocity | | Offer Acceptance Rate | Recruiting | Employer competitiveness | | Quality of Hire | Recruiting | Recruiting effectiveness | | Compa-Ratio | Compensation | Market competitiveness | --- # Partnerships & Channel Metrics Metrics for measuring partner ecosystem performance and channel revenue. --- ## Partner Portfolio ### Total Active Partners **Definition:** Number of partners actively engaged in the program. **Formula:** ``` Active Partners = Partners with activity in trailing 12 months ``` **Activity:** Deals registered, deals closed, certifications maintained or engagement threshold met. **What it tells you:** Size of active partner ecosystem. --- ### Partner Tier Distribution **Definition:** Breakdown of partners by program tier. **Tiers (typical):** - Registered / Affiliate - Silver / Select - Gold / Premier - Platinum / Elite **Formula:** ``` Tier Distribution = Partners in tier / Total partners × 100 ``` **What it tells you:** Partner ecosystem maturity. --- ### Partner Activation Rate **Definition:** Percentage of recruited partners who become productive. **Formula:** ``` Activation Rate = Partners with first deal / Partners recruited × 100 ``` **Benchmarks:** - Below 20%: Low activation - 20-40%: Average - 40-60%: Good - Above 60%: Strong enablement **What it tells you:** Partner onboarding and enablement effectiveness. --- ### Partner Churn Rate **Definition:** Percentage of partners who leave or become inactive. **Formula:** ``` Partner Churn = Partners churned / Partners at start of period × 100 ``` **What it tells you:** Partner program health and competitiveness. --- ## Partner Revenue ### Partner-Sourced Revenue **Definition:** Revenue from deals originated by partners. **Formula:** ``` Partner-Sourced Revenue = Sum of closed revenue where partner = source ``` **What it tells you:** Partner contribution to new business. --- ### Partner-Influenced Revenue **Definition:** Revenue from deals where partners were involved (but may not have originated). **Formula:** ``` Partner-Influenced Revenue = Sum of closed revenue where partner = involved ``` **What it tells you:** Total partner impact on revenue. --- ### Channel Revenue Percentage **Definition:** Partner revenue as percentage of total revenue. **Formula:** ``` Channel % = Partner-sourced revenue / Total revenue × 100 ``` **Benchmarks:** - Below 10%: Direct-dominant model - 10-30%: Developing channel - 30-50%: Balanced model - Above 50%: Channel-dominant model --- ### Partner Revenue Growth **Definition:** Year-over-year growth in partner-sourced revenue. **Formula:** ``` Growth = (Partner revenue this year - Partner revenue last year) / Partner revenue last year × 100 ``` --- ### Average Partner Revenue **Definition:** Average revenue per active partner. **Formula:** ``` Average Partner Revenue = Total partner revenue / Active partners ``` **What it tells you:** Partner productivity. --- ## Deal Flow ### Partner Deal Registration Volume **Definition:** Number of deals registered by partners. **Formula:** ``` Deal Registrations = Count of partner-registered deals in period ``` --- ### Deal Registration-to-Close Rate **Definition:** Percentage of registered deals that close. **Formula:** ``` Registration-to-Close = Closed deals / Registered deals × 100 ``` **Benchmarks:** - Below 20%: Low quality or poor follow-through - 20-35%: Average - Above 35%: Good --- ### Partner Win Rate **Definition:** Win rate on partner-involved opportunities. **Formula:** ``` Partner Win Rate = Partner deals won / (Partner deals won + Partner deals lost) × 100 ``` Compare to direct win rate to assess partner effectiveness. --- ### Partner Deal Size **Definition:** Average deal size for partner-sourced deals. **Formula:** ``` Partner Deal Size = Partner-sourced revenue / Partner deals closed ``` Compare to direct deal size. --- ### Partner Sales Cycle **Definition:** Average sales cycle for partner-sourced deals. **Formula:** ``` Partner Sales Cycle = Median of (Close date - Registration date) for partner deals ``` Compare to direct sales cycle. --- ## Partner Engagement ### Partner Portal Engagement **Definition:** Partner activity in partner portal/systems. **Metrics:** - Portal logins per partner - Content downloads - Training modules accessed - Deal registrations submitted --- ### Certification Rate **Definition:** Percentage of partners with current certifications. **Formula:** ``` Certification Rate = Certified partners / Active partners × 100 ``` **Target:** >80% for technical partners --- ### Training Completion **Definition:** Percentage of partners completing required training. **Formula:** ``` Training Completion = Partners completing training / Partners enrolled × 100 ``` --- ### Joint Marketing Activities **Definition:** Number of co-marketing activities with partners. **Activities:** Webinars, events, content, campaigns. **Formula:** ``` Joint Activities = Count of co-marketing activities in period ``` --- ### Partner NPS **Definition:** Net Promoter Score from partner satisfaction surveys. **Formula:** ``` Partner NPS = % Promoters - % Detractors ``` **What it tells you:** Partner satisfaction with the program. --- ## Partner Economics ### Partner Margin / Commission **Definition:** Compensation paid to partners. **Formula:** ``` Partner Margin = Partner compensation / Partner-sourced revenue × 100 ``` --- ### Cost of Partner Acquisition **Definition:** Cost to recruit and onboard a new partner. **Formula:** ``` Cost of Partner Acquisition = Partner program costs / New partners recruited ``` --- ### Partner Lifetime Value **Definition:** Expected revenue from a partner over their lifetime. **Formula:** ``` Partner LTV = Average annual partner revenue / Partner churn rate ``` --- ### Partner ROI **Definition:** Return on investment in partner program. **Formula:** ``` Partner ROI = (Partner-sourced revenue - Partner program costs) / Partner program costs × 100 ``` --- ## Partner Types Track metrics separately by partner type: ### Resellers - Focus: Revenue sourced, deal flow, margin - Key metric: Revenue per reseller ### Referral Partners - Focus: Lead volume, conversion, referral fees - Key metric: Referrals per partner ### Technology Partners (Integrations) - Focus: Integration usage, co-sell, marketplace - Key metric: Customers using integration ### System Integrators (SIs) - Focus: Implementation capacity, project revenue, customer success - Key metric: Implementations delivered ### Managed Service Providers (MSPs) - Focus: Managed seats, recurring revenue, retention - Key metric: Seats under management --- ## Marketplace (if applicable) ### Marketplace Revenue **Definition:** Revenue transacted through marketplace (AWS, Azure, etc.). **Formula:** ``` Marketplace Revenue = Sum of marketplace transactions ``` --- ### Marketplace as % of Revenue **Definition:** Marketplace contribution to total revenue. **Formula:** ``` Marketplace % = Marketplace revenue / Total revenue × 100 ``` --- ### Marketplace Listings Performance **Definition:** Performance of product listings. **Metrics:** - Listing views - Trial starts - Conversions - Reviews/ratings --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | Active Partners | Portfolio | Ecosystem size | | Partner Activation Rate | Portfolio | Enablement effectiveness | | Partner-Sourced Revenue | Revenue | Channel contribution | | Channel % | Revenue | Business model mix | | Deal Registration-to-Close | Deal Flow | Partner effectiveness | | Partner Win Rate | Deal Flow | Partner quality | | Certification Rate | Engagement | Partner investment | | Partner NPS | Engagement | Program health | | Partner ROI | Economics | Program efficiency | --- # Professional Services Metrics Metrics for measuring professional services delivery, profitability and capacity. Applicable when implementation, consulting or training are revenue-generating services. --- ## Revenue Metrics ### Services Revenue **Definition:** Revenue from professional services (implementation, consulting, training). **Formula:** ``` Services Revenue = Sum of recognized services revenue in period ``` --- ### Services as % of Total Revenue **Definition:** Professional services contribution to total revenue. **Formula:** ``` Services % = Services revenue / Total revenue × 100 ``` **Benchmarks:** - Below 10%: Product-led, minimal services - 10-20%: Services-assisted product - 20-30%: Balanced model - Above 30%: Services-heavy (may impact valuation multiples) **Note:** High services % can be viewed negatively by investors (less scalable than product revenue). --- ### Services Attach Rate **Definition:** Percentage of product deals that include services. **Formula:** ``` Attach Rate = Deals with services / Total deals × 100 ``` **What it tells you:** How often services are sold with product. --- ### Average Services Deal Size **Definition:** Average value of services engagements. **Formula:** ``` Avg Services Deal = Total services bookings / Number of services engagements ``` --- ### Services Backlog **Definition:** Contracted services not yet delivered. **Formula:** ``` Backlog = Services booked - Services delivered (revenue recognized) ``` **What it tells you:** Future services revenue and delivery workload. --- ## Profitability Metrics ### Services Gross Margin **Definition:** Services revenue minus direct delivery costs. **Formula:** ``` Services Gross Margin = (Services revenue - Direct delivery cost) / Services revenue × 100 ``` **Direct costs:** Consultant salaries, travel, contractor costs. **Benchmarks:** - Below 20%: Unprofitable, review pricing - 20-30%: Low margin - 30-40%: Average - 40-50%: Good - Above 50%: Excellent --- ### Project Margin **Definition:** Gross margin on individual projects. **Formula:** ``` Project Margin = (Project revenue - Project costs) / Project revenue × 100 ``` **What it tells you:** Profitability by engagement. Identify losers. --- ### Realization Rate **Definition:** Actual revenue realized vs potential revenue at standard rates. **Formula:** ``` Realization Rate = Actual revenue / (Hours worked × Standard rate) × 100 ``` **Benchmarks:** - Below 80%: Significant discounting or write-offs - 80-90%: Average - 90-100%: Good pricing discipline - Above 100%: Premium pricing achieved --- ### Write-off Rate **Definition:** Percentage of billable hours written off (not billed to client). **Formula:** ``` Write-off Rate = Written-off hours / Total billable hours × 100 ``` **Target:** <10% --- ## Utilization Metrics ### Billable Utilization **Definition:** Percentage of available time spent on billable work. **Formula:** ``` Billable Utilization = Billable hours / Available hours × 100 ``` **Available hours:** Total work hours minus PTO, holidays, company meetings. **Benchmarks:** - Below 60%: Underutilized - 60-70%: Average - 70-80%: Good - Above 80%: Maxed out (burnout risk) **Target:** 70-75% sustainable. --- ### Total Utilization **Definition:** Percentage of time spent on all productive work (billable + non-billable). **Formula:** ``` Total Utilization = (Billable + Non-billable productive hours) / Available hours × 100 ``` **Non-billable productive:** Training, pre-sales, internal projects. --- ### Bench Rate **Definition:** Percentage of team without billable assignment. **Formula:** ``` Bench Rate = Consultants without assignment / Total consultants × 100 ``` **Target:** <15% **What it tells you:** Capacity available vs excess. --- ### Capacity **Definition:** Total billable hours available in period. **Formula:** ``` Capacity = Consultants × Available hours per consultant ``` --- ### Capacity Utilization **Definition:** Billable hours sold vs available. **Formula:** ``` Capacity Utilization = Hours booked / Capacity × 100 ``` --- ## Delivery Metrics ### On-Time Delivery **Definition:** Percentage of projects delivered by committed date. **Formula:** ``` On-Time Delivery = Projects on time / Total projects completed × 100 ``` **Target:** >85% --- ### On-Budget Delivery **Definition:** Percentage of projects delivered within budget. **Formula:** ``` On-Budget = Projects within budget / Total projects × 100 ``` **Target:** >80% --- ### Scope Change Rate **Definition:** Percentage of projects with scope changes. **Formula:** ``` Scope Change Rate = Projects with scope changes / Total projects × 100 ``` **What it tells you:** Scoping accuracy and change management. --- ### Project Duration Accuracy **Definition:** Actual duration vs estimated duration. **Formula:** ``` Duration Accuracy = Estimated duration / Actual duration × 100 ``` **Target:** 90-110% --- ### Milestone Completion Rate **Definition:** Percentage of milestones completed on schedule. **Formula:** ``` Milestone Completion = Milestones on time / Total milestones × 100 ``` --- ## Quality Metrics ### Project CSAT **Definition:** Customer satisfaction with services engagement. **Formula:** ``` Project CSAT = Positive ratings / Total ratings × 100 ``` Surveyed at project completion. **Target:** >90% --- ### Project NPS **Definition:** Net Promoter Score for services experience. **Formula:** ``` Project NPS = % Promoters - % Detractors ``` --- ### Escalation Rate **Definition:** Percentage of projects with escalations. **Formula:** ``` Escalation Rate = Projects with escalations / Total projects × 100 ``` **Target:** <10% --- ### Rework Rate **Definition:** Percentage of deliverables requiring rework. **Formula:** ``` Rework Rate = Deliverables reworked / Total deliverables × 100 ``` **Target:** <5% --- ### Reference-ability **Definition:** Percentage of completed projects that become referenceable. **Formula:** ``` Reference-ability = Referenceable projects / Completed projects × 100 ``` **Target:** >70% --- ## Productivity Metrics ### Revenue per Consultant **Definition:** Services revenue per delivery resource. **Formula:** ``` Revenue per Consultant = Services revenue / Consultant headcount ``` **Benchmarks:** $150K-$300K annually, depending on rate structure. --- ### Projects per Consultant **Definition:** Average projects delivered per consultant per year. **Formula:** ``` Projects per Consultant = Completed projects / Consultant headcount ``` --- ### Average Project Duration **Definition:** Typical length of engagements. **Formula:** ``` Avg Duration = Sum of project durations / Number of projects ``` --- ## Pipeline Metrics ### Services Pipeline **Definition:** Value of services opportunities in pipeline. **Formula:** ``` Services Pipeline = Sum of services opportunity values ``` --- ### Services Win Rate **Definition:** Percentage of services opportunities won. **Formula:** ``` Services Win Rate = Services deals won / (Won + Lost) × 100 ``` --- ### Time to Start **Definition:** Time from services sold to project kickoff. **Formula:** ``` Time to Start = Median of (Kickoff date - Close date) ``` **What it tells you:** Resource availability and scheduling efficiency. --- ## Summary Table | Metric | Type | Primary Indicator Of | |--------|------|---------------------| | Services Revenue | Revenue | Services contribution | | Services Gross Margin | Profitability | Delivery economics | | Realization Rate | Profitability | Pricing discipline | | Billable Utilization | Utilization | Resource productivity | | Bench Rate | Utilization | Capacity management | | On-Time Delivery | Delivery | Project execution | | Project CSAT | Quality | Customer satisfaction | | Revenue per Consultant | Productivity | Team efficiency | --- # Metric Relationships How metrics connect and influence each other. This is the map. --- ## The Core Model Revenue is the outcome. Everything else drives it. ``` ┌─────────────────┐ │ ARR │ │ (Outcome) │ └────────┬────────┘ │ ┌──────────────────────────────┼──────────────────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ New MRR │ │ Expansion │ │ Churned │ │ │ │ MRR │ │ MRR │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ ┌─────────┴─────────┐ ┌────────┴────────┐ ┌────────┴────────┐ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ▼ ┌───────┐ ┌─────────┐ ┌──────┐ ┌─────────┐ ┌───────┐ ┌─────────┐ │Pipeline│ │Win Rate │ │Health│ │Expansion│ │ Churn │ │ NPS │ │ │ │ │ │Score │ │ Rate │ │ Rate │ │ │ └───┬───┘ └────┬────┘ └───┬──┘ └────┬────┘ └───┬───┘ └────┬────┘ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ▼ ┌───────┐ ┌─────────┐ ┌──────────┐ ┌───────┐ ┌─────────┐ ┌─────────┐ │ MQL │ │ Sales │ │ Product │ │ CSM │ │ Support │ │ Product │ │Volume │ │Execution│ │ Adoption │ │ Touch │ │ Quality │ │ Quality │ └───────┘ └─────────┘ └──────────┘ └───────┘ └─────────┘ └─────────┘ ``` --- ## Revenue Drivers ### ARR Growth **What increases it:** - New MRR (acquisition) - Expansion MRR (upsell/cross-sell) **What decreases it:** - Churned MRR (lost customers) - Contraction MRR (downgrades) **Formula:** ``` ARR Change = New MRR + Expansion MRR - Churned MRR - Contraction MRR ``` --- ### New MRR Drivers ``` New MRR = Deals Won × Average Deal Size Deals Won = Pipeline × Win Rate Pipeline = MQLs × MQL-to-SQL Rate × SQL-to-Opp Rate × ACV MQLs = Leads × Lead-to-MQL Rate Leads = Traffic × Conversion Rate ``` **Levers:** | To Increase New MRR | Action | |---------------------|--------| | More deals | Increase MQLs (marketing) | | Better conversion | Improve win rate (sales) | | Bigger deals | Increase ACV (pricing, product) | | Faster deals | Reduce sales cycle (process) | --- ### Expansion MRR Drivers ``` Expansion MRR = Customers × Expansion Rate × Average Expansion Size ``` **Levers:** | Driver | What Influences It | |--------|-------------------| | Expansion Rate | Product adoption, health score, CSM engagement | | Expansion Size | Pricing tiers, usage growth, additional seats | | Eligible customers | Contract structure, feature gating | **Key relationship:** High product adoption → high health scores → higher expansion probability. --- ### Churned MRR Drivers ``` Churned MRR = Customers × Churn Rate × Average Customer Value ``` **Levers:** | Driver | What Influences It | |--------|-------------------| | Churn Rate | NPS, health score, support quality, product fit | | Churn Timing | Contract length, renewal process, early warning | **Key relationships:** - Low NPS → higher churn (leading indicator by 3-6 months) - Low health score → higher churn risk - High support tickets → potential churn signal - Poor onboarding → higher early churn --- ## Efficiency Drivers ### CAC (Customer Acquisition Cost) ``` CAC = Sales & Marketing Spend / New Customers ``` **What increases CAC:** - Higher marketing spend without proportional lead increase - Lower win rates - Longer sales cycles - More expensive channels **What decreases CAC:** - Better lead quality (higher conversion) - More efficient channels - Faster sales cycles - Product-led growth --- ### LTV (Lifetime Value) ``` LTV = ARPA × Gross Margin / Churn Rate ``` **What increases LTV:** - Higher ARPA (pricing, upsell) - Better margins (lower COGS) - Lower churn (better retention) **Key relationship:** LTV and CAC must be considered together. LTV:CAC > 3:1 indicates healthy unit economics. --- ### CAC Payback ``` CAC Payback (months) = CAC / (ARPA × Gross Margin) ``` **Influenced by:** - CAC (higher = longer payback) - ARPA (higher = faster payback) - Gross Margin (higher = faster payback) --- ## Retention Chain ``` Onboarding Quality │ ▼ Product Adoption ────► Health Score ────► Renewal Probability │ │ │ ▼ ▼ ▼ Engagement NPS/CSAT NRR / GRR │ │ │ └────────────────────┴─────────────────────┘ │ ▼ Revenue Retention ``` **Key relationships:** | If This Goes Down | These Follow | |-------------------|--------------| | Onboarding completion | Product adoption, early churn | | Product adoption | Health scores, expansion, NPS | | Health scores | Renewal probability, churn | | NPS | Churn (lagged 3-6 months) | | Support CSAT | NPS, health score | --- ## Leading vs Lagging Indicators ### Leading Indicators (Early Warning) These change first, before outcomes: **Note:** Lead times are approximate ranges based on typical SaaS patterns. Actual lag varies by business model, sales cycle and customer segment. Calibrate to your own data. | Metric | What It Predicts | Typical Lead Time | |--------|------------------|-----------| | Pipeline coverage | Revenue miss | 1-2 quarters | | MQL volume | Future pipeline | 1-2 months | | NPS trend | Churn | 3-6 months | | Health score decline | Churn | 1-3 months | | Support ticket spike | NPS decline, churn | 1-2 months | | Product usage decline | Health decline, churn | 2-4 weeks | | Onboarding completion | Early churn | 1-3 months | ### Lagging Indicators (Outcomes) These confirm what happened: | Metric | What It Confirms | |--------|-----------------| | Revenue | Overall performance | | Churn | Retention failure | | Win rate | Sales effectiveness | | NRR | Customer value growth | --- ## Departmental Impact Map ### If Revenue Is Down **Check in this order:** 1. **New MRR down?** → Sales problem - Check pipeline, win rate, cycle time 2. **Expansion down?** → CS/Product problem - Check health scores, adoption, CSM coverage 3. **Churn up?** → Retention problem - Check NPS, support metrics, product issues --- ### If Churn Is Up **Investigation path:** ``` Churn Up │ ├── Check NPS trend │ └── If declining → deeper customer satisfaction issue │ ├── Check support metrics │ └── If tickets up / CSAT down → support or product quality │ ├── Check onboarding metrics │ └── If completion down → onboarding process issue │ ├── Check product adoption │ └── If declining → product-market fit or engagement │ └── Check by segment/cohort └── If concentrated → specific segment issue ``` --- ### If Pipeline Is Light **Investigation path:** ``` Pipeline Light │ ├── Check MQL volume │ └── If down → marketing funnel issue │ ├── Check lead volume → awareness/traffic │ └── Check conversion → content/targeting │ ├── Check SQL conversion │ └── If down → lead quality or SDR effectiveness │ ├── Check ACV │ └── If down → deal size/pricing issue │ └── Check source mix └── If channel shift → channel performance issue ``` --- ## The Full System ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ BUSINESS HEALTH │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ ACQUIRE ONBOARD ADOPT EXPAND RETAIN │ │ │ │ Traffic TTFV DAU/MAU Expansion GRR │ │ │ │ │ Rate NRR │ │ ▼ ▼ ▼ │ Churn │ │ Leads ─────► Onboarding ─────► Adoption ─────► Upsell │ │ │ │ │ Completion Health Score Cross-sell │ │ │ ▼ │ │ │ │ │ │ MQLs │ ▼ ▼ ▼ │ │ │ └────────► NPS ◄───────────────────┴────────────┘ │ │ ▼ │ │ │ SQLs │ │ │ │ ▼ │ │ ▼ ┌──────────────────────┐ │ │ Pipeline │ REVENUE │ │ │ │ │ ARR, MRR, Growth │ │ │ ▼ └──────────────────────┘ │ │ Closed Won ▲ │ │ │ │ │ │ └───────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` Every department's metrics feed into this system. Understanding the connections is how you diagnose problems and identify opportunities. --- # Commercial Event Ledger (CEL) The single source of truth for all metric computation in the GASP Standard. Every metric in this standard (revenue, retention, efficiency, operational) derives from atomic commercial events. The CEL is the governed layer where those events live. If an event is not in the CEL, it does not exist for metric purposes. If a metric cannot be traced to CEL events, it is not a governed metric. --- ## Why the CEL Exists SaaS companies typically compute metrics from derived tables: MRR snapshots, billing system exports, CRM rollups. These derived sources introduce drift. Two teams querying the same concept from different derived tables get different numbers. The CEL eliminates this by establishing a single event-level layer from which all metrics are computed. The CEL is not a product. It is a conceptual standard for how commercial events should be captured, stored and governed. Implement it in your warehouse, your lakehouse or your operational database. The schema is the contract. --- ## Design Principles 1. **Immutable events.** Once recorded, a CEL event is never modified. Corrections are new events (e.g., a `Revenue_Event` of type `adjustment`). This preserves auditability and enables point-in-time reconstruction. 2. **No derived data upstream.** The CEL contains atomic facts. MRR, ARR, NRR and every other metric are computed *from* CEL events, never stored *in* the CEL. Derived values live downstream. 3. **Daily atomic grain.** Every event has a date. The day is the smallest unit. Weekly, monthly, quarterly and annual views are aggregations of daily events. 4. **One event, one truth.** Each commercial event is recorded once. If a subscription renewal generates both a `Revenue_Event` and a `Contract_Event`, those are two distinct events. Not one event with two types. 5. **Source-system agnostic.** The CEL defines *what* to capture, not *where* it comes from. Events may originate in billing systems, CRMs, HRIS or manual entries. The CEL schema is the normalization layer. --- ## Event Classes The CEL defines five event classes. Every commercial event in a subscription SaaS business falls into one of these. ### Revenue_Event A change in recurring revenue. This is the primary input for MRR, ARR, NRR, GRR and revenue churn metrics. | Field | Type | Description | |-------|------|-------------| | `event_id` | `string` | Unique identifier | | `event_date` | `date` | Date the event occurred | | `customer_id` | `string` | [Customer](https://gaspwiki.com/v1/definitions#customer-account-organization) identifier | | `subscription_id` | `string` | [Subscription](https://gaspwiki.com/v1/definitions#subscription-contract-agreement) identifier | | `event_type` | `enum` | `new`, `expansion`, `contraction`, `churn`, `reactivation`, `renewal` | | `mrr_change` | `decimal` | Change in MRR (positive for new/expansion/reactivation, negative for contraction/churn) | | `currency` | `string` | ISO 4217 currency code | | `prior_mrr` | `decimal` | MRR before this event | | `new_mrr` | `decimal` | MRR after this event | | `change_nature` | `enum` (optional) | `permanent` (default), `temporary`, `scheduled_reversal`. See [Change Nature](#change-nature). | --- ### Cost_Event An incurred cost attributable to a commercial function. Primary input for CAC, Gross Margin, LTV and efficiency metrics. | Field | Type | Description | |-------|------|-------------| | `event_id` | `string` | Unique identifier | | `event_date` | `date` | Date the cost was incurred | | `cost_centre` | `string` | Department or team | | `amount` | `decimal` | Cost amount | | `currency` | `string` | ISO 4217 currency code | | `cost_type` | `enum` | `personnel`, `software`, `services`, `infrastructure`, `other` | | `customer_id` | `string` (nullable) | Customer if directly attributable; null for shared costs | | `description` | `string` | Human-readable description | --- ### Contract_Event A contractual milestone. Primary input for bookings, renewal rate and contract-level metrics. | Field | Type | Description | |-------|------|-------------| | `event_id` | `string` | Unique identifier | | `event_date` | `date` | Date of contractual action | | `customer_id` | `string` | [Customer](https://gaspwiki.com/v1/definitions#customer-account-organization) identifier | | `subscription_id` | `string` | [Subscription](https://gaspwiki.com/v1/definitions#subscription-contract-agreement) identifier | | `event_type` | `enum` | `new_contract`, `renewal`, `amendment`, `cancellation` | | `contract_start` | `date` | Contract start date | | `contract_end` | `date` | Contract end date | | `tcv` | `decimal` | Total contract value | | `acv` | `decimal` | Annual contract value | | `currency` | `string` | ISO 4217 currency code | --- ### Amendment_Event A mid-term change to an existing subscription. Distinct from `Contract_Event` because amendments happen *during* a contract term, not at boundaries. Primary input for expansion/contraction classification. | Field | Type | Description | |-------|------|-------------| | `event_id` | `string` | Unique identifier | | `event_date` | `date` | Date of amendment | | `customer_id` | `string` | [Customer](https://gaspwiki.com/v1/definitions#customer-account-organization) identifier | | `subscription_id` | `string` | [Subscription](https://gaspwiki.com/v1/definitions#subscription-contract-agreement) identifier | | `amendment_type` | `enum` | `upgrade`, `downgrade`, `add_on`, `seat_change`, `pricing_change` | | `mrr_change` | `decimal` | Change in MRR resulting from amendment | | `prior_plan` | `string` | Plan/tier before amendment | | `new_plan` | `string` | Plan/tier after amendment | | `prior_quantity` | `integer` (nullable) | Seat/unit count before (if applicable) | | `new_quantity` | `integer` (nullable) | Seat/unit count after (if applicable) | | `change_nature` | `enum` (optional) | `permanent` (default), `temporary`, `scheduled_reversal`. See [Change Nature](#change-nature). | --- ### Lifecycle_State_Change A change in customer lifecycle status. Primary input for health scores, onboarding metrics and churn prediction. | Field | Type | Description | |-------|------|-------------| | `event_id` | `string` | Unique identifier | | `event_date` | `date` | Date of state change | | `customer_id` | `string` | [Customer](https://gaspwiki.com/v1/definitions#customer-account-organization) identifier | | `prior_state` | `string` | Previous lifecycle state | | `new_state` | `string` | New lifecycle state | | `state_category` | `enum` | `activation`, `onboarding_complete`, `healthy`, `at_risk`, `churned`, `reactivated` | | `trigger` | `string` | What caused the state change (e.g., "health score drop below 40", "90-day inactivity") | --- ## Example Events These worked examples show how real-world commercial actions map to CEL events. ### 1. Subscription Activation A new customer signs up for a $500/mo plan. ```json { "event_class": "Revenue_Event", "event_id": "rev-001", "event_date": "2026-02-01", "customer_id": "cust-1042", "subscription_id": "sub-2001", "event_type": "new", "mrr_change": 500.00, "currency": "USD", "prior_mrr": 0.00, "new_mrr": 500.00 } ``` ### 2. Usage Commit Realisation An existing customer's usage commitment triggers an additional $200/mo. ```json { "event_class": "Revenue_Event", "event_id": "rev-002", "event_date": "2026-02-15", "customer_id": "cust-0783", "subscription_id": "sub-1450", "event_type": "expansion", "mrr_change": 200.00, "currency": "USD", "prior_mrr": 1000.00, "new_mrr": 1200.00 } ``` ### 3. Mid-Term Expansion (Seat Add) Customer adds 10 seats at $50/seat/mo mid-contract. ```json { "event_class": "Amendment_Event", "event_id": "amd-001", "event_date": "2026-02-10", "customer_id": "cust-0512", "subscription_id": "sub-0890", "amendment_type": "seat_change", "mrr_change": 500.00, "prior_plan": "Professional", "new_plan": "Professional", "prior_quantity": 20, "new_quantity": 30 } ``` ### 4. Cross-Module Expansion Customer on the Analytics module purchases the Automation module. ```json { "event_class": "Amendment_Event", "event_id": "amd-002", "event_date": "2026-03-01", "customer_id": "cust-0512", "subscription_id": "sub-0891", "amendment_type": "add_on", "mrr_change": 800.00, "prior_plan": "Analytics Pro", "new_plan": "Analytics Pro + Automation", "prior_quantity": null, "new_quantity": null } ``` ### 5. Reactivation A previously churned customer returns with a new subscription. ```json { "event_class": "Revenue_Event", "event_id": "rev-003", "event_date": "2026-02-20", "customer_id": "cust-0291", "subscription_id": "sub-2050", "event_type": "reactivation", "mrr_change": 750.00, "currency": "USD", "prior_mrr": 0.00, "new_mrr": 750.00 } ``` ### 6. Onboarding Engineering Cost Implementation team spends 40 hours onboarding a new enterprise customer. ```json { "event_class": "Cost_Event", "event_id": "cost-001", "event_date": "2026-02-05", "cost_centre": "Implementation", "amount": 6000.00, "currency": "USD", "cost_type": "personnel", "customer_id": "cust-1042", "description": "40 hrs implementation engineering @ $150/hr" } ``` ### 7. Implementation Labour (Shared) Marketing spend on demand generation. Not attributable to a single customer. ```json { "event_class": "Cost_Event", "event_id": "cost-002", "event_date": "2026-02-28", "cost_centre": "Marketing", "amount": 45000.00, "currency": "USD", "cost_type": "services", "customer_id": null, "description": "February demand generation campaigns" } ``` ### 8. Retention Success Servicing CS team effort to retain an at-risk account. ```json { "event_class": "Cost_Event", "event_id": "cost-003", "event_date": "2026-02-12", "cost_centre": "Customer Success", "amount": 2400.00, "currency": "USD", "cost_type": "personnel", "customer_id": "cust-0783", "description": "16 hrs success engineering for at-risk retention" } ``` ### 9. Contract Renewal Customer renews for another 12-month term. ```json { "event_class": "Contract_Event", "event_id": "con-001", "event_date": "2026-03-01", "customer_id": "cust-0350", "subscription_id": "sub-0670", "event_type": "renewal", "contract_start": "2026-03-01", "contract_end": "2027-02-28", "tcv": 24000.00, "acv": 24000.00, "currency": "USD" } ``` ### 10. Health Score Drop Customer's health score deteriorates, triggering an at-risk state. ```json { "event_class": "Lifecycle_State_Change", "event_id": "lsc-001", "event_date": "2026-02-18", "customer_id": "cust-0783", "prior_state": "healthy", "new_state": "at_risk", "state_category": "at_risk", "trigger": "Health score dropped from 72 to 35" } ``` --- ## Example SQL A minimal warehouse implementation. This is illustrative, not normative. Adapt to your warehouse dialect and tooling. ### Schema ```sql CREATE TABLE cel_revenue_events ( event_id VARCHAR(64) PRIMARY KEY, event_date DATE NOT NULL, customer_id VARCHAR(64) NOT NULL, subscription_id VARCHAR(64) NOT NULL, event_type VARCHAR(20) NOT NULL, -- new, expansion, contraction, churn, reactivation, renewal mrr_change DECIMAL(12,2) NOT NULL, currency CHAR(3) NOT NULL DEFAULT 'USD', prior_mrr DECIMAL(12,2) NOT NULL, new_mrr DECIMAL(12,2) NOT NULL, change_nature VARCHAR(20) DEFAULT 'permanent', -- permanent, temporary, scheduled_reversal created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE cel_cost_events ( event_id VARCHAR(64) PRIMARY KEY, event_date DATE NOT NULL, cost_centre VARCHAR(64) NOT NULL, amount DECIMAL(12,2) NOT NULL, currency CHAR(3) NOT NULL DEFAULT 'USD', cost_type VARCHAR(20) NOT NULL, customer_id VARCHAR(64), description TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); ``` ### Querying: MRR at End of Month ```sql SELECT DATE_TRUNC('month', event_date) AS month, SUM(mrr_change) AS net_mrr_change FROM cel_revenue_events WHERE event_date <= '2026-02-28' GROUP BY 1 ORDER BY 1; ``` ### Querying: New MRR in February ```sql SELECT SUM(mrr_change) AS new_mrr FROM cel_revenue_events WHERE event_type = 'new' AND event_date BETWEEN '2026-02-01' AND '2026-02-28'; ``` --- ## Change Nature An optional field on `Revenue_Event` and `Amendment_Event` that captures the intent behind a revenue movement. This field does not alter how events are classified or how metrics are calculated. It provides structured metadata that enables downstream analysis of revenue quality. ### Values | Value | Meaning | Example | |-------|---------|---------| | `permanent` | The change reflects a durable shift in the customer relationship. This is the default when the field is omitted. | Customer upgrades from Starter to Pro. | | `temporary` | The change is expected to reverse within a defined period. The underlying subscription relationship has not structurally changed. | Customer purchases a 3-month add-on for a seasonal campaign. | | `scheduled_reversal` | This event reverses a prior `temporary` event. It should be paired with the original event for analysis. | The 3-month add-on expires and MRR returns to its prior level. | ### Design Principles 1. **No metric redefinition.** MRR, ARR and NRR calculations are unchanged. A `temporary` expansion still counts as expansion in the standard metrics. The field enables a second analytical lens, not a replacement. 2. **Default is permanent.** If `change_nature` is omitted the event is treated as permanent. Teams adopt this field incrementally by tagging only the events where temporality matters. 3. **No subjective judgment.** The values describe contractual or operational facts, not interpretations. A temporary upgrade is temporary because the contract says so, not because someone thinks it might reverse. ### Example: Temporary Upgrade and Reversal A customer on a $1,000/mo plan purchases a 3-month analytics add-on for $600/mo. **Month 1: Upgrade** ```json { "event_class": "Revenue_Event", "event_id": "rev-010", "event_date": "2026-04-01", "customer_id": "cust-0512", "subscription_id": "sub-0890", "event_type": "expansion", "mrr_change": 600.00, "currency": "USD", "prior_mrr": 1000.00, "new_mrr": 1600.00, "change_nature": "temporary" } ``` **Month 4: Add-on expires** ```json { "event_class": "Revenue_Event", "event_id": "rev-011", "event_date": "2026-07-01", "customer_id": "cust-0512", "subscription_id": "sub-0890", "event_type": "contraction", "mrr_change": -600.00, "currency": "USD", "prior_mrr": 1600.00, "new_mrr": 1000.00, "change_nature": "scheduled_reversal" } ``` Under standard GASP metrics this produces +$600 expansion in April and -$600 contraction in July. Both are mechanically correct. The `change_nature` field allows downstream analysis to separate this expected reversal from true contraction that signals customer health risk. ### Adjusted NRR Teams that adopt `change_nature` can compute an adjusted NRR that excludes temporary movements. This is not a replacement for standard NRR. It is a complementary metric for internal revenue quality analysis. ``` Adjusted NRR = (Beginning MRR + Permanent Expansion - Permanent Contraction - Churn) / Beginning MRR x 100 ``` Where: - **Permanent Expansion** = expansion events where `change_nature` is `permanent` or omitted - **Permanent Contraction** = contraction events where `change_nature` is `permanent` or omitted The standard NRR (reported to investors and boards) includes all movements regardless of `change_nature`. Adjusted NRR is an internal signal. Both are computed from the same CEL events. ### SQL: Adjusted vs. Standard NRR ```sql -- Standard NRR (all movements) SELECT SUM(CASE WHEN event_type = 'expansion' THEN mrr_change ELSE 0 END) + SUM(CASE WHEN event_type IN ('contraction', 'churn') THEN mrr_change ELSE 0 END) + beginning_mrr ) / beginning_mrr * 100 AS nrr_standard, -- Adjusted NRR (permanent movements only) ( SUM(CASE WHEN event_type = 'expansion' AND COALESCE(change_nature, 'permanent') = 'permanent' THEN mrr_change ELSE 0 END) + SUM(CASE WHEN event_type IN ('contraction', 'churn') AND COALESCE(change_nature, 'permanent') = 'permanent' THEN mrr_change ELSE 0 END) + beginning_mrr ) / beginning_mrr * 100 AS nrr_adjusted FROM cohort_summary; ``` --- ## Relationship to Existing Data Model The GASP Standard defines a three-level entity hierarchy in [Definitions](https://gaspwiki.com/v1/definitions#foundational-entities): | Entity | CEL Relationship | |--------|-----------------| | **Customer** | `customer_id` on all event classes. A customer churns when their last active subscription generates a churn `Revenue_Event`. | | **Subscription** | `subscription_id` on `Revenue_Event`, `Contract_Event` and `Amendment_Event`. MRR lives here. | | **License** | Not directly in the CEL. Licenses are derived from subscriptions. Seat counts appear on `Amendment_Event` as `prior_quantity` / `new_quantity`. | The CEL does not replace the entity model. It records *events that happen to* entities. The entity model defines the nouns; the CEL defines the verbs. --- ## Scope Boundaries **The CEL covers:** - All recurring revenue changes (new, expansion, contraction, churn, reactivation, renewal) - Costs attributable to commercial functions (S&M, COGS, implementation, support) - Contractual milestones (new, renewal, amendment, cancellation) - Mid-term subscription changes - Customer lifecycle state transitions **The CEL does not cover:** - Product usage events (page views, feature clicks, API calls). These belong in a product analytics layer - GAAP revenue recognition events. These belong in the accounting ledger - HR events (hiring, termination). Unless directly costed as `Cost_Event` - Infrastructure events (deployments, incidents). These belong in engineering observability The CEL is scoped to the same domain as the rest of the GASP Standard: subscription-based SaaS with recurring revenue. Usage-based pricing, marketplace transactions and services-only revenue are out of scope. --- ## What Comes Next The CEL provides the atomic events. The [Attribution Taxonomy Layer (ATL)](https://gaspwiki.com/v1/atl) provides the tags that make dual-lens metrics possible by classifying each event by lifecycle stage, expansion type and cost function. Together, CEL + ATL form the foundation for Operating (O) and Market (M) metric forms. Ops teams get their internal economic truth and boards get the investor-comparable numbers, computed from the same events. --- # Attribution Taxonomy Layer (ATL) The tagging system that makes dual-lens metrics possible. Every event in the [Commercial Event Ledger (CEL)](https://gaspwiki.com/v1/cel) is an atomic fact: something happened, to someone, on a date, for an amount. But the same event can mean different things depending on which lens you apply. A $500/mo expansion might be organic seat growth (operating signal) or it might include a cross-module upsell (market-comparable signal). The ATL classifies events so that downstream metrics can include or exclude based on governed rules. ATL tags are not optional. Every CEL event must carry the tags appropriate to its event class. Without ATL, the CEL is just a ledger. With ATL, it becomes a semantic layer. --- ## Three Tag Dimensions ATL defines three orthogonal tag dimensions. Each dimension answers a different question about a CEL event. | Dimension | Question | Applies to | |-----------|----------|------------| | **Lifecycle Attribution** | Where is this customer in their journey? | All event classes | | **Expansion Classification** | What kind of growth is this? | `Revenue_Event` (expansion/reactivation), `Amendment_Event` | | **Cost Function Attribution** | What commercial function incurred this cost? | `Cost_Event` | --- ## Lifecycle Attribution Every CEL event receives exactly one lifecycle tag. This is the primary dimension. It tells you *why* the event happened in the context of the customer relationship. ### Values | Tag | Definition | Example | |-----|-----------|---------| | `Acquisition` | First commercial engagement with a new customer. | New customer signs a $2,000/mo contract. | | `Activation` | Customer reaches first value milestone after acquisition. | Customer completes onboarding and goes live in production. | | `Retention` | Existing customer continues or renews without change. | Annual renewal at the same MRR. | | `Expansion` | Existing customer increases their commercial commitment. | Customer upgrades from Professional to Enterprise tier. | | `Reactivation` | Previously churned customer returns. | Customer who cancelled 6 months ago signs a new contract. | | `Servicing` | Ongoing delivery cost for an active customer. | Monthly infrastructure cost, support staffing. | ### Assignment Rules 1. A customer's first `Revenue_Event` is always `Acquisition`. 2. `Lifecycle_State_Change` events with `state_category = activation` or `state_category = onboarding_complete` are `Activation`. 3. `Revenue_Event` with `event_type = renewal` and zero MRR change is `Retention`. 4. `Revenue_Event` with `event_type = expansion` is `Expansion`. 5. `Revenue_Event` with `event_type = reactivation` is `Reactivation`. 6. `Cost_Event` records for active customers with no change event are `Servicing`. 7. When a single action generates multiple CEL events (e.g., a renewal with expansion), each event gets its own lifecycle tag. The renewal portion is `Retention`; the expansion portion is `Expansion`. --- ## Expansion Classification Revenue growth and mid-term amendments are not all the same. A customer adding seats to the same product is fundamentally different from a customer buying a new module. This dimension captures that distinction. Applies to: `Revenue_Event` where `event_type` is `expansion` or `reactivation`, and all `Amendment_Event` records. ### Values | Tag | Definition | Example | |-----|-----------|---------| | `Same_Product` | More of what the customer already has. Seat adds, tier upgrades within the same module. | 20 → 30 seats on the same Professional plan. | | `New_Module` | Customer purchases a distinct product module they did not have before. | Analytics customer adds the Automation module. | | `New_Buying_Centre` | A different department or division within the same legal entity starts purchasing. | Engineering team adopts the product already used by Marketing. | | `Pricing_Adjustment` | MRR change driven by pricing action, not usage or scope change. | Annual price increase of 5% on renewal. | | `Recontracting` | MRR change driven by contract restructuring (e.g., monthly → annual, co-terming). | Customer consolidates three monthly subscriptions into one annual contract. | | `Usage_Realisation` | MRR change from usage commitments being met or exceeded. | Customer exceeds their committed API call volume, triggering overage billing. | ### Why This Matters This is the dimension that makes NRR-O differ from NRR-M. - **NRR-O (Operating)** focuses on organic, durable expansion: `Same_Product` and `Usage_Realisation`. These signal product-market fit and natural customer growth. - **NRR-M (Market)** includes all expansion types because investor-comparable NRR counts everything that is not net-new logo acquisition. Without expansion classification, you cannot separate organic growth signals from commercial motion signals. Both are valid. They answer different questions. --- ## Cost Function Attribution Not all costs serve the same commercial purpose. S&M spend to acquire new logos is fundamentally different from implementation labour to onboard them. This dimension classifies costs by function. Applies to: all `Cost_Event` records. ### Values | Tag | Definition | Example | |-----|-----------|---------| | `GTM` | Go-to-market costs: demand generation, sales compensation, partner commissions. | $45,000 monthly marketing spend; $12,000 SDR compensation. | | `Implementation` | Costs to deploy and configure the product for a new customer. | 40 hours of solutions engineering at $150/hr. | | `Onboarding` | Costs to train and enable a new customer post-implementation. | CSM time for 90-day onboarding programme. | | `Infrastructure` | Hosting, compute, storage and third-party service costs (COGS). | AWS monthly bill; Datadog monitoring. | | `Support` | Reactive customer assistance: tickets, escalations, troubleshooting. | Support team salaries; helpdesk tooling. | | `Success_Engineering` | Proactive customer engagement: health monitoring, adoption programmes, QBRs. | CS team salaries; Gainsight licensing. | | `Account_Management` | Renewal and expansion selling to existing customers. | Account executive compensation for upsell quota. | ### Why This Matters This is the dimension that makes CAC-O differ from CAC-M. - **CAC-O (Operating)** includes all costs to make a customer productive: `GTM` + `Implementation` + `Onboarding`. This reflects the true economic cost of acquiring a revenue-generating customer. - **CAC-M (Market)** includes only `GTM` costs, matching the S&M-based CAC that investors use for benchmarking. Without cost function attribution, you cannot compute both perspectives from the same data. You end up maintaining two separate cost allocation models. --- ## Tagging Rules Every CEL event must be tagged according to these rules. No exceptions. ### Rule 1: Every event gets a Lifecycle tag All five event classes receive exactly one `lifecycle_attribution` tag. ### Rule 2: Revenue growth and amendments get an Expansion tag `Revenue_Event` records where `event_type` is `expansion` or `reactivation`, and all `Amendment_Event` records, receive exactly one `expansion_classification` tag. ### Rule 3: Cost events get a Cost Function tag All `Cost_Event` records receive exactly one `cost_function` tag. ### Rule 4: Tags are mutually exclusive within a dimension An event cannot have two lifecycle tags, two expansion tags or two cost function tags. If an action spans two categories, it must be recorded as two CEL events with separate tags. ### Rule 5: Tags are assigned at event creation ATL tags are set when the CEL event is created and are immutable thereafter, consistent with the CEL's immutability principle. Corrections require new events. --- ## Example Tagged Events These examples show CEL events with their ATL tags applied. ### 1. New Customer Acquisition ```json { "event_class": "Revenue_Event", "event_id": "rev-001", "event_date": "2026-02-01", "customer_id": "cust-1042", "subscription_id": "sub-2001", "event_type": "new", "mrr_change": 500.00, "currency": "USD", "prior_mrr": 0.00, "new_mrr": 500.00, "lifecycle_attribution": "Acquisition" } ``` ### 2. Organic Seat Expansion ```json { "event_class": "Amendment_Event", "event_id": "amd-001", "event_date": "2026-02-10", "customer_id": "cust-0512", "subscription_id": "sub-0890", "amendment_type": "seat_change", "mrr_change": 500.00, "prior_quantity": 20, "new_quantity": 30, "lifecycle_attribution": "Expansion", "expansion_classification": "Same_Product" } ``` ### 3. Cross-Module Upsell ```json { "event_class": "Amendment_Event", "event_id": "amd-002", "event_date": "2026-03-01", "customer_id": "cust-0512", "subscription_id": "sub-0891", "amendment_type": "add_on", "mrr_change": 800.00, "lifecycle_attribution": "Expansion", "expansion_classification": "New_Module" } ``` ### 4. GTM Spend (Shared Cost) ```json { "event_class": "Cost_Event", "event_id": "cost-002", "event_date": "2026-02-28", "cost_centre": "Marketing", "amount": 45000.00, "currency": "USD", "cost_type": "services", "customer_id": null, "description": "February demand generation campaigns", "lifecycle_attribution": "Acquisition", "cost_function": "GTM" } ``` ### 5. Onboarding Labour (Customer-Specific Cost) ```json { "event_class": "Cost_Event", "event_id": "cost-001", "event_date": "2026-02-05", "cost_centre": "Implementation", "amount": 6000.00, "currency": "USD", "cost_type": "personnel", "customer_id": "cust-1042", "description": "40 hrs implementation engineering @ $150/hr", "lifecycle_attribution": "Activation", "cost_function": "Implementation" } ``` ### 6. Retention Success Servicing ```json { "event_class": "Cost_Event", "event_id": "cost-003", "event_date": "2026-02-12", "cost_centre": "Customer Success", "amount": 2400.00, "currency": "USD", "cost_type": "personnel", "customer_id": "cust-0783", "description": "16 hrs success engineering for at-risk retention", "lifecycle_attribution": "Servicing", "cost_function": "Success_Engineering" } ``` --- ## Example SQL ATL tags live as columns on CEL event tables. Querying by ATL dimension is a simple `WHERE` clause. ### CAC-O (Operating): Full Acquisition Cost ```sql SELECT DATE_TRUNC('quarter', e.event_date) AS quarter, SUM(e.amount) / NULLIF(COUNT(DISTINCT r.customer_id), 0) AS cac_o FROM cel_cost_events e CROSS JOIN ( SELECT DISTINCT customer_id, event_date FROM cel_revenue_events WHERE event_type = 'new' ) r WHERE e.lifecycle_attribution IN ('Acquisition', 'Activation') AND e.event_date BETWEEN DATE_TRUNC('quarter', r.event_date) AND DATE_TRUNC('quarter', r.event_date) + INTERVAL '3 months' GROUP BY 1; ``` ### CAC-M (Market): GTM-Only Acquisition Cost ```sql SELECT DATE_TRUNC('quarter', e.event_date) AS quarter, SUM(e.amount) / NULLIF(COUNT(DISTINCT r.customer_id), 0) AS cac_m FROM cel_cost_events e CROSS JOIN ( SELECT DISTINCT customer_id, event_date FROM cel_revenue_events WHERE event_type = 'new' ) r WHERE e.lifecycle_attribution = 'Acquisition' AND e.cost_function = 'GTM' AND e.event_date BETWEEN DATE_TRUNC('quarter', r.event_date) AND DATE_TRUNC('quarter', r.event_date) + INTERVAL '3 months' GROUP BY 1; ``` ### NRR-O (Operating): Organic Retention ```sql SELECT SUM(CASE WHEN event_type IN ('expansion') AND expansion_classification IN ('Same_Product', 'Usage_Realisation') THEN mrr_change ELSE 0 END) + SUM(CASE WHEN event_type IN ('contraction', 'churn') THEN mrr_change ELSE 0 END) + SUM(CASE WHEN event_type = 'renewal' THEN new_mrr ELSE 0 END) AS nrr_o_numerator FROM cel_revenue_events WHERE lifecycle_attribution IN ('Retention', 'Expansion') AND (expansion_classification IS NULL OR expansion_classification IN ('Same_Product', 'Usage_Realisation')) AND event_date BETWEEN '2025-03-01' AND '2026-02-28'; ``` --- ## How O/M Metrics Use ATL ATL tags are the mechanism that distinguishes Operating (O) from Market (M) metric forms. O-form metrics reflect internal economic reality. What ops teams use to run the business. M-form metrics match investor-comparable definitions. What boards and investors benchmark against peers. The pattern is consistent: | Metric | Operating (O) Includes | Market (M) Includes | |--------|----------------------|-------------------| | **CAC** | `lifecycle_attribution` ∈ (Acquisition, Activation) | `lifecycle_attribution` = Acquisition AND `cost_function` = GTM | | **NRR** | `expansion_classification` ∈ (Same_Product, Usage_Realisation) | All `expansion_classification` except net-new logos | | **LTV** | Contribution margin (includes Implementation, Onboarding costs) | Gross margin (COGS only) | | **Churn** | Hazard-based: includes at-risk state transitions | Logo-based: binary churned/active | | **ARR** | Durable ARR: excludes Recontracting, Pricing_Adjustment | Contracted ARR: all recurring revenue | The full inclusion/exclusion rules for each Core 8 metric (ARR, CAC, NRR, LTV, Churn, GRR, Gross Margin, Rule of 40) will be specified as O/M subsections in [Core Metrics](https://gaspwiki.com/v1/metrics/core) in a future update. The ATL dimensions defined here are the building blocks for those rules. --- ## Relationship to Existing Metrics The current GASP Standard defines metrics with Include/Exclude lists (e.g., CAC includes S&M + implementation costs. NRR excludes reactivation from some calculations). These existing definitions are implicitly the Operating (O) perspective. They represent the economic truth that internal operators need. ATL does not replace those definitions. It provides the tagging vocabulary that makes it possible to *also* compute the Market (M) perspective from the same underlying events, and to formally reconcile the two via a Translation Bridge.