On Aug 8, 2008, at 7:01 PM, Emily Ravenwood wrote:
On Aug 8, 2008, at 6:24 PM, Highlander II wrote:
having more than 30 userpics. I'd pay $15/yr for 50 or 60 or 100
userpics, because I'd use that, but I don't want to pay $25 a year
for 30 userpics, [x] voiceposts and [x] amt of photo storage
space, plus all the other pd features that I didn't do anything
with, because I *won't* use those.
If I've understood what D said correctly, though, basically you
*are* paying that $25 only for your extra userpics, because that's
what, of the paid suite, you use. And the reason the price is as
low as that is that you *don't* use the voiceposting, whereas
another user might use voiceposting a lot and only use a few
userpics. In a way, it's a la carte already, with each user
choosing which elements to apply her/his money to, and the finance
admins in the background calculating how much the average price of
paid-use is. And it works out, across the whole service, because
almost no one uses everything.
I may have misunderstood, of course, but that was the shape it
sounded like to me. Which would mean that paying only for userpics
would be likely to be more expensive than paying for the whole paid-
bundle.
You are exactly correct and have not misunderstood at all!
Mark mentioned in another message that I was looking into a la carte
pricing for DW (before it was even DW -- this was back when we were
calling it HypotheticalJournal), and the more I did the numbers, the
more it just flat-out didn't work out to be cost-effective for us. We
can offer *more* userpics if we *don't* offer a la carte pricing than
we could if we did, and the cost of a la carte userpics -- without an
associated paid account, I mean -- would be severely cost-prohibitive.
This is counter-intuitive, I know. It's a hard concept to
communicate. Some numbers will probably help here, even if they're
totally theoretical. (Which they are; like I said, Mark and I didn't
break down the numbers this far.)
Let's talk about userpics in specific, because they're what's being
used as a discussion point here. Say that we have 10,000 users, and
-- after having crunched our numbers and watched our bandwidth and
disk usage -- we decide that we can support serving a maximum of
500,000 userpics per month. The temptation is to divide the one into
the other and come up with the result of 50 userpics per user and
have done with it. The slightly more complex solution would involve
some more complex math: assume that X% of those 10,000 users are
paid, and set up an equation to balance out giving more of the
"userpic pool" to the paid users; that's beyond my quick-email-
explanation math-fu, but it's totally doable.
If you do that, though, you aren't taking into account that not all
of those 10,000 users are going to be using all of the userpics that
you allot to them. (I don't remember the exact figures on LJ, and I
was always very suspicious of the results we got out of our data
warehouse because there were some troubling inconsistencies, but
IIRC, the percentage of permanent account holders or people with the
extra userpic add-on package who had maxed out their userpic slots
was surprisingly low: over 90% of people who had the maximum userpic
slots available weren't using the maximum, and many of them were
barely using half.)
So, what you do is look at the numbers, and try to set up an even
*more* complex equation based around what the usage rate of userpic
slots is going to be: okay, we've got 10,000 users, and let's say
that 5% of them are paid, and we've set aside 50% of the userpic pool
for paid users, which would give us 500 paid users at 250 userpics
each, only we think that we're going to get a sliding scale of
userpic usage where (let's make this example a little easier, since
the actual accounting for variable use would be way, way complex) 25%
of those 500 will use 25% of their allotted space, 25% of the 500
will use 50% of their alotted space, 25% will use 75% of their
alotted space, and 25% will use 100% of their alotted space ... that
means that you've got, rounding a bit because we can't have half
userpics:
125 people using 62 userpics (7750 userpics)
125 people using 125 userpics (15625 userpics)
125 people using 187 userpics (23375 userpics)
125 people using 250 userpics (31250 userpics)
That gives a grand total of 78,000 userpics in use -- a far cry from
the 250,000 that we decided we could support.
So instead, what you do is play around with the userpic slot numbers
until your projected use comes out as close as possible to the use
you think you can support, lower the number by a bit to give yourself
a bit of wiggle room, and make *that* the number of userpics that you
can offer. The 25% of people who are going to max out their userpic
slots are supported by the 75% of people who won't ever come close.
That way, we can offer a much higher number of userpics for that 25%
of people who *want* to max out.
This is how you set your limits for anything that costs you money:
you roll the dice and guess how many people are going to use it, how
much they're going to use it, and how much it's going to cost you,
and then you guess, based on how much money you think you're going to
be bringing in, how much of that cost you can afford to bear.
Now, let's assume that we can let people buy the extra userpic add-on
without the associated paid account. This changes how many people are
using the userpics -- thus skewing the numbers of what we'd set aside
for the "paid user" userpic pool. Suddenly, we have to design our
account levels taking into account the fact that anyone can come and
pay a negligible amount and skew the numbers around at any time.
Sure, you'd be charging for that add-on, but I'll be absolutely
honest with you: Userpics are the most expensive thing that an LJ
clone site can offer. Way, way more expensive than photo hosting or
phone posting or any one of the other paid features. Far and above
more expensive than any of the other features. This is because
userpics are used in so many places in the site, and are displayed
under so many circumstances. Photo hosting, for instance, might use
more disk space, but those photos are relatively infrequently
accessed, so they use way, way, way less bandwidth. And the cost of
userpic delivery is one of the few costs that *doesn't* experience an
economy of scale; for most features, the more they're used, the less
it costs per use, whereas for userpics, it's the exact opposite. The
more different userpics someone's using, the more they cost, because
it means less chance that a given userpic (that a user is using) is
cached in the browser, more data transfered when someone goes to look
at the allpics page, more data transfered when someone goes to the
userpic selector, etc.
So, buying a paid account on DW is not "buy a whole bunch of features
I won't use in order to get the one that I will", it's "buy a paid
subscription to subsidize the site's operations for everyone, and in
exchange for your contribution, you get acccess to a bunch of stuff
that we can't offer everyone for free, because it would cost us too
much". It's still not cost-effective to offer too *much* of those
things that cost us money -- especially userpics, because of the lack
of economy of scale. If you break down what all of the "paid account"
money on a LJ-code-based site is being used to support, userpics are
far and above the largest cost. The price point we'd have to set for
the userpics alone would wind up being something like 90% of the paid
account price. That's vaguely silly.
And sure, if we offered the ability to buy userpics alone, we might
get people who wouldn't otherwise pay money to the site paying for
userpics alone -- but we'd get far, far more people who stopped
paying for a "paid account" and instead selected the (cheaper)
userpic-only option. Userpics might be the *most* expensive feature
for us to offer, but additional userpic slots are not the only paid-
only feature that costs us money, and just like people who pay for
those features and don't use all their userpic slots subsidize the
people who do use all of their userpic slots, the people who pay for
userpic slots and don't use any of the other features subsidize the
people who make maximum use of those features. With the loss of those
people subsidizing everything, it would upset the delicate economic
ecology of the service, and mean that we'd wind up having to lower
the limits for *everything*, across-the-board.
Now, we *do* know that there's a real demand for userpics -- you'd
have to be blind to miss it -- and we know that the people who are
going to max out their userpic slots no matter what really want more.
There are two major things we're going to be doing to address this:
1). For about half the people who are at or near max userpic usage,
they don't actually *select* the userpics regularly, they just have
them on hand because they don't want to delete them or they want to
use their allpics page as a gallery. For these people, we'll be (down
the road) working to integrate photo hosting with the userpic upload
page, so you can swap userpics in and out of your photo hosting space
more readily when you need them. That way, people won't need to keep
a bunch of icons that they only use once a year or so around for the
other 364 days, taking up space. This obviously won't help the people
who regularly use all of their entire userpic allotment, but it can
help some of the people who don't.
2). We're going to have, not one, but two levels of 'paid account'
-- pay us one amount of money and get one set of limits, pay us more
and get a higher set of limits. This is kinda like the NPR donation
model, where the more you donate, the more swag you get :)
We may also, down the road, allow people to purchase additional
userpic bundles in increments of $number -- something like, for every
$10 you pay you get another 100 userpic slots, etc -- but that puts
us straight back to square one in terms of needing to redo the entire
code to support a different account structure model, which is
something we're really hoping to avoid doing. It's a long
explanation, but basically: the LJ code can only support a limited
number of account capabilities, and there's zero support for bundling
add-on features (and it would be very difficult to implement it).
LJ's add-on features, like extra userpics or extra disk space, are
very binary: they're either on or off, not sliding-scale.
LiveJournal.com itself has done some work to get around this, and I'm
interested in seeing how they're going to progress, but that code,
like their entire payment system, is non-GPL and thus not available
for DW to use or adapt. Even if LJ solves it in a way that we'd like
to implement, we'd still have to reinvent the wheel.
--D
--
Denise Paolucci
[EMAIL PROTECTED]
Dreamwidth Studios: Open Source, open expression, open operations.
Coming Summer 2008!
_______________________________________________
dw-discuss mailing list
[email protected]
http://lists.dwscoalition.org/cgi-bin/mailman/listinfo/dw-discuss
