What is product analytics?
Product analytics is the practice of measuring how people actually use a product by tracking the actions they take inside it, then turning those events into funnels, retention curves, user paths, and cohorts, so a team can see where users convert, where they drop off, what keeps them coming back, and what to fix next.
How is product analytics different from web analytics?
They answer different questions, and the sharpest way to keep them straight is acquisition versus behavior. Web analytics measures how people arrive: pageviews, sessions, unique visitors, referrers, UTM campaigns, bounce rate. It is anonymous by default and organized around the page.
Product analytics measures what people do once they are inside: it tracks named events (signed up, invited a teammate, hit the aha moment, upgraded) tied to a stable per-user identifier, and organizes them around the person and their journey, not the page. That identity is what unlocks funnels, retention, and cohorts, none of which a pageview counter can produce.
The line is not a wall. A signup is a product event; a landing-page visit is a web event; the funnel from a marketing pageview to an in-app upgrade crosses both. The two are most useful together, which is why smolanalytics does both from one snippet, so a user's referrer, their first click, and their eventual conversion live on one timeline instead of in two tools that never agree.
What are the core product analytics reports?
Almost every product question resolves to one of four reports. Learn these and you can read a product's health without a data team.
All four run off the same raw material: named events with a stable distinct_id. Send that well once and every report above becomes a question you can just ask.
How smolanalytics does product analytics
smolanalytics gives you funnels, retention, paths, and cohorts (plus web analytics) from one snippet or one endpoint. What makes it different is not the report list, every tool has those, but four choices about how you get the answer:
- 1Ask in plain English. Instead of building a dashboard for every question, you type "where do trials drop off?" or "did activation improve since the new onboarding?" into a dashboard bar, or into your own Cursor / Claude Code over MCP (47 tools, 13 prompts), using your own AI model so the AI part is free.
- 2A verdict, not just charts. Beyond the reports, it tells you what to fix, on the dashboard and in a morning brief. The point of product analytics is a decision, so it surfaces the decision, not another graph to interpret.
- 3Computed, never guessed. Every answer comes from the same deterministic reports the dashboard renders, not from an LLM writing numbers. A CI agreement test fails the build if the AI answer ever differs from the dashboard, so the number you get is the real one.
- 4One binary. It is a single MIT-licensed Go binary, stdlib only, roughly 7 bytes per event, no Kafka, ClickHouse, or Postgres to run. Self-host it free forever, or use the hosted cloud.
It deliberately does not do session replay, feature flags, experiments, heatmaps, or surveys. It is for teams who want a straight, owned, cheap answer on what to fix. See every feature, how it compares vs Mixpanel, or the SaaS use case.