Usage-based pricing for SaaS: when it works and how to pick the meter

In short: Usage-based pricing retains revenue better than seat or flat pricing because merchants who grow pay more without deciding to, and the benchmark data shows a 10 point gap in net revenue retention. It hurts when the meter counts something the merchant sees as a cost, or when their volume is seasonal and your revenue falls with it in January. Pick a meter the merchant already celebrates, use graduated tiers over a flat allowance, show the meter on the home page every day, and move existing customers at the start of a billing cycle with a preview of what they would have paid.

When does usage-based pricing retain better?

When the thing you meter is the thing the merchant is trying to grow.

Aleph's summary of the 2026 Aleph x Benchmarkit report, built on full-year 2025 data from 342 SaaS and AI-native companies (230 of which reported NRR), reports usage-based companies at a median NRR of 108% against 98% for seat-based. It also puts the 75th percentile for usage-based models at 155%, which tells you the spread is wide. Usage pricing raises the ceiling and the variance at the same time.

The mechanism is simple. A seat-based affiliate app charges a brand the same $99 whether its affiliates drove $5,000 or $50,000 last month. A usage-based one charges more in the $50,000 month, and the brand pays it without a sales call, because they just made $50,000. Expansion revenue that arrives this way is cheap and quiet. The brand never had to be convinced of anything.

It works best when three things are true. The merchant's usage of your app tracks their own success. The merchant can predict next month's usage roughly from this month's. And the merchant can check your meter against a number they already have, like orders in their Shopify admin.

When does usage-based pricing hurt?

Four situations, and e-commerce has all of them.

Seasonal merchants. Shopify's newsroom post on Black Friday Cyber Monday 2025, dated 2 December 2025, reports $14.6 billion in sales across the weekend and more than 94,900 merchants having their highest-selling day ever. If your meter is orders or attributed revenue, your MRR from those merchants peaks in November and falls in January through no fault of yours. It is a problem if your board reads January as churn, or if the merchant reads the November bill as a reason to downgrade. I covered the effect on net revenue retention separately. The design answer is a flat base that covers normal months, so the usage part only moves in months the merchant is happy.

Meters that count a cost. Emails sent, API calls, review requests, creator messages. The merchant does not want more of those, they want more of what those produce. A meter on the cost side teaches merchants to use the app less.

Buyers who need a predictable number. Agencies managing twenty stores, and merchants with a finance person, will choose a worse app with a flat price over a better one with a variable bill. Give them a private flat plan rather than forcing a meter on them.

Bills nobody explained. If I were back in a support queue, the ticket I would dread most is the merchant who got a usage charge they did not see coming, because that conversation is about trust, not price. Most of this guide is about preventing it.

How do you choose the meter?

The meter is the unit you charge for. Run every candidate through five tests.

1. Does it go up when the merchant succeeds? Affiliate-attributed sales do. Messages sent do not.
2. Does the merchant already track it somewhere? Orders, revenue, subscribers and active affiliates all show up in their own reports. "Credits" show up nowhere.
3. Can the merchant predict it a month ahead? Orders, roughly. Creator video views, not at all.
4. Can the merchant verify it? If your meter says 412 attributed orders, they should be able to open a list of 412 orders with Shopify order numbers.
5. Would they say it out loud to their team as good news? "We crossed 100 active affiliates" passes. "We used 10,000 API calls" fails.

For an affiliate or referral app, the meter that passes all five is attributed sales, or active affiliates. For a TikTok Shop creator tool, it is creators who posted, not messages sent. For a reviews app, it is orders per month, a number the merchant already watches. How tiers map to store stages is covered in Shopify app pricing plans. Pick one meter. Two meters double the bill explanations and halve the chance a merchant can predict the invoice.

Graduated or volume tiers: which should you use?

Both are tiered usage prices. The difference is what happens at a boundary.

Graduated tiers charge each unit at the rate of the tier it falls in, like income tax bands. Volume tiers charge every unit at the rate of the tier the total lands in. With three tiers at $0.10, $0.08 and $0.05 per attributed order:

Tier	Graduated	Volume
Orders 1 to 1,000	$0.10 each	All orders at $0.10 if total is 1,000 or fewer
Orders 1,001 to 5,000	$0.08 each	All orders at $0.08 if total is 1,001 to 5,000
Orders 5,001 and up	$0.05 each	All orders at $0.05 if total is over 5,000

A merchant with 6,000 attributed orders pays $470 on graduated pricing (1,000 at $0.10, 4,000 at $0.08, 1,000 at $0.05) and $300 on volume pricing. Volume looks generous, but it has a cliff: 5,000 orders cost $400 and 5,001 cost about $250. Merchants notice cliffs, and the ones just below a boundary feel punished.

My recommendation is graduated tiers above a flat allowance. The flat part of each plan includes a generous number of units, so most merchants in most months pay a fixed price they can budget. The graduated part only applies above the allowance, in the months when the merchant is growing. No cliffs, and a bill that is always explainable as "your allowance plus this many extra orders at this rate".

How should the meter appear in the product?

On the home page, every day, in money as well as units. A merchant should never learn their usage from an invoice.

The card I would ship shows units used this cycle against the allowance, the date the cycle resets, the projected end-of-cycle total at the current pace, and the overage cost so far in the merchant's currency. Below it, a link to the list of units, so the merchant can check 412 attributed orders against their Shopify orders.

Then two warnings, in-app and by email. One at around 80% of the allowance, stating the overage rate and what the next plan would cost instead. One when they cross it. The 80% warning is also your best upgrade prompt, because it arrives when the merchant is growing. How to write it is in in-app upsell design.

The reason the warning has to be yours: Shopify's App Pricing documentation states that usage caps are not currently supported and that App Pricing does not use capped amounts, so the older Billing API's approaching-capped-amount webhook does not apply. There is no safety net from the platform. The app is the safety net.

What does Shopify App Pricing support for usage meters?

From the same documentation page:

• You can create up to five active usage meters per plan, and define up to six pricing tiers per usage meter.
• Usage can be charged with fixed, graduated or volume pricing structures, and combined with a monthly recurring charge.
• Usage charges must be billed monthly and cannot be combined with yearly-only plans.
• Usage caps are not supported, and one-time purchases are not supported.
• Your app reports usage by sending billable events through the App Events API.
• An app can have up to eight public plans and unlimited private plans, and you can test usage meters on a paid plan at no charge, which creates a subscription with $0 effective prices.

Five meters and six tiers is far more room than you should use. One meter, three or four tiers, graduated.

How do you migrate existing customers to usage pricing?

Carefully, in the merchant's quiet season, with a preview.

Shopify now provides the tooling. Its migration guide says you can move subscriptions in the Partner Dashboard when their recurring price matches one public plan, and use Shopify CLI for everything else, including usage-based subscriptions, price adjustments and moves to private plans. The 29 September 2026 changelog adds that subscriptions move at the start of their next billing cycle and merchants do not need to re-approve charges. Four details from the guide matter for planning: if billing terms change, the merchant gets at least 30 days' notice, a subscription with an active discount cannot move until the discount ends, usage configuration is not copied from manual plans and must be added, and once a subscription has changed to its new plan the move cannot be undone.

What I would add on the product side:

1. Grandfather by default. Put existing merchants on a private plan matching what they pay today. Move only those who opt in, or whose new bill is lower.
2. Show each merchant a preview: "On the new plan, your last three months would have cost $X, $Y and $Z." If the preview is higher, that merchant needs a conversation, not a migration.
3. Do not move a Shopify merchant in October. Move them in February, when a usage bill is small and they have nine months to see it track their growth.
4. Keep the Billing API integration and its usage records running until no subscriptions remain on it, as the guide says.
5. Watch downgrades and support tickets for 60 days after each batch before scheduling the next.

Where to start

1. Write down your current meter and run it through the five tests. If it fails test one or test five, change the meter before anything else.
2. Model graduated and volume pricing for your top 50 merchants on six months of usage. Look for cliffs and for bills that would swing more than 2x between months.
3. Design the home page usage card with units, reset date, projection and overage cost, and the 80% and 100% warnings.
4. Draft the plan structure as flat allowance plus one graduated meter, and check it against the App Pricing limits above.
5. Plan the migration in batches by season, starting with merchants whose preview shows a lower bill.