smolanalytics
menu
instrumenthow it worksdocsmcpfeaturespricingbacktestintegrationsmigrateproduct analyticsbest oftoolscontact
log inStart trial
glossary · analytics term

What is autocapture?

Analytics that records interactions automatically from one snippet, so the data is already there when you think of the question, no per-event tracking code.

Autocapture is an analytics approach where a single snippet records user interactions automatically, pageviews, clicks, scroll depth, form submits, and errors, without you writing a track() call for each one. It captures the raw event plus the element that was interacted with, so you get behavioral data the moment the snippet loads, with no per-event instrumentation. The mechanism is a listener on the page: every click, pageview, scroll, and form submit fires an event, and the snippet records not just that a click happened but which element it hit, walking up the DOM to build a selector chain (the tag, its classes, its text, its parents). That selector chain is what makes autocapture useful after the fact, because you can point at any button you already have and ask how many people clicked it, going back to the day you installed, without shipping code. The tradeoff is that autocapture gives you generic interaction events, a click on an element, not the business meaning ("upgraded to Pro"). So autocapture is best paired with a way to name business events on top of the raw clicks, either retroactively from the elements you already captured or with a handful of explicit custom events for the moments that matter. Autocapture is the opposite of manual instrumentation, where nothing is recorded until you write and ship a track() call for each event.
what it records

What autocapture actually captures

The whole point is breadth without code. From one snippet, autocapture records the interactions below, and for clicks it keeps the element (the $elements selector chain) so you can turn any of them into a named event later.

pageviews
Every page or route load, with the URL, referrer, and UTM parameters. This is the web-analytics baseline, sessions and traffic sources, without a single line of tracking code.
clicks
Every click, tagged with the element it hit and a full selector chain (tag, classes, text, parents). Because the element is recorded, any button becomes a queryable event later, retroactive to install.
scroll + engagement
How far down a page people scroll and how long they actually engage, not just that a tab was open. Scroll depth tells you whether people reach the section you care about.
rage + dead clicks
Rapid repeated clicks on the same spot (rage clicks) and clicks on things that do nothing (dead clicks). Both are frustration signals that point at broken or confusing UI without a survey.
JS exceptions
Uncaught JavaScript errors as they happen in real browsers, with the message. You find out a button throws for a subset of users from your analytics, not from a support ticket a week later.
form submits
Form submissions as events, so you can see submit rate and where a form is abandoned, again without wiring an onSubmit handler into your analytics by hand.
the real difference

Autocapture vs manual instrumentation

With manual event tracking, you get data for an event only after you write a track() call for it and deploy. So on the day you wonder "how many people click the export button?" you find you never instrumented it, add the code, ship it, and wait a week for data. Every new question starts from zero.

Autocapture flips that. Because it recorded the click and the element from the day you installed, the answer is already in your data, retroactive to install, no deploy. The cost is that the captured events are generic: a click on button.btn-primary is not the same as "upgraded to Pro" until you name it. That is why autocapture pairs with event instrumentation: autocapture gives you the raw breadth, named events give the raw clicks their business meaning.

how smolanalytics does it

Zero code in, named events out

smolanalytics autocaptures pageviews, clicks (with the full $elements selector chain), scroll depth, engagement, rage clicks, dead clicks, JS exceptions, and form submits from one snippet. You write no tracking code to get started.

Then, when you need business meaning, you have two zero-friction paths. You can name a defined event from clicks you already captured, retroactive to install, no code and no agent (the Heap move). Or you connect your coding agent (Cursor, Claude Code) over MCP and it reads the repo, writes the custom track() calls, and proves each one fires. So autocapture is the floor, not the ceiling.

The captured events are also what the investigator reads: it checks every event on a schedule and queues findings on the desk, what changed, the segment carrying it, what it costs, so autocapture feeds conclusions, not just charts.

It now ships heatmaps and an event-based session inspector too; the one thing it deliberately skips is pixel-perfect DOM session recording. See every feature or how it compares vs PostHog.

Common questions

What is autocapture in simple terms?
It is analytics that starts recording the moment you add the snippet, instead of only tracking events you wrote code for. It listens to the page and logs pageviews, clicks, scrolls, form submits, and errors automatically, and it remembers which element each click hit, so you can ask about any button later without shipping code.
How is autocapture different from manual event tracking?
With manual tracking, nothing is recorded until you write a track() call for that specific event and deploy it, so you only ever have data for events you thought to add, from the day you added them. Autocapture records the raw interactions from install with zero code, so the data is already there when you think of a new question. The tradeoff is that autocapture events are generic (a click on an element) and you usually name the business meaning on top of them.
Does autocapture capture sensitive data from forms?
A well-built autocapture library records that a form was submitted and which element was clicked, not the values typed into inputs. smolanalytics captures the interaction and the element selector, not the contents of text fields, so a password or email typed into a field is not sent as event data. You capture behavior, not keystrokes.
What are the downsides of autocapture?
Autocapture gives you raw interaction events, a click on a button with a certain selector, not the business meaning of that click. So on its own it does not know what "activated" or "upgraded" means for your product. The fix is to name business events on top of the captured clicks, either retroactively from the elements you already have, or with a few explicit custom events for the moments that matter. Autocapture handles the breadth; named events handle the meaning.
How does smolanalytics do autocapture?
One snippet, and it records pageviews, clicks (with the full $elements selector chain), scroll depth, engagement time, rage clicks, dead clicks, JS exceptions, and form submits, no tracking code. On top of that you can name a business event from clicks you already captured (retroactive to install, no code), or connect your coding agent over MCP to write and verify custom track() calls for you. So you get the breadth of autocapture and the precise business events, without hand-instrumenting.
Start the 14-day trial
no credit card · 14-day trial at Pro limits · from $19/mo after

keep reading

event instrumentation
naming business events on top of captured clicks
what is a rage click?
the frustration signal autocapture records
every feature
autocapture, defined events, MCP