Your agent writes the tracking. Proven correct.
Start by finding out what is missing. One command reads the repo you are standing in and names the user actions nothing is measuring, with the file and the line. No account, no key, and no network call, so your code never leaves your machine.
$ npx smolanalytics audit
3 things your product does that nothing is measuring.
An action nobody instrumented looks identical to one nobody performed.
untracked payment app/api/checkout/route.ts:42
suggested event: checkout
untracked signup app/(auth)/signup/page.tsx:88
suggested event: signup
untracked invite lib/team.ts:117
suggested event: invite_sent
Also seen, mostly not worth an event: 9 form submits, 14 api mutations.Then npx smolanalytics init wires the snippet: it works out what your project is, names the one file it will edit before touching anything, and refuses to write a placeholder key rather than leave you an app that looks instrumented and sends nothing.
npx smolanalytics audit reads the repo you are standing in and names the user actions nothing is measuring, with the file and the line: payments first, then signups, logins, invites, deletions, shares, uploads. Generic shapes like a form or a POST handler are counted as a footnote rather than padding the list, because a report of 497 findings gets dismissed once and never opened again. No key, no signup, and no network call on this path.
One snippet and you are already capturing pageviews, every click with its element chain, honest engagement time (focused and visible seconds, not a backgrounded tab), scroll depth, rage clicks, dead clicks and JS exceptions. No track() calls needed for any of it. npx smolanalytics init works out what your project is and names the one file it will edit before touching anything.
Connect your editor with npx smolanalytics connect, then type /instrument-my-app. Your agent calls propose_instrumentation, which reads the repo and hands back the exact track() calls for signup, activate and checkout with file, line and properties. The agent applies them, guided by us. We never touch your code, your agent does.
verify_instrumentation cross-references the code and live traffic and returns FIRING, WIRED (in the code, just run the flow) or MISSING per event. No guessing, no waiting a day. PostHog's wizard sets you up once; this proves it worked in seconds.
The tracking plan is committed to your repo and npx smolanalytics plan check gates CI, so the build fails the day a tracked event stops firing. The plan is also what makes the unattended restore safe: with no declared plan, an event that broke and an event you retired on purpose are indistinguishable, so nothing acts.
When an event in your tracking plan stops arriving but the traffic behind it doesn't, smolanalytics finds the commit that deleted the track() call and opens a pull request putting it back. The line comes back verbatim out of the parent blob, not generated. Off by default twice over: a deployment-wide switch, and a per-project setting that starts at off. Worst case is a duplicate track() call, visible in the dashboard that opened the PR, undone by closing a PR nobody merged.
The whole setup, in commands
Four commands exist. That is the entire surface, and every one of them runs through npx on your own machine:
npx smolanalytics audit # what nothing is measuring, no account needed npx smolanalytics init # wire the snippet into this project npx smolanalytics connect # wire the MCP server into your editors npx smolanalytics plan check # fail CI when a planned event stops firing # then, in the editor you just connected: /instrument-my-app # → reads your repo, writes the track() calls, declares the plan, # and proves each event fires before it's done
No coding agent? Skip code entirely and define events from clicks you already captured, right in the dashboard. Nothing on this page needs a terminal except the four commands above, and the first of them needs no account.
What the events buy you
Instrumentation is not the product, it is what the product reads. A wired event is what lets a merge come back with a number on it: about a day after a pull request lands, the metric that actually moved is posted onto that PR, chosen from your own events, and on the days nothing moved there is no comment. Every event you track is swept for step changes on a schedule, not just the four you would have suspected, so each event your agent wires widens what can be caught. And the loop closes from the same editor: when you ship a fix, mark_finding_acted records it, and the finding upgrades to verified only if the metric recovered after the date you acted. The full sequence is on how it works.
Worth saying plainly: none of that can tell you anything on the first day. A step change needs a baseline, and the first deploy comment needs a merge with a real after-window behind it. The audit and the CI gate are what work immediately, which is why they come first on this page instead of last.
Why this beats the rest
Everyone else makes you instrument by hand, or can't keep it correct:
| Tool | How you get your custom events |
|---|---|
| smolanalytics | Your coding agent writes the track() calls over MCP; a CI drift gate fails the build the day a tracked event stops firing; verify_instrumentation proves each one is wired and firing in seconds. Autocapture covers the rest. |
| Heap | autocaptures everything but can't touch your code, you define events by hand in their UI |
| Mixpanel / Amplitude | taxonomy first, you plan the events in a governance tool, then hand-write every track() call |
| Segment | enforces a tracking plan but you still write all the instrumentation yourself |
| PostHog | a setup wizard installs it once, but custom events are manual and nothing gates the plan in CI |
smolanalytics is the only one where the AI writes the instrumentation for you and a CI gate proves it stays correct and autocapture fills in everything else.
npx smolanalytics audit
Then wire it up