When would you choose Heap's autocapture over explicit instrumentation with a tracking plan?

## Frame the decision, not the product This question is not "is Heap good". It is: **where should the definition of a business event live — in your codebase, or in a rule applied to already-captured interactions?** Everything else follows from that. Hand-instrumented analytics puts semantics in code. Each event is written deliberately, reviewed, versioned, and typed if you invest in a schema. The price is foresight: you only get data for what someone predicted mattered, starting from the deploy that added it, and every new question costs a release cycle. Autocapture puts semantics in a UI over a stream of everything. The price is that the raw material is undifferentiated interaction data, and the meaning is imposed later by rules coupled to how the interface happens to be rendered. ## Where autocapture clearly wins - **Question latency exceeds release latency.** When the business asks new behavioural questions weekly and releases ship monthly, instrumentation is structurally too slow. Autocapture collapses the loop to minutes. - **Retroactive answers matter.** "What did users who churned last quarter do before leaving?" is unanswerable with instrumentation added today, and answerable with autocapture if the snippet was running. - **No analytics engineering capacity.** Small teams, or teams where PMs and analysts must self-serve without a ticket, get far more coverage per engineering hour. - **High UI churn with unstable priorities.** Early product work where nobody yet knows which flows will matter. - **Insurance against omission.** The classic failure — the one event nobody instrumented turns out to be the important one — simply cannot happen for anything visible in the browser. ## Where explicit instrumentation wins - **Server-authoritative facts.** Revenue, refunds, entitlement changes, fraud decisions. These do not exist in the DOM at all, so autocapture is irrelevant to them. - **Semantic precision.** One submit button that means three different things depending on state is ambiguous from markup; a code-level call knows which one it is. - **Governance and reproducibility.** Events defined in code get review, version history, tests and a clear owner. "What did this metric mean in March?" has an answer in git. - **Cross-surface consistency.** A single taxonomy spanning web, native mobile and backend is far easier to enforce when events are declared in one schema than when each surface's autocapture is defined separately. - **Payload and privacy discipline.** Sending only what you meant to send is the strongest privacy control there is. Autocapture records rendered text and URLs, so account numbers in labels or search terms in query strings become analytics rows unless you actively redact and review. ## The failure modes to name out loud At principal level the interviewer is listening for the operational consequences, not the feature list: 1. **Silent definition breakage.** A redeploy renames a class and a reporting event goes to zero, with nothing in the repository referencing it. This is autocapture's characteristic outage and it needs volume alerting to catch. 2. **Metric proliferation.** Three people define three slightly different "Checkout Started" events and a meeting produces three numbers. Without naming conventions, ownership and edit permissions, an autocapture deployment drifts into exactly the ambiguity it was meant to remove. 3. **Mutable history.** Because definitions are rules over retained data, editing one restates past periods — awkward when the number has already been reported externally. 4. **Portability.** The semantic layer sits in a vendor's product. Migrating means re-deriving every definition somewhere else, and the raw interaction data only travels usefully if you have been syncing it to your own warehouse. ## The answer that actually lands Most mature teams do not choose. They run autocapture as the exploratory safety net **and** maintain a short list — often a dozen or two — of deliberately instrumented, owned, code-reviewed events for the metrics that drive money and executive reporting. Those live in code, ship with tests, and are the number of record. Everything else is answered from autocapture, with the understanding that those answers are directional and may be restated. The secondary decision is where the semantic layer ultimately lives long-term: keep defining events in the vendor UI for speed, or sync the raw data to your warehouse and rebuild the important definitions in version-controlled SQL, trading self-serve speed for reproducibility and portability. Being able to argue both sides — and to say which you would pick for *this* company at *this* stage, and what would make you revisit it — is the whole point of the question.