Fine-Tuning Freemium Models through Software Product Usage Analysis

You’ve reached an archived blog post that may be out of date. Please visit the blog homepage for the most current posts.

A colleague described an interesting business problem that his former employer, a cloud-based provider of developer tools (e.g. source control, agile collaboration), faced. Like many SaaS and cloud providers, the company priced its software on a user metric – the number of developers using their software in a given enterprise.  Until recently, they offered a “free edition” for up to 10 users. But, they turned off their freemium offer because they found that there was near-zero conversion from the free edition to a paid tier.

Freemium models are a common strategy to attract and grow users, especially for brand new products. They are based on the premise that adequate number of users will sign up for paid editions, to more than make up for serving the vast majority of users on free editions – an assumption that did not quite pan out for my colleague’s former employer.

Getting your freemium model right requires that you understand several aspects of your economic model, your end users and their software usage patterns. Freemium economics are driven by three factors:

  • total user base
  • paid-to-total-user ratio (“the conversion rate”)
  • unit cost to acquire and serve user

Say you have 1 million total users of which 2% convert (the conversion rate is 1-5% for most freemium offers). If your cost to acquire and serve users is $100/user/year, then the 20,000 (=2% * 1,000,000) paid users have to each pay $5000/user/year (= 1,000,000 * $100/$20000) for the product to break even. Attracting lots of users at a low cost requires building a great product on a scalable platform with a lot of viral marketing – these topics are covered well elsewhere.

Pricing and packaging choices have a huge impact on conversion rates and it critical to the success of your freemium model. Analyzing product usage is an essential first step to optimizing pricing/packaging for freemium models. The figure below shows popularity of different features for a Flexera product (the data is real, but the product name and feature names have been anonymized). An easy way to gather this type of data is to have “try before you buy” offers – users can try out all features of your product while you observe patterns of usage.

Freemium models

Obviously, you need a framework for gathering and analyzing software product usage.  Feature usage is one type of analysis you should plan for. Analyzing user engagement with features is another important analysis. For example, for a SaaS product, you would want to know how often users log in, how long they spend on different features in a given session and so on.

Once you have an understanding of usage, the next challenge is figuring out where to draw the line between free versus paid editions. Pick a boundary that delivers too much value in a free edition and very few users will feel compelled to convert. Conversely, delivering very little value for free will not help grow the total user base. For the Flexera product referenced in the figure, we would pick Feature A and B (used by 90% of users) for the free edition and build paid tiers using the remaining features. While that analysis was based on features, if your pricing model involves a usage metric (e.g. number of users or GB of files stored), you would want the usage metric to be the basis of the analysis. For the developer tools product described at the outset, the publisher chose 10 users as the boundary between free versus paid. Experimenting on the free versus paid cut off will help find the right balance.

Besides establishing value of paid features and driving conversion, getting the free versus paid boundary right also has a huge impact on operating costs as Dropbox found out: “Dropbox’s realization that its unlimited undo history — available to free and paying users — was responsible for a huge and growing share of its costs. And further, few customers actually used the feature.” Hardly a surprise that the feature is no longer free!

It is important to set some limits for your freemium packages. Netflix, for example, allows 1 month of free streaming for new customers. “Dropbox allows you to store up to 2 GB free of charge. Dropbox reserves the right to terminate Free Accounts at any time, with or without notice…if a Free Account is inactive for ninety (90) days, then Dropbox may delete any or all of Your Files….”. Setting a limit forces an interaction between the producer and the consumer. For a user, it is about deciding if the product adds any value (or conversely if the user would even miss the feature if it was turned off) and for the software producer to check up on actual usage and decide if it is worth serving the user.

Which bring us to the final requirement: tracking limits requires you to track users and their software entitlements.

What could my colleague’s developer’s tools company have done differently? Analyzing usage patterns would have helped them pick a different cut off for their free edition (rather than removing freemium altogether). It turns out many of their competitors only allow 2-3 users for their free edition. Or they could also have a put a time limit on their free edition (e.g. 10 users free for 1 year) which would have forced a “value-based” conversation at renewal time.

To summarize, fine-tuning software pricing and packaging to optimize freemium conversions requires you to:

  • Collect and analyze software product usage to understand most popular features or levels of consumption
  • Using software usage data to fine tune the boundary between free versus paid feature or editions
  • Set time or software usage limits on freemium packages
  • Track users and their software entitlements

Have you tried a freemium model for your software or service? I would love to hear about your experiences.

One comment on “Fine-Tuning Freemium Models through Software Product Usage Analysis

Leave a Reply

Your email address will not be published. Required fields are marked *