blog · Jul 9, 2026

the analytics that autocaptures rage clicks, dead clicks, and js errors

Arjun Varma · maker of smolanalytics

autocapture is when analytics records what people do on your site without you writing tracking code for each thing. you drop in one snippet and it captures pageviews, clicks, engagement time, and scroll depth automatically. smolanalytics goes further and captures the frustration signals too: rage clicks (rapid repeated clicks in the same spot), dead clicks (clicks that do nothing), javascript exceptions, and failed form submits. those are the events that actually tell you what to fix, and you get them from the same one line, no code, cookieless.

what does autocapture actually record?

one snippet, and every click carries a full element selector chain so you can name the thing later. that is the base layer: pageviews, clicks, engagement, and scroll depth, captured the second the script loads. each click event stores the $elements chain (the button, its parent, its parent's parent, with ids and classes and text), which is what lets you define a business event from a click you already recorded, retroactive to install, without shipping any code.

but the base layer is table stakes. plausible does pageviews, umami does pageviews and basic clicks. the reason autocapture is worth having is the second layer, the signals that mean something went wrong.

how does it detect rage clicks?

a rage click is several clicks landing in nearly the same spot in a short window, and it means a user is angry at something that isn't responding. smolanalytics watches for a burst of clicks tightly clustered in space and time on the same element and fires a $rageclick event with the same $elements chain as a normal click. so you don't just know "someone rage clicked", you know they rage clicked the checkout button on the pricing page. that is a lead, not a vibe.

rage clicks are the single highest signal-to-noise event in frontend analytics. nobody clicks a thing five times in a second because they're happy. they do it because the button looked clickable and didn't respond, or the spinner never resolved, or the modal ate the tap. you sort your $rageclick events by element, and the top of that list is a to-do list ranked by how much it's pissing people off.

what is a dead click and why does it matter?

a dead click is a click that produces no reaction: no navigation, no dom change, no network call. it's the quieter cousin of the rage click. someone clicked something that looks interactive (an underlined word, an icon, a card) and nothing happened, so they gave up. smolanalytics flags these as $deadclick, again with the full selector chain, so you can see exactly which non-buttons your users keep trying to press.

dead clicks tell you where your design is lying. if 200 people a week click a label that isn't a link, that label should probably be a link, or should stop looking like one. you don't find that in a funnel. you find it because the click got recorded and marked dead, and no funnel report was going to surface a click on an element you never thought to instrument.

does it catch javascript errors?

yes, uncaught javascript exceptions get captured automatically as events, with the message and the page they happened on. this is the one that usually lives in a separate tool (sentry, bugsnag) with a separate bill. smolanalytics records a $exception when your frontend throws, so a broken deploy shows up in the same place as the drop in signups it caused. you can see the error rate climb and the conversion dip on the same timeline, from the same snippet.

it also captures form submits, so a form that people fill out but never successfully submit is visible as the gap between engagement on the form and the submit event firing. errors plus dead form submits is most of what "the signup is broken and i don't know why" actually is.

how honest is the engagement number?

engagement time only counts when the tab is focused and visible, so it's real attention, not a clock left running. a lot of tools count time-on-page as "last event minus first event", which happily bills you 40 minutes for a tab someone left open over lunch. smolanalytics pauses the timer when the tab is backgrounded or the window loses focus, using the page visibility API, so the number is time the user was actually looking. it's also cookieless: no consent banner, no cross-site id, identity is derived per-day without a persistent cookie.

how is this different from posthog or heap autocapture?

posthog and heap both autocapture clicks and pageviews with a selector chain, and heap invented the retroactive defined-event move that smolanalytics also does. the difference is threefold. one, the frustration and error layer (rage clicks, dead clicks, js exceptions) is on by default here from the same snippet, not a separate product. two, it's one Go binary you self-host for free under MIT, not a Kafka plus ClickHouse cluster or a metered cloud. three, you ask the data in plain english from a dashboard bar or your editor over MCP with your own model, so the AI is free and every answer ships a computed_by receipt showing the exact report behind it. no session replay, no heatmaps, no surveys, deliberately. the frustration signals do the job those were bought for.

try it

self-host is free forever, MIT, one binary, own your data. the cloud is $9/month on Solo up to $499 on Business with $5 per extra million events, and importers from posthog, mixpanel, umami, or csv if you're switching. drop the snippet in, ship nothing else, and watch the rage clicks tell you what to fix. the live demo is at smolanalytics.com.

smolanalytics is the analytics that tells you what to fix. try the cloud or self-host free.