denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
Denise ([staff profile] denise) wrote in [site community profile] dw_news 2024-09-19 01:20 am (UTC)

This is a really common suggestion, but that's not actually how our paid accounts work! People think of it as "you're paying this much money for this much in services, so obviously it would make sense to offer a 'lite' version that's just one of the paid account services for less than the full paid account amount", but the prices actually aren't set exactly by how much extra the paid features cost us to offer (or even how much the paid services cost to offer + a little bit of a markup to help cover the cost of free accounts). What I did pre-launch was sit down and make the Mother of All Spreadsheets, making a whole series of (educated) guesses about what our fixed costs and what our usage-dependent costs would be, which of our usage-dependent costs would depend on total registered accounts and which would depend on active use, what percentage of people would pay for their accounts (and what percentage of those would be regular paid vs premium paid), what our likely patterns of use would be over time, etc. (And each of those factors had three columns: pessimistic, realistic, optimistic.) (Then I factored in what it would cost to offer the paid services and took that as a 'discount' on the value of the paid account, etc, etc.) The plan was always to aim for a 1:10 ratio: when we launched the site, we were planning for every paid account to subsidize about ten free users' worth of costs. As it turned out, a roughly 50:50 mix of the pessimistic and realistic cost assignments with that 1:10 ratio worked out to be almost exactly what LiveJournal was charging for their paid accounts at the time, adjusted for inflation, which was further confirmation to me that I'd probably gotten it about right.

I have not been able to actually locate the Mother of All Spreadsheets (I have a sneaking suspicion it was in one of the folders that accidentally was not getting backed up, which of course I discovered after a hard drive crash, sigh) to go back and check my figures against it, but empirical evidence showed that we, indeed, got it pretty right: the costs wound up being a little bit heavier on the 'pessimistic' side of the estimate but the percentage of users who paid us exceeded the 'optimistic' estimate, so it all sort of worked out in the wash. That ratio has slipped a lot over time -- I haven't done the full formal calculation in a while but the quick and dirty, back of the envelope math on 2023's numbers show it's about 1:35 now and it's almost entirely because of how certain costs have risen, which is why we're looking really hard at inflation as the likely cause. But if we do raise prices, it won't be "the paid account features cost us more to offer", it'll be "the number of free users each paid account subsidizes has slipped too far from the 1:10 ratio we were aiming at".

Basically, paid accounts aren't just because they cost us more to offer, although that has a small bit to do with it: it's because we need to have a way to cover what free users cost us to support, and the way we did it was setting the prices and features so that paid users subsidize free users' use of the site. Some people use more of one of the paid features, some people use more of another: we can 'oversell' icon slots, for instance, because not everyone maxes out all the icons they have available to them, so we 'price in' a certain level of overage. Some of the paid features are "hey, this is a tiny perk that we can throw into the paid package because it will be the thing that makes people find the paid account valuable", some are "this legitimately does cost us more to offer", some are "actually, if we let everyone access this feature the support burden will just be too high but we can give it to a subset of people" -- there's a wide range. Between not every paid account using every paid account feature to the maximum and the fact that everyone values different elements of the paid feature set differently, the different use cases balance out over all the paid users we have.

Letting people buy accounts with just one of the paid features has two problems: one, the amount of extra revenue it could potentially bring is usually cancelled out by people for whom that's their one reason to buy a paid account (or people who always go for the cheapest option no matter what) and so they stop paying for the account priced at the price that it needs to be priced in order to properly keep up the ratio and so the option is rarely even breakeven, it's usually net negative, and two, the more options you give people, the harder it is to get them to pick one. (Our existing options are pretty much the absolute maximum that we'd ever consider having, and I have pondered so many times ending either the 1 or 2 month regular paid option, probably the 1 month because way more of it is taken up by payment processor fees, in order to simplify it further, because a lot of people do report experiencing choice paralysis when they're confronted with the options. So far I haven't, but I've been right on the verge of doing it for 15 years now, heh.)

But we really did calculate our prices very, very deliberately instead of just throwing darts or comparing with other sites! (I mean, we did compare with LiveJournal to some extent, but that was because both Mark and I had seen enough years of payment data and costs there to know what the likely patterns would be.) They were as empirical as we could make them, and they were almost bang on for 11 years or so; it's only really once the pandemic started and prices and inflation started getting incredibly weird that it started to shake out differently. (Our costs went up 20% year-over-year from 2019 to 2020 and have been bouncing oddly around ever since in ways that are just driving me up the wall because of how inconsistent they are.)

Post a comment in response:

This account has disabled anonymous posting.
If you don't have an account you can create one now.
HTML doesn't work in the subject.
More info about formatting

If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org