Gabay sa Pagsasama ng Cookie Consent para sa Hotjar Heatmap at Session Recording: 2026 Playbook para sa mga Publisher
Ang Hotjar ay may natatanging lugar sa stack ng mga tool. Hindi ito isang web analytics platform tulad ng Google Analytics, hindi isang product analytics platform tulad ng Amplitude o Mixpanel, at hindi isang tag manager. Ito ay isang tool sa pananaliksik ng karanasan ng gumagamit na umiiral nang partikular upang i-record kung ano ang ginagawa ng mga indibidwal na gumagamit sa isang pahina — kung saan inililipat nila ang kanilang mouse, kung ano ang ini-click nila, kung saan nag-scroll, kung saan nag-aalangan, at, sa kaso ng session recording, eksakto kung ano ang nai-type nila at nakita sa screen. Ang granularity na iyon ang produkto. Ito rin ang dahilan kung bakit tininutukoy ng mga regulator ang session replay bilang isa sa mga kategorya ng pinakamalaking panganib ng behavioral processing, at kung bakit ang isang walang ingat na deployment ng Hotjar ay isa sa mga pinakamadaling paraan para mawala ang pagsunod ng isang website na maayos na sumusunod. Ang CNIL, ang Garante, at ang EDPB ay naglabas lahat ng gabay na partikular na nagta-target sa gawi ng session replay, at ang 2026 EDPB cookie banner task force ay itinuturing ito bilang isang priority na kategorya. Ang magandang balita ay ang Hotjar ay isa sa mas mahusay na engineered na mga tool sa kategorya para sa consent-first deployment — basta ang publisher ay aktwal na gumagamit ng mga kontrol na mayroon.
Bakit nangangailangan ng malinaw na pahintulot ang Hotjar
Ang profile ng koleksyon ng Hotjar ang nagti-trigger ng mga obligasyon sa pahintulot sa bawat framework na mahalaga. Sa default na initialization, ang tracking script ng Hotjar ay nagsusulat ng kahit tatlong first-party na cookies — _hjSessionUser_{siteId}, _hjSession_{siteId}, at isang serye ng mga suppression at incoming-source na cookies — sa browser sa loob ng millisecond pagkatapos ng page load. Ang script ay nagsisimulang mag-stream ng tuluy-tuloy na talaan ng mga cursor coordinate, click coordinate, scroll position, viewport size, at, kapag naka-enable ang session recording, ang buong rendered DOM na na-diff laban sa isang baseline.
Sa ilalim ng Artikulo 5(3) ng ePrivacy Directive, ang bawat isa sa mga cookies na iyon ay isang storage-and-access na operasyon na nangangailangan ng nakaraang pahintulot na ibinibigay nang malaya, tiyak, may kaalaman, at walang kalabuan sa EEA, UK, Switzerland, at anumang hurisdiksyon na nag-import ng parehong pamantayan. Sa ilalim ng GDPR, ang behavioral stream ay bumubuo ng pagproseso ng personal na data dahil ang kumbinasyon ng cursor trace, IP address, device fingerprint, at session identifier ay sapat upang matukoy ang isang indibidwal. Sa ilalim ng CCPA at CPRA, ang parehong koleksyon ay binibilang bilang pagbebenta o pagbabahagi maliban kung ang publisher ay may kaugnay na service-provider na kontrata sa Hotjar — na inaalok ng Hotjar sa pamamagitan ng CCPA-compliant na DPA nito, ngunit nagkakabisa lamang kapag ang pagsasama ay naka-configure nang tama. Sa ilalim ng gabay sa session replay ng EDPB, ang bar ay mas mataas pa: ang replay ay dapat nakatali sa isang tiyak, lehitimong layunin ng pananaliksik ng UX, ang retention period ay dapat na pinakamababang kinakailangan, at ang data subject ay dapat na abisuhan hindi lamang na mayroon mga recording kundi pati na rin na ang kanilang sariling session ay maaaring i-replay ng isang analyst.
Ano ang kinokolekta ng Hotjar bago ang pahintulot — at ano ang dapat na sugpuin
Ang pinakakaraniwang pagkakamali sa implementasyon ay ang isa na kasama ng quickstart ng Hotjar: pag-paste ng tracking script nang direkta sa <head> ng pahina. Gumagana ito, ngunit nilo-load ang Hotjar bago pa man ma-render ang cookie banner, na nangangahulugang ang mga cookies ay naitakda at ang behavioral recording ay nagsisimula sa pinaka-unang page view — anuman ang maging desisyon ng gumagamit sa bandang huli. Bawat EU regulator na nagdesisyon sa pattern na ito ay nagdesisyon sa parehong paraan: ang mga cookies na itinakda bago ang pahintulot ay labag sa batas, at ang publisher ang may pananagutan.
Samakatuwid, ang isang compliant na pagsasama ay dapat pigilan ang pag-load ng script ng Hotjar nang tuluyan hanggang sa maibigay ang kaugnay na kategorya ng pahintulot. Ang pinakamalinis na paraan para gawin ito ay i-wrap ang Hotjar snippet sa loob ng isang consent-gated na <script> tag na ini-inject ng CMP lamang pagkatapos na mag-opt in ang gumagamit sa kategorya ng analytics o product research. Kung ang script ay na-load sa pamamagitan ng isang tag manager, ang katumbas ay ang pagtatakda ng trigger sa isang consent-granted na kaganapan sa halip na sa Lahat ng Pahina. Ang sariling dokumentasyon ng Hotjar ay nagrerekomenda na ngayon ng pattern na ito nang malinaw, at inilalantad ng platform ang isang hj('consent', 'grant') API para sa mga kaso kung saan ang script ay dapat na naroroon ngunit dapat na mananatiling dormant hanggang sa mai-record ang pahintulot.
Mga cookies at storage na isinusulat ng Hotjar
Ang Hotjar Tracking Code 6.x ay sumusulat ng mga sumusunod na identifier, lahat ay hindi-esensyal at nangangailangan ng pahintulot: _hjSessionUser_{siteId} na may 365-araw na pag-expire na naglalaman ng user identifier; _hjSession_{siteId} na may 30-minutong pag-expire na naglalaman ng session identifier; _hjFirstSeen; _hjIncludedInSessionSample_{siteId}; _hjAbsoluteSessionInProgress; at ilang campaign-attribution na cookies kapag aktibo ang mga survey o feedback widget. Ang mga session recording mismo ay iniimbak sa mga server ng Hotjar at nakatali sa session identifier — ang pag-withdraw ng pahintulot ay dapat samakatuwid ay mag-signal din ng deletion request sa pamamagitan ng API ng Hotjar o ng in-product user-deletion flow.
Pag-map ng Hotjar sa mga framework ng pahintulot
Ang Hotjar ay hindi natively na nagse-integrate sa IAB TCF o sa IAB Global Privacy Platform. Hindi ito isang ad-tech vendor at hindi kailanman sinadyang maging isa. Gayunpaman, nagse-integrate ito sa Google Consent Mode v2 sa pamamagitan ng signal na analytics_storage, at inilalantad nito ang sariling native consent API na maaaring i-bind ng sinumang CMP. Ang pattern na nakakaligtas sa pagsusuri ng isang regulator ay tinatrato ang bawat kakayahan ng Hotjar bilang isang hiwalay na consent gate.
- Mga heatmap at click map ay nagbi-bind sa layunin ng analytics o product research. Sa mga tuntunin ng TCF ito ay kadalasang layunin 8 (sukatin ang performance ng nilalaman) na sinamahan ng layunin 1 (mag-imbak at/o ma-access ang impormasyon). Para sa Consent Mode ito ay analytics_storage.
- Ang session recording ay dapat na nasa likod ng isang mas mahigpit, hiwalay na signal. Kinukuha ng recording ang rendered DOM at anumang unmasked na field, at ang isang malinaw na preferences-level na opt-in — hindi blanket analytics consent — ang mapangtanggol na postura sa ilalim ng gabay sa session replay ng EDPB.
- Mga survey at feedback widget ay maaaring tumakbo sa ilalim ng parehong consent gate bilang session recording kapag nangongolekta ng free-text na input, o sa ilalim ng analytics gate kapag nangongolekta lamang ng rating data.
- Mga funnel at conversion tracking ay nagbi-bind sa analytics gate; kung ang anumang user identifier ay ipinasa sa isang CRM o ad platform, nalalapat din ang marketing gate.
Ang pattern ng pagsasama na gumagana
Ang reference deployment ay may apat na bahagi: isang CMP na naglalantad ng real-time na consent change event, isang deferred script loader na nag-iinject lamang ng Hotjar snippet pagkatapos mag-fire ng analytics consent, isang session-recording suppression layer na nagde-default ng recording sa off hanggang sa mabuksan ang isang hiwalay na gate, at isang input-masking na configuration na hard-suppresses ang anumang field na itinuturing ng regulator na sensitibo kahit na naibigay na ang pahintulot. Ang ikaapat na punto ay madalas na napapabayaan: ang input masking ay hindi kapalit ng pahintulot, ngunit ito ay kapalit ng sakuna kapag ang pahintulot ay ibinigay para sa lehitimong pananaliksik at ang isang gumagamit ay nangyayaring i-paste ang sensitibong data sa isang free-text na field.
Implementasyon sa web
Sa web, ang pinakamalinis na pattern ay mag-subscribe sa consent change event ng CMP, pagkatapos ay conditionally inject ang Hotjar snippet kapag ang layunin ng analytics ay mag-flip mula false hanggang true. Gamitin ang document.createElement('script') upang i-inject ang tracking code na may nakatakdang attribute na async, at mag-attach ng onload handler na tumatawag ng hj('identify', userId, properties) lamang kung mayroon server-validated na user identifier. Kapag na-withdraw ang pahintulot, tumawag ng hj('consent', 'revoke'), i-expire ang lahat ng _hj na cookies sa pamamagitan ng document.cookie, at mag-dispatch ng deletion request sa pamamagitan ng Hotjar Data API para sa mga nakaraang session recording ng gumagamit. Huwag tamad na i-initialize ang Hotjar sa parehong render pass ng banner — ang script ay dapat maghintay ng malinaw na grant, at ang grant ay dapat na mai-record na may timestamp at consent string bago pa man mag-fire ang script.
Input masking at suppression ng sensitibong data
Ang session recorder ng Hotjar ay may tatlong masking mode: Suppress mode, na siyang default para sa mga password field at anumang elementong minarkahan ng attribute na data-hj-suppress; Whitelist mode, kung saan ang mga explicitly opted-in na input lamang ang nire-record; at Mask mode, kung saan ang mga keystroke ay nire-record bilang asterisk. Sa ilalim ng mga espesyal na kategoryang patakaran ng GDPR at kahulugan ng sensitibong personal na impormasyon ng CCPA, anumang field na maaaring kumuha ng impormasyon sa kalusugan, detalye sa pananalapi, mga identifier ng gobyerno, biometric na data, tumpak na geolocation, o mga nilalaman ng pribadong komunikasyon ay dapat gumamit ng Suppress mode anuman ang estado ng pahintulot ng gumagamit. Ang pagtatakda ng data-hj-suppress sa antas ng form kaysa sa antas ng field ang pinakaligtas na pattern — ninu-suppress nito ang buong form kahit na magdagdag ng bagong field ang isang developer na nakakalimutang markahan nang isa-isa.
Mga single-page application at mga pagbabago ng ruta
Para sa mga SPA (React, Vue, Angular, Svelte) ang Hotjar snippet ay nagbi-bind sa unang page load lamang bilang default. Upang masubaybayan ang mga virtual na page transition, ang bootstrap ay dapat tumawag ng hj('stateChange', newPath) sa bawat pagbabago ng ruta. Ang tawag na ito ay gumagalang sa anumang estado ng pahintulot na hawak ng Hotjar sa oras na iyon, kaya ang logic ng CMP gating ay hindi kailangang i-duplicate — ngunit ang pagbabago ng ruta mismo ay hindi dapat mag-trigger ng sariwang pag-load ng script kung ang pahintulot ay na-withdraw sa pagitan ng mga page view.
Pag-validate ng pagsasama
Ang hakbang sa validation ang hinahanapan ng mga regulator at madalas na nilalaktawan ng mga publisher. Ang isang tamang na-integrate na deployment ng Hotjar ay dapat pumasa sa apat na pagsubok nang sunud-sunod. Una, ang isang sariwang browser session na may ipinakitang banner ngunit walang ginawang pagpipilian ay dapat gumawa ng zero na kahilingan sa static.hotjar.com, script.hotjar.com, o vars.hotjar.com, at zero na _hj na cookies sa document.cookie. Pangalawa, ang pagtanggi sa analytics ay dapat panatilihin ang estadong iyon — walang pag-load ng script, walang recording, walang cookies. Pangatlo, ang pagtanggap ng analytics ay dapat gumawa ng pag-load ng script at ang inaasahang _hjSessionUser at _hjSession na cookies na may tamang SameSite na mga attribute, at dapat lumabas ang isang heatmap recording sa dashboard ng Hotjar sa loob ng limang minuto. Pang-apat, ang pag-withdraw ng pahintulot pagkatapos nito ay dapat agad na ihinto ang karagdagang recording, i-expire ang mga cookies, at mag-trigger ng deletion request — ang isang naantalang cleanup ay isang natuklasan.
Ang audit trail ay mahalaga nang hiwalay. Inaasahan ng mga regulator na mapapatunayan ng publisher, para sa anumang recording sa account ng Hotjar, na ang gumagamit na lumikha nito ay nagbigay ng valid na pahintulot sa sandali ng pagkuha. Ang karaniwang pattern ay ang mag-embed ng consent version at timestamp bilang isang custom na attribute sa user record ng Hotjar sa pamamagitan ng hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). Ginagawa nitong masusubaybayan ang anumang partikular na recording pabalik sa isang partikular na entry ng consent log, na siyang pamantayang itinakda ng EDPB at ang pamantayang dapat gamitin ng mga publisher anuman ang lugar ng kanilang operasyon. Ang isang tamang gated na deployment, kasama ang input masking na nagsu-suppress bilang default at isang deletion path na ina-activate sa pag-withdraw, ang nagpapahintulot sa Hotjar na maging maaaring ipagtanggol na bahagi ng isang research stack sa halip na isang pananagutang pangkumpiyansa.