Pricing is hard. We need your help.
blog.keen.io
blog.keen.io
If you need help with pricing, email me. Our company does algorithmic pricing via a REST API, I'll give Keen access for free.
To address your listed cons to utility style pricing:
1) Products aren't turned into a commodity because of how they are priced. They are commoditized when many perfect substitutions exist in the market.
2) I'm not sure if "not predictable" will go over well with your audience. Maybe you could use your own product to help people predict their bill with you. It would be a neat application of your software.
If you asked companies if they'd rather pay a random amount between 100$ and 500$, or always pay 500$, 9 out of 10 would opt for the latter. And if you don't understand why, then you've never spent any amount of time pondering a business's cash flow.
I figured, since Keen is in the business of helping people with those predictions it would be a really awesome application of their own API. Customers could see their usage as part of the visualizing product and it would help them predict their bill.
Why so ? You are perhaps referring to a business's ability to project/forecast cashflows which is critical but even then, if the number is always going to be less than or equal to 500, I would rather choose the first option.
That's also a big argument in favor of formulating seat-based pricing models as blocks as opposed to per seat. It reduces the update frequency.
In that case, totally agree with you. If, however, it was his own money, I am sure it would be a different story.
- always pay $500 vs. pay a random amount between $100 and $500, except when you have a really heavy month and you pay $3,000.
Utility pricing without the ability to set caps is problematic.
Certainly, if we go this route, we'll make sure our users can readily monitor their usage so as to minimize surprises. Even still, we don't want our customers to have to kill the service in the middle of a billing cycle.
Oops, there goes thousands of dollars.
FWIW when I was recently involved in pricing an API, after much thought I decided the best option was tiered pricing with different rate limits (requests per hour) at each tier. At least with that structure you don't have to worry about angry customers with huge bills or customers bankrupting you with usage gone wild that they'll never be able to pay for.
The other risk of pure usage based pricing is that it attracts a cost-minimization approach to usage. That was my original plan but speaking to prospects put me off when I realized that many were willing to forgo all business sense and invest crazy amounts of development time to minimize API costs. And you still have to support them. (NB Yes you can have a base charge but many seem to think that inherently unfair when they have to pay for usage on top.)
We'll edit the blog post to add a bit more background
update:
here's the working copy:
--
We make three kinds of APIs:
-data collection APIs
-data analysis APIs
-data visualization APIs
Once your app is sending us stuff, your product manager may ask you to make her a little analytics dashboard, so she can agonize over it every morning. For instance, this dashboard could have answers to questions like "How many people opened the app each day over the course of the last week?" That question (and many way more advanced ones) can be answered using one of our analysis APIs (in this case, the Series API https://keen.io/static/docs/data_analysis/series.html)
Finally, suppose a few weeks later she's tired of staring at numbers and wants to see this information graphed visually in a line graph. That can be done using our visualization APIs (not yet released).
These are all great questions. Thinking long-term, the answer should be yes to all of those questions. We should save time (and therefore money) and be a vehicle for increased revenue. And, we intend to do a lot more writing about how folks are using/could use/should use our product. At the same time, in the long run, we’re all dead. So, in the present, we’re looking to work with Series-A type companies who are in the midst of early product development. We want to work alongside them to understand their analytics needs and tweak our roadmap accordingly.
Those customer sketches/white papers are extremely important to us. We’re still learning (and probably always will be). It’s my hope that we will be in a position to blog about customer experiences soon. Dominos are certainly lining up for that.
In addition to these questions, I'd also think about how to reach a point where customer feels a high switching costs. It seems that a service like yours can be offered by many, but the important competitive advantage is that the more customers have stored data on your service, the more 'expensive' for them to switch.
What part of your service increases in value the longer someone uses it? Is it the historical data of the customer's own app, or is it the cross-sectional data of apps in other categories? As mentioned above, mixpanel is a good example, so is new relic.
Even if you use utility pricing, it's still best to frame it in terms of something meaningful to your customers.
(That said, I'm guessing that simple tiers + custom enterprise plans if needed will be the way to go. The trick is figuring out how to set them up.)
Do you have a full blown example use case of how a customer would use keen.io?
The getting started page shows an example of inserting an "event" and counting it, but I'm not sure what that means, or what the end goal is, exactly.
What do you think of it?
Mixpanel's pricing is utility based under the hood (they automatically pro-rate or upgrade the plan based on what is cheaper), but the marketing copy is tier based. That looks to be a good approach.