Metrics for a Freemium + API + Token Business
The company is three businesses wearing one trench coat — a freemium consumer app, a usage-based API, and a token economy — and each speaks a different metric language. The senior move is knowing all three grammars and which number is the real north star.
Three business models in one
Most analytics candidates walk in with one mental model — SaaS subscription metrics — and try to force the company into it. That fails, because the company is running three monetization models simultaneously, and each has its own metric grammar, its own benchmarks, and its own failure modes:
- Freemium consumer subscription — free tier funnels to a Pro tier (~$20/mo) and higher-priced tiers above it. Grammar: conversion, MRR, churn, LTV:CAC. Classic self-serve SaaS.
- Usage-based API — OpenAI-compatible, pay-as-you-go USD credits. Grammar: net revenue retention, tokens processed, expansion. Behaves like an infrastructure/consumption business, not a seat business.
- Token economy — staking of the platform's token ($TOKEN) plus a tokenized-compute credit ($CREDIT) as prepaid API capacity. Grammar: TVL, staking ratio, token velocity, utilization. Behaves like a DeFi protocol.
"The company needs three metric frameworks, not one, because it's a freemium app, a consumption API, and a token protocol at the same time — and the interesting analytics questions live in how they interact." Say that early and you've immediately separated yourself from the candidate who quotes MRR and stops. The sections below are the three frameworks plus the two syntheses that tie them together — the north star and the unit economics that cut across all three.
Freemium & subscription metrics
The consumer side is the most legible business and the one leadership will ask about first. Know the benchmarks cold so you can say whether a given number is good, average, or a fire.
| Metric | What it measures | Benchmark |
|---|---|---|
| Free → paid conversion | Share of free users who ever upgrade (self-serve freemium) | 2–5% typical · >10% exceptional |
| MRR / ARR | Recurring subscription revenue run-rate | Reportedly tens of millions in ARR (self-reported) |
| GRR (gross revenue retention) | Revenue kept before expansion — the leak rate | ~88% median SaaS |
| NRR (net revenue retention) | Revenue kept including upgrades/expansion | ~101% median · >110% strong |
| LTV:CAC | Lifetime value vs cost to acquire | 3:1 floor · 4–6:1 top quartile |
| CAC payback | Months to recover acquisition cost | <12mo (SMB/self-serve) |
Two company-specific wrinkles matter. First, all of this is measurable on billing data alone — Stripe knows who signed up, upgraded, and churned without anyone ever seeing a prompt, so subscription analytics is fully privacy-safe (Chapter 02). Second, the churn risk is specific: at ~$20/mo, the company's value proposition is privacy + uncensored access + model choice, not raw capability — and a user who doesn't prioritize privacy can get stronger models elsewhere for the same money. That "value-for-money" churn means you should watch churn reasons and cohort retention closely, because the bear case for the whole company lives in this number.
GRR is the pure leak; NRR includes expansion. Quoting both — "GRR tells me how leaky the bucket is, NRR tells me whether upgrades are refilling it faster than churn drains it" — reads far more senior than quoting either alone. For the company, expansion means free→Pro and Pro→higher-tier ladder-climbing, plus subscribers who also start buying API credits.
Engagement metrics
Engagement is the leading indicator that predicts the lagging revenue numbers, and — importantly — it's all measurable on content-free metadata: a chat-created event tells you someone is active without anyone knowing what the chat says (Chapter 02).
- Stickiness (DAU/WAU/MAU) — DAU/MAU ~20% is good, 50%+ is world-class. Useful anchor: ChatGPT's DAU/MAU runs ~36–45%, so that's the ceiling of what a great AI-chat product looks like. The company around its token launch was at ~50K DAU against a few hundred thousand registered (~11%); with several million registered users now, tracking the trend matters more than the absolute.
- Activation — did a new user reach the aha moment? For the consumer product that's something like "ran N prompts across 2+ sessions in week one," all trackable from content-free event counts.
- The "smiling curve" — because the company's capability ceiling is set by the open models it routes to, churned users who left over capability can return as the underlying models improve. So resurrection/win-back is a real, measurable motion here, not an afterthought — track reactivation cohorts, not just gross churn.
At a company whose product quality rises every time Meta or DeepSeek ships a better open weight, retention isn't a one-way door. A user who churned in Q1 because the models felt weak is a live win-back target in Q3. Most SaaS treats churn as terminal; framing the company's churn as partly recoverable — and proposing to measure the resurrection curve — is the kind of product-minded observation that lands in the room.
API / usage-based metrics
The API is a consumption business, so seat-based SaaS intuition misleads. The headline metric is net revenue retention, because in usage-based pricing revenue expands and contracts continuously with consumption rather than at renewal.
| Metric | Why it's the right lens | Benchmark |
|---|---|---|
| NRR | The headline for consumption — captures organic expansion as customers use more | >120% is good for usage-based |
| GRR | Usage-based contracts as easily as it expands — a customer can simply use less | ~3% lower than seat-based SaaS |
| Time-to-first-successful-call | Activation for developers — the API equivalent of the aha moment | Lower is better; track p50/p90 |
| Tokens processed & per-model mix | Volume + which models drive it (margin varies by model) | Track total tokens/mo and calls/day, plus the per-model split |
| Latency & error/rate-limit rates | Reliability — directly predicts developer churn | Watch p95 latency, 4xx/5xx, 429 rates |
The subtle point to raise: usage-based has structurally lower GRR than seat-based SaaS (~3 points), because there's no renewal friction protecting you — a developer whose side project dies just... stops sending requests, and revenue silently decays. That makes expansion (NRR >120%) the thing that has to carry the model, and it makes activation (time-to-first-successful-call) disproportionately important, because a developer who never gets a clean first response never becomes an expanding account. All of this is measurable from gateway metadata — request counts, token counts, latency, status codes — with no prompt content anywhere in the pipeline.
Token & staking metrics
This is the section most candidates can't do, which makes it your differentiator. The company's token layer is prepaid, committed demand, and it has DeFi-native metrics that map onto business meaning — if you translate them correctly. The mapping (know the staking mechanism cold):
| Token metric | Business analog | What it tells you |
|---|---|---|
| Amount staked / TVL | Prepaid committed demand — the "recurring revenue" analog | Capacity users have pre-committed to; a forward demand signal |
| Staking ratio (staked ÷ circulating) | Retention proxy | High ratio = holders locking in for the long term, not flipping |
| Token velocity | Hold vs churn behavior | Low velocity = holding/committed; staking is a velocity sink |
| Utilization ($CREDIT consumed ÷ staked-entitled) | Activation / engagement of committed capacity | Are stakers actually using the API capacity they hold, or just holding? |
TVL and APY can be driven by token-price speculation, not real product usage. The token has swung through enormous moves — on the order of a ~96% drawdown and back — so "TVL up 40%" might mean the price rose, not that anyone committed more real demand. Always reconcile the three views: staked capacity (what's committed) vs actual $CREDIT consumed (what's used) vs fiat revenue (what's real cash). The gap between "capacity staked" and "inference actually consumed" is the single most important token-side analysis you'll own — and it's the one that keeps leadership honest about whether the token economy is demand or speculation.
The utilization gap deserves special attention: if stakers hold entitlement to X dollars/day of inference but only consume a fraction of it, the token is functioning more as a speculative asset than as prepaid demand — and that distinction is exactly the kind of "transparent about analytical uncertainty" call the posting wants you to make to leadership. The full on-chain toolkit — Dune/Flipside queries, the consented-linkage rule, holders and burns — is Chapter 06.
The north star question
Expect to be asked: "If you could pick one metric for the company, what would it be?" This is a design question with a company-specific constraint baked in — your north star must be (a) content-free, (b) robust to rapid product iteration (a literal posting requirement), and (c) leading rather than lagging.
A strong candidate answer is weekly active paying subscribers (or, on the API side, aggregate paid inferences run per week). Both encode "a user is getting enough value to pay and to keep showing up," both are computable from billing + content-free usage metadata, and both survive product churn — you can rip out and rebuild the chat UI without breaking the definition.
Revenue is the obvious answer and the wrong one to lead with. It's lagging — it tells you what already happened after users decided — and for a token business it's distorted by the token's price swings. The senior move is: "Revenue is the scoreboard, but I want a north star that's leading and behavior-based — weekly active paying subscribers — so we see the trend before it hits the P&L. And it has to be robust to how fast this product changes, so I define it on billing + content-free usage, not on any specific feature." That directly answers the posting's 'metrics robust to rapid product iteration' line.
Inference unit economics
The token-and-subscription business model introduces this; here's why the first data hire owns it. The company sells inference, so every request has a real marginal cost — GPU time — which makes its economics look nothing like classic software.
| Fact | Number | So what |
|---|---|---|
| AI gross margin | ~50–60% (vs 80–90% classic SaaS) | Inference is COGS that scales with usage — growth doesn't free-ride |
| GPU cost | H100 ~$2.85–3.50/hr | Real cost per token is a function of utilization, not list price |
| Real GPU utilization | ~30–60% | Effective cost/token is 2–3× the spreadsheet math — idle GPUs still bill |
| LLMflation | ~$20/M tokens (2022) → ~$0.40 now | ~10×/yr capability-cost decline — a structural margin tailwind |
Two consequences the first DS should surface. First, LTV must be gross-margin-adjusted: a user paying ~$20/mo isn't worth ~$20 of LTV, they're worth ~$10–12 after inference COGS — which raises the CAC-payback bar and means the naive LTV:CAC everyone quotes is optimistic by ~2×. Second, staking prepays capacity, which hedges the usage-based COGS volatility — a genuinely elegant interaction between the token model and the cost structure, and exactly the kind of cross-business synthesis (token ↔ margin) that shows you see the company whole.
At a SaaS company, gross margin is a finance detail. At this company, it's a data problem — because true cost/token depends on real GPU utilization and per-model routing mix, which live in the gateway logs you're consolidating, not in the ledger. The person who can say "our blended margin is X, here's the per-model breakdown, and here's how routing more traffic to cheaper open weights moves it" is doing analytics that directly steers the P&L. That's the highest-leverage thing a first data hire can own here — say you'd own it. Next: Chapter 05 · Experimentation.