instrument your app without writing tracking code

automatic event instrumentation means your analytics tool records user behavior without you hand-writing track() calls for every button. smolanalytics does it in two layers: a script tag autocaptures the baseline (pageviews, clicks, scroll, rage clicks, JS exceptions, form submits) with zero code, and for the custom business events that autocapture can't name, your coding agent reads your repo over MCP and writes the instrumentation for you. no taxonomy meeting, no manual track() sprint.

why do you have to write tracking code at all?

with most analytics tools, you write tracking code because the tool ships blind. mixpanel and amplitude are taxonomy-first: you sit down, design an event schema, argue about naming conventions, then send an engineer to sprinkle track('Signup Completed', {...}) through the codebase. six months later half the events are stale, three are misspelled, and nobody trusts the funnel. the instrumentation is the product's second job and it always rots.

smolanalytics flips the default. you drop one script tag and autocapture starts recording immediately, retroactive to the moment you install. it captures pageviews, every click with a full $elements selector chain (so you can identify the exact button later), engagement time, scroll depth, rage clicks, dead clicks, uncaught JS exceptions, and form submits. that's the baseline behavioral layer, and you wrote zero code for it.

what can autocapture NOT do on its own?

autocapture can't name your business logic, because it only sees the DOM, not your intent. it knows someone clicked a button with a specific selector chain. it does not know that click means "user upgraded to the Pro plan and we charged them $9." that semantic layer is the part that used to force you into a manual instrumentation project.

there are two honest ways to close that gap in smolanalytics, and you pick based on whether the signal already exists in the DOM.

if the event is a click or pageview you already captured, use a defined event. this is the Heap move: name a business event retroactively from clicks already in your data, no code, no agent, retroactive to install. "Pro upgrade = clicks on button.upgrade-cta on /pricing." done.

if the event needs data that isn't in the DOM (a server-confirmed charge, a value that lives in app state, a step that never renders as a distinct element), that's where the agent comes in.

how does the coding agent write the tracking code?

your coding agent instruments the app by reading the repo over MCP and proposing the exact track() calls, then proving they fire. connect Cursor or Claude Code to smolanalytics over MCP and the flow is:

1. propose_instrumentation reads your codebase, finds the spots that need a custom event (the checkout confirmation, the async success handler), and drafts the track() calls with sensible names and properties.
2. you review the diff and apply it. it's normal code in your repo, not a hosted config you can't see.
3. set_tracking_plan commits those events into a tracking plan, so the names are now the contract.
4. verify_instrumentation actually exercises the paths and proves each event fires with the right shape. it's cloud-aware through a local proxy, so it works against your real deployment, not just localhost.
5. plan check runs in CI so the plan and the code can't silently drift apart later.

so the difference from Heap: Heap autocaptures but can't touch your code, which means custom server-side or state-derived events are still your problem. smolanalytics autocaptures AND lets the agent write the real track() calls where the DOM isn't enough. the difference from mixpanel/amplitude: you're not designing a taxonomy up front and hand-instrumenting it. the agent proposes, you approve, CI enforces.

how do i know the instrumented numbers are real?

the numbers can't drift because there's a plan-as-code gate and a committed test that forces the AI answer, the api, and the dashboard to agree. the tracking plan lives in your repo. plan check --code catches static drift (an event you renamed but forgot to update) and a traffic-based check catches events that stopped firing in production. plan sync reconciles them.

on top of that there's an agreement test that asserts the AI ask-bar answer equals the /v1 api response equals the dashboard, byte for byte, so a number can't be hallucinated into existence. you can read it: github.com/Arjun0606/smolanalytics/blob/main/internal/api/agreement_test.go. and every answer you get from the ask bar ships a computed_by receipt showing the exact deterministic report and scope behind it, so you can check the math instead of trusting it.

so what's the actual workflow?

drop the tag, get the baseline free, then let the agent handle the events the tag can't see. concretely: install the script, autocapture starts. name your obvious business events as defined events, retroactive, no code. for the events that need custom data, point your coding agent at the repo and run propose then verify. commit the plan, add plan check to CI, and now instrumentation maintains itself instead of rotting.

no session replay, no feature flags, no heatmaps, no surveys. it's one Go binary that does analytics you can ask in plain english, and it doesn't make you write the tracking code.

try it: self-host free (MIT, single binary), or Solo is $9/mo, or poke the live demo at smolanalytics.com. importers from PostHog, Mixpanel, Umami, and CSV are built in if you're moving over.