This article is the fourth in a six-part series about monetizing IoT.
This article examines monetization metrics, which are the units of value that enable a company to generate more revenue through increased use or adoption of the product, and how product managers can identify and price the units of value that are important to customers. This article’s evaluation of unit structures for pricing products builds on concepts previously addressed in this series. The first article describes IoT monetization strategies—the why behind the work. The second article introduces a two-part framework for defining the what and “how” of monetizing the IoT stack. The third key concept in monetizing IoT– understanding monetization models and strategies — is addressed in this article, which provides a deep dive into different revenue models and how they may apply to your business.
What is monetization metrics?
A monetization metric is one of two structures — along with the product structure — that defines the units of usage or value to which individual product pricing is attached. In price book parlance, a monetization metric is the unit of “each” that’s used for buying items. In other words, pay more as you use more or it’s what you are counting to generate more revenue.
This is one area of monetization where art meets science. Properly structured, monetization metrics enable a company to generate more revenue as product use or adoption increases. However, improperly selected metrics can lead to revenue leaks or products that are overly complex to configure and price. For example, metrics might be the number of named users for IoT design software, the number of end points managed by SCADA software, or the amount of data analyzed in a cloud-based IoT analytics application. In each example, as usage increases, the customer receives more value and the supplier should receive more revenue.
Properly aligning a metric to value is an area where product managers can be creative to gain a competitive advantage and increase revenue. The goal is to structure price according to a meaningful unit value while calculating the actual price by business goals, such as profit, market penetration and brand. Increasingly, the value of products in IoT are created by digitally enabled functions. Product managers can adopt the principles used for structuring monetization metrics in other digitally enabled functions, namely software products.
How applicable is a metric?
Whether or not a metric is applicable for software and other digitally enabled products depends on four criteria:
- The metric should be simple so that customers know what they are buying. Defining metrics by a calculation is typically not transparent, making it difficult to determine what might happen as product adoption increases. For example, the number of analysis reports generated by IoT cloud analysis software is easier to understand than a calculation that involves data throughput, average daily data loads, and terabytes of storage consumed.
- The metric should represent a reasonable measure of value for the customer. For example, pricing engineering design software by the number of total employees at a company will not be viewed as fair, but pricing HR software by the number of employees at a company will seem fair.
- A metric is best if it provides a way for the supplier to generate more revenue if usage or adoption of the product increases. If the number of endpoints connected to a programmable logic controller increases, it’s reasonable that the supplier is entitled to additional fees.
- Actual usage should be measured so that compliance, supplier fees and customer costs can be accurately determined. For example, pricing software by the number of API calls that are performed in a month by an IoT endpoint is not a good metric if the number isn’t being counted anywhere.
What metric is most suitable?
When selecting metrics, keep in mind that some metrics might meet two or three of the criteria above, but not all four. For example, some software is monetized by the number of cores of the machine where the software is running. This might not accurately represent the value received, but the function might be so complex or dynamic that no other metric can be measured.
Products might be sold at different price points for different metrics, creating a stratified offering. Some IoT controllers might be sold at one price for the number of concurrently active endpoints, while another price might apply if the metric is the total number of endpoints; active or not.
Complex products or those that cross the IoT solution stack could be sold by multiple metrics. An IoT analytics platform that manages cargo container traffic through shipping port combines metrics, such as the number of users of the solution, the amount of cargo that is analyzed and the amount of high-risk cargo that is identified and verified at the port.
Conversely, solutions that include multiple elements of the IoT solution stack might even use a simpler metric. Using the same example of a cargo container traffic solution, a supplier might have performed usage analytics on previous deployments and may have determined that it can simplify the offering by setting the metric to be the total number of ships that pass through the port in a year.
In the next article of this series, we’ll look at another element of monetizing products: the product structure or bundling. The sixth and final article will tie together all the elements of the series.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.