Last updated: October 2026
Usage based pricing is the decision to charge customers in proportion to what they actually consume, not what they might use, not how many seats are on their contract, not a flat monthly fee regardless of activity. By the end of this page, you’ll be able to decide whether consumption-based pricing belongs in your offer structure, pick the right unit to charge on, and avoid the implementation traps that turn a smart pricing decision into a churn and forecasting problem.
The idea is older than software. Your electric bill has worked this way for over a century. So has the taxicab meter, the long-distance phone call, the per-pound deli counter. What changed is that digital products, APIs, cloud compute, messaging platforms, AI inference, finally made fine-grained metering cheap enough that any operator with the right infrastructure can charge the same way.
What hasn’t changed is the underlying logic: when the unit of price matches the unit of value, both sides feel like the deal is fair. That fairness feeling, compounded across thousands of customers who grow at different rates, is what makes usage-based pricing one of the most powerful revenue-architecture decisions an operator can make, and one of the most misunderstood.
The idea in 30 seconds
- Usage-based pricing (UBP) charges customers for the quantity of value they consume, API calls, messages sent, gigabytes stored, transactions processed, rather than a fixed seat or subscription fee.
- The model works best when there’s a clear, measurable unit of output that scales naturally with the value a customer receives.
- UBP companies post a median NRR of 108% versus 98% for seat-based companies, a structural ten-point gap that compounds over time (Benchmarkit 2026, N=342, full-year 2025 data).
- The biggest risks are revenue unpredictability for you and bill shock for your customers; hybrid models, a base fee plus usage, solve for both.
- The single most important decision is picking the right value metric. Everything else follows from that choice.
- Not every business fits this model. If throttling usage reduces the value a customer gets, UBP works. If it doesn’t, consider another structure.
Where Usage-Based Pricing Came From
Software pricing before cloud was mostly a one-time license. SaaS moved everyone to subscriptions in the late ’90s and early 2000s, lower upfront cost, predictable revenue, ongoing relationship. The seat became the unit of price. It stuck because it was simple, not because it was right.
The problem is that seats measure access, not value. A company with 50 Salesforce seats and 12 active users was still paying for 50. That math bothered CFOs enough to become a real purchasing objection. AWS changed the frame in 2006, no upfront commitment, pay only for what you consume, and Twilio and Stripe followed in the 2008 to 2010 window, billing per SMS, per voice minute, per transaction. All three picked their metric for the same practical reason: their own costs scaled with consumption, so the pricing had to match.
By the time OpenView Partners started tracking adoption in 2021, usage-based models had already moved from infrastructure into application software. Today the shift is accelerating because of AI: when software agents complete work independently, seat count stops being a proxy for value at all. Hybrid models, a base fee plus metered usage, now account for the majority of the market. This isn’t a category still testing the idea. It’s in real contracts, real dashboards, and real board conversations.
The Core Logic: Value Metrics and Why They’re Everything
Every usage-based model rests on one decision above all others: what is the unit you’re charging for? This is your value metric, and everything else in your pricing follows from it.
A good value metric does three things simultaneously. It scales with the value the customer receives, so that paying more feels like getting more, not just consuming more. It’s something the customer can understand and predict. And it maps closely enough to your own costs that your margins hold as volume grows. Miss any one of those, and the model turns adversarial.
Twilio gets this right. Every SMS sent is a direct action the customer chose to take and presumably benefited from. There’s no ambiguity between usage and value. That clarity is the goal, when a customer looks at an invoice and immediately understands why the number is what it is, you’ve chosen the right metric.
A useful gut check: if you need more than one sentence to explain the billing unit to a new customer, the metric is probably wrong.
Most metrics fall into four categories: time (duration of use), transaction (discrete events like API calls), volume (amount of data, e.g. GB), and count (number of connected devices or agent actions completed). The right one depends on what customers actually care about, not what’s easiest to track on your side. Those two things are often different.
A real example: one SaaS vendor focused on frontline worker safety shifted from per-user pricing to the number of times workers used the app for a safety workflow. Same product, different metric. The buyer conversation changed immediately because the new unit mapped directly to value delivered rather than access granted.
One nuance that catches operators: your metric should be something the customer controls through deliberate choices, not something that accumulates from your system’s behavior. If the number goes up because your platform ran a background job, you’ve created a billing event the customer didn’t choose, and surprise bills from opaque system events are the fastest path to churn in this model.
Why the Numbers Are Compelling
The case for usage-based pricing doesn’t rest on philosophy. It rests on what happens to the revenue curve when you adopt it.
The central mechanism is expansion without a sales motion. In a seat-based model, a customer who grows from 10 to 50 users generates more revenue only if someone calls them and closes an upsell. In a usage-based model, that growth shows up automatically on the next invoice.
The retention numbers are hard to argue with. Usage-based companies post a median NRR of 108% versus 98% for seat-based, a 10-point structural gap, per the 2026 Aleph × Benchmarkit SaaS & AI Performance Benchmarks (N=342, full-year 2025 data). To put that plainly: usage-based companies clear the break-even bar by 8 points while seat-based companies sit below it at 98%. Seat-based companies are already shrinking their existing customer revenue before accounting for new logos. Usage-based companies are growing inside existing accounts without a sales call. Those are different businesses over a five-year horizon.
At the top end, Snowflake reported full-year product revenue of $4.47 billion for fiscal year 2026 and an NRR of 125% as of January 31, 2026. Datadog’s trailing 12-month dollar-based net retention rate was about 120% as of December 31, 2025, on FY2025 revenue of $3.427 billion. Both price on consumption. In both cases, revenue scales with the customer’s own growth, though the same mechanism that creates upside also contracts automatically when customers optimize spend or hit a slow quarter.
That last part matters. When a customer cuts usage, because their business slows, because they get more efficient, because a competitor undercuts on unit price, revenue contracts without a cancellation conversation. This isn’t a flaw. It’s the honest trade. You’re selling fairness, not stickiness. The question is whether your product is good enough that usage trends upward over time.
Stripe’s per-transaction model is the ideal expression: revenue grew as customers processed more payments, creating natural expansion without a sales motion. The product is so embedded in the customer’s success that revenue growth is a byproduct of the customer succeeding, not of a quarterly business review.
The Main Variants of Usage-Based Pricing
Usage-based pricing isn’t one thing. It’s a family of structures, and the differences matter when you’re deciding which fits your business.
Pure Pay-As-You-Go
No base fee, no commitment, charge only for what’s consumed. AWS is the canonical example: a small startup running lightweight workloads might pay $12/month; a company processing petabytes pays millions. The advantage is a near-zero barrier to entry. The disadvantage is maximum revenue variability for you and maximum bill unpredictability for your customer. AWS cost management being a $3B+ third-party industry is not a coincidence, it’s the market pricing the opacity of pure pay-as-you-go at scale.
Per-Unit (Event-Based)
Charge a fixed price per discrete event, per SMS, per API call, per email sent, per transaction processed. Twilio and Stripe both live here. The unit price is simple and predictable; the total bill varies only with volume, which the customer controls. This is the easiest variant to sell because customers can run the math before committing.
Credit-Based
Customers buy a block of credits upfront, then spend them as they use the product. OpenAI’s token system and many AI platforms work this way. It combines subscription predictability with usage flexibility: customers know their upfront cost, avoiding surprise bills, while vendors secure recurring revenue. The downside is cognitive load, credits as currency add abstraction that some customers find opaque.
Percentage of Value (Outcome-Based)
Instead of charging per unit consumed, you take a percentage of the economic outcome your product enables. Stripe charges 2.9% + $0.30 per transaction. Shopify charges a revenue percentage on sales. This is arguably the purest expression of value alignment, you only win when the customer wins, but it requires that value be directly measurable in dollar terms, which limits where it applies.
Hybrid: Base + Usage
Most operators end up here. A fixed base fee creates a revenue floor and signals commitment; usage charges on top let the relationship scale. HubSpot prices its marketing suite by contacts (usage-based) but its sales automation by seat. Datadog charges by host and log ingestion volume on top of a platform fee. According to Maxio’s 2025 SaaS Pricing Trends Report, based on Benchmarkit survey data from 316 SaaS companies, companies using hybrid pricing (subscription + usage) reported the highest median growth rate in the sample, at 21%, outperforming both pure subscription and pure usage-based models.
For most small and mid-size operators, hybrid is the safest starting point. You get the expansion flywheel without the forecasting whiplash of pure pay-as-you-go.
Putting this to work? The ideas in the Canon are the foundation under the tactical playbook in Build a Complete Marketing Department — grab the free companion kit at mmsvegas.com/resources.
Real Companies, Real Metrics, What Usage-Based Pricing Looks Like in Practice
The best way to understand the model is to see the specific choices real operators made and why those choices hold together.
AWS charges per second of EC2 compute, per GB of S3 storage, per GB of data transfer out. The genius wasn’t just the model, it was the metering infrastructure underneath it. Every service tracks usage at a granular level, and customers get dashboards showing exactly what’s accumulating. That visibility is what makes the unpredictability tolerable.
Twilio charges per SMS, per voice minute, per email sent, per phone number provisioned, with no seats and no base fee. Pure event-based billing. Every charge maps to an action the customer deliberately chose to take.
Stripe takes 2.9% + $0.30 per transaction. If you process a $100 payment, Stripe takes $3.20. Process nothing, pay nothing. This is the outcome-based variant, revenue is literally tied to the customer’s own revenue. The alignment is complete.
Snowflake runs a two-axis model: compute usage and data storage. The charge for computing is based on credits consumed, with the rate varying by edition, standard, enterprise, or business-critical. Layering a quality tier on top of a consumption model is an elegant way to preserve enterprise pricing leverage while keeping the usage-based structure. Snowflake closed FY2026 with product revenue of $4.47 billion and an NRR of 125%, with growth driven primarily by increased consumption from existing customers. Their answer to bill shock was query budgets and resource monitors shipped alongside the pricing, a lesson every operator building on this model should take seriously.
Brevo (formerly Sendinblue) shows how hybrid works at the small-business scale: it charges a subscription for features and prices email sends by volume tier above the plan’s included allocation, free at 300 emails/day, starter from $9/month for 5,000 emails/month. As your list grows and you send more, you pay more, and the revenue relationship deepens without a sales call.
Blacksmitha CI/CD infrastructure provider, shows that usage-based pricing doesn’t require a massive company. They built usage-based billing for CI/CD infrastructure, a category where seat pricing makes no sense (two engineers can generate radically different CI load) and where value delivered is directly proportional to time saved on builds. The model scales down as well as up, as long as the value metric is honest.
Where Usage-Based Pricing Works, and How to Tell
A practical test for whether usage-based pricing fits your product: if a customer throttles their usage, uses the product less, does the value they receive go down proportionally? If yes, you probably have a usage-based pricing candidate. If no, you may not.
Twilio is a clean example. If a company sends fewer SMS messages, they get less communication delivered. Less value, less cost. Linear and obvious. That lower commitment is only a problem if the product doesn’t stand on its own merits; for Twilio, it’s a feature, because it removes the objection to getting started.
Usage-based pricing tends to work well in these situations:
- Variable usage patterns. Customers whose demand swings seasonally, or who are in early growth and don’t know what they’ll need. The flexibility is valuable precisely when a customer can’t predict their own trajectory.
- High cost-of-goods that scale with consumption. Cloud infrastructure providers like AWS, Snowflake, Datadog, and MongoDB all incur direct costs when their platform is used. Fixed revenues against variable costs is a fast way out of business, so the pricing has to match the cost structure.
- AI-intensive products. ICONIQ Capital’s 2026 State of AI: Bi-Annual Snapshot reports that AI-native products are projected to average roughly 52% gross margins in 2026, up from 45% in 2025, still 23 to 33 percentage points below traditional SaaS, with inference cost as the primary culprit. Flat pricing on a compute-intensive product makes that gap worse, not better.
- Developer or API-centric products. Developers are culturally comfortable with pay-as-you-go; they’ve been using it with AWS, Twilio, and Stripe for years. Asking for a seat license feels odd in that context.
- Products that embed in the customer’s revenue-generating workflow. When your tool is part of how a customer generates revenue, tying your price to that output aligns your success with theirs, and makes the value legible.
- Land-and-expand motions. UBP lets more users access a product within an account, making the software more ubiquitous and seeding new use cases without requiring a formal upsell conversation.
The flip side of the throttle test: if reducing usage doesn’t reduce value, if the product’s core benefit is availability rather than consumption, you need a different structure. A password manager is worth the same whether you access it once a week or fifty times a day. The product’s job is to exist and be accessible; the value isn’t in the act of use.
Where Usage-Based Pricing Doesn’t Work
The fact that Snowflake and Twilio built their entire businesses on consumption-based pricing doesn’t mean it’s the right structure for every product. There are real categories where usage-based pricing creates more problems than it solves.
When usage is unpredictable and not in the customer’s control. If a customer’s bill spikes because your platform processed a data job that ran longer than expected, that’s your problem, not theirs, even if it technically counts as their usage. Bill shock from events the customer didn’t choose destroys trust faster than almost any other event in a customer relationship.
When the product’s value is in access, not consumption. Collaboration tools, where the benefit is availability, being able to reach a colleague, having the document exist, don’t benefit from usage pricing. Charging Slack users per message sent would be perverse. Seat pricing is the right answer for that benefit structure.
When your customer base can’t handle variable invoices. Enterprise procurement teams and government buyers often work from fixed budgets. A variable monthly invoice, even if it averages lower than a fixed subscription, creates headaches in their procurement systems. In enterprise sales into regulated industries, a predictable number is sometimes worth more than a lower average.
When your metering infrastructure isn’t ready. Usage-based pricing requires that you can measure consumption accurately, in near real time, at the customer level, and translate it into invoices without manual error. Revenue, cash flow, and capacity forecasting all get harder. If your billing stack can’t do that today, the model will create operational problems that undermine the customer experience you’re trying to build.
When you’re an early-stage operator trying to survive the next six months. Revenue unpredictability is a real cost. For an operator with 12 months of runway who needs to hit a number, the variance introduced by pure usage-based billing is risk you should understand clearly before taking it on. Get the product right first. Get customers paying something predictable. Then redesign pricing around real usage data.
Common Misunderstandings About Usage-Based Pricing
“Usage-based pricing means pure pay-as-you-go.” Not quite. Pure pay-as-you-go is one variant, and not the most common one. According to OpenView Partners’ 2023 State of Usage-Based Pricing report, 46% of SaaS companies take a hybrid approach, bundling usage within seat plans or layering usage fees on top of a subscription, versus only 15% running a largely pure pay-as-you-go model. A hybrid base fee plus metered use is both more common and usually more practical for operators outside the infrastructure layer.
“It always increases revenue.” The expansion mechanism is real, but so is the contraction mechanism. A customer who gets more efficient with your product, who figures out how to send fewer API calls to accomplish the same task, will pay you less. That’s the deal. If your product keeps delivering value, usage trends up. If it doesn’t, the model makes that visible faster than a subscription would.
“The metric is just a billing detail.” The metric is the strategy. It needs to track value closely enough that customers accept it as fair, and it needs to map to your infrastructure costs closely enough that your margins stay intact as volume grows. Getting this wrong doesn’t just create friction in billing, it shapes how prospects perceive value before they buy.
“You need to get the metric right the first time.” You don’t. That said, changing a billable metric after customers have built workflows around it is genuinely disruptive, the customer who signed up paying per API call and now gets told they’ll pay per active user has a legitimate complaint. Set a review cadence and monitor usage patterns, but do the hard work upfront to get as close as you can before launch.
“Usage-based pricing is inherently less predictable.” For pure pay-as-you-go, that’s partially true. But the hybrid structure gives you a known revenue floor with upside that tracks customer success. And over time, as you accumulate usage history, cohort-level consumption patterns get remarkably predictable, the first 6 to 12 months are the hardest.
Common Mistakes
- Picking a metric that’s easy to measure but disconnected from value, and not finding out until renewal — Map your candidate metric against actual customer outcomes before configuring anything in billing. Does a higher number on that metric reliably mean a better result for the customer? Run it by three current customers. Ask them what number they’d use to tell whether your product is working. If their answer and your metric are different things, yours is wrong. Page views, server requests, and raw data volume are all easy to capture but often disconnected from value, which means you spend more time explaining invoices than renewing accounts. Pick the metric your best customers would recognize as fair, not the one your data pipeline already emits cleanly.
- Launching usage-based pricing before your event data is clean enough to bill from — The most common implementation failure isn’t a pricing strategy problem, it’s a data problem. The team defines pricing, configures billing rules, then discovers the usage data coming out of the product is too messy to rate reliably: events arrive out of order, duplicates appear, fields are missing. Before you configure billing rules, solve the data problem. Capture at minimum a customer identifier, timestamp, metric type, and quantity on every event. Run a deduplication and reconciliation pass against your infrastructure provider’s invoice before going live. If your event data can’t be reconciled cleanly today, fix that first.
- Not building spending controls before the first invoice goes out — Spend caps, in-product usage dashboards, and automated alerts at 70% and 90% of a threshold aren’t optional niceties, they’re the difference between a customer who trusts your pricing and one who calls you angry. Snowflake had to build query budgets and resource monitors because customers couldn’t manage spend on pure consumption billing without them. Build visibility into the customer experience before it becomes a billing event, not after. Launch the controls at the same time as the pricing change. The first surprise invoice you send is the last time that customer trusts your model.
- Under-instrumenting event data at launch and having to rebuild the pipeline every time pricing evolves — Teams typically capture what they need for billing today without considering what a pricing iteration will require. Adding a new dimension, say, differentiating standard from premium API calls, requires that distinction to already exist in the event data. If it doesn’t, you’re rebuilding instrumentation from scratch. Capture more granularity than you think you need from day one: customer ID, timestamp, metric type, quantity, feature line, and at least one quality or tier dimension. The extra fields cost almost nothing to emit. Rebuilding the event pipeline six months later, while customers are already live on the billing model, costs a lot.
- Treating the first metric as permanent because changing it feels risky, then never updating it even when the data says it’s wrong — It is risky to change a billable metric after customers have built integrations around it, the customer who signed up paying per API call and gets repriced to per active user has a legitimate complaint. But refusing to fix a metric that’s clearly wrong is riskier. The answer isn’t to freeze the metric; it’s to set a structured six-month review from day one, comparing the metric against actual customer value data. When the data says the metric is off, iterate with advance notice and clear rationale, not reactively when it’s become an obvious billing complaint. Customers can handle pricing evolution if they get fair warning and a real explanation.
Operator’s Take
When an operator brings usage-based pricing to me, I’m not really thinking about whether to adopt it. I’m thinking about the two places where I’ve watched operators get it wrong consistently, and what to actually do about each one.
First: pin down the metric before you touch billing infrastructure. Most operators pick something measurable rather than something meaningful. Measurable is easy, you can count API calls, logins, records processed. Meaningful is harder. It’s the unit that, when the number goes up, the customer is clearly getting more of what they came for. The fastest field test: ask your three best customers what number they’d use to evaluate whether your product is working. Their answer is almost always closer to the right metric than whatever you were originally considering. If you need more than one sentence to explain the billing unit to a new prospect, keep looking. Don’t configure a single billing rule until you’ve run that conversation with at least three real accounts.
Second: don’t eliminate the base fee. Operators who go fully pay-as-you-go in the name of removing friction tend to end up with lower average contract values, harder forecasting, and customers who feel no commitment and leave at the first inconvenience. Maxio’s 2025 SaaS Pricing Trends Report, based on Benchmarkit data from 316 companies, found hybrid pricing (subscription + usage) reported the highest median growth rate at 21%, ahead of both pure subscription and pure usage-based models. A base fee isn’t a contradiction of the usage-based model. It’s what makes the model operationally sustainable. Set your base fee to cover your fixed costs per account at minimum; let the usage layer be pure upside.
Third: audit your AI cost exposure before touching pricing infrastructure. ICONIQ Capital’s 2026 State of AI: Bi-Annual Snapshot reports that AI-native products are projected to average roughly 52% gross margins in 2026, up from 45% in 2025, but still 23 to 33 percentage points below traditional SaaS, with inference cost as the primary driver. If you have LLM inference anywhere in your product and you’re on flat or seat pricing, calculate your cost per active account at different usage levels right now. Absorbing inference costs into a fixed seat fee isn’t a pricing philosophy, it’s a P&L problem you’re choosing to make permanent. Usage-based or hybrid pricing is one of the few structural levers that protects your unit economics while keeping the product accessible at low volume.
Fourth: build spending controls before the first invoice goes out, not after. Real-time usage dashboards, automated alerts at 70% and 90% of a usage threshold, and customer-controlled spend caps aren’t polish items. They’re what separates a customer who trusts your pricing from one who calls you angry. Snowflake had to build query budgets and resource monitors because customers couldn’t manage spend on pure consumption billing without them. Don’t ship the pricing change without shipping the controls alongside it. The first surprise invoice you send is the last time that customer trusts your model.
Fifth: instrument your event data at more granularity than you think you need today. Adding a new pricing dimension later, say, differentiating standard from premium API calls, requires that distinction to already exist in your event stream. If it doesn’t, you’re rebuilding instrumentation from scratch while customers are already live on the billing model. Capture customer ID, timestamp, metric type, quantity, feature line, and at least one quality or tier dimension from day one. The extra fields cost almost nothing to emit. Rebuilding the pipeline six months later costs a lot.
On the agent monetization angle: when an AI agent resolves a ticket, drafts a response, or executes a workflow independently, charging per human login makes no sense to the person writing the check. Intercom’s Fin charges $0.99 per resolved ticket. That’s outcome-based pricing, and it’s where agent monetization is heading. If you sell anything that runs autonomously on behalf of a customer, the per-seat conversation is going to get uncomfortable sooner than your next pricing review cycle.
One honest caveat underneath all of this: don’t redesign pricing before you have real usage data. Get a handful of customers paying something predictable, watch what they actually consume, then build the model around what you observe, not around what you expect.
Used in
- ✓ Build a Complete Marketing Department
Used to frame how pricing architecture communicates value in your offer, specifically, how aligning the unit of price to the unit of value sharpens positioning and improves conversion from prospect to first payment. - ✓ The Missing Manual for FunnelKit
Used to structure order bump and upsell logic around consumption thresholds, triggering upgrade offers at usage limits rather than on time or seat count. - ✓ The Missing Manual for Make
Used to automate metered billing workflows, tracking consumption events, triggering overage alerts to customers, and syncing usage data to billing platforms without manual intervention.
FAQ
What’s the difference between usage-based pricing and subscription pricing?
Subscription pricing charges a fixed fee for a period regardless of how much the customer uses the product. Usage-based pricing charges in proportion to actual consumption. Subscriptions favor the vendor when usage is high and the customer when usage is low; usage-based models distribute that risk more evenly and align revenue with value delivered.
Do I need to eliminate my subscription fee to use usage-based pricing?
No, and most operators shouldn’t. The hybrid model (a base subscription fee plus usage-based charges above a threshold) is the most common and most practical structure. The base fee creates revenue predictability and signals commitment; the usage layer creates expansion revenue as customers grow.
How do I pick the right value metric?
Start by asking: when the customer uses the product more, do they get more of what they came for? If yes, that unit of ‘more’ is likely your metric. It should be something the customer controls, can predict, and immediately recognizes as fair. Then cross-check it against your own cost structure, the metric should also correlate with your variable costs so margins hold at scale. A quick field test: if you can’t explain the billing unit in one sentence, keep looking.
Is usage-based pricing right for a small business that isn’t a SaaS company?
Potentially, yes. Any service business where output is measurable and variable can apply this logic, a marketing agency billing per deliverable, a bookkeeper billing per transaction, a consultancy billing per hour are all usage-based models. The key question is whether your costs scale with output and whether customers perceive fairness in paying for consumption rather than access.
How do I prevent bill shock from damaging customer relationships?
Build usage visibility into the customer experience before it becomes a billing event. Real-time dashboards, automated alerts at 70% and 90% of a usage threshold, and spending caps customers can set themselves are the standard tools. AWS, despite being the canonical usage-based company, has built an entire cost management suite for exactly this reason, the controls are part of the model, not an afterthought.
Will switching to usage-based pricing hurt my revenue predictability?
Pure pay-as-you-go does reduce predictability; a hybrid model mitigates most of that. Over time, as you accumulate usage history, forecasting becomes more accurate because customer consumption tends to follow predictable patterns. The first 6 to 12 months after a switch are the hardest; after that, cohort-level usage data makes forecasting much more tractable.
Does usage-based pricing still make sense if my product uses AI?
It’s more urgent, not less. ICONIQ Capital’s 2026 State of AI: Bi-Annual Snapshot reports that AI-native products are projected to average roughly 52% gross margins in 2026, up from 45% in 2025, but still 23 to 33 points below traditional SaaS, and inference cost is the primary driver of that gap. Absorbing inference costs under a fixed seat fee is how operators make that margin gap permanent. Usage-based or hybrid pricing protects your unit economics while keeping the product accessible at low volume.
Further reading
- Metronome, State of Usage-Based Pricing 2025: Survey of 100 SaaS companies on adoption rates, implementation timelines, and operational challenges. Free at metronome.com.
- Monetizing Innovation by Madhavan Ramanujam and Georg Tacke: The clearest thinking available on how to choose a pricing metric that customers will accept as fair, relevant far beyond usage-based contexts.
- Lago (getlago.com), Usage-Based Pricing Implementation Playbook: Practical, technically honest guide to metering architecture, charge metric selection, and billing infrastructure for operators actually building the model.
- BillingPlatform, Best Practices for Usage-Based Billing Implementation: Covers the data-quality problem in detail, event ordering, deduplication, instrumentation granularity, for operators building metering from scratch.
- ICONIQ Capital, State of AI: Bi-Annual Snapshot (January 2026): The primary source for AI-native gross margin data and inference cost benchmarks cited throughout this page.
Sources: 2026 Aleph × Benchmarkit SaaS & AI Performance Benchmarks (N=342, full-year 2025 data); Benchmarkit 2026 B2B SaaS & AI-Native Metrics Report; Snowflake SEC filings, FY2026 Q4 8-K (product revenue $1.23B Q4, NRR 125% as of Jan 31, 2026); Snowflake FY2026 full-year product revenue $4.47B; Snowflake Q3 FY2026 8-K (product revenue $1.16B, NRR 125% as of Oct 31, 2025); Snowflake Q1 FY2027 8-K (NRR 126% as of Apr 30, 2026); Datadog FY2025 10-K (trailing 12-month dollar-based NRR ~120% as of Dec 31, 2025; revenue $3.427B); ICONIQ Capital State of AI: Bi-Annual Snapshot (January 2026), AI-native gross margin projected ~52% in 2026 (survey of ~300 executives); Maxio 2025 SaaS Pricing Trends Report, hybrid pricing 21% highest median growth rate (Benchmarkit survey, N=316); OpenView Partners State of Usage-Based Pricing 2nd Edition (2023), 46% hybrid, 15% pure PAYG; OpenView Partners SaaS Benchmarks (2021, 2023); Lago, 7 AI Pricing Models: What Works, What Breaks (2026); Digital Applied, SaaS Pricing in the AI Era Decision Matrix (May 2026); BillingPlatform, Best Practices for Usage-Based Billing Implementation; Stripe Resources, Usage-Based Pricing for SaaS (2026); getlago.com Usage-Based Pricing guide and billable metric selection guide.
Brian Kasday spent forty years in direct-response marketing before rebuilding the whole operation as a one-person shop. He writes The Operator’s Library — including “Build a Complete Marketing Department” — for operators who’d rather build it themselves than wait on someone else.
Build the department these ideas describe — the free companion kit: mmsvegas.com/resources.
More The Operator's Canon guides
Free · Operator Toolkit
Want the tools, not just the guide?
Get the free operator toolkit — templates and checklists for the systems you actually run, plus a note when this guide changes.
Get the free toolkit →How to cite: Usage-Based Pricing. Associated with Kyle Poyar / OpenView Partners. The Operator’s Canon, MMS Vegas. https://mmsvegas.com/library/usage-based-pricing-explained/