Pricing is a tricky question, since this kind of service is an industry first, with many variables to keep in mind. But we wanted something simple. We didn't just want to pass down the raw costs of the service. This would have made the billing amount unpredictable and very complicated for the developers.
We wanted one number, that can easily be understand.
Paying in volume is the easiest way, we could come up with. That is how everybody think about notifications, similar to text messages on a phone plan and here are the details:
Sandbox and Production
- unlimited users
- unlimited apps
- token registration is free (see the documentation for details)
- 1000 notifications per month/per account free
- 1000 notifications for 1€
- pre payable
- notifications valid for 3 months
- notifications are account wide usable by all apps, pool with friends if you want
This means in certain limits the sandbox environment is free. We like to try before we buy and I guess most of you are the same here.
To give you a hint on how you can calculate your costs, use this easy formula.
Costs of one notifications per customer, per year.
1 notification * 356 days = 365365 / 1000 = 0.365€ per year, per customerThis means for 1€ per customer you can send roughly 1 notification per day to a customer for the next 3 years.
If you leverage tools like the Apple In-App Purchase framework, you have an easy way to pass this costs on to the customer in a recurring way and do not have to incorporate those costs into the application price itself. Also it can represent an additional incoming stream from your application, for the entire life cycle of the application.
Let me know what you think.
Posts
6 Kommentare:
Pricing seems OK. However I would like to see a model where the notifications are recycled after 3 months. I suspect that at the beginning any app may not have a great uptake (there are also advertising to take place to create higher uptake...) All this takes time.
Could you have a model where the first 1000 notifications are not bound to 3 months?
I would also think that in my application, I would offer the first 10 messages for free and then start to charge for bulk messages (100 messages for instance).
Is there a way to dynamically increase this on your side without impacting the service on our side? I was thinking for instance where you could notify us when a threshold would be met.
Even if your app does not take off after a year, we are talking about an investment of 4€ right. Sounds like this should be covered by the first 2 sales of your app in the store.
Jesus
True, makes sense. However, is there a way to cover the rest of my "concerns" regarding usage and blocking the account if the 1000 threshold is reached? Would you send a notification? Would you offer the service to automatically replenish the account when a specified threshold id reached?
The math still doesn't really add up for me. Here's how I'm seeing this. Suppose I have a free ad supported app and I want to send out on average 1 notification per user/day. I'm now looking at $1 day/1k active users. As it stands I'd be pretty happy to make $1-$2 a day per 1k users right now. If I'm only making that much, the $1 a day per 1k users starts to sound really pricey.
What I'm interested in is how companies like Hunch, Certona, iLoopMobile, Baynote, Loomia, etc. price their API engines for managing reputation, sentiment, location, recommendation, behavioral, etc. I'm getting a sense of it from the models discussed in these and other posts, in that there seems to be some consistency, especially in terms of the cross-selling and 5% per actual sale, but I'd still like to know more. Let me know your thoughts.
Seth Kaplan
Post a Comment