Hotjar Varmekart og Sesjonsopptak Cookie-samtykke Integrasjonsveiledning: 2026 Spillebok for Utgivere
Hotjar inntar en unik plass i verktøystakken. Det er ikke en nettanalyseplatform som Google Analytics, ikke en produktanalyseplatform som Amplitude eller Mixpanel, og ikke en tagbehandler. Det er et verktøy for brukeropplevelse-forskning som eksisterer spesifikt for å registrere hva individuelle brukere gjør på en side — hvor de beveger musen, hva de klikker, hvor de ruller, hvor de nøler, og i tilfelle av sesjonsopptak nøyaktig hva de skrev og så gjengitt på skjermen. Den granulariteten er produktet. Det er også grunnen til at regulatorer har pekt ut sesjonsavspilling som en av kategoriene med høyest risiko for atferdsbehandling, og hvorfor en uforsiktig Hotjar-distribusjon er en av de enkleste måtene et ellers compliant nettsted kan falle ut av samsvar. CNIL, Garante og EDPB har alle publisert veiledning som spesifikt retter seg mot sesjonsavspillings-atferd, og EDPB cookie banner-arbeidsgruppen for 2026 behandler det som en prioritetskategori. Den gode nyheten er at Hotjar er et av de bedre engineered verktøyene i kategorien for samtykke-først distribusjon — forutsatt at utgiveren faktisk bruker de kontrollene som finnes.
Hvorfor Hotjar krever eksplisitt samtykke
Hotjars innsamlingsprofil er det som utløser samtykkeforpliktelser på tvers av alle relevante rammeverk. På en standard initialisering skriver Hotjar-sporingsskriptet minst tre førstepartscookies — _hjSessionUser_{siteId}, _hjSession_{siteId}, og en rekke undertrykkings- og innkommende-kilde-cookies — inn i nettleseren innen millisekunder etter sidelasting. Skriptet begynner deretter å strømme en kontinuerlig registrering av markørkoordinater, klikkoordinater, rulleposisjon, visningsportsstørrelse, og når sesjonsopptak er aktivert, den fullstendig gjengitte DOM differensiert mot en grunnlinje.
Under artikkel 5(3) i ePrivacy-direktivet er hver av disse informasjonskapslene en lagrings-og-tilgang-operasjon som krever forutgående, fritt gitt, spesifikt, informert og utvetydig samtykke i EØS, Storbritannia, Sveits og enhver jurisdiksjon som har importert samme standard. Under GDPR utgjør atferdsstrømmen behandling av personopplysninger fordi kombinasjonen av markørspor, IP-adresse, enhetsfingeravtrykk og sesjonsidentifikator er tilstrekkelig til å singularisere et individ. Under CCPA og CPRA teller den samme innsamlingen som salg eller deling med mindre utgiveren har den relevante tjenesteleverandørkontrakten med Hotjar — som Hotjar tilbyr gjennom sin CCPA-compliant DPA, men som kun trer i kraft når integrasjonen er konfigurert riktig. Under EDPBs veiledning for sesjonsavspilling er listen enda høyere: avspilling må knyttes til et spesifikt, legitimt UX-forskningsformål, oppbevaringsperioden må være minimalt nødvendig, og den registrerte må informeres ikke bare om at opptak eksisterer, men at deres egen sesjon kan spilles av av en analytiker.
Hva Hotjar samler inn før samtykke — og hva som må undertrykkes
Den vanligste implementeringsfeilen er den som leveres med Hotjars egen hurtigstart: å lime inn sporingsskriptet direkte i sidens <head>. Det fungerer, men det laster Hotjar før cookiebanneret engang er gjengitt, noe som betyr at informasjonskapsler settes og atferdsregistrering begynner på den aller første sidevisningen — uavhengig av hva brukeren senere bestemmer. Enhver EU-regulator som har avgjort dette mønsteret har avgjort det på samme måte: informasjonskapsler satt før samtykke er ulovlige, og utgiveren er ansvarlig.
En compliant integrasjon må derfor forhindre at Hotjar-skriptet lastes i det hele tatt inntil den relevante samtykkekategorien er gitt. Den reneste måten å gjøre dette på er å pakke Hotjar-snippeten inn i en samtykke-portet <script>-tag som CMP injiserer kun etter at brukeren har valgt inn i analytics- eller produktforskningskategorien. Hvis skriptet lastes via en tagbehandler er ekvivalenten å sette utløseren til en samtykke-gitt-hendelse heller enn til Alle sider. Hotjars egen dokumentasjon anbefaler nå dette mønsteret eksplisitt, og plattformen eksponerer en hj('consent', 'grant') API for tilfeller der skriptet må være til stede men bør forbli inaktivt inntil samtykke er registrert.
Informasjonskapsler og lagring Hotjar skriver
Hotjar Tracking Code 6.x skriver følgende identifikatorer, alle av hvilke er ikke-essensielle og krever samtykke: _hjSessionUser_{siteId} med 365-dagers utløp som inneholder brukeridentifikatoren, _hjSession_{siteId} med 30-minutters utløp som inneholder sesjonsidentifikatoren, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress, og et antall kampanjeattribusjonscookies når undersøkelser eller tilbakemeldingswidgets er aktive. Sesjonsopptak lagres på Hotjars servere og er knyttet til sesjonsidentifikatoren — tilbakekalling av samtykke må derfor også signalisere en slettingsforespørsel via Hotjars API eller in-produkt bruker-sletteflyt.
Kartlegge Hotjar til samtykkerammeverk
Hotjar integrerer ikke nativt med IAB TCF eller IAB Global Privacy Platform. Det er ikke en ad-tech-leverandør og var aldri ment å være det. Det integrerer imidlertid med Google Consent Mode v2 via analytics_storage-signalet, og det eksponerer sin egen native samtykke-API som enhver CMP kan binde til. Mønsteret som overlever en regulators gjennomgang behandler hver Hotjar-funksjon som en separat samtykkeport.
- Varmekart og klikkart binder seg til analytics- eller produktforskningsformålet. I TCF-termer er dette oftest formål 8 (måle innholdsytelse) kombinert med formål 1 (lagre og/eller få tilgang til informasjon). For Consent Mode er dette analytics_storage.
- Sesjonsopptak bør sitte bak et strengere, separat signal. Opptak fanger den gjengitte DOM og eventuelle umaskerte felt, og en eksplisitt preferansenivå-opt-in — ikke blanket analytics-samtykke — er den forsvarlige holdningen under EDPBs veiledning for sesjonsavspilling.
- Undersøkelser og tilbakemeldingswidgets kan kjøre under samme samtykkeport som sesjonsopptak når de samler inn fritekst-input, eller under analytics-porten når de bare samler inn vurderingsdata.
- Trakter og konverteringssporing binder seg til analytics-porten; hvis noen brukeridentifikator propageres til et CRM eller annonseplattform gjelder også markedsføringsporten.
Integrasjonsmønsteret som fungerer
Referansedistribusjonen har fire deler: en CMP som eksponerer en sanntids samtykkeendringshendelse, en utsatt skriptlaster som bare injiserer Hotjar-snippeten etter at analytics-samtykke utløses, et sesjonsopptak-undertrykkingslag som standard setter opptak til av inntil en separat port åpnes, og en inndatamaskerings-konfigurasjon som hardt undertrykker ethvert felt en regulator ville vurdere som sensitivt selv når samtykke er gitt. Det fjerde punktet er ofte oversett: innmasking er ikke et substitutt for samtykke, men det er et substitutt for katastrofe når samtykke gis for legitim forskning og en bruker tilfeldigvis limer inn sensitive data i et fritekstfelt.
Nett-implementering
På nettet er det reneste mønsteret å abonnere på CMPs samtykkeendringshendelse, og deretter betinget injisere Hotjar-snippeten når analysicsformålet bytter fra false til true. Bruk document.createElement('script') til å injisere sporingskoden med async-attributtet satt, og legg ved en onload-handler som kaller hj('identify', userId, properties) kun hvis en server-validert brukeridentifikator eksisterer. Når samtykke trekkes tilbake, kall hj('consent', 'revoke'), la alle _hj-informasjonskapsler utløpe via document.cookie, og send en slettingsforespørsel via Hotjar Data API for brukerens tidligere sesjonsopptak. Ikke lat-initialiser Hotjar i samme renderpass som banneret — skriptet må vente på en eksplisitt tildeling, og tildelingen må registreres med et tidsstempel og samtykkestreng før skriptet i det hele tatt utløses.
Innmatingsmaskering og sensitivt-data-undertrykkelse
Hotjars sesjonsopptaker leveres med tre maskeringsmoduser: Suppress mode, som er standard for passordfelt og ethvert element merket med data-hj-suppress-attributtet; Whitelist mode, der bare eksplisitt valgte inndata registreres; og Mask mode, der tastetrykk registreres som asterisker. Under GDPRs spesialkategori-regler og CCPAs definisjon av sensitiv personlig informasjon, må ethvert felt som kan fange helseinformasjon, finansielle detaljer, statlige identifikatorer, biometriske data, presis geolokasjon eller innhold i privat kommunikasjon bruke Suppress mode uavhengig av brukerens samtykkestatus. Å sette data-hj-suppress på skjemanivå heller enn feltnivå er det sikreste mønsteret — det undertrykker hele skjemaet selv om en utvikler senere legger til et nytt felt som de glemmer å merke individuelt.
Enkeltside-applikasjoner og ruteendringer
For SPA-er (React, Vue, Angular, Svelte) binder Hotjar-snippeten seg bare til den første sidelastingen som standard. For å spore virtuelle sideoverganger må bootstrap-koden kalle hj('stateChange', newPath) ved hver ruteendring. Dette kallet respekterer den samtykketilstanden Hotjar har på det tidspunktet, så CMP-portlogikken trenger ikke å dupliseres — men ruteendringen må ikke i seg selv utløse en ny skriptlasting hvis samtykke er trukket tilbake mellom sidevisninger.
Validering av integrasjonen
Valideringstrinnet er det regulatorer sjekker og det utgivere oftest hopper over. En korrekt integrert Hotjar-distribusjon må bestå fire tester i rekkefølge. For det første bør en fersk nettleserøkt med banneret vist men ingen valg gjort produsere null forespørsler til static.hotjar.com, script.hotjar.com eller vars.hotjar.com, og null _hj-cookies i document.cookie. For det andre bør avvisning av analytics beholde den tilstanden — ingen skriptlasting, ingen opptak, ingen informasjonskapsler. For det tredje bør aksept av analytics produsere en skriptlasting og de forventede _hjSessionUser- og _hjSession-cookies med korrekte SameSite-attributter, og et varmekart-opptak bør vises i Hotjar-dashbordet innen fem minutter. For det fjerde bør tilbakekalling av samtykke etter det umiddelbart stoppe videre opptak, la informasjonskapslene utløpe og utløse en slettingsforespørsel — forsinket opprydding er et funn.
Revisjonssporet er viktig separat. Regulatorer forventer at utgiveren kan bevise, for ethvert gitt opptak i Hotjar-kontoen, at brukeren som genererte det hadde gitt gyldig samtykke på fangstøyeblikket. Standardmønsteret er å legge inn samtykkeversjon og tidsstempel som et tilpasset attributt på Hotjar-brukerposten via hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). Det gjør at ethvert spesifikt opptak kan spores tilbake til en spesifikk samtykkeloggoppføring, som er standarden EDPB har satt og standarden utgivere bør adoptere uavhengig av hvor de opererer. En korrekt portet distribusjon, kombinert med innmasking som undertrykker som standard og en slettingsbane som aktiveres ved tilbakekalling, er det som gjør Hotjar til en forsvarlig del av en forskningsstakk snarere enn en compliance-forpliktelse.