Ръководство за интегриране на съгласие за бисквитки при топлинни карти и записи на сесии в Hotjar: Наръчник 2026 за издатели
Hotjar заема уникално място в набора от инструменти. Той не е платформа за уеб анализ като Google Analytics, не е платформа за продуктов анализ като Amplitude или Mixpanel и не е мениджър на тагове. Той е инструмент за изследване на потребителското изживяване, създаден специално за записване на това, което отделните потребители правят на дадена страница — накъде движат мишката, върху какво кликват, накъде скролират, къде се колебаят и, в случай на запис на сесия, точно какво са написали и какво са видели изобразено на екрана. Тази прецизност е самият продукт. Именно поради нея регулаторите са определили повторното изпълнение на сесии като една от категориите с най-висок риск при поведенческата обработка и именно затова небрежното внедряване на Hotjar е един от най-лесните начини за иначе съответстващ уебсайт да излезе извън съответствие. CNIL, Garante и EDPB са публикували насоки, насочени специално към поведението при повторно изпълнение на сесии, а работната група на EDPB за банери с бисквитки за 2026 г. го третира като приоритетна категория. Добрата новина е, че Hotjar е един от инструментите с по-добро инженерно изпълнение в тази категория за внедряване с приоритет на съгласието — при условие, че издателят действително използва съществуващите контроли.
Защо Hotjar изисква изрично съгласие
Профилът на събиране на данни от Hotjar е причината за задълженията за съгласие в рамките на всяка значима правна система. При инициализация по подразбиране скриптът за проследяване на Hotjar записва поне три бисквитки от първа страна — _hjSessionUser_{siteId}, _hjSession_{siteId} и поредица от бисквитки за потискане и входящ източник — в браузъра в рамките на милисекунди след зареждането на страницата. След това скриптът започва да предава непрекъснат запис на координатите на курсора, координатите на кликванията, позицията на скролирането, размера на видимата област и, когато е активиран записът на сесията, пълния изобразен DOM, сравнен с базова линия.
Съгласно член 5(3) от Директивата за ePrivacy, всяка от тези бисквитки е операция за съхранение и достъп, която изисква предварително, свободно дадено, специфично, информирано и недвусмислено съгласие в ЕИП, Обединеното кралство, Швейцария и всяка юрисдикция, която е приела същия стандарт. Съгласно GDPR потокът от поведенчески данни представлява обработка на лични данни, тъй като комбинацията от следата на курсора, IP адреса, цифровия отпечатък на устройството и идентификатора на сесията е достатъчна за идентифициране на отделно лице. Съгласно CCPA и CPRA същото събиране се счита за продажба или споделяне, освен ако издателят няма съответния договор за доставчик на услуги с Hotjar — който Hotjar предлага чрез своето DPA, съответстващо с CCPA, но то влиза в сила едва когато интегрирането е конфигурирано правилно. Съгласно насоките на EDPB за повторно изпълнение на сесии стандартът е още по-висок: повторното изпълнение трябва да е обвързано с конкретна, легитимна цел за UX изследвания, периодът на съхранение трябва да е минимално необходимият, а субектът на данни трябва да бъде информиран не само за съществуването на записите, но и за това, че неговата собствена сесия може да бъде повторно изиграна от анализатор.
Какво събира Hotjar преди съгласие — и какво трябва да бъде потиснато
Най-честата грешка при внедряването е тази, която се доставя с бързото стартиране на Hotjar: поставяне на скрипта за проследяване директно в <head> на страницата. Това работи, но зарежда Hotjar преди дори да е изобразен банерът с бисквитките, което означава, че бисквитките се задават и записването на поведение започва при самото първо показване на страницата — независимо от това, което потребителят реши по-късно. Всеки регулатор в ЕС, който се е произнесъл по този модел, е стигнал до едно и също заключение: бисквитките, зададени преди съгласие, са незаконни, а издателят носи отговорност.
Следователно едно съответстващо интегриране трябва изцяло да предотврати зареждането на скрипта на Hotjar, докато не бъде предоставена съответната категория съгласие. Най-чистият начин за постигането на това е да се обвие откъсът на Hotjar в таг <script>, ограничен от съгласие, който CMP инжектира едва след като потребителят се е съгласил с категорията аналитика или продуктово изследване. Ако скриптът се зарежда чрез мениджър на тагове, еквивалентът е да се зададе тригерът на събитие за предоставено съгласие, а не на All Pages. Собствената документация на Hotjar вече препоръчва изрично този модел, а платформата предлага API hj('consent', 'grant') за случаите, когато скриптът трябва да присъства, но да остане неактивен, докато не бъде записано съгласие.
Бисквитки и съхранение, записвани от Hotjar
Hotjar Tracking Code 6.x записва следните идентификатори, всички от които са несъществени и изискват съгласие: _hjSessionUser_{siteId} с давност 365 дни, съдържащ идентификатора на потребителя, _hjSession_{siteId} с давност 30 минути, съдържащ идентификатора на сесията, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress и редица бисквитки за атрибуция на кампании, когато са активни анкети или уиджети за обратна връзка. Самите записи на сесии се съхраняват на сървърите на 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 и всяко немаскирано поле, а изричното включване на ниво предпочитания — а не общото съгласие за аналитика — е защитимата позиция съгласно насоките на EDPB за повторно изпълнение на сесии.
- Анкетите и уиджетите за обратна връзка могат да работят под същата порта за съгласие като записа на сесия, когато събират въвеждане на свободен текст, или под портата за аналитика, когато събират само данни за оценки.
- Фунелите и проследяването на конверсии са обвързани с портата за аналитика; ако някакъв идентификатор на потребителя се разпространява към CRM или рекламна платформа, се прилага и маркетинговата порта.
Моделът на интегриране, който работи
Референтното внедряване има четири части: CMP, предлагащ събитие за промяна на съгласието в реално време; отложен зареждач на скрипт, инжектиращ откъса на Hotjar само след като се задейства съгласието за аналитика; слой за потискане на записа на сесия, задаващ записването по подразбиране като изключено, докато не се отвори отделна порта; и конфигурация за маскиране на въвеждане, твърдо потискаща всяко поле, което регулатор би счел за чувствително, дори когато е дадено съгласие. Четвъртата точка често се пренебрегва: маскирането на въвеждане не е заместител на съгласието, но е заместител на катастрофата, когато съгласие е дадено за законно изследване и потребителят случайно постави чувствителни данни в поле за свободен текст.
Уеб имплементация
В уеб пространството най-чистият модел е да се абонирате за събитието за промяна на съгласието на CMP, след което условно да инжектирате откъса на Hotjar, когато целта за аналитика премине от false на true. Използвайте document.createElement('script') за инжектиране на кода за проследяване с зададен атрибут async и прикачете обработчик на onload, който извиква hj('identify', userId, properties) само ако съществува идентификатор на потребителя, валидиран на сървъра. Когато съгласието бъде оттеглено, извикайте hj('consent', 'revoke'), изтрийте всички бисквитки _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 по подразбиране се свързва само с първоначалното зареждане на страницата. За проследяване на виртуални преходи между страници, стартирането трябва да извика hj('stateChange', newPath) при всяка промяна на маршрута. Това извикване зачита статуса на съгласие, поддържан от Hotjar в момента, така че логиката за ограничаване на CMP не трябва да се дублира — но промяната на маршрута сама по себе си не трябва да предизвика ново зареждане на скрипта, ако съгласието е оттеглено между прегледите на страницата.
Валидиране на интегрирането
Стъпката за валидиране е тази, която регулаторите проверяват и която издателите най-често пропускат. Правилно интегрираното внедряване на Hotjar трябва да премине четири теста по ред. Първо, нова браузърна сесия с показан банер, но без направен избор, трябва да генерира нула заявки към static.hotjar.com, script.hotjar.com или vars.hotjar.com и нула бисквитки _hj в document.cookie. Второ, отказът от аналитика трябва да запази това състояние — без зареждане на скрипт, без запис, без бисквитки. Трето, приемането на аналитика трябва да доведе до зареждане на скрипт и очакваните бисквитки _hjSessionUser и _hjSession с правилни атрибути SameSite, а запис на топлинна карта трябва да се появи в таблото на Hotjar в рамките на пет минути. Четвърто, оттеглянето на съгласие след факта трябва незабавно да спре по-нататъшното записване, да изтрие бисквитките и да задейства заявка за изтриване — забавеното почистване е нарушение.
Одитната следа е от отделно значение. Регулаторите очакват от издателя да може да докаже, за всеки даден запис в акаунта на Hotjar, че потребителят, който го е генерирал, е дал валидно съгласие в момента на заснемането. Стандартният модел е да се вгради версията на съгласието и времевият печат като персонализиран атрибут в записа на потребителя в Hotjar чрез hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). Това прави всеки конкретен запис проследим до конкретен запис в журнала за съгласие — това е стандартът, зададен от EDPB, и стандартът, който издателите трябва да приемат независимо от мястото на дейността им. Правилно ограниченото внедряване, съчетано с маскиране на въвеждане, потискащо по подразбиране, и с път за изтриване, активиращ се при оттегляне, е това, което прави Hotjar защитима част от изследователския стек, а не задължение за съответствие.