The price model you use when selling your software is a primary key to increase or decrease your profit. Even if you sell your product at one price, give it away for free, negotiate a price individually from customer to customer or whatever way your model is designed, we believe you’ll find inspiration in this document that can help you improve your business.
Choosing the right price model is definitely not easy and to run your business at its best you must make adjustments from time to time. In a sense you need to experiment, but experiments with price models are difficult to conduct without unsettling your customers. As the potential effects can be damaging to your business, if done wrong, such experiments are, with good reason, often postponed. You know what you have – you don’t know what you’ll get.
With application analytics you can gain insights that can help you adjust your price model based on indisputable facts about your customer and user bases. Armed with this information you can, to a certain extent,predict the impact of the changes. This is far more attractive than shooting in the dark and only in retrospect seeing the effects of your price model changes.
TIP #1: Reconsider your current price model. Your answers to the questions below will help you clarify whether or not optimization of your model is a viable path to pursuit.
- Is it based on market standards set by competitors?
- How often has it been modified over the years?
- How much has your product changed over time and is this change reflected in the model?
- Based on which principles did you originally design the model?
- Do you have quantitative data supporting the model?
Most price models for software products are based on the simple principle that prices generally increase with increased access to functionality. “Increased access to functionality” must be understood in the broadest possible sense, but the idea is that there are a number of limiting factors (practically anything) that you as supplier can control. This control enables sale of restricted versions of your software at a lower price to customers with lesser means and/or lesser functional demands and at the same time sale of the same software at a higher price to other customers. This increases your market and your profit.
This raises several questions:
- Which limiting factors are relevant?
- Which limit values are relevant for your limiting factors?
- How should the limiting factors along with limit values be combined in actual offerings?
- What should the price be for the actual offerings?
With application analytics you can collect information that can answer question 1 and 2 - and to a lesser degree 3. Question 4 can only be answered with actual experimentation.
Let’s look at a real world example. EQATEC Profiler is a performance profiler for .NET. When it was first released in the spring of 2008, it was the world’s only supporting .NET compact framework. Later it was the first supporting Microsoft Silverlight. Both niche platforms are from Microsoft.
Here is the price model for EQATEC Profiler from April 2012:
The limiting factors in our price model are all the elements listed on each row, e.g. “Silverlight” or “Compare”. The lines are essentially the answer to question 1 on page 1.
For each limiting factor in our price model we have defined four limit values, e.g. for “Silverlight” we have the values “unlimited”, “10”, “3” and “1”. For “Compare” we have the values “on”, “on”, “off”, “off” (“off” is denoted by blank). All the values essentially are the answer to question 2 on page 1.
We have bundled the limiting factors and the limit values into four actual offerings, i.e. the “Corporate”, “Professional”, “Standard” or “Free” versions of our software. These four columns are essentially the answer to question 3 and page 1.
The price for each acutal offering has been set by a combination of experiments and knowledge about competitor prices.
This price model has been adjusted a number of times over the years, and is always based on new data measurements collected through Analytics. In the following sections you’ll see some examples about how we did this.
TIP #2: Measure all aspect of your current price model. No matter how your price model is designed today you have made some assumptions about your users and their use of your product. Maybe you already have a price model with limiting factors as described above? Measure all such aspects of these assumptions and limiting factors:
- number of concurrent users
- number of user accounts
- number of database entries
- number of reports generated
- size of documents
- number of users using functionalities X, Y, Z
How did we decide what the limiting factors should be in the price model for the EQATEC Profiler? Measurements always guided us to an understanding of what factors were relevant and which were not. Here are some examples of measurements and conclusions.
The EQATEC Profiler supports all .NET versions. Support for each of these platforms is a key feature of the product and it didn’t take Analytics to understand that these could be relevant limiting factors, but our measurements have had strong impact on our understanding of our user base and customers and again on the design of our price model.
What do we measure? Every time our users are profiling one of their applications we register the particular .NET development platform used. This is done with one line of code such as this:
Resulting in a graph such as this:
When we first saw this graph we were very surprised to see how many users used our profiler for the full .NET platform. There are many suppliers of profilers and many free .NET profilers in the world so we didn’t expect this distribution at all. Our profiler was the world’s first to support the niche platforms and the number of alternatives is still very low – none supporting all platforms. Nevertheless, our users use it heavily with full .NET and this fact is reflected in our price model as a limiting factor - you have to purchase a license if you want to use it with .NET applications built with more than 3 assemblies. Prior to this insight we gave it away for free to .NET users.
Through the filtering mechanisms in Analytics we can gain further insights as the following examples show.
If we apply the FeatureUse filter and limit usage to users running the unlicensed (free) version we get the following graph showing which development platforms they use:
The graph contains data from all users of the free edition, beginners to advanced. If we add the Usage Count filter and only include data from users having used the application more than 15 times, we get this graph:
Note that the fraction of Full .NET is increasing. Hence free-riders are practically only using the profiler for Full .NET. Now let us take a look at the same data but for licensed (Corporate) users only:
And now for “loyal Corporate customers” having used the application more than 15 times:
The message is clear: Many customers purchase our Corporate license for the special .NET Compact Framework support and few for Silverlight and WindowsPhone7 support, though still a majority are using it for full .NET.
These facts are directly reflected in our price model. Support for each development platform is a limiting factor. This was not the case when we first released EQATEC Profiler. We have moved away from absolutely free, to a version where only compact framework was restricted, to a version where all platforms are restricted.
Without these insights we would wrongly have assumed that all our customers were using the niche platforms and lost all of the full .NET business. Had we only used our gut-feelings while designing our price model we would have done poorly.
- TIP #3: Measure the obvious. Don’t trust your gut-feeling is correct. Measure aspects you already believe to understand. Reality might bring surprises that quickly can be used to improve your business.
In our price model we restrict access to specific functional features such as “Print”, “Save”, “Search”, “No adverts”, etc. How did we choose amongst candidates for these? Simply by measuring to which extent they are used and by whom. The limiting factors evolved over time along with the addition of new functional features. Some features added were used by a limited amount of users, some were used by everyone. Those used by a large fraction are prime candidates for limiting factors in the price model.
- TIP #4: Measure all major functional aspects of your software with feature usage measurements. Many of these measurements are probably directly linked to the GUI either as menu-actions or button-clicks and, as such, can be added to the application through a few lines of source code. Once you know what is used most you have a potential list of limiting factors.
Here is an example from the EQATEC Profiler. We show in-app advertisements in the free version and we measure how often the users try to hide the advertisements:
Measured with source code like this:
And e.g. visible in Analytics in a dialog like this:
Based on these measurement we can see how many unique users try to close the “AdBar” and how many follow the advertisement URL. Based on these measurements we know that a little more than 5% of our customers would like to remove the advertisements. Having “No adverts” as a limiting factor in the price model is believed to push free users towards a purchase of a commercial license. Just as well as missing functionality such as “Compare” could pull users to pay for access to popular functionality.
The numbers in the price model rows for “Full .NET”, “Windows Phone 7”, “Silverlight” and “NET CF” denotes the maximum number of assemblies (DLLs) that can be handled by the profiler for each development platform. This is a limiting factor which is essential for controlling the value delivered to the customer.
How did we decide what the limit values should be? How did we come up with a maximum of 10 Full .NET assemblies for the Standard license?
When we first released the profiler in 2008 we didn’t have Analytics, so we didn’t have a clue. But even worse we didn’t know how far away from reality our gut feelings were. Thus, we designed the price model with restrictions we believed to be the best. It turned out that our qualified guesses were way off. Our limits were not restrictive enough. Essentially our customers didn’t need more than what they had in our standard edition at that time, at a price 10 times below our Corporate edition price.
With feature value measurements we collected the data that we needed to optimize the price model and thus the profit. We added these feature value measurements, to register the number of DLLs in the users application:
monitor.TrackFeatureValue("Build.AppAssemblies.FullNet", <number of FullNet-DLLs>); monitor.TrackFeatureValue("Build.AppAssemblies.WP7", <number of WP7-DLLs>); monitor.TrackFeatureValue("Build.AppAssemblies.SilverLight", <number of Silverlight-DLLs>); monitor.TrackFeatureValue("Build.AppAssemblies.NetCF", <number of NetCF-DLLs>);
This resulted in feature value graphs like this:
With such measuring points we can exactly see how large applications our users are profiling and thus find out how to best design our price model. Note that a majority is small applications with 1 to 3 DLLs. Thus the free version only supports 1 DLL.
Our price model today is about 10 times more restrictive on the number of DLLs than it originally was. A substantial amount of our licenses sold are now Corporate licenses, which have increased our revenue by several hundred percentage points.
With the measurements we could quickly define limit values that matches reality, increase revenue and do this without slowly improving the price model through many stepwise modifications of it.
- TIP #5: Select limit values through feature value measurements. It is very easy to measure the limit values that you use in your price model with feature value measurements. When you add a new feature to your product consider making it available for every user for a while. Measure how the feature is used. Once you have enough data decide whether the feature qualifies as a limiting factor and what the limit values should be.
As seen in the two previous sections Analytics makes the identification of limiting factors and the fine tuning of their limit values easy. When you need to decide how to bundle these into actual offerings such as our Corporate EQATEC Profiler license you cannot get the answers directly from measurements. Here you have to rely on best guesses and remember to do experiments.
But as soon as you have defined your offerings you should definitely measure these with a feature usage measurement such as this:
This results in a graphs like the following (in the lower graph we have deselected the Unlicensed usages so they are not shown, to emphasize the usage pattern of the licensed editions):
Now, over time, you can follow how your customers in each segment behave relative to each other. You can also compare with experiments you may conduct with e.g. the introduction of new offerings, and this will help you define your actual offerings.
But on top of this you can, through the use of our advanced queries, view data only from specific customer segments such as the following example:
In this report we have taken a look at the number of computer displays/screens for users running the unlicensed/free edition of the EQATEC Profiler and compared with customers running the Corporate version. As expected there is a difference. Measurements show the exact difference.
We cannot give you any advice here except for the obvious: see what your competitors are doing, experiment, read the extensive literature on the subject and use Analytics to monitor how your customers react.
We have shown actual examples of measuring points from the EQATEC Profiler and conclusions drawn from the data collected. We have shown that you don’t need many measuring points and you don’t need to spend many hours of analysis to dramatically improve your pricing model and thus the profit you make from your products. Without quantitative data you simply cannot know how to optimally design a price model for your market. With the data you can make the changes that over time will result in a substantial increase of your profit.
Our recommendation is that if you are new to the field of application analytics you should aim for price model optimizations as one of your initial improvement goals. The effort needed is low and the effect can be dramatic!