Посібник з інтеграції згоди на файли cookie для теплових карт Hotjar і запису сеансів: Гайд 2026 для видавців
Hotjar займає унікальне місце в наборі інструментів. Це не платформа веб-аналітики, як Google Analytics, не платформа аналітики продукту, як Amplitude або Mixpanel, і не менеджер тегів. Це інструмент дослідження користувацького досвіду, який існує спеціально для запису того, що роблять окремі користувачі на сторінці — куди вони переміщують мишу, що натискають, де прокручують, де вагаються, і, у випадку запису сеансів, саме те, що вони ввели та побачили відрендеренного на екрані. Ця деталізація є продуктом. Це також причина, чому регулятори виділили відтворення сеансів як одну з категорій найвищого ризику поведінкової обробки, і чому недбале розгортання Hotjar є одним із найпростіших способів для інакше сумісного веб-сайту вийти з відповідності. CNIL, Garante та EDPB — всі опублікували вказівки, спеціально спрямовані на поведінку відтворення сеансів, і робоча група EDPB з банерів cookie 2026 року розглядає це як пріоритетну категорію. Хороша новина полягає в тому, що Hotjar є одним із краще розроблених інструментів у категорії для розгортання з пріоритетом згоди — за умови, що видавець дійсно використовує наявні засоби контролю.
Чому Hotjar вимагає явної згоди
Профіль збору Hotjar — це те, що викликає зобов'язання щодо згоди в усіх важливих системах. При стандартній ініціалізації скрипт відстеження Hotjar записує щонайменше три сторонні файли cookie — _hjSessionUser_{siteId}, _hjSession_{siteId} та серію файлів cookie придушення та вхідного джерела — у браузер протягом мілісекунд після завантаження сторінки. Потім скрипт починає транслювати безперервний запис координат курсору, координат кліків, позиції прокрутки, розміру вікна перегляду та, коли запис сеансів увімкнено, повного відрендереного DOM, порівняного з базовою лінією.
Відповідно до Статті 5(3) Директиви ePrivacy, кожен із цих файлів cookie є операцією зберігання та доступу, яка вимагає попередньої, вільно наданої, конкретної, поінформованої та недвозначної згоди в ЄЕЗ, Великій Британії, Швейцарії та будь-якій юрисдикції, яка прийняла той самий стандарт. Відповідно до GDPR поведінковий потік є обробкою персональних даних, оскільки поєднання сліду курсору, IP-адреси, цифрового відбитка пристрою та ідентифікатора сеансу достатньо для ідентифікації особи. Відповідно до CCPA і CPRA той самий збір вважається продажем або обміном, якщо тільки у видавця немає відповідного договору з постачальником послуг з Hotjar — який Hotjar пропонує через свій DPA, сумісний з CCPA, але він набирає чинності лише тоді, коли інтеграція правильно налаштована. Відповідно до вказівок EDPB щодо відтворення сеансів, планка ще вища: відтворення повинно бути прив'язане до конкретної законної мети дослідження UX, термін зберігання повинен бути мінімально необхідним, а суб'єкту даних потрібно повідомити не лише про існування записів, а й про те, що їхній власний сеанс може бути відтворений аналітиком.
Що Hotjar збирає до отримання згоди — і що має бути придушено
Найпоширенішою помилкою реалізації є та, яка поставляється з власним швидким стартом Hotjar: вставлення скрипту відстеження безпосередньо в <head> сторінки. Це працює, але завантажує Hotjar ще до того, як банер файлів cookie навіть відрендериться, тобто файли cookie встановлюються та запис поведінки починається під час самого першого перегляду сторінки — незалежно від того, що пізніше вирішить користувач. Кожен регулятор ЄС, який приймав рішення щодо цієї схеми, приймав його однаково: файли cookie, встановлені до отримання згоди, є незаконними, і видавець несе відповідальність.
Тому сумісна інтеграція повинна запобігати завантаженню скрипту Hotjar взагалі до того, як відповідну категорію згоди буде надано. Найчистіший спосіб зробити це — обернути фрагмент Hotjar у тег <script>, захищений згодою, який CMP вводить лише після того, як користувач відмовиться від категорії аналітики або дослідження продукту. Якщо скрипт завантажується через менеджер тегів, еквівалент полягає в тому, щоб встановити тригер на подію надання згоди, а не на All Pages. Власна документація Hotjar тепер явно рекомендує цю схему, і платформа відкриває API hj('consent', 'grant') для випадків, коли скрипт повинен бути присутній, але залишатися бездіяльним до запису згоди.
Файли cookie та сховище, які записує Hotjar
Hotjar Tracking Code 6.x записує такі ідентифікатори, всі з яких є необов'язковими і вимагають згоди: _hjSessionUser_{siteId} зі строком дії 365 днів, що містить ідентифікатор користувача, _hjSession_{siteId} зі строком дії 30 хвилин, що містить ідентифікатор сеансу, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress і ряд файлів cookie атрибуції кампанії, коли активні опитування або віджети зворотного зв'язку. Самі записи сеансів зберігаються на серверах Hotjar та прив'язані до ідентифікатора сеансу — відкликання згоди тому також повинно сигналізувати про запит на видалення через API Hotjar або внутрішній потік видалення користувача в продукті.
Зіставлення Hotjar з системами згоди
Hotjar не інтегрується нативно з IAB TCF або IAB Global Privacy Platform. Це не постачальник рекламних технологій і ніколи не передбачався таким. Однак він інтегрується з Google Consent Mode v2 через сигнал analytics_storage і відкриває власний нативний API згоди, до якого може прив'язатись будь-який CMP. Схема, яка витримує перевірку регулятора, розглядає кожну можливість Hotjar як окремий шлюз згоди.
- Теплові карти та карти кліків прив'язуються до мети аналітики або дослідження продукту. У термінах TCF це найчастіше мета 8 (вимірювання ефективності контенту) у поєднанні з метою 1 (зберігати та/або отримувати доступ до інформації). Для Consent Mode це analytics_storage.
- Запис сеансів повинен стояти за суворішим окремим сигналом. Запис фіксує відрендерений DOM та будь-яке немасковане поле, а явний opt-in на рівні налаштувань — не масштабна аналітична згода — є обґрунтованою позицією відповідно до вказівок EDPB щодо відтворення сеансів.
- Опитування та віджети зворотного зв'язку можуть працювати під тим самим шлюзом згоди, що й запис сеансів, коли вони збирають введення у вільній формі, або під шлюзом аналітики, коли збирають лише дані оцінок.
- Воронки та відстеження конверсій прив'язуються до шлюзу аналітики; якщо будь-який ідентифікатор користувача поширюється на CRM або рекламну платформу, застосовується також маркетинговий шлюз.
Схема інтеграції, яка працює
Еталонне розгортання має чотири частини: CMP, який відкриває подію зміни згоди в реальному часі, відкладений завантажувач скриптів, який вводить фрагмент Hotjar лише після спрацювання аналітичної згоди, шар придушення запису сеансів, який за замовчуванням встановлює запис у вимкнений стан до відкриття окремого шлюзу, та конфігурацію маскування введення, яка примусово придушує будь-яке поле, яке регулятор вважатиме конфіденційним, навіть якщо згоду надано. Четвертий пункт часто ігнорується: маскування введення не є замінником згоди, але є замінником катастрофи, коли згоду надано для законних досліджень і користувач випадково вставляє конфіденційні дані у поле вільного тексту.
Веб-реалізація
У вебі найчистіша схема — підписатися на подію зміни згоди CMP, а потім умовно впровадити фрагмент Hotjar, коли мета аналітики перемикається з false на true. Використовуйте document.createElement('script') для впровадження коду відстеження з встановленим атрибутом async і прикріпіть обробник onload, який викликає hj('identify', userId, properties) лише якщо існує ідентифікатор користувача, підтверджений сервером. Коли згоду відкликано, викличте hj('consent', 'revoke'), закінчіть усі файли cookie _hj через document.cookie і надішліть запит на видалення через Hotjar Data API для попередніх записів сеансів користувача. Не ініціалізуйте Hotjar ліниво в тому самому проходженні рендерингу, що й банер — скрипт повинен чекати явного дозволу, а дозвіл повинен бути записаний з міткою часу та рядком згоди, перш ніж скрипт коли-небудь запуститься.
Маскування введення та придушення конфіденційних даних
Записувач сеансів Hotjar постачається з трьома режимами маскування: Suppress mode, який є типовим для полів паролів та будь-якого елемента, позначеного атрибутом data-hj-suppress; Whitelist mode, де записуються лише явно включені введення; та Mask mode, де натискання клавіш записуються як зірочки. Відповідно до правил спеціальних категорій GDPR і визначення CCPA щодо конфіденційної особистої інформації, будь-яке поле, яке може фіксувати медичну інформацію, фінансові деталі, урядові ідентифікатори, біометричні дані, точне геолокацію або вміст приватного спілкування, повинно використовувати Suppress mode незалежно від стану згоди користувача. Встановлення data-hj-suppress на рівні форми, а не на рівні поля, є найбезпечнішою схемою — воно придушує всю форму, навіть якщо розробник пізніше додасть нове поле, яке вони забудуть позначити окремо.
Односторінкові програми та зміни маршруту
Для SPA (React, Vue, Angular, Svelte) фрагмент Hotjar за замовчуванням прив'язується лише до початкового завантаження сторінки. Для відстеження віртуальних переходів між сторінками bootstrap повинен викликати hj('stateChange', newPath) при кожній зміні маршруту. Цей виклик поважає будь-який стан згоди, який Hotjar зберігає на той момент, тому логіку шлюзу CMP не потрібно дублювати — але зміна маршруту сама по собі не повинна ініціювати нове завантаження скрипту, якщо згоду було відкликано між переглядами сторінок.
Перевірка інтеграції
Крок перевірки — це те, що перевіряють регулятори і що видавці найчастіше пропускають. Правильно інтегроване розгортання Hotjar повинно пройти чотири тести по порядку. По-перше, новий сеанс браузера з показаним банером, але без вибору повинен давати нуль запитів до static.hotjar.com, script.hotjar.com або vars.hotjar.com і нуль файлів cookie _hj у document.cookie. По-друге, відмова від аналітики повинна зберігати цей стан — без завантаження скрипту, запису або файлів cookie. По-третє, прийняття аналітики повинне призводити до завантаження скрипту та очікуваних файлів cookie _hjSessionUser і _hjSession з правильними атрибутами SameSite, а запис теплової карти повинен з'явитися на панелі Hotjar протягом п'яти хвилин. По-четверте, відкликання згоди після факту повинно негайно зупинити подальший запис, закінчити файли cookie та ініціювати запит на видалення — відкладене очищення є знахідкою.
Слід аудиту має значення окремо. Регулятори очікують, що видавець зможе довести для будь-якого запису в обліковому записі Hotjar, що користувач, який його створив, надав дійсну згоду на момент захоплення. Стандартна схема — вбудовувати версію згоди та мітку часу як настроюваний атрибут у запис користувача Hotjar через hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). Це робить будь-який конкретний запис відстежуваним до конкретного запису журналу згоди, що є стандартом, встановленим EDPB, і стандартом, який видавці повинні приймати незалежно від того, де вони працюють. Правильно захищене розгортання у поєднанні з маскуванням введення, яке за замовчуванням придушує, та шляхом видалення, що активується при відкликанні, — це те, що робить Hotjar захищеною частиною дослідницького стеку, а не зобов'язанням щодо відповідності.