48.4k Log in Get started
Dashboard

What goes in an LLM adoption and unit economics dashboard?

An LLM adoption and unit economics dashboard connects the cost story to the value story: who uses the AI features, how deeply, what each active user costs, and — where revenue data is joined — whether the features earn their spend. It's the dashboard that decides whether the LLM budget grows or gets capped.

For: Product managers, growth teams, and engineering leadership. Refresh: daily. Source: modeled LLM usage tables in a Metabase-connected database.

Which cards belong on this dashboard?

  • Active users of LLM features per week (line)
  • LLM cost per active user (line)
  • Requests per user distribution (histogram or table)
  • Feature usage by app or surface (bar)
  • Retention of AI-feature users vs. non-users (cohort table)
  • Top tenants or accounts by LLM spend (table)
  • Cost vs. revenue per feature, where joined (table)
  • New-user activation into AI features (funnel or line)

What data does this dashboard need?

  • User- or tenant-grain daily rollups: requests, tokens, cost per user
  • Feature and app tags on requests
  • Product analytics user table for the join (signup date, plan, segment)
  • Revenue per account where the margin view is wanted
  • Consistent user IDs across the LLM gateway and product analytics

How do you build it?

  1. Sync usage rollups from your LLM gateway, tracing, or eval tool into a database, keeping stable IDs, timestamps, token counts, and costs.
  2. Build clean models at the grain this dashboard requires — daily per app and model is the workhorse.
  3. Create one saved question per card and certify the shared models and metric definitions.
  4. Add dashboard filters for Date range, feature, plan or segment, app, tenant.
  5. Exclude test, staging, and playground traffic from headline cards, and show the refresh time.

Example card SQL

LLM cost per active user by monthPostgreSQL
SELECT
  date_trunc('month', window_start) AS month,
  COUNT(DISTINCT user_id) AS active_users,
  ROUND(SUM(cost_usd), 2) AS llm_cost_usd,
  ROUND(
    SUM(cost_usd) / NULLIF(COUNT(DISTINCT user_id), 0), 4
  ) AS cost_per_active_user
FROM llm_user_rollups
WHERE environment = 'production'
GROUP BY 1
ORDER BY 1;

Dashboards

LLM spend overview dashboardModel usage & cost dashboardLLM latency & errors dashboardEval quality tracking dashboard

Integrations

AI & LLM analytics integrationsLangfuse + MetabaseLangSmith + MetabaseHelicone + MetabaseBraintrust + MetabaseArize Phoenix + MetabaseW&B Weave + MetabaseOpenRouter + Metabase

Metrics

Token usageCost per 1M tokensLLM cost per userp95 LLM latencyLLM error rateCache hit rateEval pass rateLLM requests per day

Analytics

LLM analytics

FAQ

What counts as an active user for cost per user?
A user who triggered at least one LLM request in the window — the same denominator as LLM cost per user. Resist widening it to all product users: that flatters the number and hides the real question, which is whether heavy AI users are profitable. Show the distribution too — LLM usage is usually far more skewed than general product usage.
How do I join LLM usage to product analytics?
Propagate the same user or tenant ID into the LLM gateway's request metadata that your product analytics uses. Most tracing tools and proxies accept a user field per request. Without that shared key you can still report totals, but per-user economics, retention splits, and account-level views all need the join.
Is comparing retention of AI users vs. non-users fair?
Treat it as correlation, not causation — engaged users adopt more features of every kind, so AI users retaining better doesn't prove the AI caused it. The split is still worth showing: if AI-feature users retain worse, that's a genuine alarm. For causal claims you need an experiment, not this dashboard.
What history do the caveats require?
Cohort retention needs several months of consistent user-grain history — if your LLM logs only started recently, label the cohort card accordingly. And when the source API limits the window (OpenRouter's activity API keeps 30 days), a scheduled daily export into the warehouse is what makes any of the longer views possible.