# 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://koinedata.com. Index: https://koinedata.com/llms.txt. > Machine-readable data: https://koinedata.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://koinedata.com/v1/overview - Canonical Definitions: https://koinedata.com/v1/definitions - MRR, ARR, NRR, GRR, CAC, LTV, Rule of 40: Standard Definitions: https://koinedata.com/v1/metrics/core - SaaS Sales Metrics: Pipeline, Win Rate, ACV, Quota Attainment: https://koinedata.com/v1/metrics/sales - SaaS Marketing Metrics: MQL, SQL, CAC, Funnel Conversion: https://koinedata.com/v1/metrics/marketing - SaaS Customer Success Metrics: NRR, Health Score, Churn: https://koinedata.com/v1/metrics/customer-success - SaaS Support Metrics: CSAT, CES, First Response Time: https://koinedata.com/v1/metrics/support - SaaS Onboarding Metrics: Time to First Value, Activation: https://koinedata.com/v1/metrics/onboarding - SaaS Product Metrics: DAU/MAU, Feature Adoption, Stickiness: https://koinedata.com/v1/metrics/product - SaaS Engineering Metrics: DORA, Uptime, Deploy Frequency: https://koinedata.com/v1/metrics/engineering - SaaS Finance Metrics: Gross Margin, Burn Rate, Magic Number: https://koinedata.com/v1/metrics/finance - SaaS RevOps Metrics: Forecast Accuracy, DSO, Quote-to-Cash: https://koinedata.com/v1/metrics/revops - SaaS People Metrics: Turnover, eNPS, Revenue per Employee: https://koinedata.com/v1/metrics/people - SaaS Partnership Metrics: Partner Revenue, Channel Attribution: https://koinedata.com/v1/metrics/partnerships - SaaS Professional Services Metrics: Utilization, Margin: https://koinedata.com/v1/metrics/professional-services - Metric Relationships: https://koinedata.com/v1/relationships - Commercial Event Ledger (CEL): https://koinedata.com/v1/cel - Attribution Taxonomy Layer (ATL): https://koinedata.com/v1/atl --- # The GASP Standard ## The Unified SaaS Reporting Standard **GAAP for SaaS.** Generally Accepted Accounting Principles standardised financial reporting for management and investors alike. The GASP Standard does the same for SaaS metrics, with one consensus definition per metric and one way to calculate it. --- ## Foundation The GASP Standard provides canonical definitions for SaaS metrics across all departments, drawing on published work from 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 - This overview and the [metrics index](https://koinedata.com/v1/metrics), which together give the standard view of business health - Practical implementation guidance We follow industry consensus where it exists and fill the gaps from 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 spend meetings arguing about definitions when they could be discussing the numbers. The GASP Standard writes down how the industry already measures performance: a consensus that exists in practice but had not been recorded in one place. --- ## What This Standard Provides - **Canonical definitions** for every metric, from the ops review to the board room - **Exact formulas**, one calculation per metric, written in a machine-readable grammar. Each compiles to SQL in four dialects (Postgres, Snowflake, BigQuery and Databricks) and ships as Apache Ossie files. Breakdowns such as by segment or by plan are declared on the metric itself - **Industry benchmarks** for context - **Relationships** between metrics, showing how they move together - **The [metrics index](https://koinedata.com/v1/metrics)**, every metric by department with the Core Metrics as the view of business health The standard is opinionated on purpose and expects you to adopt the definitions as written. --- ## From Ops Dashboard to Board Deck Most SaaS metrics frameworks are written for operators or for investors. The GASP Standard serves both through its dual-lens framework: key metrics have two forms, Operating (O) and Market (M), computed from the same underlying data through the [Commercial Event Ledger](https://koinedata.com/v1/cel) and [Attribution Taxonomy Layer](https://koinedata.com/v1/atl). - **O-form** metrics reflect the internal economics, the numbers ops teams run the business on - **M-form** metrics follow investor-comparable definitions, the numbers boards and investors benchmark against peers Both forms come from the same events, so nobody has to keep a spreadsheet reconciling the ops number with the board number. --- ## Scope **This standard covers:** SaaS sold by subscription, by consumption or by both. It defines the building blocks every SaaS business shares. Consumption pricing with or without a contracted commitment is covered through the CEL's [Credit_Event](https://koinedata.com/v1/cel#credit_event) class. MRR and ARR still exclude usage fees that are not contractually guaranteed, and usage above a contracted commitment counts as expansion (the ATL `usage_realisation` tag). Uncommitted usage is reported by [Consumption Revenue](https://koinedata.com/v1/metrics/finance#consumption-revenue) and [Usage Run-Rate](https://koinedata.com/v1/metrics/finance#usage-run-rate). **This standard does not cover:** - **Implementation edge cases**: downstream concerns for individual businesses - **Industry-specific variations**: vertical SaaS may have additional metrics The aim is a foundation any SaaS business can adopt. Daily is the atomic unit, with weekly, monthly and annual views derived from it. --- ## Principles 1. **Consensus over custom.** These definitions reflect industry standard practice. Your business is not special enough to need different definitions. Where you must deviate, keep the canonical formula as it is and document your variant beside it, using the adapter's field `transform` and `notes` to record how your data differs, so the two can be reconciled. 2. **Precision over flexibility.** Each metric has one canonical formula, never "it depends." Where a metric has Operating and Market forms, the standard declares both beside the canonical formula. 3. **Outcomes over activity.** We pick metrics for what they say about the business rather than for how easy they are to track. 4. **Connection over isolation.** Metrics move together. The standard records how each one feeds the others, since a single number makes most sense read next to the metrics that move it. --- ## 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://koinedata.com/v1/definitions) | Canonical definitions for all terms, the source of truth | | [Relationships](https://koinedata.com/v1/relationships) | How metrics connect and influence each other | | [Commercial Event Ledger (CEL)](https://koinedata.com/v1/cel) | The atomic event layer behind the revenue, retention and cost metrics | | [Attribution Taxonomy Layer (ATL)](https://koinedata.com/v1/atl) | The event tags that separate the Operating and Market forms | | [Signal Type Taxonomy](taxonomy.json) | The four signal types (outcome, leading, efficiency and operational) and each metric's classification | | [Formulas](formulas.json) | The canonical formula for every metric in the GASP formula grammar, with forms, variants and breakdowns | | [Ontology](ontology.json) | Entities, concepts, datasets and canonical fields, with temporal semantics, access-control recommendations and validation rules | --- ## Departments Covered | Department | File | Focus | |------------|------|-------| | **Core** | [core.md](https://koinedata.com/v1/metrics/core) | MRR, ARR, NRR, CAC, LTV: the fundamentals | | **Sales** | [sales.md](https://koinedata.com/v1/metrics/sales) | Pipeline, win rate, quota, deal velocity | | **Marketing** | [marketing.md](https://koinedata.com/v1/metrics/marketing) | Funnel, MQLs, CAC, demand generation | | **Customer Success** | [customer-success.md](https://koinedata.com/v1/metrics/customer-success) | Health scores, retention, expansion | | **Support** | [support.md](https://koinedata.com/v1/metrics/support) | Tickets, CSAT, resolution, efficiency | | **Onboarding** | [onboarding.md](https://koinedata.com/v1/metrics/onboarding) | TTFV, completion, activation | | **Product** | [product.md](https://koinedata.com/v1/metrics/product) | Usage, adoption, stickiness, delivery | | **Engineering** | [engineering.md](https://koinedata.com/v1/metrics/engineering) | Uptime, DORA metrics, incidents | | **Finance** | [finance.md](https://koinedata.com/v1/metrics/finance) | Margins, burn, cash, profitability | | **RevOps / Order to Cash** | [revops.md](https://koinedata.com/v1/metrics/revops) | Billing, collections, revenue recognition | | **People (HR)** | [people.md](https://koinedata.com/v1/metrics/people) | Turnover, eNPS, hiring, engagement | | **Partnerships** | [partnerships.md](https://koinedata.com/v1/metrics/partnerships) | Channel revenue, partner performance | | **Professional Services** | [professional-services.md](https://koinedata.com/v1/metrics/professional-services) | Utilization, project delivery, margins | --- ## Signal Types Every metric carries one primary signal type of four: outcome, leading, efficiency or operational. [taxonomy.json](taxonomy.json) defines each type and classifies every metric; the site renders it at [koinedata.com/v1/taxonomy](https://koinedata.com/v1/taxonomy). --- ## Hierarchy ``` ┌─────────────────┐ │ Core Metrics │ │ business health │ └────────┬────────┘ │ ┌────────────────────┼────────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌───────────┐ ┌───────────┐ │ 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.** They are 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 the canonical formulas as defined.** If your business needs a local variant, keep the canonical formula unchanged, document the variant beside it and record how your data differs in the adapter's field `transform` and `notes`. 4. **Start from the [metrics index](https://koinedata.com/v1/metrics).** The [Core Metrics](https://koinedata.com/v1/metrics/core) give the standard view of business health. 5. **Investigate with Departmental Metrics.** When a core number is off, drill into the department behind it. --- # 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://koinedata.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 Churn Rate, LTV, ARPA, 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, Churned MRR, Revenue Churn Rate - **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:** License Utilization, Feature Adoption Rate, Core Feature Adoption - **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://koinedata.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://koinedata.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://koinedata.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://koinedata.com/v1/metrics/core#expansion-mrr) - **Used in:** Core, Customer Success ### Churned MRR MRR lost from customers who cancelled. - **Canonical definition:** [Core Metrics](https://koinedata.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://koinedata.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://koinedata.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 + Reactivation MRR - Churned MRR - Contraction MRR - **Canonical definition:** [Core Metrics](https://koinedata.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://koinedata.com/v1/metrics/finance#revenue-gaap) - **Used in:** Finance, RevOps ### Bookings Total contract value signed in a period. - **Canonical definition:** [Finance Metrics](https://koinedata.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://koinedata.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://koinedata.com/v1/metrics/core#arpa-average-revenue-per-account) - **Used in:** Core (LTV, CAC Payback), Finance ### Consumption Revenue Revenue earned as customers use the product: consumption drawn from a prepaid balance, billed as overage above a commitment or billed on demand with no commitment. - **Canonical definition:** [Finance Metrics](https://koinedata.com/v1/metrics/finance#consumption-revenue) - **Used in:** Finance ### Usage Run-Rate (Usage ARR) On-demand consumption revenue over the trailing three months, annualised. Added to ARR it gives ARR Including Usage Run-Rate without counting any usage twice. - **Canonical definition:** [Finance Metrics](https://koinedata.com/v1/metrics/finance#usage-run-rate) - **Used in:** Finance ### Prepaid Credit Balance (Remaining Commitment) The prepaid commitment customers have paid for and not yet consumed or forfeited: the part of the deferred revenue balance that is prepaid consumption. - **Canonical definition:** [Finance Metrics](https://koinedata.com/v1/metrics/finance#prepaid-credit-balance) - **Used in:** Finance ### Credit Breakage The prepaid balance forfeited at expiry in a period. The commercial fact behind breakage revenue, which the accounting standards recognise on their own timing. - **Canonical definition:** [Finance Metrics](https://koinedata.com/v1/metrics/finance#credit-breakage) - **Used in:** 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://koinedata.com/v1/metrics/core#net-revenue-retention-nrr) - **Used in:** Core, Customer Success - **Adjusted variant:** Filter CEL events by [`change_nature`](https://koinedata.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://koinedata.com/v1/metrics/core#gross-revenue-retention-grr) - **Adjusted variant:** Filter CEL events by [`change_nature`](https://koinedata.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://koinedata.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://koinedata.com/v1/metrics/core#revenue-churn-rate) - **Used in:** Core ### Renewal Rate Percentage of contracts renewed at term. - **Canonical definition:** [Customer Success Metrics](https://koinedata.com/v1/metrics/customer-success#renewal-rate) - **Used in:** Customer Success, RevOps ### Consumption Net Revenue Retention The consumption revenue of the customers active at period start over twelve months, divided by the same customers' consumption revenue over the twelve months before. A second basis beside NRR, reported as Consumption NRR rather than as NRR. - **Canonical definition:** [Finance Metrics](https://koinedata.com/v1/metrics/finance#consumption-net-revenue-retention) - **Used in:** Finance --- ## Efficiency Terms ### CAC (Customer Acquisition Cost) Total cost to acquire a new customer. - **Canonical definition:** [Core Metrics](https://koinedata.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://koinedata.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://koinedata.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://koinedata.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://koinedata.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://koinedata.com/v1/metrics/core#gross-margin) - **Used in:** Core, Finance ### Rule of 40 ARR Growth Rate (YoY %) + EBITDA Margin (%). - **Canonical definition:** [Core Metrics](https://koinedata.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://koinedata.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://koinedata.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) ### Trial An account evaluating the product for free for a set period before it decides to pay. - **Outcomes:** converted (became a customer), expired (the period ended), cancelled (closed early) - **Not:** A customer, until it converts; a proof of concept run by sales, which is an opportunity stage - **Canonical definition:** [Product Metrics](https://koinedata.com/v1/metrics/product#trial-to-paid-conversion-rate) ### Active User A user who performed a qualifying action in the defined period. - **Canonical definition:** [Product Metrics](https://koinedata.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://koinedata.com/v1/metrics/marketing#leads) ### MQL (Marketing Qualified Lead) A lead meeting criteria indicating sales-readiness. - **Canonical definition:** [Marketing Metrics](https://koinedata.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://koinedata.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://koinedata.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://koinedata.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://koinedata.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://koinedata.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, compute, payment processing and third-party service costs (the ATL `infrastructure` cost function) - **SaaS COGS excludes:** Sales, marketing, R&D, G&A - **Support and success cost:** Outside COGS in Gross Margin. Contribution margin, the Operating form of Gross Margin (GM-O), subtracts it ### 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://koinedata.com/v1/metrics/finance#cash-burn-rate) ### Runway Months until cash runs out at current burn rate. - **Canonical definition:** [Finance Metrics](https://koinedata.com/v1/metrics/finance#cash-runway) ### DSO (Days Sales Outstanding) Average days to collect payment after invoicing. - **Canonical definition:** [RevOps Metrics](https://koinedata.com/v1/metrics/revops#days-sales-outstanding-dso) - **Used in:** RevOps, Finance (same definition) ### Bad Debt Rate Percentage of revenue written off as uncollectable. - **Canonical definition:** [Finance Metrics](https://koinedata.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://koinedata.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://koinedata.com/v1/metrics/engineering#mean-time-to-resolve-mttr) - **Note:** DORA uses "Mean Time to Recovery" for the same concept ### Error Rate Percentage of requests resulting in errors. - **Canonical definition:** [Engineering Metrics](https://koinedata.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://koinedata.com/v1/metrics/sales#pipeline-value) ### Pipeline Coverage Ratio of unweighted pipeline value to quota. - **Canonical definition:** [Sales Metrics](https://koinedata.com/v1/metrics/sales#pipeline-coverage-ratio) ### Win Rate Percentage of opportunities closed as won. - **Canonical definition:** [Sales Metrics](https://koinedata.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://koinedata.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://koinedata.com/v1/metrics/product) ### Stickiness DAU/MAU ratio: how often users return. - **Canonical definition:** [Product Metrics](https://koinedata.com/v1/metrics/product#daumau-ratio-stickiness) ### Feature Adoption Percentage of users using a specific feature. - **Canonical definition:** [Product Metrics](https://koinedata.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://koinedata.com/v1/metrics/product#activation-rate) --- ## Time-Based Metrics ### TTFV (Time to First Value) Time from contract start to achieving first meaningful value. - **Canonical definition:** [Onboarding Metrics](https://koinedata.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://koinedata.com/v1/metrics/support#first-response-time-frt) ### Resolution Time Time from request to final resolution. - **Canonical definition:** [Support Metrics](https://koinedata.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://koinedata.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 **Prefer percentiles to averages** for latency and time metrics, because outliers skew averages. MTTR keeps the mean its name declares. --- ## 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 and how the twin is assembled. They sit apart 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 the GASP revenue, retention and cost metrics derive. If a commercial event is not in the CEL, it does not exist for metric purposes. Operational metrics read the other datasets in the ontology. - **Canonical definition:** [CEL](https://koinedata.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 tags let each dual-lens metric compute its Operating form and its Market form from the same events. - **Canonical definition:** [ATL](https://koinedata.com/v1/atl#attribution-taxonomy-layer-atl) - **Used in:** Core metrics with dual-lens forms (ARR, NRR, CAC, LTV, LTV:CAC, CAC Payback, Gross Margin, Churn) ### Adapter The JSON mapping file that connects GASP's canonical vocabulary to your warehouse: a table for each GASP dataset you have, a column (`schema.table.column`) for each field and optional owners for field data and metric definitions. The adapter is the only file a consuming organization writes. - **Reference:** [Adapter Guide](https://koinedata.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 query the twin instead of the source systems. - **Reference:** [SaaS Digital Twin](https://koinedata.com/v1/digital-twin) ### Ontology The structured representation of GASP's entities, concepts, fields, datasets, 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://koinedata.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://koinedata.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://koinedata.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://koinedata.com/v1/cel#change-nature) ### Segment The customer classification by size, vertical or fit (SMB, Mid-Market, Enterprise or the organisation's own scheme), recorded in the `segment` field. Revenue, contract and amendment events carry the segment as of the event; the customer and subscription snapshots carry it as of the snapshot. Segment is a dimension for slicing metrics rather than an ATL tag. Pricing tier lives on the plan. - **Canonical definition:** [CEL segment](https://koinedata.com/v1/cel#segment-on-events) - **Used in:** Named `by_segment` breakdowns of MRR, ARR, NRR, GRR, the churn and movement metrics, ARPA and Health Score ### Structured Formula A decomposed representation of a metric's canonical formula, derived from formulas.json: 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. The adapter schema recommends an owner for every metric you report and the validator lists metrics without one. 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 any deviation. - **Reference:** [Adapter Guide](https://koinedata.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 metrics describe the health of a SaaS business. Every SaaS business should track them. **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 Usage with no commitment behind it is reported as [Consumption Revenue](https://koinedata.com/v1/metrics/finance#consumption-revenue). **Inputs:** - Active customer list - Subscription/contract value for each customer - Contract term (monthly/annual) MRR is reported per plan (by plan id and plan name) and per customer segment. **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. **Industry equivalents:** Committed ARR, CARR (Committed Annual Recurring Revenue), Baseline ARR and CMRR (Committed Monthly Recurring Revenue, annualised). GASP's ARR includes contractual commitments and leaves uncommitted usage out, which is what each of these names describes. Consumption companies that report usage inside ARR are reporting [ARR Including Usage Run-Rate](https://koinedata.com/v1/metrics/finance#arr-including-usage-run-rate), which the GASP Standard names separately. ARR is reported per customer segment. **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 − TTM_Pricing_Adjustment_MRR − TTM_Recontracting_MRR) × 12 ``` Where TTM_Pricing_Adjustment_MRR and TTM_Recontracting_MRR are the MRR changes tagged with `expansion_classification` `pricing_adjustment` or `recontracting` in the trailing 12 months, counted for customers active at period end. MRR is the period-end MRR used by ARR-M. ARR-O is therefore a trailing twelve month measure. Stripping price rises out of ARR is a GASP construct rather than an industry convention; where price and volume are separated elsewhere, it is a growth decomposition over the period. **What it tells you:** The run rate of revenue that customers created by adopting and expanding, with price rises and recontracting taken out. It is the part of ARR most likely to last. #### 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 + TTM_Pricing_Adjustment_MRR × 12 + TTM_Recontracting_MRR × 12 ``` **Diagnostic:** The delta (ARR-M − ARR-O) is the **Durability Gap.** Because ARR-O subtracts only the trailing 12 months of tagged MRR change for customers active at period end, the Durability Gap is a trailing-year growth decomposition: it shows how much of reported ARR growth came from pricing and contract changes rather than organic customer expansion. A growing gap means ARR growth that may not last. KeyBanc tracks it implicitly in its annual SaaS survey. Public SaaS companies report total ARR (ARR-M), while internal planning teams strip out pricing actions to see the growth the product earned. --- ### ARPA (Average Revenue Per Account) **Definition:** Average monthly recurring revenue per customer. **Formula:** ``` ARPA = MRR / Active Customers ``` ARPA is reported per customer segment. **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 New MRR is reported per customer segment. **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 Expansion MRR is reported per customer segment. **What it tells you:** How much revenue you grow from customers you already have, which usually costs far less than winning new ones. **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) ``` Churned MRR is reported per customer segment. **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 Contraction MRR is reported per customer segment. **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) --- ### Reactivation MRR **Definition:** MRR regained from customers who had churned and signed up again in the period. **Formula:** ``` Reactivation MRR = Sum of (first month MRR from previously churned customers who returned this period) ``` **Also known as:** Resurrected MRR, Win-back MRR, Reactivated MRR A reactivation is the `reactivation` event in the [Commercial Event Ledger](../cel.md): the customer's status was `churned` and a new subscription starts. It is counted apart from New MRR, so win-back and acquisition can be judged on their own, and apart from Expansion MRR, which only existing customers generate. Reactivation MRR is reported per customer segment. **What it tells you:** How much lost revenue comes back. A rising share of net new MRR from reactivation usually means churn was recoverable (billing failures, seasonal pauses) rather than lost for good. **Dual-lens note:** Net Revenue Retention (NRR) in its Market form counts reactivation of customers who were in the period-start cohort; the Operating form leaves it out, as [NRR](#net-revenue-retention-nrr) sets out. **Sources:** [ChartMogul](https://chartmogul.com/blog/mrr-movements/), [Baremetrics](https://baremetrics.com/academy/saas-calculate-mrr) --- ### Carry MRR **Definition:** The part of beginning MRR that existing customers kept paying in the period: beginning MRR less churned and contraction MRR, before any expansion. **Formula:** ``` Carry MRR = Beginning MRR - Churned MRR - Contraction MRR ``` **Also known as:** Base MRR, Retained MRR, Renewal MRR **What it tells you:** How much of last period's revenue base is still in place. Carry MRR is Gross Revenue Retention (GRR) in dollar terms: divide it by beginning MRR and you get GRR. **Key insight:** 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 + Reactivation MRR - Churned MRR - Contraction MRR ``` **Example:** $50,000 starting + $2,500 new + $5,000 expansion + $300 reactivation - $1,000 churned - $500 contraction = $56,300 ending Ending MRR = Carry MRR + New MRR + Expansion MRR + Reactivation MRR, so the five movements and Carry MRR always reconcile to the period-end MRR. **What it tells you:** Whether MRR grew or shrank over the period and by how much, after every movement is counted. **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) --- ## Customer Count Metrics The three counts behind every per-customer ratio. ARPA divides by Total Customers, CAC by New Customers and Logo Churn Rate by Total Customers at the start of the period, so the counts are metrics in their own right. They reconcile the way the MRR movements do: Total Customers at period end = Total Customers at period start + New Customers - Churned Customers, plus any reactivated customers, who return to the active count. ### Total Customers **Definition:** The number of active customers at the end of the period. **Formula:** ``` Total Customers = Count of customers with customer_status = active at period end ``` **Also known as:** Customer Count, Active Customers, Logos **Counting:** One customer is one billing entity, whatever its number of users, seats or subscriptions (see [Customer](../definitions.md#customer)). Trial and free accounts are not customers until they pay. Total Customers is reported per customer segment. **What it tells you:** The size of the base. Watch it beside MRR, since a base growing faster than MRR means ARPA is falling. --- ### New Customers **Definition:** The number of customers acquired in the period: customers whose first paid subscription started in the period. **Formula:** ``` New Customers = Count of customers with a new revenue event in the period ``` **Also known as:** New Logos, Logo Acquisitions, Gross Adds **Not:** Reactivated customers, who return through a `reactivation` event and are counted in Reactivation MRR; expansion of an existing customer, however large. New Customers is reported per customer segment. **What it tells you:** The output of the acquisition engine in logos rather than dollars. New Customers x ACV equals New MRR x 12, so when the two trends part, deal size has moved. --- ### Churned Customers **Definition:** The number of customers lost in the period: customers whose last active subscription ended. **Formula:** ``` Churned Customers = Count of customers with a churn event in the period ``` **Also known as:** Lost Logos, Logo Churn (count) **Not:** Customers who downgraded but kept at least one active subscription (contraction). Churned Customers is reported per customer segment. **What it tells you:** The numerator of [Logo Churn Rate](#logo-churn-rate-customer-churn). Logo churn concentrated in one segment shows here before it moves the blended rate. --- ## 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** because it keeps customers acquired during the period out by construction. The GASP Standard gets the same protection by running the formula method over the customers active at period start. **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:** The GASP Standard measures NRR over the **trailing 12 months**, which smooths seasonality and is the basis boards and investors expect. **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 NRR is reported per customer segment, each snapshot and event counting in the segment it carries. **Usage and consumption:** NRR already includes realised usage: overage above a commitment is expansion tagged `usage_realisation`, and for a customer on a prepaid commitment the commitment sits in the MRR base. Pay-as-you-go customers have no MRR and sit outside the cohort, as Snowflake keeps its on-demand customers outside its NRR. The retention of consumption revenue itself is [Consumption Net Revenue Retention](https://koinedata.com/v1/metrics/finance#consumption-net-revenue-retention), a separate basis reported under its own name. **What it tells you:** Whether the customers you had a year ago are paying you more or less today. Above 100%, the existing base grows on its own and new customers add on top; below it, new sales first have to replace what the base lost. **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 on the same product and usage realisation. It excludes expansion from new modules, new buying centres, reactivation, recontracting 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:** Whether customers expand because the product gives them more value, with cross-sell, reactivation and pricing taken out. It is the closest NRR gets to a product-market fit signal. #### Market Form: Account NRR (NRR-M) NRR-M uses the cohort method over the customers active at period start, the same construction public SaaS companies report and investors benchmark (Bessemer, KeyBanc). It includes all six `expansion_classification` values plus reactivation of cohort customers. A customer who churned before the window and returns inside it is new business, not retention. A customer who churns and returns inside the window is in the cohort, so that reactivation counts. **CEL Source:** `Revenue_Event` **ATL Inclusion:** - All `expansion_classification` values included (`same_product`, `new_module`, `new_buying_centre`, `pricing_adjustment`, `recontracting`, `usage_realisation`) - `event_type` = `reactivation` included for customers in the period-start cohort - Excluded: `lifecycle_attribution` = `acquisition`; reactivation of customers who had already churned before period start (new business) **Formula:** ``` NRR-M = MRR of cohort today (all expansion types and cohort reactivation) / MRR of same cohort 12 months ago × 100 ``` Equivalently, as the formula method over the same cohort: ``` NRR-M = (Beginning MRR + All Expansion MRR + Cohort Reactivation 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.** It shows how much of reported NRR comes from commercial motion (cross-sell, reactivation, pricing) rather than organic product expansion. A wide gap means NRR depends on sales execution more than product-led growth. That can be a sound strategy. The board should still know which one drives retention. SaaS Metrics Standards Board recommends the cohort method. Public SaaS companies report cohort-based NRR (NRR-M), so both forms use the cohort method and differ only in which expansion counts. --- ### 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 GASP Standard uses the **formula method** as canonical. Both run over the customers active at the start of the period. **1. Formula Method (Canonical):** ``` GRR = (Beginning MRR - Contraction MRR - Churned MRR) / Beginning MRR × 100 ``` **2. Cohort Method (Alternative):** 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 ``` **Why they differ:** The cohort method nets each customer's movements within the period, so a customer who contracts and then expands back to their starting MRR shows no loss. The formula method counts every contraction and churn event as it happens, so it is equal to or lower than the cohort method. The formula method is canonical because it reads the same contraction and churn events as Net Revenue Retention (NRR), keeping the two retention rates on one basis. It also needs no per-customer end-of-period snapshot. Report the cohort method as a labelled alternative. **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 GRR is reported per customer segment, each snapshot and event counting in the segment it carries. **Usage and consumption:** GRR runs on the same MRR base as NRR, so a prepaid commitment counts in it. Pay-as-you-go customers have no MRR and sit outside the cohort, as Snowflake keeps its on-demand customers outside its NRR. The consumption-revenue basis is [Consumption Net Revenue Retention](https://koinedata.com/v1/metrics/finance#consumption-net-revenue-retention). **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 and leaves expansion out. The Operating and Market forms of other metrics differ in which expansion classifications they count, so GRR has nothing to filter. One calculation serves internal planning and investor reporting. --- ### 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 Logo Churn Rate is reported per customer segment. **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. It is the canonical formula because it isolates the leakage. **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) Revenue Churn Rate is reported per customer segment. **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 economic damage of attrition, which is why it is the operating form. 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:** How many customers leave, counted the simple way investors benchmark, which is why it is the market form. **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) - Read the pattern by customer segment to see where retention work should go. --- ### 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. A falling NPS often shows churn risk before it reaches the revenue metrics, early enough to act. 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 hosting costs **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. **By cost centre:** CAC can also be reported per cost centre, over all new customers: each row divides that centre's acquisition spend by every new customer in the period, so the rows sum 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 is the full cost of turning a prospect into a customer who generates revenue. Implementation support during a trial or proof of concept is an activation cost: tag it `cost_function` = `implementation` and it counts in CAC-O and in the Activation Delta, outside the main CAC Include list. **CEL Source:** `Cost_Event` **ATL Inclusion:** `cost_function` ∈ (`gtm`, `implementation`, `onboarding`), the acquisition and activation lifecycle costs **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. It is the CAC to use in 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:** `cost_function` = `gtm` (all sales and marketing spend, the S&M basis investors use) **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 cost of making customers productive, which S&M-based benchmarks leave out. A large Activation Delta means investor-comparable CAC understates what acquisition really costs. Implementation complexity, onboarding duration and services intensity drive it. 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 gross 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 every variable cost, including implementation, onboarding, support and customer success. It is the profit a customer contributes over their 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.** Large leakage means the business model depends on services that erode unit economics. It points to services that could be productised or onboarding that could be self-serve. 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/) #### Operating Form: Contribution LTV:CAC (LTV:CAC-O) LTV:CAC-O divides Contribution LTV by Fully Loaded CAC. Both sides carry the cost of making a customer productive: the numerator loses the variable service costs over the lifetime and the denominator gains implementation and onboarding. **CEL Source:** `Revenue_Event`, `Cost_Event` **ATL Inclusion for costs:** LTV-O margin costs (`infrastructure`, `support`, `success_engineering`, `implementation`, `onboarding`); CAC-O costs (`gtm`, `implementation`, `onboarding`) **Formula:** ``` LTV:CAC-O = LTV-O / CAC-O ``` **What it tells you:** The return on acquisition spend after every variable cost of acquiring and serving a customer. The ratio to use for pricing, packaging and services investment decisions. #### Market Form: Gross Margin LTV:CAC (LTV:CAC-M) LTV:CAC-M divides Gross Margin LTV by GTM CAC. This is the ratio investors benchmark and the form the 3:1 threshold above assumes. **CEL Source:** `Revenue_Event`, `Cost_Event` **ATL Inclusion for costs:** LTV-M margin costs (`infrastructure` only); CAC-M costs (`gtm` only) **Formula:** ``` LTV:CAC-M = LTV-M / CAC-M ``` **What it tells you:** The investor-comparable unit economics ratio reported to the board and in fundraising materials. #### Bridge: LTV:CAC-O ↔ LTV:CAC-M **Reconciliation:** ``` LTV:CAC-O = LTV:CAC-M × (LTV-O / LTV-M) × (CAC-M / CAC-O) ``` The two factors are the Contribution Leakage on the LTV side and the Activation Delta on the CAC side. **Diagnostic:** The gap between LTV:CAC-M and LTV:CAC-O shows how much of the headline ratio depends on human delivery costs that S&M-based benchmarks leave out. A business at 3:1 on the market form and well under 2:1 on the operating form is buying growth with services effort. Report LTV:CAC-M for comparability and manage to LTV:CAC-O. --- ### 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 many months of gross profit a new customer takes to repay what it cost to win. Payback sets how much cash growth ties up, so it limits how fast a company can grow on its own money. **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/) #### Operating Form: Fully Loaded CAC Payback (CAC Payback-O) CAC Payback-O recovers Fully Loaded CAC from contribution margin. Implementation and onboarding cost raise the amount to recover and variable service costs lower the monthly margin that recovers it. **CEL Source:** `Revenue_Event`, `Cost_Event` **ATL Inclusion for costs:** CAC-O costs (`gtm`, `implementation`, `onboarding`); GM-O costs (`infrastructure`, `support`, `success_engineering`, `implementation`, `onboarding`) **Formula:** ``` CAC Payback-O = CAC-O / (ARPA × GM-O) ``` **What it tells you:** How long a customer really takes to pay back everything spent to win and activate it. The number for cash planning. #### Market Form: GTM CAC Payback (CAC Payback-M) CAC Payback-M recovers GTM CAC from SaaS gross margin. It matches the payback period Benchmarkit and KeyBanc report and the benchmarks above. **CEL Source:** `Revenue_Event`, `Cost_Event` **ATL Inclusion for costs:** CAC-M costs (`gtm` only); GM-M costs (`infrastructure` only) **Formula:** ``` CAC Payback-M = CAC-M / (ARPA × GM-M) ``` **What it tells you:** The investor-comparable payback period used in benchmarks and board reporting. #### Bridge: CAC Payback-O ↔ CAC Payback-M **Reconciliation:** ``` CAC Payback-O = CAC Payback-M × (CAC-O / CAC-M) × (GM-M / GM-O) ``` ARPA is the same in both forms, so the gap comes from the Activation Delta and the Services Drag alone. **Diagnostic:** A payback that looks healthy on the market form and runs months longer on the operating form means activation and service costs are tying up cash the S&M view does not show. The ratio CAC-O / CAC-M isolates the acquisition side; GM-M / GM-O isolates the delivery side. --- ### 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** (ATL `cost_function` = `infrastructure`): - Hosting/infrastructure costs (AWS, Azure, etc.) - DevOps team costs that keep the service running - Payment processing fees - Third-party software for product delivery - Capitalized software amortization **Exclude from COGS:** - Customer Support and Customer Success teams (`cost_function` = `support`, `success_engineering`). These are subtracted in the Operating Form below, not in COGS. - Implementation and onboarding (`cost_function` = `implementation`, `onboarding`). Also Operating Form. - Sales & Marketing expenses (`gtm`) - 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 teams include all costs: wages, bonuses, payroll taxes, benefits, travel, training, internal tools. The canonical Gross Margin is the Market Form (GM-M) below. Companies that allocate Support and CS to COGS in their financial statements should report that figure as GM-O (contribution margin), which is where those costs belong in GASP. **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 every variable cost of serving customers. It shows what each customer earns after the costs that grow 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:** How much profit each customer generates after every variable delivery cost, which is why it is the operating form. #### 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 canonical Gross Margin above equals GM-M. GM-O subtracts the human delivery costs (Support, CS, Implementation, Onboarding) that some companies allocate to COGS in their statements; GASP keeps them out of COGS so the two forms reconcile exactly through the bridge below. #### 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 customer operation that depends on people. A delta that declines over time points to more 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 shows whether the balance of growth and profitability holds once delivery costs are counted. 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 | | Net New MRR | Revenue | Net movement, five components | | Total Customers | Customer Count | Size of the base | | New Customers | Customer Count | Acquisition in logos | | 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 Core metrics serve two audiences. Operating forms are what management runs the business on and market forms match the benchmarks investors compare against. 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 open sales opportunities, weighted by stage probability unless stated as unweighted. **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 unweighted pipeline value to quota for the period. **Formula:** ``` Pipeline Coverage = Unweighted Pipeline Value / Quota for Period ``` Use the unweighted Pipeline Value (open opportunities at full deal value). The 1 / Win Rate rule below already applies the conversion, so a stage-weighted pipeline would count it twice. 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 open opportunities in pipeline 2. **Win Rate:** Conversion rate from opportunity to close 3. **Deal Size:** Average deal value 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:** Find the lever that is holding velocity back. Too few opportunities points to lead generation; deals stuck in negotiation point to 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 closed in the period that were won. **Formula:** ``` Win Rate = Deals Won / (Deals Won + Deals Lost) × 100 ``` Win Rate is reported per acquisition channel. 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:** Track your own win rate over time. Benchmarks are a rough guide to where you sit. **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:** The GASP Standard computes it as Win Rate. The two names describe the same measure, taken from the qualified 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. Aggregated, it is the average ACV of new contracts signed in the period. **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 deals won in the period (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 deals won in the period ``` Measured in days. Report the median of the same deals beside the average, since a few long deals skew the mean. **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:** New revenue closed in the period divided by the 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 count sales inputs. Use them to diagnose a pipeline or conversion problem and keep them out of headline 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 = Sum of unique visitors in period across traffic sources ``` Web analytics report unique visitors per traffic source, so the GASP Standard sums the per-source counts. A visitor who arrives through two sources counts once in each. Load one figure per source per reporting period so a returning visitor counts once within a source. **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 ``` Leads are reported per lead source (such as organic, paid, referral, direct and events) and per lead stage as of period end. --- ### 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 ``` MQLs are reported per lead source. **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 ``` Lead-to-MQL Rate is reported per lead source. **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 ``` MQL-to-SQL Rate is reported per lead source. **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 (MQLs). **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 reports deals that already closed. LVR moves months earlier, because this month's qualified leads become the pipeline that closes later. **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://koinedata.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: go-to-market cost booked to the marketing cost centre, divided by all new customers in the period. **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 ad spend / Deals won in period via channel ``` **Channels:** Paid ads, organic search, email, events, content, referral, direct and other. CAC by Channel is reported per channel: one value for each channel. Spend is campaign ad spend, which records its channel. New customers are deals won in the period, attributed to their first-touch channel. The cost ledger has no channel, so ledger cost cannot be split this way; Marketing CAC remains the total. **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: closed won revenue from the paid ads channel in the period, divided by paid 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:** Net Revenue Retention (NRR) and Gross Revenue Retention (GRR) are defined in [Core Metrics](https://koinedata.com/v1/metrics/core). --- ## Retention Metrics ### Net Revenue Retention (NRR) See [Core Metrics](https://koinedata.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://koinedata.com/v1/metrics/core#gross-revenue-retention-grr) for full definition. GRR shows retention with expansion taken out. --- ### 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 ``` Logo Retention Rate is reported per customer segment. **What it tells you:** How many customer relationships you keep, whatever each one is worth. --- ## Health Metrics ### Customer Health Score **Definition:** A composite score predicting likelihood of retention or churn. **Formula:** ``` Health Score (per account) = Weighted average of health indicators, scaled 0 to 100 Health Score (portfolio) = Average health score of active customers at period end ``` The per-account composite is built upstream and lands on the customer record as one score from 0 to 100. The portfolio Health Score is the average of that score across active customers, reported for the whole base and per customer segment. **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. **Reference weighting (a starting point, not canon):** for a team building its first score. The weights are yours: replace them once you can test each signal against your own churn. | Signal group | Reference weight | What it covers | |--------------|------------------|----------------| | Usage | 35% | Frequency and depth of product use, including adoption of key features | | Engagement | 25% | Responsiveness to outreach, QBR attendance and an engaged executive sponsor | | Support | 20% | Ticket volume trend, escalations and support sentiment | | Commercial | 20% | Payment health, renewal status and expansion or contraction history | **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 active customers that have a health score. **Formula:** ``` Health Score Coverage = Customers with health score / Total customers × 100 ``` Health Score Coverage is reported per customer segment. **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 ``` At-Risk Customer Rate is reported per customer segment. **Variant `entered_at_risk`:** the share of customers active at period start that entered the `at_risk` state in the period. The move into `state_category = 'at_risk'` is a leading indicator of churn, which this variant counts as it happens. **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 = Accounts with a completed QBR / Accounts due a QBR × 100 ``` A QBR counts as completed when it is held in the period. Eligible accounts are those due a QBR in the period. **Target:** 90%+ for enterprise/strategic accounts **What it tells you:** Whether you are keeping up the regular reviews that strategic relationships run on. --- ### Executive Sponsor Coverage **Definition:** The percentage of active accounts with an engaged contact whose role is executive sponsor. **Formula:** ``` Exec Sponsor Coverage = Accounts with an engaged executive sponsor contact / Active accounts × 100 ``` **Population:** Contacts come from the contact dataset (one row per named person at an account, with a role and an engaged flag). An account counts once however many sponsors it has. Restrict to managed accounts by filtering the denominator. **What it tells you:** Whether you have a senior relationship at each account. Accounts with an engaged sponsor tend to hold up better at renewal. --- ### Contact Coverage **Definition:** Average number of engaged contacts per active account. **Formula:** ``` Contact Coverage = Engaged contacts / Active accounts ``` **Population:** Engaged contacts are rows of the contact dataset with the engaged flag set at period end (engaged means activity in the last 90 days, however the CRM defines activity). The denominator is active accounts, so an account with no contacts pulls the average down rather than disappearing from it. **Target:** 3+ contacts per account **What it tells you:** Whether accounts depend on a single contact. An account with several engaged contacts is less likely to churn when one person leaves. --- ## 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 Expansion Revenue Rate is reported per customer segment. **What it tells you:** How fast existing customers grow their spend. As companies mature, expansion becomes the largest source of growth. **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/) --- ### License Utilization **Definition:** The share of purchased seats that are assigned to a user, across active licenses at period end. **Formula:** ``` License Utilization = Seats assigned / Seats purchased × 100 ``` **Population:** Active licenses (the license dataset: one row per entitlement a subscription grants, with the product it covers, seats purchased and seats assigned). Reported for the whole base and per product (by product id and product name). **Target:** 70 to 90 percent. Below 70 percent the account is paying for seats it does not use and is a downgrade risk at renewal. Above 90 percent the account is close to needing more seats, which is an expansion signal. **What it tells you:** Whether customers are growing into what they bought. For seat-priced products it is the earliest hard signal of contraction or expansion. --- ### Upsell Rate **Definition:** The percentage of customers eligible for an upgrade at period start who upgraded in the period. **Formula:** ``` Upsell Rate = Customers who upgraded / Customers eligible for upgrade × 100 ``` **What it tells you:** How well you turn upgrade headroom into upgrades. --- ### Cross-sell Rate **Definition:** The percentage of customers active at period start who bought an additional product in the period. **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 subscriptions whose term ended in the period that renewed. **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 closely the forecast renewal value matched the value actually renewed, for contracts ending in the period. **Formula:** ``` Forecast Accuracy = 1 - |Forecasted renewals - Actual renewals| / Actual renewals ``` **Target:** >90% **What it tells you:** How far revenue planning can rely on the renewal forecast. --- ### Days to Renewal **Definition:** Average number of days until upcoming renewals. **What it tells you:** How soon the renewal workload arrives. A short average means renewals are bunched close together, which strains CSM capacity. --- ## 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 | | License Utilization | Growth | Seat usage, contraction and expansion signal | | 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 Annual Recurring Revenue (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 ``` Ticket Volume is reported per ticket type. Teams that staff by channel (email, chat, phone) add that split from their help desk. Questions answered without a ticket are counted by Self-Service Rate instead. **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 the customer base. A rising ratio usually points to product or onboarding issues. --- ### Ticket Backlog **Definition:** Number of tickets open or pending at the end of the period. **Formula:** ``` Backlog = Count of open tickets ``` **What it tells you:** Current support debt. It should hold steady or fall. --- ### Ticket Distribution by Type **Definition:** Breakdown of tickets by category. **Formula:** ``` Type share = Tickets of the type created in period / Ticket Volume ``` **Categories (typical):** - How-to / Usage questions - Bug reports - Feature requests - Billing inquiries - Account issues - Other (including outage or incident related) Ticket Distribution by Type is reported per ticket type: one share for each type, with the shares summing to 100%. **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) ``` Resolution Time is reported per ticket type. **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%. **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 ``` GASP uses a 5-point scale and counts the top two ratings (4 and 5) as positive. **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 the percentage of respondents scoring 5 or above on the same 1-7 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, so cutting friction does more for repeat business than raising 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/) --- ### Ticket Escalation Rate **Definition:** Percentage of tickets escalated to higher tier or engineering. **Formula:** ``` Ticket 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 resolved. **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. It should fall 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 ``` Self-service resolutions are deflections: help center or chatbot sessions that ended without a ticket. Raw help center views overstate the rate. **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 | | Ticket 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. Wyzowl's research puts the churn reduction from effective onboarding at up to 67%. Of the metrics below, Time to First Value (TTFV) and Onboarding-to-Active Rate (Activation Rate) track retention most closely. --- ## Time Metrics ### Time to First Value (TTFV) **Definition:** Time from contract start to the customer's first meaningful value milestone. **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, which feeds directly into 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 from onboarding start to onboarding completion, for onboardings completed in the period. **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 ``` Both counts come from the same period: onboardings completed in it over onboardings started in it. **Benchmarks:** - Below 70%: Low, investigate friction points - 70-85%: Average - 85-95%: Good - Above 95%: Excellent **What it tells you:** Onboarding program effectiveness. --- ### Onboarding Milestone Completion Rate **Definition:** Percentage of due onboarding milestones that customers reach. **Formula:** ``` Onboarding Milestone Completion Rate = Milestones reached / Milestones due × 100 ``` Count the milestones due in the period and how many of them were reached by period end. Track each milestone separately to identify drop-off points. **Typical milestones:** 1. Kickoff (`kickoff`) 2. First value (`first_value`) 3. Go-live (`go_live`) 4. Full adoption (`full_adoption`) These are the canonical `onboarding_milestone` values. Data import, configuration, integration and training usually fall between kickoff and go-live. Teams whose onboarding tool records them can track them as sub-steps. **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) ``` Each team sets its own weights, so the standard publishes no canonical formula for this score. **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 ``` A session counts as attended when at least one customer attendee is recorded. **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. Positive means 4 or 5 on a 5-point scale. **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 The score is an assessment against these components. The standard gives no weights, so it has no canonical formula. **What it tells you:** Whether implementations are configured to work in production. --- ## 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 ``` A customer counts as active once it has an activation date: the date it first met the product's usage threshold (its "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:** Whether onboarding turns into real 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 ``` Measured as a snapshot at the go-live milestone. **What it tells you:** Whether customers are set up to use the whole product. --- ## 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:** A core action, defined per product, that the user chose to take. Logging in on its own does not qualify. **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 users who signed up in the period that reached 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:** Whether new users reach the product's core value, the first step to keeping them. --- ### Trial-to-Paid Conversion Rate **Definition:** The percentage of trials that ended in the period and became paying customers. **Formula:** ``` Trial-to-Paid Conversion Rate = Trials converted / Trials ended (converted + expired + cancelled) × 100 ``` **Also known as:** Free-to-Paid Conversion Rate, Trial Conversion Rate **Cohort:** Trials are counted by the date they ended, not started, so every trial in the denominator has an outcome. A trial that converts before its end date ends on the day it converts. Counting by start date understates recent periods while trials are still running; report it as a variant and say so. **Scope:** Time-boxed free trials and freemium accounts that upgrade. A proof of concept run by sales is an opportunity stage, not a trial. **Benchmarks:** - Opt-in free trial (no card): 10-25% (per OpenView / Lenny's PLG benchmarks) - Opt-out trial (card required): 40-60% - Freemium to paid: 2-5% **What it tells you:** Whether the product sells itself once someone tries it. It is the first conversion metric of a product-led motion. Read it with [Activation Rate](#activation-rate), since trials that never activate rarely convert. --- ## Adoption Metrics ### Feature Adoption Rate **Definition:** Percentage of active users who used a specific feature in the period. **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 intensively users engage with features: average feature actions per user who used a feature in the period. **Formula:** ``` Feature Depth = Average feature actions per user per period ``` **What it tells you:** How heavily people use the features they have adopted, which breadth measures miss. --- ### Time to Feature Adoption **Definition:** Median time from signup to a user's first use of a specific feature, for users whose first use falls in the period. **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 = Distinct (account, feature) pairs used in period / Active accounts ``` Each account counts each feature it used once, so the result is the average number of distinct features per active account. **What it tells you:** How much of the product each account uses. --- ## 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. The canonical formula reports Day 30 for users who signed up in the period. **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. The canonical formula reports week 8 for the period's signup cohort. **Formula:** ``` Cohort Retention (Week N) = Active users in week N / Users in cohort × 100 ``` **What it tells you:** How retention evolves and whether it is improving for newer cohorts. --- ### Resurrection Rate **Definition:** Percentage of users dormant at period start who returned in the period. **Formula:** ``` Resurrection Rate = Reactivated users / Dormant users × 100 ``` **What it tells you:** How many lapsed users you win back. --- ## 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:** Share of bugs found in production rather than caught 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 | | Trial-to-Paid Conversion Rate | Adoption | Product-led conversion | | 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 research program behind the annual State of DevOps reports. 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 ``` GASP's canonical latency is P95, with P50 and P99 as variants. Report percentiles rather than averages, which 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 ``` Incident Count is reported per severity and per incident type (availability, performance, security and data). Categorize by severity: - SEV1/P1: Critical, full outage - SEV2/P2: Major, significant degradation - SEV3/P3: Minor, limited impact - SEV4/P4: Cosmetic, no customer impact **What it tells you:** System stability. Read the trend per severity, since one SEV1 outweighs a month of SEV4 noise. --- ### 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 detection (the alert firing) to a person acknowledging the incident. **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) ``` MTTR is reported per severity and per incident type, since resolution targets differ by severity. **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 are Deployment Frequency, Lead Time for Changes, Mean Time to Recovery and Change Failure Rate (listed under Incident Metrics above). DORA added a fifth, Rework Rate, in 2024. GASP does not define it. **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 ``` Headroom is the complement of Infrastructure Utilization (1 minus utilization). **Target:** Maintain 20-30% headroom for traffic spikes. --- ## Security Metrics ### Vulnerability Count **Definition:** Number of known vulnerabilities still open in your 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 a vulnerability being discovered to its patch being deployed, for patches deployed in the period. **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 ``` Billings are reported per payment status (paid, unpaid, partial, written off) as of period end. **What it tells you:** The cash the period's invoices should bring in. The payment status breakdown shows how much of it has arrived. --- ### ARR / MRR See [Core Metrics: MRR](https://koinedata.com/v1/metrics/core#mrr-monthly-recurring-revenue) and [ARR](https://koinedata.com/v1/metrics/core#arr-annual-recurring-revenue) for full definitions. --- ### Deferred Revenue See [RevOps](https://koinedata.com/v1/metrics/revops#deferred-revenue-balance) for the canonical definition. Deferred revenue is a balance: cumulative billings to date minus cumulative revenue recognised to date. It arises on billing, not on cash receipt. --- ### Consumption Revenue **Definition:** Revenue earned as customers use the product: consumption drawn from a prepaid balance, billed as overage above a commitment or billed on demand with no commitment. **Formula:** ``` Consumption Revenue = Sum of consumption drawn, billed as overage or billed on demand in the period ``` Consumption Revenue reads the `consumption` events of the [Commercial Event Ledger (CEL)](../cel.md#credit_event) `Credit_Event` class. Those events carry a negative `credit_amount`, since they reduce what the customer has left to use, and the metric reports the positive amount. Consumption Revenue is reported per consumption basis (committed, overage, on demand) and per customer segment. **Includes:** - Consumption drawn from a prepaid balance (basis `committed`) - Consumption above an exhausted or per-period commitment (basis `overage`) - Consumption billed with no commitment (basis `on_demand`) **Excludes:** - Usage within a ratable commitment: that revenue is the commitment itself, already in MRR - Credit purchases: a prepayment is a contract liability until it is consumed, so it counts in bookings and billings - Expired credits, which [Credit Breakage](#credit-breakage) reports **What it tells you:** How much revenue usage earned in the period, whichever way the customer bought it. The breakdown by basis shows how much came from prepaid commitments, how much ran past them and how much arrived with no commitment at all. **Note:** Under ASC 606 and IFRS 15 a SaaS usage fee is variable consideration, recognised as the usage occurs. Consumption Revenue is the commercial figure read from the credit ledger; [Revenue (GAAP)](#revenue-gaap) remains the accounting figure. **Common mistakes:** - Counting credit purchases as consumption revenue - Adding consumption revenue to MRR, which excludes uncommitted usage - Counting usage within a ratable commitment a second time beside the commitment **Related metrics:** Usage Run-Rate, Prepaid Credit Balance, Credit Breakage, Consumption Revenue Growth Rate, Consumption Net Revenue Retention, Revenue (GAAP) **Sources:** - [FASB: ASU 2014-09, Topic 606](https://storage.fasb.org/ASU%202014-09_Section%20A.pdf) - [IFRS 15](https://www.icab.org.bd/icabadmin/uploads/ckeditor/7910IFRS%2015.pdf) - [Deloitte: Cloud arrangements with variable consideration](https://www.deloitte.com/content/dam/assets-zone3/us/en/docs/services/audit-assurance/2024/us-audit-tech-alert-accounting-for-cloud-basedor-hosted-software-arrangements-with-variable-consideration.pdf) - [Snowflake: Form 10-K, fiscal 2026](https://www.sec.gov/Archives/edgar/data/1640147/000164014726000008/snow-20260131.htm) - [Stripe: Billing credits](https://docs.stripe.com/billing/subscriptions/usage-based/billing-credits) - [Metronome: Glossary](https://metronome.com/glossary) --- ### Usage Run-Rate **Definition:** On-demand consumption revenue over the trailing three months, annualised. Also called Usage ARR. **Formula:** ``` Usage Run-Rate = On-demand Consumption Revenue in the three months ending at period end × 4 ``` **Window:** The GASP Standard fixes the window at three months × 4, the basis of MongoDB's 90 days and Confluent's three months. Companies also use one month × 12 (Datadog), which moves with every unusual month, and a six-month average × 12 (Metronome's guidance), which is slower to show a trend; daily × 365 appears too. The standard picks one window so two companies' figures compare. A company that reports on another window states it beside the GASP figure. **Base:** Only on-demand consumption enters. Committed consumption is already in ARR through the commitment, and overage is already in MRR through the `usage_realisation` expansion the [CEL](../cel.md#deriving-usage-realisation) derives. With the base held to on-demand consumption, ARR plus Usage Run-Rate counts each dollar once. **Includes:** Consumption with basis `on_demand`. **Excludes:** Committed consumption and overage, which ARR already carries. **What it tells you:** The annual scale of the usage that no contract guarantees. Set beside ARR it shows how much of the business runs on commitments and how much on customers who could stop tomorrow. **Note:** A run-rate, not a forecast. Datadog describes its usage-inclusive figures as "not intended to be replacements or forecasts of revenue". **Common mistakes:** - Annualising all consumption and adding it to ARR, which counts commitments and overage twice - Changing the window from one period to the next - Comparing two companies' usage figures without checking their windows **Related metrics:** ARR Including Usage Run-Rate, Consumption Revenue, ARR **Sources:** - [MongoDB: Form 10-K, fiscal 2026](https://www.sec.gov/Archives/edgar/data/1441816/000162828026016799/mdb-20260131.htm) - [Confluent: Form 10-K, 2025](https://www.sec.gov/Archives/edgar/data/1699838/000169983826000006/cflt-20251231.htm) - [Datadog: Form 10-K, 2025](https://www.sec.gov/Archives/edgar/data/1561550/000162828026008819/ddog-20251231.htm) - [Ordway: Cloud usage-based pricing ARR study](https://ordwaylabs.com/blog/cloud-usage-based-pricing-report-arr/) - [Metronome: ARR for usage-heavy SaaS](https://metronome.com/blog/arr-usage-heavy-saas) - [m3ter: SaaS usage metrics](https://www.m3ter.com/guides/saas-usage-metrics) --- ### Prepaid Credit Balance **Definition:** The prepaid commitment customers have paid for and not yet consumed or forfeited, as of period end. Also called Remaining Commitment. **Formula:** ``` Prepaid Credit Balance = Purchases + granting adjustments − committed consumption − expiries − reducing adjustments, cumulative to period end ``` Every `purchase`, `expiry` and `adjustment` event and every consumption with basis `committed` is summed from the start of the ledger to period end, each with the sign it carries. **Includes:** Prepaid commitments and blocks of credits, rollover grants and promotional grants, less what has been drawn down, forfeited or reduced. **Excludes:** Overage and on-demand consumption, which draw no balance. **What it tells you:** How much consumption customers have paid for in advance and not yet used: revenue still to be earned through use, or forfeited at expiry. **Note:** A prepayment is a contract liability when it is received and becomes revenue as the service is consumed (ASC 606-10-55-46, IFRS 15.B44). The Prepaid Credit Balance is the part of the [Deferred Revenue Balance](https://koinedata.com/v1/metrics/revops#deferred-revenue-balance) that is prepaid consumption. A balance that can roll over extends the obligation, so it is not yet breakage. The GASP Standard records the commercial fact and leaves the breakage method to the company's accounting policy. **Common mistakes:** - Drawing on-demand or overage consumption against the balance - Reading the balance as a revenue forecast: rollover and consumption timing move it, and Snowflake states its deferred revenue "is not a meaningful indicator of future revenue" - Letting the balance go negative: consumption beyond the balance is overage **Related metrics:** Consumption Revenue, Credit Breakage, Deferred Revenue Balance **Sources:** - [FASB: ASU 2014-09, Topic 606](https://storage.fasb.org/ASU%202014-09_Section%20A.pdf) - [IFRS 15](https://www.icab.org.bd/icabadmin/uploads/ckeditor/7910IFRS%2015.pdf) - [Stripe: Credit grant object](https://docs.stripe.com/api/billing/credit-grant/object) - [Stripe: Billing credits](https://docs.stripe.com/billing/subscriptions/usage-based/billing-credits) - [Orb: Credit ledger](https://docs.withorb.com/api-reference/credit/fetch-customer-credits-ledger) - [Metronome: Remaining balance](https://docs.metronome.com/guides/customers-billing/optimize-customer-experience/get-remaining-balance.md) - [Zuora: Prepaid balance transaction fields](https://docs.zuora.com/en/zuora-billing/bill-your-customer/usage-billing/prepaid-with-drawdown/query-the-prepaid-with-drawdown-objects-through-data-query/prepaid-balance-transaction-fields) - [Lago: Wallets and prepaid credits](https://doc.getlago.com/guide/wallet-and-prepaid-credits/overview) --- ### ARR Including Usage Run-Rate **Definition:** Annual Recurring Revenue (ARR) plus Usage Run-Rate: committed recurring revenue and annualised on-demand usage together. It is the figure Datadog, MongoDB and Confluent report as ARR. **Formula:** ``` ARR Including Usage Run-Rate = ARR + Usage Run-Rate ``` **No double counting:** ARR carries commitments and the overage realised above them; Usage Run-Rate carries on-demand consumption alone. Each dollar of usage sits in exactly one of the two. **Relation to ARR:** The GASP Standard keeps [ARR](https://koinedata.com/v1/metrics/core#arr-annual-recurring-revenue) committed, which is what the industry calls Committed ARR, CARR or Baseline ARR. Public consumption companies split between that policy and a usage-inclusive ARR, so the combined figure carries its own name and the two stay distinct. **What it tells you:** The annual scale of the business with usage included, on a basis comparable to the ARR consumption companies report. The gap to ARR is the share of scale that no contract guarantees. **Common mistakes:** - Reporting this figure as ARR - Adding a run-rate over all consumption, which counts commitments and overage twice **Related metrics:** ARR, Usage Run-Rate, Consumption Revenue **Sources:** - [Datadog: Form 10-K, 2025](https://www.sec.gov/Archives/edgar/data/1561550/000162828026008819/ddog-20251231.htm) - [MongoDB: Form 10-K, fiscal 2026](https://www.sec.gov/Archives/edgar/data/1441816/000162828026016799/mdb-20260131.htm) - [Confluent: Form 10-K, 2025](https://www.sec.gov/Archives/edgar/data/1699838/000169983826000006/cflt-20251231.htm) - [Ordway: ARR at public SaaS companies](https://ordwaylabs.com/resources/research/arr-public-saas-companies-research-study/) - [Stripe: Committed ARR explained](https://stripe.com/resources/more/committed-annual-recurring-revenue-explained) - [Bessemer: Cloud computing metrics](https://www.bvp.com/atlas/cloud-computing-metrics) --- ### Credit Breakage **Definition:** The prepaid balance forfeited at expiry in the period. **Formula:** ``` Credit Breakage = Sum of prepaid balances forfeited at expiry in the period ``` Expiry events carry a negative `credit_amount` and the metric reports the positive amount. **Excludes:** Balances that roll over into a new term. A rollover writes no expiry event; the new term's grant carries the new expiry date. **What it tells you:** How much prepaid consumption customers paid for and never used. A rising figure means commitments are sized above what customers consume, which tends to show up at renewal as a smaller commitment. **Note:** The event is the forfeiture, not the recognition. Breakage is codified in ASC 606-10-55-48 and IFRS 15.B46: a company that expects to be entitled to breakage recognises it in proportion to the pattern of consumption, and otherwise when the chance of the customer using the balance becomes remote. Recognising breakage only when it occurs is not a permitted policy, and amounts owed under unclaimed-property law are never revenue. Credit Breakage therefore differs in timing from breakage revenue. Credit-billing systems record expiry as a movement on the ledger; the public consumption filers do not disclose breakage. **Common mistakes:** - Treating Credit Breakage as the period's breakage revenue - Counting a rolled-over balance as forfeited **Related metrics:** Prepaid Credit Balance, Consumption Revenue **Sources:** - [FASB: ASU 2014-09, Topic 606](https://storage.fasb.org/ASU%202014-09_Section%20A.pdf) - [IFRS 15](https://www.icab.org.bd/icabadmin/uploads/ckeditor/7910IFRS%2015.pdf) - [PwC Viewpoint: Unexercised rights (RR 7.4)](https://viewpoint.pwc.com/dt/us/en/pwc/accounting_guides/revenue_from_contrac/revenue_from_contrac_US/chapter_7_options_to_US/74unexercised_rights_US.html) - [Stripe: Billing credits](https://docs.stripe.com/billing/subscriptions/usage-based/billing-credits) - [Orb: Prepurchase](https://docs.withorb.com/product-catalog/prepurchase) - [Zenskar: Credit breakage](https://www.zenskar.com/finance-glossary/credit-breakage) --- ### Consumption Revenue Growth Rate **Definition:** The month-over-month change in Consumption Revenue. **Formula:** ``` Consumption Revenue Growth Rate = (Consumption Revenue this month − Consumption Revenue last month) / Consumption Revenue last month × 100 ``` **What it tells you:** Whether usage is accelerating or slowing. It is the consumption counterpart of MRR Growth Rate and the figure consumption companies discuss on their earnings calls. **Note:** No benchmark publisher defines this metric; the GASP Standard defines it so consumption growth is measured one way. It is undefined for a month that follows one with no consumption revenue. **Common mistakes:** - Comparing periods of different lengths without adjusting - Counting credit purchases as growth **Related metrics:** Consumption Revenue, MRR Growth Rate, Consumption Net Revenue Retention **Sources:** - [Snowflake: Form 10-K, fiscal 2026](https://www.sec.gov/Archives/edgar/data/1640147/000164014726000008/snow-20260131.htm) - [MongoDB: Form 10-K, fiscal 2026](https://www.sec.gov/Archives/edgar/data/1441816/000162828026016799/mdb-20260131.htm) --- ### Consumption Net Revenue Retention **Definition:** The consumption revenue of the customers active at period start, over a twelve-month period, divided by the same customers' consumption revenue over the twelve months before. Consumption Net Revenue Retention (Consumption NRR) reads year two over year one, Snowflake's basis. **Formula:** ``` Consumption NRR = Consumption Revenue of the period-start cohort in the twelve-month period / Consumption Revenue of the same cohort in the prior twelve months × 100 ``` **Cohort:** The customers on the customer snapshot at period start. A customer in the cohort that consumed nothing in the period counts at zero; customers acquired during the period stay out. A pay-as-you-go customer enters the cohort once the company's customer status marks it active. **Two bases:** [Net Revenue Retention (NRR)](https://koinedata.com/v1/metrics/core#net-revenue-retention-nrr) reads MRR movements and already includes realised usage through the `usage_realisation` expansion, so it stays the main retention figure. Consumption NRR is a second basis, on recognised consumption: Snowflake reports on it, Twilio on recognised revenue, and Ordway finds public companies split between a revenue basis and an ARR basis. A company reporting this figure names it Consumption NRR rather than NRR. **What it tells you:** Whether the customers you had a year ago consume more or less today, including the pay-as-you-go customers whom NRR leaves outside its cohort. **Common mistakes:** - Reporting Consumption NRR as NRR - Including customers acquired during the period - Measuring over a period shorter than twelve months, where seasonal consumption distorts the ratio **Related metrics:** Net Revenue Retention (NRR), Consumption Revenue, Consumption Revenue Growth Rate **Sources:** - [Snowflake: Form 10-K, fiscal 2026](https://www.sec.gov/Archives/edgar/data/1640147/000164014726000008/snow-20260131.htm) - [Twilio: Form 10-K, 2025](https://www.sec.gov/Archives/edgar/data/1447669/000144766926000021/twlo-20251231.htm) - [Ordway: How public companies calculate NRR](https://ordwaylabs.com/resources/research/how-public-companies-calculate-net-revenue-retention.md) - [Ordway: NRR for usage-based pricing](https://ordwaylabs.com/blog/net-revenue-retention-for-usage-based-pricing/) - [SaaS Capital: Pitfalls in measuring churn](https://www.saas-capital.com/blog-posts/grrumbling-about-retention-metrics-or-pitfalls-in-measuring-saas-churn/) --- ### Revenue per Employee **Definition:** Annual Recurring Revenue (ARR) divided by total 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:** How much recurring revenue the company carries per person, a rough measure of overall productivity. --- ## Profitability Metrics ### Gross Margin See [Core Metrics](https://koinedata.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://koinedata.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://koinedata.com/v1/metrics/core#cac-payback-period) for full definition. --- ### LTV:CAC Ratio See [Core Metrics](https://koinedata.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 ``` Opex Ratio can also be reported per cost centre, over all revenue: each row divides that centre's operating expenses by total revenue, so the rows sum to the Opex Ratio. --- ### 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) See [RevOps](https://koinedata.com/v1/metrics/revops#days-sales-outstanding-dso) for the canonical definition: accounts receivable over revenue, times days in the period. --- ### Collection Rate **Definition:** Percentage of invoiced amounts collected. **Formula:** ``` Collection Rate = Amount of invoices paid / Amount invoiced × 100 ``` Both sides read the invoices issued in the period. An invoice counts as collected at its full amount once it carries a payment date. The GASP Standard has no payment amount field, so a partial payment counts as the whole invoice and cash received is measured at the invoice level. **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 | | Consumption Revenue | Revenue | Usage earned | | Usage Run-Rate | Revenue | Scale of uncommitted usage | | Prepaid Credit Balance | Revenue | Prepaid consumption not yet used | | ARR Including Usage Run-Rate | Revenue | Business scale with usage | | Credit Breakage | Revenue | Prepaid consumption forfeited | | Consumption Revenue Growth Rate | Revenue | Usage momentum | | Consumption Net Revenue Retention | Retention | Consumption growth in the existing base | | 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 across open opportunities. **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:** How far you can trust the pipeline data your forecast is built on. --- ### 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:** How predictable revenue is, which sets how much weight plans can put on the forecast. --- ### 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 sent 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:** Discount off list price across quotes sent in the period, weighted by list price. **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) ``` Measured in calendar days. A business-day count reads lower when the interval spans a weekend or holiday, so state which one you report. **Target:** <7 calendar days (about 5 business days) --- ### Billing Disputes **Definition:** Percentage of invoices disputed by customers. **Formula:** ``` Dispute Rate = Invoices disputed / Total invoices × 100 ``` Billing Disputes are reported per payment status as of period end. **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:** [Finance metrics](https://koinedata.com/v1/metrics/finance) links here. This is the canonical definition. --- ### Collection Effectiveness Index (CEI) **Definition:** The share of collectible receivables actually collected in the period. Billings stand in for credit sales. Current AR is receivables aged 30 days or less. **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 ``` Aging Buckets is reported per bucket: one share for each age bucket, each over the whole outstanding balance, so the shares sum to 100%. Age is the days from invoice date to the period end. Bounds are inclusive, so the 90+ bucket starts at 91 days. **Targets:** - Current: >80% - 31-60: <15% - 61-90: <4% - 90+: <1% --- ### Accounts Receivable Balance **Definition:** Total amount outstanding on open invoices at period end. **Formula:** ``` AR Balance = Sum of outstanding amounts on open invoices at period end ``` **Population:** The invoice snapshot at period end, invoices with an outstanding amount above zero. Accounts Receivable Balance is reported per payment status (unpaid, partial and so on) as of period end. **Note:** AR Balance should reconcile to `balance_sheet.accounts_receivable`, which DSO reads. Differences are unapplied cash or write-offs. **What it tells you:** How much billed cash is still to be collected. The payment status breakdown shows how much of it sits in partly paid or written-off invoices. --- ### Bad Debt Rate See [Finance](https://koinedata.com/v1/metrics/finance#bad-debt-rate) for the canonical definition: bad debt expense over GAAP revenue. --- ### Payment Method Distribution **Definition:** Breakdown of payments by method. **Formula:** ``` Method share = Invoiced amount in period paid by the method / Invoiced amount in period with a known method ``` **Methods:** - Credit card - ACH/Direct debit - Wire transfer - Check Payment Method Distribution is reported per method: one share for each method, with the shares summing to 100%. **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:** Revenue billed but not yet recognized. A balance of cumulative billings less cumulative recognized revenue, independent of when cash is received. **Formula:** ``` Deferred Revenue = Cumulative billings - Cumulative recognized revenue ``` **What it tells you:** Revenue already billed that the company still owes in service. The [Prepaid Credit Balance](https://koinedata.com/v1/metrics/finance#prepaid-credit-balance) is the part of the deferred revenue balance that is prepaid consumption. --- ### Unbilled Revenue **Definition:** Revenue recognized but not yet invoiced. **Formula:** ``` Unbilled Revenue = Recognized revenue - Billed revenue (where recognition > billing) ``` **What it tells you:** Service already delivered that billing has to catch up on. --- ### 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 | | AR Balance | Collections | Cash still to collect | | 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 active employees at the end of the period. **Formula:** ``` Headcount = Total active employees at end of period ``` Total Headcount is reported per department (the `by_department` breakdown). Share of headcount is each department's count over the total. Include: Full-time, part-time employees Exclude: Contractors (track separately) **Typical shares by department 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% | --- ### 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. --- ### Revenue per Employee See [Finance](https://koinedata.com/v1/metrics/finance#revenue-per-employee) for the canonical definition: ARR over total headcount. --- ## Retention Metrics ### Employee Turnover Rate **Definition:** Percentage of employees who left in a period. **Formula:** ``` Turnover Rate = Employees departed / Average headcount × 100 ``` Employee Turnover Rate is reported per department, with leavers and headcount counted within each department. 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 ``` Voluntary Turnover Rate is reported per department. **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, as a share of the high performers employed at the start of the period. **Formula:** ``` Regrettable Turnover = High performer departures / Total high performers × 100 ``` **Target:** <5% **What it tells you:** Whether you are losing your best people. --- ### Average Tenure **Definition:** Average length of employment. **Formula:** ``` Average Tenure = Sum of employee tenure / Total employees ``` Averaged over active employees at period end and reported in months. **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 ``` 90-Day Turnover is reported per hiring source. **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:** Usually an annual or quarterly survey covering: - Job satisfaction - Manager relationship - Growth opportunities - Company direction - Work-life balance The canonical value is the average composite score across employee survey responses in the period. **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 open requisitions (unfilled roles) at the end of the period. **What it tells you:** Hiring backlog and growth plans. --- ### Time to Fill **Definition:** Days from a requisition opening to it being filled with an accepted offer, for requisitions filled in the period. **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 the hired employee's application to their start date, for employees hired in the period. **Formula:** ``` Time to Hire = Average of (Start 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 ``` Some teams report the share of new hires meeting or exceeding expectations instead. That version needs a rating threshold, which each team sets. **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. **Formula:** ``` Source share = Hires in period from the source / Total hires in period ``` **Channels:** - Employee referrals - Inbound applications (job boards and career page) - Direct sourcing (LinkedIn and similar) - Agencies - Internal transfers - Campus hiring Source of Hire is reported per source: one share for each source, with the shares summing to 100%. **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) ``` GASP compares employees from underrepresented groups (Group A) with everyone else (Group B), within the same role. **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. A partner's status moves to active when it meets one of these, so the count reads the partner status flag. **What it tells you:** Size of the active partner ecosystem. --- ### Partner Tier Distribution **Definition:** Breakdown of partners by program tier. **Tiers (typical):** - Registered / Affiliate - Silver / Select - Gold / Premier - Platinum / Elite The first name in each pair is the canonical `partner_tier` value. **Formula:** ``` Tier Distribution = Partners in tier / Total partners × 100 ``` Partner Tier Distribution is reported per tier: one share for each tier, with the shares summing to 100%. **What it tells you:** Partner ecosystem maturity. --- ### Partner Activation Rate **Definition:** Percentage of recruited partners who become productive. **Formula:** ``` Activation Rate = Partners recruited in period now active / Partners recruited in period × 100 ``` A recruited partner becomes active once productive: a first deal registered or closed, or the engagement threshold met. Count activation at period end for the partners recruited in the period. **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 in period / Active partners at start of period × 100 ``` Partner Churn Rate is reported per partner tier. **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-sourced revenue as a percentage of total recognised (GAAP) 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 ``` Total partner revenue is Partner-Influenced Revenue: closed revenue on every deal with a partner involved, partner-sourced deals included. **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:** Median sales cycle for registered partner deals that closed won in the period, from registration to close. **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 its lifetime. **Formula:** ``` Partner LTV = Average annual partner revenue / Partner churn rate ``` Average annual partner revenue is Average Partner Revenue measured over a 12-month period. --- ### 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 deals are closed-won opportunities whose `channel` is `marketplace`. --- ### 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:** Investors often discount a high services share, because services revenue grows with headcount rather than with product usage. --- ### 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 ``` Measured on projects completed in the period. **What it tells you:** Profitability by engagement, including which ones lose money. --- ### Realization Rate **Definition:** Actual revenue realized vs potential revenue at standard rates. **Formula:** ``` Realization Rate = Actual revenue / (Hours worked × Standard rate) × 100 ``` Hours worked are taken from billed hours. **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. Hours booked are the budgeted hours on sold projects. **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 completed in the period within their budgeted hours. **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 = Average of (Estimated duration / Actual duration) per project × 100 ``` Compute the ratio for each project completed in the period, then average, so every project carries equal weight. **Target:** 90-110% --- ### Project Milestone Completion Rate **Definition:** Percentage of milestones completed on schedule. **Formula:** ``` Project Milestone Completion Rate = 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 ``` --- ### Project Escalation Rate **Definition:** Percentage of projects with escalations. **Formula:** ``` Project 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. Use an annual period to compare against them. --- ### Projects per Consultant **Definition:** Average projects completed per consultant in the period. **Formula:** ``` Projects per Consultant = Completed projects / Consultant headcount ``` --- ### Average Project Duration **Definition:** Average length, in days, of projects completed in the period. **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, with the order to check them in when one moves. --- ## The Core Model Revenue is the outcome that every other metric here drives. The diagram starts from Annual Recurring Revenue (ARR) and the Monthly Recurring Revenue (MRR) movements that change 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 │ └───────┘ └─────────┘ └──────────┘ └───────┘ └─────────┘ └─────────┘ ``` --- ## Reading the Map The [interactive diagram](https://koinedata.com/v1/relationships) ([relationships.json](relationships.json)) and the MCP traversal tools read the same graph. Its edges come in three groups: - **Component** edges say A is an input to B's formula. They are generated from the canonical formulas rather than drawn by hand, so they always match them. - **Drives**, **reduces** and **predicts** edges are curated. A drives B when A rising pushes B up. A reduces B when A rising pushes B down, which lets a lower-is-better metric such as First Response Time, or a cost, point at what it affects. A predicts B when A moves first and forecasts where B goes. - **Measures** edges link a metric to the business entity it tracks (Logo Churn Rate measures Customer) and are derived from the datasets each formula reads. Entity edges such as owns, converts_to and generates describe how the business objects relate. Two rules shape how the tools walk the graph: - **One direction per pair.** The graph has no two-way edges. A rate computed from an amount does not also claim to move that amount, so a walk upstream never loops back through a ratio's own inputs. - **Baseline inputs end the walk.** A metric read at period start or inside `lag()` is a baseline: NRR, for example, reads MRR at the start of the period over the customers active then. Driver traversal lists the baseline as a component and stops there, because whatever moved it did so before the period began. New business reaches MRR and enters NRR only as next period's baseline, which is why the tools leave New MRR, Win Rate and pipeline out of NRR's drivers. --- ## Revenue Drivers ### ARR Growth **What increases it:** - New MRR (acquisition) - Expansion MRR (upsell/cross-sell) - Reactivation MRR (churned customers returning) **What decreases it:** - Churned MRR (lost customers) - Contraction MRR (downgrades) **Formula:** ``` Net New MRR = New MRR + Expansion MRR + Reactivation MRR - Churned MRR - Contraction MRR ``` ARR moves by twelve times Net New MRR, because ARR is MRR × 12. --- ### 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 Net Promoter Score (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 / Revenue Churn Rate ``` **What increases LTV:** - Higher Average Revenue per Account (ARPA) from pricing and upsell - Better margins (lower COGS) - Lower churn (better retention) **Key relationship:** Read LTV against CAC. An LTV:CAC ratio above 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 The retention chain runs from onboarding to Net Revenue Retention (NRR) and Gross Revenue Retention (GRR): ``` 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 | --- ## Leading vs Lagging Indicators ### Leading Indicators (Early Warning) These move before the outcomes do: **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 (by_segment breakdowns on Logo Churn Rate, │ Revenue Churn Rate, Churned MRR, NRR and GRR) └── 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, so when an outcome moves, the diagram above shows which stage to check first. --- # Commercial Event Ledger (CEL) The event layer behind the commercial metrics of the GASP Standard. Every revenue, retention and cost metric in this standard derives from atomic commercial events. The CEL is the governed layer where those events live: if a commercial event is not in the CEL, it does not exist for metric purposes. Operational metrics (support, engineering, product usage, people) read the other datasets declared in `ontology.json`, such as tickets, incidents and product events, which sit outside the CEL (see [Scope Boundaries](#scope-boundaries)). --- ## Why the CEL Exists SaaS companies typically compute metrics from derived tables: MRR snapshots, billing system exports, CRM rollups. These derived sources drift: two teams querying MRR from different derived tables get different numbers. The CEL removes the drift by computing every commercial metric from one event-level layer. The CEL is a conceptual standard for how commercial events are captured, stored and governed, which you implement 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 rather than 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 six event classes. Every commercial event in a SaaS business sold by subscription, by consumption or by both 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://koinedata.com/v1/definitions#customer-account-organization) identifier | | `subscription_id` | `string` | [Subscription](https://koinedata.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 | | `expansion_classification` | `enum` (expansion, contraction and reactivation only) | `same_product`, `new_module`, `new_buying_centre`, `pricing_adjustment`, `recontracting`, `usage_realisation`. See [ATL](https://koinedata.com/v1/atl#expansion-classification). The NRR and ARR forms read it. | | `change_nature` | `enum` (optional) | `permanent` (default), `temporary`, `scheduled_reversal`. See [Change Nature](#change-nature). | | `segment` | `string` | Segment the customer was in when the event occurred. A customer that moves segment keeps its history as it was. See [Segment on events](#segment-on-events). | --- ### Cost_Event An incurred cost, tagged with the function it serves. 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` | `enum` | Department or team: `marketing`, `sales`, `customer_success`, `support`, `engineering`, `product`, `finance`, `people`, `services`, `partnerships`, `general` | | `cost` | `decimal` | Cost amount | | `currency` | `string` | ISO 4217 currency code | | `cost_type` | `enum` | Nature of the cost: `personnel`, `software`, `services`, `infrastructure`, `other` | | `cost_function` | `enum` | Purpose of the cost (the ATL cost function tag): `gtm`, `implementation`, `onboarding`, `infrastructure`, `support`, `success_engineering`, `account_management`, `research_development`, `general_administrative`, `services_delivery`, `recruiting`, `partner_program`, `partner_commission` | | `customer_id` | `string` (nullable) | Customer if directly attributable; null for shared costs | | `partner_id` | `string` (nullable) | Partner identifier; null on costs not attributable to a partner | | `project_id` | `string` (nullable) | Services project identifier; null on costs not attributable to a project | | `lifecycle_attribution` | `enum` | ATL lifecycle tag: `acquisition`, `activation`, `retention`, `expansion`, `reactivation`, `servicing`. See [ATL](https://koinedata.com/v1/atl#lifecycle-attribution). | | `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://koinedata.com/v1/definitions#customer-account-organization) identifier | | `subscription_id` | `string` | [Subscription](https://koinedata.com/v1/definitions#subscription-contract-agreement) identifier | | `contract_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 | | `segment` | `string` | Segment the customer was in when the event occurred. A customer that moves segment keeps its history as it was. See [Segment on events](#segment-on-events). | --- ### 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://koinedata.com/v1/definitions#customer-account-organization) identifier | | `subscription_id` | `string` | [Subscription](https://koinedata.com/v1/definitions#subscription-contract-agreement) identifier | | `amendment_type` | `enum` | `upgrade`, `downgrade`, `add_on`, `cross_sell`, `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). | | `segment` | `string` | Segment the customer was in when the event occurred. A customer that moves segment keeps its history as it was. See [Segment on events](#segment-on-events). | --- ### 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://koinedata.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") | --- ### Credit_Event A movement on a prepaid credit balance, or consumption billed with no balance behind it. Primary input for Consumption Revenue, Usage Run-Rate, Prepaid Credit Balance and Credit Breakage. | Field | Type | Description | |-------|------|-------------| | `event_id` | `string` | Unique identifier | | `event_date` | `date` | Date the event occurred: the day or the billing period end the source records, never a single product usage event | | `customer_id` | `string` | [Customer](https://koinedata.com/v1/definitions#customer-account-organization) identifier | | `subscription_id` | `string` | [Subscription](https://koinedata.com/v1/definitions#subscription-contract-agreement) or commitment the balance belongs to | | `credit_event_type` | `enum` | `purchase` (a prepaid commitment or block of credits paid for, a rollover grant included), `consumption` (usage drawn down or billed), `expiry` (unused balance forfeited at its expiry date), `adjustment` (promotional grants, refunds, reversals, corrections) | | `credit_amount` | `decimal` | Signed amount in currency at the contract's rates: positive for `purchase` and a granting `adjustment`, negative for `consumption`, `expiry` and a reducing `adjustment`. The sign convention mirrors `mrr_change` | | `consumption_basis` | `enum` (consumption only) | `committed` (drawn from a prepaid balance), `overage` (above an exhausted or per-period commitment), `on_demand` (no commitment) | | `credit_balance_before` | `decimal` (optional) | The customer's prepaid balance before the event; equal to `credit_balance_after` on `overage` and `on_demand` consumption, which draw no balance | | `credit_balance_after` | `decimal` (optional) | The customer's prepaid balance after the event. Where both balances are mapped, `credit_balance_before + credit_amount = credit_balance_after` on every row that moves the balance | | `expires_on` | `date` (purchase only) | When the granted balance expires; empty when it does not | | `currency` | `string` | ISO 4217 currency code | | `segment` | `string` | Segment the customer was in when the event occurred. See [Segment on events](#segment-on-events). | The balances are optional because several billing systems carry the signed amount alone and leave the balance to a sum; the metrics read `credit_amount` either way. The ledger is kept at customer and subscription level, so the source system decides which grant a consumption draws first. **Rollover.** A balance that rolls over into a new term has no `expiry` event. The new term's grant is a `purchase` carrying the new `expires_on`, and the rolled-over amount is carried by that grant rather than bought again. **What stays out.** Usage quantities in product units (the CEL carries currency), rated usage lines (the billing system keeps those) and GAAP journal entries. A `Credit_Event` is the commercial fact that a balance was bought, consumed or forfeited; the entry that recognises it as revenue stays in the accounting ledger. ### Pairing rule: amendments that change MRR Any `Amendment_Event` that changes MRR also writes a `Revenue_Event` carrying the `mrr_change`, the `event_type` (`expansion` or `contraction`) and the `expansion_classification`. The amendment row keeps the contract detail (plan, quantity, amendment type). The two are distinct facts about one commercial action, so NRR, ARR and the other revenue metrics read `Revenue_Event` and still see mid-term expansion such as seat adds and `new_module` upsells. ### Segment on events `segment` is a dimension for slicing metrics, not an ATL tag: it says which kind of customer an event belongs to, not what the event means. It is denormalised onto `Revenue_Event`, `Contract_Event`, `Amendment_Event` and `Credit_Event` on purpose, as of the event date, so NRR, churn and the MRR movements group by segment without a join and a customer that moves from SMB to Mid-Market keeps its earlier events in SMB. The customer and subscription snapshots carry the current value on each snapshot date. Pricing tier is the plan (`plan_id`), not the segment. --- ## 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 } ``` The paired `Revenue_Event` carries the revenue effect: ```json { "event_class": "Revenue_Event", "event_id": "rev-020", "event_date": "2026-02-10", "customer_id": "cust-0512", "subscription_id": "sub-0890", "event_type": "expansion", "expansion_classification": "same_product", "mrr_change": 500.00, "currency": "USD", "prior_mrr": 1000.00, "new_mrr": 1500.00 } ``` ### 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 } ``` The paired `Revenue_Event` carries the revenue effect: ```json { "event_class": "Revenue_Event", "event_id": "rev-021", "event_date": "2026-03-01", "customer_id": "cust-0512", "subscription_id": "sub-0891", "event_type": "expansion", "expansion_classification": "new_module", "mrr_change": 800.00, "currency": "USD", "prior_mrr": 2000.00, "new_mrr": 2800.00 } ``` ### 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": "services", "cost": 6000.00, "currency": "USD", "cost_type": "personnel", "cost_function": "implementation", "customer_id": "cust-1042", "description": "40 hrs implementation engineering @ $150/hr" } ``` ### 7. GTM Spend (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", "cost": 45000.00, "currency": "USD", "cost_type": "services", "cost_function": "gtm", "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", "cost": 2400.00, "currency": "USD", "cost_type": "personnel", "cost_function": "success_engineering", "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", "contract_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" } ``` ### 11. Prepaid Credit Drawdown A customer on a $120,000 annual prepaid commitment consumes $9,400 of it in March. The purchase was recorded as its own `Credit_Event` when the commitment was paid for. ```json { "event_class": "Credit_Event", "event_id": "cre-001", "event_date": "2026-03-31", "customer_id": "cust-0921", "subscription_id": "sub-1730", "credit_event_type": "consumption", "credit_amount": -9400.00, "consumption_basis": "committed", "credit_balance_before": 101200.00, "credit_balance_after": 91800.00, "currency": "USD", "segment": "Enterprise" } ``` --- ## Example SQL A minimal warehouse implementation, illustrative rather than normative, so adapt it to your warehouse dialect and tooling. The MCP server's `generate_query` and `get_data_requirements` tools compile the canonical formulas to SQL in several warehouse dialects. ### 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(32) NOT NULL, cost DECIMAL(12,2) NOT NULL, currency CHAR(3) NOT NULL DEFAULT 'USD', cost_type VARCHAR(20) NOT NULL, cost_function VARCHAR(32) NOT NULL, -- ATL cost function tag 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. Events keep their classification and metrics keep their calculation; the field adds structured metadata for analysing revenue quality downstream. ### 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. It sits beside standard NRR as an internal measure of revenue quality. ``` 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 -- Beginning MRR is the sum of all movements before the period; the cohort is -- the customers with MRR at that point. :period_start and :period_end bound -- the trailing twelve months. WITH cohort AS ( SELECT customer_id, SUM(mrr_change) AS beginning_mrr FROM cel_revenue_events WHERE event_date < :period_start GROUP BY customer_id HAVING SUM(mrr_change) > 0 ), movements AS ( SELECT e.event_type, e.mrr_change, COALESCE(e.change_nature, 'permanent') AS change_nature FROM cel_revenue_events e JOIN cohort c ON c.customer_id = e.customer_id WHERE e.event_date >= :period_start AND e.event_date <= :period_end ) SELECT -- Standard NRR (all movements) ((SELECT SUM(beginning_mrr) FROM cohort) + SUM(CASE WHEN event_type IN ('expansion', 'contraction', 'churn') THEN mrr_change ELSE 0 END)) / (SELECT SUM(beginning_mrr) FROM cohort) AS nrr_standard, -- Adjusted NRR (permanent movements only) ((SELECT SUM(beginning_mrr) FROM cohort) + SUM(CASE WHEN event_type IN ('expansion', 'contraction', 'churn') AND change_nature = 'permanent' THEN mrr_change ELSE 0 END)) / (SELECT SUM(beginning_mrr) FROM cohort) AS nrr_adjusted FROM movements; ``` --- ## Deriving Revenue Events from a Subscription Ledger Most billing systems hold subscriptions, not events: one record per subscription whose plan, quantity, MRR and status change over time, kept as periodic snapshots or as a version history. The CEL needs the movements between those states. This section defines how to derive `Revenue_Event` rows from such a ledger. The rules are the same for every source system, in keeping with design principle 5: a billing system appears only in the mapping that names its tables and columns, never in the rules. Where a billing system records amendments as events of its own, those are the better source: they carry the amendment type, the quantities and the date the change was agreed, and the [pairing rule](#pairing-rule-amendments-that-change-mrr) applies. The derivation below is for the common case where no such stream exists. Two further sources feed the same rules: an [invoice ledger](#deriving-revenue-events-from-an-invoice-ledger), for a billing system that keeps invoices but no subscription history, and [usage records](#deriving-usage-realisation), for the usage a customer realises beyond a commitment. ### Input The GASP `subscription` dataset: `subscription_id`, `customer_id`, `snapshot_date`, `mrr`, `subscription_status` and `segment`. A snapshot table has one row per subscription per snapshot date at any cadence. A version history (one row per change, valid from a date) is the same thing with `snapshot_date` as the date each version took effect. ### Rules 1. **MRR on a snapshot.** A subscription's MRR on a snapshot is its `mrr`, to the cent and 0 when null, when `subscription_status` is `active`, else 0. A paused, cancelled or expired subscription contributes nothing. A customer's MRR is the sum over its subscriptions, and a total within half a cent of zero is zero. 2. **Steps.** A step is a snapshot whose MRR differs from the same subscription's previous snapshot, in `snapshot_date` order. A subscription's first snapshot is a step from 0. The ledger holds one row per subscription per snapshot date and keeps a row for a cancelled or expired subscription: a subscription that stops appearing has no step and produces no event. 3. **Opening balances.** Rows on the ledger's first snapshot date are opening balances. They seed each customer's MRR and produce no event, and a customer that churned before that date comes back as `new`, since the ledger cannot know otherwise. If the ledger begins after the oldest subscription, its first date is the day from which events are trusted. A ledger that begins with the business has no opening balances: say so, and every first row is a step from 0. 4. **One event per step.** The event is dated the snapshot that first shows the change. `mrr_change` is the subscription's change. `prior_mrr` and `new_mrr` are the customer's MRR before and after the step, chained through the customer's steps in `snapshot_date` order, increases before decreases and then `subscription_id`, so `prior_mrr + mrr_change = new_mrr` holds on every row and the rows of one date add up to the customer's net movement. 5. **Event type**, from the customer's MRR at the start and the end of the step's date. An increase on a date the customer started at 0 is `new`, or `reactivation` when the customer had MRR on an earlier date. A decrease on a date the customer ends at 0 is `churn`. Any other increase is `expansion` and any other decrease `contraction`. So a plan swap onto a new subscription id is an expansion and a contraction, and two subscriptions cancelled on one date are two churns. A `renewal` changes no MRR and is not derived from the ledger; it comes from `Contract_Event` or the subscription's renewal fields. 6. **Tags and defaults.** `lifecycle_attribution` follows the [ATL assignment rules](https://koinedata.com/v1/atl#assignment-rules) for the event type: `new` is `acquisition`, `expansion` is `expansion`, `reactivation` is `reactivation`, `contraction` and `churn` are `retention`. `change_nature` is `permanent`. `segment` is the snapshot's. `currency` is the ledger's currency, supplied as a parameter because the `subscription` dataset carries none. `expansion_classification` is empty: the ledger shows that MRR moved, not whether the customer bought seats, a module or a price rise, and the Operating forms of ARR and NRR read that tag. Until the tag is filled from the amendment records, an ATL completeness check flags every derived expansion, contraction and reactivation. 7. **Identity.** `event_id` is `:`, a colon and the date in ISO 8601 form, so re-running the derivation over a longer ledger produces the same ids for the same events. The [usage realisation](#deriving-usage-realisation) events put `usage` between the two, `:usage:`, so a ledger step and a usage event on one day keep distinct ids. ### Cadence The ledger's cadence is the grain of the events. Daily snapshots show every movement on its day. Month-end snapshots net the movements inside a month into one event dated the month end, and a churn followed by a reactivation inside one interval leaves no event at all. Net New MRR and ending MRR by month are unaffected by that netting. The split into expansion, contraction, churn and reactivation moves when movements inside one interval offset each other, as do event dates and anything counted at a finer grain. Snapshot at the finest cadence the source allows. ### Reference SQL The derivation over the GASP field names, as the MCP server's `derive_cel` compiles it over a mapping. `'USD'` stands for the ledger's currency. Window functions and `||` run on Postgres, Redshift, Snowflake, BigQuery and Databricks; the text casts and the date shift are the constructs the dialects spell differently. The `kind` column is `ledger` on every row here; the usage derivation below adds its two kinds to the same chain. The test suite runs this over the standard's synthetic dataset and checks that it reproduces every generated movement (renewals and events before the first snapshot excluded), agrees with the compiled MRR movement metrics in every month and types a plan swap, a double cancellation and a two-subscription acquisition on one date as the rules say. ```sql WITH ledger AS ( SELECT subscription_id AS subscription_id, customer_id AS customer_id, snapshot_date AS snapshot_date, segment AS segment, CASE WHEN subscription_status = 'active' THEN ROUND(COALESCE(mrr, 0), 2) ELSE 0 END AS mrr FROM subscription WHERE snapshot_date IS NOT NULL ), steps AS ( SELECT subscription_id, customer_id, snapshot_date, segment, mrr, COALESCE(LAG(mrr) OVER (PARTITION BY subscription_id ORDER BY snapshot_date), 0) AS prior_sub_mrr, CASE WHEN snapshot_date = MIN(snapshot_date) OVER () THEN 1 ELSE 0 END AS opening FROM ledger ), changes AS ( SELECT subscription_id, customer_id, snapshot_date, segment, opening, mrr - prior_sub_mrr AS mrr_change, 'ledger' AS kind FROM steps WHERE mrr <> prior_sub_mrr ), day_changes AS ( SELECT customer_id, snapshot_date, SUM(mrr_change) AS day_change FROM changes GROUP BY customer_id, snapshot_date ), days AS ( SELECT customer_id, snapshot_date, day_change, SUM(day_change) OVER (PARTITION BY customer_id ORDER BY snapshot_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS day_end FROM day_changes ), day_state AS ( SELECT customer_id, snapshot_date, day_end - day_change AS day_start, day_end, COALESCE(MAX(CASE WHEN day_end > 0.005 THEN 1 ELSE 0 END) OVER (PARTITION BY customer_id ORDER BY snapshot_date ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING), 0) AS active_before FROM days ), chained AS ( SELECT c.subscription_id, c.customer_id, c.snapshot_date, c.segment, c.opening, c.mrr_change, c.kind, COALESCE(SUM(c.mrr_change) OVER (PARTITION BY c.customer_id ORDER BY c.snapshot_date, CASE WHEN c.mrr_change > 0 THEN 0 ELSE 1 END, c.subscription_id, c.kind ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING), 0) AS prior_mrr, SUM(c.mrr_change) OVER (PARTITION BY c.customer_id ORDER BY c.snapshot_date, CASE WHEN c.mrr_change > 0 THEN 0 ELSE 1 END, c.subscription_id, c.kind ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS new_mrr, s.day_start, s.day_end, s.active_before FROM changes c JOIN day_state s ON s.customer_id = c.customer_id AND s.snapshot_date = c.snapshot_date ), typed AS ( SELECT subscription_id, customer_id, snapshot_date, segment, opening, mrr_change, prior_mrr, new_mrr, kind, CASE WHEN kind = 'usage' THEN 'expansion' WHEN kind = 'usage_reversal' THEN 'contraction' WHEN mrr_change > 0 AND ABS(day_start) < 0.005 AND active_before = 1 THEN 'reactivation' WHEN mrr_change > 0 AND ABS(day_start) < 0.005 THEN 'new' WHEN mrr_change < 0 AND ABS(day_end) < 0.005 THEN 'churn' WHEN mrr_change > 0 THEN 'expansion' ELSE 'contraction' END AS event_type FROM chained ) SELECT CAST(subscription_id AS VARCHAR) || CASE WHEN kind = 'ledger' THEN ':' ELSE ':usage:' END || CAST(snapshot_date AS VARCHAR) AS event_id, snapshot_date AS event_date, customer_id, subscription_id, event_type, mrr_change, 'USD' AS currency, prior_mrr, new_mrr, CASE WHEN kind = 'ledger' THEN CAST(NULL AS VARCHAR) ELSE 'usage_realisation' END AS expansion_classification, CASE kind WHEN 'usage' THEN 'temporary' WHEN 'usage_reversal' THEN 'scheduled_reversal' ELSE 'permanent' END AS change_nature, CASE event_type WHEN 'new' THEN 'acquisition' WHEN 'expansion' THEN 'expansion' WHEN 'reactivation' THEN 'reactivation' ELSE 'retention' END AS lifecycle_attribution, segment FROM typed WHERE opening = 0 ORDER BY snapshot_date, customer_id, CASE WHEN mrr_change > 0 THEN 0 ELSE 1 END, subscription_id, kind ``` --- ## Deriving Revenue Events from an Invoice Ledger Some billing systems keep no subscription history: what they keep is the invoices. An invoice ledger is a subscription ledger with one row per service period, and the [rules above](#rules) apply to it once the invoices are read that way. This section defines the reading. It is the second choice: where a subscription ledger or an amendment stream exists, use that. ### Input The GASP `invoice` dataset: `invoice_id`, `subscription_id`, `customer_id`, `snapshot_date`, `service_period_start`, `service_period_end` and `recurring_amount`. `recurring_amount` is the recurring part of the invoice as billed for the service period: subscription charges only, with one-off charges, usage billed beyond a commitment, credits and tax excluded. The service period is the days the recurring charge pays for, both ends inclusive. An invoice with no subscription or no service period (a one-off charge, a usage overage billed on its own) is not recurring and produces no event. ### Rules 1. **One row per invoice.** An invoice is read at its latest snapshot, so a correction replaces the earlier reading rather than adding to it. 2. **MRR of an invoice.** The recurring amount divided by the months the service period covers: the nearest whole number of months when the period is a fortnight or more (so a calendar month is one month whether it has 28 or 31 days, a quarter three and a year twelve), else the fraction of a month, with a month being 365.25 / 12 days. A prorated invoice for part of a period is approximate by this rule; where the billing system records the full-period rate beside the prorated charge, map `recurring_amount` to the rate. 3. **The ledger.** A subscription's ledger dates are the first day of each of its service periods and the day after the last day of each, and its MRR on a date is the sum of the MRR of its invoices whose service period covers that date. So a date with no covering invoice carries 0: the subscription has lapsed. The invoice dataset carries no segment and the rows carry none. 4. **The horizon.** The latest service period start on the ledger is the horizon, and no date after it is read. A subscription whose last invoice is still current therefore produces no churn, and a subscription whose last period ended before the horizon churns the day after it ended. The horizon moves forward with each billing run and the derivation picks the churn up then. 5. **Then the subscription rules.** Steps, opening balances, chaining, event types, tags and identity follow [rules 2 to 7](#rules) above. Rows on the ledger's first date (the earliest service period start) are opening balances by default; say `steps` when the invoices begin with the business. Each movement is dated the service period that first bills it: a change agreed mid-period shows on the next period's start unless a prorated invoice was issued for the remainder, which shows it on that invoice's start. ### Reference SQL The `ledger` common table expression of the invoice source, over the GASP field names. The rest of the query is the [subscription derivation](#reference-sql) from `steps` on, unchanged. `derive_cel` emits the whole query with `source: invoice`. The test suite runs it over the synthetic dataset's monthly invoices and checks that every change in a customer's MRR on the first of a month comes back as an event dated that day, that a lapsed subscription churns the day after its last period and that a current one does not, and that a one-off invoice adds nothing. ```sql invoices AS ( SELECT invoice_id, subscription_id, customer_id, service_period_start, service_period_end, recurring_amount FROM ( SELECT invoice_id AS invoice_id, subscription_id AS subscription_id, customer_id AS customer_id, service_period_start AS service_period_start, service_period_end AS service_period_end, recurring_amount AS recurring_amount, ROW_NUMBER() OVER (PARTITION BY invoice_id ORDER BY snapshot_date DESC) AS latest FROM invoice WHERE subscription_id IS NOT NULL AND service_period_start IS NOT NULL AND service_period_end IS NOT NULL ) i WHERE latest = 1 ), periods AS ( SELECT invoice_id, subscription_id, customer_id, service_period_start, service_period_end, ROUND(COALESCE(recurring_amount, 0) / (CASE WHEN ROUND(months) < 1 THEN months ELSE ROUND(months) END), 2) AS mrr FROM ( SELECT i.*, (service_period_end - service_period_start + 1) * 12.0 / 365.25 AS months FROM invoices i ) m ), boundaries AS ( SELECT subscription_id, customer_id, service_period_start AS snapshot_date FROM periods UNION SELECT subscription_id, customer_id, CAST((service_period_end + INTERVAL '1 day') AS DATE) FROM periods ), horizon AS ( SELECT MAX(service_period_start) AS latest FROM periods ), ledger AS ( SELECT b.subscription_id, b.customer_id, b.snapshot_date, CAST(NULL AS VARCHAR) AS segment, ROUND(COALESCE(SUM(p.mrr), 0), 2) AS mrr FROM boundaries b LEFT JOIN periods p ON p.subscription_id = b.subscription_id AND p.service_period_start <= b.snapshot_date AND b.snapshot_date <= p.service_period_end WHERE b.snapshot_date <= (SELECT latest FROM horizon) GROUP BY b.subscription_id, b.customer_id, b.snapshot_date ) ``` --- ## Deriving Usage Realisation A customer on a usage commitment pays for what it committed to whether or not it uses it, and for what it uses beyond that. The commitment is in the subscription's MRR and the ledger derivations above carry it. The usage beyond it is the `usage_realisation` expansion the [ATL](https://koinedata.com/v1/atl#expansion-classification) names, and this section defines how it is derived. Usage that stays within the commitment is no event: the committed revenue was recognised when the commitment was made. ### Input The GASP `usage_record` dataset: `subscription_id`, `customer_id`, `period_start`, `period_end`, `committed_amount` and `usage_amount`, one row per subscription per usage period. `committed_amount` is the recurring charge the customer committed to for the period, at the price it is billed at, and `usage_amount` the charge for the usage recorded in the period at the contract's rates, before the commitment is applied. The part of `usage_amount` above `committed_amount` is what the period bills as overage. ### Rules 1. **Overage.** A period realises usage when `usage_amount` exceeds `committed_amount`. The overage is the difference, divided by the months the period covers by the [invoice rule](#rules-1) for months, so it is stated as MRR. 2. **A pair of events.** Each such period adds two `Revenue_Event` rows to the ledger's events. The realisation is an `expansion` dated the period's last day, when the overage is known, for the overage, tagged `expansion_classification` `usage_realisation`, `lifecycle_attribution` `expansion` and `change_nature` `temporary`: the contract bills it for that period only. Its reversal is a `contraction` dated the next day for the same amount, tagged `usage_realisation`, `retention` and `change_nature` `scheduled_reversal`, as the [change nature](#change-nature) rules pair them. Both are known on the period's last day, so the reversal exists as soon as the realisation does. 3. **Chaining.** The pairs are steps in the customer's MRR like the ledger's own, chained with them in date order, so `prior_mrr + mrr_change = new_mrr` holds across both and the customer's MRR at a period end includes the usage realised in it. A realisation is an expansion and a reversal a contraction whatever the customer's other MRR on the day, so a reversal on the day a subscription churns is not a second churn. 4. **What the records do not say.** Usage that repeats every period is still temporary each time: the values describe the contract, not a judgement. A commitment raised to cover the usage shows on the subscription or invoice ledger as a permanent expansion, and from then on the usage within it is no event. The usage records carry no segment. The `usage_record` dataset's currency is the ledger's. Identity is `:usage:`. ### Reference SQL The two common table expressions the usage records add, over the GASP field names. `usage_changes` is appended to the subscription derivation's `changes` with `UNION ALL`, and its `kind` sets the event type, the tags and the identity in the final `SELECT` above. `derive_cel` emits the whole query when the mapping covers `usage_record`. The test suite runs it over the synthetic dataset's usage records and checks that every month over the commitment gives its pair, dated the month's last day and the first of the next, that the pairs chain with the ledger's steps, and that the months within the commitment give nothing. ```sql usage_periods AS ( SELECT subscription_id, customer_id, period_end, ROUND(overage / (CASE WHEN ROUND(months) < 1 THEN months ELSE ROUND(months) END), 2) AS overage FROM ( SELECT subscription_id AS subscription_id, customer_id AS customer_id, period_end AS period_end, usage_amount - committed_amount AS overage, (period_end - period_start + 1) * 12.0 / 365.25 AS months FROM usage_record WHERE period_start IS NOT NULL AND period_end IS NOT NULL AND usage_amount > committed_amount ) u ), usage_changes AS ( SELECT subscription_id, customer_id, period_end AS snapshot_date, CAST(NULL AS VARCHAR) AS segment, 0 AS opening, overage AS mrr_change, 'usage' AS kind FROM usage_periods WHERE overage >= 0.01 UNION ALL SELECT subscription_id, customer_id, CAST((period_end + INTERVAL '1 day') AS DATE), CAST(NULL AS VARCHAR), 0, -overage, 'usage_reversal' FROM usage_periods WHERE overage >= 0.01 ) ``` --- ## Deriving Credit Events The [Credit_Event](#credit_event) ledger and the usage records describe the same overage from two sides. A billing system that keeps a credit ledger records the usage billed beyond a commitment as `consumption` with basis `overage`; a billing system that keeps usage records states the commitment and the usage beside it. This section defines how each gives what the other would: the usage realisation pair from the credit ledger, and the consumption events from the usage records. One of the two is read, so the overage is never counted twice. ### Realisation from the Credit Ledger #### Input The GASP `credit_event` dataset: `subscription_id`, `customer_id`, `event_date`, `credit_event_type`, `consumption_basis` and `credit_amount`. Only `consumption` rows with basis `overage` are read. Consumption drawn from a prepaid balance (basis `committed`) is already in the subscription's MRR through the commitment, and pay-as-you-go consumption (basis `on_demand`) has no commitment to exceed, so neither realises usage. #### Rules 1. **Overage per month.** A subscription's `consumption` events with basis `overage` in a calendar month sum to that month's realised usage: the sum of their `credit_amount`, negated, since consumption is negative. 2. **The pair.** Each month with an overage of a cent or more adds the pair the [usage realisation rules](#deriving-usage-realisation) define: an `expansion` dated the month's last day and its `scheduled_reversal` dated the next day, tagged `usage_realisation`, chained with the ledger's steps, identity `:usage:`. The pair is the same whichever way the commitment was billed: realised usage above a commitment is expansion, ratable or drawn down. 3. **One source.** Where the usage records are mapped they are the source, and the credit ledger's overage is not derived again: `derive_cel` reads the `usage_record` dataset when the mapping covers it and the `credit_event` dataset otherwise. #### Reference SQL The two common table expressions the credit ledger adds in place of the usage records', over the GASP field names. They end in the same `usage_changes`, so the final `SELECT` of the [subscription derivation](#reference-sql) types, tags and identifies the pairs exactly as it does the usage records'. The test suite runs it over the synthetic dataset's credit events and checks that it gives the pairs the usage records give for the same customers, row for row, and nothing for drawdown and pay-as-you-go consumption. ```sql usage_periods AS ( SELECT subscription_id, customer_id, period_end, ROUND(SUM(overage), 2) AS overage FROM ( SELECT subscription_id AS subscription_id, customer_id AS customer_id, CAST(DATE_TRUNC('month', event_date) + INTERVAL '1 month' - INTERVAL '1 day' AS DATE) AS period_end, -(credit_amount) AS overage FROM credit_event WHERE subscription_id IS NOT NULL AND event_date IS NOT NULL AND credit_event_type = 'consumption' AND consumption_basis = 'overage' ) c GROUP BY subscription_id, customer_id, period_end ), usage_changes AS ( SELECT subscription_id, customer_id, period_end AS snapshot_date, CAST(NULL AS VARCHAR) AS segment, 0 AS opening, overage AS mrr_change, 'usage' AS kind FROM usage_periods WHERE overage >= 0.01 UNION ALL SELECT subscription_id, customer_id, CAST((period_end + INTERVAL '1 day') AS DATE), CAST(NULL AS VARCHAR), 0, -overage, 'usage_reversal' FROM usage_periods WHERE overage >= 0.01 ) ``` ### Consumption Events from Usage Records #### Input The GASP `usage_record` dataset, as [above](#deriving-usage-realisation): `subscription_id`, `customer_id`, `period_end`, `committed_amount` and `usage_amount`. This is for a company with usage records and no credit ledger, so that Consumption Revenue and Usage Run-Rate exist for its ratable customers. #### Rules 1. **One event per period over the commitment.** Each period whose `usage_amount` exceeds its `committed_amount` by a cent or more gives one `Credit_Event`: `credit_event_type` `consumption`, `consumption_basis` `overage`, dated the period's last day, identity `:overage:`. 2. **The amount as billed.** `credit_amount` is the overage the period bills, negated: `-(usage_amount - committed_amount)`. It is the whole period's charge, not stated as MRR; the realisation pair states it as MRR. 3. **What the records do not say.** Usage within a ratable commitment is no event: the commitment is in the subscription's MRR. The records hold no prepaid balance, so `credit_balance_before`, `credit_balance_after` and `expires_on` are empty, and they carry no segment. A prepaid balance, its purchases, its committed drawdowns and its expiries come from the billing system's credit ledger. 4. **No second realisation.** The usage records stay the source of the realisation pair, so the events written here are not read back by the rules above. #### Reference SQL The whole query, over the GASP field names. `derive_cel` emits it with `target: credit_event`. The test suite runs it over the synthetic dataset's usage records and checks that every month over the commitment gives one event for its overage, with the balances empty, and that the months within the commitment give nothing. ```sql WITH overage_periods AS ( SELECT subscription_id AS subscription_id, customer_id AS customer_id, period_end AS period_end, ROUND(usage_amount - committed_amount, 2) AS overage FROM usage_record WHERE period_end IS NOT NULL AND usage_amount > committed_amount ) SELECT CAST(subscription_id AS VARCHAR) || ':overage:' || CAST(period_end AS VARCHAR) AS event_id, period_end AS event_date, customer_id, subscription_id, 'consumption' AS credit_event_type, -overage AS credit_amount, 'overage' AS consumption_basis, CAST(NULL AS DECIMAL(18, 2)) AS credit_balance_before, CAST(NULL AS DECIMAL(18, 2)) AS credit_balance_after, CAST(NULL AS DATE) AS expires_on, 'USD' AS currency, CAST(NULL AS VARCHAR) AS segment FROM overage_periods WHERE overage >= 0.01 ORDER BY period_end, customer_id, subscription_id ``` --- ## Relationship to Existing Data Model The GASP Standard defines a three-level entity hierarchy in [Definitions](https://koinedata.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`, `Amendment_Event` and `Credit_Event`. MRR lives here, and so does a prepaid credit balance: a `Credit_Event` names the subscription or commitment its balance belongs to. | | **License** | Not directly in the CEL. Licenses are derived from subscriptions. Seat counts appear on `Amendment_Event` as `prior_quantity` / `new_quantity`. | The CEL sits beside the entity model and 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, tagged by function (S&M, COGS, implementation, support, R&D, G&A) - Contractual milestones (new, renewal, amendment, cancellation) - Mid-term subscription changes - Customer lifecycle state transitions - Prepaid commitments and credit blocks, their consumption and their expiry - Consumption billed on demand, with no commitment behind it **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. The credit ledger records the commercial fact; the journal entry that recognises it stays in the accounting ledger - HR events (hiring, termination), unless directly costed as a `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: SaaS sold by subscription, by consumption or by both. Consumption with or without a contracted commitment is covered through `Credit_Event`. MRR and ARR still exclude uncommitted usage, which [Consumption Revenue](https://koinedata.com/v1/metrics/finance#consumption-revenue) and [Usage Run-Rate](https://koinedata.com/v1/metrics/finance#usage-run-rate) report. Usage that exceeds a contracted commitment is also a `Revenue_Event` tagged `usage_realisation`, derived as [Deriving Usage Realisation](#deriving-usage-realisation) says. 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://koinedata.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 they supply the inputs for the Operating (O) and Market (M) forms declared in [Core Metrics](https://koinedata.com/v1/metrics/core), so ops teams get their internal economic truth and boards get the investor-comparable numbers 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://koinedata.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. Every CEL event carries the tags appropriate to its event class (see [Tagging Rules](#tagging-rules)). The tags are what metrics filter on: the Operating and Market forms of Customer Acquisition Cost (CAC) read the same cost events and differ only in which `cost_function` values they include. --- ## 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/contraction/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`. 8. `Revenue_Event` with `event_type = contraction` or `event_type = churn` is `retention`: the retention lens carries what was kept and what was lost, which is what Net Revenue Retention (NRR) and Gross Revenue Retention (GRR) read. --- ## Expansion Classification A customer adding seats to the product they already have is growing differently from a customer buying a new module; operators read the first as product pull and investors count both. This dimension records which kind of growth each event is. Applies to: `Revenue_Event` where `event_type` is `expansion`, `contraction` or `reactivation`, plus every `Amendment_Event` record. A price cut or a restructured contract that lowers MRR is a contraction tagged `pricing_adjustment` or `recontracting`. ARR-O reads those tags whatever the direction. ### 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 Expansion classification separates the Operating form of Net Revenue Retention (NRR-O) from its Market form (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. With expansion classification the same ledger reports organic growth apart from growth that came through new modules, new buying centres or pricing actions. Each number answers a different question. --- ## Cost Function Attribution Sales and marketing (S&M) spend to win a logo and implementation labour to onboard it are both costs of getting a paying customer. Only the first appears in the CAC that investors benchmark, so this dimension classifies every cost by the function it serves. 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. | | `research_development` | Building the product. Not customer-attributable. | Engineering and product salaries; development tooling. | | `general_administrative` | Running the company. Not customer-attributable. | Finance, legal, HR, facilities. | | `services_delivery` | Delivering paid professional services. | Consultant time on a billable project. | | `recruiting` | Hiring. | Agency fees; recruiter time. | | `partner_program` | Running the partner programme. | Partner enablement, portal, marketing development funds. | | `partner_commission` | Commissions paid to partners on sourced deals. | 15% referral fee on a closed deal. | Every cost event carries one `cost_function` value (Rule 3), so the enum covers all costs, including those outside the customer lifecycle. ### Why This Matters Cost function attribution separates CAC-O 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. Tagging each cost once lets both forms come from the same cost events, where a team without the tag ends up maintaining two separate cost allocation models. --- ## Tagging Rules Every CEL event is tagged according to these rules. ### Rule 1: Every event gets a Lifecycle tag Every `Revenue_Event`, `Cost_Event` and `Amendment_Event` receives exactly one `lifecycle_attribution` tag. The other three classes carry none: a `Contract_Event` is tagged through the `Revenue_Event` it generates, a `Lifecycle_State_Change` is itself the lifecycle transition, and a `Credit_Event` records a movement on a prepaid balance. A `Credit_Event` carries no `expansion_classification` and no `cost_function` tag either. The realised usage it feeds is tagged on the `Revenue_Event` the derivation writes, as [Deriving Usage Realisation](https://koinedata.com/v1/cel#deriving-usage-realisation) says. ### Rule 2: Revenue growth and amendments get an Expansion tag `Revenue_Event` records where `event_type` is `expansion`, `contraction` or `reactivation`, plus every `Amendment_Event` record, 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", "cost": 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": "services", "cost": 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", "cost": 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 CAC-O adds implementation and onboarding cost to GTM cost. This matches the `cac` operating form in `formulas.json`. ```sql SELECT (SELECT SUM(cost) FROM cel_cost_events WHERE cost_function IN ('gtm', 'implementation', 'onboarding') AND event_date BETWEEN :period_start AND :period_end) / NULLIF((SELECT COUNT(DISTINCT customer_id) FROM cel_revenue_events WHERE event_type = 'new' AND event_date BETWEEN :period_start AND :period_end), 0) AS cac_o; ``` ### CAC-M (Market): GTM-Only Acquisition Cost ```sql SELECT (SELECT SUM(cost) FROM cel_cost_events WHERE cost_function = 'gtm' AND event_date BETWEEN :period_start AND :period_end) / NULLIF((SELECT COUNT(DISTINCT customer_id) FROM cel_revenue_events WHERE event_type = 'new' AND event_date BETWEEN :period_start AND :period_end), 0) AS cac_m; ``` ### 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, the numbers ops teams use to run the business. M-form metrics match investor-comparable definitions, the numbers boards and investors benchmark against peers. The pattern is consistent: | Metric | Operating (O) Includes | Market (M) Includes | |--------|----------------------|-------------------| | **CAC** | `cost_function` ∈ (gtm, implementation, onboarding) | `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** | Revenue churn: MRR-weighted churned and contraction MRR | Logo-based: binary churned/active | | **ARR** | Durable ARR: excludes recontracting, pricing_adjustment (trailing 12 months, customers active at period end) | Contracted ARR: all recurring revenue | | **LTV:CAC** | LTV-O over CAC-O (contribution margin; gtm, implementation and onboarding cost) | LTV-M over CAC-M (gross margin; gtm cost only) | | **CAC Payback** | CAC-O over ARPA × GM-O | CAC-M over ARPA × GM-M | The full inclusion/exclusion rules for each dual-lens Core metric are specified as `ATL Inclusion` lines in the O/M subsections of [Core Metrics](https://koinedata.com/v1/metrics/core). Rule of 40 has no separate O/M form and needs none. The ATL dimensions defined here are the building blocks for those rules. --- ## Relationship to Existing Metrics Each dual-lens Core metric keeps one canonical formula. For CAC, ARR, LTV, LTV:CAC, CAC Payback and Gross Margin the canonical formula equals the Market (M) form. [Core Metrics](https://koinedata.com/v1/metrics/core) declares the Operating (O) and Market (M) forms beside each canonical formula, with a Bridge subsection that reconciles the two numbers. ATL supplies the tags both forms filter on, so the O form, the M form and the bridge between them all come from the same CEL events.