Autocapture
Date: 2026-08-16
Record every click and pageview automatically, define events afterwards. It buys retroactive analysis — you can answer questions about last month that nobody thought to instrument — and it moves the naming problem to definition, where it rots the same way.
What it is
Autocapture is automatically recording interactions — clicks, pageviews, form submissions, sometimes input changes — without per-event instrumentation, then defining meaningful events retrospectively by matching against selectors or element text.
DELIBERATE INSTRUMENTATION AUTOCAPTURE
decide what matters record everything
↓ ↓
write the tracking call define later, from what was recorded
↓ ↓
deploy "clicks on button where
↓ text = 'Add to basket'
data starts from now and path contains /products"
↓
data exists retroactively
The genuine advantage
Retroactive analysis. Someone asks in October whether people used the size guide in August. With deliberate instrumentation the answer is “we didn’t track that, ask again in three months”. With autocapture the data is already there.
That’s a real capability, and it’s the argument that carries. Most analytics questions are unanticipated, and the cost of every unanticipated question being a three-month wait is high.
Secondary benefits: no engineering time per event, nothing to forget, and coverage of pages nobody thought to instrument.
The costs
- Definitions are brittle. An event defined as “clicks where CSS class is
.btn-primary” breaks silently when a designer renames the class. Deliberate instrumentation breaks loudly, in code review; autocapture breaks quietly, in a dashboard - Volume. Orders of magnitude more events, which is storage cost and Cardinality pressure
- No properties. Autocapture knows that a button was clicked; it doesn’t know the product ID, the price or the variant. Anything business-meaningful still needs deliberate instrumentation
- Personal data by accident. Capturing input values or element text can sweep up names, emails and addresses. Most tools mask inputs by default — verify rather than assume — PII in Analytics
- Payload size. The capturing script is heavier than a minimal SDK — JavaScript Execution Cost
- The naming problem moves rather than disappears. You now have a growing set of retrospective definitions with no owner, no review and no plan. That’s Event Taxonomy Design decay in a different location
The combination that works
Not a choice. Use each for what it’s good at:
| Use | For |
|---|---|
| Autocapture | Exploration, unanticipated questions, low-stakes UI interaction, pages nobody instrumented |
| Deliberate events | Anything feeding a reported metric, anything needing properties, the whole Ecommerce Event Schema funnel |
The rule: nothing anyone reports on should depend on an autocaptured definition. Revenue, conversion and the funnel are instrumented deliberately, in code, in the tracking plan. Everything else can be autocaptured and treated as directional.
If you do use it
- Add stable hooks.
data-analytics-id="add-to-basket"on the elements you’ll want to define events from. Immune to class renames, and it’s a contract the front end can see - Version your definitions, with an owner, exactly as you would events
- Confirm input masking is on before you assume it
- Watch the volume, and sample if the cost becomes real
- Audit definitions alongside events — a definition matching nothing is the same failure as an event that stopped firing — Guide - Auditing a Tracking Plan
The honest summary: autocapture is a safety net, not a strategy. It rescues the questions you didn’t anticipate; it doesn’t relieve you of designing the events you did.