Hotjar Heatmap en Sessie-opname Cookie-toestemming Integratiegids: 2026 Draaiboek voor Uitgevers
Hotjar neemt een unieke positie in de toolingstack in. Het is geen webanalyseplatform zoals Google Analytics, geen productanalyseplatform zoals Amplitude of Mixpanel, en geen tagbeheerder. Het is een tool voor gebruikerservaring-onderzoek die er specifiek op gericht is te registreren wat individuele gebruikers op een pagina doen — waar ze hun muis bewegen, wat ze klikken, waar ze scrollen, waar ze aarzelen, en in het geval van sessie-opname precies wat ze typten en zagen weergegeven op het scherm. Die granulariteit is het product. Het is ook de reden waarom toezichthouders sessie-replay hebben aangeduid als een van de hoogste risico-categorieën van gedragsverwerking, en waarom een onzorgvuldige Hotjar-implementatie een van de makkelijkste manieren is waarop een anderszins compliante website buiten compliance kan raken. De CNIL, de Garante en het EDPB hebben allemaal richtlijnen gepubliceerd die specifiek gericht zijn op sessie-replay-gedrag, en de EDPB cookie banner-taskforce voor 2026 behandelt het als een prioriteitscategorie. Het goede nieuws is dat Hotjar een van de beter ontworpen tools in de categorie is voor consent-first implementatie — mits de uitgever daadwerkelijk de beschikbare bedieningselementen gebruikt.
Waarom Hotjar expliciete toestemming vereist
Het verzamelprofiel van Hotjar is wat toestemmingsverplichtingen activeert in elk relevant kader. Bij een standaard initialisatie schrijft het Hotjar-trackingscript minstens drie first-party cookies — _hjSessionUser_{siteId}, _hjSession_{siteId}, en een reeks onderdrukking- en inkomende-broncookies — binnen milliseconden na het laden van de pagina in de browser. Het script begint dan een continu record te streamen van cursorcoördinaten, klikcoördinaten, scrollpositie, viewportgrootte, en bij ingeschakelde sessie-opname de volledig gerenderde DOM vergeleken met een basislijn.
Onder artikel 5(3) van de ePrivacy-richtlijn is elk van die cookies een opslag-en-toegangsoperatie die in de EER, het VK, Zwitserland en elke jurisdictie die dezelfde norm heeft overgenomen voorafgaande, vrijelijk gegeven, specifieke, geïnformeerde en ondubbelzinnige toestemming vereist. Onder de GDPR vormt de gedragsstroom verwerking van persoonsgegevens omdat de combinatie van cursorspoor, IP-adres, apparaatvingerafdruk en sessie-identifier voldoende is om een individu te singulariseren. Onder de CCPA en CPRA telt dezelfde verzameling als verkoop of deling tenzij de uitgever het relevante dienstverlenercontract met Hotjar heeft — dat Hotjar aanbiedt via zijn CCPA-compliant DPA, maar alleen van kracht wordt wanneer de integratie correct is geconfigureerd. Onder de EDPB-richtlijnen voor sessie-replay ligt de lat nog hoger: replay moet worden gekoppeld aan een specifiek, legitiem UX-onderzoeksdoel, de bewaartermijn moet minimaal noodzakelijk zijn, en de betrokkene moet niet alleen worden geïnformeerd dat opnames bestaan, maar ook dat zijn eigen sessie mogelijk door een analist wordt afgespeeld.
Wat Hotjar verzamelt vóór toestemming — en wat onderdrukt moet worden
De meest voorkomende implementatiefout is degene die wordt geleverd met Hotjar's eigen quickstart: het trackingscript rechtstreeks in de <head> van de pagina plakken. Dat werkt, maar het laadt Hotjar voordat de cookiebanner zelfs maar is gerenderd, wat betekent dat cookies worden ingesteld en gedragsregistratie begint bij de allereerste paginaweergave — ongeacht wat de gebruiker later besluit. Elke EU-toezichthouder die over dit patroon heeft geoordeeld, heeft op dezelfde manier geoordeeld: cookies die zijn ingesteld vóór toestemming zijn onwettig, en de uitgever is aansprakelijk.
Een conforme integratie moet er daarom voor zorgen dat het Hotjar-script helemaal niet laadt totdat de relevante toestemmingscategorie is verleend. De schoonste manier om dit te doen is het Hotjar-fragment in een toestemmingsbeheerd <script>-tag te plaatsen dat de CMP alleen injecteert nadat de gebruiker heeft ingestemd met de analytics- of productonderzoekscategorie. Als het script via een tagbeheerder wordt geladen, is het equivalent de trigger in te stellen op een toestemming-verleend-event in plaats van op Alle pagina's. Hotjar's eigen documentatie beveelt dit patroon nu expliciet aan, en het platform stelt een hj('consent', 'grant') API beschikbaar voor gevallen waarin het script aanwezig moet zijn maar slapend moet blijven totdat toestemming is vastgelegd.
Cookies en opslag die Hotjar schrijft
De Hotjar Tracking Code 6.x schrijft de volgende identifiers, die allemaal niet-essentieel zijn en toestemming vereisen: _hjSessionUser_{siteId} met een vervaldatum van 365 dagen die de gebruikersidentifier bevat, _hjSession_{siteId} met een vervaldatum van 30 minuten die de sessie-identifier bevat, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress, en een aantal campagne-attributiecookies wanneer enquêtes of feedbackwidgets actief zijn. Sessie-opnames zelf worden opgeslagen op de servers van Hotjar en gekoppeld aan de sessie-identifier — het intrekken van toestemming moet daarom ook een verwijderverzoek signaleren via Hotjar's API of de in-product gebruikers-verwijderstroom.
Hotjar koppelen aan toestemmingskaders
Hotjar integreert niet van nature met IAB TCF of het IAB Global Privacy Platform. Het is geen ad-tech-leverancier en was nooit bedoeld om dat te zijn. Het integreert echter wel met Google Consent Mode v2 via het analytics_storage-signaal, en het stelt zijn eigen native toestemming-API beschikbaar waaraan elke CMP kan koppelen. Het patroon dat een regulatoire toetsing overleeft behandelt elke Hotjar-mogelijkheid als een aparte toestemmingsgate.
- Heatmaps en klikmaps koppelen aan het analytics- of productonderzoeksdoel. In TCF-termen is dit het meest gebruikelijk doel 8 (contentprestaties meten) gecombineerd met doel 1 (informatie opslaan en/of openen). Voor Consent Mode is dit analytics_storage.
- Sessie-opname moet achter een strikter, apart signaal zitten. Opname legt de gerenderde DOM vast en elk niet-gemaskeerd veld, en een expliciete opt-in op voorkeurniveau — geen blanket analytics-toestemming — is de verdedigbare houding onder de EDPB-richtlijnen voor sessie-replay.
- Enquêtes en feedbackwidgets kunnen onder dezelfde toestemmingsgate als sessie-opname worden uitgevoerd wanneer ze vrije tekst verzamelen, of onder de analyticsgate wanneer ze alleen beoordelingsdata verzamelen.
- Funnels en conversie-tracking koppelen aan de analyticsgate; als een gebruikersidentifier wordt doorgegeven aan een CRM of advertentieplatform is ook de marketinggate van toepassing.
Het integratiepatroon dat werkt
De referentie-implementatie heeft vier delen: een CMP die een realtime toestemmingswijziging-event beschikbaar stelt, een uitgestelde scriptlader die het Hotjar-fragment alleen injecteert nadat analyticstoestemming wordt geactiveerd, een sessie-opname-onderdrukkingslaag die opname standaard uitschakelt totdat een aparte gate opengaat, en een invoermaskeringsconfiguratie die elk veld dat een toezichthouder als gevoelig zou beschouwen hard onderdrukt zelfs wanneer toestemming is verleend. Het vierde punt wordt vaak over het hoofd gezien: invoermaskering is geen vervanging voor toestemming, maar het is wel een vervanging voor een ramp wanneer toestemming wordt verleend voor legitiem onderzoek en een gebruiker toevallig gevoelige gegevens in een vrij tekstveld plakt.
Web-implementatie
Op het web is het schoonste patroon zich te abonneren op het toestemmingswijziging-event van de CMP en het Hotjar-fragment dan conditioneel te injecteren wanneer het analyticsdoel omschakelt van false naar true. Gebruik document.createElement('script') om de trackingcode te injecteren met het async-attribuut ingesteld, en koppel een onload-handler die hj('identify', userId, properties) aanroept alleen als een door de server gevalideerde gebruikersidentifier bestaat. Wanneer toestemming wordt ingetrokken, roep hj('consent', 'revoke') aan, laat alle _hj-cookies vervallen via document.cookie, en stuur een verwijderverzoek via de Hotjar Data API voor de vorige sessie-opnames van de gebruiker. Initialiseer Hotjar niet lui in dezelfde renderingpass als de banner — het script moet wachten op een expliciete verlening, en de verlening moet worden vastgelegd met een tijdstempel en toestemmingsstring voordat het script überhaupt wordt uitgevoerd.
Invoermaskering en gevoelige-dataponderdrukking
Hotjar's sessierecorder wordt geleverd met drie maskeringsmodi: Suppress mode, wat de standaard is voor wachtwoordvelden en elk element gemarkeerd met het data-hj-suppress-attribuut; Whitelist mode, waarbij alleen expliciet aangemelde invoer wordt vastgelegd; en Mask mode, waarbij toetsaanslagen worden vastgelegd als sterretjes. Onder de speciale-categorieregels van de GDPR en de definitie van gevoelige persoonlijke informatie van de CCPA moet elk veld dat gezondheidsinformatie, financiële details, overheidsidentifiers, biometrische gegevens, nauwkeurige geolocatie of inhoud van privécommunicaties kan vastleggen Suppress mode gebruiken ongeacht de toestemmingsstatus van de gebruiker. Het instellen van data-hj-suppress op formulierniveau in plaats van veldniveau is het veiligste patroon — het onderdrukt het volledige formulier zelfs als een ontwikkelaar later een nieuw veld toevoegt dat hij vergeet individueel te markeren.
Single-page applicaties en route-wijzigingen
Voor SPA's (React, Vue, Angular, Svelte) bindt het Hotjar-fragment standaard alleen aan de initiële paginalading. Om virtuele paginaovergangen te volgen moet de bootstrap hj('stateChange', newPath) aanroepen bij elke route-wijziging. Deze aanroep respecteert de op dat moment geldende toestemmingsstatus van Hotjar, dus de CMP-gatinglogica hoeft niet te worden gedupliceerd — maar de route-wijziging mag zelf geen nieuwe scriptiading activeren als de toestemming tussen paginaweergaven is ingetrokken.
De integratie valideren
De validatiestap is wat toezichthouders controleren en wat uitgevers het vaakst overslaan. Een correct geïntegreerde Hotjar-implementatie moet vier tests in volgorde doorstaan. Ten eerste moet een nieuwe browsersessie met de getoonde banner maar zonder gemaakte keuze nul verzoeken aan static.hotjar.com, script.hotjar.com of vars.hotjar.com produceren, en nul _hj-cookies in document.cookie. Ten tweede moet het weigeren van analytics die staat behouden — geen script geladen, geen opname, geen cookies. Ten derde moet het accepteren van analytics een script laden en de verwachte _hjSessionUser- en _hjSession-cookies met correcte SameSite-attributen produceren, en een heatmap-opname moet binnen vijf minuten in het Hotjar-dashboard verschijnen. Ten vierde moet het intrekken van toestemming achteraf onmiddellijk verdere opname stoppen, de cookies laten verlopen en een verwijderverzoek activeren — vertraagde opschoning is een bevinding.
Het auditspoor is apart van belang. Toezichthouders verwachten dat de uitgever voor elke opname in het Hotjar-account kan aantonen dat de gebruiker die de opname genereerde op het moment van vastleggen geldige toestemming had gegeven. Het standaardpatroon is de toestemmingsversie en het tijdstempel als aangepast attribuut in te bedden in de Hotjar-gebruikersrecord via hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). Dat maakt elke specifieke opname herleidbaar naar een specifieke toestemmingslogvermelding, wat de standaard is die het EDPB heeft vastgesteld en de standaard die uitgevers moeten hanteren ongeacht waar ze actief zijn. Een correct beveiligde implementatie, gecombineerd met invoermaskering die standaard onderdrukt en een verwijderpad dat wordt geactiveerd bij intrekking, is wat Hotjar een verdedigbaar onderdeel van een onderzoeksstack maakt in plaats van een compliance-aansprakelijkheid.