Hotjar 히트맵 및 세션 녹화 쿠키 동의 통합 가이드: 2026년 퍼블리셔 플레이북

Hotjar는 도구 스택에서 독특한 위치를 차지합니다. Google Analytics 같은 웹 분석 플랫폼도, Amplitude나 Mixpanel 같은 제품 분석 플랫폼도, 태그 관리자도 아닙니다. 개별 사용자가 페이지에서 무엇을 하는지 — 마우스를 어디서 움직이는지, 무엇을 클릭하는지, 어디서 스크롤하는지, 어디서 망설이는지, 세션 녹화의 경우 정확히 무엇을 입력하고 화면에서 무엇이 렌더링되었는지 — 를 기록하기 위해 존재하는 사용자 경험 연구 도구입니다. 그 세분화가 바로 제품입니다. 또한 규제 기관이 세션 재생을 행동 처리의 가장 고위험 카테고리 중 하나로 지목한 이유이며, 부주의한 Hotjar 배포가 그렇지 않으면 규정을 준수하는 웹사이트가 비준수 상태에 빠지는 가장 쉬운 방법 중 하나인 이유입니다. CNIL, Garante, EDPB 모두 세션 재생 동작을 특별히 겨냥한 지침을 발표했으며, 2026년 EDPB 쿠키 배너 태스크포스는 이를 우선순위 카테고리로 취급하고 있습니다. 좋은 소식은 Hotjar가 동의 우선 배포를 위해 이 카테고리에서 더 잘 설계된 도구 중 하나라는 것입니다 — 퍼블리셔가 실제로 존재하는 컨트롤을 사용한다면요.

Hotjar가 명시적 동의를 필요로 하는 이유

Hotjar의 수집 프로필이 중요한 모든 프레임워크에서 동의 의무를 촉발합니다. 기본 초기화 시 Hotjar 추적 스크립트는 페이지 로드 후 밀리초 내에 최소 세 개의 자사 쿠키 — _hjSessionUser_{siteId}, _hjSession_{siteId}, 그리고 일련의 억제 및 유입 소스 쿠키들 — 를 브라우저에 씁니다. 그런 다음 스크립트는 커서 좌표, 클릭 좌표, 스크롤 위치, 뷰포트 크기, 그리고 세션 녹화가 활성화된 경우 기준선 대비 차이를 계산한 전체 렌더링 DOM의 연속 스트리밍 기록을 시작합니다.

ePrivacy 지침 제5조(3)에 따라 각 쿠키는 EEA, 영국, 스위스 및 동일한 기준을 채택한 모든 관할권에서 사전, 자유롭게 제공, 구체적, 정보에 근거하고 명확한 동의가 필요한 저장 및 접근 작업입니다. GDPR에 따라 커서 흔적, IP 주소, 기기 지문 및 세션 식별자의 조합이 개인을 특정하기에 충분하기 때문에 행동 스트림은 개인 데이터 처리를 구성합니다. CCPA 및 CPRA에 따라 퍼블리셔가 Hotjar와 관련 서비스 제공자 계약을 맺지 않는 한 동일한 수집은 판매 또는 공유로 간주됩니다. Hotjar는 CCPA 준수 DPA를 통해 이를 제공하지만 통합이 올바르게 구성된 경우에만 효력을 발휘합니다. EDPB의 세션 재생 지침에 따르면 기준이 더욱 높습니다: 재생은 특정하고 합법적인 UX 연구 목적과 연결되어야 하고, 보존 기간은 최소한으로 필요한 기간이어야 하며, 데이터 주체는 녹화가 존재한다는 사실뿐만 아니라 자신의 세션이 분석가에 의해 재생될 수 있다는 사실도 고지받아야 합니다.

Hotjar가 동의 전에 수집하는 것 — 그리고 억제되어야 하는 것

가장 흔한 구현 실수는 Hotjar 자체 빠른 시작과 함께 제공되는 것입니다: 추적 스크립트를 페이지 <head>에 직접 붙여넣는 것입니다. 이것은 작동하지만 쿠키 배너가 렌더링되기 전에 Hotjar를 로드하므로, 사용자가 나중에 무엇을 결정하든 관계없이 첫 번째 페이지 뷰에서 쿠키가 설정되고 행동 녹화가 시작됩니다. 이 패턴에 대해 판결을 내린 모든 EU 규제 기관은 동일하게 판결했습니다: 동의 전에 설정된 쿠키는 불법이며 퍼블리셔가 책임을 집니다.

따라서 준수하는 통합은 관련 동의 카테고리가 부여될 때까지 Hotjar 스크립트가 전혀 로드되지 않도록 해야 합니다. 이를 위한 가장 깔끔한 방법은 사용자가 분석 또는 제품 연구 카테고리에 옵트인한 후에만 CMP가 삽입하는 동의 제어 <script> 태그 내에 Hotjar 스니펫을 래핑하는 것입니다. 스크립트가 태그 관리자를 통해 로드되는 경우, 동등한 방법은 트리거를 모든 페이지가 아닌 동의 부여 이벤트로 설정하는 것입니다. Hotjar의 자체 문서는 이제 이 패턴을 명시적으로 권장하며, 플랫폼은 스크립트가 존재해야 하지만 동의가 기록될 때까지 휴면 상태를 유지해야 하는 경우를 위해 hj('consent', 'grant') API를 노출합니다.

Hotjar가 작성하는 쿠키 및 스토리지

Hotjar Tracking Code 6.x는 다음 식별자들을 작성하며, 모두 필수적이지 않고 동의가 필요합니다: 사용자 식별자를 포함하는 365일 만료의 _hjSessionUser_{siteId}, 세션 식별자를 포함하는 30분 만료의 _hjSession_{siteId}, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress, 그리고 설문이나 피드백 위젯이 활성화된 경우의 다수의 캠페인 귀속 쿠키. 세션 녹화 자체는 Hotjar 서버에 저장되며 세션 식별자에 연결됩니다 — 따라서 동의를 철회하면 Hotjar API 또는 제품 내 사용자 삭제 흐름을 통해 삭제 요청도 신호해야 합니다.

Hotjar를 동의 프레임워크에 매핑하기

Hotjar는 IAB TCF 또는 IAB Global Privacy Platform과 기본적으로 통합되지 않습니다. 광고 기술 공급업체가 아니며 그렇게 설계된 적도 없습니다. 그러나 analytics_storage 신호를 통해 Google Consent Mode v2와 통합되며, 모든 CMP가 바인딩할 수 있는 자체 기본 동의 API를 노출합니다. 규제 기관의 검토를 통과하는 패턴은 각 Hotjar 기능을 별도의 동의 게이트로 취급합니다.

작동하는 통합 패턴

참조 배포는 네 가지 부분으로 구성됩니다: 실시간 동의 변경 이벤트를 노출하는 CMP, 분석 동의가 발화된 후에만 Hotjar 스니펫을 삽입하는 지연 스크립트 로더, 별도 게이트가 열릴 때까지 기본적으로 녹화를 끄는 세션 녹화 억제 레이어, 그리고 동의가 부여된 경우에도 규제 기관이 민감하다고 간주하는 필드를 강제로 억제하는 입력 마스킹 구성. 네 번째 포인트는 종종 간과됩니다: 입력 마스킹은 동의의 대체물이 아니지만, 합법적인 연구를 위해 동의가 부여되고 사용자가 우연히 자유 텍스트 필드에 민감한 데이터를 붙여넣는 경우의 재앙의 대체물입니다.

웹 구현

웹에서 가장 깔끔한 패턴은 CMP의 동의 변경 이벤트를 구독하고, 분석 목적이 false에서 true로 전환될 때 조건부로 Hotjar 스니펫을 삽입하는 것입니다. async 속성이 설정된 상태로 추적 코드를 삽입하기 위해 document.createElement('script')를 사용하고, 서버 검증된 사용자 식별자가 존재하는 경우에만 hj('identify', userId, properties)를 호출하는 onload 핸들러를 첨부합니다. 동의가 철회되면 hj('consent', 'revoke')를 호출하고, document.cookie를 통해 모든 _hj 쿠키를 만료시키며, 사용자의 이전 세션 녹화에 대해 Hotjar Data API를 통해 삭제 요청을 발송합니다. Hotjar를 배너와 동일한 렌더 패스에서 게으르게 초기화하지 마세요 — 스크립트는 명시적 부여를 기다려야 하며, 스크립트가 발화되기 전에 타임스탬프와 동의 문자열과 함께 부여가 기록되어야 합니다.

입력 마스킹 및 민감한 데이터 억제

Hotjar의 세션 레코더는 세 가지 마스킹 모드와 함께 제공됩니다: 비밀번호 필드와 data-hj-suppress 속성으로 표시된 모든 요소에 대한 기본값인 Suppress mode; 명시적으로 옵트인된 입력만 기록되는 Whitelist mode; 키 입력이 별표로 기록되는 Mask mode. GDPR의 특수 카테고리 규칙과 CCPA의 민감한 개인 정보 정의에 따라, 건강 정보, 재정 세부 사항, 정부 식별자, 생체 데이터, 정확한 위치, 또는 개인 통신 내용을 캡처할 수 있는 모든 필드는 사용자의 동의 상태에 관계없이 Suppress mode를 사용해야 합니다. 필드 수준이 아닌 폼 수준에서 data-hj-suppress를 설정하는 것이 가장 안전한 패턴입니다 — 개발자가 나중에 개별적으로 표시하는 것을 잊은 새 필드를 추가하더라도 전체 폼을 억제합니다.

단일 페이지 애플리케이션 및 라우트 변경

SPA (React, Vue, Angular, Svelte)의 경우 Hotjar 스니펫은 기본적으로 초기 페이지 로드에만 바인딩됩니다. 가상 페이지 전환을 추적하려면 부트스트랩이 모든 라우트 변경 시 hj('stateChange', newPath)를 호출해야 합니다. 이 호출은 그 시점에 Hotjar가 보유한 동의 상태를 존중하므로 CMP 게이팅 로직을 중복시킬 필요가 없습니다 — 하지만 페이지 뷰 사이에 동의가 철회된 경우 라우트 변경 자체가 새로운 스크립트 로드를 트리거해서는 안 됩니다.

통합 검증

검증 단계는 규제 기관이 확인하고 퍼블리셔가 가장 자주 건너뛰는 것입니다. 올바르게 통합된 Hotjar 배포는 순서대로 네 가지 테스트를 통과해야 합니다. 첫째, 배너는 표시되지만 선택이 없는 새 브라우저 세션은 static.hotjar.com, script.hotjar.com 또는 vars.hotjar.com에 대한 요청이 0건이고, document.cookie에 _hj 쿠키가 0개여야 합니다. 둘째, 분석을 거부하면 해당 상태가 유지되어야 합니다 — 스크립트 로드 없음, 녹화 없음, 쿠키 없음. 셋째, 분석을 수락하면 스크립트 로드와 올바른 SameSite 속성을 가진 예상되는 _hjSessionUser_hjSession 쿠키가 생성되어야 하며, 히트맵 녹화가 5분 내에 Hotjar 대시보드에 나타나야 합니다. 넷째, 이후 동의를 철회하면 즉시 추가 녹화를 중지하고 쿠키를 만료시키며 삭제 요청을 트리거해야 합니다 — 지연된 정리는 위반입니다.

감사 추적은 별도로 중요합니다. 규제 기관은 퍼블리셔가 Hotjar 계정의 특정 녹화에 대해 그것을 생성한 사용자가 캡처 시점에 유효한 동의를 제공했음을 증명할 수 있기를 기대합니다. 표준 패턴은 hj('identify', userId, { consent_version: 'v3', consent_ts: ts })를 통해 Hotjar 사용자 레코드에 동의 버전과 타임스탬프를 커스텀 속성으로 임베딩하는 것입니다. 이를 통해 특정 녹화를 특정 동의 로그 항목까지 추적할 수 있으며, 이것이 EDPB가 설정한 기준이자 퍼블리셔가 운영 위치에 관계없이 채택해야 할 기준입니다. 올바르게 게이트된 배포는 기본적으로 억제하는 입력 마스킹과 철회 시 활성화되는 삭제 경로와 짝을 이루어 Hotjar를 준수 의무가 아닌 연구 스택의 방어 가능한 부분으로 만듭니다.

← 블로그 전체 읽기 →