Optimizing usage-based pricing for infrastructure SaaS

When I joined ClickHouse to build out our serverless cloud offering, one of the biggest unknowns was how to approach pricing.

For a full story of how we built the cloud offering, read Building ClickHouse Cloud From Scratch in a Year. This article focuses specifically on what I learned about usage-based pricing in the process, and tips-and-tricks applying this concept to infrastructure SaaS products.

What is usage-based pricing?

In a SaaS world, a usage-based pricing model means that you pay for the service based on consumption or “usage” by the users of the service. In contrast, a more traditional subscription-based model means that you get charged a flat fee on a monthly or early basis for a package chosen by you, regardless of usage.

Usage-based pricing can be more user-friendly, especially if it is hard to predict how the service will get used, because you don’t have to select the right subscription package upfront, and your bill is adjusted dynamically as you rely more (or less) on the product or service chosen.

For enterprises and larger customers, usage-based pricing is often coupled with the concept of “committed spend” for those users that know how much they will use the service and are comfortable pre-committing to a certain level of spend in return for discount.

Finally, one of the main advantages of usage-based pricing is that customer use of your product (and thus presumably the value they derive from it) is directly related to the revenue you derive. This means your incentives are aligned — you don’t “sell and forget”, but try at every step to ensure that your existing customers keep using your product with success.

How to decide on usage-based pricing dimensions?

Usage-based pricing is not always straightforward to define, because it may be hard to predict on which “dimension”, or indicator of usage, to base the pricing model. Ideally, pricing dimensions should be simple to reason about and possible to estimate based on how users envision themselves consuming the service as well as previous usage patterns.

For example, when we built out pricing for a cloud database like ClickHouse Cloud, there are several options we considered:

• Many granular dimensions. If you consider every scenario in which your service may get used, you could arrive at dozens of potential pricing dimensions. Exposing all of them is likely going to be overwhelming to users, but paradoxically it is often the most “fair” pricing model, because it fine-tunes the pricing to every type of workload. You may have a user that is writing and reading at vastly different levels, storing vastly different amounts of data, creating a lot of tables vs not, a lot of partitions vs not, using a lot of columns vs not, using the network heavily vs not, relying on backups a lot vs very little, and so endlessly on. After evaluating the “extremely fair but inscrutable” pricing model, we discarded it as not the most user-friendly in ClickHouse Cloud.
• Opaque “usage units”. To deal with the explosion of granular dimensions, some SaaS services hide this complexity behind opaque “usage units” and charge by a single dimension calculated in the background by the cloud vendor. This approach may keep the fairness of the above model, but relies on user trusting the SaaS provider to be fair and honest. The opaque model makes it impossible for the user to reason upfront about intended usage vs price upfront; the only way to learn how much you will pay is to start using the service and see how many “units” a particular workload accrues. We briefly considered this approach in ClickHouse Cloud, but ultimately decided that it was a bit too opaque for the types of users we have, who are typically more technical and pride themselves on understanding the details.
• A few simple dimensions. This pricing model can be derived from the first model by taking away some dimensions from initial pricing, typically those that are either fairly constant amongst all users (e.g. all users want basic backups) or scale well with other dimensions (e.g. network consumption typically scales well with read and write volume). By simplifying the pricing model to a few core dimensions is not easy, but if you can do it, you can have the best of both worlds — a model that can be reasoned about by the users upfront and fair across your user base.

Here is what we ended up with https://clickhouse.com/pricing

As you start on your pricing work, it is important to make sure you have a reliable metering, billing, and pre-paid credits account engine. At ClickHouse we chose not to build our own and instead partnered with m3ter on this capability. This allowed us to play around with different pricing models quickly during the private preview and beta period, without having to spend engineering resources building out functionality that we ultimately never shipped in production in GA, without regret. It also helped us get to market faster with our usage-based billing.

How to make sure your pricing is “correct”?

There are several places where you can go wrong with pricing, and it is important to pay attention to them continuously and course-correct as needed. Here are two examples:

User friction

Once you’ve come up with the pricing model, you can try to market-test it by showing it to users and asking for their feedback. Even better, you can get users to try an early version of your service for free, show them “mock usage bills”, and ask for their reactions. However, in my experience, this type of early market testing has limited value, because there is always selection bias in that type of exercise, and the real test comes when your service is out there used by many users with different workloads and needs.

When you go into public beta, it is very important to listen to the many signals that you receive (e.g. in HackerNews, Twitter, support cases, direct feedback) for any signs of friction in users understanding your pricing or misalignment between what you charge, the value users get, and alternatives they consider. Based on the feedback, you may have to make a pricing adjustment (e.g. take away a particularly difficult to reason about dimension and build it into the margin), or introduce a new class of an offering for a sub-classes of users with different needs (e.g. a new usage tier for a subset of the market).

In ClickHouse Cloud, we learned a lot through working with real users in Beta and made both types of these changes — we removed “read and write units” from pricing to simplify it, and introduced “developer services” for users that are just getting started vs going to production.

Margins

One thing you have to watch for with all these models is how your infrastructure costs scale with your pricing model, because if you missed a dimension or predicted wrong how it scales with usage, you may end up with higher costs vs how you priced for usage, and thus lower margins. If that happens, you can still correct it after the fact. For instance, you can add a new dimension to pricing or rate limit / cap usage for that dimension and optionally charge for overages as an add-on.

Importance of ongoing usage and pricing analytics

It is important to recognize that usage-based pricing is never final and you need to continue to evolve it as your product changes and new usage patterns emerge. It is very important to collect all usage dimensions (not just the ones you bill by) as well as all your infrastructure costs into a reliable datastore and analyze it overtime. At ClickHouse, we use our own analytical database technology for this, and can tell at any point in time how usage translates into billings for our users, and how additional usage dimensions and our trend, translating into margins. This enables us to adjust pricing and roll out changes to our service with confidence.

Thanks for reading! Please follow me here on Medium, Twitter, and LinkedIn to learn more about my thoughts on product management, packaging, pricing, and latest news about the products I am building.