Review this FinOps dashboard for a video platform. The headline metric is cost per request. It is flat quarter on quarter and the team reports efficiency as stable. Transcoding - 2% of requests - is 90% of infrastructure cost. What would you remove and what would you change?

What is actually required

A unit cost metric exists to answer one question: if the business doubles, what happens to the bill? It is useful only when its denominator is the thing that drives the cost. Here the denominator is requests, and 98% of requests cost almost nothing. The metric is an average over two populations that have nothing in common, and it moves only when the ratio between them changes - which makes it a mix indicator wearing the costume of an efficiency indicator.

The concrete failure: a 30% improvement in transcoding efficiency alongside a 30% rise in cheap API traffic leaves cost per request exactly flat. Both numbers matter and the dashboard reports neither.

What I would remove

The headline metric, and the quarterly efficiency target attached to it. A target on a mix-sensitive average rewards whichever team can grow cheap traffic fastest, and it makes transcoding improvements invisible to the people funding them. Remove also any cost-per-request alert: it will fire on a traffic mix change and train everyone to ignore it.

The one change that matters

Pick the denominator that the cost is proportional to, per cost driver, and report it separately. For this platform:

• Cost per minute of video transcoded, split by output rendition set. This is the metric that moves when encoding settings, instance type or codec change, and it is the one worth a target.
• Cost per minute delivered, which is dominated by egress and cache-hit ratio and has nothing to do with transcoding.
• Cost per thousand API requests for everything else, so it is not mixed into either.
• Cost per paying account, as the only business-facing figure, because that is what gross margin is computed from.

Four numbers, each with one owner and one lever. A good unit metric is one a single team can move without the others changing anything.

What I would keep, even though it looks odd

The flat quarter-on-quarter chart. Kept and labelled as a mix indicator, it is genuinely informative: a sudden move means the traffic shape changed, which is worth knowing even though it says nothing about efficiency. Keep the allocation method documented too, including the share of shared platform cost that was spread across products - an imperfect allocation that everyone understands beats a precise one nobody can reproduce.

How I would argue this in the review

With the arithmetic rather than the principle. Show that 2% of requests carry 90% of cost, then show the two scenarios that leave the headline unchanged - a real efficiency win and a traffic mix shift - and ask which one the dashboard is supposed to detect. A metric that cannot distinguish improvement from mix change is not measuring efficiency, and that argument wins a room faster than any discussion of denominators in the abstract.

When not to split the metric

For a single-product SaaS where every request does roughly the same work, cost per request is an excellent metric and splitting it is make-work. The test is cost dispersion: if the most expensive decile of requests costs less than a few times the cheapest, one denominator is fine. Above that ratio, the average stops describing anybody.