You cannot back into Metering from Pricing and Billing

As usage-based pricing (UBP) continues to become more and more mainstream, many people have questions about the correct way to go about transitioning and implementing UBP at their businesses. Check out these blogs here and here for more evidence why UBP continues to gain traction, particularly for monetizing cloud-based solutions (i.e. SaaS, PaaS, IaaS applications and services) 

At first glance, it seems perfectly sensible to start out small - first selecting a few events/user actions (pricing vectors) to track and meter, and then charging customers based on that metered usage. This is one of the most common pitfalls awaiting companies attempting to implement UBP. The main drawback to the approach is that it requires the vendor to know the optimal pricing vectors to meter and charge customers on before even beginning to transition to the pricing model. Without basing the pricing vectors on live usage data, the best that can be done is making an educated guess based on competitors strategies and trends in the greater market. Do you feel comfortable basing your pricing strategy on a gut instinct? Even if this approach does seem to be working, how can you be sure it is optimized, both to capture revenue and to drive users to action? By approaching UBP first as a financial (pricing) problem, rather than as a data (metering) problem, a vendor will never be able to see the entire picture of customer behavior and usage of the solution.

This point-and-shoot method of pricing and metering may yield short term gains. After all, it is still a usage-based model, so customers are likely to prefer the fairness and simplicity. However, by first identifying actions and consumption to price upon, and then bringing the request to engineering to implement, the data will always be incomplete as a system of record for usage and consumption. The business will always be playing “catch up” with its pricing. After the first iteration of UBP is in place, suppose the business identifies additional pricing vectors or meters. Since there isn’t a full repository of usage data, the next batch of proposed meters are still based on gut feel or industry standards, and lack the live usage data on real customers to show that they are the optimal vectors to price upon. You can see how this yields a continuous cycle of guess-and-check - first “guessing” which user actions and resources to meter, and then “checking” based on the impact to revenue whether the new meters made the desired impact to revenue. This is massively inefficient, both on the product side to be continuously delivering a pricing plan that is not optimized (and the requisite meeting cycles to identify, implement, and evaluate the next batch of meters), and on the engineering side to be constantly updating the metering pipeline each cycle. On an awareness and visibility side, this strategy will never deliver the key advertised benefits of UBP – granular, real-time visibility into customer adoption and consumption, and the ability to agilely modify pricing to align with changes to customer usage and value realization – since the business will always be reactive instead of proactive with regards to customer usage/adoption and product pricing. 

Metering is the way forward

The meter data pipeline must be engineered with the design principles of a cloud platform in mind – durability, scalability, ease-of-use, cost-effectiveness. It is to be the system of record for all usage and consumption data, which can then be leveraged for downstream applications across the business. To be of any use as a true system of record, the usage data should be comprehensive, covering the full scope of the application or service to capture all of the user actions and resource consumption. This is different from observability or logging technology – it cannot drop or lose records, and must be built from the ground up with principles of accuracy (records are idempotent and deduplicated) and automatic data aggregation over time-series in mind. 

Decouple Metering from Pricing and Billing (but integrated)

Metering should be considered and implemented before taking any actions with regards to pricing and billing. Rather than picking a select few pricing vectors to meter, we recommend metering the set of all possible pricing vectors and then allowing real customer usage data to pass into the system (at least one billing cycle ideally). After sufficient data is collected, product teams responsible for pricing should leverage this usage data to inform the creation of pricing plans. Teams can identify viable pricing vectors and backtest potential pricing models with real-world data, minimizing the number of cycles necessary to optimize. 

Product and Engineering teams collaborate with ownership of their respective tools

Once the metering infrastructure is in place, building or modifying pricing models to incorporate new pricing vectors does not require continued involvement from engineering. The two teams and tools are decoupled (yet integrated). As new products or features arrive, engineering teams independently, irrespective of what the downstream pricing change might be, put in place meters to instrument new products and features. 

Capture Customer journey and product usage analytics via Metering

As we’ve alluded, the metering pipeline creates a system of record for usage and consumption data that bears tremendous value across the organization as a whole, not only for use in pricing and billing. By implementing a comprehensive infrastructure that properly tracks and aggregates usage across the solution, the business captures the full customer journey in data, which can then be fed downstream proactively to inform customer-facing teams like sales, marketing, and service to deliver more relevant and personalized interactions. Beyond customer experience, the data should be used to inform product development and to identify value-add roadmap items. There are other potential uses across finance and accounting, executive planning, and engineering. 

‍

Without this data, or with an incomplete picture from only metering a select few vectors, all of these functions must be driven instead by gut feel  or manager instinct. Perhaps this won’t have severely detrimental consequences to all businesses, but also no business ever rose to the top of its market by sticking to the status quo.

The Amberflo Approach

At Amberflo we built our platform to enable usage-based pricing and billing built on a robust cloud metering platform, in line with the strategy we’ve just described. Amberflo Metering Cloud is built in accordance with cloud platform design principles, and ensures record accuracy by way of idempotency and data deduplication. It is a developer-friendly platform, fully API-interactive and with SDKs for multiple languages. Metering Cloud is decoupled (yet integrated) with Amberflo Billing Cloud, and can be implemented separately (we encourage this). Our pricing plan and Forever Free tier encourage users to meter all relevant actions and resource consumption without becoming cost-prohibitive. Beyond simply tracking and aggregating meter events, Amberflo provides a Usage Explorer, with dashboards and filters to visualize and explore meter data. Filter by meter name, customer, or any custom dimension (metadata) you define to understand usage patterns and identify the most viable pricing vectors. We do not price our platform per-seat, so anyone within the organization can access this meter data for cross-functional use cases such as finance/accounting, customer experience, and product development, not just the engineers who implement the system. By making metering cost-effective to implement at scale, and surfacing the data across the full organization, Amberflo enables you to create data-backed usage-based pricing plans the right way. 

‍