คู่มือการผสานรวมการยินยอมคุกกี้ Hotjar Heatmap และการบันทึกเซสชัน: แผนเกมปี 2026 สำหรับผู้เผยแพร่
Hotjar มีที่ยืนที่ไม่เหมือนใครในชุดเครื่องมือ ไม่ใช่แพลตฟอร์มการวิเคราะห์เว็บอย่าง Google Analytics ไม่ใช่แพลตฟอร์มการวิเคราะห์ผลิตภัณฑ์อย่าง Amplitude หรือ Mixpanel และไม่ใช่ตัวจัดการแท็ก แต่เป็นเครื่องมือวิจัยประสบการณ์ผู้ใช้ที่มีอยู่โดยเฉพาะเพื่อบันทึกสิ่งที่ผู้ใช้แต่ละรายทำบนหน้าเพจ — พวกเขาเลื่อนเมาส์ที่ไหน คลิกอะไร เลื่อนที่ไหน ลังเลที่ไหน และในกรณีของการบันทึกเซสชัน คือสิ่งที่พวกเขาพิมพ์และเห็นที่แสดงผลบนหน้าจอ ความละเอียดนั้นคือผลิตภัณฑ์ นั่นยังเป็นเหตุผลที่หน่วยงานกำกับดูแลได้ระบุการเล่นซ้ำเซสชันว่าเป็นหนึ่งในประเภทที่มีความเสี่ยงสูงสุดของการประมวลผลพฤติกรรม และเหตุใดการติดตั้ง Hotjar อย่างไม่ระมัดระวังจึงเป็นวิธีที่ง่ายที่สุดวิธีหนึ่งสำหรับเว็บไซต์ที่สอดคล้องในด้านอื่นๆ ให้หลุดออกจากการปฏิบัติตาม CNIL, Garante และ EDPB ต่างได้เผยแพร่แนวทางที่กำหนดเป้าหมายพฤติกรรมการเล่นซ้ำเซสชันโดยเฉพาะ และกลุ่มทำงานแบนเนอร์คุกกี้ EDPB ปี 2026 กำลังจัดการกับมันในฐานะหมวดหมู่ลำดับความสำคัญ ข่าวดีคือ Hotjar เป็นหนึ่งในเครื่องมือที่ออกแบบมาได้ดีกว่าในหมวดหมู่สำหรับการติดตั้งที่ให้ความยินยอมเป็นอันดับแรก — หากผู้เผยแพร่ใช้ตัวควบคุมที่มีอยู่จริง
ทำไม Hotjar จึงต้องการการยินยอมอย่างชัดเจน
โปรไฟล์การรวบรวมของ Hotjar คือสิ่งที่กระตุ้นภาระผูกพันการยินยอมในทุกกรอบงานที่สำคัญ ในการเริ่มต้นเริ่มต้นแบบปกติ สคริปต์การติดตาม Hotjar จะเขียนคุกกี้ฝ่ายแรกอย่างน้อยสาม — _hjSessionUser_{siteId}, _hjSession_{siteId} และชุดคุกกี้การระงับและแหล่งขาเข้า — ลงในเบราว์เซอร์ภายในมิลลิวินาทีหลังจากโหลดหน้าเพจ สคริปต์จะเริ่มสตรีมบันทึกต่อเนื่องของพิกัดเคอร์เซอร์ พิกัดการคลิก ตำแหน่งการเลื่อน ขนาดวิวพอร์ต และเมื่อเปิดใช้งานการบันทึกเซสชัน DOM ที่แสดงผลทั้งหมดที่แตกต่างจากพื้นฐาน
ภายใต้มาตรา 5(3) ของ ePrivacy Directive คุกกี้แต่ละตัวเหล่านั้นเป็นการดำเนินการจัดเก็บและเข้าถึงที่ต้องการการยินยอมก่อน ได้รับโดยเสรี เฉพาะเจาะจง มีข้อมูล และไม่คลุมเครือใน EEA สหราชอาณาจักร สวิตเซอร์แลนด์ และเขตอำนาจศาลใดๆ ที่ได้นำมาตรฐานเดียวกันมาใช้ ภายใต้ GDPR กระแสพฤติกรรมถือเป็นการประมวลผลข้อมูลส่วนบุคคล เนื่องจากการรวมกันของเส้นทางเคอร์เซอร์ ที่อยู่ IP ลายนิ้วมือของอุปกรณ์ และตัวระบุเซสชันเพียงพอสำหรับการระบุตัวบุคคล ภายใต้ CCPA และ CPRA การรวบรวมเดียวกันถือเป็นการขายหรือการแบ่งปัน เว้นแต่ผู้เผยแพร่มีสัญญาผู้ให้บริการที่เกี่ยวข้องกับ Hotjar — ซึ่ง Hotjar เสนอผ่าน DPA ที่สอดคล้องกับ CCPA แต่จะมีผลบังคับใช้เมื่อการผสานรวมได้รับการกำหนดค่าอย่างถูกต้องเท่านั้น ภายใต้แนวทาง EDPB สำหรับการเล่นซ้ำเซสชัน มาตรฐานนั้นสูงกว่านี้: การเล่นซ้ำต้องเชื่อมโยงกับวัตถุประสงค์การวิจัย UX ที่เฉพาะเจาะจงและถูกต้องตามกฎหมาย ระยะเวลาการเก็บรักษาต้องน้อยที่สุดเท่าที่จำเป็น และต้องแจ้งให้เจ้าของข้อมูลทราบไม่เพียงแต่ว่ามีการบันทึกอยู่ แต่ว่าเซสชันของพวกเขาเองอาจถูกเล่นซ้ำโดยนักวิเคราะห์
Hotjar รวบรวมอะไรก่อนการยินยอม — และอะไรที่ต้องระงับ
ข้อผิดพลาดการใช้งานที่พบบ่อยที่สุดคือข้อผิดพลาดที่มาพร้อมกับ quickstart ของ Hotjar เอง: การวางสคริปต์การติดตามโดยตรงใน <head> ของหน้าเพจ ซึ่งทำงานได้ แต่โหลด Hotjar ก่อนที่แบนเนอร์คุกกี้จะถูกแสดงผล หมายความว่ามีการตั้งค่าคุกกี้และการบันทึกพฤติกรรมเริ่มต้นในการดูหน้าเพจครั้งแรกสุด — โดยไม่คำนึงถึงสิ่งที่ผู้ใช้ตัดสินใจในภายหลัง หน่วยงานกำกับดูแล EU ทุกแห่งที่ตัดสินในรูปแบบนี้ได้ตัดสินในทำนองเดียวกัน: คุกกี้ที่ตั้งค่าก่อนการยินยอมเป็นสิ่งผิดกฎหมาย และผู้เผยแพร่มีความรับผิดชอบ
ดังนั้นการผสานรวมที่สอดคล้องต้องป้องกันไม่ให้สคริปต์ Hotjar โหลดเลยจนกว่าหมวดหมู่การยินยอมที่เกี่ยวข้องจะได้รับการอนุมัติ วิธีที่สะอาดที่สุดในการทำเช่นนี้คือการห่อ Hotjar snippet ไว้ใน <script> tag ที่มีการตรวจสอบการยินยอมซึ่ง 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 แบบ native ไม่ใช่ผู้ขายเทคโนโลยีโฆษณาและไม่เคยตั้งใจจะเป็น อย่างไรก็ตาม ผสานรวมกับ Google Consent Mode v2 ผ่านสัญญาณ analytics_storage และเปิดเผย API การยินยอม native ของตนเองที่ CMP ใดก็ได้สามารถผูกได้ รูปแบบที่ผ่านการตรวจสอบของหน่วยงานกำกับดูแลจะถือว่าความสามารถ Hotjar แต่ละอย่างเป็นประตูการยินยอมที่แยกจากกัน
- Heatmaps และแผนที่การคลิก ผูกกับวัตถุประสงค์การวิเคราะห์หรือการวิจัยผลิตภัณฑ์ ในแง่ TCF นี่มักเป็นวัตถุประสงค์ 8 (วัดประสิทธิภาพเนื้อหา) รวมกับวัตถุประสงค์ 1 (จัดเก็บและ/หรือเข้าถึงข้อมูล) สำหรับ Consent Mode นี่คือ analytics_storage
- การบันทึกเซสชัน ควรอยู่หลังสัญญาณที่เข้มงวดกว่า แยกจากกัน การบันทึกจับ DOM ที่แสดงผลและฟิลด์ที่ไม่ได้ปิดบังใดๆ และการยินยอมระดับการตั้งค่าที่ชัดเจน — ไม่ใช่การยินยอมการวิเคราะห์ครอบคลุม — เป็นท่าทีที่ป้องกันได้ภายใต้แนวทาง EDPB สำหรับการเล่นซ้ำเซสชัน
- แบบสำรวจและวิดเจ็ตข้อเสนอแนะ สามารถทำงานภายใต้ประตูการยินยอมเดียวกันกับการบันทึกเซสชันเมื่อรวบรวมข้อความอิสระ หรือภายใต้ประตูการวิเคราะห์เมื่อรวบรวมเฉพาะข้อมูลการให้คะแนน
- ช่องทางและการติดตามการแปลง ผูกกับประตูการวิเคราะห์ หากตัวระบุผู้ใช้ใดๆ ถูกส่งไปยัง CRM หรือแพลตฟอร์มโฆษณา ประตูการตลาดก็ใช้ด้วยเช่นกัน
รูปแบบการผสานรวมที่ใช้งานได้
การติดตั้งอ้างอิงมีสี่ส่วน: CMP ที่เปิดเผยเหตุการณ์การเปลี่ยนแปลงการยินยอมแบบเรียลไทม์ ตัวโหลดสคริปต์แบบเลื่อนออกไปที่แทรก Hotjar snippet เพียงหลังจากที่การยินยอมการวิเคราะห์ทำงาน ชั้นการระงับการบันทึกเซสชันที่ตั้งค่าเริ่มต้นการบันทึกเป็นปิดจนกว่าประตูแยกต่างหากจะเปิด และการกำหนดค่าการปิดบังการป้อนข้อมูลที่ระงับฟิลด์ใดๆ อย่างแข็งกร้าวที่หน่วยงานกำกับดูแลจะถือว่าละเอียดอ่อนแม้เมื่อได้รับการยินยอมแล้ว จุดที่สี่มักถูกมองข้าม: การปิดบังการป้อนข้อมูลไม่ใช่สิ่งทดแทนการยินยอม แต่เป็นสิ่งทดแทนความหายนะเมื่อการยินยอมได้รับสำหรับการวิจัยที่ถูกต้องตามกฎหมายและผู้ใช้บังเอิญวางข้อมูลที่ละเอียดอ่อนลงในฟิลด์ข้อความอิสระ
การใช้งานบนเว็บ
บนเว็บรูปแบบที่สะอาดที่สุดคือการสมัครรับเหตุการณ์การเปลี่ยนแปลงการยินยอมของ CMP จากนั้นแทรก Hotjar snippet ตามเงื่อนไขเมื่อวัตถุประสงค์การวิเคราะห์สลับจาก false เป็น true ใช้ document.createElement('script') เพื่อแทรกโค้ดการติดตามโดยตั้งค่าแอตทริบิวต์ async และแนบตัวจัดการ onload ที่เรียก hj('identify', userId, properties) เฉพาะเมื่อมีตัวระบุผู้ใช้ที่ได้รับการตรวจสอบจากเซิร์ฟเวอร์ เมื่อถอนการยินยอม เรียก hj('consent', 'revoke') ทำให้คุกกี้ _hj ทั้งหมดหมดอายุผ่าน document.cookie และส่งคำขอการลบผ่าน Hotjar Data API สำหรับการบันทึกเซสชันก่อนหน้าของผู้ใช้ อย่าเริ่มต้น Hotjar แบบขี้เกียจในรอบการแสดงผลเดียวกับแบนเนอร์ — สคริปต์ต้องรอการอนุมัติที่ชัดเจน และการอนุมัติต้องถูกบันทึกพร้อมกับ timestamp และ consent string ก่อนที่สคริปต์จะทำงานเลย
การปิดบังการป้อนข้อมูลและการระงับข้อมูลที่ละเอียดอ่อน
เครื่องบันทึกเซสชันของ Hotjar มาพร้อมกับโหมดการปิดบังสามแบบ: Suppress mode ซึ่งเป็นค่าเริ่มต้นสำหรับฟิลด์รหัสผ่านและองค์ประกอบที่ทำเครื่องหมายด้วยแอตทริบิวต์ data-hj-suppress; Whitelist mode ที่บันทึกเฉพาะการป้อนข้อมูลที่เลือกเข้าอย่างชัดเจน; และ Mask mode ที่บันทึกการกดแป้นพิมพ์เป็นเครื่องหมายดอกจัน ภายใต้กฎหมายหมวดหมู่พิเศษของ GDPR และคำจำกัดความของ CCPA เกี่ยวกับข้อมูลส่วนบุคคลที่ละเอียดอ่อน ฟิลด์ใดๆ ที่อาจจับข้อมูลสุขภาพ รายละเอียดทางการเงิน ตัวระบุของรัฐบาล ข้อมูลชีวมิติ ตำแหน่งที่ตั้งที่แม่นยำ หรือเนื้อหาของการสื่อสารส่วนตัวต้องใช้ Suppress mode โดยไม่คำนึงถึงสถานะการยินยอมของผู้ใช้ การตั้งค่า data-hj-suppress ที่ระดับฟอร์มแทนที่จะเป็นระดับฟิลด์เป็นรูปแบบที่ปลอดภัยที่สุด — มันระงับทั้งฟอร์มแม้ว่านักพัฒนาจะเพิ่มฟิลด์ใหม่ในภายหลังที่พวกเขาลืมทำเครื่องหมายแยกต่างหาก
แอปพลิเคชันหน้าเดียวและการเปลี่ยนเส้นทาง
สำหรับ SPA (React, Vue, Angular, Svelte) Hotjar snippet ผูกกับการโหลดหน้าเพจแรกสุดเท่านั้นตามค่าเริ่มต้น เพื่อติดตามการเปลี่ยนหน้าเพจเสมือน bootstrap ต้องเรียก hj('stateChange', newPath) ทุกครั้งที่เปลี่ยนเส้นทาง การเรียกนี้เคารพสถานะการยินยอมที่ Hotjar ยึดถือในขณะนั้น ดังนั้นตรรกะ CMP gating ไม่จำเป็นต้องทำซ้ำ — แต่การเปลี่ยนเส้นทางเองต้องไม่กระตุ้นการโหลดสคริปต์ใหม่หากการยินยอมถูกถอนออกระหว่างการดูหน้าเพจ
การตรวจสอบการผสานรวม
ขั้นตอนการตรวจสอบคือสิ่งที่หน่วยงานกำกับดูแลตรวจสอบและสิ่งที่ผู้เผยแพร่มักข้ามไป การติดตั้ง Hotjar ที่ผสานรวมอย่างถูกต้องต้องผ่านการทดสอบสี่ครั้งตามลำดับ ประการแรก เซสชันเบราว์เซอร์ใหม่ที่มีแบนเนอร์แสดงแต่ยังไม่เลือกควรสร้างคำขอศูนย์ไปยัง static.hotjar.com, script.hotjar.com หรือ vars.hotjar.com และคุกกี้ _hj ศูนย์ใน document.cookie ประการที่สอง การปฏิเสธการวิเคราะห์ควรคงสภาพนั้น — ไม่มีการโหลดสคริปต์ ไม่มีการบันทึก ไม่มีคุกกี้ ประการที่สาม การยอมรับการวิเคราะห์ควรสร้างการโหลดสคริปต์และคุกกี้ _hjSessionUser และ _hjSession ที่คาดหวังด้วยแอตทริบิวต์ SameSite ที่ถูกต้อง และการบันทึก heatmap ควรปรากฏในแดชบอร์ด Hotjar ภายในห้านาที ประการที่สี่ การถอนการยินยอมหลังจากนั้นควรหยุดการบันทึกเพิ่มเติมทันที ทำให้คุกกี้หมดอายุ และกระตุ้นคำขอการลบ — การล้างข้อมูลที่ล่าช้าเป็นสิ่งที่ค้นพบ
เส้นทางการตรวจสอบมีความสำคัญแยกต่างหาก หน่วยงานกำกับดูแลคาดหวังให้ผู้เผยแพร่สามารถพิสูจน์ได้สำหรับการบันทึกใดๆ ในบัญชี Hotjar ว่าผู้ใช้ที่สร้างมันได้ให้การยินยอมที่ถูกต้องในขณะที่จับข้อมูล รูปแบบมาตรฐานคือการฝังเวอร์ชันการยินยอมและ timestamp เป็นแอตทริบิวต์แบบกำหนดเองบนระเบียนผู้ใช้ Hotjar ผ่าน hj('identify', userId, { consent_version: 'v3', consent_ts: ts }) ซึ่งทำให้การบันทึกเฉพาะใดๆ สามารถติดตามย้อนกลับไปยังรายการบันทึกการยินยอมเฉพาะได้ ซึ่งเป็นมาตรฐานที่ EDPB ตั้งไว้และมาตรฐานที่ผู้เผยแพร่ควรนำมาใช้โดยไม่คำนึงถึงที่ที่พวกเขาดำเนินการ การติดตั้งที่มีประตูอย่างถูกต้อง จับคู่กับการปิดบังการป้อนข้อมูลที่ระงับตามค่าเริ่มต้นและเส้นทางการลบที่เปิดใช้งานเมื่อถอน คือสิ่งที่ทำให้ Hotjar เป็นส่วนที่ป้องกันได้ของ research stack แทนที่จะเป็นภาระผูกพันการปฏิบัติตาม