What is event instrumentation?
The work of making your product record user actions as named events, the foundation every funnel, retention curve, and cohort is built on.
the anatomy
What makes up an event
Instrumentation is getting three things right for every event, consistently:
- ·A name. What happened, like signup_completed. This has to be consistent, because signup, sign_up, and Signup are three different events to a query engine.
- ·A per-user id. A distinct_id so the event joins to that person's other activity, and their browser and server events land on one timeline.
- ·Properties. The context, like plan, amount, or source. Missing properties are why a breakdown you want later turns out to be impossible.
three ways to do it
How events actually get instrumented
There is more than one way to get events flowing, and they trade off speed, precision, and how much history you have.
manual (write track calls)
A developer adds a track() call at each moment (signup, upgrade) and deploys. Precise and explicit, but slow, easy to forget, and nothing exists until it is coded, so a question you ask later often has no data behind it.
autocapture + defined events
A snippet records every click automatically, then you name a business event from the clicks you already captured, retroactive to install, no code and no deploy. Fast and retroactive, best for events that map cleanly to a UI element.
agent-written
A coding agent reads your repo, proposes the track() calls where they belong, adds them, and proves each one fires before you trust it. You get manual precision and custom events without hand-writing and hand-verifying every call.
Most teams need all three: broad autocapture for the floor, retroactive defined events for the clean cases, and agent-written custom events for the moments a click cannot express.
how smolanalytics does it
Let the agent instrument, then prove it fires
In smolanalytics you do not hand-write and hand-check every track call. On top of autocapture, you connect your coding agent (Cursor, Claude Code) over MCP and it does the instrumentation for you:
propose_instrumentation: reads the repo and writes the track() calls where they belong
verify_instrumentation: proves each event actually fires (cloud-aware via a local proxy)
The verify step is the part that matters: most instrumentation bugs are events that were added but silently never fire, so you find out months later that a funnel has a hole. Proving each event fires before you trust it closes that gap. And for the clean cases you skip code entirely and name a defined event from clicks you already captured, retroactive to install.
To keep names from drifting once instrumented, smolanalytics also has a committed tracking plan with drift gates. See every feature.
Common questions
What is event instrumentation in simple terms?
It is setting up your product so the things users do get recorded as named events. When someone signs up, an event called signup arrives in your analytics with details like their plan and source. Instrumentation is the work of making those events fire reliably, so that later, when you want a funnel or retention curve, the data is already there and named consistently.
What makes up an event?
Three things: a name (what happened, like checkout_completed), a per-user identifier (a distinct_id so the event ties to that person's other activity), and properties (context like plan, amount, or source). Consistent names and complete properties are what let you build funnels, break results down, and trust the numbers. Sloppy names (signup vs sign_up) and missing properties are the most common instrumentation failures.
Why is event instrumentation hard to get right?
Because it is manual and easy to skip. Event names drift across the team, properties get left off, and events you did not think to add three months ago simply have no history when you finally need them. The result is a report with gaps or a number nobody trusts. The fixes are recording broadly up front (autocapture) so you can name events retroactively, keeping a committed tracking plan so names cannot drift, and having an agent write and verify the calls so they actually fire.
What is the difference between autocapture and event instrumentation?
Autocapture records raw interactions (clicks, pageviews) automatically with no code, but they are generic, a click on an element, not "upgraded to Pro." Event instrumentation is giving those actions business meaning as named events. In practice they work together: autocapture gives you the breadth for free, and instrumentation (retroactive defined events, or a few custom track calls) names the moments that matter.
How does smolanalytics do event instrumentation?
Two zero-friction paths on top of autocapture. You can name a defined event from clicks you already captured, retroactive to install, no code. Or you connect your coding agent (Cursor, Claude Code) over MCP: propose_instrumentation reads the repo and writes the track() calls, and verify_instrumentation proves each one actually fires (it is cloud-aware via a local proxy). So the agent instruments your app for you, and you get proof it works instead of hoping.
no credit card · or self-host free forever (MIT)