What Autocapture Records Without Any Manual Instrumentation

What is autocapture in product analytics?

Product analytics tools use autocapture to record clicks, page views, form submissions and rage clicks automatically, without an engineer writing a tracking call for each one. The script loads once, watches the page for interactions, and stores what it sees, so a team gets a working product analytics event stream on day one instead of waiting for someone to instrument every button first.

How does autocapture work without instrumentation?

Autocapture works by attaching listeners to the page at the framework level instead of to individual elements a developer has to name in advance. A single script watches for clicks, form submissions, page loads and navigation across the whole site, tags each one with the element it happened on, and sends that record to the analytics backend without a line of tracking code inside the application itself. The tradeoff for that speed is that the tool decides what an event means after the fact, from the page structure, rather than a developer deciding it before the code ships.

What are CSS-selector-based event definitions?

CSS-selector-based event definitions let a team define "signup button clicked" after launch by pointing at the button's CSS selector inside the analytics tool, instead of adding a tracking call to the button's code. The analytics platform matches every future click against that selector and counts it as the named event, which means the definition lives in the analytics tool's configuration, not in the application's source code.

Why is autocapture brittle when the DOM changes?

Autocapture is brittle because a CSS-selector-based event definition points at a specific element in the page's structure, and a redesign, a class name change or a new component library breaks that pointer without breaking the page itself. The button still works for the user, the click still fires, but the selector the analytics tool was matching against no longer exists, so the event silently stops recording with no error for anyone to notice. Audit autocapture-defined events after any front-end redesign, since the dashboard keeps showing a chart with no indication the underlying data went quiet.

What is the difference between autocapture and manual event tracking?

Autocapture records interactions automatically and lets a team name events after the fact from what the script captured, while manual event tracking requires a developer to add a tracking call to the code before the event exists in the data at all. Manual tracking costs engineering time up front but survives a redesign, since the tracking call moves with the code rather than pointing at a CSS selector that a designer can change without knowing analytics depends on it.

When should a team use manual tracking instead of autocapture?

A team should use manual tracking for events tied to revenue or a core funnel step, such as a completed purchase, a started trial or a signed contract, where a silent break costs real reporting accuracy. Reserve autocapture for exploratory analysis, early-stage products still discovering which interactions matter, and any page a team expects to redesign often, since re-pointing a broken manual tracking call after every redesign defeats the point of shipping fast.

How does Flowsery capture sessions without re-instrumentation?

Flowsery records every user session automatically with one script under 10 KB, and it can connect to sessions already recorded in PostHog or Amplitude with no re-instrumentation needed to start. That removes the setup step autocapture is built to solve for session recording specifically, while goal and funnel events stay defined explicitly for the metrics a team wants to track by name rather than infer from page structure. Pair automatic session capture with named goals instead of choosing one approach for the whole product.

Frequently Asked Questions

What does autocapture record by default?

Autocapture records clicks, page views, form submissions and navigation events by default, tagging each with the element and page it happened on. It does this without a developer adding a tracking call for any individual event first.

Does autocapture replace the need for manual event tracking?

No. Autocapture covers broad, exploratory interaction data quickly, but revenue-critical events like a completed purchase or a signed contract need a manual tracking call that survives a redesign instead of a CSS selector that a design change can break.

Why did my autocapture event stop recording?

An autocapture event usually stops recording because the CSS selector it was matching no longer exists on the page, most often after a redesign, a class name change or a new component library. The click still happens for the user; the analytics tool just stops recognizing it as the named event.

Is autocapture the same as session replay?

No. Autocapture defines and counts named events like clicks and form submissions, while session replay records the full sequence of a user's screen and interactions as a video-like playback. A product can use one, the other, or both, since they answer different questions.

How do I check if an autocaptured event is still working?

Check an autocaptured event by comparing the raw interaction count on the page, such as actual button clicks visible in a session, against the event count the analytics tool reports for that selector. A gap between the two after a recent front-end change usually means the selector broke.

When should I switch an autocaptured event to manual tracking?

Switch to manual tracking once an autocaptured event feeds a metric the business reports on regularly, such as signups or revenue, since a silent selector break on a reported metric costs more than the engineering time a manual tracking call takes to add.

Can Flowsery use session data already recorded in PostHog or Amplitude?

Flowsery connects to sessions already recorded in PostHog or Amplitude with no re-instrumentation needed to start. That removes the setup step autocapture exists to solve, since the session data is already there. Goal and funnel events still get defined explicitly on top of that, for the metrics a team wants to track by name.

How fast can a team start collecting data with autocapture?

A single script loads once and starts watching the page for clicks, page views, form submissions and rage clicks right away. There's no tracking call to write for each event first, so a team gets a working event stream from day one instead of waiting for someone to instrument every button.

Should a new product start with autocapture or manual tracking?

Ship autocapture first, since one script gets clicks, views and submits recorded from day one. Early-stage products still discovering which interactions matter are exactly the case autocapture is built for. Add a manual tracking call once an event turns out to matter, such as a signup or a purchase, rather than instrumenting everything up front.

Can a product use autocapture and named goal tracking at the same time?

Pairing automatic session capture with named goals works better than picking one approach for the whole product. Session recording can run without re-instrumentation while goal and funnel events for things like signups stay defined explicitly by name. That split keeps exploratory data flowing while the metrics a business reports on stay stable.