[DW Discuss] Paid account design (was: RP use cases and styles)

[Denise Paolucci]

On Aug 7, 2008, at 9:10 PM, Highlander II wrote:



> This was one of the things I never understood about LJ - why can't  
> *I* choose what my $$ pay for on my paid acct?  I may have ZERO  
> interest in voice-posts or photo space or icons - but, then again,  
> I may want icons galore!  So, instead of paying for something I'll  
> never use, why can't I allocate that I want 500 icons/userpics and  
> NO voiceposts and NO image hosting, or that I was [x]MB of image  
> hosting and none of the other stuff?  I know, K.I.S.S. - from a  
> managing standpoint, but from a 'customer service' standpoint, it's  
> kind of a bad plan.  (And this isn't directly related only to RP  
> stuff.)

You had to ask this, didn't you. *cracks knuckles*

The very, very simple answer (and it is *exceedingly* simplified --  
the real answer involves about five pages or so) is that in order to  
do something like this on LJ, it would require a rewrite not only of  
the LJ-specific account payment system (which is complex, Byzantine,  
crufty, and somewhat akin to the fabled Necronomicon in its ability  
to destroy the minds and sanity of men and women confronted with it)  
but also to the entire codebase, to completely change the model of  
what a 'paid account' is and how the code interacts with it. Given  
the complexity of the code and the fact that the account structure  
model is so fundamentally rooted into every decision everywhere, it  
would entail, in essence, a year's worth of engineering work, with  
zero guarantee of not breaking anything in the process and, in fact,  
a very good chance that things *would* break. (For those who feel  
that I'm exaggerating here: if I recall correctly, automatic payments  
took something like six or seven months, and that was fairly self- 
contained: ie, not touching on everything else in the code.) The  
potential rate of return for a project like that in no way approaches  
the risk or the effort expended, and the end result would most likely  
involve a serious loss rather than an increase in revenue.

There are many, many other considerations to take into account:

	* Different features have different costs to the service, which are  
risk-managed across a large group when they're available to everyone  
(because not everyone uses all the features to their full extent) but  
which would be prohibitive on an individual basis, so a site is  
actually able to offer higher limits when bundled as part of a  
package. For instance, a site might be able to offer 10GB of photo  
hosting space to all its users based on the assumption that 50% won't  
use it at all, 40% will use it a little, 8% will use it a lot, and 2%  
will use it to the maximum. When that's bundled as part of a package,  
you get people paying for the package for any one of a number of  
reasons (voice posts, extra userpics, etc), all of which, again, have  
different costs, so someone in that 2% of maximum-users will be in  
the 50% who don't use another feature at all. That way, the costs of  
each feature are spread out over a wider pool. If users could pay  
only for the features they wanted or only the features they'd use  
heavily, that benefit would evaporate, and the site would have to  
either offer (much) lower limits or charge (much) higher prices.

	* People would also only pay for the features they'd use heavily,  
skewing those usage figures even more, or feel like they had to use  
the features they'd paid for in order to get their money's worth,  
thus upping the usage (and also the site's costs).

	* A-la-carte pricing might work for the major, showy things such as  
userpics, photo hosting, or voice posting, but what about the little  
minor paid features like the forwarding email address or comment  
editing? You wouldn't be able to charge more than a dollar or so per  
year for those, tops, which if someone is paying monthly or bimonthly  
gets us down to pennies, which gets us into:

	* Sites lose money on credit card or PayPal transactions below a  
certain threshold due to merchant fees, making it not cost-effective  
for the site; and also:

	* What happens when you release a new paid account feature? People  
won't know about it in order for it to be something they want to pay  
for, which means you've either just coded a feature that nobody will  
ever use (waste of time and effort, thus discouraging development) or  
you have to bundle it with one of the other features, and we're right  
back to the old model, plus:

	* Releasing a new paid account feature that people would have to pay  
for separately means that you have people at different stages of  
their paid account time paying to turn that feature on, which means  
you either a). have to keep track of multiple expiration dates (your  
userpics expire on 4/1/09, your storage space expires on 4/9/09, your  
phone posts expire on 6/19/09, etc ad nauseam) or b). pro-rate the  
cost of the feature to the end of the subscription period, which is  
an administrative nightmare, a usability disaster (nobody ever, ever,  
EVER understood pro-rating with automatic payments on LJ, ever, no  
matter how it was explained; the support volume was legion), and  
leads you back to the problem of what happens when someone wants to  
add a $1-a-year feature three days before the expiration of their  
subscription, thus leading to a $.0082 charge, neatly cycling around  
to the micro-payment problem again.

	* Having to pay to activate a single paid feature means that people  
wouldn't pay for it unless they were sure they wanted it, but there  
are so many features on LJ that people don't realize how useful  
they'll be until they try them -- for instance, when phone posting or  
post-by-email was introduced, I saw so many people who said "I'll  
never use this, ever", and about half of them are now regularly  
posting by phone or email. A-la-carte pricing eliminates the ability  
to discover new features and new uses for old features.


Even if you're not talking about true a-la-carte pricing, instead  
having a single level of paid account with a pool of credits which  
could then be applied to specific subsets -- ie, your $25/year gives  
you 200 credits, every 10 userpics is 10 credits, every 5 phone posts  
is 10 credits, etc ad nauseam -- you run into equally serious problems:

	* What happens when people run out of credits and want to buy more?  
Again, you have to either keep track of multiple expirations or pro- 
rate.

	* What happens when people want to switch their credit allocation  
mid-year? You have to gracefully handle expirations on things that  
expire, and over-engineer solutions to things that don't expire like  
creating and applying custom styles, etc. People would game the  
system like nobody's business, to their benefit but to the site's  
detriment.

	* What happens when people hit the end of the year and haven't used  
all their credits? You'd have to either bank them somehow (which  
accountants *hate* -- under accrual-based accounting, having all of  
that unrealized revenue floating around out there gives accountants  
hives), or pro-rate the cost of the yearly renewal to account for the  
difference between a full set of credits and a pro-rated set of credits.

	* This still doesn't solve the problem of cost-pool-management. Some  
paid account features are expensive and popular; some are expensive  
and less popular; some are cheap and popular; some are cheap and less  
popular. They all support each other. If someone puts all their  
credits to an expensive-and-popular feature, they'll be happy, but  
the site will be losing money on them. (I don't think LJ ever worked  
out what each individual userpic costs them to store and serve, and  
our back-of-the-envelope calculations for DW didn't break things down  
that far, but userpics fall into the 'expensive-and-popular' category.)


All of this is a very longwinded way of saying: there are very,  
*very* strong business reasons not to do it that way. Neither system  
(the a-la-carte system or the credit system) is inherently unworkable  
as a whole -- there are some services out there that use them quite  
successfully. (Wordpress uses the credit system, I think.) But as it  
stands now, without either an investment of serious engineering time  
or an investment of moderate-to-serious engineering time + some  
really, really, really hacky workarounds, they're unworkable for LJ  
or a site running on the LJ codebase.

--D


-- 
Denise Paolucci
denise at dwscoalition.org
Dreamwidth Studios: Open Source, open expression, open operations.  
Coming Summer 2008!