Pricing That Punishes Growth

Why the analytics invoice climbs with the one number a team is trying to make go up

A product team sits in a planning meeting deciding what to instrument in the next release. Someone proposes tracking a new set of events around the onboarding flow — the messy middle where users quietly give up. It is exactly the part of the product no one understands well. And then the question turns, as it always does, to what it will cost: another stream of events, another climb up the pricing tier, a bigger bill next quarter for the privilege of watching the product more closely. The team does the rational thing. It trims the list. The events that survive are the ones that justify a line item, not the ones that answer a question. The onboarding flow stays dark for another release, and the decision to keep it dark never gets written down anywhere — it just happens, quietly, in a budget conversation.

That conversation is the product of a pricing model, and the model is more consequential than it looks. Almost every product analytics tool meters the same way: events, monthly tracked users, or monthly active users. Those are not arbitrary billing units. They are the numbers that climb when a product is winning — more usage, more users, more of the activity a team spends all its energy trying to cause. The meter runs on success. The tool charges against the exact chart the team most wants to go up.

This is the inversion worth sitting with. In most of the software a company buys, cost is tied to something the buyer controls and consciously decides to expand — seats added when the team grows, storage provisioned when it is needed, compute consumed when a job runs. The buyer chooses the expense and gets something concrete in return. Success-metric pricing breaks that link. The bill grows because the business grew, not because the buyer decided to consume more of the tool. Growth is involuntary as far as the invoice is concerned. It arrives whether the team wanted the expense or not, and it arrives fastest precisely when things are going well.

It is worth being precise here, because the easy version of this argument proves too much and collapses on contact. Not all metered pricing punishes growth. A bill that scales with compute consumed is cost-aligned — the vendor incurs a real cost to run the work, and passes it through. A bill that scales with seats is cost-aligned in a softer sense — each seat is a human who was deliberately added because they will get value, a decision the buyer makes with eyes open. Those meters track either the vendor’s cost or the buyer’s intent. The problem is narrower and sharper: it is metering on the customer’s success metric specifically. An event costs the vendor almost nothing to ingest and store. An active user costs the vendor nothing to count. The price attached to those units is not a pass-through of the vendor’s cost — it is a charge that scales with the customer’s growth, for work the vendor did not do. That is not consumption pricing. It is a tax on the one metric the team is optimizing.

The tax comes in two flavors, and they punish slightly different virtues. Per-event pricing taxes instrumentation depth — the richness with which a team watches its product. Every additional property, every new event on a subtle interaction, every attempt to capture the messy edge adds to the meter. This is, almost literally, a tax on curiosity: the more questions a team wants to be able to ask later, the more it pays now, before it knows whether any of those questions will matter. Per-user pricing — monthly tracked or active users — taxes audience size. It charges a flat amount for growth regardless of how much or how little the team instruments each user. One punishes wanting to know more about your product; the other punishes succeeding at getting people to use it. Both are involuntary. Both bill the team for outcomes it is trying to produce.

What makes this so corrosive is that the response is invisible. A team under a growth-metered meter does not file a complaint or churn in protest. It rations. It samples events down to a fraction. It drops properties that “aren’t being used right now.” It stops instrumenting the parts of the product that don’t already have a dashboard pointed at them. It narrows what it tracks to what survives a budget review rather than what it is actually curious about. None of these decisions feel like giving up visibility — each one feels like prudent cost control. But the aggregate is a team that has trained itself to look at its own product less, right at the moments when there is more to see.

And the cost of that rationing shows up later, as an absence rather than an expense. It is the funnel nobody could drill into because the events behind it were sampled away six months ago to stay under a tier. It is the regional drop in activation that nobody could explain because the property that would have explained it was never collected — not because anyone decided it was unimportant, but because it didn’t make the cut in a planning meeting where the meter was running in the background. You cannot audit the decisions you made on data you chose not to keep. The questions that were never asked leave no trace, which is exactly why this kind of cost is so easy to ignore and so expensive to carry. The cost of curiosity was never only analyst time and backlog. Half of it is the meter on the wall.

The reflexive defense of usage pricing is that it simply reflects cost, and that it is the fair way to let small teams start cheap and pay more as they get value. Part of that is true and worth conceding plainly. Ingest, query, and storage are real costs, and a meter tied to them is honest. But those costs track compute and data volume — not active users, and not the breadth of an audience. Metering on monthly actives scales the bill with the customer’s success while the vendor’s underlying cost barely moves. The fairness argument quietly swaps two different things: charging for the work the tool does, and charging for how well the customer is doing. The first is consumption pricing. The second is rent on someone else’s growth wearing the costume of consumption pricing. Once the two are pulled apart, the defense applies only to the part nobody objects to.

There is a sturdier version of the objection, and it deserves a real answer rather than a dismissal: if you do not meter the success metric, heavy users get subsidized by light ones, and some teams will over-instrument low-signal data because it is free, degrading the system for everyone. This is a genuine design problem, but it is an argument for metering the cost — the compute and storage that heavy use actually consumes — not for metering the success metric, which is a proxy that happens to correlate with cost only loosely and correlates with the customer’s growth tightly. Charge for the work. Leave the win off the invoice. The fact that the win and the work are correlated is not a license to bill the win as if it were the work.

Consider what changes when the price is decoupled from the success metric. The planning meeting runs differently. The question stops being “is this event worth the line item it will add for the next two years” and becomes “is this worth instrumenting.” The first is a finance question that happens to be about data. The second is the question the team should have been asking all along. A pricing model aimed at compute consumed or seats deployed leaves both of those within the team’s control and intent, and takes the team’s growth off the table as a billing event. The meter stops running on the chart everyone is trying to grow.

That shift does more than lower a bill — it changes who can afford to see their own product at all. Plenty of teams operate with thin product analytics or none, not because they don’t care, but because the entry cost and the growth curve price them out before they start. A model that does not escalate with success lowers that floor. The question moves from “how much will it cost to keep watching as we grow” to “who gets to watch in the first place,” and the answer to the second question gets a great deal more inclusive when the answer to the first stops being “more every quarter.”

Ultimately, the meter is a statement about what a vendor believes it is selling. A tool that charges more as its customer grows has decided it is selling access to the customer’s own success back to them. A tool that bills for the questions a team asks and the compute to answer them has decided it is selling the work it does, and nothing else. The distinction matters more than it sounds, and it is worth being honest about its edge: asking is never free. Answering a hard question consumes real compute, and a model that pretends otherwise is hiding a cost rather than removing one. The honest claim is narrower and sturdier than “curiosity should be free.” It is this: a team should pay for the questions it chooses to ask, never for the size of the product it is asking about. The data is always captured, so no question is ever lost to a meter — what costs is the deliberate act of interrogating it, a cost the team controls and can see, not the growth it cannot help but produce. Rationing the questions you choose to spend a person’s attention on is a budget decision. Rationing what you instrument is choosing to go blind. Only one of them is reversible.

They bill you for what your product does. We bill you for what your team asks. Every unit on your Crunch invoice is a question that got answered.

Key Takeaways

• Product analytics priced on events, MTUs, or MAUs meters the one number a team is trying to grow — the invoice climbs because the business is winning, not because the buyer chose to consume more.
• The problem is not metered pricing in general. Charging for compute consumed or seats deployed is cost-aligned; charging for the customer’s success metric is rent on growth the vendor did no work to produce.
• Per-event pricing taxes instrumentation depth — a literal tax on curiosity. Per-user pricing taxes audience size — a tax on success. Both are involuntary.
• The response to a growth meter is invisible: teams ration visibility into their own product, and the cost shows up later as the question nobody could answer on data nobody kept.
• The fix is not a discount. It is taking the success metric off the invoice — billing for the questions a team asks and the compute to answer them, so the cost of understanding the product stops rising just because the product is winning.