Hotjar Karstuma Karšu un Sesiju Ierakstīšanas Sīkfailu Piekrišanas Integrācijas Rokasgrāmata: 2026. Gada Izdevēju Ceļvedis
Hotjar ieņem unikālu vietu rīku stekā. Tas nav tīmekļa analītikas platforma kā Google Analytics, ne produktu analītikas platforma kā Amplitude vai Mixpanel, un ne tagu pārvaldnieks. Tas ir lietotāja pieredzes pētījumu rīks, kas pastāv īpaši tam, lai reģistrētu, ko atsevišķi lietotāji dara lapā — kur viņi pārvieto peli, ko klikšķina, kur ritina, kur vilcinās, un sesiju ierakstīšanas gadījumā — tieši ko viņi rakstīja un redzēja ekrānā. Šī detalizācija ir produkts. Tieši tāpēc regulatori ir atsevišķi izdalījuši sesiju atskaņošanu kā vienu no augstākā riska uzvedības apstrādes kategorijām un kāpēc nevērīgs Hotjar izvietojums ir viens no vieglākajiem veidiem, kā citādi atbilstīga mājaslapa var zaudēt atbilstību. CNIL, Garante un EDPB ir publicējuši norādījumus, kas īpaši vērsti uz sesiju atskaņošanas uzvedību, un 2026. gada EDPB sīkfailu bannera darba grupa to uzskata par prioritāro kategoriju. Labā ziņa ir tā, ka Hotjar ir viens no labāk izstrādātajiem rīkiem šajā kategorijā piekrišanai pirmais izvietošanai — ja vien izdevējs faktiski izmanto pastāvošās vadīklas.
Kāpēc Hotjar prasa skaidru piekrišanu
Hotjar savākšanas profils ir tas, kas aktivizē piekrišanas pienākumus visos svarīgajos regulējumos. Pēc noklusējuma inicializācijas Hotjar izsekošanas skripts ieraksta vismaz trīs pirmās puses sīkfailus — _hjSessionUser_{siteId}, _hjSession_{siteId} un virkni slāpēšanas un ienākošā avota sīkfailu — pārlūkprogrammā milisekundēs pēc lapas ielādes. Pēc tam skripts sāk straumēt nepārtrauktu kursora koordinātu, klikšķu koordinātu, ritināšanas pozīcijas, skata izmēra ierakstu un, kad sesiju ierakstīšana ir iespējota, pilnu renderēto DOM, kas salīdzināts ar atskaites punktu.
Saskaņā ar ePrivacy direktīvas 5. panta 3. punktu katrs no šiem sīkfailiem ir glabāšanas un piekļuves darbība, kas EEZ, Apvienotajā Karalistē, Šveicē un jebkurā jurisdikcijā, kas ir ieviesusi to pašu standartu, prasa iepriekšēju, brīvi sniegtu, konkrētu, informētu un nepārprotamu piekrišanu. Saskaņā ar GDPR uzvedības straume ir personas datu apstrāde, jo kursora pēdas, IP adreses, ierīces pirkstu nospieduma un sesijas identifikatora kombinācija ir pietiekama, lai identificētu personu. Saskaņā ar CCPA un CPRA tas pats savākums tiek uzskatīts par pārdošanu vai kopīgošanu, ja vien izdevējam nav atbilstošs pakalpojumu sniedzēja līgums ar Hotjar — ko Hotjar piedāvā ar savu CCPA atbilstošo DPA, bet tas stājas spēkā tikai tad, kad integrācija ir pareizi konfigurēta. Saskaņā ar EDPB sesiju atskaņošanas norādījumiem slieksnis ir vēl augstāks: atskaņošanai jābūt saistītai ar konkrētu, leģitīmu UX pētniecības mērķi, saglabāšanas periodam jābūt minimāli nepieciešamam, un datu subjekts jāinformē ne tikai par to, ka ieraksti pastāv, bet arī par to, ka viņu pašu sesiju var atskaņot analītiķis.
Ko Hotjar apkopo pirms piekrišanas — un kas jāslāpē
Visizplatītākā implementācijas kļūda ir tā, kas tiek piegādāta ar Hotjar paša ātro sākumu: izsekošanas skripta ielīmēšana tieši lapas <head>. Tas darbojas, bet ielādē Hotjar pirms sīkfailu bannera pat parādīšanas, kas nozīmē, ka sīkfaili tiek iestatīti un uzvedības ierakstīšana sākas jau pirmajā lapas skatījumā — neatkarīgi no tā, ko lietotājs vēlāk nolemj. Katrs ES regulators, kas ir spriedis par šo modeli, ir spriedis vienādi: sīkfaili, kas iestatīti pirms piekrišanas, ir pretlikumīgi, un izdevējs ir atbildīgs.
Tāpēc atbilstīgai integrācijai jānovērš Hotjar skripta ielāde vispār, līdz attiecīgā piekrišanas kategorija ir piešķirta. Tīrākais veids to izdarīt ir ietīt Hotjar fragmentu piekrišanas ietvarā iekļautā <script> tagā, ko CMP injicē tikai pēc tam, kad lietotājs ir izvēlējies analītikas vai produktu pētniecības kategoriju. Ja skripts tiek ielādēts ar tagu pārvaldnieku, ekvivalents ir iestatīt aktivizētāju uz piekrišanas piešķiršanas notikumu, nevis uz Visām lapām. Hotjar paša dokumentācija tagad skaidri iesaka šo modeli, un platforma piedāvā hj('consent', 'grant') API gadījumiem, kad skriptam jābūt klāt, bet tam jāpaliek neaktīvam, līdz piekrišana tiek reģistrēta.
Hotjar rakstītie sīkfaili un krātuve
Hotjar izsekošanas kods 6.x ieraksta šādus identifikatorus, no kuriem visi ir neobligāti un prasa piekrišanu: _hjSessionUser_{siteId} ar 365 dienu derīgumu, kas satur lietotāja identifikatoru, _hjSession_{siteId} ar 30 minūšu derīgumu, kas satur sesijas identifikatoru, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress, un vairāki kampaņas attiecinājuma sīkfaili, kad aptaujas vai atsauksmju logrīki ir aktīvi. Sesiju ieraksti paši tiek glabāti Hotjar serveros un saistīti ar sesijas identifikatoru — piekrišanas atsaukšanai arī jānosūta dzēšanas pieprasījums ar Hotjar API vai produktā iekļautā lietotāju dzēšanas plūsmu.
Hotjar kartēšana piekrišanas ietvaros
Hotjar nav dzimtenē integrēts ar IAB TCF vai IAB Global Privacy Platform. Tas nav reklāmtehnoloģiju piegādātājs un nekad nebija paredzēts tādam būt. Tomēr tas integrējas ar Google Consent Mode v2 caur analytics_storage signālu un piedāvā savu native piekrišanas API, kurai jebkurš CMP var pieslēgties. Modelis, kas iztur regulatora pārbaudi, katru Hotjar iespēju uzskata par atsevišķu piekrišanas vārteju.
- Karstuma kartes un klikšķu kartes saistās ar analītikas vai produktu pētniecības mērķi. TCF terminos tas visbiežāk ir 8. mērķis (satura veiktspējas mērīšana) kombinācijā ar 1. mērķi (informācijas glabāšana un/vai piekļuve tai). Piekrišanas režīmam tas ir analytics_storage.
- Sesiju ierakstīšanai jābūt aiz stingrāka, atsevišķa signāla. Ierakstīšana uztver renderēto DOM un visus nemaskētos laukus, un skaidra preferenču līmeņa piekrišana — nevis visaptveroša analītikas piekrišana — ir aizstāvama nostāja saskaņā ar EDPB sesiju atskaņošanas norādījumiem.
- Aptaujas un atsauksmju logrīki var darboties ar to pašu piekrišanas vārteju kā sesiju ierakstīšana, kad tie apkopo brīva teksta ievadi, vai ar analītikas vārteju, kad tie apkopo tikai vērtējuma datus.
- Piltuves un konversiju izsekošana saistās ar analītikas vārteju; ja kāds lietotāja identifikators tiek izplatīts uz CRM vai reklāmu platformu, attiecas arī mārketinga vārteja.
Integrācijas modelis, kas darbojas
Atsauces izvietojumam ir četras daļas: CMP, kas piedāvā reāllaika piekrišanas maiņas notikumu, atliktais skripta ielādētājs, kas injicē Hotjar fragmentu tikai pēc analītikas piekrišanas aktivizācijas, sesiju ierakstīšanas slāpēšanas slānis, kas pēc noklusējuma iestata ierakstīšanu uz izslēgtu, līdz tiek atvērta atsevišķa vārteja, un ievades maskēšanas konfigurācija, kas stingri slāpē visus laukus, ko regulators uzskatītu par jutīgiem, pat ja piekrišana ir piešķirta. Ceturtais punkts bieži tiek aizmirsts: ievades maskēšana nav piekrišanas aizstājējs, bet tā ir katastrofas aizstājējs, kad piekrišana ir piešķirta leģitīmiem pētījumiem un lietotājs nejauši ielīmē jutīgus datus brīvā teksta laukā.
Tīmekļa implementācija
Tīmeklī tīrākais modelis ir abonēt CMP piekrišanas maiņas notikumu, pēc tam nosacīti injicēt Hotjar fragmentu, kad analītikas mērķis pārslēdzas no nepatiess uz patiesu. Izmantojiet document.createElement('script'), lai injicētu izsekošanas kodu ar iestatītu async atribūtu, un pievienojiet onload apdarinātāju, kas izsauc hj('identify', userId, properties) tikai tad, ja pastāv servera pārbaudīts lietotāja identifikators. Kad piekrišana tiek atsaukta, izsauciet hj('consent', 'revoke'), beidziet visus _hj sīkfailus caur document.cookie un nosūtiet dzēšanas pieprasījumu caur Hotjar Data API lietotāja iepriekšējiem sesiju ierakstiem. Nelaiski inicializējiet Hotjar tajā pašā renderēšanas pasā kā banneri — skriptam jāgaida uz skaidru piešķīrumu, un piešķīrums jāreģistrē ar laikspiedolu un piekrišanas virkni pirms skripta jebkāda palaišanas.
Ievades maskēšana un jutīgu datu slāpēšana
Hotjar sesiju ierakstītājs tiek piegādāts ar trim maskēšanas režīmiem: Suppress mode, kas ir paroles lauku un jebkura elementa, kas atzīmēts ar data-hj-suppress atribūtu, noklusējums; Whitelist mode, kur tiek ierakstītas tikai skaidri izvēlētās ievades; un Mask mode, kur taustiņsitieni tiek ierakstīti kā zvaigznītes. Saskaņā ar GDPR īpašo kategoriju noteikumiem un CCPA jutīgās personiskās informācijas definīciju, jebkuram laukam, kas var uztvert veselības informāciju, finanšu detaļas, valdības identifikatorus, biometriskos datus, precīzu ģeoatrašanās vietu vai privātu saraksti, jāizmanto Suppress mode neatkarīgi no lietotāja piekrišanas stāvokļa. data-hj-suppress iestatīšana formas līmenī, nevis lauka līmenī, ir drošākais modelis — tas slāpē visu formu pat tad, ja izstrādātājs vēlāk pievieno jaunu lauku, par kuras atzīmēšanu aizmirst.
Vienas lapas lietojumprogrammas un maršruta maiņas
SPA (React, Vue, Angular, Svelte) gadījumā Hotjar fragments pēc noklusējuma piesaistās tikai sākotnējai lapas ielādei. Lai izsekotu virtuālās lapas pārejas, sāknēšanai jāizsauc hj('stateChange', newPath) pie katras maršruta maiņas. Šis izsaukums ievēro jebkuru Hotjar piekrišanas stāvokli tajā laikā, tāpēc CMP vārtsardzības loģika nav jādublicē — bet maršruta maiņai pašai nedrīkst izraisīt jaunu skripta ielādi, ja piekrišana ir atsaukta starp lapas skatījumiem.
Integrācijas validācija
Validācijas solis ir tas, ko pārbauda regulatori un ko izdevēji visbiežāk izlaiž. Pareizi integrētam Hotjar izvietojumam secīgi jāiztur četri testi. Pirmkārt, svaiga pārlūkprogrammas sesija ar parādītu banneri, bet bez izdarītas izvēles, nedrīkst radīt nevienu pieprasījumu uz static.hotjar.com, script.hotjar.com vai vars.hotjar.com un nevienu _hj sīkfailu document.cookie. Otrkārt, analītikas atteikšanai jāsaglabā šis stāvoklis — bez skripta ielādes, ierakstīšanas, sīkfailiem. Treškārt, analītikas pieņemšanai jārada skripta ielāde un gaidītie _hjSessionUser un _hjSession sīkfaili ar pareiziem SameSite atribūtiem, un Hotjar informācijas panelī piecu minūšu laikā jāparādās karstuma kartes ieraksts. Ceturtkārt, piekrišanas atsaukšanai pēc fakta nekavējoties jāpārtrauc turpmākā ierakstīšana, jābeidz sīkfaili un jāaktivizē dzēšanas pieprasījums — novēlota tīrīšana ir atradums.
Audita pēdas ir svarīgas atsevišķi. Regulatori sagaida, ka izdevējs spēj pierādīt jebkuram konkrētam Hotjar konta ierakstam, ka lietotājs, kas to radīja, bija devis derīgu piekrišanu uztveršanas brīdī. Standarta modelis ir iegult piekrišanas versiju un laikspiedolu kā pielāgotu atribūtu Hotjar lietotāja ierakstā caur hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). Tas padara jebkuru konkrētu ierakstu izsekojamu līdz konkrētam piekrišanas žurnāla ierakstam, kas ir EDPB noteiktais standarts un standarts, ko izdevējiem jāpieņem neatkarīgi no tā, kur viņi darbojas. Pareizi norobežots izvietojums kopā ar ievades maskēšanu, kas pēc noklusējuma slāpē, un dzēšanas ceļu, kas aktivizējas atsaukšanas gadījumā, ir tas, kas padara Hotjar par aizstāvamu pētījumu steka daļu, nevis atbilstības saistību.