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, UK, स्विट्ज़रलैंड और किसी भी क्षेत्राधिकार में जिसने उसी मानक को आयात किया है, पूर्व, स्वतंत्र रूप से दी गई, विशिष्ट, सूचित और अस्पष्टता-रहित सहमति की आवश्यकता है। GDPR के तहत व्यवहार संबंधी स्ट्रीम व्यक्तिगत डेटा के प्रसंस्करण का गठन करती है क्योंकि कर्सर ट्रेस, IP पता, डिवाइस फिंगरप्रिंट और सत्र पहचानकर्ता का संयोजन किसी व्यक्ति को एकल करने के लिए पर्याप्त है। CCPA और CPRA के तहत वही संग्रह बिक्री या साझाकरण के रूप में गिना जाता है जब तक कि प्रकाशक के पास Hotjar के साथ प्रासंगिक सेवा-प्रदाता अनुबंध न हो — जो Hotjar अपने CCPA-अनुपालन DPA के माध्यम से प्रदान करता है, लेकिन केवल तब प्रभावी होता है जब एकीकरण सही ढंग से कॉन्फ़िगर किया गया हो। EDPB के सत्र-रिप्ले मार्गदर्शन के तहत बार और भी ऊंचा है: रिप्ले को एक विशिष्ट, वैध UX-अनुसंधान उद्देश्य से जोड़ा जाना चाहिए, प्रतिधारण अवधि न्यूनतम आवश्यक होनी चाहिए, और डेटा विषय को न केवल यह सूचित किया जाना चाहिए कि रिकॉर्डिंग मौजूद हैं बल्कि यह भी कि उनके अपने सत्र को एक विश्लेषक द्वारा फिर से चलाया जा सकता है।

Hotjar सहमति से पहले क्या एकत्र करता है — और क्या दबाया जाना चाहिए

सबसे आम कार्यान्वयन गलती वह है जो Hotjar के अपने क्विकस्टार्ट के साथ आती है: ट्रैकिंग स्क्रिप्ट को सीधे पेज <head> में पेस्ट करना। यह काम करता है, लेकिन कुकी बैनर के रेंडर होने से पहले ही Hotjar लोड हो जाता है, जिसका अर्थ है कि कुकीज़ सेट हो जाती हैं और व्यवहार रिकॉर्डिंग पहले ही पेज व्यू पर शुरू हो जाती है — चाहे उपयोगकर्ता बाद में जो भी निर्णय ले। हर EU नियामक जिसने इस पैटर्न पर निर्णय लिया है, उसने एक ही तरीके से निर्णय लिया है: सहमति से पहले सेट की गई कुकीज़ गैरकानूनी हैं, और प्रकाशक उत्तरदायी है।

इसलिए एक अनुपालन एकीकरण को Hotjar स्क्रिप्ट को तब तक लोड होने से रोकना चाहिए जब तक प्रासंगिक सहमति श्रेणी प्रदान नहीं की जाती। इसे करने का सबसे स्वच्छ तरीका है Hotjar स्निपेट को एक सहमति-गेटेड <script> टैग के अंदर लपेटना जिसे CMP केवल तभी इंजेक्ट करता है जब उपयोगकर्ता एनालिटिक्स या प्रोडक्ट-रिसर्च श्रेणी में ऑप्ट इन करे। यदि स्क्रिप्ट टैग मैनेजर के माध्यम से लोड होती है तो समकक्ष ट्रिगर को सभी पेज के बजाय सहमति-प्रदत्त ईवेंट पर सेट करना है। Hotjar का अपना दस्तावेज़ीकरण अब इस पैटर्न की स्पष्ट रूप से सिफारिश करता है, और प्लेटफॉर्म उन मामलों के लिए एक hj('consent', 'grant') API को उजागर करता है जहां स्क्रिप्ट मौजूद होनी चाहिए लेकिन सहमति दर्ज होने तक निष्क्रिय रहनी चाहिए।

Hotjar द्वारा लिखी गई कुकीज़ और स्टोरेज

Hotjar Tracking Code 6.x निम्नलिखित पहचानकर्ता लिखता है, जो सभी गैर-आवश्यक हैं और सहमति की आवश्यकता है: _hjSessionUser_{siteId} उपयोगकर्ता पहचानकर्ता युक्त 365-दिन की समाप्ति के साथ; _hjSession_{siteId} सत्र पहचानकर्ता युक्त 30-मिनट की समाप्ति के साथ; _hjFirstSeen; _hjIncludedInSessionSample_{siteId}; _hjAbsoluteSessionInProgress; और जब सर्वेक्षण या फीडबैक विजेट सक्रिय हों तो कई अभियान-एट्रिब्यूशन कुकीज़। सत्र रिकॉर्डिंग खुद Hotjar के सर्वर पर संग्रहीत होती हैं और सत्र पहचानकर्ता से जुड़ी होती हैं — इसलिए सहमति वापस लेने पर Hotjar के API या इन-प्रोडक्ट यूज़र-डिलीशन फ्लो के माध्यम से एक डिलीशन अनुरोध भी सिग्नल करना होगा।

Hotjar को सहमति फ्रेमवर्क से मैप करना

Hotjar IAB TCF या IAB Global Privacy Platform के साथ नेटिव रूप से एकीकृत नहीं होता। यह एक ad-tech विक्रेता नहीं है और कभी ऐसा होने का इरादा नहीं था। हालाँकि, यह analytics_storage सिग्नल के माध्यम से Google Consent Mode v2 के साथ एकीकृत होता है, और अपने नेटिव सहमति API को उजागर करता है जिसे कोई भी CMP बांध सकता है। वह पैटर्न जो किसी नियामक की समीक्षा से बचता है, Hotjar की प्रत्येक क्षमता को एक अलग सहमति गेट के रूप में मानता है।

एकीकरण पैटर्न जो काम करता है

संदर्भ परिनियोजन के चार भाग हैं: एक CMP जो एक रियल-टाइम सहमति परिवर्तन ईवेंट उजागर करता है, एक डिफर्ड स्क्रिप्ट लोडर जो केवल एनालिटिक्स सहमति फायर होने के बाद Hotjar स्निपेट इंजेक्ट करता है, एक सत्र-रिकॉर्डिंग सप्रेशन परत जो एक अलग गेट खुलने तक रिकॉर्डिंग को डिफ़ॉल्ट रूप से बंद करती है, और एक इनपुट-मास्किंग कॉन्फ़िगरेशन जो किसी भी फ़ील्ड को जिसे कोई नियामक संवेदनशील मानेगा, सहमति मिलने पर भी कठोरता से दबाता है। चौथे बिंदु को अक्सर नज़रअंदाज़ किया जाता है: इनपुट मास्किंग सहमति का विकल्प नहीं है, लेकिन यह आपदा का विकल्प है जब वैध शोध के लिए सहमति दी जाती है और उपयोगकर्ता संयोगवश मुक्त-पाठ फ़ील्ड में संवेदनशील डेटा पेस्ट करता है।

वेब कार्यान्वयन

वेब पर सबसे स्वच्छ पैटर्न CMP के सहमति परिवर्तन ईवेंट की सदस्यता लेना है, फिर जब एनालिटिक्स उद्देश्य false से true में बदलता है तो सशर्त रूप से Hotjar स्निपेट इंजेक्ट करना है। async एट्रिब्यूट सेट के साथ ट्रैकिंग कोड इंजेक्ट करने के लिए document.createElement('script') का उपयोग करें, और एक onload हैंडलर संलग्न करें जो hj('identify', userId, properties) को केवल तभी कॉल करे जब सर्वर-वैलिडेटेड उपयोगकर्ता पहचानकर्ता मौजूद हो। जब सहमति वापस ली जाती है, hj('consent', 'revoke') कॉल करें, document.cookie के माध्यम से सभी _hj कुकीज़ को समाप्त करें, और उपयोगकर्ता की पूर्व सत्र रिकॉर्डिंग के लिए Hotjar Data API के माध्यम से डिलीशन अनुरोध भेजें। बैनर के समान रेंडर पास में Hotjar को आलस्यपूर्वक इनिशियलाइज़ न करें — स्क्रिप्ट को एक स्पष्ट अनुदान की प्रतीक्षा करनी चाहिए, और अनुदान को एक टाइमस्टैम्प और सहमति स्ट्रिंग के साथ स्क्रिप्ट के फायर होने से पहले रिकॉर्ड किया जाना चाहिए।

इनपुट मास्किंग और संवेदनशील-डेटा सप्रेशन

Hotjar का सत्र रिकॉर्डर तीन मास्किंग मोड के साथ आता है: Suppress mode, जो पासवर्ड फ़ील्ड और data-hj-suppress एट्रिब्यूट के साथ चिह्नित किसी भी तत्व के लिए डिफ़ॉल्ट है; Whitelist mode, जहां केवल स्पष्ट रूप से ऑप्ट-इन किए गए इनपुट रिकॉर्ड किए जाते हैं; और Mask mode, जहां कीस्ट्रोक को तारांकन के रूप में रिकॉर्ड किया जाता है। GDPR की विशेष-श्रेणी नियमों और CCPA की संवेदनशील-व्यक्तिगत-जानकारी परिभाषा के तहत, कोई भी फ़ील्ड जो स्वास्थ्य जानकारी, वित्तीय विवरण, सरकारी पहचानकर्ता, बायोमेट्रिक डेटा, सटीक जियोलोकेशन या निजी संचार की सामग्री कैप्चर कर सकती है, उपयोगकर्ता की सहमति स्थिति की परवाह किए बिना Suppress mode का उपयोग करना चाहिए। फ़ील्ड स्तर के बजाय फॉर्म स्तर पर data-hj-suppress सेट करना सबसे सुरक्षित पैटर्न है — यह पूरे फॉर्म को दबाता है भले ही एक डेवलपर बाद में एक नया फ़ील्ड जोड़े जिसे वे व्यक्तिगत रूप से चिह्नित करना भूल जाते हैं।

सिंगल-पेज एप्लिकेशन और रूट परिवर्तन

SPAs के लिए (React, Vue, Angular, Svelte) Hotjar स्निपेट डिफ़ॉल्ट रूप से केवल प्रारंभिक पेज लोड से बंधता है। वर्चुअल पेज ट्रांजिशन को ट्रैक करने के लिए बूटस्ट्रैप को प्रत्येक रूट परिवर्तन पर hj('stateChange', newPath) कॉल करना चाहिए। यह कॉल उस समय Hotjar जो सहमति स्थिति रखता है उसका सम्मान करती है, इसलिए CMP गेटिंग लॉजिक को डुप्लिकेट करने की आवश्यकता नहीं है — लेकिन रूट परिवर्तन स्वयं एक नई स्क्रिप्ट लोड को ट्रिगर नहीं करना चाहिए यदि पेज व्यू के बीच सहमति वापस ली गई हो।

एकीकरण को मान्य करना

मान्यता चरण वह है जो नियामक जांचते हैं और जिसे प्रकाशक अक्सर छोड़ देते हैं। एक सही ढंग से एकीकृत Hotjar परिनियोजन को क्रम में चार परीक्षण पास करने होंगे। पहला, बैनर दिखाया गया लेकिन कोई विकल्प नहीं बनाया गया के साथ एक नया ब्राउज़र सत्र static.hotjar.com, script.hotjar.com या vars.hotjar.com को शून्य अनुरोध और document.cookie में शून्य _hj कुकीज़ उत्पन्न करना चाहिए। दूसरा, एनालिटिक्स को अस्वीकार करने से वह स्थिति बनी रहनी चाहिए — कोई स्क्रिप्ट लोड नहीं, कोई रिकॉर्डिंग नहीं, कोई कुकीज़ नहीं। तीसरा, एनालिटिक्स स्वीकार करने से एक स्क्रिप्ट लोड और सही SameSite एट्रिब्यूट के साथ अपेक्षित _hjSessionUser और _hjSession कुकीज़ उत्पन्न होनी चाहिए, और पांच मिनट के भीतर Hotjar डैशबोर्ड में एक हीटमैप रिकॉर्डिंग दिखनी चाहिए। चौथा, बाद में सहमति वापस लेने से तुरंत आगे की रिकॉर्डिंग रोकनी चाहिए, कुकीज़ समाप्त होनी चाहिए और एक डिलीशन अनुरोध ट्रिगर होना चाहिए — देर से सफाई एक खोज है।

ऑडिट ट्रेल अलग से महत्वपूर्ण है। नियामकों को उम्मीद है कि प्रकाशक Hotjar खाते में किसी भी रिकॉर्डिंग के लिए यह साबित करने में सक्षम हो कि इसे उत्पन्न करने वाले उपयोगकर्ता ने कैप्चर के समय वैध सहमति दी थी। मानक पैटर्न Hotjar उपयोगकर्ता रिकॉर्ड पर hj('identify', userId, { consent_version: 'v3', consent_ts: ts }) के माध्यम से एक कस्टम एट्रिब्यूट के रूप में सहमति संस्करण और टाइमस्टैम्प एम्बेड करना है। यह किसी भी विशिष्ट रिकॉर्डिंग को एक विशिष्ट सहमति लॉग प्रविष्टि तक ट्रेस करने योग्य बनाता है, जो EDPB द्वारा निर्धारित मानक है और जिसे प्रकाशकों को उनके संचालन स्थान की परवाह किए बिना अपनाना चाहिए। एक सही ढंग से गेटेड परिनियोजन, इनपुट मास्किंग के साथ जो डिफ़ॉल्ट रूप से दबाती है और एक डिलीशन पथ जो वापसी पर सक्रिय होता है, वह है जो Hotjar को एक अनुसंधान स्टैक का रक्षा योग्य हिस्सा बनाता है बजाय अनुपालन देनदारी के।

← ब्लaderegistrdelays delays सभी पढ़ें →