Usage-based pricing (UBP) delivers very high levels of revenue growth and product adoption. Any company operating in the cloud can (and should) adopt a usage-based pricing model enabled by best practices and frameworks that optimize the value being provided to the customer.

The usage-based model is the only one that makes sense in the cloud. Given the elastic nature of the underlying infrastructure, anything that gets layered on top needs to be just as flexible — and that includes pricing. Below, we will lay out six steps to get started with a usage-based pricing model at your business using Amberflo.

‍

But first, why Usage-Based Pricing?

Usage-based pricing offers a number of benefits to both customers and vendors. For customers, it is the most flexible and transparent model and it addresses the growing problem of shelfware, or software that is paid for but goes unused (some estimates peg that up to one third of user licenses go unused or underused).

According to research from OpenView Partners, usage-based pricing leads to demonstrable improvements in net dollar retention (NDR) and customer acquisition cost payback time (CAC Payback). Usage-based pricing provides a more flexible model that allows customers to pay only for what is used, and to scale usage up and down as needed, leading to better retention and reduced churn. By providing a natural pathway to monetize as usage grows, you can recover customer acquisition costs more quickly than with fixed recurring (subscription) payments.

See the charts below from OpenView’s most recent State of Usage-Based Pricing report which demonstrate this fact:

‍

‍

True product-led growth strategies require usage-based pricing. This eliminates friction to adopt and realize value from the product while providing a viable pathway to monetization once value and fit have been confirmed. Without usage-based pricing, companies must impose usage limits and time-tables that bring friction and pressure into the sales process; this can turn customers away or inhibit them from truly recognizing the product’s value for their own use case.

Product-led growth is becoming the dominant or status quo motion in technology sales, as the buying power has moved down the org chart. New buyers are the actual users of technology, and these buyers do not have the budgets or time for expensive, drawn out testing and negotiation processes. They simply want to try the product, and if it helps with their immediate use case, they will continue using it and scale usage across their teams and companies. With usage-based pricing in place, this usage can be metered and then priced accordingly with built-in free tiers and trials to allow for a seamless, product-led experience.

‍

‍

This guide will provide high-level best practices and specific, actionable steps in Amberflo that will get you on the right track to offering a flexible, customer-friendly usage-based pricing model.

‍

‍Step 1: Implement usage metering

Many companies make the mistake of starting with a pricing model and then trying to backpedal into measuring usage.

This is the wrong approach. The first step needs to be metering all of your technology artifacts. If you are a startup building from scratch, implementing metering right at the outset will give you a tremendous advantage.

Knowing who is using what, when, where and how much will help you unlock valuable insights across all functional groups and teams, and make determining pricing much more straightforward.

‍

In Amberflo:

Amberflo allows you to accurately meter any resource or metric in real-time. You can customize the meter event data structure to include any additional metadata for use later on to filter, analyze, or even price the metered usage. 

First, you need to identify what resources should be tracked and what metrics are required to completely reflect usage and backend costs for your system. Identify how the usage events should be aggregated and what (if any) additional metadata should be included with each event record as dimensions. 

Once the meters are defined and created in Amberflo, we recommend that you leverage Amberflo SDKs to meter events at the source where they are being produced. This allows for the fewest ‘hops’ or actions with usage data and allows for real-time performance. If you cannot use an SDK to track usage, or if you already have usage records being stored in another location, Amberflo offers several different options for meter ingestion including via API, and using intermediate locations such as AWS S3, cloud databases like Snowflake and MongoDB, or even raw CSV files.

‍

Step 2: Model customer usage and backend costs

Deploy meters across your tech stack to track both front-end usage and back-end resource consumption. To do this, we classify meters into two types:

• Usage meters: What your customers are using of your products and services.
• Cost meters: What your products and services are using of the underlying cloud resources.

‍

A usage model shows overall aggregated usage by product features, filtered by customers and custom groupings. It is the real-time dashboard that serves to answer accurately what was used by whom, when, where and how much.

A usage model is the output of a full-featured metering service. There should be no delay and no custom work or design needed to see the raw events being ingested, aggregated, grouped in real time, sliced over a time series and displayed in tabular and graphical format on a usage dashboard.

A usage model should answer time series-based usage questions in real time, accurately. For example:

• What was the total count of API calls on April 18, 2022?
• For customer X, what was the API call count on January 30, 2022?
• For customer X, what was the peak API call count on January 30, 2002?
• For customer Y, what was the API call count from April 1 through June 30, 2021?
• For customer Y, how much storage was used on July 3, 2022?
• For customer Z, what was the max storage used in February 2020, 2021, 2022?
• Who are the top N customers using this meter (feature) in a specific region over last week?

‍

With this level of insight, you are now on your way to institutionalizing usage-based pricing to scale with your business and growth for the long term.

In addition to tracking customer usage, you should also instrument your tech stack to meter the back-end resource consumption that is associated with serving customer usage. Having visibility into both the front-end usage and its corresponding backend resource demand will allow for granular, real-time visibility into margins and to help identify the best and worst-performing product items or pricing models.

For example, you may have an API call for which the payload size can vary vastly based on the customer profile. In this case, you may choose to price on the storage cost and not on the API count, or a combination of the two. Or, if your API call execution results in an ETL type farm-out job, you may want to price only on the duration and not on the raw count.

The cost meters offer a way to align front-end usage (API call — usage meter) to back-end usage (API call gets farmed out into a Lambda function and ETL job, S3 storage and a database write — cost meters).

With cost meters in place, you get the usage profile of the cost footprint. In the above example, you may find that the Lambda function and S3 storage charge dominate the usage-cost profile. You may then choose to spread the cost of the database write and ETL job over Lambda function and/or S3.

‍

In Amberflo:

After deploying meters to your solution, the raw events will begin flowing into Amberflo. From the moment of ingestion, we guarantee accuracy, idempotency, and data deduplication of all events. As they are ingested, the usage is viewable in the Metering Dashboard. There is no delay or custom configuration required, immediately as events are ingested, they are viewable and ready for analysis. Users can filter by customer, by meter, or even by custom dimension to easily address the questions listed above. 

For recurring queries or reports, users can create Custom Reports and save them for easy access. This simplifies regular reporting tasks and provides immediate visibility to critical usage patterns and metrics. See the screenshot below for an example of a custom report with advanced search and filter options.

‍

‍

Step 3: Build a pricing model

You are now ready to build and iterate on a pricing model. With steps 1 through 3 in place, this truly will be a fun, empowering, insightful and data-backed exercise. Keep in mind that pricing is sort of ephemeral in nature. Pricing will come and go and change over time. The usage record is the historical record. If you have (historical) usage data, pricing can be built and modeled at any time.

Begin by building at least two different pricing plans. Explore different line items and rates. Seek a usage-based pricing and billing service that, in addition to creating pricing plans with various usage rate types (unit, block, volume, tiers, etc., which are table stakes), also has the built-in capability to work over large volumes of usage data by connecting directly to a metering service and perform price simulations in real time.

Since you already have usage data metered and available, this should be a snap. Note that the pricing and billing app is not taking ownership of the accuracy of the usage data or the ingestion and collection of usage data. That is the function of the metering platform. The pricing and billing application defines and applies the rate card (or pricing plans) and generates on-demand, real-time metered invoicing and billing.

Build your pricing plans based on the customer-facing posture you wish to take (e.g., free-tier, free-trial, multiple plans or only line items-based, credits-based). As long as you have a metering ingestion stream working and scaling independent of pricing and billing, you are well positioned for scale, growth and whatever comes in the future.

‍

In Amberflo: 

Now that usage is being tracked and aggregated in Amberflo, you are ready to begin building flexible usage-based pricing plans. Amberflo provides options to customize plans with free units, discounts and promotions, fixed-rate add-on pricing, or add-ons based on a percentage of the invoice amount. 

Product items are the line items or catalog items that will appear on invoices. Each product item is associated with a corresponding meter that tracks the usage. When adding a product item to a pricing plan you can configure how that usage will be priced, whether it be on a per-unit, per-block, or tiered model. You also have the option to price by dimension and configure custom rates based on unique dimension values or combinations of dimension values.

After all product items are added to the pricing plan, save and activate the plan. You can now assign the plan to customers to begin generating metered invoices and billing based on real-time usage.

‍

Step 4: Do a beta test

Once steps 1 through 4 are done, you should now beta test with a set of customers. Keep in mind that the steps outlined are designed so that by the time you get to beta testing, you have a near-final pricing plan — an advantage of having a metering service in place early. You should beta test, if possible, at least for one or two monthly billing cycles to surface any edge cases.

Just like any mature software development process, beta testing with real customer usage data is good hygiene and provides the opportunity to catch any outlier usage patterns or surprises. A full-featured usage-based pricing and billing application should now be generating real-time, current invoices with line item-level metered usage data and price breakdowns.

Additionally, across metering and billing, you should have full lineage and visibility into the life cycle of each event, from ingestion to pricing, invoicing and billing. Once you have run it for one to two monthly billing cycles and have verified usage and billing using a built-in data-lineage pipeline, you are ready to go into production with full confidence.

‍

In Amberflo: 

At Amberflo, we recommend using the usage data from the Metering service as your guide to identify the correct pricing vectors and usage-based rates. Using this data, you will arrive at a data-backed pricing strategy that should scale based on your customers’ unique usage profiles. In the process of identifying the correct pricing model, you should iterate and experiment using multiple models and pricing strategies. You can then test and compare these plans against each other using the Price Modeling feature to forecast revenue based on historical usage and rank pricing plans by their anticipated performance.

‍

Step 5: Continuous price modeling

The pace of innovation is the hallmark of cloud businesses. As you come up with new products and features, or even as you scale your customer base on the existing pricing plan, you’ll need a built-in price-modeling tool as your guide.

The price-modeling tool will help product, sales, finance and accounting teams with their respective planning needs and with what-if scenarios that are reliable and trustworthy. Having forecasting built into the pricing and modeling tool as a first-class object provides additional insights for future planning and business operations.

The rise of usage-based pricing is directly related to the pace of innovation in the cloud, the growing importance of software across all industries, more things shifting left toward the developer and the rise of product-led growth (PLG). Not all of these trends are mainstream yet, but in my view, they are all inevitable.

So if you’re reading this now, and you haven’t yet started your journey to building and implementing a usage-based model, consider it an opportunity to get started today and save yourself a lot of headache down the line.

There is a lot of discussion around usage-based pricing lacking predictability, and therefore, potentially not being a good choice for some. For now, let me just say that predictability is key, and if it is lacking, it is not because of a limitation of the model itself but rather a lack of proper tooling and infrastructure.

‍

In Amberflo: 

As usage rates and profiles will change over time, usage-based pricing should also be dynamic and change to remain optimal. It is important to constantly be analyzing usage patterns and customer usage profiles to see if a new pricing model or strategy would scale more appropriately. Liberally utilize the Price Modeling feature to tweak the current plan or identify completely new pricing based on real usage data. For more information on Price Modeling in Amberflo, see this blog, this article in our documentation, and this feature demonstration video.

‍

‍