What does Heap's autocapture collect from a page without any per-event code?
answer
- listens instead of being told
- every click, not chosen clicks
- DOM path and text travel with it
- browser only — no server events
- typed input values are not stored
basics
~20 sHeap's browser snippet automatically records user interactions — clicks, input changes, form submissions and pageviews — with each element's DOM path, visible text, link target and page URL, plus session and user context. No per-event tracking call is written.
solid answer
~40 sHeap installs a single snippet that listens at the document level and captures interactions as they happen, rather than waiting for an engineer to instrument a named event. For each interaction it stores the type (click, change, submit, pageview) and enough context to identify the element later: its DOM hierarchy and selector path, tag, id and classes, visible text, `href`, plus page path, query string, referrer, and Heap's own anonymous user and session ids. What it does **not** capture is anything outside the browser DOM: server-side events like a refund webhook, values the page never renders, and cross-origin iframe content. You still write code for identity and context — `heap.identify`, `heap.addUserProperties`, `heap.addEventProperties` — and `heap.track` for custom events that autocapture cannot see. Text typed into inputs is not stored as a value by default.
code
javascript · 10 lines// Autocapture already records the click itself; these add context around it
heap.identify('user_8f2c');
heap.addUserProperties({ plan: 'pro', account_id: 'acct_412' });
heap.addEventProperties({ app_version: '2026.8.1' });
// Values the DOM never renders still need an explicit event
heap.track('Subscription Upgraded', { from_plan: 'pro', to_plan: 'enterprise' });
// On logout, so the next visitor is not merged into this user
heap.resetIdentity();go deeper
Be ready to say plainly what the snippet does: it listens for clicks, changes, submissions and pageviews and stores the element's DOM context, without a tracking call per event.
Explain the mechanism and its boundary — document-level listeners over the DOM — and name what still needs code: identity, user and event properties, and custom events for anything the page never renders.
An interviewer expects you to weigh the operational cost: heavier client payloads, a noisy raw corpus, and a privacy surface where rendered text and query strings become analytics rows unless you redact them.
Own the policy question — what may appear in the DOM and in URLs on sensitive screens, what redaction and consent gating apply, and how the autocaptured corpus is retained and governed.
## What autocapture means Most product-analytics tools are instrumented event-first. Someone decides that "Checkout Started" matters, an engineer writes a tracking call, the change ships, and only from that deploy forward does data exist. Heap inverts the order. Its browser snippet attaches listeners at the document level and records the interactions users actually perform, whether or not anyone has decided those interactions are interesting. The decision about which interactions constitute a business event is made afterwards, in Heap's UI, against data that has already been collected. That inversion is the whole product. It is why Heap is described as an autocapture platform and why its trade-offs are the opposite of a hand-instrumented tool: nothing is missing because someone forgot to add a call, but a great deal of what is captured is noise nobody will ever name. ## What the snippet records For each captured interaction, Heap stores the interaction plus enough context to identify the element later: - **The interaction type** — a click, an input change, a form submission, a pageview, and on single-page apps the virtual navigations it detects. - **Element identity** — where the element sits in the DOM: its hierarchy/selector path, tag name, `id`, class list, and the visible text on or near it. For links, the `href`. - **Page context** — URL path and query string, page title, referrer. - **Session and device context** — timestamp, browser and operating system, viewport, and Heap's anonymous user id and session id. That element context is the raw material for a later event definition: when you tell Heap "a click on this button is Checkout Started", you are writing a matching rule over exactly these captured attributes. ## What autocapture does not see Autocapture is a browser mechanism reading the DOM, so its blind spots follow directly: - **Server-side events.** A refund processed by a payment webhook, a subscription renewal from a nightly job, a dunning email — none of these involve a browser, so no listener fires. They need a server-side call or a warehouse join. - **Values that never reach the page.** Gross margin, an internal risk score, a fulfilment centre id. If it is not in the DOM, it was not captured. - **Typed input values.** Heap records that a field was interacted with, not the characters a user typed into a free-text field. This is deliberate — capturing input values would make every form a PII pipeline. - **Non-DOM surfaces.** Cross-origin iframes are separate documents; canvas- or WebGL-rendered interfaces have no elements to describe; some shadow-DOM cases depend on SDK version. Native mobile SDKs run their own autocapture over the view hierarchy, with different coverage from the web. ## The code you still write Autocapture removes per-event instrumentation, not all instrumentation: - `heap.identify(identity)` ties the current anonymous visitor to a known user id. - `heap.addUserProperties({...})` attaches attributes to that user (plan, account, role). - `heap.addEventProperties({...})` attaches attributes to all subsequent events until `heap.clearEventProperties()`; useful for app version, experiment arm, tenant. - `heap.track(name, properties)` fires a custom event for things autocapture cannot observe. - `heap.resetIdentity()` on logout, so the next visitor on a shared device is not merged into the previous user. A sensible deployment therefore looks like: autocapture as the default safety net, plus a deliberate handful of explicit calls for identity, tenancy and the few business events whose values live on the server. ## The costs you should be able to name Autocapture ships more data per session than a targeted tracking plan: every click on the page becomes a row, each carrying a DOM path. That means a heavier client payload, more raw storage, and a downstream corpus where the ratio of meaningful events to noise is low. It also widens the privacy surface, because DOM text and URLs get recorded verbatim — if an account number is rendered as a link label or a search term ends up in a query string, it lands in your analytics store. Teams that take this seriously redact sensitive elements, keep PII out of URLs and visible labels, and review what autocapture is picking up on sensitive screens. ## What an interviewer is checking At this level they want to hear the mechanism (a DOM listener, not a database reader), the boundary (browser only), the fact that you still write identity and custom-event code, and the honest downside — noise, payload weight, and the privacy exposure that comes with recording everything visible.
- What kinds of events will Heap's autocapture never see, however well the site is built?Anything outside the browser DOM. Backend-only events — refunds, renewals, cron-driven emails — never touch a page. So do values the page never renders, such as a server-computed margin. Cross-origin iframes are separate documents, and canvas or WebGL interfaces expose no elements to describe. Those need `heap.track`, a server-side path, or a warehouse join.
- How would you attach an order value to an autocaptured checkout click?Autocapture only keeps what the DOM exposes, so either put the value in captured context or send it yourself. `heap.addEventProperties` attaches context such as tenant or app version to subsequent events; `heap.track` sends an explicit event with its own properties. For money you must trust, prefer joining the Heap event to the order record in the warehouse rather than reading a rendered figure.
- Why does Heap not record what users type into text inputs?Because it would turn every form into a PII pipeline — passwords, card numbers, health details and free-text notes would all land in analytics storage. Heap records that a field was interacted with, not its contents. Even so, DOM text and URLs are captured verbatim, so sensitive labels and query strings still need redaction and review.
It is closer to a security camera in a shop than a clerk tallying specific purchases: everything in view is on tape, and you decide afterwards which moments count as a sale.
saying these in an interview costs you the question
- Claims Heap records keystrokes and text-input values by default
- Says autocapture means no analytics code is ever needed
- Thinks autocapture also captures server-side or database events
- Believes Heap only stores events someone defined in the UI
- Ignores the privacy exposure of capturing DOM text and URLs