Webclat / PostHog Practice

Autocapture vs explicit events: the decision that defines your PostHog taxonomy

Autocapture makes PostHog feel instant to install - clicks, pageviews, and form submissions start flowing with a single script tag. Whether that data is trustworthy six months later depends on a decision most teams never make deliberately: what autocapture should handle, and what needs an explicit event.

Two different jobs, one tool

Autocapture and explicit events are not competing approaches - they answer different questions. Autocapture is exploratory: it captures DOM interactions broadly so you can retroactively ask "did people click this?" without having instrumented it in advance. Explicit events are deliberate: a developer fires posthog.capture('subscription_upgraded', {...}) with the properties a specific analysis or report actually needs.

The architecture decision, as a framework

SignalUse autocaptureUse an explicit event
Business meaningInteraction is exploratory, meaning not yet definedInteraction maps to a specific business outcome (upgrade, churn signal, activation)
Properties neededDOM context is enough (element, page, text)Needs custom properties (plan tier, amount, feature flag variant)
Reliability requirementDirectional exploration is fineFeeds a dashboard, report, or alert someone relies on
Stability over timeUI element may change without noticeEvent name and schema stay stable even if the UI changes

Why the mixed approach beats either extreme

All-autocapture setups produce a lot of events that are hard to query meaningfully six months later, because they describe DOM structure, not product meaning - and DOM structure changes with every redesign, silently breaking historical comparisons. All-explicit setups require instrumenting every interaction in advance, which slows shipping and misses the things nobody thought to track. The right taxonomy uses autocapture for breadth and exploration, and explicit events for anything a metric, dashboard, or migration depends on.

Where this decision has to happen

This is exactly the design work we do before instrumentation ships on a new implementation, and it is also the first thing we audit on an existing PostHog instance with a taxonomy nobody trusts. It connects directly to cost control (autocapture volume drives event usage) and to migration engineering (a source platform's explicit-event schema needs a deliberate mapping, not a blanket recreation in PostHog).

Frequently Asked Questions

What does PostHog autocapture actually track?

Autocapture instruments clicks, pageviews, form submissions, and other DOM interactions automatically once installed, without a developer writing individual tracking calls for each one.

Why not just use autocapture for everything?

Autocapture describes what happened in the DOM, not what it meant in the product. A click on a button tells you a click happened; it does not tell you a subscription was upgraded, a project was archived, or a payment failed - those need explicit events with the business meaning attached.

Does autocapture affect PostHog's pricing?

Yes - every autocaptured interaction is an event, and event volume is a primary driver of usage-based cost. Autocapturing broadly without a taxonomy plan is a common way pricing surprises happen; see our pricing guide.

What's a practical rule for choosing between them?

If the interaction has business meaning that matters to a metric or a report (conversion, activation, churn signal), fire an explicit event with the properties that meaning needs. If it is exploratory or you are not sure yet, let autocapture cover it until you know.

Get a taxonomy that survives the next redesign.

We draw the line between autocapture and explicit events before instrumentation ships - or fix it on an instance that already drifted.

Design My Event Taxonomy