Calculating a Real Cost-Per-Transaction Number

The unit has to match what actually drives cost, not just what's easiest to count. Total API calls is a reasonable unit if calls are roughly uniform in cost; it's a misleading one if a small share of calls, a bulk export, a complex search, cost far more than a typical call and get averaged away into a number that looks stable while the mix underneath it is shifting.

Test your candidate unit against a simple question: if a customer doubled their usage of the expensive call type only, would your chosen unit's cost figure actually move in a way that reflects that. If it wouldn't, because the unit averages that call type away with everything else, it's the wrong denominator for what you're actually trying to see.

Include compute, storage, and data transfer directly attributable to serving that transaction type, and be explicit about what you're leaving out, shared platform overhead, monitoring, the parts of the bill that don't scale cleanly with any single transaction type. A cost-per-transaction number that quietly excludes a growing share of shared overhead will look better every quarter for reasons that have nothing to do with actual efficiency.

Decide on an allocation method for shared overhead rather than dropping it entirely, even a simple even split across transaction types is more honest than leaving it out, since a number that ignores a real and growing cost isn't actually measuring efficiency, it's measuring how much of the bill you chose not to count.

Say your infrastructure bill for a specific service runs $80,000 a month and it handled 4 million transactions that month, that's a cost per transaction of two cents; if next month the bill rises to $95,000 but transactions rise to 5.5 million, your cost per transaction actually falls to roughly 1.7 cents even though the total bill grew, which is exactly the distinction a raw total-spend number would have missed.

• Redefining what counts as a billable transaction to make the denominator look better, without a corresponding change in what's actually being delivered
• Excluding a specific expensive transaction type from the calculation because it makes the average look worse, rather than tracking it as its own segment
• Comparing this quarter's number to a stale baseline instead of the immediately preceding period, which hides a recent regression inside a longer, more flattering trend
• Averaging across transaction types with very different cost profiles instead of reporting cost per transaction type separately

Calculate cost per transaction on the same cadence you review total infrastructure spend, and segment it by transaction type whenever the mix is uneven enough that a single blended average would hide a real difference. A rising blended average with a falling number in every individual segment usually means your mix has shifted toward more expensive transaction types, which is a genuinely different story than a real efficiency regression, and the segmented view is the only way to tell the two apart.

Share this number with whoever owns product pricing as well as with engineering, since a shifting transaction mix is often a signal worth feeding back into how a specific plan or feature is priced, not just an engineering efficiency question to solve on the infrastructure side alone.