Section B · The Core Challenge

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 framing that signals seniority

"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.

Bring GRR and NRR as a pair

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.

The smiling curve is a company-shaped insight

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?

The caution that proves you're not naive about crypto

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.

Why not just revenue?

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.

Why the first DS owns margin analytics

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.

✓ Check yourself

Answer from memory before opening each one.

Why does a usage-based API carry structurally lower gross revenue retention than seat-based SaaS, and what does that make you watch?

Show answer
There is no renewal friction: a developer whose side project dies simply stops sending requests, and revenue decays without a cancel event. Expansion has to carry the model, so NRR matters most, and activation, meaning time to the first successful call, matters because a developer who never gets a clean response never expands. See API and usage-based metrics.
A dashboard shows staked-token value up 40% this month. What do you tell leadership before anyone celebrates?

Show answer
That the number may be price, not demand, because TVL and APY can be driven by token speculation. Reconcile three views: staked capacity, compute credit actually consumed, and fiat revenue. A large gap between staked and consumed means the demand is speculative. See token and staking metrics.
A subscriber pays $20 a month and inference takes 40% to 50% of revenue. What is their margin per month, and what does it do to an LTV:CAC figure someone quotes?

Show answer
About $10 to $12 a month after inference cost, not $20. The naive LTV:CAC is optimistic by roughly two times, and the CAC payback bar rises. LTV must be gross-margin adjusted at a company that sells inference. See inference unit economics.
You are asked for one north-star metric. Why weekly active paying subscribers rather than revenue, and when would you pick something else?

Show answer
It is content-free, leading, and survives a rebuilt UI, since it needs only billing plus usage counts. Revenue lags and token price distorts it, so it stays the scoreboard. If the API came to dominate, use aggregate paid inferences per week instead. See the north star question.
A user cancels in the first quarter because the models felt weak. Most SaaS writes that user off. Why might you not, and what do you measure?

Show answer
The product routes to open models whose quality improves with each release, so a user who left over capability can return. Churn is partly recoverable here. Track reactivation cohorts and the resurrection curve, not gross churn alone. See engagement metrics.
An executive wants one blended NRR across subscriptions, API credits and staked capacity. What goes wrong?

Show answer
The three surfaces have different grammars and failure modes. Staked capacity is prepaid and moves with token price, so folding it into NRR makes a revenue metric move with speculation. Report each surface on its own terms and track staked capacity as a committed-demand line. See three business models in one.

Takeaway

The company runs three monetization models at once, so it needs three metric frameworks, and the interesting questions sit in how they interact.
Subscription health is measurable on billing data alone, so it is privacy-safe; report GRR and NRR as a pair.
Usage-based API revenue leans on NRR and activation because nothing renewal-shaped protects it from silent decay.
Staked tokens are committed demand and not revenue; reconcile staked capacity, credit consumed and fiat revenue, because price alone can move TVL.
Weekly active paying subscribers is a strong north star: leading, content-free and robust to product change.
Inference is cost of goods, so margins run near 50% to 60% and LTV must be margin-adjusted; the true cost per token lives in the gateway logs.

Metrics only steer decisions if you can test changes to them without tracking people, which is the next chapter. → Experimentation