Reference
SaaS Metrics Definition Library
Reference library for SaaS metric definitions: ARR, MRR, NRR, churn, and pipeline coverage with variants, validation questions, drift traps, and ClariLayer Drift Risk.
Use this SaaS Metrics Definition Library as a practical reference for ARR, MRR, NRR, churn, and pipeline coverage metric definitions: each metric definition shows common variants, decisions to lock, validation questions, drift traps, and ClariLayer Drift Risk.
The short answer is that a SaaS metric definition is not just formula text. A useful definition states what the business means, which source systems are trusted, which variants are allowed, which owner can approve changes, and which questions should be answered before people or AI agents rely on the number.
This v0 library is anchored by five high-conflict flagship definitions because they are easy to name and hard to keep aligned: Annual Recurring Revenue, Monthly Recurring Revenue, Net Revenue Retention, churn, and pipeline coverage. The broader set continues into adjacent SaaS and RevOps metrics; use the cards for scanning, then use the detailed sections when a dashboard, board deck, forecast model, or agent workflow needs the assumptions behind the number.
Drift Risk methodology
ClariLayer Drift Risk is editorial scoring for definition governance. It is not a claim about public prevalence, platform performance, or financial outcome. Each score explains why a metric is likely to drift when teams separate business meaning from warehouse implementation.
Every metric is scored on four 1-5 axes:
- Ambiguity: how easily the metric name hides competing variants.
- Source-system dependency: how many operational systems must agree.
- Time-window sensitivity: how much dates, snapshots, or movement timing change the answer.
- Governance need: how much owner approval and change history the metric needs before reuse.
High-risk metrics are not bad metrics. They are metrics that need sharper context, clearer variant labels, and stronger review paths before the same name travels across finance, revenue operations, customer success, analytics, and AI-agent workflows.
How to use the library
Start by finding the metric name your team already uses. Compare the common variants to the definition in your dashboard or warehouse model. Then look at the decisions, validation questions, and drift traps before treating the metric as canonical.
The fastest useful workflow is:
- Pick the metric name that appears in a decision or external-facing report.
- Identify which variant the current number actually represents.
- Lock the business decisions that change the answer.
- Validate source-system boundaries and edge cases.
- Attach the definition, reasoning, owner, and review cadence to the context layer.
Filter metric definitions
16 of 16 definitions shown.
Metric definition cards
The v0 library is anchored by the first five flagship definitions and expands into adjacent SaaS and RevOps metrics. Each entry keeps the formula, business decisions, validation checks, drift traps, and AI context together.
Recurring revenue
Annual Recurring Revenue
Annual Recurring Revenue is the recurring subscription revenue expected from active customer commitments over a twelve-month period, after the team decides which contract states, billing events, discounts, and recurring product lines count.
- Formula
- sum(active recurring subscription value normalized to an annual period)
- Typical owners
- Finance, Revenue operations, Data and analytics
Recurring revenue
Monthly Recurring Revenue
Monthly Recurring Revenue is the recurring subscription revenue expected for a normalized month from active customer commitments, after the team decides how to handle billing cadence, usage, discounts, credits, pauses, and partial-month activity.
- Formula
- sum(active recurring subscription value normalized to one month)
- Typical owners
- Finance, Revenue operations, Data and analytics
Retention
Net Revenue Retention
Net Revenue Retention measures how much recurring revenue a starting cohort keeps after expansion, contraction, and churn over a defined period, before adding revenue from new customers outside that starting cohort.
- Formula
- (starting cohort recurring revenue + expansion - contraction - churn) / starting cohort recurring revenue
- Typical owners
- Finance, Customer success, Revenue operations, Data and analytics
Retention
Churn
Churn measures the loss of customers, subscriptions, or recurring revenue from a defined starting population over a defined period, with the exact answer depending on whether the governed variant is logo churn, revenue churn, or another approved loss view.
- Formula
- lost logos or lost recurring revenue from the starting population / starting population
- Typical owners
- Customer success, Finance, Revenue operations, Data and analytics
Sales pipeline
Pipeline Coverage
Pipeline Coverage compares qualified open pipeline to a bookings, revenue, or quota target for a defined future period, after the team decides which opportunities, stages, probabilities, forecast categories, and close dates are eligible.
- Formula
- eligible open pipeline for the target period / target bookings, revenue, or quota for the same period
- Typical owners
- Sales, Revenue operations, Finance, Data and analytics
Retention
Gross Revenue Retention
Gross Revenue Retention measures how much recurring revenue a starting customer cohort keeps after churn and contraction, before any expansion offsets are added back into the result.
- Formula
- (starting cohort recurring revenue - contraction - churn) / starting cohort recurring revenue
- Typical owners
- Finance, Customer success, Revenue operations
Recurring revenue
Expansion MRR
Expansion MRR measures recurring monthly revenue added from existing customers through upgrades, seat growth, package changes, or cross-sell activity during a defined period.
- Formula
- sum(positive recurring monthly revenue movements from existing customers in the period)
- Typical owners
- Revenue operations, Finance, Sales, Data and analytics
Recurring revenue
Contraction MRR
Contraction MRR measures recurring monthly revenue lost from existing customers through downgrades, seat reductions, package reductions, or other partial recurring decreases during a defined period.
- Formula
- sum(negative recurring monthly revenue movements from retained existing customers in the period)
- Typical owners
- Finance, Customer success, Revenue operations
Retention
Customer Churn Rate
Customer Churn Rate measures the share of starting customers that are no longer active by the end of a period, after the team defines the customer grain and the event that counts as customer loss.
- Formula
- customers lost from the starting customer population / customers in the starting customer population
- Typical owners
- Customer success, Revenue operations, Data and analytics
Retention
Logo Retention
Logo Retention measures the share of starting customers that remain active by the end of a period, independent of how much recurring revenue each retained customer contributes.
- Formula
- retained customers from the starting population / customers in the starting population
- Typical owners
- Customer success, Revenue operations, Executive
Recurring revenue
Average Revenue per Account
Average Revenue per Account measures recurring revenue divided by a governed account or user population for a defined period, making the denominator and revenue basis as important as the arithmetic.
- Formula
- recurring revenue for the governed population / count of governed accounts or users
- Typical owners
- Finance, Revenue operations, Data and analytics
Recurring revenue
Annual Contract Value
Annual Contract Value measures the annualized value of a customer contract or opportunity, after deciding how recurring, non-recurring, ramped, multi-year, and discounted amounts are treated.
- Formula
- contract value normalized to one annual period using the governed value basis
- Typical owners
- Sales, Finance, Revenue operations
Recurring revenue
ARR Growth Rate
ARR Growth Rate measures the percentage change in governed ARR between two points or periods, after the team decides which ARR variant, movement basis, and comparison window are valid.
- Formula
- (ending ARR - starting ARR) / starting ARR
- Typical owners
- Finance, Executive, Revenue operations
Sales pipeline
Sales Cycle Length
Sales Cycle Length measures the time between a governed sales start event and a governed close event for opportunities that meet the selected population and outcome criteria.
- Formula
- average(close event date - sales start event date) for governed opportunities
- Typical owners
- Sales, Revenue operations, Data and analytics
Sales pipeline
Win Rate
Win Rate measures the share of governed sales opportunities that close won within a selected population, outcome set, and time window.
- Formula
- closed-won opportunities / governed closed opportunity population
- Typical owners
- Sales, Revenue operations, Data and analytics
Sales pipeline
Forecast Accuracy
Forecast Accuracy measures how closely a governed forecast value matches the governed actual result for the same period, scope, currency, and business outcome.
- Formula
- 1 - absolute(forecast value - actual value) / actual value
- Typical owners
- Sales, Revenue operations, Finance, Executive
Detailed definitions
Use the detailed sections when the same metric name appears in a dashboard, board deck, forecast model, or AI workflow with different assumptions attached.
Recurring revenue
Annual Recurring Revenue
Annual Recurring Revenue is the recurring subscription revenue expected from active customer commitments over a twelve-month period, after the team decides which contract states, billing events, discounts, and recurring product lines count.
Governed formula
sum(active recurring subscription value normalized to an annual period)
- Exclude one-time services, implementation fees, usage overages, and taxes unless a governed definition explicitly includes them.
- Normalize monthly, quarterly, and multi-year recurring commitments to an annual amount before aggregation.
Booked ARR
Counts recurring contract value once an order or subscription is signed, even if billing or service start happens later.
Useful for sales momentum, but it can overstate revenue available to finance if start dates and cancellations are not governed.
Live ARR
Counts only recurring value from subscriptions that are active and serviceable during the reporting period.
Useful for operating reviews, but it depends on clean activation and termination state across billing and contract systems.
Committed ARR
Counts signed recurring commitments that are not yet active separately from currently live subscriptions.
Useful for handoffs between sales, finance, and delivery, but it requires clear treatment of future starts and ramp schedules.
Decisions to lock
Which subscription states count as active recurring revenue?
Signed, provisioned, billed, suspended, and canceled states can each tell a different story unless the accepted state boundary is explicit.
How are discounts, credits, ramp deals, and future-dated starts normalized?
ARR shifts materially when teams mix list price, net price, contracted ramps, and activation timing in the same metric.
Which product lines are recurring enough to belong in ARR?
Professional services, one-time setup, and variable usage can dilute the decision signal when they are blended into subscription run rate.
Validation questions
- Can the ARR total be reconciled from account-level rows back to signed commitments and active billing records?
- Do booked, live, and committed ARR views use separate labels rather than sharing one ambiguous ARR field?
- Are future-dated starts, canceled subscriptions, credits, and non-recurring fees visible in exception checks?
Common drift traps
- A CRM opportunity amount is reused as ARR after close even though the billing subscription later starts with a different net recurring value.
- Ramped contracts are annualized from the first month instead of the governed committed schedule, changing expansion and renewal views.
- One-time implementation or usage fees get bundled into recurring revenue because product and charge-type filters are not versioned.
Source-system boundary
Contract and billing spine
Contracts, Billing platform, CRM, Data warehouse
The governed definition should state which system supplies contract value, subscription state, start dates, end dates, currency, and account hierarchy.
Context-layer proof
ClariLayer's context layer should bind ARR to the approved contract state, recurring product filter, annualization rule, and owner decision so finance, sales, and AI agents do not silently swap booked ARR for live ARR.
- Governed signals
- approved subscription-state boundary, recurring charge-type filter, annualization and currency-normalization rule, owner and review cadence
- Review cadence
- Review after pricing, packaging, billing-system, or close-process changes.
ClariLayer Drift Risk
ARR is high risk because the name is familiar while the accepted state boundary, annualization rule, and source-system handoff often vary across finance, sales, and analytics.
Ambiguity
5/5ARR can mean booked, live, committed, gross, net, or product-filtered recurring value unless the accepted variant is named.
Source-system dependency
5/5The metric usually depends on contract, CRM, billing, and warehouse records that do not share identical lifecycle states.
Time-window sensitivity
4/5Future starts, ramps, renewals, cancellations, and mid-period changes can alter the annualized view for the same account.
Governance need
5/5ARR appears in executive, finance, board, and sales decisions, so owners need explicit approval and change history.
AI-agent risk
An AI agent answering ARR questions can mix booked, live, and committed definitions if the context layer does not expose the approved state boundary, product filters, and normalization rule next to the metric.
Recurring revenue
Monthly Recurring Revenue
Monthly Recurring Revenue is the recurring subscription revenue expected for a normalized month from active customer commitments, after the team decides how to handle billing cadence, usage, discounts, credits, pauses, and partial-month activity.
Governed formula
sum(active recurring subscription value normalized to one month)
- Normalize annual, quarterly, and monthly recurring commitments to a monthly amount before aggregation.
- Keep MRR separate from cash collected, invoices issued, and recognized revenue unless a governed variant says otherwise.
Ending MRR
Measures recurring monthly value at the end of a reporting period.
Useful for period-close reporting, but can hide intra-month churn, expansion, and pauses.
Average MRR
Averages recurring monthly value across the period rather than taking one point-in-time snapshot.
Useful for trend smoothing, but it needs an explicit daily or monthly snapshot policy.
Net New MRR
Tracks the period change from new, expansion, contraction, and churn movements.
Useful for growth decomposition, but only if movement categories share one event and timing model.
Decisions to lock
Is the metric a point-in-time ending value, an average value, or a movement measure?
Each view answers a different operating question and should not be compared as if it were the same metric.
How are pauses, credits, discounts, and partial-month subscriptions represented?
Small billing-state differences can create unexplained month-over-month changes that are not true growth or churn.
Does usage-based recurring revenue belong in core MRR or a separate governed variant?
Variable usage can make a recurring metric behave like consumption revenue unless the inclusion rule is visible.
Validation questions
- Can ending MRR reconcile to the active subscription ledger for the same close date?
- Do new, expansion, contraction, and churn movements add back to the total period change?
- Are credits, pauses, and partial-month records classified consistently instead of being dropped silently?
Common drift traps
- Invoice totals are treated as MRR, creating swings from annual prepayments, credits, and tax lines.
- A daily snapshot and a month-end snapshot share the same MRR label, so trend charts do not reconcile.
- Paused accounts remain active in CRM while billing records show no collectible recurring value.
Source-system boundary
Subscription movement spine
Billing platform, Contracts, CRM, Data warehouse
The governed definition should state which subscription events create monthly value, movement categories, and period snapshots.
Context-layer proof
ClariLayer's context layer should pin MRR to the approved snapshot timing, billing-state filter, movement taxonomy, and normalization rule so product, finance, and AI agent workflows can explain each monthly change.
- Governed signals
- snapshot timing, billing-state filter, movement taxonomy, normalization rule
- Review cadence
- Review after billing-state, discounting, pause-policy, or usage-pricing changes.
ClariLayer Drift Risk
MRR is high risk because it is used frequently, changes every period, and can drift when teams mix billing, subscription, and movement views.
Ambiguity
4/5MRR may mean ending, average, net new, gross, or billing-derived monthly value without a visible variant label.
Source-system dependency
5/5The metric depends on billing subscriptions, contract terms, CRM account structure, and warehouse movement logic.
Time-window sensitivity
5/5Snapshot date, partial-month treatment, pause timing, and movement dates can all change the reported month.
Governance need
4/5MRR drives recurring revenue reviews and needs owner-approved movement rules to keep period changes explainable.
AI-agent risk
An AI agent can confuse MRR with invoiced revenue or ARR divided by twelve unless the context layer supplies the approved monthly normalization and movement model.
Retention
Net Revenue Retention
Net Revenue Retention measures how much recurring revenue a starting cohort keeps after expansion, contraction, and churn over a defined period, before adding revenue from new customers outside that starting cohort.
Governed formula
(starting cohort recurring revenue + expansion - contraction - churn) / starting cohort recurring revenue
- Use the same cohort, currency, product filter, and recurring revenue basis for the numerator and denominator.
- Exclude new-customer recurring revenue that was not present in the starting cohort.
Account-cohort NRR
Builds the cohort from accounts active at the start of the period and follows those accounts through expansion, contraction, and churn.
Useful for customer-base health, but it needs account hierarchy and merger treatment to be explicit.
Subscription-cohort NRR
Builds the cohort from subscriptions active at the start of the period and follows subscription-level changes.
Useful for product-line analysis, but it may miss account-level expansion across related subscriptions.
Logo-excluded NRR
Keeps reactivated or acquired logos out of the cohort unless they existed at the start of the period.
Useful for strict retention analysis, but it requires a governed reactivation and acquisition policy.
Decisions to lock
What creates the starting cohort: accounts, subscriptions, products, or contracts?
Cohort grain controls which expansions and contractions are counted as retained revenue.
How are reactivations, account merges, acquisitions, and product migrations treated?
Those events can move revenue in or out of the cohort unless they have explicit treatment.
Which recurring revenue basis powers NRR: ARR, MRR, booked value, or live value?
NRR inherits the definition risk of the revenue basis used in both the starting and ending amounts.
Validation questions
- Can each NRR movement be traced back to a starting-cohort account or subscription?
- Do expansion, contraction, and churn movements reconcile to the same recurring revenue basis?
- Are reactivations, account merges, product migrations, and acquired accounts classified before the ratio is calculated?
Common drift traps
- New customers are accidentally included in the numerator because the ending-period query does not restrict to the starting cohort.
- Expansion uses booked ARR while contraction and churn use live MRR, producing a ratio that mixes definitions.
- Account hierarchy changes make a retained parent account look like churn at a child account level.
Source-system boundary
Retention cohort spine
Billing platform, Contracts, CRM, Customer success platform, Data warehouse
The governed definition should state cohort grain, start population, movement events, account hierarchy, and revenue basis.
Context-layer proof
ClariLayer's context layer should attach NRR to its cohort grain, starting population, revenue basis, and movement taxonomy so every retention answer can show which revenue stayed, expanded, contracted, or churned.
- Governed signals
- cohort grain, starting population, revenue basis, movement taxonomy
- Review cadence
- Review after account-hierarchy, pricing, packaging, renewal-process, or customer-success-system changes.
ClariLayer Drift Risk
NRR is high risk because it combines revenue definitions, cohort logic, and movement taxonomy into one ratio that often travels without its assumptions.
Ambiguity
5/5NRR can vary by cohort grain, revenue basis, reactivation treatment, and whether new-customer revenue is excluded correctly.
Source-system dependency
5/5The calculation depends on billing, contract, CRM, account hierarchy, success, and warehouse movement records.
Time-window sensitivity
5/5Start and end dates define the cohort, the movements, and the retained revenue, so small window changes can alter the ratio.
Governance need
5/5NRR is used in executive retention reviews and needs explicit owner approval for cohort and movement rules.
AI-agent risk
An AI agent summarizing retention can produce a confident but wrong answer if it cannot see the cohort grain, revenue basis, and movement classification that created the NRR figure.
Retention
Churn
Churn measures the loss of customers, subscriptions, or recurring revenue from a defined starting population over a defined period, with the exact answer depending on whether the governed variant is logo churn, revenue churn, or another approved loss view.
Governed formula
lost logos or lost recurring revenue from the starting population / starting population
- Logo churn and revenue churn answer different questions and should keep separate labels.
- State whether downgrades, pauses, non-payment, reactivations, and product migrations count as churn, contraction, or neither.
Logo Churn
Counts customers from the starting population that are no longer active by the end of the period.
Useful for customer-base health, but it ignores the size of each lost account.
Gross Revenue Churn
Counts recurring revenue lost from churn and contraction before expansion offsets.
Useful for downside pressure, but it needs a clear boundary between full churn and contraction.
Net Revenue Churn
Offsets lost recurring revenue with expansion or recovery inside the same governed population.
Useful for net movement reviews, but it can hide loss patterns if expansion is not shown separately.
Decisions to lock
Is the governed metric counting logos, subscriptions, seats, or recurring revenue?
The grain determines whether a lost small account and a lost large account carry the same weight.
When does churn occur: cancellation request, contract end, service stop, billing stop, or data inactivity?
Different operational systems mark churn at different times, creating period misalignment.
How are pauses, downgrades, reactivations, non-payment, and product migrations classified?
Churn can be inflated or understated when edge cases move between churn, contraction, and retained states.
Validation questions
- Can each churned logo or revenue amount be tied back to a member of the starting population?
- Do cancellation, billing, and customer-success states agree on the churn date or expose a governed precedence rule?
- Are downgrades, pauses, non-payment, and reactivations reported as explicit exceptions instead of being hidden in churn?
Common drift traps
- A customer marked canceled in CRM still has an active billing subscription, so logo churn and revenue churn diverge without explanation.
- Downgrades are counted as full churn in one dashboard and contraction in another because the movement taxonomy is not governed.
- Reactivated accounts are removed from churn retroactively, changing historical retention without a visible version change.
Source-system boundary
Loss-event spine
Billing platform, Contracts, CRM, Customer success platform, Product analytics, Data warehouse
The governed definition should state the starting population, loss event, reactivation rule, and whether the metric is logo-based or revenue-based.
Context-layer proof
ClariLayer's context layer should keep churn tied to an approved grain, starting population, loss event, and edge-case taxonomy so teams can tell whether they are discussing logo loss, recurring revenue loss, or contraction.
- Governed signals
- metric grain, starting population, loss event, edge-case taxonomy
- Review cadence
- Review after cancellation-flow, billing-state, renewal-process, or customer-success-process changes.
ClariLayer Drift Risk
Churn is high risk because the same word is used for logo loss, revenue loss, contraction, non-payment, and inactivity unless the governed grain is attached.
Ambiguity
5/5The label churn does not reveal whether the metric counts logos, revenue, subscriptions, seats, or product activity.
Source-system dependency
5/5The metric can draw from CRM cancellations, billing status, contract end dates, success records, and product activity.
Time-window sensitivity
5/5Cancellation request date, service end date, billing stop date, and reactivation timing can move churn between periods.
Governance need
5/5Churn drives retention, forecast, customer-success, and finance decisions, so edge-case treatment needs approved ownership.
AI-agent risk
An AI agent can answer churn questions with the wrong grain if it does not know whether the user needs logo churn, revenue churn, contraction, or a retention-cohort movement view.
Sales pipeline
Pipeline Coverage
Pipeline Coverage compares qualified open pipeline to a bookings, revenue, or quota target for a defined future period, after the team decides which opportunities, stages, probabilities, forecast categories, and close dates are eligible.
Governed formula
eligible open pipeline for the target period / target bookings, revenue, or quota for the same period
- State whether pipeline is unweighted, probability-weighted, commit-only, or limited to specific forecast categories.
- Use the same territory, segment, currency, and close-period boundary for pipeline and target.
Unweighted Pipeline Coverage
Uses the full amount of eligible open opportunities without multiplying by probability.
Useful for top-of-funnel sufficiency, but it can overstate coverage when stage quality is inconsistent.
Weighted Pipeline Coverage
Weights opportunity amount by probability, stage, or forecast category before comparing to target.
Useful for forecast discipline, but it depends on a governed probability or stage model.
Commit Pipeline Coverage
Limits coverage to opportunities in commit or similarly strict forecast categories.
Useful for near-term execution reviews, but it can miss creation gaps earlier in the pipeline.
Decisions to lock
Which opportunity stages, forecast categories, and close dates count as eligible pipeline?
Coverage changes quickly when early-stage or stale opportunities are included without an agreed quality boundary.
Is opportunity value unweighted, probability-weighted, stage-weighted, or commit-only?
The weighting model changes the relationship between pipeline creation and expected bookings.
What target is the denominator: bookings, ARR, revenue, quota, or another sales goal?
The numerator and denominator must describe the same period, segment, currency, and business outcome.
Validation questions
- Can every opportunity in coverage be explained by stage, forecast category, owner, amount, currency, and close-period eligibility?
- Does the denominator come from the same segment, territory, currency, and period as the open-pipeline numerator?
- Are stale opportunities, pushed close dates, duplicate opportunities, and renewal or expansion deals classified consistently?
Common drift traps
- The numerator uses all open opportunity amount while the denominator is new ARR quota, mixing renewals, expansion, services, and new business.
- Close dates are pushed into the target quarter without stage-quality checks, making coverage look healthier than sales execution supports.
- One dashboard uses unweighted pipeline while another uses probability-weighted pipeline under the same coverage label.
Source-system boundary
Sales planning spine
CRM, Spreadsheets, Data warehouse, ERP
The governed definition should state eligible opportunity filters, target source, currency handling, stage model, and close-period rules.
Context-layer proof
ClariLayer's context layer should connect pipeline coverage to the approved eligible-pipeline filter, weighting rule, target denominator, and stale-opportunity policy so forecast and planning agents do not treat every open deal as equivalent coverage.
- Governed signals
- eligible-pipeline filter, weighting rule, target denominator, stale-opportunity policy
- Review cadence
- Review after sales-stage, forecast-category, territory, quota, or CRM-process changes.
ClariLayer Drift Risk
Pipeline coverage is high risk because it joins sales-process quality, opportunity timing, target planning, and weighting assumptions into one ratio.
Ambiguity
5/5Coverage can mean unweighted, weighted, commit-only, new-business-only, expansion-inclusive, or target-specific pipeline.
Source-system dependency
4/5The metric depends on CRM opportunity data, planning targets, currency rules, and warehouse transformations.
Time-window sensitivity
5/5Close-date pushes, target-period boundaries, and quarter rollovers can move pipeline into or out of coverage quickly.
Governance need
5/5Coverage informs forecast, hiring, capacity, and executive sales reviews, so eligibility and target rules need owner approval.
AI-agent risk
An AI agent can recommend sales action from a misleading coverage number if it cannot see the eligible stage boundary, target denominator, weighting rule, and stale-pipeline policy.
Retention
Gross Revenue Retention
Gross Revenue Retention measures how much recurring revenue a starting customer cohort keeps after churn and contraction, before any expansion offsets are added back into the result.
Governed formula
(starting cohort recurring revenue - contraction - churn) / starting cohort recurring revenue
- Use one recurring revenue basis for starting revenue, contraction, and churn.
- Exclude expansion from the numerator so the metric shows downside retention pressure.
Account-cohort GRR
Follows accounts active at the start of the period and measures retained recurring revenue after losses.
Useful for customer-base durability, but account hierarchy changes need explicit treatment.
Subscription-cohort GRR
Follows subscriptions active at the start of the period instead of rolling movement to the account level.
Useful for product-line analysis, but it can miss offsetting changes across related subscriptions.
Product-filtered GRR
Limits the starting cohort and loss movements to approved recurring products or packages.
Useful when packaging changes, but it requires versioned product filters to keep history explainable.
Decisions to lock
Which starting cohort grain and recurring revenue basis define GRR?
GRR inherits the cohort and revenue-basis decisions behind ARR, MRR, and retention movements.
Which movements count as contraction versus full churn?
The numerator depends on loss classification, especially for downgrades, cancellations, and product migrations.
How are reactivations, account merges, and partial-period losses handled?
Edge cases can move retained revenue between periods or remove prior losses without a visible rule.
Validation questions
- Can every contraction and churn amount be traced to a starting-cohort customer or subscription?
- Does GRR exclude expansion even when the same account expands in the measurement period?
- Are downgrades, product migrations, and reactivations classified before the ratio is calculated?
Common drift traps
- Expansion is netted into the numerator, causing GRR to behave like NRR under a different label.
- Contraction uses subscription events while churn uses CRM account status, creating movement totals that do not reconcile.
- Product migrations are recorded as contraction in one system and retained revenue in another without a governed bridge.
Source-system boundary
Gross retention movement spine
Billing platform, Contracts, CRM, Customer success platform, Data warehouse
The governed definition should state cohort grain, recurring revenue basis, movement taxonomy, and account hierarchy handling.
Context-layer proof
ClariLayer's context layer should bind GRR to the approved cohort grain, recurring revenue basis, loss taxonomy, and expansion exclusion rule so retention conversations separate downside pressure from expansion strength.
- Governed signals
- cohort grain, recurring revenue basis, loss movement taxonomy, expansion exclusion rule
- Review cadence
- Review after packaging, renewal-process, billing-state, or account-hierarchy changes.
ClariLayer Drift Risk
GRR is high risk because it looks close to NRR while answering a different question about downside retention before expansion offsets.
Ambiguity
5/5GRR changes meaning when teams vary the cohort grain, revenue basis, loss taxonomy, or expansion exclusion rule.
Source-system dependency
5/5The metric depends on billing movements, contracts, CRM hierarchy, success records, and warehouse cohort logic.
Time-window sensitivity
4/5Start and end dates decide the cohort and loss movements, while reactivations can alter retained revenue timing.
Governance need
5/5GRR informs retention and customer-success action, so the exclusion of expansion and loss rules need owner approval.
AI-agent risk
An AI agent can misread GRR as net retention if the context layer does not expose that expansion is excluded and the loss movements come only from the starting cohort.
Recurring revenue
Expansion MRR
Expansion MRR measures recurring monthly revenue added from existing customers through upgrades, seat growth, package changes, or cross-sell activity during a defined period.
Governed formula
sum(positive recurring monthly revenue movements from existing customers in the period)
- Classify expansion from the same movement spine used for MRR, NRR, and retention reporting.
- Exclude new-customer MRR unless the governed definition explicitly treats reactivation or acquisition as expansion.
Upgrade Expansion MRR
Counts monthly recurring revenue added when an existing customer moves to a higher package or plan.
Useful for packaging reviews, but it needs plan migration rules to avoid double counting.
Seat Expansion MRR
Counts monthly recurring revenue added from additional seats, users, or capacity on an existing subscription.
Useful for product adoption motions, but only when quantity and price changes are separated.
Cross-sell Expansion MRR
Counts monthly recurring revenue added from new recurring products sold to existing customers.
Useful for account growth, but it depends on a governed existing-customer boundary.
Decisions to lock
What qualifies a customer as existing for expansion purposes?
Reactivations, acquisitions, and account hierarchy changes can make new revenue look like customer expansion.
Which movement events distinguish expansion from correction, migration, or new business?
Expansion totals drift when billing corrections and product migrations are not separated from true growth.
How are mid-period upgrades, ramp schedules, and currency changes normalized?
Movement timing and normalization decide which month receives expansion and how much value is recognized.
Validation questions
- Do expansion movements reconcile to the net change in MRR for existing customers?
- Are upgrades, seat growth, cross-sell, migrations, and billing corrections classified as separate movement types?
- Can each expansion amount be tied to an account, subscription, product, effective date, and prior monthly value?
Common drift traps
- Reactivated customers are counted as expansion even though they were outside the retained cohort at period start.
- Package migrations create both contraction and expansion movements that are not netted or labeled consistently.
- Sales opportunity amount is used as expansion MRR before billing activation confirms the recurring monthly value.
Source-system boundary
Existing-customer movement spine
Billing platform, Contracts, CRM, Data warehouse
The governed definition should state existing-customer eligibility, movement event types, product filters, and monthly normalization.
Context-layer proof
ClariLayer's context layer should attach Expansion MRR to customer eligibility, movement event type, effective date, and recurring monthly value so sales and success agents can distinguish true growth from migrations or corrections.
- Governed signals
- existing-customer boundary, movement event type, effective date, monthly normalization rule
- Review cadence
- Review after pricing, packaging, account-hierarchy, or billing-event changes.
ClariLayer Drift Risk
Expansion MRR is high risk because the same positive movement can represent upsell, cross-sell, migration, correction, or reactivation.
Ambiguity
5/5The label does not reveal whether upgrades, seat growth, cross-sell, reactivation, or migration movements are included.
Source-system dependency
4/5The metric depends on billing events, contract terms, CRM account status, and warehouse movement classification.
Time-window sensitivity
4/5Effective dates, ramps, and mid-period changes decide which month receives the expansion movement.
Governance need
4/5Expansion MRR influences sales credit, success programs, and growth decomposition, so movement rules need approval.
AI-agent risk
An AI agent can overstate account growth if expansion MRR is not tied to the approved existing-customer boundary, movement taxonomy, and monthly normalization rule.
Recurring revenue
Contraction MRR
Contraction MRR measures recurring monthly revenue lost from existing customers through downgrades, seat reductions, package reductions, or other partial recurring decreases during a defined period.
Governed formula
sum(negative recurring monthly revenue movements from retained existing customers in the period)
- Keep contraction separate from full churn so partial losses and account exits remain explainable.
- Use the same movement timing, currency, and product filters as the governed MRR definition.
Downgrade Contraction MRR
Counts recurring monthly value lost when customers move to lower packages or plans.
Useful for packaging and value reviews, but migration rules must identify true downgrades.
Seat Contraction MRR
Counts recurring monthly value lost from lower quantities, seat reductions, or capacity cuts.
Useful for adoption analysis, but it requires quantity changes to be separated from price changes.
Product Contraction MRR
Counts recurring monthly value lost when an existing customer removes one product but keeps another.
Useful for product health, but full account churn must remain classified separately.
Decisions to lock
Where is the boundary between contraction and churn?
Partial reductions and full exits drive different operating actions and must not share one loss bucket.
Do billing credits, corrections, pauses, and price concessions count as contraction?
Temporary or corrective records can inflate contraction when they are not governed as separate event types.
How are migration bundles and product swaps netted across a customer?
One migration can create negative and positive lines that should not be interpreted as separate churn and expansion events.
Validation questions
- Can contraction movements reconcile to retained customers whose recurring value decreased but did not fully churn?
- Are credits, pauses, corrections, and concessions excluded or separately labeled?
- Do product migrations net to the expected customer-level movement instead of double counting loss?
Common drift traps
- A full cancellation is recorded as contraction because the account record remains active after the subscription ends.
- Credits and billing corrections are treated as recurring loss movements without checking whether recurring value changed.
- A product swap creates contraction in one product view and expansion in another without a customer-level bridge.
Source-system boundary
Existing-customer loss movement spine
Billing platform, Contracts, CRM, Customer success platform, Data warehouse
The governed definition should state partial-loss boundaries, event types, migration handling, and monthly normalization.
Context-layer proof
ClariLayer's context layer should pin Contraction MRR to the approved partial-loss boundary, movement event taxonomy, migration handling, and monthly value change so teams can separate recoverable downgrades from churn.
- Governed signals
- partial-loss boundary, movement event taxonomy, migration handling, monthly value change
- Review cadence
- Review after cancellation, downgrade, billing-credit, packaging, or migration-process changes.
ClariLayer Drift Risk
Contraction MRR is high risk because negative movements can represent true downgrades, corrections, pauses, concessions, or full churn.
Ambiguity
5/5The metric is ambiguous unless the boundary between contraction, churn, credit, pause, and migration is explicit.
Source-system dependency
4/5The calculation relies on billing movement records, contract state, CRM account status, and success classifications.
Time-window sensitivity
4/5Effective dates, credits, pauses, and downgrade timing can move contraction between reporting periods.
Governance need
4/5Contraction MRR drives retention intervention and revenue decomposition, so movement rules need ownership.
AI-agent risk
An AI agent can send the wrong retention signal if contraction MRR is not separated from churn, billing corrections, pauses, and migration movements.
Retention
Customer Churn Rate
Customer Churn Rate measures the share of starting customers that are no longer active by the end of a period, after the team defines the customer grain and the event that counts as customer loss.
Governed formula
customers lost from the starting customer population / customers in the starting customer population
- Keep the customer grain separate from subscription, seat, product, and revenue churn views.
- State the precedence among cancellation request, contract end, billing stop, service stop, and inactivity signals.
Account Churn Rate
Counts lost accounts from the starting account population.
Useful for customer-base health, but parent-child account handling must be explicit.
Subscription Churn Rate
Counts lost subscriptions from the starting subscription population.
Useful for product operations, but it can count one customer multiple times.
Active-customer Churn Rate
Counts only customers that met a governed active status at the start of the period.
Useful for lifecycle reporting, but active status must not drift across CRM and billing systems.
Decisions to lock
What is the customer grain: parent account, child account, billing customer, or subscription owner?
The numerator and denominator change when one commercial relationship appears as multiple records.
Which event date marks a customer as churned?
Cancellation, service, contract, billing, and inactivity dates can place the same loss in different periods.
How are pauses, reactivations, mergers, and internal test accounts handled?
The starting population and loss count can drift when lifecycle edge cases are not removed or classified.
Validation questions
- Can every churned customer be traced to the starting population and a governed loss event?
- Do CRM, billing, contract, and success states agree or expose a documented precedence rule?
- Are reactivations, pauses, mergers, and test accounts visible in exception checks?
Common drift traps
- A parent account is retained while a child account churns, causing churn to change when hierarchy rolls up differently.
- Billing stop date and cancellation request date are mixed, shifting customer churn between months.
- Dormant free or test accounts remain in the starting population and dilute the loss rate.
Source-system boundary
Customer lifecycle spine
CRM, Billing platform, Contracts, Customer success platform, Product analytics, Data warehouse
The governed definition should state customer grain, active-state filter, loss event, and reactivation policy.
Context-layer proof
ClariLayer's context layer should bind Customer Churn Rate to customer grain, starting active population, loss event, and reactivation policy so retention agents know which commercial relationships truly exited.
- Governed signals
- customer grain, starting active population, loss event, reactivation policy
- Review cadence
- Review after lifecycle, account-hierarchy, cancellation-flow, or customer-success-system changes.
ClariLayer Drift Risk
Customer Churn Rate is high risk because customer grain and churn timing vary across CRM, billing, contracts, and success workflows.
Ambiguity
5/5The metric can count accounts, billing customers, subscriptions, or active users unless the customer grain is stated.
Source-system dependency
5/5The metric depends on CRM hierarchy, billing state, contracts, success lifecycle fields, and warehouse exclusions.
Time-window sensitivity
5/5Cancellation, end-date, billing-stop, inactivity, and reactivation timing can move churn between periods.
Governance need
5/5Customer churn informs retention programs and executive reporting, so grain and loss-event rules need approval.
AI-agent risk
An AI agent can confuse customer churn rate with revenue churn or subscription churn if the customer grain and loss-event precedence are not available with the metric.
Retention
Logo Retention
Logo Retention measures the share of starting customers that remain active by the end of a period, independent of how much recurring revenue each retained customer contributes.
Governed formula
retained customers from the starting population / customers in the starting population
- Use the same customer grain and active-state rule as the governed customer churn metric.
- Do not infer revenue health from logo retention without pairing it with recurring revenue retention metrics.
Renewal Logo Retention
Counts customers with renewal decisions in the period that remain active after renewal.
Useful for renewal operations, but it excludes customers not up for renewal in that period.
Period Logo Retention
Counts all starting customers and checks whether they remain active at period end.
Useful for broad customer-base health, but it depends heavily on active-state timing.
Segment Logo Retention
Calculates retention for a governed segment, region, plan, or customer size band.
Useful for focused action, but segment snapshots need to be fixed at the cohort start.
Decisions to lock
Which customer grain and active status define a retained logo?
Logo retention can change when account hierarchy or billing customer identity changes.
Is the denominator all starting customers or only customers with renewal events?
Period retention and renewal retention answer different operating questions.
How are reactivations, pauses, mergers, and acquired accounts treated?
Those lifecycle events can add, remove, or reshape logos unless the cohort rule is governed.
Validation questions
- Can every retained and lost logo be traced to the same starting population?
- Are renewal-only and full-period retention views labeled separately?
- Do account hierarchy changes, pauses, and reactivations produce visible exceptions?
Common drift traps
- Renewal logo retention is compared with full-period logo retention under the same label.
- Accounts that downgrade to zero recurring value remain active in CRM and are counted as retained logos.
- Segment retention changes when end-period segment labels replace start-period cohort labels.
Source-system boundary
Logo cohort spine
CRM, Billing platform, Contracts, Customer success platform, Data warehouse
The governed definition should state customer grain, active-state rule, renewal-event rule, and segment snapshot timing.
Context-layer proof
ClariLayer's context layer should attach Logo Retention to the approved customer grain, cohort denominator, active-state rule, and segment snapshot so teams can separate logo survival from revenue retention.
- Governed signals
- customer grain, cohort denominator, active-state rule, segment snapshot
- Review cadence
- Review after renewal-process, account-hierarchy, segment-model, or lifecycle-state changes.
ClariLayer Drift Risk
Logo Retention is medium risk because the formula is simple, but the customer grain, denominator, and active-state rule still drift across systems.
Ambiguity
4/5The metric can mean renewal retention, period retention, account retention, or billing-customer retention.
Source-system dependency
4/5The calculation uses CRM hierarchy, billing status, contract renewals, success lifecycle fields, and warehouse cohorts.
Time-window sensitivity
4/5Cohort start date, renewal date, active-state date, and reactivation timing can change retained logo counts.
Governance need
4/5Logo retention informs customer-success and executive reviews, so denominator and lifecycle rules need ownership.
AI-agent risk
An AI agent can overstate customer health if logo retention is interpreted as revenue retention or if renewal-only and full-period variants are not distinguished.
Recurring revenue
Average Revenue per Account
Average Revenue per Account measures recurring revenue divided by a governed account or user population for a defined period, making the denominator and revenue basis as important as the arithmetic.
Governed formula
recurring revenue for the governed population / count of governed accounts or users
- State whether the denominator is accounts, users, paying customers, active customers, or subscriptions.
- Use a labeled recurring revenue basis such as ARR, MRR, recognized subscription revenue, or another governed variant.
Ending ARPA
Uses ending recurring revenue and ending account count for a point-in-time view.
Useful for current account value, but it can swing when late-period activations or churn occur.
Average-period ARPA
Uses average recurring revenue and average account count across the period.
Useful for trend analysis, but it needs a governed snapshot cadence.
Segment ARPA
Calculates average revenue for a governed customer segment, plan, region, or sales motion.
Useful for pricing and packaging, but segment assignment must be versioned.
Decisions to lock
Is the denominator accounts, customers, subscriptions, users, or active users?
The metric changes meaning completely when the unit of account changes.
Which revenue basis and timing define the numerator?
ARR, MRR, billed revenue, and recognized subscription revenue answer different questions.
How are free, trial, internal, paused, and multi-product accounts handled?
Population filters can make average revenue appear to change even when customer value has not.
Validation questions
- Can the denominator reconcile to the governed account, customer, user, or subscription population?
- Does the numerator use a labeled revenue basis with the same period and segment filters?
- Are free, trial, paused, internal, and multi-product records handled consistently?
Common drift traps
- ARPA and ARPU are used interchangeably even though one denominator is accounts and another is users.
- The numerator uses ARR while the denominator uses active monthly users, mixing commercial and product grains.
- Trial accounts enter the denominator in product analytics but not in billing, changing average revenue unexpectedly.
Source-system boundary
Account value spine
Billing platform, CRM, Contracts, Data warehouse
The governed definition should state numerator basis, denominator grain, population filters, and snapshot timing.
Context-layer proof
ClariLayer's context layer should bind ARPA to the approved revenue basis, denominator grain, population filter, and snapshot timing so pricing and growth analyses do not mix account, user, and subscription views.
- Governed signals
- revenue basis, denominator grain, population filter, snapshot timing
- Review cadence
- Review after packaging, account-model, product-analytics, or billing-population changes.
ClariLayer Drift Risk
ARPA is medium risk because the arithmetic is simple but the denominator grain and revenue basis often vary across finance and product teams.
Ambiguity
4/5ARPA can be confused with ARPU, average contract value, average billed revenue, or active-user revenue.
Source-system dependency
4/5The metric joins billing or contract revenue with CRM account records, product users, and warehouse filters.
Time-window sensitivity
3/5Point-in-time versus average-period denominators can change the result during activation or churn-heavy periods.
Governance need
4/5ARPA informs pricing and segmentation decisions, so numerator and denominator rules need visible ownership.
AI-agent risk
An AI agent can draw the wrong pricing conclusion if ARPA does not expose the revenue basis, denominator grain, and population filters used to create the average.
Recurring revenue
Annual Contract Value
Annual Contract Value measures the annualized value of a customer contract or opportunity, after deciding how recurring, non-recurring, ramped, multi-year, and discounted amounts are treated.
Governed formula
contract value normalized to one annual period using the governed value basis
- State whether ACV is per contract, per account, per opportunity, or averaged across a population.
- Keep ACV separate from ARR unless both use the same recurring value and active-state rules.
Booked ACV
Uses signed opportunity or contract value normalized to one annual period.
Useful for sales bookings, but it can diverge from live recurring revenue after activation.
First-year ACV
Uses the value expected in the first contract year, including governed ramps or discounts.
Useful for implementation and planning, but it should not be mixed with steady-state annualized value.
Average ACV
Averages annualized contract values across a governed customer or deal population.
Useful for segment strategy, but outlier and population filters need to be visible.
Decisions to lock
Does ACV include only recurring subscription value or also services, usage, and one-time fees?
The metric may be used like ARR even when non-recurring amounts are included.
How are multi-year contracts, ramps, discounts, and future starts normalized?
Different normalization rules change both sales productivity and customer-value views.
Is ACV reported per contract, per account, per opportunity, or as an average?
The grain determines whether renewals, expansions, and multiple contracts are combined or separated.
Validation questions
- Can each ACV amount be traced back to a signed contract, opportunity, or approved quote?
- Are services, usage, discounts, ramps, and multi-year terms classified before annualization?
- Do ACV and ARR reconcile only where their governed inclusion rules intentionally match?
Common drift traps
- Opportunity amount is reused as ACV even though it includes services or usage that ARR excludes.
- A ramped deal is annualized from steady-state value while first-year planning uses discounted value.
- Multiple contracts under one account are averaged in one report and summed in another without a grain label.
Source-system boundary
Contract value spine
CRM, Contracts, Billing platform, Data warehouse
The governed definition should state value basis, contract grain, recurring filters, ramp handling, and discount treatment.
Context-layer proof
ClariLayer's context layer should bind ACV to value basis, contract grain, recurring inclusion rule, and annualization method so sales and finance agents do not substitute opportunity amount for governed contract value.
- Governed signals
- value basis, contract grain, recurring inclusion rule, annualization method
- Review cadence
- Review after quote, contract, packaging, discounting, or sales-process changes.
ClariLayer Drift Risk
ACV is high risk because it sits between sales bookings and recurring revenue, where opportunity, quote, contract, and billing values often differ.
Ambiguity
5/5ACV can mean booked value, first-year value, average contract value, recurring-only value, or total contract annualization.
Source-system dependency
5/5The metric depends on CRM opportunities, quotes, contracts, billing records, discounts, and warehouse normalization.
Time-window sensitivity
4/5Contract start dates, ramps, renewals, amendments, and close dates can shift ACV between periods.
Governance need
5/5ACV drives sales productivity and financial planning, so value basis and grain need explicit approval.
AI-agent risk
An AI agent can compare ACV with ARR or ARPA incorrectly if contract grain, recurring inclusion, and annualization rules are not attached to the value.
Recurring revenue
ARR Growth Rate
ARR Growth Rate measures the percentage change in governed ARR between two points or periods, after the team decides which ARR variant, movement basis, and comparison window are valid.
Governed formula
(ending ARR - starting ARR) / starting ARR
- Use the same ARR definition, currency rule, and account hierarchy for starting and ending values.
- State whether growth is point-in-time, period-average, organic-only, acquisition-inclusive, or movement-derived.
Period ARR Growth
Compares ending ARR with starting ARR for a governed reporting period.
Useful for executive trend reporting, but it depends on consistent period boundaries.
Organic ARR Growth
Excludes acquired, migrated, or imported revenue according to an approved rule.
Useful for operating performance, but it needs visible exclusion and reclassification logic.
Movement-derived ARR Growth
Builds growth from new, expansion, contraction, churn, and reactivation movements.
Useful for diagnostics, but movement categories must reconcile to the ARR change.
Decisions to lock
Which ARR variant powers the starting and ending values?
Booked, live, committed, and product-filtered ARR can each produce a different growth rate.
Which period boundary and comparison baseline define growth?
Month-over-month, quarter-over-quarter, year-over-year, and rolling views answer different questions.
How are acquisitions, migrations, currency changes, and reactivations classified?
Those changes can create apparent growth that is not comparable to recurring operating movement.
Validation questions
- Do starting and ending ARR use the same governed definition and currency rule?
- Can movement-derived growth reconcile to the period change in ARR?
- Are acquisitions, migrations, imports, and reactivations labeled before growth is calculated?
Common drift traps
- Starting ARR uses live subscriptions while ending ARR uses booked contracts, overstating growth.
- Currency restatement is reported as growth because starting and ending values use different exchange assumptions.
- Imported or acquired revenue enters the ending balance without an exclusion label for organic growth.
Source-system boundary
ARR movement spine
Billing platform, Contracts, CRM, Data warehouse
The governed definition should state ARR variant, comparison window, movement taxonomy, currency rule, and exclusion policy.
Context-layer proof
ClariLayer's context layer should bind ARR Growth Rate to the approved ARR variant, comparison window, movement taxonomy, and exclusion policy so every growth answer can explain what changed and what was reclassified.
- Governed signals
- ARR variant, comparison window, movement taxonomy, exclusion policy
- Review cadence
- Review after ARR definition, acquisition, migration, currency, or revenue-movement changes.
ClariLayer Drift Risk
ARR Growth Rate is high risk because it inherits ARR definition risk and adds comparison-window, movement, and exclusion decisions.
Ambiguity
5/5The rate can mean booked, live, organic, acquisition-inclusive, point-in-time, or movement-derived growth.
Source-system dependency
4/5The metric depends on recurring revenue sources, account hierarchy, currency rules, and movement classification.
Time-window sensitivity
5/5Starting date, ending date, rolling window, and restatement timing can materially change the growth rate.
Governance need
5/5Growth rate informs executive and planning decisions, so comparison and exclusion rules need owner approval.
AI-agent risk
An AI agent can explain ARR growth incorrectly if it cannot see the ARR variant, comparison window, movement taxonomy, and exclusion policy behind the rate.
Sales pipeline
Sales Cycle Length
Sales Cycle Length measures the time between a governed sales start event and a governed close event for opportunities that meet the selected population and outcome criteria.
Governed formula
average(close event date - sales start event date) for governed opportunities
- State whether the population includes won deals only, all closed deals, qualified opportunities, renewals, expansions, or new business.
- Keep start-event and close-event definitions versioned when sales stages or qualification rules change.
Won-deal Sales Cycle
Measures time from start event to close-won for opportunities that become customers or booked expansions.
Useful for sales capacity planning, but it excludes lost deals that consume selling time.
Qualified-to-close Cycle
Starts the clock when an opportunity reaches an approved qualified stage.
Useful for pipeline execution, but qualification criteria must be consistent over time.
Created-to-close Cycle
Starts the clock at opportunity creation and ends when the opportunity closes.
Useful for broad process visibility, but created dates can include unqualified or backfilled deals.
Decisions to lock
Which start event begins the sales cycle clock?
Opportunity created, qualified, accepted, demoed, and proposal dates each describe a different process span.
Which closed outcomes and deal types belong in the population?
Won-only, closed-all, renewal, expansion, and new-business populations produce different operating signals.
How are reopened, duplicated, merged, or backfilled opportunities handled?
Operational cleanup can create extreme cycle lengths unless exception rules are explicit.
Validation questions
- Can each included opportunity show the governed start date, close date, outcome, owner, and deal type?
- Are reopened, duplicate, merged, and backfilled records excluded or labeled consistently?
- Do stage-history changes explain differences between created-to-close and qualified-to-close views?
Common drift traps
- Opportunity created date is used after sellers begin creating placeholder opportunities earlier in the process.
- Closed-lost deals are excluded from one view and included in another under the same average cycle label.
- Reopened opportunities keep the original start date, making sales cycle appear longer than the active pursuit window.
Source-system boundary
Opportunity lifecycle spine
CRM, Spreadsheets, Data warehouse
The governed definition should state start event, close event, outcome population, deal-type filters, and exception handling.
Context-layer proof
ClariLayer's context layer should attach Sales Cycle Length to the approved start event, close event, opportunity population, and exception policy so sales agents can compare cycle trends without mixing process definitions.
- Governed signals
- start event, close event, opportunity population, exception policy
- Review cadence
- Review after sales-stage, qualification, CRM hygiene, or opportunity-management changes.
ClariLayer Drift Risk
Sales Cycle Length is medium risk because date subtraction is simple, but start events and opportunity populations drift with sales process changes.
Ambiguity
4/5The metric can mean created-to-close, qualified-to-close, won-only cycle, or all-closed cycle.
Source-system dependency
3/5The metric primarily depends on CRM opportunity dates, stage history, deal types, and warehouse cleanup rules.
Time-window sensitivity
4/5Close-period filters, reopened dates, and backfilled opportunity history can change averages quickly.
Governance need
4/5Sales cycle informs capacity and pipeline planning, so start-event and population rules need ownership.
AI-agent risk
An AI agent can misread sales efficiency if sales cycle length lacks the start event, close population, deal-type filter, and reopened-opportunity rule.
Sales pipeline
Win Rate
Win Rate measures the share of governed sales opportunities that close won within a selected population, outcome set, and time window.
Governed formula
closed-won opportunities / governed closed opportunity population
- State whether the denominator counts opportunities, revenue amount, accounts, or qualified opportunities.
- Separate new business, expansion, renewal, and self-serve motions unless a governed combined view is approved.
Opportunity-count Win Rate
Counts closed-won opportunities divided by closed opportunities.
Useful for rep and process conversion, but it treats small and large deals equally.
Amount-weighted Win Rate
Uses closed-won amount divided by closed opportunity amount.
Useful for revenue conversion, but it depends on governed opportunity value and currency rules.
Qualified Win Rate
Limits the denominator to opportunities that reached an approved qualified stage.
Useful for sales execution, but qualification rules must be stable and auditable.
Decisions to lock
What is the denominator: all closed opportunities, qualified opportunities, accounts, or amount?
The denominator determines whether the metric describes process conversion or revenue conversion.
Which deal types, sources, territories, and sales motions are included?
Combining renewals, expansion, self-serve, and new business can hide motion-specific conversion signals.
How are no-decisions, duplicates, reopened deals, and disqualified opportunities classified?
Outcome taxonomy changes can move records in or out of the denominator without true performance change.
Validation questions
- Can every numerator and denominator record show close date, outcome, deal type, amount, owner, and stage history?
- Are qualified, all-closed, and amount-weighted win rates labeled separately?
- Are no-decisions, duplicates, reopened deals, and disqualified opportunities classified consistently?
Common drift traps
- Closed-lost and disqualified opportunities are removed from the denominator after a stage-process change.
- Amount-weighted win rate uses opportunity amount that includes services while bookings targets exclude them.
- Renewal and expansion deals are blended with new business, making conversion look healthier than the new-logo motion.
Source-system boundary
Closed opportunity spine
CRM, Data warehouse, Spreadsheets
The governed definition should state outcome taxonomy, denominator grain, deal-type filters, close-period boundary, and value basis.
Context-layer proof
ClariLayer's context layer should bind Win Rate to the approved denominator grain, outcome taxonomy, sales-motion filters, and close-period boundary so conversion analysis stays tied to the intended selling motion.
- Governed signals
- denominator grain, outcome taxonomy, sales-motion filters, close-period boundary
- Review cadence
- Review after sales-stage, disqualification, territory, renewal-motion, or CRM outcome changes.
ClariLayer Drift Risk
Win Rate is high risk because denominator choices, sales-motion filters, and outcome taxonomy can change the signal without changing sales performance.
Ambiguity
5/5Win rate can be count-based, amount-weighted, qualified-only, all-closed, new-business-only, or renewal-inclusive.
Source-system dependency
4/5The metric relies on CRM outcomes, stage history, opportunity amounts, territories, and warehouse filters.
Time-window sensitivity
4/5Close-period boundaries, reopened deals, late outcome edits, and stage changes can shift conversion rates.
Governance need
5/5Win rate guides sales strategy and coaching, so outcome and denominator rules need explicit owner approval.
AI-agent risk
An AI agent can recommend sales coaching from the wrong conversion signal if win rate lacks denominator grain, outcome taxonomy, and sales-motion filters.
Sales pipeline
Forecast Accuracy
Forecast Accuracy measures how closely a governed forecast value matches the governed actual result for the same period, scope, currency, and business outcome.
Governed formula
1 - absolute(forecast value - actual value) / actual value
- State the forecast snapshot time, forecast category, actual result definition, and whether accuracy is absolute or signed.
- Use the same period, segment, currency, and revenue or bookings basis for forecast and actual values.
Commit Forecast Accuracy
Compares commit forecast at a governed snapshot time with actual closed results.
Useful for sales execution reviews, but commit category rules must be stable.
Pipeline Forecast Accuracy
Compares a pipeline-derived forecast or weighted pipeline value with actual results.
Useful for model review, but it depends on approved weighting and eligibility rules.
Signed Forecast Variance
Reports over-forecast and under-forecast direction instead of only absolute accuracy.
Useful for bias detection, but it must not be mixed with absolute accuracy under one label.
Decisions to lock
Which forecast snapshot time and forecast category define the numerator?
A week-one commit forecast and final-week forecast answer different discipline questions.
Which actual result does the forecast reconcile against?
Bookings, ARR, revenue, closed-won amount, and invoiced value can all differ for the same period.
Is the metric absolute accuracy, signed variance, or weighted error?
Direction and magnitude tell different stories and should not share one field.
Validation questions
- Can the forecast snapshot be reproduced with the exact timestamp, scope, owner, and category rules?
- Does the actual result use the same period, segment, currency, and bookings or revenue basis as the forecast?
- Are absolute accuracy, signed variance, and weighted error labeled as different metrics?
Common drift traps
- Forecast values are updated after the snapshot point, making past accuracy look better than the governed forecast at the time.
- The forecast is measured against bookings while the actual uses recognized revenue or invoiced amount.
- Over-forecast and under-forecast errors are netted together, hiding directional bias in the forecast process.
Source-system boundary
Forecast reconciliation spine
CRM, Spreadsheets, ERP, Data warehouse
The governed definition should state snapshot timing, forecast category, actual-result basis, scope, currency, and variance method.
Context-layer proof
ClariLayer's context layer should bind Forecast Accuracy to snapshot timestamp, forecast category, actual-result basis, and variance method so forecast agents can explain whether misses came from timing, scope, or definition changes.
- Governed signals
- snapshot timestamp, forecast category, actual-result basis, variance method
- Review cadence
- Review after forecast-category, close-process, territory, target, or finance-reconciliation changes.
ClariLayer Drift Risk
Forecast Accuracy is high risk because it joins mutable forecast snapshots with actual-result definitions that can differ across sales and finance.
Ambiguity
5/5The metric can mean commit accuracy, pipeline accuracy, signed variance, absolute error, or weighted forecast error.
Source-system dependency
5/5The calculation depends on CRM forecast snapshots, spreadsheet overlays, finance actuals, currency, and warehouse reconciliation.
Time-window sensitivity
5/5Snapshot timing, close timing, late updates, and fiscal-period boundaries can all change measured accuracy.
Governance need
5/5Forecast accuracy drives executive trust and sales process reviews, so snapshot and actual-result rules need approval.
AI-agent risk
An AI agent can assign forecast blame incorrectly if it cannot see snapshot timing, forecast category, actual-result basis, and variance method.