Make metering a first-order artifact on your platform, application, or service (solution). Just as logging, monitoring, and other observability technologies are considered such today for tracking system health and performance, metering should be treated in the same category for tracking applications and systems usage and resource consumption, attributable to both internally (supporting and running the solution) and externally for customers consuming the solution. Just as observability components are included right at the outset of developing software, a metering infrastructure should be included  within your technology stack from the outset as well. 

Beyond enabling Usage-Based Pricing and Metered Billing , the metering data serves as a single source of truth for usage and consumption. This level of insight into “which customers are using what features, when, how much, and how often” is immensely valuable for both the product development and customer experience (sales, service, marketing, etc.) business areas, and provides the data necessary to re-optimize all areas of business around the product or solution (i.e. product-led growth, product-led sales). 

Note that we haven’t said anything about a pricing or billing application yet. This is because the metering pipeline must be decoupled from pricing and billing. Metering is an engineering function, and the creation, implementation, and maintenance of meters should be handled by engineers independently guided by “platform” design principles (what makes a solution a platform). From our experience at AWS, we learnt that you cannot back your way into Metering from Pricing and Billing. Metering is the way forward to Pricing and Billing. You need to put a metering platform foundation in place and the build solutions on top. The metering data provides the system  of record of usage and consumption that can then be made available to the product teams to inform of usage and adoption trends and enable modeling for pricing based on usage. With meter data in hand, product teams can then identify and optimize the pricing vectors (meters) that are most closely aligned with the value-add objectives customers address with the solution. This way solution profitability can be maximized while the customers can relate the invoiced amount to the value being derived from the solution. Even if the metering pipeline isn’t being used for pricing, there is still value to be derived from the level of granular visibility it provides.

Customer facing - Usage Meters

These are the traditional meters that you’re likely familiar with. As mentioned above, these should be a subset of your total metering infrastructure, focused on understanding and aggregating user actions and the associated resource consumption within the solution. These meters provide the visibility into “which customers are using and consuming what services within your solution, aggregated in real time.” Aggregated in real time is a key phrase here - this provides users up-to-the-minute visibility into usage and adoption trends and ensures that there is an accurate, idempotent, auditable record for each meter event. Beyond being used to calculate and bill based on usage, these records provide a wealth of data to customer-facing and product teams to inform and refine operations. 

For example, the value of having real-time usage and adoption data in a sales context is clear - if the sales agent knows what services and how much of each are being consumed, it makes efforts at upselling and cross-sales much more effective. In the same vein, marketing and support efforts can become much more targeted to the capabilities and value drivers and pain points (respectively) that customers are experiencing, and in some cases become new profit channels (rather than cost centers) without costly fact-finding or strategic initiatives led by third-party tools or consultants. Product development and pricing teams can identify the most common use cases and services on their solution to inform future roadmap development and short-term updates. Lastly, the relationship between the meter pipeline and product pricing - specifically usage-based pricing - is clear, and we’ve broken it down in detail here. 

‍

Internal facing - Cost Meters

We encourage new users to our platform to meter as much as possible within their solution - API calls, CPU hours, cluster count/hours, reads/writes to a database, the possibilities are infinite - any action within the solution can be metered. Beyond exclusively metering the customer-facing aspects of the solution (which we would do if we were only focused on enabling usage-based pricing), we take a more zoomed-out approach, viewing the set of meter data as the superset, while the customer-facing meters involved with pricing and billing would be a subset. Meters should be implemented with every feature or action of the system in the same vein as how observability primitives are included.

This is only possible if you have a Metering Service that is designed and built from the ground up to operate as a platform service that is highly durable, scalable, AND cost effective.

As an example, a database-as-a-service provider would likely meter reads and writes (and storage volume) to the database as customer-facing meters to be used in measuring adoption and for pricing purposes. However, it would also be of value for the vendor to meter the overall data volumes and instance  hours consumed on the backend to understand the operational costs associated with servicing each customer at their respective levels of usage. Having this granular view into the costs and resource consumption of backend systems offers value in optimizing system efficiency and performance at scale, and in forecasting future costs under different usage patterns. The possibilities for what to meter really are limitless, and the value of having an accurate, real-time view into user actions, application and system performance, and resource consumption is only just starting to become clear to the greater business community. 

‍

For more information on the technical requirements of a metering system and key differentiators for our own Metering Cloud at Amberflo, read this blog post titled, “Does your Metering System do this?”

‍