Apa yang Sebenarnya Dirakam oleh Clarity

Clarity SDK (dimuatkan dari www.clarity.ms/tag/{project_id}) memulakan objek clarity global dan mengenal pasti pelawat dengan kuki milik Microsoft bernama _clck, bersama kuki sesi _clsk. Dari saat itu, skrip menangkap aliran tingkah laku yang padat:

• Input tetikus dan sentuhan — setiap pergerakan, klik, ketuk, tatal, dan isyarat dirakam dengan cap masa dan koordinat.
• Interaksi borang — peristiwa fokus, kabur, dan input pada setiap medan borang, ditambah teks medan tidak sensitif jika penyembunyian tidak dikonfigurasi.
• Tangkapan skrin DOM — tangkapan skrin penuh DOM halaman secara berkala supaya ulangan sesi dapat membina semula keadaan visual yang tepat pada bila-bila masa.
• Peristiwa tersuai — sebarang peristiwa yang aplikasi pancarkan secara eksplisit melalui panggilan clarity("event", "name").
• Data prestasi dan ralat — ralat JavaScript, kegagalan rangkaian, dan masa vital web teras.
• Data pengecam — kuki milik Clarity ditambah geolokasi yang diperoleh daripada IP dan cap jari ejen pengguna.

Kombinasi tersebut — terutamanya tangkapan skrin DOM dan penangkapan medan borang — menjadikan Clarity secara fungsional setara dengan rakaman video sesi pelawat. Pengelasan kawal selia di bawah GDPR adalah mudah: ini adalah pemprosesan data peribadi, kuki tidak penting, data melintasi sempadan ke infrastruktur AS Microsoft, dan asas undang-undang yang diperlukan adalah persetujuan. Panduan CNIL 2024 mengenai rakaman sesi tidak samar-samar mengenai perkara ini dan secara eksplisit menamakan alat dalam kategori Clarity.

Risiko Data Sensitif

Alat rakaman sesi mempunyai bahaya privasi khusus yang tidak dimiliki oleh alat analitik lain: ia boleh menangkap data peribadi sensitif secara tidak sengaja. Pengguna yang menaip nombor kad kredit, kondisi kesihatan, afiliasi agama, atau pengenal pasti nasional ke dalam mana-mana medan borang dirakam oleh Clarity jika medan itu tidak disembunyikan secara eksplisit. Di bawah GDPR ini adalah pemprosesan data peribadi sensitif Article 9, yang memerlukan persetujuan opt-in eksplisit dan jarang dilindungi oleh keputusan persetujuan pemasaran umum.

Clarity menyokong konfigurasi penyembunyian kandungan yang menyembunyikan medan tertentu daripada rakaman, tetapi tingkah laku lalai menangkap segala-galanya. Pendekatan yang boleh dipertahankan dalam audit adalah menyembunyikan secara agresif — anggap setiap medan borang sensitif sehingga terbukti sebaliknya — dan mendokumentasikan keputusan penyembunyian secara eksplisit.

Kawalan Privasi Clarity Asli

Microsoft telah melabur dalam kawalan privasi Clarity selama dua tahun yang lalu. Platform ini kini mendedahkan beberapa primitif yang boleh dimanfaatkan oleh integrasi CMP.

Atribut topeng

Menambah data-clarity-mask="true" pada elemen DOM menyembunyikan kandungannya daripada rakaman sesi. Menambah data-clarity-unmask="true" pada elemen anak mengatasi topeng untuk subtree tersebut. Lalai yang betul untuk mana-mana medan borang yang boleh mengandungi data peribadi adalah menyembunyikan, kemudian nyah-sembunyikan secara eksplisit di mana ia selamat.

API persetujuan

Clarity mendedahkan panggilan clarity("consent") yang, apabila dipanggil, memberi isyarat bahawa persetujuan telah diberikan dan SDK harus meneruskan. Tanpa panggilan ini, SDK boleh dikonfigurasi untuk berhenti selepas muatan awal. Ini adalah primitif yang tepat untuk integrasi CMP pada sisi pengaktifan.

Penyembunyian IP dan pengendalian pengecam

Tetapan projek Clarity mendedahkan pilihan untuk pemotongan IP dan penyembunyian pengecam. Mengaktifkan ini adalah langkah pertahanan mendalam di atas penghalang CMP; ia tidak menggantikan persetujuan.

Penyembunyian automatik kandungan sensitif

Keluaran Clarity terkini cuba mengesan secara automatik medan sensitif (corak kad kredit, medan kata laluan, medan bernama "ssn" atau seumpamanya) dan menyembunyikannya secara lalai. Pengesanan adalah heuristik dan tidak lengkap; jangan bergantung padanya sebagai satu-satunya garis pertahanan.

Integrasi CMP Langkah demi Langkah

Seni bina yang boleh dipercayai adalah menangguhkan Clarity SDK sepenuhnya sehingga persetujuan diberikan, kemudian mengaktifkannya secara eksplisit melalui API persetujuan.

1. Buang tag lalai daripada kepala dokumen

Coretan pemasangan Clarity adalah skrip sebaris tunggal yang memulakan SDK semasa pemuatan halaman. Gantikannya dengan elemen skrip pemegang tempat yang type-nya adalah text/plain dan data-category-nya adalah analytics atau marketing bergantung pada cara CMP anda mengategorikan alat rakaman sesi.

2. Putuskan pemetaan kategori

Rakaman sesi adalah kategori yang dipertikaikan. CNIL telah memperlakukannya pelbagai kali sebagai analitik (apabila data digunakan untuk penyelidikan UX dalaman) dan sebagai pemasaran (apabila data menyuburkan keputusan pemperibadian atau perkongsian luaran). Pemetaan konservatif adalah pemasaran; kedudukan yang boleh dipertahankan dalam audit memerlukan anda untuk spesifik tentang bagaimana rakaman sebenarnya digunakan.

3. Konfigurasikan penyembunyian agresif sebelum pengaktifan

Tambah data-clarity-mask="true" pada setiap elemen borang, setiap medan input, setiap bekas yang boleh menyimpan data peribadi. Dasar lalai adalah sembunyikan-secara-lalai dengan pengecualian nyah-sembunyikan eksplisit untuk elemen yang diketahui selamat (tajuk halaman, label navigasi, blok kandungan awam).

4. Aktifkan Clarity daripada panggilan balik persetujuan

Apabila CMP mencetuskan peristiwa kategori-diterima yang berkaitan, tulis semula tag skrip pemegang tempat dan panggil clarity("consent") untuk memberikan kebenaran SDK untuk meneruskan. Peristiwa beratur yang telah ditukar semasa tempoh pra-persetujuan akan dibilas kemudian.

5. Kendalikan pembatalan secara eksplisit

Jika pengguna membatalkan persetujuan, Clarity SDK tidak mempunyai panggilan "henti rakaman" yang bersih setara dengan API pengaktifan. Corak praktikal adalah memanggil clarity("consent", false) jika disokong dalam versi SDK anda, dan tambahan membersihkan kuki Clarity di sisi klien. Untuk pemadaman lengkap rakaman sejarah, gunakan aliran kerja pemadaman data dalam antara muka pentadbir Clarity atau API pemadaman.

Perangkap Biasa

Empat kesilapan integrasi menyumbang kepada majoriti penemuan audit dalam penggunaan Clarity.

Memasang Clarity "hanya untuk melihat apa yang pelawat lakukan"

Corak paling biasa: pengurus produk memasang Clarity untuk menyelidik masalah UX, tidak pernah mengaktifkan penghalang persetujuan, tidak pernah mengkonfigurasi penyembunyian, dan melupakan skrip tersebut. Permukaan rakaman terus terkumpul. Pemulihan adalah sama ada mengalih keluar Clarity sepenuhnya atau membawanya di bawah seni bina persetujuan yang sama seperti setiap penjejak lain.

Mempercayai penyembunyian automatik

Pengesanan medan sensitif heuristik Clarity menangkap kes-kes yang jelas tetapi terlepas yang khusus domain — kawasan teks "gejala" laman web penjagaan kesihatan, medan "nombor akaun" laman web kewangan dengan nama yang unik. Sembunyikan secara eksplisit; jangan bergantung pada pengesanan.

Menganggap rakaman sesi sebagai analitik

CNIL telah menegaskan bahawa kategori rakaman sesi lebih dekat dengan pemasaran daripada analitik pihak pertama dari perspektif persetujuan. Menghalang Clarity hanya di bawah persetujuan analitik boleh dipertahankan hanya jika rakaman digunakan secara eksklusif untuk penyelidikan UX dalaman dan tidak pernah dikongsi di luar organisasi.

Melupakan muatan peristiwa tersuai

Kod aplikasi yang memanggil clarity("event", "name", customProperties) boleh membocorkan data peribadi ke dalam aliran Clarity melalui muatan customProperties. Audit setiap tapak panggilan dan elakkan menghantar pengecam pengguna, alamat e-mel, atau sebarang data peribadi dalam sifat peristiwa.

Senarai Semak Audit

Enam soalan konkrit untuk dijawab bagi mana-mana penggunaan Clarity yang menyentuh trafik EU, UK, Brazil, atau California.

• Adakah Clarity menunggu persetujuan? Buka halaman dalam tetingkap peribadi dan sahkan tiada permintaan clarity.ms tercetus sebelum sepanduk diterima.
• Adakah penyembunyian agresif? Sahkan setiap medan borang dan setiap bekas dengan kandungan yang berpotensi peribadi mempunyai data-clarity-mask yang diterapkan.
• Adakah pemetaan kategori didokumentasikan? Sahkan terdapat rekod bertulis sama ada Clarity dihalang di bawah analitik atau pemasaran, dengan alasan.
• Adakah API persetujuan disambungkan? Sahkan panggilan balik CMP memanggil clarity("consent") semasa pemberian dan yang setara semasa pembatalan.
• Adakah peristiwa tersuai diaudit? Sahkan panggilan clarity("event", ...) tidak menghantar data pengenalan atau sensitif dalam muatan sifat mereka.
• Adakah pemadaman diautomasikan? Sahkan permintaan DSAR mencetuskan aliran kerja pemadaman Clarity, bukan tiket sokongan manual.

Di Mana Clarity Sesuai dalam Tumpukan Persetujuan-Pertama

Rakaman sesi adalah permukaan penjejakan tingkah laku dengan ketumpatan maklumat tertinggi dalam penggunaan biasa, dan Clarity adalah alat yang telah mendemokratikannya paling agresif. Tahap harga percuma dan pemasangan tanpa geseran menjadikannya laluan rintangan paling sedikit untuk mana-mana pasukan yang mahukan keterlihatan ke dalam tingkah laku UX. Pemasangan bebas-geseran yang sama itulah yang menjadikan Clarity alat analitik yang paling biasa dikonfigurasi salah dalam audit 2026. Seni bina yang betul melayan Clarity seperti setiap penjejak pengenal lain: halangnya di sebalik persetujuan eksplisit, sembunyikan medan borang secara agresif secara lalai, dokumenkan pemetaan kategori, dan sambungkan API persetujuan supaya primitif SDK sendiri menguatkuasakan apa yang CMP rekodkan. Dilakukan dengan betul, nilai penyelidikan UX yang alat itu dibeli dikekalkan sementara pendedahan kawal selia turun kepada sebahagian kecil daripada apa yang pemasangan lalai bawa.