Heap
Autocapture-by-default product analytics: every click, pageview, and form interaction is recorded to Heap's cloud (US by default) and stitched to persistent user identities.
verified 2026-07-11 · grade set per the published methodology
How the grade breaks down
How little it collects, and whether collection is purpose-bound.
Whether it respects GPC, consent state, and tracking-prevention signals.
Cookieless vs. persistent IDs, cross-site linkage, fingerprinting risk.
Where data lives and whether it is shared with third parties.
How verifiable and documented its real behavior is.
At a glance
Heap’s core design is autocapture: by default the SDK records every click, pageview, and form interaction and transmits it to Heap’s cloud, where retroactive analysis and identity stitching link events to persistent user profiles. That inverts data minimization — the operator collects everything first and decides what matters later. Heap documents that form-field values are not captured, but clicked-element text and attributes are, which can carry personal data on many pages. Hosting defaults to Heap’s US cloud; its developer documentation references an EU ingestion endpoint, so an EU deployment option appears to exist — confirm current availability with the vendor, as the default remains US. It provides opt-out APIs, deletion tooling, and a DPA, but collection is not gated on consent out of the box and GPC is not honored by default. A privacy-conscious deployment requires suppressing autocapture on sensitive surfaces and holding the SDK back until consent is granted.
Sources & basis for grade
Grades reflect documented behavior, vendor documentation, and ad.rip scans as of the date above. Each assessment is reproducible and vendors may request correction.
- Heap autocapture documentation
- Heap privacy / data-governance documentation
- Heap DPA and sub-processor list