The interesting point about this analysis is that the 'freemium' model, where you give away the service for 'free' and them upgrade folks to 'pay' has a lower customer acquisition cost than the "advertise and convert" model.
This has been a very successful strategy in the apps market for mobile devices as well.
I did not see where the cost of hosting the free users was being factored into the acquisiton costs. Presumably a large number of people are 'free' users and there is certainly an operating cost associated with that, and over time that cost accrues against your acquisition costs.
If the addressable market for 'free' use was 100x the size of the market for 'paid' use then you would be holding 100GB of data for every GB of data that you were being paid to hold. If you can net revenue for that paid GB to cover that cost then you're good to go, but if not you push back on the free size.
Google offered everyone a GB of free email space when they started gmail but they understood that most people would not use a full GB. So in the 'hosted' storage space if you are going with a freemium model you've got a spectrum between '0' where your free customers aren't actually using your system and 'max' where your free customers are all pushing right to the limit.
The other challenge with the 'freemium' model is that bandwidth costs do go up as you use more. So having a 1GB pipe to the internet might cost you $3K/month whereas having a 10GB pipe to the internet would cost you 20 - 25K$ /month. Generally those are 'burstable' prices where you pay for a minumum bandwidth usaga and you pay extra when you exceed your minimum (think minutes on your cell phone).
Having and fully filling at 10GbE pipe to the internet can easily cost $50K/month. Lots of 'little' customers can do that without providing any return. So its harder to price out the 'free' customers into the total cost.
Bottom line its a great way to analyze your web service to get a feel for whether or not you are really making money or you only think you are making money.
Unfortunately this article gets the details of S3 storage costs for Dropbox wrong. You only pay once to get (what Amazon says is) 3x copies of your data on the backend.
The article estimates that 8% of dropbox users must convert to paid to cover the cost of the free users. I think this is an overestimate since I read somewhere that dropbox do not use disk space for duplicate files. Therefore the overall cost to store files are lower.
Another thing to consider is that Carbonite throttles the hell out of your connection so that you're only able to upload at the following speeds:
* The first 35GB of data can achieve upload speeds of up to 2 mbps (megabits per second).
* Between 35GB - 200GB of data can have the upload speeds reach up to 512 kbps (kilobits per second).
* 200GB or more of data can be uploaded at up to 100 kbps (kilobits per second).
So if you use Carbonite to backup over 200GB of data, and let's say your computer is on for 6 hours a day, you can only backup 270MB a day which is useless (or 1.08GB if you run your computer 24 hours a day). I did the math and it would take 1 year 7 months for me to backup the 800GB of data I wanted to with Carbonite.
It's also not fair to compare Carbonite to Dropbox. Comparing Carbonite to Mozy would be a more leveled playing field.
I never even heard of Backblaze until now. I used to be a Mozy user until they went ahead and pulled the "Yeah remember how we said unlimited? lol jk." card. Downloaded Backblaze now to give it a try, so far it looks like an amazing deal!
I made the Mozy to Backblaze jump a few days after Mozy thanked me for being an early adopter by quintupling my bill. I only had about 250GB to back up, computer was on 24 hours, I throttled it a bit during evening hours to not interfere with Netflix, and it was about three weeks to finish the backup. I don't know if they have a graduated scale if you have to back up a lot more.
So far, I'm very happy, but I haven't had to restore yet...
I don't know either, but, I made the switch from Mozy to Backblaze (after their CEO told me via e-mail that they won't jack up the pricing), and I've been happy. (like other commenter, I haven't had to restore yet - aside from some tests)
This has been a very successful strategy in the apps market for mobile devices as well.
I did not see where the cost of hosting the free users was being factored into the acquisiton costs. Presumably a large number of people are 'free' users and there is certainly an operating cost associated with that, and over time that cost accrues against your acquisition costs.
If the addressable market for 'free' use was 100x the size of the market for 'paid' use then you would be holding 100GB of data for every GB of data that you were being paid to hold. If you can net revenue for that paid GB to cover that cost then you're good to go, but if not you push back on the free size.
Google offered everyone a GB of free email space when they started gmail but they understood that most people would not use a full GB. So in the 'hosted' storage space if you are going with a freemium model you've got a spectrum between '0' where your free customers aren't actually using your system and 'max' where your free customers are all pushing right to the limit.
The other challenge with the 'freemium' model is that bandwidth costs do go up as you use more. So having a 1GB pipe to the internet might cost you $3K/month whereas having a 10GB pipe to the internet would cost you 20 - 25K$ /month. Generally those are 'burstable' prices where you pay for a minumum bandwidth usaga and you pay extra when you exceed your minimum (think minutes on your cell phone).
Having and fully filling at 10GbE pipe to the internet can easily cost $50K/month. Lots of 'little' customers can do that without providing any return. So its harder to price out the 'free' customers into the total cost.
Bottom line its a great way to analyze your web service to get a feel for whether or not you are really making money or you only think you are making money.