Heap

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Do not rebuild this. Retroactive events on data already captured is the idea, and it is a storage and query problem rather than a feature.

Capturing every click, form change and page view, then letting somebody define an event afterwards and still have the history, means keeping everything at full fidelity and querying it fast. At real volume that is a columnar store and careful design.

WHEN TO KEEP PAYING
- You genuinely define new events after the fact and need the history
- Enough volume that the query performance is doing real work

WHEN TO BUILD
- Named events, defined in your code, cover the questions you actually ask. That shape is under Mixpanel and Usermaven elsewhere in this catalogue

THE THING TO COPY, WHICHEVER YOU CHOOSE
- **Record more than you publish**, always. A signal not captured today starts from zero the day somebody wants it, and a missing year cannot be bought back
- Everything is one events table with a name and properties. A new signal is a new name, never a migration
- Keep both the anonymous and the identified identifier on every row, so stitching applies retroactively rather than requiring a rewrite

IF YOU DO AUTOCAPTURE
- The stable selector is the hard part: prefer an explicit attribute, then an id, then a structural path that ignores generated class names. A selector that changes on every build makes the history worthless, which is the failure that quietly undermines the whole idea
- **Never capture the contents of an input.** Record that a field was interacted with, never what was typed. Autocapture that reads form values is how a password reaches an analytics database
- Autocapture is a starting point. Named events with properties are better for anything that matters, so make defining one a single line

AND THE HONEST LIMIT
Retroactive definition sounds like it removes the need to think in advance. It does not: if you never captured the property you now want to break down by, the history is still missing it. Decide your important properties early regardless.

THE ONE-LINE VERSION
Buy it for retroactive history at scale. Whatever you choose, capture generously, keep both identifiers, and never store what somebody typed.