3 ms·

Excellent analysis here. The cost of the free users really made me cringe. For what I'm doing, cost for free and premium is pretty much the same (a couple datab

Excellent analysis here. The cost of the free users really made me cringe. For what I'm doing, cost for free and premium is pretty much the same (a couple database rows), so I can afford to carry a lot of freeloaders. I can't say I planned that, though. I got lucky.

StavrosK 16y ago
Yep, most services won't have anything approaching our cost. A commenter on the blog offered a good compromise: Send the user an email after, say, two months of them not logging in, saying "click here to keep your account or wait 30 days to have it cleared out". I'm guessing that would take care of cleanup very very well, while not inconveniencing users in the least. Users who use the service frequently will never even see the email, since only inactive users get it. We might implement that very, very soon.
- mr_luc 16y ago
  That sounds fantastic. I wish more cloud services realized that they can have a pretty generous policy re: killing user's data. It's like timeouts in Redis/memcached: doubling the TTL won't generally double memory usage, or anything close to it, for most types of data. The more important issue is having timeouts vs. unbounded waste; the length of the timeout is so much less important that you could afford to be pretty generous.
- DJN 16y ago
  One way to deal with the "stale data" problem is to prune old users from the system, but many people will be understandably dissatisfied with this, and it is not recommended. I don't think you should worry too much about this. Someone who abandons a free service for an inordinate amount of time shouldn't expect to see their data. Especially when the cost of storing such data isn't nominal. Send them one or two reminders and you should be fine.
  - StavrosK 16y ago
    Yep, that makes sense. We're actually just implementing this now, hopefully it will solve our problem (it looks very promising, from some initial data crunching we ran), and is very easy to implement. We plan to send an email one month after the user's last activity, and then delete the documents (just the documents, not the account, just in case) a month after that.
- DJN 16y ago
  One way to deal with the "stale data" problem is to prune old users from the system, but many people will be understandably dissatisfied with this, and it is not recommended. I don't think you should worry too much about this. Someone who abandons a free service for an inordinate amount of time shouldn't expect to see their data. Especially when the cost of storing such data isn't nominal. Send them one or two reminders and you should be fine.
- tomjen3 16y ago
  Alternatively you could make storing a snapshot a premium feature, and only offer it on the paid plans, or do as dropbox does and offer full restore only for paid users (the others gets the newest version, and the ability to restore any version that isn't more than 30 days old).
  - StavrosK 16y ago
    That would probably cut down on our usage a lot, but we think that that feature is useful enough to everyone that it should be a core feature, and we'd have to index the page anyway so it would consume a bit of data (not as much as storing the entire page, but still). I think that, by lowering the free limit to 300 and culling inactive users' data, we won't need to worry about cost again. We are already in the green (very much so) from the great support we have gotten from paid users, but this will allow us to focus on improving the service rather than worry how we'll scale all that abandoned user data.

StavrosK 16y ago

Yep, most services won't have anything approaching our cost. A commenter on the blog offered a good compromise: Send the user an email after, say, two months of them not logging in, saying "click here to keep your account or wait 30 days to have it cleared out". I'm guessing that would take care of cleanup very very well, while not inconveniencing users in the least. Users who use the service frequently will never even see the email, since only inactive users get it. We might implement that very, very soon.

mr_luc 16y ago
That sounds fantastic. I wish more cloud services realized that they can have a pretty generous policy re: killing user's data. It's like timeouts in Redis/memcached: doubling the TTL won't generally double memory usage, or anything close to it, for most types of data. The more important issue is having timeouts vs. unbounded waste; the length of the timeout is so much less important that you could afford to be pretty generous.
DJN 16y ago
One way to deal with the "stale data" problem is to prune old users from the system, but many people will be understandably dissatisfied with this, and it is not recommended. I don't think you should worry too much about this. Someone who abandons a free service for an inordinate amount of time shouldn't expect to see their data. Especially when the cost of storing such data isn't nominal. Send them one or two reminders and you should be fine.
- StavrosK 16y ago
  Yep, that makes sense. We're actually just implementing this now, hopefully it will solve our problem (it looks very promising, from some initial data crunching we ran), and is very easy to implement. We plan to send an email one month after the user's last activity, and then delete the documents (just the documents, not the account, just in case) a month after that.
DJN 16y ago
One way to deal with the "stale data" problem is to prune old users from the system, but many people will be understandably dissatisfied with this, and it is not recommended. I don't think you should worry too much about this. Someone who abandons a free service for an inordinate amount of time shouldn't expect to see their data. Especially when the cost of storing such data isn't nominal. Send them one or two reminders and you should be fine.
tomjen3 16y ago
Alternatively you could make storing a snapshot a premium feature, and only offer it on the paid plans, or do as dropbox does and offer full restore only for paid users (the others gets the newest version, and the ability to restore any version that isn't more than 30 days old).
- StavrosK 16y ago
  That would probably cut down on our usage a lot, but we think that that feature is useful enough to everyone that it should be a core feature, and we'd have to index the page anyway so it would consume a bit of data (not as much as storing the entire page, but still). I think that, by lowering the free limit to 300 and culling inactive users' data, we won't need to worry about cost again. We are already in the green (very much so) from the great support we have gotten from paid users, but this will allow us to focus on improving the service rather than worry how we'll scale all that abandoned user data.