Autocapture

How autocapture works

Autocapture (also written auto-capture, or called automatic event tracking) inverts the usual setup. Instead of writing a line of tracking code for every button and form, you add one analytics SDK. It listens to interactions in the browser or app and records them automatically, capturing context like the element clicked, its text, and its CSS selector. Events are usually batched and sent in the background, then often enriched server-side with details like geography, device, and UTM parameters.

Autocapture vs manual event tracking

Manual (or “explicit”) tracking means calling a function like track('order_completed') for each event you care about. It’s precise and well-named, but slow to set up and easy to forget. Autocapture solves the cold-start problem: you get behavioral data the moment the SDK is installed, including interactions no tracking plan would have predicted. The trade-off is that raw captured events are noisier than curated business events.

On data quality, each one fails in its own way. Autocaptured events are keyed to the page: an element’s text, its selector, and the URL. Rename a button or restructure a page and a metric built on the old selector quietly splits in two. Manual events stay stable for as long as the code does, but they only cover what someone remembered to instrument, and their names drift (signup, sign_up, SignUp) unless a naming convention is enforced.

The best practice is to use both: autocapture for breadth and the long tail of interactions, plus a handful of named custom events for your key conversions.

Frustration signals

Richer autocapture also records rage clicks (rapid repeated clicks on the same spot) and dead clicks (clicks that produce no response): early signals that a UI is confusing or broken, which you’d never think to instrument by hand.

Example: what autocapture records

Drop the SDK on an e-commerce site and a single visit can produce a stream like this, with no tracking code written:

• page_view: /products/blue-runner
• click: button, text “Add to cart”, selector #pdp .add-to-cart
• rage_click: three rapid clicks on a greyed-out “Apply coupon” button
• form_submit: the checkout form (which fields were filled, never their values)

You never planned the rage_click, but it’s the exact signal that the coupon field is broken. That’s the payoff: the interaction you’d never have thought to instrument is already captured.

Which analytics tools have autocapture

Autocapture started as Heap’s signature and is now common in product analytics, though tools differ in what they record and whether it is on by default:

• Heap was built around it: interactions are recorded from install, and you define events retroactively from what was already captured.
• PostHog autocaptures page views, clicks, and form submissions in its web SDK by default.
• Amplitude’s Browser SDK can autocapture sessions, page views, form interactions, file downloads, element clicks, and frustration signals such as rage and dead clicks.
• Mixpanel’s JavaScript SDK records page views, scrolls, clicks, form interactions, and rage and dead clicks once you add autocapture: true to the snippet. It stays off until you do.
• Google Analytics 4 has a partial version, enhanced measurement: page views, scrolls, outbound clicks, site search, file downloads, and video and form interactions, but not every click.
• Plausible and Umami are page-view-first. Beyond optional extras like Plausible’s outbound-link and file-download tracking, interactions are events you tag yourself.

For how these tools compare beyond autocapture, see the best product analytics tools roundup.

How Pug does autocapture

After a single init(), Pug’s Web SDK autocaptures page views, clicks, scrolls, and form submissions, plus rage and dead clicks, then enriches every event with geo, device, and browser, and UTM parameters on ingest. Those events flow straight into trends, funnels, retention, and user flows, and you can still add named custom events with track(). See the SDKs for setup.