راهنمای یکپارچه‌سازی رضایت کوکی نقشه حرارتی و ضبط جلسه Hotjar: کتاب راهنمای ۲۰۲۶ برای ناشران
Hotjar جایگاه منحصربه‌فردی در پشته ابزارها دارد. نه یک پلتفرم تحلیل وب مانند Google Analytics است، نه یک پلتفرم تحلیل محصول مانند Amplitude یا Mixpanel، و نه یک مدیر برچسب. این یک ابزار تحقیق تجربه کاربری است که به‌طور خاص برای ثبت آنچه کاربران فردی در یک صفحه انجام می‌دهند وجود دارد — کجا ماوس خود را حرکت می‌دهند، روی چه چیزی کلیک می‌کنند، به کجا اسکرول می‌کنند، کجا مکث می‌کنند، و در مورد ضبط جلسه، دقیقاً چه تایپ کردند و چه چیزی روی صفحه دیدند. این دقت، خود محصول است. همین دلیل است که تنظیم‌کنندگان بازپخش جلسه را به عنوان یکی از پرخطرترین دسته‌بندی‌های پردازش رفتاری معرفی کرده‌اند، و یک استقرار بی‌احتیاط Hotjar یکی از ساده‌ترین راه‌ها برای خروج از انطباق یک وب‌سایت است. CNIL، Garante و EDPB همگی راهنماهایی منتشر کرده‌اند که به‌طور خاص رفتار بازپخش جلسه را هدف قرار می‌دهند، و کارگروه بنر کوکی EDPB در سال ۲۰۲۶ آن را به عنوان یک دسته اولویت‌دار در نظر می‌گیرد. خبر خوب این است که Hotjar یکی از ابزارهای بهتر مهندسی‌شده در این دسته برای استقرار اول-رضایت است — به شرط آنکه ناشر واقعاً از کنترل‌هایی که وجود دارند استفاده کند.
چرا Hotjar به رضایت صریح نیاز دارد
پروفایل جمع‌آوری Hotjar چیزی است که تعهدات رضایت را در هر چارچوب مهمی فعال می‌کند. در یک راه‌اندازی پیش‌فرض، اسکریپت ردیابی Hotjar حداقل سه کوکی طرف اول می‌نویسد — _hjSessionUser_{siteId}، _hjSession_{siteId} و مجموعه‌ای از کوکی‌های سرکوب و منبع ورودی — در مرورگر در عرض میلی‌ثانیه‌ها پس از بارگذاری صفحه. سپس اسکریپت شروع به پخش جریانی یک رکورد مداوم از مختصات مکان‌نما، مختصات کلیک، موقعیت اسکرول، اندازه ویوپورت و، وقتی ضبط جلسه فعال است، DOM کامل رندرشده در مقابل یک خط پایه می‌کند.
تحت ماده ۵(۳) دستورالعمل ePrivacy، هر یک از این کوکی‌ها یک عملیات ذخیره‌سازی و دسترسی است که نیاز به رضایت قبلی، آزادانه داده‌شده، خاص، آگاهانه و بدون ابهام در EEA، انگلستان، سوئیس و هر حوزه قضایی که همان استاندارد را وارد کرده دارد. تحت GDPR، جریان رفتاری پردازش داده‌های شخصی را تشکیل می‌دهد زیرا ترکیب ردپای مکان‌نما، آدرس IP، اثر انگشت دستگاه و شناسه جلسه برای شناسایی یک فرد کافی است. تحت CCPA و CPRA، همان مجموعه به عنوان فروش یا اشتراک‌گذاری محاسبه می‌شود مگر اینکه ناشر قرارداد ارائه‌دهنده خدمات مربوطه را با Hotjar داشته باشد — که Hotjar از طریق DPA سازگار با CCPA خود ارائه می‌دهد، اما تنها زمانی اثر می‌کند که یکپارچه‌سازی به‌درستی پیکربندی شده باشد. تحت راهنمای بازپخش جلسه EDPB، سطح انتظار بالاتر است: بازپخش باید به یک هدف تحقیقات UX خاص و مشروع مرتبط باشد، دوره نگهداری باید حداقل لازم باشد، و موضوع داده باید نه تنها از وجود ضبط‌ها، بلکه از اینکه جلسه خودشان ممکن است توسط یک تحلیلگر بازپخش شود آگاه شود.
آنچه Hotjar قبل از رضایت جمع‌آوری می‌کند — و آنچه باید سرکوب شود
رایج‌ترین اشتباه پیاده‌سازی همان است که با راه‌اندازی سریع خود Hotjar ارائه می‌شود: چسباندن اسکریپت ردیابی مستقیماً در <head> صفحه. این کار می‌کند، اما Hotjar را قبل از اینکه بنر کوکی حتی رندر شده باشد بارگذاری می‌کند، به این معنی که کوکی‌ها تنظیم می‌شوند و ضبط رفتاری در همان اولین بازدید صفحه آغاز می‌شود — صرف نظر از اینکه کاربر بعداً چه تصمیمی می‌گیرد. هر تنظیم‌کننده‌ای از اتحادیه اروپا که درباره این الگو حکم داده است، به همان شکل حکم داده است: کوکی‌های تنظیم‌شده قبل از رضایت غیرقانونی هستند و ناشر مسئول است.
بنابراین یک یکپارچه‌سازی منطبق باید از بارگذاری اسکریپت Hotjar به طور کلی جلوگیری کند تا زمانی که دسته رضایت مربوطه اعطا شده باشد. پاک‌ترین راه انجام این کار بسته‌بندی قطعه Hotjar در داخل یک تگ <script> دروازه‌بندی رضایت است که CMP آن را تنها پس از اینکه کاربر در دسته تحلیل یا تحقیق محصول شرکت کرده، تزریق می‌کند. اگر اسکریپت از طریق یک مدیر برچسب بارگذاری شود، معادل آن تنظیم trigger روی یک رویداد رضایت-اعطاشده به جای همه صفحات است. مستندات خود Hotjar اکنون این الگو را به‌صراحت توصیه می‌کند، و این پلتفرم یک API hj('consent', 'grant') برای مواردی که اسکریپت باید حاضر باشد اما باید تا ثبت رضایت غیرفعال بماند، ارائه می‌دهد.
کوکی‌ها و فضای ذخیره‌سازی که Hotjar می‌نویسد
Hotjar Tracking Code 6.x شناسه‌های زیر را می‌نویسد که همه غیرضروری هستند و نیاز به رضایت دارند: _hjSessionUser_{siteId} با انقضای ۳۶۵ روزه حاوی شناسه کاربر؛ _hjSession_{siteId} با انقضای ۳۰ دقیقه‌ای حاوی شناسه جلسه؛ _hjFirstSeen؛ _hjIncludedInSessionSample_{siteId}؛ _hjAbsoluteSessionInProgress؛ و تعدادی کوکی انتساب کمپین هنگامی که نظرسنجی‌ها یا ابزارک‌های بازخورد فعال هستند. خود ضبط جلسات در سرورهای Hotjar ذخیره می‌شوند و با شناسه جلسه کلیدگذاری می‌شوند — پس عقب‌نشینی رضایت باید همچنین یک درخواست حذف از طریق API Hotjar یا جریان حذف کاربر درون محصول را نشانه‌گذاری کند.
نگاشت Hotjar به چارچوب‌های رضایت
Hotjar به‌صورت بومی با IAB TCF یا IAB Global Privacy Platform یکپارچه نمی‌شود. این یک فروشنده ad-tech نیست و هرگز قرار نبود باشد. با این حال، با Google Consent Mode v2 از طریق سیگنال analytics_storage یکپارچه می‌شود و API رضایت بومی خود را که هر CMP می‌تواند به آن متصل شود، ارائه می‌دهد. الگویی که بررسی یک تنظیم‌کننده را تحمل می‌کند، هر قابلیت Hotjar را به عنوان یک دروازه رضایت جداگانه در نظر می‌گیرد.
- نقشه‌های حرارتی و نقشه‌های کلیک به هدف تحلیل یا تحقیق محصول متصل می‌شوند. در اصطلاح TCF این معمولاً هدف ۸ (اندازه‌گیری عملکرد محتوا) در ترکیب با هدف ۱ (ذخیره و/یا دسترسی به اطلاعات) است. برای Consent Mode این analytics_storage است.
- ضبط جلسه باید پشت یک سیگنال سخت‌گیرانه‌تر و جداگانه قرار گیرد. ضبط DOM رندرشده و هر فیلد بدون ماسک را ثبت می‌کند، و یک انتخاب صریح در سطح ترجیحات — نه رضایت کلی تحلیل — موضع قابل دفاع تحت راهنمای بازپخش جلسه EDPB است.
- نظرسنجی‌ها و ابزارک‌های بازخورد می‌توانند تحت همان دروازه رضایت مانند ضبط جلسه اجرا شوند وقتی ورودی متن آزاد جمع‌آوری می‌کنند، یا تحت دروازه تحلیل وقتی فقط داده رتبه‌بندی جمع‌آوری می‌کنند.
- قیف‌ها و ردیابی تبدیل به دروازه تحلیل متصل می‌شوند؛ اگر هر شناسه کاربری به یک CRM یا پلتفرم تبلیغاتی منتقل شود، دروازه بازاریابی نیز اعمال می‌شود.
الگوی یکپارچه‌سازی که کار می‌کند
استقرار مرجع چهار بخش دارد: یک CMP که یک رویداد تغییر رضایت در زمان واقعی ارائه می‌دهد؛ یک بارگذار اسکریپت معوق که تنها پس از اجرای رضایت تحلیل، قطعه Hotjar را تزریق می‌کند؛ یک لایه سرکوب ضبط جلسه که ضبط را به‌طور پیش‌فرض خاموش می‌کند تا دروازه جداگانه‌ای باز شود؛ و یک پیکربندی پوشش‌دهی ورودی که هر فیلدی را که تنظیم‌کننده‌ای حساس می‌داند به‌سختی سرکوب می‌کند حتی زمانی که رضایت اعطا شده. نقطه چهارم اغلب نادیده گرفته می‌شود: پوشش‌دهی ورودی جایگزین رضایت نیست، اما جایگزین فاجعه است وقتی رضایت برای تحقیق مشروع اعطا شده و یک کاربر تصادفاً داده حساس را در یک فیلد متن آزاد جای‌گذاری می‌کند.
پیاده‌سازی وب
در وب، پاک‌ترین الگو این است که در رویداد تغییر رضایت CMP مشترک شوید، سپس قطعه Hotjar را به‌صورت شرطی تزریق کنید وقتی هدف تحلیل از false به true تبدیل می‌شود. از document.createElement('script') برای تزریق کد ردیابی با ویژگی async تنظیم‌شده استفاده کنید، و یک handler onload اضافه کنید که hj('identify', userId, properties) را تنها اگر شناسه کاربر اعتبارسنجی‌شده توسط سرور وجود داشته باشد فراخوانی کند. وقتی رضایت عقب‌نشینی می‌کند، hj('consent', 'revoke') را فراخوانی کنید، تمام کوکی‌های _hj را از طریق document.cookie منقضی کنید، و یک درخواست حذف از طریق Hotjar Data API برای ضبط‌های جلسه قبلی کاربر ارسال کنید. Hotjar را در همان پاس رندر بنر به‌طور تنبلانه راه‌اندازی نکنید — اسکریپت باید منتظر یک اعطای صریح باشد، و اعطا باید با یک timestamp و رشته رضایت قبل از اینکه اسکریپت اجرا شود ثبت شود.
پوشش‌دهی ورودی و سرکوب داده حساس
ضبط‌کننده جلسه 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 و صفر کوکی _hj در document.cookie تولید کند. دوم، رد کردن تحلیل باید آن وضعیت را حفظ کند — بدون بارگذاری اسکریپت، بدون ضبط، بدون کوکی. سوم، پذیرش تحلیل باید یک بارگذاری اسکریپت و کوکی‌های _hjSessionUser و _hjSession مورد انتظار با ویژگی‌های SameSite صحیح تولید کند، و یک ضبط نقشه حرارتی باید ظرف پنج دقیقه در داشبورد Hotjar ظاهر شود. چهارم، عقب‌نشینی رضایت بعد از آن باید فوراً ضبط بیشتر را متوقف کند، کوکی‌ها را منقضی کند و یک درخواست حذف را راه‌اندازی کند — یک پاک‌سازی با تاخیر یک یافته است.
مسیر حسابرسی جداگانه اهمیت دارد. تنظیم‌کنندگان از ناشر انتظار دارند که برای هر ضبطی در حساب Hotjar، ثابت کند که کاربری که آن را ایجاد کرده در لحظه ثبت رضایت معتبر داده بوده است. الگوی استاندارد این است که نسخه رضایت و timestamp را به عنوان یک ویژگی سفارشی در پرونده کاربر Hotjar از طریق hj('identify', userId, { consent_version: 'v3', consent_ts: ts }) تعبیه کنید. این هر ضبط خاصی را قابل ردیابی به یک ورودی گزارش رضایت خاص می‌کند، که استانداردی است که EDPB تعیین کرده و ناشران صرف نظر از محل عملیاتشان باید اتخاذ کنند. یک استقرار به‌درستی دروازه‌بندی‌شده، همراه با پوشش‌دهی ورودی که به‌طور پیش‌فرض سرکوب می‌کند و یک مسیر حذف که در عقب‌نشینی فعال می‌شود، همان چیزی است که Hotjar را بخشی قابل دفاع از یک پشته تحقیقاتی می‌کند نه یک مسئولیت انطباق.