Integrationsvägledning för cookie-samtycke för Hotjar Heatmap och Sessionsregistrering: 2026 Spelbok för Utgivare
Hotjar håller en unik plats i verktygsstacken. Det är inte en webbanalytikplattform som Google Analytics, inte en produktanalytikplattform som Amplitude eller Mixpanel, och inte en tagghanterare. Det är ett verktyg för användarupplevelseforskning som finns specifikt för att registrera vad enskilda användare gör på en sida — var de rör musen, vad de klickar på, var de scrollar, var de tvekar, och i fallet med sessionsregistrering, exakt vad de skrivit och sett renderat på skärmen. Den granulariteten är produkten. Det är också varför tillsynsmyndigheter har pekat ut sessionsreplay som en av de högsta riskategorierna för beteendebehandling, och varför en slarvig Hotjar-driftsättning är ett av de enklaste sätten för en annars regelefterlevande webbplats att falla ur efterlevnad. CNIL, Garante och EDPB har alla publicerat vägledning specifikt riktad mot sessionsreplay-beteende, och EDPB:s cookie-bannerarbetsgrupp för 2026 behandlar det som en prioritetskategori. Den goda nyheten är att Hotjar är ett av de bättre konstruerade verktygen i kategorin för samtyckesfirstimplementering — förutsatt att utgivaren faktiskt använder de kontroller som finns.
Varför Hotjar kräver uttryckligt samtycke
Hotjars insamlingsprofil är det som utlöser samtyckesförpliktelser i alla ramverk som spelar roll. Vid en standard-initialisering skriver Hotjars spårningsskript minst tre förstapartscookies — _hjSessionUser_{siteId}, _hjSession_{siteId} och en serie undertrycknings- och inkommande källcookies — i webbläsaren inom millisekunder efter sidinläsning. Skriptet börjar sedan strömma ett kontinuerligt register över koordinater för muspekaren, klickkoordinater, scrollposition, visningsstorlek och, när sessionsregistrering är aktiverad, hela den renderade DOM:en differensad mot en baslinje.
Under Artikel 5(3) i ePrivacy-direktivet är var och en av dessa cookies en lagrings- och åtkomstoperation som kräver föregående, fritt givet, specifikt, informerat och otvetydigt samtycke i EEA, UK, Schweiz och alla jurisdiktioner som har antagit samma standard. Under GDPR utgör beteendeströmmen behandling av personuppgifter eftersom kombinationen av muspekarlinje, IP-adress, enhetens fingeravtryck och sessionsidentifierare räcker för att identifiera en individ. Under CCPA och CPRA räknas samma insamling som en försäljning eller delning om inte utgivaren har det relevanta tjänsteleverantörsavtalet med Hotjar — som Hotjar erbjuder via sitt CCPA-kompatibla DPA, men som bara träder i kraft när integrationen är korrekt konfigurerad. Under EDPB:s sessionsreplay-vägledning är ribban ännu högre: replay måste vara knuten till ett specifikt, legitimt UX-forskningssyfte, lagringsperioden måste vara minimal och nödvändig, och den registrerade måste informeras inte bara om att inspelningar finns, utan att deras egen session kan återuppspelas av en analytiker.
Vad Hotjar samlar in före samtycke — och vad som måste undertryckas
Det vanligaste implementationsfelet är det som levereras med Hotjars egna quickstart: att klistra in spårningsskriptet direkt i sidans <head>. Det fungerar, men laddar Hotjar innan cookie-bannern ens renderats, vilket innebär att cookies sätts och beteenderegistrering börjar vid allra första sidvisningen — oavsett vad användaren senare beslutar. Varje EU-tillsynsmyndighet som har prövat detta mönster har prövat det på samma sätt: cookies satta före samtycke är olagliga och utgivaren är ansvarig.
En regelefterlevande integration måste därför förhindra att Hotjar-skriptet laddas alls tills den relevanta samtyckeskategorin har beviljats. Det renaste sättet att göra detta är att linda in Hotjar-snippeten inuti en samtyckesgradad <script>-tagg som CMP:n injicerar först efter att användaren har valt in i analytics- eller produktforskningskategorin. Om skriptet laddas via en tagghanterare är motsvarigheten att ställa in utlösaren till ett samtyckesbeviljat händelse snarare än till All Pages. Hotjars egna dokumentation rekommenderar nu detta mönster uttryckligen, och plattformen exponerar en hj('consent', 'grant') API för fall där skriptet måste finnas men bör förbli vilande tills samtycke registreras.
Cookies och lagring som Hotjar skriver
Hotjar Tracking Code 6.x skriver följande identifierare, alla är icke-essentiella och kräver samtycke: _hjSessionUser_{siteId} med 365-dagars utgång som innehåller användaridentifieraren, _hjSession_{siteId} med 30-minuters utgång som innehåller sessionsidentifieraren, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress och ett antal kampanjtillskrivningscookies när undersökningar eller feedbackwidgetar är aktiva. Sessionsregistreringarna lagras på Hotjars servrar och är nycklad till sessionsidentifieraren — att återkalla samtycke måste därför även signalera en radering via Hotjars API eller produktintern användarraderingsflöde.
Kartlägga Hotjar mot samtyckesramverk
Hotjar integrerar inte nativt med IAB TCF eller IAB Global Privacy Platform. Det är inte en annonsteknikförsäljare och var aldrig avsett att vara en. Det integrerar dock med Google Consent Mode v2 via signalen analytics_storage, och exponerar sin egen nativa samtyckes-API som vilken CMP som helst kan binda till. Det mönster som överlever en tillsynsmyndighets granskning behandlar varje Hotjar-förmåga som en separat samtyckesgrind.
- Värmekarta och klickkartor binds till analys- eller produktforskningssyftet. I TCF-termer är detta vanligast syfte 8 (mät innehållsprestanda) kombinerat med syfte 1 (lagra och/eller komma åt information). För Consent Mode är detta analytics_storage.
- Sessionsregistrering bör sitta bakom en striktare, separat signal. Registrering fångar renderad DOM och alla omaskerade fält, och en uttrycklig preferensnivå opt-in — inte täckande analyksamtycke — är den försvarsbara positionen under EDPB:s sessionsreplay-vägledning.
- Undersökningar och feedbackwidgetar kan köras under samma samtyckesgrind som sessionsregistrering när de samlar in fritext, eller under analysgrindet när de bara samlar in betygsdata.
- Trattar och konverteringsspårning binds till analysgrindet; om någon användaridentifierare propageras till en CRM eller annonsplattform gäller även marknadsföringsgrindet.
Det integrationsmönster som fungerar
Referensdriftsättningen har fyra delar: en CMP som exponerar en realtids samtyckeändringshändelse, en fördröjd skriptladdare som bara injicerar Hotjar-snippeten efter att analyksamtycke utlöses, ett undertryckningslager för sessionsregistrering som som standard ställer registrering till av tills en separat grind öppnas, och en inmatningsmaskeringskonfiguration som hårdundertrycker alla fält en tillsynsmyndighet skulle betrakta som känsliga även när samtycke har beviljats. Den fjärde punkten förbises ofta: inmatningsmaskning är inte en ersättning för samtycke, men det är en ersättning för katastrof när samtycke beviljas för legitim forskning och en användare råkar klistra in känsliga uppgifter i ett fritextfält.
Webbimplementation
På webben är det renaste mönstret att prenumerera på CMP:ns samtyckeändringshändelse och sedan villkorligt injicera Hotjar-snippeten när analyspurposen växlar från false till true. Använd document.createElement('script') för att injicera spårningskoden med attributet async inställt, och bifoga en onload-hanterare som anropar hj('identify', userId, properties) bara om ett servavaliderat användaridentifierare finns. När samtycke återkallas, anropa hj('consent', 'revoke'), förfalla alla _hj-cookies via document.cookie och skicka en raderingsbegäran via Hotjar Data API för användarens tidigare sessionsregistreringar. Initiera inte Hotjar lätt i samma renderingspass som bannern — skriptet måste vänta på ett uttryckligt beviljande, och beviljandet måste registreras med en tidsstämpel och samtyckessträngen innan skriptet någonsin utlöses.
Inmatningsmaskning och undertryckning av känsliga data
Hotjars sessionsregistrerare levereras med tre maskeringslägen: Suppress mode, som är standard för lösenordsfält och alla element märkta med attributet data-hj-suppress; Whitelist mode, där bara uttryckligen inkluderade inmatningar registreras; och Mask mode, där tangenttryckningar registreras som asterisker. Under GDPR:s specialkategorieregler och CCPA:s definition av känslig personlig information måste alla fält som kan fånga hälsoinformation, finansiella uppgifter, statliga identifierare, biometriska data, precis geolokalisering eller innehållet i privata kommunikationer använda Suppress mode oavsett användarens samtyckestillstånd. Att ställa in data-hj-suppress på formulärnivå snarare än fältnivå är det säkraste mönstret — det undertrycker hela formuläret även om en utvecklare senare lägger till ett nytt fält som de glömmer att märka individuellt.
Enkelsidiga applikationer och ruttändringar
För SPA:er (React, Vue, Angular, Svelte) binds Hotjar-snippeten som standard bara till den initiala sidinläsningen. För att spåra virtuella sidövergångar måste bootstrap anropa hj('stateChange', newPath) vid varje ruttändring. Detta anrop respekterar vilket samtyckestillstånd Hotjar håller vid tillfället, så CMP-gatinglogiken behöver inte dupliceras — men ruttändringen i sig får inte utlösa en ny skriptladdning om samtycke har återkallats mellan sidvisningar.
Validering av integrationen
Valideringssteget är vad tillsynsmyndigheter kontrollerar och vad utgivare oftast hoppar över. En korrekt integrerad Hotjar-driftsättning måste klara fyra tester i ordning. Först bör en ny webbläsarsession med bannern visad men inget val gjort producera noll förfrågningar till static.hotjar.com, script.hotjar.com eller vars.hotjar.com och noll _hj-cookies i document.cookie. Andra, att avböja analys bör hålla det tillståndet — ingen skriptladdning, ingen registrering, inga cookies. Tredje, att acceptera analys bör producera en skriptladdning och de förväntade _hjSessionUser- och _hjSession-cookies med korrekta SameSite-attribut, och en värmekartregistrering bör dyka upp i Hotjar-kontrollpanelen inom fem minuter. Fjärde, att återkalla samtycke efteråt bör omedelbart stoppa ytterligare registrering, förfalla cookies och utlösa en raderingsbegäran — en fördröjd rensning är ett fynd.
Granskningsspåret spelar roll separat. Tillsynsmyndigheter förväntar sig att utgivaren ska kunna bevisa, för varje given inspelning i Hotjar-kontot, att användaren som genererade den hade gett giltigt samtycke vid fångsttillfället. Standardmönstret är att bädda in samtyckesversionen och tidsstämpeln som ett anpassat attribut på Hotjar-användarposten via hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). Det gör varje specifik inspelning spårbar tillbaka till en specifik loggpost för samtycke, vilket är standarden som EDPB har satt och standarden som utgivare bör anta oavsett var de verkar. En korrekt gated driftsättning, parad med inmatningsmaskning som undertrycker som standard och en raderingsväg som aktiveras vid återkallelse, är det som gör Hotjar till en försvarbar del av en forskningsstack snarare än en efterlevnadsplikt.