Pricing your product correctly can be tricky, and a lot of technical people who build SaaS products get it wrong on their first few tries. Our story makes for a nice case study.
Heap is web and iOS analytics tool that captures every user interaction on your website and in your app. Instead of requiring you to log events in code, Heap captures everything upfront and lets you analyze it later. This means that, when you want to answer a question with data, you can do it immediately, instead of writing code, deploying it, and waiting for metrics to trickle in.
Our Old Pricing Model
We designed our initial pricing model with a few goals in mind:
- It should be simple. We didn’t want to make the “engineer” mistake of having a highly configurable pricing scheme that confused people or scared them off. Someone who runs a website should be able to visit our pricing page and get a good idea how much Heap would cost for them pretty quickly.
- It shouldn’t discourage people from using Heap more. We didn’t want to charge by the event definition or by the API call. This would disincentivize people from getting more value out of Heap.
- It should scale gradually. We were concerned that customers would worry about about overages or going over discontinuities in their pricing plans.
We settled on a sliding scale based on the number of monthly unique users.
This satisfies all of the design goals above. It’s based on a single, standard metric that owners of major websites know off the tops of their heads, and it doesn’t have discontinuities or perverse incentives.
This has some problems, though.
- This plan charges people as soon as they sign up for Heap, when it hasn’t captured much data yet. Heap provides more value over time, as your analysis goes over more data, but we were asking for money before we had delivered any value.
- Our initial model was too simple. It papers over serious differences in value provided to each customer. A social app making money off of ads might have a lifetime revenue per user on the order of $2, whereas a web store selling $1000+ items has a much larger one. Heap provides a lot more value per user to the latter than to the former. A pricing model that only considers the number of users is either undercharging the latter or overcharging the former.
Schools Of Thought
There are a number of standard approaches to this problem, and we thought a lot about two of them in particular.
- Pricing based on cost. This can be intuitive from an engineering perspective, as we can accurately measure how much each customer costs to service in terms of hardware, but this can be opaque to customers. Pricing based on the amount of data stored (i.e., the number of events) is one way to go about this, but customers don’t have a great frame of reference for how many events Heap captures, especially before they’ve started to use it. This also isn’t a great fit for us, since our costs are dominated by an engineering team’s salaries. The portion of our AWS bill that goes towards any customer is easy to measure, but that customer’s share of our dev throughput is inscrutable.
- Pricing based on value provided. This aligns our goals with the customer’s. The amount of value each customer gets out of using Heap corresponds with the amount they pay us. This has the reverse problem, though: it’s difficult to model in an explicit formula how much value another company gets out of using Heap. A lot of SaaS companies use the number of accounts or licenses as a proxy for value. If a customer dedicates a team of eight people towards using Heap full-time, they’re probably getting a lot more value out of it than a company in which only one person uses it.
Today’s Pricing Model
This includes a number of important changes.
Heap is now free for websites with fewer than 25k monthly visits. Free as in “don’t enter a credit card; we won’t be charging you.” Rather than trying to nickel and dime small websites, we’ve decided that the most important thing is to get Heap into as many peoples’ hands as possible.
We offer a 60-day free trial, because we want everyone to have a Heap experience. We’ve found that, once people try Heap, they usually don’t want to go back to manually defining events in code or waiting for new data. We settled on a trial period of 60 days, because this gives customers a chance to accumulate enough data that the power of doing analysis “retroactively” becomes apparent.
We charge by the visit, not by the monthly user. A “visit” occurs when someone loads a page on your website for the first time in at least 30 minutes. This gives us a closer approximation to how valuable that user is. Before, we were charging the same amount for someone who landed on your homepage and immediately left as for someone who came back ten times that month. In most cases, the latter is a lot more valuable.
This pricing model is simple, and it doesn’t disincentivize people from using Heap more. However, unlike our initial pricing model, it’s not gradual. We’re ok with this for now, since overages and pricing discontinuities don’t seem to be a serious concern for any of our customers. (The concern appears to be more common amongst tire-kickers.) But, it’s something we’re monitoring.
As for the choices of $149 and $499 as base prices for the tiers and 25k and 75k monthly visits as cutoffs between the tiers, the specific numbers are a little bit arbitrary. Looking at our existing ~500 customers, they made sense as parameter choices for us. For example, $149/month was close to what a lot of companies that would end up in the Growth tier were paying before, 75k monthly visits made sense as a cutoff after which we’d want to charge customers at ad-hoc levels, and so forth. A low “Enterprise Plan” cutoff is important, because it lets us attempt to charge our larger customers based on value provided.
For questions like “How many people are using our new feature?” or “Are people who signed up in the last two weeks more likely to convert to paying customers?” it should be possible to answer with data in a matter of minutes, instead of pushing new logging code and waiting for metrics over a span of days or weeks. In addition to answering your existing questions faster, a feedback loop on the order of minutes enables you to ask a whole new class of questions that would otherwise not be worth the effort of answering. This kind of analysis is empowering, and everyone with a website or an iOS app should be able to try it.
Like the technical pieces of a startup, our pricing plan is a work in progress, and we’re still refining it. We’re looking forward to seeing how this turns out.
We benefit tremendously from customer feedback. Give it a try and let us know what you think @heap!