How to Choose a Billable Metric (and Why Most Companies Get It Wrong)

Most usage-based pricing decisions get made backwards. Teams pick a model first: pay-per-use, credits, hybrid. Then figure out what to meter. The metric becomes an afterthought.

That's the wrong order. The metric is the model. Get it wrong and the whole pricing strategy falls apart, regardless of how elegant the structure around it is.

The obvious objection

Before the framework: the strongest counterargument is "just A/B test it."

Pick two metrics. Split a cohort. See which one converts better and retains longer. Let the market decide.

This works for price levels. It doesn't work for metrics. Changing a billable metric after customers have built workflows around it is one of the more disruptive migrations you can do. The customer who signed up paying per API call and now gets told they'll pay per active user has a legitimate complaint. You repriced their contract mid-flight.

Metric choice has to be right from the start. That's why it's worth thinking through before you ship.

The four-test filter

A good billable metric passes four tests. Most metrics that cause problems fail at least one.

Test 1: Does it correlate with your costs?

The thing you charge for should scale with the thing you pay for.

An AI inference API incurs cost per token processed. Charging per token protects margins. As usage scales, revenue scales with it. Charge a flat monthly fee instead, and a high-volume customer becomes a money-losing customer.

This test matters most for AI and infrastructure companies where marginal costs are real and variable. It matters less for pure software with near-zero marginal costs.

Test 2: Does it align with customer value?

Customers don't care what you pay for. They care about what they get.

An AI search engine incurs costs per result returned. But most results aren't clicked. They don't generate value. Charging per result means customers pay for something that, from their perspective, didn't help them. Value misalignment creates friction at renewal.

Twilio charges per message sent, not per message delivered. The value is reaching someone. Sending is the closest proxy. PostHog charges for events and session recordings: actions the customer directly initiated and can observe. Both metrics feel fair because they're tied to something the customer recognizes as using the product.

Test 3: Does it degrade the product experience?

This is the test most teams miss entirely.

Whenever you meter something, you create an incentive to minimize it. That's fine when minimization is neutral. It's a problem when minimization makes the product worse.

A BI tool that bills per event ingested creates a rational incentive to send fewer events. Fewer events means worse analytics. The pricing works against the product's purpose. Every query becomes a cost decision instead of a product decision.

This is the taximeter effect. When every action has a visible cost, customers behave like someone watching the meter in a taxi: hesitant, calculating, less likely to explore freely. You built a tool to help them. The pricing is making them use it less.

The test: if a customer tried to minimize this metric, would it make their experience worse? If yes, rethink the metric.

Test 4: Can customers predict it?

A metric customers can't forecast is a metric customers fear. Fear creates churn.

Unexpected AWS bills are a genre. Customers spin up a workload, forget to set a budget alert, and get invoiced for thousands they didn't plan for. The problem isn't AWS's pricing. It's that compute hours are genuinely hard to estimate before you've run the workload. For engineers, manageable. For non-technical buyers, terrifying.

For B2B products targeting technical buyers: GPU hours, API calls, database rows are all fine. Those buyers can estimate consumption. For products targeting less technical teams, the metric needs to be something a person can count in their head before they sign up.

PostHog's session recordings work because a PM can roughly estimate session volume from traffic data before committing. The invoice isn't shocking.

The taximeter trap

Notion doesn't charge by the page. If it did, users would work around it: giant single pages, aggressive nesting, anything to minimize the count. The product would become a game of metric-avoidance instead of a tool for thought.

Charging per page creates friction at the exact moments of high engagement: when someone is doing a lot of work, which is exactly when you want them to feel free, not cost-conscious.

Notion's actual metric: workspace seats. Minimizing seats means fewer people using the product. That's a natural limit. It doesn't distort how anyone uses the tool itself.

A hypothetical email tool that charged per email opened would punish good marketing. Every high open rate would also mean a higher bill. Optimizing for engagement becomes financially punishing. That's a taximeter.

The pattern: any metric that makes customers second-guess natural product usage is a taximeter. The question is always "what would a rational customer do to minimize this?" and whether that behavior is neutral, helpful, or harmful to the product.

Usage restrictions: the other category

Not every limit on usage is a billable metric. Some are usage restrictions: limits tied to plan tier rather than direct charge per unit.

AhRefs doesn't charge per project. The Lite plan includes 5 projects. Anyone needing more than 5 likely has the business scale to justify the Standard plan. The restriction proxies for ability to pay without creating a per-unit charge.

It works because "number of projects" is a clear indicator of business maturity, not a consumption metric. Packaging decision, not a metering decision.

Usage restrictions make sense when the limit is a clear proxy for customer scale, when you want plan differentiation without per-unit billing complexity, and when the threshold is predictable enough that customers can plan around it before signing.

They don't work when the restriction feels arbitrary or punishes normal usage patterns that have nothing to do with ability to pay.

Three metrics that work, and why

PostHog charges for analytics events and session recordings. Both are triggered by real product activity, not background processes. A PM can estimate session volume from traffic data before signing up. Minimizing session recordings means using the product less. That's the customer's choice, not a pricing distortion.

Mistral charges per million tokens. Tokens map directly to inference compute cost. For AI developers, tokens are already a native unit of thought. No translation needed. The number grows in proportion to how much the customer is actually doing with the API.

Twilio charges per SMS sent. Each message is a discrete, customer-initiated action. The value: reaching a recipient. Customers can estimate volume from their own send lists before committing.

Worth separating two things these examples share: the metric the customer sees, and the value the business actually cares about. A resolved support ticket, a closed deal, a shipped feature, those are business-value metrics. A token, a session, a message sent are user-value metrics: things the customer directly did. The best billable metrics sit as close as possible to the user-value side, because that's what the customer can observe and control. Charging for a business outcome you don't fully control tends to create disputes over attribution.

The pattern: observable, proportional to recognized value, no distortion of natural usage.

The pressure-test checklist

Before you build anything, run these five questions:

1. If a customer tried to minimize this metric, what would they do, and would it make the product worse?
2. Can a typical buyer estimate their monthly bill from information they already have, before they sign up?
3. Does the metric grow when your infrastructure costs grow?
4. Is the metric something the customer directly controls, or can it grow from background system behavior they don't notice?
5. Does charging for this metric create an incentive that conflicts with the product's purpose?

Stuck on any of these: the metric needs redesigning before it goes live.

What this looks like in a billing system

Once you've chosen a metric, you need a system that can meter it correctly at scale. The aggregation type matters as much as the metric itself.

Lago supports COUNT, COUNT UNIQUE, SUM, MAX, LATEST, WEIGHTED SUM, and custom aggregations. Each maps to a different kind of usage:

COUNT is total events: API calls, messages sent. COUNT UNIQUE deduplicates: monthly active users, unique devices. SUM is cumulative quantity: tokens processed, GB transferred. MAX is peak value within a period: max concurrent sessions.

The aggregation choice isn't an implementation detail. A "monthly active users" metric that uses COUNT instead of COUNT UNIQUE will double-bill customers whose users touch the product twice in a day. That's how billing disputes happen.

Every Lago event has a unique transaction_id. It prevents double-counting if the same event is sent twice. Relevant for high-volume AI workloads where retries are common. Every aggregation rule is open-source and inspectable. You can read exactly how a billable metric is computed before it hits a customer invoice.

FAQ

What's the difference between a billable metric and a pricing model? The pricing model is the structure (per-unit, tiered, credits, hybrid). The billable metric is what gets measured inside that structure. You can apply the same pricing model to a bad metric and a good one, the model won't fix a metric that fails the four tests.

Can I change a billable metric after launch? You can, but treat it like a migration, not a settings change. Customers built workflows and budgets around the old metric. Communicate the change well in advance, and consider grandfathering existing customers on the old metric for a transition period.

Should every usage-based plan have exactly one billable metric? No. Hybrid and multi-dimensional pricing often combine several metrics (a seat count plus an API call volume, for example). Each individual metric in the mix still needs to pass the four tests on its own.

What if my product doesn't have an obvious usage-based metric? That's often a signal the product is better suited to seat-based or flat pricing, or that a usage restriction (a plan-tier limit) is a better fit than a per-unit billable metric. Not every product needs to meter something.

The metric is the foundation

Everything in usage-based pricing: the model structure, the overage policy, the customer dashboard, the invoice format. All of it sits on top of this decision.

Most companies discover the metric was wrong after the billing system is built around it. The migration is painful. The customer conversations are worse.

Run the four tests. Check for the taximeter. Make sure customers can predict the number before they see the invoice.

The hybrid pricing and credit-based decisions that come after are easier once this one is solid.

Download the full usage-based pricing playbook, the ebook this article is drawn from. Or book a demo to see how Lago's billable metric configuration works in practice.