Hotjar Hőtérkép és Munkamenet-rögzítés Cookie Hozzájárulás Integrációs Útmutató: 2026-os Kiadó Kézikönyv
A Hotjar egyedülálló helyet foglal el az eszközkészletben. Nem webelemzési platform, mint a Google Analytics, nem termékanalitikai platform, mint az Amplitude vagy a Mixpanel, és nem is tagkezelő. Ez egy felhasználói élménykutatási eszköz, amelynek kifejezett célja az egyes felhasználók oldalon végzett tevékenységeinek rögzítése — az egér mozgása, a kattintások helye, a görgetés mértéke, a habozás helye, és munkamenet-rögzítés esetén pontosan az, amit a felhasználó begépelt és a képernyőn látott. Ez a granularitás maga a termék. Ez az oka annak is, hogy a szabályozók a munkamenet-visszajátszást az egyik legmagasabb kockázatú viselkedési adatkezelési kategóriának tekintik, és ez az oka annak, hogy egy gondatlan Hotjar telepítés az egyik legkönnyebb módja annak, hogy egy egyébként megfelelő weboldal megfelelőségi problémába kerüljön. A CNIL, a Garante és az EDPB mind közzétett konkrétan a munkamenet-visszajátszásra vonatkozó útmutatást, és a 2026-os EDPB cookie banner munkacsoport prioritáskategóriaként kezeli. A jó hír az, hogy a Hotjar az egyik jobban megtervezett eszköz ebben a kategóriában a hozzájárulás-először telepítéshez — feltéve, hogy a kiadó ténylegesen használja a rendelkezésre álló vezérlőket.
Miért igényel a Hotjar kifejezett hozzájárulást
A Hotjar gyűjtési profilja az, ami minden fontos keretrendszerben hozzájárulási kötelezettségeket vált ki. Alapértelmezett inicializáláskor a Hotjar nyomkövető szkript legalább három saját cookie-t ír — _hjSessionUser_{siteId}, _hjSession_{siteId}, és egy sor elnyomási és bejövő forrás cookie-t — a böngészőbe az oldalletöltés után milliszekundumokkal. A szkript ezután folyamatos adatfolyamot indít el kurzorkoordináták, kattintási koordináták, görgetési pozíció, nézetablak mérete, és munkamenet-rögzítés esetén a teljes megjelenített DOM alapvonal-összehasonlítás alapján.
Az ePrivacy Irányelv 5(3) cikke alapján mindegyik cookie tárolási és hozzáférési művelet, amely előzetes, szabadon adott, konkrét, tájékoztatott és egyértelmű hozzájárulást igényel az EEA-ban, az Egyesült Királyságban, Svájcban és minden olyan joghatóságban, amely ugyanezt a szabványt átvette. A GDPR alapján a viselkedési adatfolyam személyes adatok kezelésének minősül, mivel a kurzornyom, az IP-cím, az eszközujjlenyomat és a munkamenet-azonosító kombinációja elegendő egy egyén azonosításához. A CCPA és CPRA alapján ugyanez a gyűjtés értékesítésnek vagy megosztásnak minősül, kivéve ha a kiadónak megvan a vonatkozó szolgáltatói szerződése a Hotjarral — amelyet a Hotjar a CCPA-kompatibilis DPA révén kínál, de csak akkor lép hatályba, ha az integráció helyesen van konfigurálva. Az EDPB munkamenet-visszajátszásra vonatkozó útmutatása alapján a küszöb még magasabb: a visszajátszást specifikus, jogszerű UX-kutatási célhoz kell kötni, a megőrzési időt a szükséges minimumra kell korlátozni, és az érintettet nem csak arról kell tájékoztatni, hogy felvételek léteznek, hanem arról is, hogy saját munkamenetét egy elemző visszajátszhatja.
Mit gyűjt a Hotjar hozzájárulás előtt — és mit kell elnyomni
A leggyakoribb implementációs hiba az, amely a Hotjar saját gyorsindításával kerül szállításra: a nyomkövető szkript közvetlenül az oldal <head> részébe másolása. Ez működik, de a Hotjart még azelőtt tölti be, hogy a cookie banner megjelenítésre került volna, ami azt jelenti, hogy cookie-k kerülnek beállításra és a viselkedési rögzítés az első oldallátogatáson kezdődik — függetlenül attól, hogy a felhasználó később mit dönt. Minden EU szabályozó, amely döntött erről a mintáról, ugyanúgy döntött: a hozzájárulás előtt beállított cookie-k jogszerűtlenek, és a kiadó felelős.
Egy megfelelő integrációnak tehát meg kell akadályoznia, hogy a Hotjar szkript egyáltalán betöltődjön, amíg a vonatkozó hozzájárulási kategória meg nem lett adva. Ennek legtisztább módja az, hogy a Hotjar kódrészletet egy hozzájáruláshoz kötött <script> tagbe kell csomagolni, amelyet a CMP csak akkor injektál, ha a felhasználó belépett az elemzési vagy termékfejlesztési kategóriába. Ha a szkript egy tagkezelőn keresztül töltődik be, akkor az egyenértékű az trigger beállítása egy hozzájárulás-megadási eseményre az Összes oldal helyett. A Hotjar saját dokumentációja most kifejezetten javasolja ezt a mintát, és a platform egy hj('consent', 'grant') API-t tesz elérhetővé azokban az esetekben, amikor a szkriptnek jelen kell lennie, de szunnyadóan kell maradnia, amíg a hozzájárulás rögzítésre nem kerül.
A Hotjar által írt cookie-k és tárolók
A Hotjar Tracking Code 6.x a következő azonosítókat írja, amelyek mind nem alapvető fontosságúak és hozzájárulást igényelnek: _hjSessionUser_{siteId} 365 napos lejárattal, amely a felhasználói azonosítót tartalmazza, _hjSession_{siteId} 30 perces lejárattal, amely a munkamenet-azonosítót tartalmazza, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress, és számos kampány-hozzárendelési cookie, amikor felmérések vagy visszajelzési widgetek aktívak. Maguk a munkamenet-felvételek a Hotjar szervereire kerülnek tárolásra, és a munkamenet-azonosítóhoz vannak kötve — a hozzájárulás visszavonásának ezért törlési kérelmet is kell jelezni a Hotjar API-n vagy a terméken belüli felhasználó-törlési folyamaton keresztül.
A Hotjar leképezése hozzájárulási keretrendszerekre
A Hotjar natívan nem integrálódik az IAB TCF-fel vagy az IAB Global Privacy Platform-mal. Nem egy hirdetéstechnológiai szállító, és soha nem is volt azzá szánva. Integrálódik azonban a Google Consent Mode v2-vel az analytics_storage jelen keresztül, és saját natív hozzájárulási API-t tesz elérhetővé, amelyhez bármely CMP kapcsolódhat. Az a minta, amely megállja a helyét egy szabályozói felülvizsgálaton, minden Hotjar képességet külön hozzájárulási kapuként kezel.
- Hőtérképek és kattintástérképek az elemzési vagy termékfejlesztési célhoz kötődnek. TCF szempontból ez leggyakrabban a 8. cél (tartalom teljesítményének mérése) kombinálva az 1. céllal (információk tárolása és/vagy hozzáférése). Hozzájárulási módhoz ez az analytics_storage.
- A munkamenet-rögzítésnek egy szigorúbb, külön jel mögött kell állnia. A rögzítés rögzíti a megjelenített DOM-ot és bármely maszkolatlan mezőt, és az EDPB munkamenet-visszajátszásra vonatkozó útmutatása alapján az explicit preferencia szintű hozzájárulás — nem az általános elemzési hozzájárulás — a védhető álláspont.
- A felmérések és visszajelzési widgetek ugyanolyan hozzájárulási kapu alatt futhatnak, mint a munkamenet-rögzítés, ha szabad szöveges bevitelt gyűjtenek, vagy az elemzési kapu alatt, ha csak értékelési adatokat gyűjtenek.
- A tölcsérek és konverziókövetés az elemzési kapuhoz kötődnek; ha bármely felhasználói azonosítót egy CRM-be vagy hirdetési platformra propagálnak, a marketing kapu is alkalmazandó.
A működő integrációs minta
A referencia telepítésnek négy része van: egy CMP, amely valós idejű hozzájárulásváltozási eseményt tesz elérhetővé, egy halasztott szkript betöltő, amely csak az elemzési hozzájárulás megszerzése után injektálja a Hotjar kódrészletet, egy munkamenet-rögzítési elnyomási réteg, amely alapértelmezés szerint rögzítést ki állapotba állítja, amíg egy külön kapu nem nyílik meg, és egy beviteli maszkolási konfiguráció, amely keményen elnyom minden mezőt, amelyet egy szabályozó érzékenynek tekintene, még akkor is, ha hozzájárulás már megadásra került. A negyedik pont sokszor figyelmen kívül marad: a beviteli maszkolás nem helyettesíti a hozzájárulást, de helyettesíti a katasztrófát, amikor hozzájárulás adódik jogos kutatási célra, és egy felhasználó véletlenül érzékeny adatokat illeszt be egy szabad szöveges mezőbe.
Webes megvalósítás
A weben a legtisztább minta az, hogy feliratkozunk a CMP hozzájárulásváltozási eseményére, majd feltételesen injektáljuk a Hotjar kódrészletet, amikor az elemzési cél hamisból igazra vált. A document.createElement('script') segítségével injektáljuk a nyomkövető kódot az async attribútum beállításával, és hozzáadunk egy onload kezelőt, amely csak akkor hívja meg a hj('identify', userId, properties) függvényt, ha szerver által érvényesített felhasználói azonosító létezik. Amikor a hozzájárulást visszavonják, hívjuk meg a hj('consent', 'revoke') függvényt, járjunk le minden _hj cookie-t a document.cookie segítségével, és küldjünk törlési kérelmet a Hotjar Data API-n keresztül a felhasználó korábbi munkamenet-felvételeihez. Ne inicializáljuk lustán a Hotjart ugyanabban a megjelenítési menetben, mint a banner — a szkriptnek explicit megadásra kell várnia, és a megadást időbélyeggel és hozzájárulási karakterlánccal kell rögzíteni, mielőtt a szkript valaha is elindul.
Beviteli maszkolás és érzékeny adatok elnyomása
A Hotjar munkamenet-rögzítője három maszkolási móddal érkezik: Suppress mode, amely alapértelmezett jelszómezők és az data-hj-suppress attribútummal jelölt elemek számára; Whitelist mode, ahol csak az explicit módon engedélyezett bevitelek rögzítésre kerülnek; és Mask mode, ahol a billentyűleütések csillagokként kerülnek rögzítésre. A GDPR különleges kategóriájú szabályai és a CCPA érzékeny személyes adatok definíciója alapján minden olyan mezőt, amely egészségügyi adatokat, pénzügyi részleteket, kormányzati azonosítókat, biometrikus adatokat, pontos tartózkodási helyet vagy privát kommunikáció tartalmát rögzítheti, Suppress mode-ban kell használni a felhasználó hozzájárulási állapotától függetlenül. A data-hj-suppress beállítása a mező szintje helyett az űrlap szintjén a legbiztonságosabb minta — elnyomja az egész űrlapot, még akkor is, ha egy fejlesztő később hozzáad egy új mezőt, amelyet elfelejtett egyedileg megjelölni.
Egyoldalas alkalmazások és útvonalváltások
SPA-k esetén (React, Vue, Angular, Svelte) a Hotjar kódrészlet alapértelmezés szerint csak a kezdeti oldalletöltéshez kötődik. A virtuális oldaltranzitek nyomon követéséhez a bootstrapnek minden útvonalváltásnál meg kell hívnia a hj('stateChange', newPath) függvényt. Ez a hívás tiszteletben tartja azt a hozzájárulási állapotot, amelyet a Hotjar ebben az időpontban tart, tehát a CMP kapu logikát nem kell duplikálni — de az útvonalváltásnak nem szabad friss szkriptbetöltést kiváltania, ha az oldalletöltések között visszavonták a hozzájárulást.
Az integráció érvényesítése
Az érvényesítési lépés az, amit a szabályozók ellenőriznek, és amit a kiadók leggyakrabban kihagynak. Egy helyesen integrált Hotjar telepítésnek sorban négy teszten kell átmennie. Először, egy friss böngésző munkamenetnek, amelyben a banner megjelenik, de nem történt választás, nulla kérést kell produkálnia a static.hotjar.com, script.hotjar.com vagy vars.hotjar.com felé, és nulla _hj cookie-t a document.cookie-ban. Másodszor, az elemzés elutasításának meg kell őriznie ezt az állapotot — nincs szkriptbetöltés, nincs rögzítés, nincs cookie. Harmadszor, az elemzés elfogadásának szkriptbetöltést és a várt _hjSessionUser és _hjSession cookie-kat kell produkálnia helyes SameSite attribútumokkal, és öt percen belül meg kell jelennie egy hőtérkép-felvételnek a Hotjar irányítópultján. Negyedszer, a hozzájárulás utólagos visszavonásának azonnal le kell állítania a további rögzítést, le kell járatnia a cookie-kat, és törlési kérelmet kell kiváltania — a késleltetett takarítás egy megállapítás.
Az ellenőrzési nyomvonal külön is fontos. A szabályozók elvárják, hogy a kiadó bizonyítani tudja a Hotjar fiókban lévő bármely felvételről, hogy az azt generáló felhasználó érvényes hozzájárulást adott a rögzítés pillanatában. A szabványos minta az, hogy a hozzájárulás verzióját és időbélyegét egyéni attribútumként kell beágyazni a Hotjar felhasználói rekordba a hj('identify', userId, { consent_version: 'v3', consent_ts: ts }) segítségével. Ez bármely konkrét felvételt egy konkrét hozzájárulási naplóbejegyzésre nyomozhatóvá tesz, ami az EDPB által meghatározott szabvány, és amelyet a kiadóknak el kell fogadniuk, függetlenül attól, hol működnek. Egy helyesen kapuzott telepítés, párosítva alapértelmezés szerint elnyomó beviteli maszkolással és visszavonáskor aktiválódó törlési útvonallal, az, ami a Hotjart egy kutatási stack védhető részévé teszi, nem pedig megfelelőségi felelősségnek.