In Heap, why can a newly defined event return historical data?
answer
- collect first, name later
- the definition is a rule, not a call
- raw interactions are the real data
- reaches back only to install date
- consent gaps and retention bound it
basics
~20 sBecause Heap already captured and retained the raw interactions. An event definition is a matching rule applied over that stored data, not a new collection instruction, so saving it classifies past interactions as well as future ones.
solid answer
~50 sHeap's snippet records interactions continuously, independent of whether anyone has named them. An event definition — a rule matching a selector path, element text, and page or URL filters — is **metadata over already-collected data**, not a new tracking call. Saving the definition classifies every retained interaction that matches, so a report can start at the button's launch date rather than at the moment someone thought to instrument it. That kills the classic "instrument, deploy, wait three weeks for data" cycle. The limits matter, though: retroactivity reaches back only over interactions Heap actually captured and still retains. Nothing exists from before the snippet was installed, from pages or apps where it is not deployed, from sessions where consent blocked it, or beyond your retention window. And events autocapture cannot see at all — server-side ones — are not recoverable by any definition.
go deeper
Remember the order of operations: Heap captures interactions first and you name them later, so a report can cover time before anyone created the event.
Explain that a definition is a matching rule over retained raw interactions — selector, text, page filters — applied to history, and state the install-date and retention floors that bound it.
Show you have felt the consequence: definitions are mutable metadata, so dashboards and warehouse numbers can be restated, and duplicate definitions produce two conflicting versions of the same metric.
Own the governance model — who may edit reporting-critical definitions, how they are named and documented, and whether the semantic layer belongs in a vendor UI or is rebuilt from raw data in your warehouse.
## The problem retroactivity solves With hand-instrumented analytics, every new question costs a release cycle. A PM asks "how many people who opened the plan comparison page upgraded within a week?", the answer is "we do not track that view", an engineer adds a call, it ships next sprint, and the first usable data arrives a month after the question was asked. Worse, the answer for *last quarter* is permanently unavailable — you cannot instrument the past. Heap's autocapture removes the collection step from that loop. Because the browser snippet has been recording interactions all along, the only thing missing when a new question arrives is a *name* for the interactions that answer it. ## How a definition works A Heap event definition is a matching rule over captured interaction attributes. Typically it specifies: - **An interaction type** — click, change, submit, pageview. - **An element selector** — the DOM path, id, classes, or a combination that isolates the element. - **Optional text or attribute filters** — the visible label, an `href`. - **Optional page filters** — the URL path or query parameters where it counts. Saving that rule does not deploy anything to the site and does not ask the browser for anything new. It is applied against the retained corpus of autocaptured interactions, so the resulting event has volume for every historical interaction that matches. This is why a definition created today can plot a funnel beginning six months ago. The corollary is important for how you think about the data: **the raw interaction stream is the data; the event is a view of it.** Definitions can be edited, renamed, narrowed or deleted without losing anything underneath, and two teams can define two different events over the same clicks. ## What retroactivity does not rescue Candidates routinely overstate this, so be precise about the four boundaries: 1. **Before the snippet existed.** Retroactivity reaches back to when Heap started capturing on that surface, not to the site's launch. Install date is a hard floor. 2. **Where the snippet is not deployed.** A page, subdomain, mobile app or embedded checkout without the SDK contributes nothing, no matter how the definition is written. 3. **Sessions where capture did not run.** Consent gating, ad blockers, script failures and bot filtering all remove interactions from the corpus permanently. 4. **What autocapture cannot see at all.** Server-side events and values that never render in the DOM are outside the mechanism, so no definition can conjure them. Retention is the fifth boundary: retroactivity is bounded by how long raw interaction data is kept under your plan and configuration, and that window is a commercial matter to confirm rather than assume. ## Why you still write explicit events Even with retroactivity, teams keep a small set of deliberate `heap.track` calls. The reasons are practical: server-authoritative values (revenue, refunds, entitlement changes) are not in the browser; some interactions are semantically ambiguous from markup alone (one submit button that means three different things depending on state); and a handful of events matter enough that they deserve to exist in reviewed code rather than in a UI rule someone can edit. A common shape is autocapture as the safety net for exploratory questions, plus a short instrumented list for the metrics that feed board decks and billing reconciliation. ## The consequence engineers care about Because the event layer is metadata, event definitions are *mutable inputs to your numbers*. Narrowing a definition to exclude a disabled-state click can change last quarter's conversion rate the next time the report runs. That is a feature when it is a correction and a hazard when it is unannounced. Treat definitions as a governed asset: name them consistently, document what each matches, restrict who can edit the ones that feed reporting, and if a number must be immutable, snapshot it rather than re-reading a mutable definition. ## What an interviewer is checking They want the mechanism stated crisply — capture first, classify later, definition is a rule over retained raw data — followed immediately by the honest limits. A candidate who says "Heap can tell you about anything, retroactively" has missed the install-date floor, the consent gap and the server-side blind spot. A candidate who adds "and because definitions are editable, my warehouse numbers are not frozen" is thinking like the engineer who has to reconcile the dashboards.
- If Heap defines events retroactively, why do teams still ship explicit heap.track calls?Three reasons. Server-authoritative values such as revenue and refunds never appear in the DOM. Some interactions are ambiguous from markup alone — one submit button meaning different things by state. And the handful of metrics that drive board decks or billing deserve to live in reviewed, versioned code rather than a UI rule anyone with access can edit.
- Does a retroactive Heap definition give you data from before the snippet was installed?No. Retroactivity only reaches over interactions Heap actually captured and still retains. Before the snippet ran — or on surfaces where it is not deployed, or in sessions blocked by consent or a script failure — nothing was recorded, and no definition can recover it. Retention limits cap the window further.
- Two teams define slightly different events over the same button. Is that a problem?Mechanically it is fine — definitions are views over the same raw interactions, so both can exist. Organisationally it is the classic autocapture failure: two "Checkout Started" numbers that disagree in a meeting. Fix it with naming conventions, a documented owner per reporting event, and edit permissions on the definitions that feed dashboards.
Autocapture is filming the whole shop floor; defining an event is going back through the tape and marking which moments count as a sale. You can re-mark them next week, but you can only mark what the camera saw.
saying these in an interview costs you the question
- Claims Heap recovers data from before the snippet was installed
- Thinks a definition change requires a code deploy
- Says retroactivity means no instrumentation is ever needed
- Ignores that editing a definition can restate historical numbers
- Forgets consent gating and retention limit the lookback window