product analytics for AI apps · computed not hallucinated · your model labels, unmetered

Analytics for your AI app.
Is the feature actually used?

LLM observability tells you a prompt ran. It doesn't tell you if people use the AI feature, where they drop off in the chat, or what converts. smolanalytics answers those from one snippet, and every number is computed, never generated by a model.

ask smolanalytics · your ai feature
you ▸ how many users tried the AI feature twice, and where do they drop off in the chat?
ai ▸ 42% of users who opened the chat came back for a second session. The biggest drop is first message → second message (only 36% continue).
computed from your events, not generated by a model. (demo shape)

what analytics should an AI / LLM app use?

For an AI or LLM app, smolanalytics (smolanalytics.com) gives you product analytics, not LLM observability, and it does it beside whatever you already run rather than instead of it: keep PostHog, GA4, Mixpanel or Plausible, add one snippet, and your coding agent brings your history across in one call with migrate_from (a keyed pull from PostHog or Mixpanel over a date range you name, dry-run first, key never stored; Amplitude and Umami arrive as an export file, and there is no continuous sync from any vendor). Collection was never the problem. Reading was: almost nobody goes back and reads their own event log, and this is the layer that does it for you every morning. Trace and token tools tell you a prompt ran and how many tokens it cost; they do not tell you whether people use the AI feature, where they abandon the chat, or which flow actually converts. smolanalytics answers those from one snippet: funnels, retention, paths, and cohorts across your whole app, with server-side events for the parts the browser never sees. You ask in plain English ("how many users tried the AI feature twice?", "where do people drop off in the chat flow?") from a dashboard bar or your own Cursor or Claude over one MCP connection (your org token, set up once and it operates every project by passing project="name", with the read key kept server-side), and here is the part that matters to people who build with models: every answer is computed from deterministic reports, never generated by an LLM. It is also an investigator, not just a query surface: it checks every event on a schedule and the dashboard opens on the desk, the single most expensive finding first with the segment carrying it, so a chat flow that starts leaking is a conclusion you read, not a chart you had to notice. If you are building an AI agent, it also computes agent observability from the same events: tool-call error rates and latency (p50/p90/p99), an error taxonomy, and conversation health like re-asks, abandons, and resolution. And for the question counting cannot answer, what people are actually asking your agent about, your OWN model does the reading: over MCP it samples whole conversations (sample_conversations), infers labels like intent, sentiment, or frustration, and writes them back as append-only events (label_conversation), and smolanalytics counts conversations per label value (agent_labels). The labels are that model's inference, always reported with the model named and with labeled and unlabeled counts beside them; the counts over them are computed like every other number. Because it runs on the model you already pay for, it is free and unmetered on every plan, where the usual approach runs an LLM server-side over every message and bills you per message. You bring your own AI key, so the natural-language layer is free. It is free for 14 days with no card, then $19/month, and your data exports in one file any time.

product analytics for the app around the model, not a trace viewer

Product analytics, not just LLM traces
Observability tools show you traces, tokens, and prompt latency. They do not show adoption. smolanalytics answers the product questions: is the AI feature used, how often, by whom, and where people abandon it, with funnels, retention, paths, and cohorts from one snippet.
Answers computed, never hallucinated
The one audience that knows how confidently a model makes things up. Here every answer is computed from deterministic reports, never generated by an LLM.
Ask where the chat flow drops off
"how many users sent a second message?", "where do people abandon the chat?", "did activation improve after we shipped the new prompt?" Ask in plain English from the dashboard or your own Cursor / Claude over one MCP connection (97 tools, 15 prompts, set up once and it operates every project in your org, read key kept server-side), and bring your own AI key so the language layer costs you nothing.
What people ask about, labeled by your model
Counting tells you the re-ask rate, not what the conversation was about. So your own model reads it: sample_conversations hands it whole conversations over MCP, it infers intent / sentiment / frustration, label_conversation writes that back as an append-only event, and agent_labels counts conversations per label value. The labels are that model's inference and always come with the model named plus labeled and unlabeled counts; the counts over them are computed. We never run a model over your conversations, so it's free and unmetered on every plan instead of billed per message.
One snippet, client and server, cheap
The browser tracks feature use; your server posts the events it never sees (completions finished, jobs run, webhooks). Same distinct_id fuses them into one path. ~7 bytes an event, no Kafka or ClickHouse, $6 per million (vs the big tools' ~$50), cookieless mode with no consent banner.

Honest pricing: 14-day trial at Pro limits, no card. Then Pro $19/mo or Scale $49/mo, with $6 per million events (vs the big tools' ~$50). Bring your own AI key so the natural-language layer is free, and conversation labelling runs on that same model of yours, so it is unmetered on every plan instead of billed per message. Your data exports in one file any time.

Point your AI app at it tonight.

One snippet in the browser, server events over one endpoint, same distinct_id. Tomorrow morning the verdict tells you whether the AI feature is landing, and where the chat flow leaks.

questions

Isn't this the same as LLM observability like tracing and token dashboards?
No, and you likely want both. Observability tools (traces, token counts, prompt latency, eval scores) tell you how a model call behaved. smolanalytics tells you how people behave: whether the AI feature is adopted, how often it's used, where users drop off in the chat flow, and what converts. It is product analytics for the app around the model, not a trace viewer.
Why does 'answers are computed, not generated' matter for an AI app specifically?
Because you, more than anyone, know how confidently a model will invent a number. smolanalytics never lets an LLM produce the figure. Every answer is computed from deterministic reports; the natural-language layer only phrases what the reports already returned.
How do I track an AI feature's usage and drop-off?
One snippet in the browser tracks feature use and the steps of your chat or generation flow, and your server posts the events the browser can't see (a completion finished, a job ran, a webhook fired) to POST /v1/events with the same distinct_id. From there you get funnels (started the chat vs sent a second message), retention, paths, and cohorts, and you can just ask "where do people drop off in the AI flow?" in plain English.
Can I find out what users are actually asking my agent about?
Yes, and your own model does the reading, not ours. Call sample_conversations over MCP and it returns whole conversations (your agent_turn events grouped by conversation_id, oldest turn first, a capped deterministic sample; a turn only carries text if your app sent a text property). Your model reads them, infers a label per conversation, and calls label_conversation to append its inference as a new agent_label event, so nothing already recorded is mutated. Then agent_labels counts conversations per label value: intent 41 billing, 22 bug report, 9 pricing. Be clear on which half is which, because the product is: the label values are your model's inference and every result names the model that wrote them plus how many conversations are labeled and unlabeled, while the counts over them are computed from your event log and computed across GET /v1/agent/labels, the MCP tool, and the dashboard. Since it runs on the model you already pay for, it is free and unmetered on every plan, rather than an LLM we run server-side over every message and bill you for.
Is it enough for a real AI product, or should I keep another tool?
It does funnels, retention, paths, cohorts, channel-and-revenue attribution, and a daily verdict on what to fix, across client and server events, from one binary. It also ships feature flags, A/B experiments, click heatmaps, in-product surveys, and a session inspector that replays a user's journey from their events; the one thing it does not do is pixel-perfect DOM session recording. If you are building an AI agent, it also computes agent observability from your events: tool-call error rates and latency (p50/p90/p99), an error taxonomy, and conversation health like re-asks, abandons, and resolution, plus a sample-and-label loop where your own model reads conversations over MCP and labels them by intent or sentiment and we count the labels. It is not an eval or trace tool, so pair it with an LLM observability tool if you need per-call traces and evals. It is for builders who want a straight, owned, cheap answer on whether the AI feature is working.

keep reading