Inside Mixpanel

A year ago, we realized our pricing wasn’t good for our customers. Here’s what we did.

Danielle Kucera

It can be tough to take a step back and concede that something you’ve been doing for a decade isn’t good for your customers.

We recently had to do that with our pricing. Since Mixpanel’s founding, we’ve charged for event volume, which roughly translates to the amount of actions (sign ups, clicks, voice commands, etc.) users take on our customers’ apps and websites.

It’s a framework competitors who followed in our footsteps adopted as well, but it’s no longer the right one for us or our customers. In 2019, we’ll be shifting to a pricing model based on monthly tracked users (available now to customers on enterprise plans). More on why we landed on MTUs in a moment. First: the journey.

It’s been an arduous one, and we wanted to share what we learned along the way. There’s a lot we wish we’d known in the beginning of this process that would have helped us move faster.

A quick coming of age tale

Back in 2009, we asked ourselves a question many early stage companies do when they’re trying to figure out what to charge for something that didn’t exist a few hours prior: “What’s an easy-to-measure metric that correlates with our cost?” We also wanted to make sure we chose a metric customers had control over (something they could lever up or down if they needed to). Events fit the bill.

Events are a proxy for data volume, and while volume isn’t 100% aligned with our costs (CPU usage), it’s closely correlated. And our customers can track whichever events they want; if Mixpanel gets too expensive, they can exclude less valuable data.

That’s where it gets complicated. Excluding data sometimes requires customers to guess which user behaviors are most and least valuable before they use our product – a product that’s supposed to give them insight into which user behaviors are most and least valuable.

It also means that some customers end up omitting events they care about to lower costs. In other words, our pricing can stop companies from seeing a complete view of users’ behavior, which is one of the main ways they get value out of Mixpanel. That’s obviously not ideal.

So, as part of an effort over the past year to become more customer-obsessed, we went on a mission to figure out how we could help our customers track all the things that might matter – at no extra cost to them – so they could sit back and let our product tell them what actually does.

A paradox of choice, and the framework that helped us overcome it

All in all, we considered more than 50 different pricing metrics and models, things like number of apps and websites tracked, page views, flat rates, query volume, data stored, data exported, a percentage of revenue attributed to Mixpanel, a percentage of churn reduced, and so on.

It felt overwhelming at first. We narrowed down the list by subjecting every metric to the following five criteria: is it predictable, sellable, trackable, scalable, and aligned with value? Here’s what each means:

Is it predictable?

Can you reliably model price increases over time?

Customers want their bills to be reasonably consistent – and we want that, too. If a customer is paying $100 this month and $100,000 the next, it makes it hard for them to predict costs and for us to forecast revenue.

Monthly tracked users (defined as users that have taken at least one action in a given month) passed this test with flying colors, because customer growth usually aligns with revenue growth – which is also something the vast majority of companies have to track and forecast.

Said in another way: If you ask someone how many actions their users will take in their product next month, nine times out of ten, they’ll have no idea what the answer is. If you ask them how many users they’ll have next month, you’ll get a number.

Is it acceptable to customers?

Can a salesperson sell this? Does it seem logical to prospects?

Have you ever heard anyone argue for a flat tax rate across the U.S.? If so, it probably elicited some pretty polarized opinions. Similarly, a flat rate can be a tough sell when you’ve got customers ranging from 10 employees to more than 100,000.

Event-based pricing can be hard to swallow for gaming startups that have a small base of incredibly active users, which means their costs can outweigh their means early on. We also don’t want something that deters our customers from getting the most out of our product. Pricing based on query volume, for example, would discourage people exploring and trying new sorts of analyses inside Mixpanel.

Is it trackable?

Is this something both Mixpanel and our customers can reliably track?

Let’s apply this criterion to the idea of pricing based on a percentage of revenue attributable to Mixpanel. While this may seem like an enticing promise (If we don’t increase your revenue, you don’t pay us!) customers would have to give us unfettered access to their financial records. Most companies don’t want to do that, which means there would be a lot of awkward sales conversations. And even if customers were keen on opening up their books, that coordination would add an inefficient layer of bureaucracy that would slow down backend pricing operations. This idea was a non-starter.

With MTUs, customers know how many users they have, as do we, so it’s simple for both parties.

Is it scalable?

Can the model apply to both tiny companies and giant ones – and can it grow comfortably with each?

The goal here is to strike a balance between affordability for smaller customers and volume discounts for the larger ones.

To figure out if something is scalable, you have to ask yourself a question: are there several orders of magnitudes of difference separating the smallest and largest value of the metric you’re looking at? For us, project-based pricing wasn’t scalable, because there wasn’t a consistent distribution between the smallest and largest amount of projects most customers have.

Is it aligned with value?

This was our biggest consideration. The answer, surprisingly, was black and white. We ran regression analyses for every metric I’ve mentioned (and many more) to see which correlated most with revenue. Monthly tracked users won by a landslide. Event volume didn’t pass the test.

Nor did another aspect of our pricing: people profiles. Mixpanel is most powerful when you use events and people profiles in tandem. We were selling them as two separate SKUs, which was leading our customers to buy one or the other.

People profiles are a faster and cheaper way of organizing data than solely using events, allowing us to pass cost savings and performance benefits on to customers. They’re also more powerful; they allow you to look at users’ current states and past states so that you can see a full view of the customer lifecycle. This is something our competitors can’t do.

We needed a pricing structure that didn’t make this advantage seem like a hassle to buy (good news: with MTUs, people profiles and events will no longer be sold separately!).

Here’s a quick rundown of how monthly tracked users, events, and people profiles compared when judged against the five criteria above.

We finally had a clear answer: monthly tracked users. A brief sense of relief ensued, but things are never that simple. We’ll continue researching and testing pricing curves, feature bundles, and more in the beginning of 2019 to make sure our new model gives customers the most value possible.

Small but important things to think about before you start

To wrap up, I’m going to leave you with a few pieces of advice from the team at Mixpanel for anyone else who might be re-evaluating their pricing structure.

  1. Only charge people for what they need. For example, every Mixpanel customer should have people profiles, while only some customers need our messaging product. How do we make sure every customer automatically gets people profiles, while only those who want messaging are the ones paying for it?
  2. Test early. We made sure we started testing from the very beginning by offering a small subset of price sensitive current customers the opportunity to move to the new model and supported each transition manually.
  3. Involve sales early on. Include sales from the get-go, so they have time to voice concerns and understand the value of the changes. Your pricing plan will be better for it, because they know what they can and can’t sell, and you want them to be able to explain changes to customers and prospects with confidence.
  4. Figure out a plan for customers on existing plans. Will you allow them to stay on old pricing plans for a period of time, and if so, how long? You’re either going to frustrate your customers by forcing them to switch to a new model, or frustrate your operations team by forcing them to support multiple pricing models. What’s the best choice for your business right now?
  5. Don’t neglect the backend. You’ll have a lot of code to update when you change pricing units. Things that used to happen automatically – like upgrades, for example – will need to be tinkered with. Have a plan in place early on to ensure that happens.

And most important, do not force customers to transition to your new pricing model until you verify that you’ve tested every possible scenario, and ironed out every kink. We’re still going through that process.

Just like any good renovation, it takes a lot longer than you’d think.

Get the latest from Mixpanel
This field is required.