คู่มือการผสานรวมการยินยอมคุกกี้การบันทึกเซสชัน Microsoft Clarity สำหรับปี 2026

Microsoft Clarity เปิดตัวในปี 2020 ในฐานะทางเลือกฟรีที่ไม่มีโควต้าสำหรับ Hotjar และ Smartlook สำหรับการบันทึกเซสชัน แผนที่ความร้อน และการวิเคราะห์การโต้ตอบ ห้าปีต่อมา มันครองส่วนแบ่งที่มีนัยสำคัญ ของเว็บไซต์ตลาดกลางและธุรกิจขนาดเล็กทั่วโลก ส่วนหนึ่งเพราะมีประโยชน์จริงๆ และส่วนหนึ่งเพราะ การติดตั้งเป็นโค้ด JavaScript เพียงบรรทัดเดียวที่ผู้ดำเนินการส่วนใหญ่วางไว้โดยไม่คิดอะไรมากไปกว่านั้น จากมุมมองด้านความเป็นส่วนตัว ความง่ายของการติดตั้งนั้นคือปัญหาที่แท้จริง Clarity บันทึกการเคลื่อนไหว ของเมาส์ พฤติกรรมการเลื่อน การคลิก การกดแป้นพิมพ์ การโต้ตอบแบบฟอร์ม และสแนปช็อต DOM แบบเต็มหน้า — เปย์โหลดพฤติกรรมที่หนาแน่นที่สุดในบรรดาเครื่องมือวิเคราะห์ที่ใช้งานทั่วไปทั้งหมด — และส่งต่อทุก อย่างไปยังเซิร์ฟเวอร์ของ Microsoft ทันทีที่สคริปต์โหลด สำหรับการใช้งานใดๆ ที่สัมผัสกับการรับส่งข้อมูล ของ EU, UK, EEA, บราซิล หรือแคลิฟอร์เนีย การติดตั้งเริ่มต้นไม่เป็นไปตามข้อกำหนด และหน่วยงานกำกับดูแล ที่กระตือรือร้นที่สุดในการบังคับใช้การบันทึกเซสชัน — CNIL, Garante ของอิตาลี, UK ICO — ได้ระบุอย่าง ชัดเจนว่าการวิเคราะห์นี้ใช้ได้โดยไม่คำนึงถึงระดับราคาหรือผู้จำหน่ายของเครื่องมือ คู่มือนี้อธิบาย สิ่งที่ Clarity บันทึก วิธีการทำงานของขอบเขตการยินยอม และรูปแบบการผสานรวมที่ผ่านการตรวจสอบ

สิ่งที่ Clarity บันทึกจริงๆ

Clarity SDK (โหลดจาก www.clarity.ms/tag/{project_id}) เริ่มต้นออบเจ็กต์ clarity ทั่วโลกและระบุผู้เยี่ยมชมด้วยคุกกี้ที่ Microsoft เป็นเจ้าของชื่อว่า _clck พร้อมด้วยคุกกี้เซสชัน _clsk นับจากนั้น สคริปต์จะจับ สตรีมพฤติกรรมที่หนาแน่น:

การรวมกัน — โดยเฉพาะสแนปช็อต DOM และการจับฟิลด์ฟอร์ม — ทำให้ Clarity เทียบเท่ากับการบันทึกวิดีโอ ของเซสชันของผู้เยี่ยมชม การจำแนกประเภทตามกฎระเบียบภายใต้ GDPR เป็นเรื่องง่าย: นี่คือการประมวลผลข้อมูล ส่วนบุคคล คุกกี้ไม่จำเป็น ข้อมูลข้ามพรมแดนไปยังโครงสร้างพื้นฐานสหรัฐฯ ของ Microsoft และ พื้นฐานทางกฎหมายที่จำเป็นคือการยินยอม แนวทาง CNIL ปี 2024 เกี่ยวกับการบันทึกเซสชันไม่คลุมเครือ ในประเด็นนี้และระบุชื่อเครื่องมือในหมวดหมู่ของ Clarity อย่างชัดเจน

ความเสี่ยงของข้อมูลที่ละเอียดอ่อน

เครื่องมือบันทึกเซสชันมีอันตรายด้านความเป็นส่วนตัวเฉพาะที่เครื่องมือวิเคราะห์อื่นไม่มี: พวกมันสามารถจับข้อมูลส่วนบุคคลที่ละเอียดอ่อนโดยบังเอิญ ผู้ใช้ที่พิมพ์หมายเลขบัตรเครดิต สภาพสุขภาพ ความเชื่อทางศาสนา หรือตัวระบุประชาชาติในฟิลด์ฟอร์มใดๆ จะถูก Clarity บันทึกหาก ฟิลด์ไม่ได้มาสก์อย่างชัดเจน ภายใต้ GDPR นี่คือการประมวลผลข้อมูลส่วนบุคคลที่ละเอียดอ่อนตาม Article 9 ซึ่งต้องการความยินยอมแบบ opt-in อย่างชัดเจนและแทบจะไม่ครอบคลุมโดยการตัดสินใจ ยินยอมทางการตลาดทั่วไป

Clarity รองรับการกำหนดค่าการมาสก์เนื้อหาที่ซ่อนฟิลด์เฉพาะจากการบันทึก แต่พฤติกรรมเริ่มต้น จะจับทุกอย่าง แนวทางที่ป้องกันได้ในการตรวจสอบคือมาสก์อย่างเข้มงวด — สันนิษฐานว่าทุกฟิลด์ฟอร์ม มีความละเอียดอ่อนจนกว่าจะพิสูจน์ได้เป็นอย่างอื่น — และบันทึกการตัดสินใจมาสก์อย่างชัดเจน

การควบคุมความเป็นส่วนตัวดั้งเดิมของ Clarity

Microsoft ได้ลงทุนในการควบคุมความเป็นส่วนตัวของ Clarity ในช่วงสองปีที่ผ่านมา แพลตฟอร์ม ตอนนี้เปิดเผย primitive หลายรายการที่การผสานรวม CMP สามารถใช้ประโยชน์ได้

แอตทริบิวต์มาสก์

การเพิ่ม data-clarity-mask="true" ให้กับองค์ประกอบ DOM จะซ่อนเนื้อหาจาก การบันทึกเซสชัน การเพิ่ม data-clarity-unmask="true" ให้กับองค์ประกอบย่อย จะแทนที่มาสก์สำหรับ subtree นั้น ค่าเริ่มต้นที่ถูกต้องสำหรับฟิลด์ฟอร์มที่อาจมีข้อมูลส่วนบุคคล คือมาสก์ จากนั้นยกเลิกมาสก์อย่างชัดเจนในที่ที่ปลอดภัย

API การยินยอม

Clarity เปิดเผยการเรียก clarity("consent") ซึ่งเมื่อถูกเรียก จะส่งสัญญาณ ว่าได้รับความยินยอมแล้วและ SDK ควรดำเนินการต่อ หากไม่มีการเรียกนี้ SDK สามารถกำหนดค่าให้หยุด หลังจากโหลดเริ่มต้น นี่คือ primitive ที่ถูกต้องสำหรับการผสานรวม CMP ในฝั่งการเปิดใช้งาน

การมาสก์ IP และการจัดการตัวระบุ

การตั้งค่าโปรเจ็กต์ Clarity เปิดเผยตัวเลือกสำหรับการตัด IP และการมาสก์ตัวระบุ การเปิดใช้ สิ่งเหล่านี้เป็นมาตรการป้องกันเชิงลึกเพิ่มเติมจากการควบคุม CMP โดยไม่แทนที่การยินยอม

การมาสก์เนื้อหาละเอียดอ่อนอัตโนมัติ

Clarity รุ่นล่าสุดพยายามตรวจจับฟิลด์ละเอียดอ่อนโดยอัตโนมัติ (รูปแบบบัตรเครดิต ฟิลด์รหัสผ่าน ฟิลด์ชื่อว่า "ssn" หรือคล้ายกัน) และมาสก์โดยค่าเริ่มต้น การตรวจจับเป็นแบบ heuristic และไม่ สมบูรณ์ อย่าพึ่งพาเป็นแนวป้องกันเพียงเส้นเดียว

การผสานรวม CMP ทีละขั้นตอน

สถาปัตยกรรมที่เชื่อถือได้คือการเลื่อน Clarity SDK ออกไปทั้งหมดจนกว่าจะได้รับความยินยอม จากนั้นเปิดใช้งานอย่างชัดเจนผ่าน API การยินยอม

1. ลบแท็กเริ่มต้นออกจากส่วนหัวของเอกสาร

ข้อมูลโค้ดการติดตั้ง Clarity เป็นสคริปต์อินไลน์เดียวที่เริ่มต้น SDK เมื่อโหลดหน้า แทนที่ด้วย องค์ประกอบสคริปต์ตัวแทนที่ type คือ text/plain และ data-category คือ analytics หรือ marketing ขึ้นอยู่กับวิธีที่ CMP ของคุณจัดหมวดหมู่เครื่องมือบันทึกเซสชัน

2. ตัดสินใจเกี่ยวกับการแมปหมวดหมู่

การบันทึกเซสชันเป็นหมวดหมู่ที่ยังโต้เถียงกัน CNIL ได้จัดการในหลายลักษณะทั้งเป็นการวิเคราะห์ (เมื่อข้อมูลใช้สำหรับการวิจัย UX ภายใน) และเป็นการตลาด (เมื่อข้อมูลป้อนการตัดสินใจส่วนบุคคลหรือ การแบ่งปันภายนอก) การแมปแบบอนุรักษ์นิยมคือการตลาด ตำแหน่งที่ป้องกันได้ในการตรวจสอบต้องการให้ คุณระบุอย่างชัดเจนว่าการบันทึกถูกใช้จริงอย่างไร

3. กำหนดค่าการมาสก์อย่างเข้มงวดก่อนการเปิดใช้งาน

เพิ่ม data-clarity-mask="true" ให้กับทุกองค์ประกอบฟอร์ม ทุกฟิลด์อินพุต ทุกคอนเทนเนอร์ที่อาจมีข้อมูลส่วนบุคคล นโยบายเริ่มต้นคือมาสก์โดยค่าเริ่มต้นพร้อมข้อยกเว้น การยกเลิกมาสก์อย่างชัดเจนสำหรับองค์ประกอบที่รู้ว่าปลอดภัย (ชื่อหน้า ป้ายนำทาง บล็อกเนื้อหาสาธารณะ)

4. เปิดใช้งาน Clarity จาก callback การยินยอม

เมื่อ CMP เริ่มต้นเหตุการณ์ที่เกี่ยวข้องกับหมวดหมู่ที่ยอมรับ ให้เขียนแท็กสคริปต์ตัวแทนใหม่ และเรียก clarity("consent") เพื่อให้ SDK รับอนุญาตดำเนินการต่อ เหตุการณ์ที่ อยู่ในคิวซึ่งถูกบัฟเฟอร์ในช่วงก่อนยินยอมจะถูก flush ออกมา

5. จัดการการเพิกถอนอย่างชัดเจน

หากผู้ใช้เพิกถอนความยินยอม Clarity SDK ไม่มีการเรียก "หยุดบันทึก" ที่สะอาดเทียบเท่ากับ API การเปิดใช้งาน รูปแบบที่ใช้ได้จริงคือเรียก clarity("consent", false) หากรองรับใน SDK เวอร์ชันของคุณ และล้างคุกกี้ Clarity ฝั่งไคลเอนต์เพิ่มเติม สำหรับการลบ การบันทึกในอดีตอย่างสมบูรณ์ ให้ใช้เวิร์กโฟลว์การลบข้อมูลของ UI ผู้ดูแลระบบ Clarity หรือ API การลบ

ข้อผิดพลาดที่พบบ่อย

ข้อผิดพลาดการผสานรวมสี่อย่างที่คิดเป็นส่วนใหญ่ของผลการตรวจสอบในการปรับใช้ Clarity

การติดตั้ง Clarity "แค่เพื่อดูว่าผู้เยี่ยมชมทำอะไร"

รูปแบบที่พบบ่อยที่สุด: ผู้จัดการผลิตภัณฑ์ติดตั้ง Clarity เพื่อวิจัยปัญหา UX ไม่เคยเปิดใช้ การควบคุมการยินยอม ไม่เคยกำหนดค่าการมาสก์ และลืมสคริปต์ พื้นที่การบันทึกยังคงสะสม การแก้ไขคือลบ Clarity ออกทั้งหมดหรือนำมาอยู่ภายใต้สถาปัตยกรรมการยินยอมเดียวกันกับ tracker อื่นๆ

ไว้ใจการมาสก์อัตโนมัติ

การตรวจจับฟิลด์ละเอียดอ่อนแบบ heuristic ของ Clarity จับกรณีที่ชัดเจนแต่พลาดกรณีเฉพาะของโดเมน — textarea "symptoms" ของเว็บไซต์สุขภาพ ฟิลด์ "account number" ของเว็บไซต์การเงินที่มีชื่อ แปลกๆ มาสก์อย่างชัดเจน อย่าพึ่งพาการตรวจจับ

ถือว่าการบันทึกเซสชันเป็นการวิเคราะห์

CNIL ได้ระบุอย่างชัดเจนว่าหมวดหมู่การบันทึกเซสชันใกล้เคียงกับการตลาดมากกว่าการวิเคราะห์ ฝั่งแรกจากมุมมองการยินยอม การควบคุม Clarity ภายใต้ความยินยอมเฉพาะการวิเคราะห์ป้องกันได้ก็ต่อเมื่อ การบันทึกถูกใช้เฉพาะสำหรับการวิจัย UX ภายในและไม่เคยแบ่งปันนอกองค์กร

ลืม payload ของเหตุการณ์ที่กำหนดเอง

โค้ดแอปพลิเคชันที่เรียก clarity("event", "name", customProperties) อาจ รั่วข้อมูลส่วนบุคคลเข้าสู่สตรีม Clarity ผ่าน payload ของ customProperties ตรวจสอบทุก call site และหลีกเลี่ยงการส่งตัวระบุผู้ใช้ ที่อยู่อีเมล หรือข้อมูลส่วนบุคคลใดๆ ใน property ของเหตุการณ์

รายการตรวจสอบการตรวจสอบ

คำถามที่เป็นรูปธรรมหกข้อเพื่อตอบสำหรับการปรับใช้ Clarity ที่สัมผัสกับการรับส่งข้อมูลของ EU, UK, บราซิล หรือแคลิฟอร์เนีย

Clarity อยู่ที่ไหนใน Stack ที่เน้นการยินยอม

การบันทึกเซสชันเป็นพื้นผิวการติดตามพฤติกรรมที่มีความหนาแน่นของข้อมูลสูงสุดในการปรับใช้ทั่วไป และ Clarity คือเครื่องมือที่ทำให้เป็นประชาธิปไตยอย่างเข้มงวดที่สุด ระดับราคาฟรีและการติดตั้งที่ ไม่มีแรงเสียดทานทำให้เป็นเส้นทางที่มีแรงต้านน้อยที่สุดสำหรับทีมที่ต้องการมองเห็นพฤติกรรม UX การติดตั้งที่ไม่มีแรงเสียดทานเดียวกันนั้นคือสิ่งที่ทำให้ Clarity เป็นเครื่องมือวิเคราะห์ที่กำหนดค่า ผิดพลาดบ่อยที่สุดในการตรวจสอบปี 2026 สถาปัตยกรรมที่ถูกต้องถือว่า Clarity เหมือน tracker ที่ ระบุตัวตนอื่นๆ ทุกตัว: ควบคุมมันด้วยความยินยอมอย่างชัดเจน มาสก์ฟิลด์ฟอร์มอย่างเข้มงวดโดยค่าเริ่มต้น บันทึกการแมปหมวดหมู่ และเชื่อมต่อ API การยินยอมเพื่อให้ primitive ของ SDK เองบังคับใช้สิ่งที่ CMP บันทึกไว้ หากทำถูกต้อง คุณค่าการวิจัย UX ที่เครื่องมือซื้อมาเพื่อจะได้รับการรักษาไว้ ขณะที่ การเปิดเผยตามกฎระเบียบลดลงเหลือเพียงส่วนเล็กๆ ของสิ่งที่การติดตั้งเริ่มต้นมี

← บล็อก อ่านทั้งหมด →