Integreringsguide för cookie-samtycke för Heap Auto-Capture produktanalys: 2026 Playbook för utgivare
Heap är ovanlig i produktanalysekosystemet på grund av vad den gör som standard. Medan Mixpanel, Amplitude och PostHog ber utgivaren att instrumentera de händelser som spelar roll, fångar Heap allt automatiskt och låter analytikern definiera händelser retroaktivt från den insamlade strömmen. Den auto-capture-modellen är produktens definierande funktion och anledningen till att team väljer den; det är också anledningen till att en standard Heap-driftsättning bär en av de bredaste beteendedataytorna av vilket verktyg en utgivare sannolikt installerar. Varje klick, tryck, scroll, formulärinteraktion, sidövergång och rasericlick fångas mot en persistent identifierare inom millisekunder från sidinläsning — vilket innebär att var och en av dessa operationer engagerar en samtyckesskyldighet. Den goda nyheten är att Heap, sedan förvärvet av Contentsquare, levereras med ett av de mer granulära samtyckes-API:erna i produktanalysutrymmet; arbetet är att faktiskt koppla det korrekt över auto-capture-ytan, identitetslagret och session-replay-modulen som Contentsquare-integrationen lägger till.
Varför Heap kräver samtycke — och varför svaret är bredare än typisk analys
En standard Heap-initialisering gör flera saker vid sidans första rendering. Den sätter en förstapartscookie under _hp2_id.{envId} som innehåller den persistenta användaridentifieraren, en sessionscookie under _hp2_ses_id.{envId} med sessionsidentifieraren, en samplingscookie under _hp2_props.{envId}, och en _hp2_loaded-markör som indikerar att SDK:n har initierats. Den genererar den distinkta identifieraren om en inte redan finns, fångar den initiala sidvisningen med referrer, UTM-parametrar och klickidentifierare, och börjar omedelbart registrera varje efterföljande interaktion mot den identifieraren — klick, tryck, formulärändringar, ruttändringar, anpassade händelser och, när Contentsquare-integrationen är aktiverad, den fullständiga renderade DOM-diffensen för session replay.
Var och en av dessa aktiviteter engagerar en separat samtyckesport. Att bevara användaridentifieraren är en lagrings- och åtkomstoperation under Artikel 5(3) i ePrivacy-direktivet och kräver föregående, fritt givet, specifikt, informerat och otvetydigt samtycke i hela EEA, UK och varje jurisdiktion som har importerat samma standard. Att fånga auto-capture-händelseströmmen är behandling av personuppgifter under GDPR eftersom kombinationen av identifierare, IP-adress och beteendespår är tillräcklig för att peka ut en individ. Session replay faller i en separat, striktare kategori under EDPB:s session replay-vägledning — replay fångar renderat DOM och eventuellt omaskerade inmatningsfält och kräver uttryckligt, granulerat samtycke som är distinkt från generiskt analyssamtycke. CCPA och CPRA behandlar samma behandling som en försäljning eller delning om inte utgivaren har det relevanta leverantörsavtalet med Heap — vilket Heap erbjuder, men avtalet träder i kraft enbart när integrationen är konfigurerad för leverantörsläge.
Vad Heap skriver innan samtycke — och vad som måste undertryckas
Standardsnabbstarten som levereras med Heap-dashboarden installerar spårningssnippet direkt i sidans <head>. Det fungerar som dokumenterat och är källan till det vanligaste efterlevnadsfelet i Heap-driftsättningar: snippeten körs innan cookie-bannern har renderats, _hp2_-cookies skrivs inom millisekunder och auto-capture-strömmen börjar flöda till heapanalytics.com oavsett vad användaren senare bestämmer. Varje europeisk tillsynsmyndighet som har avgjort detta mönster har avgjort på samma sätt: cookies som sätts innan samtycke är olagliga och utgivaren bär ansvar.
En kompatibel integration måste därför förhindra att Heap-snippeten laddas tills den relevanta samtyckeskategorin har beviljats. De två mönster som fungerar i produktion är villkorlig skriptinjektion — snippeten läggs till i DOM:en först efter att CMP:n signalerar samtycke — och förladda snippeten med heap.load(appId, { disableTextCapture: true, secureCookie: true, autocapture: false }) som en uppskjuten bootstrap och sedan anropa heap.startAutoCapture() när samtycke har registrerats. Det villkorliga injektionsmönstret är renare och det som Heap-dokumentationen nu rekommenderar. Det uppskjutna bootstrap-mönstret är rätt val när utgivaren behöver en stabil global referens för identitetssammanslagning men inte kan tillåta auto-capture att triggas innan samtycke.
Cookies och lagring som Heap skriver
Heap-snippeten skriver följande identifierare vid initialisering, alla är icke-väsentliga och kräver samtycke: _hp2_id.{envId} med 14 månaders utgångsdatum som innehåller användaridentifieraren, _hp2_ses_id.{envId} med 30 minuters sessionsutgångsdatum, _hp2_props.{envId} för samplingshastighet och egenskapspropagering, och _hp2_loaded som laddningsmarkören. Den Contentsquare-integrerade session replay-modulen lägger till en inspelningsbuffert i minnet som töms till Heap-slutpunkten var några sekunder och kan bevara en liten replay-sessionsidentifierare separat. Att återkalla samtycke måste därför både utgångsdatera _hp2_-cookies och signalera en borttagningsbegäran via Heaps GDPR-API för användarens tidigare inspelningar och händelseström.
Kartläggning av Heap till samtyckesramverk
Heap implementerar inte IAB TCF eller IAB Global Privacy Platform nativt — det är en förstaparts produktanalysplattform, inte en adtech-leverantör — men integreras med Google Consent Mode v2 via bryggning på utgivarsidan, exponerar ett nativt opt-in och opt-out API, och stöder ett redaktionslager för känsliga egenskaper som fungerar oavsett samtyckestillstånd. Mönstret som överlever en tillsynsmyndighets granskning behandlar varje Heap-modul som en separat port bunden till en specifik CMP-signal.
- Auto-capture och kärnhändelseströmmen kopplas till analyssyftet. I TCF-termer är detta oftast syfte 8 (mäta innehållsprestanda) kombinerat med syfte 1 (lagra och/eller komma åt information). För Consent Mode mappas detta till analytics_storage.
- Session replay via Contentsquare-integrationen ligger bakom en striktare, separat port eftersom replay fångar renderat DOM och eventuella omaskerade inmatningsfält, och EDPB:s session replay-vägledning behandlar det som en kategori som kräver uttryckligt och granulerat samtycke distinkt från generisk analys.
- Användaridentifiering via heap.identify() kan köra med en efemär sessionsidentifierare under en legitim-intressebasis när användaren är anonym, men att koppla identifiering till en persistent förstapartsidentifierare över sessioner kräver samma samtycke som analys eftersom det är då identifieraren blir en spårbar datapunkt på användarnivå.
- Korsplattforms- eller korsproduktidentitetspropagering via identitets-API:et kräver marknadsföringsporten eftersom det korsar gränsen från produktanalys till marknadsföringsattribuering på användarnivå.
Integrationsmönstret som fungerar
Referensdriftsättningen har fyra delar: en CMP som exponerar en realtids samtyckeshändelse, en uppskjuten bootstrap som laddar Heap med auto-capture inaktiverat, en samtyckeslyssnare som aktiverar auto-capture och startar session replay-bufferten när de relevanta portarna öppnas, och en återkallningsväg som anropar heap.resetIdentity(), stoppar auto-capture, utgångsdaterar _hp2_-cookies och skickar en borttagningsbegäran via Heaps GDPR-slutpunkt.
Webbimplementering
På webben är det renaste mönstret att ladda Heap-snippeten villkorligt — <script>-taggen injiceras endast efter att analyskategorin har beviljats. Prenumerera på CMP:ns samtyckesändringshändelse. När analyskategorin övergår till sant, injicera Heap-snippeten med secureCookie: true, disableTextCapture: false för full auto-capture och eventuell miljöspecifik konfiguration. När session replay-samtycket övergår till sant och Contentsquare-integrationen är aktiverad aktiveras replay-bufferten automatiskt. När någon port återkallas, anropa heap.resetIdentity() följt av borttagning av Heap-scriptelementet, utgångsdatera _hp2_-cookies via document.cookie och aktivera GDPR-borttagnings-API:et för användarens identifierare.
Redaktion av känsliga egenskaper
Heap levereras med ett redaktionslager som fungerar oavsett samtyckestillstånd och som utgivare bör använda även när samtycke har beviljats. Attributet data-heap-redact-text på ett formulärfält undertrycker det fångade textinnehållet; attributet data-heap-redact-attributes undertrycker elementattributen. Under GDPR:s regler för särskild kategori och CCPA:s definition av känslig personlig information måste varje fält som potentiellt kan fånga hälsoinformation, finansiella detaljer, myndighetsidentifierare, biometriska uppgifter, exakt geolokalisering eller innehåll i privat kommunikation använda redaktionsattributen oavsett användarens samtyckestillstånd. Att sätta attributen på formulärnivå är det säkraste mönstret — det undertrycker hela formuläret även när en utvecklare lägger till ett nytt fält som de glömmer att märka individuellt.
Regionval: EU vs USA dataresidentskap
Heap driver separata EU- och USA-intagningsslutpunkter. För EEA- och UK-trafik är EU-slutpunkten rätt standard; den håller intag, bearbetning och lagring inom EEA och minskar Schrems II-exponeringen som varje USA-regionsanalys-driftsättning bär. Slutpunkten ställs in via snippetkonfigurationen och kan inte ändras retroaktivt — befintliga data stannar där de ursprungligen intogs. För utgivare som planerar en Heap-utrullning är det därför värt att bekräfta regionen innan skalning, och värt att dokumentera valet i integritetspolicyn så att den rättsliga grundskedjan är ren från insamling till lagring.
Validering av integrationen och revisionsspår
Valideringssteget är vad tillsynsmyndigheter kontrollerar och vad utgivare oftast hoppar över. En korrekt integrerad Heap-driftsättning måste klara fyra tester i följd. Först måste en ren webbläsarsession med bannern visad men inget val gjort producera noll begäranden till heapanalytics.com förutom SDK-filhämtningen och noll _hp2_-cookies i document.cookie. Andra, att avvisa analys måste hålla det tillståndet — ingen auto-capture, ingen identifierare, ingen inspelning. Tredje, att acceptera analys måste producera den förväntade _hp2_id-cookie med korrekta SameSite-attribut och händelsetrafik som flödar till den konfigurerade regionsslutpunkten. Fjärde, att återkalla samtycke måste omedelbart stoppa ytterligare auto-capture och replay, utgångsdatera _hp2_-cookies och utlösa en borttagningsbegäran via Heaps GDPR-API.
Revisionssspårförväntningen under EDPB:s riktlinjer för cookie-banner från 2023 och de förnyade prioriteterna för arbetsgruppen 2026 är att utgivaren kan bevisa, för varje given händelse i Heap-projektet, att användaren som genererade den hade gett giltigt samtycke vid tidpunkten för insamling. Standardmönstret är att ange samtyckesversion och tidsstämpel som användaregenskaper på det distinkta ID:t via heap.addUserProperties({ consent_version: 'v3', consent_ts: ts }) så att varje enskild händelse är spårbar tillbaka till en specifik samtyckesloggpost. En korrekt portad driftsättning, parad med redaktionsattribut som undertrycker känsliga fält som standard och en borttagningsväg som aktiveras vid återkallelse, är vad som förvandlar Heaps auto-capture-modell från en regulatorisk koncentrationsrisk till en av de mest kraftfulla och försvarliga delarna av en utgivares produktanalystack.