|Ala-cart billing models; best practices?
||[Apr. 4th, 2004|10:51 pm]
This is being posted to lj_dev and not lj_biz because I need analytic answers, and not just hand-wavy high-level answers. Both together, though, are ideal.|
With the ever-upcoming-but-moving-again photo hosting, we'll be giving away so much disk space to paid users, and letting people pay to upgrade their quota. The problem is our existing billing system can't handle variable amounts of items, and here's why it's hard:
Say somebody buys a year paid account on Jan 1 2004, and they have 50 MB of quota.
7.5 months later, they fill that up and want more. Let's say they want 75 MB, so they need to increase their quota by 25 MB for 5 months. But maybe we only sell month units. Or 2/6/12 month units. So they buy under or buy over. Even if we let them buy exactly the number of days to hit their paid account expiration, there are people who have gotten paid account gifts going out years, and people won't always want to buy a quota extension to match the duration of their paid account. So you have to assume quota and paid account are somewhat separate. (as much as that sucks.) How to minimize the suckage?
Problem/Observation #1: what we're really selling is "MB*Months", the unit of the area formed by the rectangle of months (imagine x axis) and quota (y axis). We could sell "megmonths", but nobody would get it. We could market it as something else, but people would confuse its units with their disk quota units.
Problem #2: do we let people buy disk quota extended past their paid account time? We do for userpics, and then just note how much is remaining when the paid account expires to reinstate it later. I suppose the same would work for disk quota.
Problem #3: we don't really want to sell megmonths, even if it we could explain it right, because we probably want to offer lower prices per MB as they increase their quota ever-higher. which means 1000 units of megmonths laying along the X axis, 10 months wide by 100 MB high, is more expensive than 1000 units stacked up (1000 MB * 1 month).
Problem #4: if we let somebody buy 6 months of +25 MB quota, then a month later buy 3 months of +10 MB quota, then a month later buy 12 months of +30 MB quota, we don't want their sum quota shooting up and down all the time as different upgrades expire. It'd be nice if, come an expiration period for any of the quota raises, the remaining pieces all shorten in duration to keep the quota as-is, filling in the area. But then we're essentially working in a fluid area of "megmonths" again, and explaining to users why their gallery quota expiration is shrinking could be confusing. As would explaining why buying "12 months of +20 MB" will only get them 9.5 months, because one of their extensions is due to expire soon. I imagine what's better is let people buy "12 months of 800MB" and have it be absolute 800MB (not a relative amount), and be exactly 12 months, and just subtract from the price the area from that area the user has already paid for.
Problem #5: How to handle disk space gifts? (Can't expose the recipient's account status.) I imagine the simplest answer is don't. Just require coupons as gifts. (as we do with userpics)
Constraint #5: should people be able to lower their quota? Or just let it expire? Can they turn 1 month of 200 MB into 2 months of 100 MB? Easiest answer: no. If so, requires tons of checks to prevent abuse.
Problem #6: if quota does fall, what's the policy on the gallery? Show all? Show some pics? Disable all, until quota is fixed?
Problem #7: we mail somebody, saying they're using 720MB and their 800MB quota is expiring in 14 days, then 7 days. 2 days away, they renew, buying 750 MB for 60 days. Is that 60 days from the time they renewed, with the price deducting the sum of (2 days * MIN(750MB, 800MB) * $price/mbmonth), or do they keep their 800MB for two days and then drop down to 750 MB for 60 days?
Any advice? (or links to papers on this? Google failed me.)