Unit Economics

Last reviewed: September 2026

In one sentence: Unit economics connects technology spending with a measurable unit of consumption, output, or business value so organizations can understand what they are getting for their spend.

What are cloud unit economics?

Cloud unit economics measures technology cost relative to a defined unit of consumption, output, or value, such as cost per customer, transaction, order, workload, or successful outcome.

The basic calculation is simple:

Unit cost = relevant cost ÷ number of units

If an online service costs €100,000 per month to operate and serves 20,000 active customers, its average technology cost per active customer is:

€100,000 ÷ 20,000 = €5 per customer

That €5 metric creates context that the €100,000 total alone cannot provide.

If technology spending rises to €120,000 next month, that initially looks like a 20% increase.

But suppose the number of customers rises from 20,000 to 30,000.

The new unit cost becomes:

€120,000 ÷ 30,000 = €4 per customer

Total spending increased.

Cost per customer decreased by 20%.

Those two facts are not contradictory. They describe different dimensions of the business.

This is one of the central ideas behind unit economics: higher technology spending is not necessarily worse if that spending is producing proportionally more value.

Cost per what?

Every unit economics calculation has two parts:

a numerator — the cost

and

a denominator — the unit

Most discussions focus on the numerator.

How much did AWS cost?
How much did the Kubernetes cluster cost?
How much did the AI model cost?

Unit economics forces another question:

Cost per what?

The denominator determines what the metric actually means.

For example, the same €100,000 technology cost could produce:

• €5 per customer

• €0.20 per transaction

• €10 per order

• €2 per successful workflow

• €0.002 per API request

None of those metrics is inherently more correct than the others.

They answer different questions.

The challenge is choosing the unit that best represents what the organization is trying to understand.

Resource efficiency vs business unit economics

Not every unit metric measures business value directly.

A useful distinction is between resource-efficiency metrics and business unit metrics.

Resource-efficiency metrics

These describe how efficiently technical resources are being consumed.

Examples include:

• cost per vCPU-hour

• cost per GB stored

• cost per GB transferred

• cost per container

• cost per GPU-hour

• cost per API request

• cost per AI token

These metrics are particularly useful to engineering, infrastructure, and FinOps teams.

They can reveal inefficient architecture, expensive services, changing provider rates, or opportunities for optimization.

But they usually stop at the technology layer.

Business unit metrics

These connect technology cost with something the organization actually delivers.

Examples include:

• cost per customer

• cost per transaction

• cost per order

• cost per booking

• cost per shipment

• cost per claim processed

• cost per support case resolved

• cost per successful AI outcome

These metrics are often harder to calculate because they require technology data to be combined with operational or business information.

They can also be more useful for strategic decisions.

The FinOps Foundation currently makes this same broad distinction between resource-efficiency unit metrics and business unit metrics within its Unit Economics capability.

Choosing a meaningful unit

The easiest unit to measure is not necessarily the best one.

Suppose a video platform processes 500 million API requests per month.

Cost per API request may be technically straightforward to calculate.

But customers do not buy API requests.

They might buy subscriptions, viewing time, streamed events, or another service outcome.

The closer the denominator gets to the thing the business or customer actually values, the more useful the metric can become.

A useful unit should ideally be:

Measurable — the organization can obtain reliable data for it.

Relevant — it represents something meaningful to the service or business.

Repeatable — it can be calculated consistently over time.

Actionable — changes in the metric can influence a decision.

Understandable — engineering, finance, and business stakeholders can interpret what it means.

There is rarely one unit that satisfies every purpose.

A platform team might monitor cost per vCPU-hour, while product leadership monitors cost per customer, and finance tracks cost to serve and contribution margin.

All three can coexist.

Worked example: from infrastructure cost to cost per customer

Consider a SaaS company with the following monthly technology costs:

The company serves 20,000 active customers.

Its average technology cost per active customer is:

€100,000 ÷ 20,000 = €5

Now suppose the company grows.

The following month:

• technology cost increases to €120,000

• active customers increase to 30,000

The new cost per customer is:

€120,000 ÷ 30,000 = €4

The company is spending €20,000 more each month, but its technology cost per active customer has fallen from €5 to €4.

That represents a:

(€5 − €4) ÷ €5 × 100 = 20% reduction

in cost per customer.

If the company looked only at its total technology bill, it might conclude that costs were deteriorating.

Unit economics shows that the infrastructure is actually supporting growth more efficiently.

Cost per customer can still hide important differences

An average is useful, but it can conceal variation.

Suppose those 30,000 customers consist of three groups:

The overall average is still:

€120,000 ÷ 30,000 = €4

But an Enterprise customer costs six times as much to serve as a Standard customer.

That may be perfectly acceptable if Enterprise customers also generate substantially more revenue.

The point is that a single organization-wide unit metric can hide economically important differences.

Useful unit economics often requires segmentation.

Cost to serve

Cost to serve asks how much it costs to deliver a product or service to a customer or another unit of demand.

The relevant numerator may include more than the public cloud bill.

For example:

With 20,000 customers:

€110,000 ÷ 20,000 = €5.50 per customer

This is different from the earlier €5 technology-only metric.

Neither number is necessarily wrong.

They have different cost boundaries.

Whenever a unit metric is presented, it should therefore be possible to answer:

What costs are included in the numerator?

Cost allocation comes before useful unit economics

Unit economics depends heavily on cost allocation.

Suppose Product A has:

• €40,000 of directly attributable cloud costs

• €10,000 of allocated shared platform costs

• 25,000 active customers

If we ignore shared costs:

€40,000 ÷ 25,000 = €1.60 per customer

If we include Product A's share of the common platform:

(€40,000 + €10,000) ÷ 25,000 = €2.00 per customer

The difference is 25%.

Neither calculation is mathematically difficult.

The difficult question is whether the €10,000 shared cost genuinely belongs in Product A's cost base and how that amount was determined.

This is why allocation methodology and unit economics cannot be separated.

A precise denominator cannot compensate for a misleading numerator.

See Cost allocation for a detailed explanation of direct, shared, proportional, fixed, and unallocated costs.

Cost per attempt vs cost per successful outcome

Some units are more meaningful than they initially appear.

Suppose an automated service performs 100,000 tasks per month at a total cost of €20,000.

Cost per attempt:

€20,000 ÷ 100,000 = €0.20

Now suppose only 80,000 tasks complete successfully.

Cost per successful outcome:

€20,000 ÷ 80,000 = €0.25

Both calculations use the same €20,000.

But the denominator changes from activity to outcome.

That distinction becomes important when comparing systems with different failure rates.

Consider two systems:

System B looks 40% more expensive when comparing cost per attempt.

At the outcome level, the difference is much smaller.

Add the cost of correcting the 20,000 failed outcomes from System A and the economics could change again.

This is particularly important for automation and AI, where cheap attempts do not necessarily translate into cheap successful outcomes.

Non-obvious units can reveal more useful economics

Customers and transactions are common denominators.

They are not the only ones.

Sometimes the most useful unit is specific to the economics of the system.

Examples might include:

• cost per 1,000 streamed hours

• cost per document processed

• cost per GB delivered

• cost per active tenant

• cost per inference

• cost per completed workflow

• cost per successful recommendation

• cost per resolved case

• cost per unit of energy consumed

• value delivered per watt

The FinOps Foundation similarly notes that unit metrics should reflect the organization and service being measured rather than following a universal template. Its examples include metrics such as cost per reservation, ride, active user, and engagement team.

The important question is not whether a unit sounds conventional.

It is whether it helps the organization understand the relationship between cost and value.

Value per watt

Some technology environments have constraints beyond money.

Power-intensive data centers, HPC environments, GPU infrastructure, and AI workloads may be limited by available energy capacity.

In those environments, cost per workload might tell only part of the story.

Imagine two systems:

Outcomes per kW:

System A:

1,000 ÷ 20 = 50 outcomes per kW

System B:

1,300 ÷ 30 ≈ 43.3 outcomes per kW

System B produces more total output.

System A produces more output relative to power consumption.

Depending on whether the limiting factor is time, cost, energy, capacity, or sustainability, either metric might be more important.

This illustrates a broader principle:

Unit economics should reflect the constraint or outcome that matters to the decision being made.

Cost per unit is only half of unit economics

Cost efficiency is important.

But unit economics becomes more powerful when cost is compared with value.

Suppose a SaaS product has:

Revenue per customer: €20

Technology cost per customer: €5

Ignoring other expenses for this simplified example, the technology contribution is:

€20 − €5 = €15 per customer

Now suppose an optimization project reduces technology cost to €4.50.

The saving is:

€0.50 per customer

Across 100,000 customers:

€0.50 × 100,000 = €50,000

That creates a clear connection between engineering efficiency and financial performance.

But the reverse also matters.

If technology cost increases from €5 to €6 while revenue per customer increases from €20 to €30 because the additional infrastructure enables a more valuable service, the higher cost may be economically desirable.

Optimizing unit cost in isolation can therefore be just as misleading as optimizing total spend in isolation.

Contribution margin

Unit economics can also contribute to understanding contribution margin.

In simplified form:

Contribution margin per unit = revenue per unit − variable cost per unit

Suppose a service earns €25 per customer per month.

The variable technology cost to serve each customer is €6.

Simplified contribution margin:

€25 − €6 = €19

Contribution margin percentage:

€19 ÷ €25 × 100 = 76%

Now suppose the technology team reduces cost per customer from €6 to €5 without changing revenue or service quality.

New contribution margin:

€25 − €5 = €20

New contribution margin percentage:

€20 ÷ €25 × 100 = 80%

This is how a technical optimization can be translated into a business outcome.

In a complete financial model, contribution margin may include other variable costs as well. Technology unit economics should therefore be explicit about which costs are and are not included.

Unit economics can explain rising cloud costs

One of the most useful applications of unit economics is distinguishing growth from inefficiency.

Consider:

Cloud spend increased from €80,000 to €110,000.

That is a 37.5% increase.

Transactions increased from 4 million to 7 million.

That is a 75% increase.

Meanwhile, cost per transaction fell from €0.020 to approximately €0.0157.

The bill is getting larger.

The system is also becoming more efficient per unit of business activity.

Without the denominator, those two stories are impossible to distinguish.

The opposite can also happen

Suppose instead:

Now spending is increasing much faster than output.

Cost per transaction rises from €0.020 to approximately €0.0262.

That is a unit-cost increase of about 31%.

This does not automatically identify the cause.

The increase could result from:

• inefficient architecture

• idle capacity

• higher provider rates

• a new product feature

• additional redundancy

• stronger security requirements

• changing customer behavior

• migration activity

• deliberately improved service quality

Unit economics identifies that the relationship between cost and output changed.

Investigation explains why.

Unit metrics need context

A unit metric should rarely be interpreted as a standalone number.

Imagine cost per customer rises from €4 to €5.

That could be bad.

Or perhaps the company launched a premium capability that increased revenue per customer from €10 to €20.

Or perhaps service availability improved significantly.

Or customers began processing twice as much data.

Or a temporary migration increased infrastructure cost for three months.

The unit cost tells you that something changed.

Business and operational context tells you whether that change is desirable.

Trends are often more useful than benchmarks

Organizations frequently ask what a "good" cost per customer should be.

There is rarely a universal answer.

A customer using a simple SaaS application cannot meaningfully be compared with a customer running large-scale analytics or AI workloads.

Even within one company, different customer segments may have fundamentally different economics.

For this reason, tracking a consistent unit metric over time is often more actionable than trying to compare unrelated services.

The FinOps Foundation's current guidance similarly notes that organizations often gain more value from tracking trends within a defined scope than from forcing comparisons across unrelated products or business objectives.

A useful question is therefore not simply:

"Is €5 per customer good?"

but:

"Why did cost per customer move from €4.20 to €5, and did the value per customer change with it?"

Unit economics for AI

AI makes the choice of denominator particularly important.

Common AI metrics include:

• cost per token

• cost per model request

• cost per inference

• cost per agent run

• cost per workflow

• cost per customer

• cost per successful outcome

Cost per token is useful for measuring model consumption.

But it does not tell you whether the model completed the task successfully.

Likewise, cost per agent run says little about whether the agent produced something valuable.

For an AI customer-service system, a more meaningful metric might eventually be:

Cost per successfully resolved case

For a sales agent:

Cost per qualified opportunity

For document automation:

Cost per correctly processed document

This creates a progression from technical consumption toward business value.

See AI Token Economics for a detailed example including model cost, infrastructure, retries, and human escalation.

From cost per unit to value per unit

Not every useful unit metric needs cost in the numerator.

Sometimes reversing the relationship reveals another dimension of efficiency.

Instead of:

Cost ÷ outcomes = cost per outcome

you might measure:

Outcomes ÷ cost = outcomes per euro

Or:

Revenue ÷ technology cost = revenue enabled per euro of technology spend

Or, where infrastructure capacity is constrained:

Business value ÷ energy consumed = value per watt

These metrics do not replace cost-based unit economics.

They provide another perspective on the same underlying relationship:

How effectively is technology consumption being converted into value?

Building a unit economics model

A practical unit economics model can start with five questions.

1. What decision are we trying to make?

Do you want to optimize infrastructure?

Understand customer profitability?

Compare architectures?

Forecast growth?

Measure AI ROI?

The decision should guide the metric.

2. What is the relevant unit?

Choose a denominator that reflects the activity or outcome being evaluated.

That might be a customer, transaction, workload, booking, successful case, or another measurable unit.

3. Which costs belong in the numerator?

Define whether the metric includes:

• direct cloud cost

• allocated shared infrastructure

• SaaS

• licenses

• observability

• private infrastructure

• support

• labor

• other operating costs

Document the boundary.

4. Can the cost and unit data be correlated?

Technology billing data and business data often originate in different systems.

A useful model needs a common dimension such as:

• customer

• product

• application

• workload

• service

• transaction

• workflow

Without that relationship, dividing two organization-wide totals may produce an average that is mathematically correct but operationally weak.

5. What will we do when the metric changes?

A metric is most useful when it can trigger a decision.

If cost per transaction rises by 20%, who investigates?

If cost per customer falls, can the change be connected to an engineering decision?

If cost per successful AI outcome rises, should the organization investigate the model, prompts, retries, tooling, or human escalation?

Measurement without action is reporting, not management.

Start simple, then improve the model

A useful unit economics model does not need to be perfect on day one.

An organization might begin with:

public cloud cost ÷ customers

Later, it might add:

• private infrastructure

• SaaS costs

• licenses

• shared platform costs

• customer segmentation

• operational outcomes

• revenue or contribution margin

The first metric provides a baseline.

Later versions provide a more complete economic model.

This progression aligns with current FinOps guidance, which describes more mature unit economics practices as incorporating broader technology categories, more complete cost bases, business context, and governance around metric definitions.

The important thing is to document what each version means so changes in methodology are not mistaken for changes in performance.

How Exivity supports unit economics

Unit economics requires more than a cloud bill.

The cost side may originate from public cloud, private cloud, Kubernetes, virtualization, SaaS, AI services, physical infrastructure, or other technology systems.

The unit side may come from operational or business data.

Exivity is designed to bring those different data sources together so organizations can correlate technology consumption and cost with the units that matter to their business.

That can support metrics such as:

• cost per customer

• cost per service

• cost per workload

• cost per transaction

• cost per AI agent or workflow

• cost per successful outcome

• custom unit metrics based on available business data

Costs can first be enriched and allocated to the relevant products, customers, services, or other entities before the unit metric is calculated.

This is important because unit economics is only as meaningful as the cost model underneath it.

The objective is not to prescribe a universal unit.

It is to provide the cost, consumption, and business context required for an organization to define and measure the units that matter to it.

From technology cost to business value

Traditional technology cost management often ends with questions such as:

How much did we spend?

Which provider did we spend it with?

Which resources cost the most?

Those questions remain important.

Unit economics adds another layer:

What did that spending produce?

That change in perspective allows engineering, finance, product, and business teams to discuss technology using a shared economic language.

A €1 million cloud bill may be too high, too low, or exactly appropriate.

Without understanding what the €1 million produced, the number alone cannot tell you.

The most useful question is therefore often the simplest:

Cost per what?

Related: Cost allocation · Chargeback vs showback · AI token economics · FOCUS, explained