[HN Gopher] Usage-based pricing isn't always best
___________________________________________________________________
Usage-based pricing isn't always best
Author : AnhTho_FR
Score : 90 points
Date : 2023-02-17 00:56 UTC (2 days ago)
(HTM) web link (chrisreuter.me)
(TXT) w3m dump (chrisreuter.me)
| brilee wrote:
| "There are only two ways to make money in business: bundling and
| unbundling"
| lpolovets wrote:
| IMHO the key to usage-based pricing is that the usage metric that
| pricing is based on must always be a fraction of the value metric
| in the customer's head. Otherwise customers start thinking about
| how to game the pricing system, which leads to them using your
| product less and also getting annoyed that they have to think
| about pricing so much.
|
| For example, let's say you have a product that manages AWS cloud
| spend in a way where you can always reduce AWS costs by 10%, and
| you charge 2% of cloud spend for this product. This is a great
| example of usage based pricing: whenever the customer is paying
| you 2%, they are saving 8%. This is a no-brainer, and the
| customer will use your product as much as possible.
|
| On the other hand, lets say your product can sometimes save 30%
| on AWS spend, and sometimes it can't save anything at all. For
| example, maybe it's great at optimizing spot instances but not
| reserved instances, or it's good for some AWS locations but not
| others. Now pricing based on cloud spend sucks because you're
| forcing your users to think hard about whether to apply your
| product to each individual piece of cloud infra. This is a crappy
| user experience, and customers will leave if something friendlier
| comes along.
|
| On a side note, a more subtle example here is Heroku. When you're
| a small Heroku customer, paying a 200% premium on cloud spend is
| fine because you save _so much_ by not hiring a team to manage
| your cloud infra. However as you grow, the price you pay
| increases much faster than the value you receive. As a result,
| lots of customers graduate once they hit a certain size.
|
| This is a general pricing principle I've been thinking about: you
| want your price to be proportional to your value. Doesn't matter
| if you're charging by usage, or per seat, or a flat price -- you
| want the decision to be a clear win for your target customer all
| of the time.
| ip26 wrote:
| I think your pitch here really just ties back to simplicity in
| pricing. Simplicity in pricing is a strong customer desire.
| When your service is so valuable that it's a no brainer, the
| pricing is de facto simple; pay the final bill and be done.
| When the value add is thinner or more uneven, it's ok, but
| pricing becomes complex and customer preference will be for
| simple pricing structures such as all-you-can-eat.
| JohnFen wrote:
| I agree. I avoid usage-based pricing in favor of a flat fee
| whenever possible because of this. It's very rare that the
| hassle of having to work out the charges is worth it to me.
| lpolovets wrote:
| Simplicity is definitely part of it! But the value/price
| alignment piece is also important.
|
| Take Hacker News. If they charged $50/mo, I'd pay that. But
| if HN charged $1 per homepage visit, I'd start visiting a lot
| less. Maybe once or twice a day, but not 20x/day. Both $50/mo
| and $1/visit are simple pricing methods, but my value is not
| the same with each visit given the homepage doesn't change
| much hour by hour. So maybe it's really worth $5 for the
| first visit of the day and 25 cents/visit after that, and
| thus the $1/visit system wouldn't work well (for me).
| baidifnaoxi wrote:
| I agree with the premise - not all situations benefit from usage-
| based pricing. However, this discussion misses many dimensions of
| what makes usage-based pricing valuable.
|
| It's akin to a poorly developed benchmark that doesn't consider
| all the real world factors but tries to win on one vector.
|
| Here are some other intangibles:
|
| (1) Subscription pricing is difficult to scale upwards. The
| concepts of upsells and new products are difficult to execute and
| increasingly result in lower and lower adoption. Each new
| capability needs to be "sold in" with a new sales motion creating
| endless amounts of feature creep and unused features.
|
| (2) If your costs are variable and your revenue is fixed, you
| better hope your customers don't like you or your product is
| really simple. Otherwise, you risk more margin compression as
| customers use you more and more beyond what you modeled. The
| difference between your ARR and the cost to serve gets smaller.
| Like a perverse Innovators Dilemma.
|
| (3) Innovation tends to be simpler with usage based pricing, when
| done right. In a subscription model, product teams tend to be
| much more conservative. Each new sellable feature needs to be
| fully supported with training and enablement for sales teams.
| When the product fails to grow like the first product, then the
| sales team becomes increasingly more conservative. It's a viscous
| cycle.
|
| Usage- based pricing makes a lot of the above moot. If any
| existing or new benefits of the product are offered to all
| customers, then it actually aligns the incentive of your company
| and your customer. Use more to drive revenue (you) or use more to
| get more value.
|
| Of course, marginal value isn't always the same, so that's when
| usage tiers develop.
|
| Now how you quantify all this I'm not sure. But there are far
| more simplification benefits to usage based pricing.
| ptero wrote:
| This is an interesting post and an interesting discussion! But
| for me (a lowly algorithm developer far removed from IaaS
| pricing) the most confusing part of it is the meaning of "you".
| The author and comments seem to use it in critical equations
| assuming it is obvious from context and benefits whether this
| "you" is a service provider or a consumer (company buying IaaS).
|
| It would be much easier for us if folks liberally sprinkled IAAS
| "buyer" / "seller" or "provider" / "consumer" in their opinions.
| idopmstuff wrote:
| As a general principle, the best pricing structure for a product
| is one that most closely matches the value that the customer
| derives from a product. Usage-based pricing is best when each
| time you use it, you're saving your customers money. The company
| I work for makes software that helps to speed up the process of
| reviewing real estate appraisals. We help a human check for
| important issues in the appraisal much more quickly than they
| could do so themselves. That makes usage-based pricing perfect -
| every time our customers use us for an appraisal, they pay us.
| That's ideal, because the amount of time they save by using our
| software has a greater dollar value than the amount they pay us.
| It also means that when the market turns down and they need our
| software less, they're not stuck with large, fixed bills.
|
| For many tools, this isn't the case. I've worked on a lot of
| enterprise software that charges on a per-user basis. This makes
| sense for something like enterprise content management and CRMs -
| the number of people using them is roughly going to correlate for
| their value. If you hire a new salesperson, you expect to make
| more sales and thus have a willingness to pay a little more for a
| tool that helps with that.
| hinata08 wrote:
| >I've worked on a lot of enterprise software that charges on a
| per-user basis.
|
| I hate them the most, after seeing them in companies with 10^2
| - 10^3 of employees.
|
| whenever you get an intern, or when an employee could help on a
| job that isn't his, you have to get them a license. And by the
| time the licensing process has happened, someone would have
| found a solution without using the software.
|
| Then, instead of getting new licenses, some employees will just
| waste time to find someone who can access the right
| functionality on the software.
|
| Eventually, if your company doesn't have a strict whitelisting
| policy for the software that is being used, employees will just
| end up using their own open source software or free smartphone
| apps, and will ditch the software that will charge on a per
| user basis. If your company has a strict policy, they will just
| hate it.
|
| I would prefer to have a bundle, and a salesperson that
| properly estimates the value for each company, so that each
| employee can have the proper tools.
| idopmstuff wrote:
| > Eventually, if your company doesn't have a strict
| whitelisting policy for the software that is being used,
| employees will just end up using their own open source
| software or free smartphone apps
|
| We're definitely thinking of different kinds of software
| here, as this would never be the case with the kind of stuff
| I'm talking about. Whatever CRM your company uses, every
| salesperson is using. It would be incredibly obvious if they
| were using something else (their manager is regularly looking
| at reporting in the CRM), and it wouldn't ever fly. To your
| point, many people do hate it, but you can't find a way
| around it.
|
| Similar with services like Box, Zoom, ServiceNow, JIRA, etc.
| If it's important that each person have their own account,
| then a per-user model is generally pretty reasonable. You'd
| typically need this if you need to easily track which user is
| doing what and/or if you need user-level access controls.
| ghaff wrote:
| This is especially true if, as if often the case, only a
| segment of the company uses the software in question.
| Engineering probably doesn't use Salesforce. Sales probably
| doesn't use JIRA.
|
| A flat fee based on some tiered size of the company might
| still make sense and reduce some friction. But the amount
| has to work for both the buyer and seller and per-user
| pricing is just a natural fit in a lot of circumstances.
| stevencorona wrote:
| Tangential comment - but that Netezza appliance was really cool.
| I was able to use one early in my career, circa 2008. It had a
| nice cli query interface similar to psql (maybe it spoke postgres
| protocol, I don't remember) - and was blazing fast. I ran totally
| rookie-mistake filled, unoptimized queries on tables w/ billions
| of rows and got results back in ~seconds. Of course, not so
| impressive now, but was really impressive 15 years ago!
|
| They had a really wild architecture with FPGAs that, if I
| remember correctly, sat in between the CPU/disk and was used to
| offload some of query execution.
|
| It was wildly expensive + expensive to maintain, so the company
| ended up (unsuccessfully, I think) jumping to Hadoop. Crazy times
| :)
| kfk wrote:
| Within the data world, I am especially confused by usage-based
| pricing _and_ the push towards data mesh. In a data mesh you now
| have hundreds of data analysts in your company... all needing
| access (and driving consumption) to the data lake and all the
| tooling around it like on demand spark clusters, notebooks,
| lakehouses, dbts, dashboarding, catalogs, governance and so on...
| it gets really expensive to run what 90% of the times is good old
| sql. Most importantly, none of the vendors are going to help you
| optimize resources. You got a standard, highly predictable, BI
| job each Monday? Vendors will push you to use everything they
| got, while maybe an on prem server is all you need and it will be
| cheaper.
| simonw wrote:
| "Google also spent a long time in the early 2010s focusing on
| something other than SQL which, while it may seem bananas now,
| was not that crazy when everyone thought Java was going to be the
| data engineering language of choice."
|
| Anyone know what this is referring to?
| DecadeSol wrote:
| Hi there! Author here. What I was referring to was
| MapReduce/BigTable. While I think BigQuery always had SQL
| support, some customers in the early 2010s had the perception
| that Google was more interested in building a new language for
| queries rather than support something for SQL.
|
| Mike Stonebraker talked a little bit about this in the context
| of MapReduce on the dbt podcast recently:
| https://roundup.getdbt.com/p/ep38-a-romp-through-database-hi...
| [deleted]
| danpalmer wrote:
| There's another caveat to this, which is that even in places
| where usage-based pricing may be best, doing too much of it may
| lose the advantages.
|
| An example from my experience: Datadog. It makes sense that we
| pay for usage, after all things like logging and metrics scale in
| wildly different ways from product to product, and charging flat
| rates or per-user rates doesn't factor this in well enough. The
| problem is that for a feature-complete Datadog deployment, there
| may be 10-20 axes of pricing - how much log data, how many unique
| metrics, how much of your logs do you want to index, and so on.
|
| The problem comes with cost estimation. Because there are so many
| axes, we can't just take our size and figure out a cost estimate,
| we have to model out different scenarios. Does a traffic spike
| for us equal a logging spike? or Metrics? How does it impact
| second order pricing like log indexing or archival? Even when you
| know exactly how much, e.g. logging you generate, it's still all
| approximated modelling, and many teams won't have the necessary
| input numbers at the beginning anyway.
|
| Stripe's usage-based pricing works well because it's so direct -
| it's _just_ X% of revenue. Datadog 's is a pain because there are
| many factors, all of which are quite far removed from revenue.
|
| I understand that at some level this is required. They're pricing
| for compute and storage, essentially, and a cloud provider
| offering those wouldn't price them at a flat rate or per-user
| rate, but it always felt much harder than it needed to be. I'd
| almost have rather paid more, but a known amount.
|
| However,
| stingraycharles wrote:
| > The problem comes with cost estimation. Because there are so
| many axes, we can't just take our size and figure out a cost
| estimate, we have to model out different scenarios. Does a
| traffic spike for us equal a logging spike?
|
| In the case of Datadog it's even worse that they don't allow
| you to cap costs. If you have an accidental spike (e.g. some
| deployment gone haywire and relaunching containers and suddenly
| you have 100x the amount of containers as usual in a 1 hour
| time span), they will not refund it. I had to plea a lot for me
| as a solo developer, and they ended up locking me into a 1 year
| contract in order to be reimbursed.
|
| I'm convinced it's entirely deliberate and they prey upon these
| types of things. It was a terrible, hostile experience, because
| I had to pay a huge sum I did not get any value out of. I was
| so scared of using their product for the rest of the year that
| I simply wrote off the yearly subscription as a loss.
| switch007 wrote:
| > I'm convinced it's entirely deliberate
|
| I'm sure it is too.
|
| My colleagues are investigating Datadog as a vendor and I
| think they're off their heads. We're meant to be tightening
| our belts and I think we'll waste a metric fuck ton of money
| on Datadog for a gram of value. Hopefully we don't go with
| them.
| danpalmer wrote:
| > e.g. some deployment gone haywire and relaunching
| containers and suddenly you have 100x the amount of
| containers as usual in a 1 hour time span
|
| To be fair to them, I believe they bill at something like a
| 98% high water mark for the month, so you can spike briefly
| like this.
|
| I completely agree with the point though.
| indymike wrote:
| As a rule, if I can't understand the pricing in two minutes, I
| do not do business with a vendor. Also, if there is not a stop-
| loss, I view the vendor as predatory.
| drewda wrote:
| > Stripe's usage-based pricing works well because it's so
| direct - it's just X% of revenue.
|
| For what it's worth, that's how Stripe Payments works. But if
| you want to also use billing, invoicing, other additional
| functionality, then it's X% + Y% + $Z/month.
| danpalmer wrote:
| You're right, but they're all typically fractions of the
| revenue figure, so really very easy to price out. They may
| not be worth it for some businesses, but my point isn't about
| price, it's about the complexity in figuring out that price.
| drewda wrote:
| Yeah, agreed that it's all along the "dimension" of
| revenue. But the details of how Stripe prices its add-on
| functionality is different than competitors like Chargebee
| or Recurly (for subscription management) or QuickBooks
| Online (for invoicing), so it does make it hard to make
| "apples to apples" price comparisons.
| philstephenson wrote:
| It's true that with Datadog, a spike in your usage can have a
| dramatic impact on your bill. This feels true though of any
| usage model. We've all read stories about out of control AWS
| bills. Datadog does at least provide some guardrails to prevent
| things from getting out of control:
| https://docs.datadoghq.com/account_management/billing/usage_...
|
| With these usage metrics and a little bit of automation (for
| example the Webhooks integration:
| https://docs.datadoghq.com/integrations/webhooks/), you could
| stop shipping telemetry at a certain threshold.
|
| Disclosure: I work at Datadog.
| danpalmer wrote:
| My issue isn't necessarily that a usage spike impacts the
| bill, that's fine!
|
| The problem is that because of the billing complexity, it's
| hard to predict how billing will scale with usage. There are
| just too many axes. Even steady-state billing is hard to
| price out before signing up, so much so that the answer we
| received from sales was to just try it and see what the bill
| is.
|
| This becomes a road block. "I'd like to move us to Datadog! -
| Oh yeah, how much does it cost? - I won't know until after
| we've moved." - these conversations are hard to have
| internally.
|
| The product is fantastic, I'm a big fan. And the total price
| isn't necessarily bad, it's just opaque, and required a lot
| of work on my side to model out the pricing, present the
| business case, get sign-off, and manage the contract over the
| years. Not something that I, as one of ~8 engineers, wanted
| to spend my time doing.
| 323 wrote:
| Why not offer two types of pricing, a flat (expensive) one and
| a usage-after-the-fact (cheap) one.
|
| Like in Electricity markets - you can either get market pricing
| (cheaper, but very volatile) or fixed price.
| judge2020 wrote:
| That most likely is an option, where DataDog (and others)
| will happing sign an enterprise contract with you and take
| more of your money than what you end up using. The issue is
| that you're still going to be bound to a maximum
| logging/metrics/etc budget, so you still end up needing to
| estimate your usage to avoid going over your pre-paid limits.
| jerf wrote:
| Let's take the simplest example of flat pricing for a logging
| service: You pay $X and you get all the service you can
| consume. A salesperson tries to intelligently set $X for you.
| We'll even spot the salesperson full knowledge of the
| previous year of usage, and we'll even stipulate that the
| purchasing company is 100% honest about their _intent_ to
| consume, but that they do not have a 100% accurate prediction
| of the future.
|
| The problem here is the statistical distribution of the usage
| will bankrupt you as a company if you try that. People
| mentally want to model everything as nice, polite
| distributions through a combination of all the statistics
| classes they've ever taken using them (where the "uniform"
| distribution is the default and "gaussian" is if you want to
| get fancy) and internal cognitive biases around the nice
| distributions generally encountered in most real life and a
| general lack of experience with pathological ones, but the
| real distribution of consumption is grotesquely pathological
| and has huge spikes in the tail. The probability of one of
| your 10 biggest customers, which collectively account for
| ~90% of your business, getting an unexpected 10x or greater
| spike, isn't negligible like a naive high school statistical
| analysis might suggest. It is instead virtually certain.
|
| I've simplified this problem down just to concentrate on that
| bare statistical problem, which is something engineers should
| try to develop an intuition for. However, as we de-simplify
| the problem by re-introducing back all the real world
| complications, they all tend to make this problem even worse.
| For instance, give a company an all-they-can-eat deal, and if
| they _accidentally_ spike your usage because the intern
| accidentally committed a debug logging message that spiked
| their usage by 50x, they have no particular incentive to fix
| that.
|
| Naturally, in the real world you'd put limits in the
| contract... but if you think about it, flat pricing with
| limits that you can realistically hit because the limits
| really ought to be thought of in logarithmic terms, rather
| than linear ones, is just usage based billing with extra
| steps.
|
| I've also taken advantage of the local topic of conversation
| being a logging service. Other businesses are not necessarily
| so pathologically distributed. Email is more reasonable to
| charge per seat, partially because people are used to the
| pathological part of the resource consumption distribution
| being cut off... or to put it in the terms everyone is used
| to, people are used to being told they can't attached a 3.5
| terabyte attachment to their email and that emails to a few
| thousand people at a time generally cause trouble. Since the
| number of emails an account can use is bound to some degree
| by human attention and the size and therefore resource
| consumption of the email is bound by size limits, it tends to
| be less pathological. Email also permits throttling, and
| indeed, if someone is suddenly receiving millions of emails
| per hour they may be _happy_ that you are throttling their
| inbox. Although in the end it 's probably still more
| pathological than you may intuit.
|
| Even here though, when you return the real world back into
| the picture it doesn't mean a flat pricing model perfectly
| works. Give them an $X/month all-you-can-eat, and one of your
| customers will find a way to provide email addresses to every
| resident in a country or something. Put limits on that and
| it's just usage with extra steps. There is a sense in which
| usage-based-billing is the only real option, it's just a
| matter of the details of how you price and market it.
| JohnFen wrote:
| > flat pricing with limits that you can realistically hit
| because the limits really ought to be thought of in
| logarithmic terms, rather than linear ones, is just usage
| based billing with extra steps.
|
| In a sense, yes. But the difference is that with flat
| pricing, you can at least easily predict what your charges
| will be. With usage-based pricing, you can't unless your
| use case is very simple.
| OliverJones wrote:
| I worked for a B2B SaaS outfit which charged by month by seat.
| Some customers demanded usage-based charges and our sales and PM
| said yes, without checking in with dev.
|
| As the guy who knew the app's logs best, it fell to me to code up
| and then maintain the monthly report to generate those customers'
| usage data and send it to billing. (The things we do for love.)
|
| Our app's log data wasn't complete and predictable enough to
| generate completely accurate usage data, so some assumptions were
| needed. (The problem was sometimes-missing timestamps for "usage
| session complete". Yeah I know, WTF? I inherited that code.)
|
| Things got a tiny bit ugly. Customers -- whales of course --
| started demanding weekly, then daily, usage reports. They
| demanded backing data for their bills. And, it became really hard
| to actually fix the defects in the app's logging so it was
| possible to generate accurate usage -- it would change the
| billing too much, and we'd have to explain it to the customer. It
| was a pain in the you-know-what. Especially for a guy like me who
| prefers to write really accurate software where other peoples'
| money is involved. This didn't threaten the business, it wasn't
| nearly that serious. But, wowee, it was unpleasant.
|
| Lesson: If you're going to add a new SaaS pricing model to an
| existing service, think of it as a BIG change. Make sure you can
| capture accurate and commercially defensible metrics for your
| pricing model. Get devs to think it through. Get testfolk to
| think it through and work out some system tests. Sales people,
| don't just tell customers they can have their own pricing model,
| but only if they sign up by the end of the quarter.
| higeorge13 wrote:
| Until you have ran your full etl load in snowflake or bigquery,
| you can never estimate the cost. You may answer some
| questionnaire about your projected usage, data volume, frequency,
| etc. but until you execute all your models with any warehouse you
| can estimate nothing.
|
| Usage based pricing is fine when it's on predictable metrics,
| number of logs sent, number of rows sent, number of
| emails/sms/etc sent, number of seats, users, licences, etc. When
| it's on abstract terms like credits or abstract resources like
| warehouses (with no idea what resource a medium warehouse
| utilizes) or error prone metrics like scanned gigabytes per
| query, it might become problematic at some point.
| BillPalombi wrote:
| Totally agreed - vendor specific constructs like credits are
| particularly opaque. They burden the user with the complexity
| of managing cost without clear levers that directly correspond
| to a known metric describing their usage.
| lupire wrote:
| Charge for what you sell. Do you sell RAM and CPU, or do you
| sell data processing? Which do your customers prefer? How do
| the model their need?
| higeorge13 wrote:
| This is true, but my point is that it's not predictable. e.g.
| I have 1 TB db with 50 tables and a specific i/u/d pattern.
| Until i replicate the whole db incrementally and run this
| with some warehouse, there is no way i can make an estimation
| about #credits per year. I want to add some new big dbt
| model? There is no way i know how much time will a warehouse
| be running because the query planner cannot create a sensible
| query execution plan. And so on.
|
| Charging e.g. by # of processed rows is more predictable from
| end-user/admin perspective. That's all. But obviously they
| make more money the way they price, what do i know? :-)
___________________________________________________________________
(page generated 2023-02-19 23:01 UTC)