how do i know what to fix in my product? (analytics that gives a verdict)

your ai assistant admits it hallucinates your numbers. mine can't. it's a CI test. that is the whole difference, and it is why you can act on the answer instead of double-checking it. most analytics tools bolt an AI on top that generates a query against your data; a generated query is a second path, and it can disagree with the computed report, so the model confidently returns a wrong number. smolanalytics does the opposite: its AI calls the exact same deterministic reports the HTTP API serves, never generated SQL, so it returns the real computed number or nothing. that is not a promise in a README: a CI agreement test asks the same question through the HTTP API and through the AI's channel, and fails the build if the two answers differ. on top of that, npx smolanalytics desk opens with a verdict, a sentence that says what changed and what to fix, instead of a wall of charts. so "what should i fix?" has a trustworthy answer, right where you work.

how do i know what to fix in my product?

honestly, most tools do not tell you; they hand you charts and expect you to find it. that is the problem the verdict is built to solve.

open almost any analytics dashboard and you get a grid of graphs. the number is in there somewhere, but the tool has quietly outsourced the actual job (figuring out what changed and what it means) back to you. you came to find out what is wrong, and you leave with homework.

the verdict inverts that. npx smolanalytics desk opens with a sentence, not a chart: what dropped, where the leak is, what to look at first. the charts are still there, underneath, as evidence. but the read comes first. the same thing is available as a tool your coding assistant can call, so the morning triage ("anything broken today?") runs without you opening a tab.

here is the shape of a verdict (example numbers; this launched recently and there is no real traffic worth quoting):

you ▸ what's broken today?
ai  ▸ one thing changed: signup is down [18%] vs a typical
      day ([94] vs [115]), starting around 14:00. tracking is
      healthy: all 6 planned events flowing, referrers normal.
      this is a product problem, not a tracking one. most useful
      action: check yesterday's deploy to the signup form.

what's wrong with my funnel?

that is exactly the question the product-analytics side answers, and it answers it as a read, not a chart.

funnels, retention, paths, and cohorts are all built in, on every plan, from the same events as the web analytics. so "where do people drop off after signup" is one question, and the answer names the step and the size of the leak rather than drawing you a bar chart to squint at. you ask it from your editor, over MCP, and the number is the real computed number rather than a model's guess at one.

can i just ask, in my editor?

yes; that is the intended way to use it. you run npx smolanalytics connect once, and your coding assistant (Claude Code, Cursor, Windsurf, and other MCP clients) gets analytics as an MCP server: 97 tools and 15 built-in prompts. then you ship a feature and ask "did it work?" in the same window you wrote it, without alt-tabbing to a dashboard.

there are ready-made routines behind a slash: whats-broken-today is the morning triage, weekly-review is the recap a good cofounder would give you, instrument-my-app wires tracking on a fresh repo. each one calls the right tools in the right order and gives you the read, not a data dump.

why can i trust the number the AI gives me?

because the AI does not write a query, and there is a test proving its answers match the HTTP API.

this is the load-bearing claim, so here is the mechanism. every other tool's AI assistant works by generating a query (PostHog's MCP, for example, lets the model write HogQL). a generated query is a second path to your data, and a second path can drift from what the API computes, which is how these assistants hallucinate a number that looks plausible and is wrong. smolanalytics's MCP tools do not generate queries at all. they call the exact same deterministic report functions the HTTP API serves, so there is no second path to disagree.

and that is enforced, not asserted. the agreement test seeds a server, asks the same question through the HTTP API and through the MCP server, and fails the build if the answers are not identical. it runs in CI on every commit, so the claim cannot quietly rot. the honest caveat: your model can still ask the wrong question. it just cannot invent the number.

how is this different from PostHog?

PostHog is a bigger platform with more depth: pixel-perfect DOM session recording and the heaviest experimentation stack, the works. the difference that matters for "what do i fix" is three things it structurally cannot match, because matching them would break its business. its AI is metered (yours is free, you bring your own model), its assistant generates queries that can be wrong (ours calls deterministic reports and CI-checks them against the HTTP API), and its data lives in one shared cloud (yours gets its own isolated instance, exportable in one file any time). if you want the full suite and are happy to pay for it or run the cluster, PostHog is the better pick.

if you want pixel-perfect DOM session recording, use PostHog; smolanalytics ships flags, experiments, heatmaps, surveys, and a session inspector, but that inspector replays a journey from events, not the raw DOM, and pixel-perfect recording is the one thing on this tool's deliberate never-list. if you want a trustworthy answer to "what should i fix?" without an ops project or a metered AI, this is the trade.

what does it cost, and why should i believe any of this?

a 14-day trial at Pro limits with no card, then $19/month on Pro (2M events, one plan), $6 per million past that, and reads never lock.

on believing it: this is one person, it launched recently, there are no testimonials because there are none, and none will be faked. so trust does not come from a track record; it comes from the design. the agreement test runs on every commit, every answer ships a computed_by receipt you can re-run, and your data exports in one file any time, so the worst case is you leave with everything. the number cannot be made up, and that is the one property i would not ship without.

if you want the verdict for your own product, start the trial: 14 days, no card, and tomorrow's brief tells you what to fix first.