Usage-Based Pricing Analytics: What SaaS Must Track

Monthly Recurring Revenue is a clean, predictable number in a seat-based SaaS model. It is a misleading one in a consumption model. When revenue rises and falls with usage volume, MRR tells you what happened last month but gives you almost no signal about what will happen next month. A customer who generated $4,000 in usage in March and $1,200 in April has not necessarily churned — their project ended. A customer who grew from $200 to $3,800 in the same period has not necessarily converted to enterprise — they ran a large batch. Standard SaaS dashboards, built for recurring seat revenue, produce false alarms and missed signals in equal measure when layered on top of consumption data.

The 2026 shift is material. According to Alguna's 2026 SaaS pricing analysis, approximately 74% of suppliers have adopted usage-based or hybrid models, with AI products accelerating the trend sharply upward. Token pricing, API-call metering, and agent-action billing are now mainstream in the SaaS stack, and the analytics infrastructure that served seat-based businesses is due for a rebuild. This post covers the instrumentation and metrics that actually work in a consumption model.

Why seat-based analytics metrics mislead under consumption pricing

The core problem is that seat-based SaaS metrics are built on the assumption of predictability. MRR works because a $500/seat/month customer generates $500 this month, $500 next month, and the only events that change the number are expansion (more seats) or contraction (fewer seats). Churn is binary — a customer either renews or does not. This predictability is what makes MRR useful as a north star.

Consumption pricing breaks every one of those assumptions. Revenue is a function of two variables — price per unit and units consumed — and the second variable fluctuates. A customer's monthly consumption can swing 50% based on project cycles, team activity, or seasonal patterns that have nothing to do with their satisfaction with the product. Treating a slow consumption month as a retention risk — the reflex in a seat-based model — leads to false churn alarms and misallocated CS attention. Treating a high consumption month as organic expansion — equally natural in a seat-based model — misses the distinction between a one-time spike and genuine account growth. The NRR analytics framework needs to be rebuilt on usage cohorts, not renewal windows.

The usage events your product needs to emit

Instrumentation for consumption pricing operates at three layers. The first is the billable unit event — one event per unit of the thing you bill on. For an LLM product, this is a token batch. For a data pipeline tool, a record processed. For a communication API, a message sent. The billable unit event must carry: a stable customer identifier, a timestamp, the quantity of units consumed, and any properties needed to split by customer segment or product feature. This is the event your billing system reads; it is also the raw data for all downstream analytics.

The second layer is the workflow event — a higher-level event that groups billable units into the context that produced them. A "report.generated" event on a data analytics product might aggregate 4,200 tokens of LLM usage and 1.3 GB of data scanned. A "batch.completed" event on a document processing tool groups 800 pages of OCR. Workflow events are essential because they are the unit customers understand. A customer can reason about how many reports they generate per week; they cannot reason about 4.2 million tokens per month. Your internal analytics should connect the two — consumption per workflow, and workflows per customer per period — so you understand which product features are driving the most usage and whether that usage is correlated with high-value activities or waste.

The third layer is the customer-facing usage summary — aggregated daily and monthly totals per customer, surfaced inside the product. This is not just a billing transparency feature; it is a retention instrument. Customers who can see their usage trajectory, projected costs, and per-workflow breakdown are far less likely to experience bill shock and far more likely to make conscious decisions about increasing or constraining their usage. The event taxonomy design for consumption products follows the same outcome-oriented principles as any SaaS schema — instrument what the customer did and what it cost, not just that they interacted with the product.

Replacing MRR: the metrics that matter in a consumption model

Monthly Consumption Revenue (MCR) is the actual sum of billed usage in a calendar month per customer and in aggregate. Unlike MRR, it is not forward-looking — it is the realized figure, known at the end of the month. If your product has contracted minimums, those constitute a true recurring floor; consumption above the floor is variable revenue. Track both components separately. The floor is your MRR analogue — predictable and tied to contract renewal. The variable component is where you measure growth.

Consumption NRR (Net Revenue Retention measured on usage cohorts) is the core health metric for a UBP SaaS business. The calculation is the same as seat-based NRR — starting-period revenue minus contraction, plus expansion, divided by starting-period revenue — but applied to consumption revenue over a rolling monthly window per customer cohort. A consumption NRR above 120% means the average customer in a cohort is consuming 20% more than they did at the cohort start date, which is strong organic growth. Below 100% means the average customer is consuming less over time — a structural concern regardless of whether any individual customer has formally churned.

Drivetrain's guide to SaaS performance metrics for usage-based models notes that "consumption or usage-based SaaS models require metrics that seat-based SaaS never needed, and traditional metrics like seat count and logo churn miss the nuances of usage-driven revenue." Monthly Active Usage Units — the count of distinct customers who consumed above a meaningful threshold in the month — functions as the leading indicator before billing closes. It is the equivalent of weekly active users for consumption revenue.

How to measure expansion and contraction in real time

In a seat-based model, expansion and contraction are discrete events — an upsell closes, a downgrade ticket is submitted. In a consumption model, expansion and contraction happen continuously and are only visible in the usage data if you instrument it correctly. The practical approach is to compute a rolling usage trend per customer: compare this month's consumption to the average of the prior three months. Customers trending above their average are expansion candidates; customers trending below are contraction or churn risks. The threshold that distinguishes signal from noise depends on the natural variance of your product — a tool that serves project-based work will have higher monthly variance than one serving steady-state operations.

Customer Success teams in consumption models should work from this trend signal rather than from renewal dates. A customer at 60% of their prior- quarter consumption pace is worth a proactive conversation this month, not three months from now when the contract renewal arrives. The predictive churn analytics framework translates naturally to consumption data: usage trajectory is the leading indicator, and a sufficiently long sustained decline is the predictive signal. Build this as a weekly automated report, not a monthly manual pull, because the intervention window in consumption models is shorter than in annual-seat models.

Preventing bill shock with usage visibility

Bill shock — a customer receiving an invoice significantly larger than they expected — is the single fastest trust-destroyer in consumption pricing. Lago's 2026 analysis of usage-based pricing tactics notes that "bill shock is the fastest way to lose trust and trigger churn in a consumption model." The instrumentation requirement to prevent it is that your usage metering data must flow to customer-facing UI, not just to your billing system.

At minimum, customers need three things: a live or near-live usage counter (not a number that updates once a day), a projected cost for the current billing cycle based on their usage pace, and configurable alerts when consumption approaches user-defined thresholds. These are not nice-to-have features; they are the UI layer that makes the pricing model trustworthy. Customers who can see that they have used 80% of their typical monthly budget by day 18 can decide whether to throttle usage, change their workflows, or accept the overage — an informed decision. Customers who cannot see this receive an invoice that feels unfair, even when the billing is correct.

The analytics instrumentation that enables customer-facing usage visibility is the same metering data you use internally. The engineering work is in making aggregations fast enough to query in real time. Time-series aggregation by customer ID, bucketed by day, is the standard approach: it allows you to show daily consumption histograms, cumulative monthly totals, and projected end-of-month cost with a single query per customer session.

The analytics stack for usage-based SaaS

Standard product analytics tools — Mixpanel, Amplitude, PostHog — work well for the workflow event layer but are not designed for high-frequency billable unit events. If you bill on API calls and a single customer generates 10 million calls per month, event-level ingestion into a product analytics platform becomes expensive and the per-event data model is the wrong granularity for billing analytics anyway. The right architecture separates concerns: a metering system (Lago, Stripe Billing, Orb, or a custom pipeline) handles billable unit aggregation and billing logic; a product analytics tool handles workflow events and user behaviour; a warehouse (BigQuery, Snowflake) joins the two for cohort analysis and NRR calculation.

The analytics stack by ARR stage guide covers the full instrumentation sequencing. For UBP-specific additions, the minimum viable stack is: a metering API that emits aggregated daily usage per customer to your data warehouse, a billing system that reads from the warehouse or metering API, and a dashboard per customer that queries the warehouse directly. The product analytics tool sits on top of workflow events and augments the picture with behavioural context — which workflows drove the most usage, which user roles consume the most, and how usage correlates with the outcomes customers care about. Without that behavioural layer, consumption data tells you what was billed but not why usage trended the way it did.

What to build first

If you are moving from seat-based to consumption pricing, or shipping a consumption tier alongside existing plans, the instrumentation priority order is: metering accuracy first (billable unit events must be reliable and auditable before anything else — a disputed invoice is worse than no invoice), customer-facing usage visibility second (prevent bill shock before it happens), and analytics cohorts third (consumption NRR, usage trend by customer, and workflow attribution). The dashboards that serve your CS and finance teams follow from the same metering data; they are a reporting layer, not a separate instrumentation effort.

The decision-first analytics framework applies here directly: start with the question you need to answer ("is this customer expanding or contracting?") and work back to the event that answers it. In a consumption model, the answer almost always starts with the metering data — the rest of the analytics stack is interpretation built on top of that foundation.