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