Smolanalytics

That's the real product on demo data. Run it yourself in 30 seconds below. ([still image](docs/dashboard.png))

See it live, no install

smolanalytics-demo.fly.dev is the real product on demo data, running right now. The verdict up top, the ask bar, your events and pages as chips. Click checkout, or type "visitors to /pricing", and get the exact computed answer. The whole thing, one click away.

Run it yourself (30 seconds)

# Docker
docker run -p 8080:8080 ghcr.io/arjun0606/smolanalytics demo

or grab the binary:

curl -fsSL https://raw.githubusercontent.com/Arjun0606/smolanalytics/main/install.sh | sh
smolanalytics demo

or with Go:

go run github.com/Arjun0606/smolanalytics/cmd/smolanalytics@latest demo

Give it a few seconds to pull and seed, then open localhost:8080. Same fully populated dashboard, now on your machine. (If port 8080 is busy, use -p 8081:8080 and open localhost:8081.) The ask bar shows your real event names and pages as chips, so asking is a pick, not a guess: click checkout or type "visitors to /pricing" and get the exact computed answer.

Two ways to ask (and which is which)

smolanalytics answers plain-English questions on two surfaces. They are different, and keeping them straight is the whole model:

• The dashboard ask bar asks about your data. It's built in, zero setup, deterministic. It does not read your code: it knows your events and pages because they're in your data, and it shows them as chips so you never guess a name. Good for "how many checkout this week?", "visitors to /pricing", "where do people drop off?".
• Your coding agent over MCP (Cursor / Claude Code) asks code-aware questions. It has your codebase, your tracking plan (smolanalytics.plan.json), and smolanalytics over MCP, so it bridges the two: ask "what's the MAU for the PQR page" and the agent knows PQR is the /pqr route from your code, then queries smolanalytics for it. This is also where you instrument ("add tracking to the checkout flow I just built") and verify.

Recurring metrics never need re-typing: pin any report you build (or have your agent call save_report) and it renders on the dashboard every visit.

Why this exists

Every analytics tool now has an AI assistant, but it's bolted inside their app, you pay for it, and you still leave your editor to use it. smolanalytics flips it: the analytics comes to where you already work, answered by the model you already pay for.

• Ask in your editor, for free. It's an MCP server: connect Claude / Cursor / Claude Code and ask in plain English. Your model does the reasoning, so there are no API keys and no metered AI credits. The dashboard has a built-in ask bar too, zero setup.
• Answers are computed, never generated. Every other tool's AI assistant admits it hallucinates. Ours calls exact, deterministic reports (not guessed SQL), so the number it returns is the real computed number or nothing. Your model can still ask the wrong question, but it cannot invent an answer. And this isn't a promise, it's CI: [the agreement test](internal/api/agreement_test.go) asserts the MCP answer and the HTTP API answer are identical for the same question, every build, forever. There is no second query path that can drift.
• Google Search Console, built in. smolanalytics gsc auth (BYO OAuth client, two env vars) and your top search queries (clicks, impressions, position, biggest movers) appear on the dashboard, in the search_console_report MCP tool, next to what those visitors did after landing.
• Real product analytics AND web analytics, one tool. Funnels, retention, trends, segmentation, lifecycle, stickiness, paths, cohorts, B2B accounts, plus the Plausible-shaped web view (visitors, live-now, top pages, referrers, UTM sources, devices). The usual answer is "run Plausible AND something heavier"; this is both, in one binary.
• One binary, not a cluster. No Kafka/ClickHouse/Redis, no 12-hours-debugging-self-host. docker run and it's up. Your data never leaves your box and never trains anyone's model.
• One instance, all your projects. The SDK stamps every event with its site's hostname: point every product you run at the same instance, switch sites on the dashboard, filter any report (or any MCP question) by site, and the morning brief breaks down per product. You do not need a server per project.
• Beautiful by default. Server-rendered, instant, opinionated. It looks designed, not assembled.
• Open source (MIT), genuinely self-hostable. Own the whole thing, with no paywalled features stripped from the self-hosted edition.

Why not just use Mixpanel or PostHog? They're deeper, but there are three things they structurally can't match, because it would break their business: (1) the AI is yours, so it's free (they meter theirs); (2) answers come from exact reports, not generated SQL, and CI enforces that they match the dashboard, which their own MCP docs don't promise; (3) your data never leaves your box (theirs lives in their cloud). Same funnels/retention, a fraction of the price, and it tells you what to fix instead of making you dig. You can even try it before moving anything: plan check --source=posthog runs our tracking-drift gate against your existing PostHog project, and when you switch, smolanalytics import replays your history with original timestamps ([docs/migration.md](docs/migration.md)).

The most private analytics you can run

Every hosted analytics tool, the privacy-first ones included, still asks you to trust their servers with your users' data. smolanalytics keeps no cloud in the loop: it's a binary on your own box, so the data physically never leaves your infrastructure.

• No third party, ever. Nothing to sign a DPA with, no processor to disclose, nothing crossing a border. The answer to "who can see this data?" is just: you.
• No third-party cookies, no fingerprinting, no cross-site tracking. The browser SDK uses a first-party anonymous id and nothing else.
• Cookieless mode, no consent banner needed. smolanalytics.init(key, { anonymous: true }) stores nothing on the visitor's device; the server derives a daily-rotating anonymous id instead (Plausible's model). Visitors are unlinkable across days, funnels still work within a day, and identified users (after login) keep full analytics. Consent banners cost ~55% of your data; this mode needs none.
• Right to erasure, built in. DELETE /v1/users/{id}/data (or ask your AI: "delete everything about user u123") erases a person's events across every storage tier. The GDPR request that takes a ticket queue elsewhere is one call here.
• It never trains a model. There's no model and no vendor, so there's no one to train on your data.
• Private by architecture, not by policy. It isn't private because of a promise on a privacy page; it's private because there's no one else in the loop.

Plausible, Fathom, and Simple Analytics are lovely, and far more private than Google. But they're still a cloud you send data to. Self-hosting is the version where the data never leaves at all.

Built to outlive its maker

Betting on a small tool shouldn't mean betting on the person behind it. The architecture makes us unnecessary:

• MIT, no CLA. There is no license to revoke and no relicense lever to pull ([LICENSE](LICENSE)). Fork it the day you stop liking us.
• One static binary, no external services. It calls no hosted API, has no license server, and never phones home. It does not know we exist.
• Your data is open files on your own disk. An append-only log that seals into columnar segments, with the format and its compatibility guarantees written down in [STABILITY.md](STABILITY.md) and [docs/design/storage.md](docs/design/storage.md).
• Export any time. GET /v1/export hands you everything as CSV or JSONL, and the JSONL round-trips straight back into /v1/events.
• Works forever without us. If this repo went dark tomorrow, your instance would not notice.

Ask it in your editor (the whole point)

This is the code-aware surface: your coding agent has your codebase, your tracking plan, and smolanalytics over MCP, so it answers questions in your own terms. Ask "what's the MAU for the PQR page" and it knows PQR is the /pqr route from your code, then queries smolanalytics for it. (For quick data questions with no code lookup, the dashboard ask bar is faster and needs no setup. See "Two ways to ask" above.)

Connect once:

smolanalytics connect          # wires it into every coding assistant you have installed

That's it: restart the editor and ask "where are users dropping off this week?". It detects your installed assistants and merges the config in (keeping any MCP servers you already have). Target one with smolanalytics connect :

| Assistant | connect | It configures | |---|---|---| | Claude Desktop | claude | claude_desktop_config.json | | Claude Code | claude-code | runs claude mcp add for you | | Cursor | cursor | ~/.cursor/mcp.json | | Windsurf | windsurf | ~/.codeium/windsurf/mcp_config.json | | VS Code (Copilot) | vscode | user mcp.json (servers key) | | Cline | cline | cline_mcp_settings.json |

Any MCP client works: it's a standard stdio + Streamable-HTTP server.

Building with Lovable, Bolt, v0, or Replit instead? You don't need any of the above. Sign up, create a project, and it hands you one prompt to paste into your app builder. The builder's AI installs the snippet and wires your key events itself. From then on the dashboard answers questions in plain English and the morning brief lands by email: zero code, zero terminal. More at smolanalytics.com/for/lovable.

Wire it up by hand (or point at a running/remote server over HTTP)

stdio (local, no server needed, reads your data file directly):

{ "mcpServers": { "smolanalytics": { "command": "smolanalytics", "args": ["mcp"] } } }

HTTP (point at a running instance, local or remote, shares its live data):

{ "mcpServers": { "smolanalytics": { "url": "http://localhost:8080/mcp" } } }

Claude Code, HTTP: claude mcp add --transport http smolanalytics http://localhost:8080/mcp Zed: add to context_servers in settings. VS Code: the top-level key is servers, not mcpServers.

(When a write key is set, add "headers": { "Authorization": "Bearer YOUR_KEY" } next to the url.)

Then just ask, in the same window you write code:

you ▸ how's activation, and is pro converting better than free?
ai  ▸ Activation is 62% (657 of 1,051 signups reach "activate").
      Pro converts 2.4× better end-to-end: 45% signup→checkout vs 19% on free.
      The leak is activate→checkout on free (only 31% continue). Want the paths after activate?

Your model gets 47 tools + 13 built-in prompts. The editor runs the whole thing, not just queries:

• Ask: whats_notable (the what-to-fix verdict), overview, list_events, funnel, retention, trends, breakdown, web_overview (traffic at a glance), lifecycle, stickiness, paths, groups (B2B accounts), recent_events, user_activity, every one filterable by property (plan=pro, source=hn, …).
• Do: "alert me if signups drop below 10 a day" → create_alert; "send alerts to Slack" → add_webhook; "track paying users as a group" → create_cohort; "pin that funnel to my dashboard" → save_report, plus list/delete for each. Everything created in your editor appears on the dashboard instantly (same stores, one source of truth). A saved report keeps rendering on the dashboard every visit, so recurring metrics never need re-typing.
• Run the instance: rename the project, set the timezone and retention, create/revoke API keys, full settings parity, no browser.
• Verify the instrumentation (built for AI-assisted building): the agent that wires your tracking declares it with set_tracking_plan, then instrumentation_health checks reality against the plan: which events are flowing, which never arrived, which expected properties are missing. The loop closes: build → instrument → verify → watch, all in the editor.
• Prompts: 13 named jobs surfaced natively by MCP clients: instrument-my-app (full setup, end to end), whats-broken-today (the morning check), weekly-review and monthly-report (founder-grade recaps), funnel-leak, launch-day, money-pages (the SEO wins already in reach), and the rest. The full library, with what each reads and the shape of the answer: [docs/prompts.md](docs/prompts.md).

Shipping with an agent? Make tracking automatic

If Claude Code or Cursor writes your features, it can write your instrumentation too: one block in your repo's CLAUDE.md / AGENTS.md / .cursorrules tells your agent to add track() for every feature it ships, keep smolanalytics.plan.json current, and verify events actually flow with smolanalytics plan check after each deploy. The copy-paste block and the full build → instrument → verify loop: [docs/agents.md](docs/agents.md). Already on PostHog? plan check --source=posthog runs the same gate against your existing PostHog project, no server, no migration ([docs/agents-ci.md](docs/agents-ci.md#already-on-posthog)).

Which deploy moved the metric?

Every other analytics tool shows you the graph dropped. It can't tell you which ship dropped it — it doesn't have your commits. smolanalytics does.

Record a marker when you ship (one line in CI), and it ties every metric change to the deploy behind it:

# in your CI, after deploy — records the current git HEAD as a deploy marker
smolanalytics deploy      # SMOLANALYTICS_HOST + SMOLANALYTICS_WRITE_KEY set
# or from anywhere:  curl -XPOST $HOST/v1/deploys -H "Authorization: Bearer $WRITE_KEY" \
#                      -d '{"sha":"'"$GIT_SHA"'","message":"tighten checkout validation"}'

Then ask your editor — the answer is computed from the same reports the dashboard renders, never guessed:

you ▸ did my last deploy move signups?
ai  ▸ signups −38% in the 3 days after deadbeef "tighten checkout validation"
      (was 22/day, now 13/day). Significant given the volume — likely a regression.
      Correlation, not proof, but that ship is the suspect.

It's the deploy_impact MCP tool (before/after per deploy, leads with any regression) and GET /v1/deploys?event=. Both compute the same numbers — a CI test asserts the editor's answer equals the dashboard's, so it can't drift. Correlation, not proof: the copy always says so.

Send events (2 minutes, zero instrumentation)

Drop the snippet in and it autocaptures pageviews + clicks instantly, so you get real data with no manual event tagging. Add track() for the key moments (signup, checkout) when you want funnels.

  smolanalytics.init("YOUR_WRITE_KEY", { host: "https://YOUR_HOST" });
  // that's it: pageviews + clicks are captured automatically.
  // optional, for funnels:
  smolanalytics.tra

…

## Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [Arjun0606](https://github.com/Arjun0606)
- **Source:** [Arjun0606/smolanalytics](https://github.com/Arjun0606/smolanalytics)
- **License:** MIT
- **Homepage:** https://smolanalytics.com

Install and usage instructions live in the source repository linked above.