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 (97 tools, 15 prompts), using your own AI model so the AI part is free.
- 2An investigator, not just charts. It reads your event log on its own, and the dashboard opens on the desk: the most expensive finding up top, a queue of findings with their status (needs you, recovered, verified), and a quarter table of whether your metrics moved at all, with the report library behind a menu. The point of product analytics is a decision, so it leads with 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.
- 4One binary. Your project runs as its own single Go binary, stdlib only, roughly 7 bytes per event, no Kafka, ClickHouse, or Postgres to run, and your data exports in one file any time.
It now ships feature flags, experiments, heatmaps, surveys, and a session inspector too, without a suite you have to operate or a per-seat bill. The one thing it deliberately skips is pixel-perfect DOM session recording; the session inspector replays journeys from events, not video. If you build AI agents, 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. 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.