Cost per feature, and cost per outcome

Tag your calls by product surface and AI spend lands on the feature that spent it. Because your orders and leads are in the same store, the next question — was it worth it — is a chart rather than an integration project.

In short

A gateway tag rides through to attributes.tag, so spend by feature is a grouping, not a project.
The AI spend template ships that widget, and one plotting AI spend against leads over the same days.
A single computed cost-per-lead number is not a built widget — plot the two series and divide. Said plainly rather than implied.
Tags apply from the moment you set them. No tool can reconstruct them for traffic already billed, which is the argument for tagging today.
Untagged spend shows as untagged. That is a finding, not a gap.

Four providers, one pipeline, and the three ratios a growth team runs on. Because every connector reports money in cents and every event carries the same envelope, cost per click, cost per lead and ROAS are simple divisions wherever you land the events — a warehouse, a sheet, your own database.

Tag once, at the call site

One value per product surface. Keep the vocabulary short — a handful of surfaces, not one per request — because a tag is a category and a high-cardinality tag is a useless grouping:

support-triage      the inbox assistant
report-writer       the weekly summary generator
onboarding          the setup walkthrough
internal-tools      staff-facing utilities

The gateway groups its reporting by that tag; the connector carries it through unchanged. A widget grouping llm.cost_reported by attributes.tag is then spend per feature, and it is one of the nine widgets in the AI spend template.

The question one store answers and two do not

You have	Cost by model	Cost by feature	Cost per lead or order
An LLM observability tool	yes	yes, if it reads tags	no — it has no revenue events
A BI tool over your warehouse	after an integration	after an integration	after both integrations
HookGet	yes	yes	both series in one store, on one chart

Stated precisely, so you can check us. The template ships a widget plotting llm.cost_reported and lead.created over the same daily buckets — two series, one chart, one store. Dividing them gives you cost per lead. A single-number widget that performs that division across two event families is not built; formulas today combine aggregates inside one widget query.

What to do with the number

Finding	The move
One feature is most of the spend	Cache it, shorten its outputs, or move it to a cheaper model — you now know which one to touch
A feature costs more per lead than the lead is worth	That is a product decision with a number attached, which is rare
Spend rose, cost per 1M tokens flat	Volume grew, not price. Often that is success — check the outcome series before cutting
Cost per 1M tokens rose, volume flat	The mix moved to an expensive model, or a promotional rate ended. See gateways
Cache hit rate fell	A prompt change probably broke the cache prefix. Cache reads are roughly an eighth of input price, so this is usually the cheapest fix available

Questions

How do I tag a call?

At the call site, using your gateway's own tag field — one value per product surface: support-triage, report-writer, onboarding. The gateway reports spend grouped by that tag, and the connector carries it through as attributes.tag. Nothing is inferred: an untagged call is reported untagged, which is itself worth seeing.

Can I really see AI cost per lead?

You can see AI spend and lead volume on one chart over the same days, from the same store, because HookGet already carries both — that widget is in the template. A single computed "cost per lead" number is a formula between two event families, and formulas today run across aggregates within one widget query. Plot them together, divide the two figures, and you have the ratio; an automatic single-number widget for it is not built.

Why can a dedicated LLM tool not do this?

Because it does not hold your revenue events. Cost per lead needs AI spend and leads in one queryable place. An observability tool has the first and no notion of the second; a BI tool has the second and needs an integration project for the first. HookGet already ingests both, which is an accident of what it is rather than a feature we added.

What if we do not tag anything?

You still get spend by model, by ledger and by upstream provider. Tagging is what turns "we spent $14,000 on one model" into "$5,100 of it was support triage". Start tagging before you need the answer: tags apply from the moment they are set, and no tool can reconstruct them for traffic that has already been billed.