Compute per Conversion
Compute per conversion is an efficiency metric attributing the total computational effort spent on a conversion path to a single conversion. It captures model inference, vector search, personalisation computation and evaluation runs — regardless of whether they occur in the frontend or in the background.
Compute per conversion quantifies the computational effort — in tokens, GPU seconds or euros — required to produce one conversion. It translates technical load into marketing economics.
Explanation
Where token cost per lead looks at the model bill of one funnel, compute per conversion is broader and aimed at data teams: it also captures batch jobs, personalisation models, recommendation rankings and automated quality checks. Practically it is built by mapping per-service compute consumption onto sessions via traces and joining that with conversion events. The value is particularly good at exposing hidden cost drivers — such as a re-ranking model that runs on every page view but influences the decision in only two percent of sessions.
Marketing Relevance
The metric keeps personalisation and generative features from eating margin. It shows which models actually contribute value and which merely create load, providing the basis for decisions on sampling, smaller models or switching individual features off.
Example
A travel portal measures EUR 0.42 compute per booking. A breakdown shows 61 percent stems from a generative description module running on all listing pages. After moving to precomputation for top hotels the value falls to EUR 0.17 with no measurable drop in booking rate.
Common Pitfalls
Without traces, consumption is spread flat across all sessions and the metric becomes useless. And optimising only downwards may remove exactly the computation that converts weak segments in the first place — a holdout counter-measurement is mandatory.
Origin & History
The metric originated in infrastructure controlling at large platforms, where GPU utilisation had long been allocated to product KPIs. With the spread of generative personalisation it moved into marketing data teams in 2025. Through 2026 it became common practice to place compute consumption directly in FinOps dashboards next to revenue and conversion metrics rather than treating it as an IT cost block. The trigger was personalisation and agent workloads whose cost grew linearly with traffic while revenue contribution stayed highly uneven.
Marketing Use Cases
FinOps reporting that shows compute cost next to revenue and conversion rate.
Prioritising which generative features are precomputed rather than generated live.
Capacity planning ahead of seasonal traffic peaks such as Black Friday.
Assessing whether a larger model justifies its extra consumption through extra revenue.
Frequently Asked Questions
How does compute per conversion differ from token cost per lead?
Token cost per lead looks at the model cost of one specific conversational path up to the lead. Compute per conversion is broader and includes all computational load along the path to closing, including background processes such as ranking, personalisation and batch evaluation.
How do you attribute background jobs to individual conversions?
Via tracing IDs that link sessions to triggered jobs, and via proportional allocation of shared batch cost by usage share. A documented, stable attribution logic matters so time series stay comparable and apparent gains do not come from a change of method.
What target value makes sense?
There is no universal target, as it depends heavily on basket size or contract value. A useful approach is an upper bound expressed as a share of contribution margin per conversion, often in the low single-digit percent range, combined with an alert on sudden jumps.
Related Services
Go deeper: Measurement & attribution · Model comparison 2026