Apa yang Sebenarnya Direkam Clarity

Clarity SDK (dimuat dari www.clarity.ms/tag/{project_id}) menginisialisasi objek clarity global dan mengidentifikasi pengunjung dengan cookie milik Microsoft bernama _clck, bersama cookie sesi _clsk. Sejak saat itu, skrip menangkap aliran perilaku yang padat:

• Masukan mouse dan sentuh — setiap gerakan, klik, ketukan, gulir, dan gestur direkam dengan cap waktu dan koordinat.
• Interaksi formulir — kejadian fokus, blur, dan input pada setiap bidang formulir, ditambah teks bidang yang tidak sensitif jika masking tidak dikonfigurasi.
• Snapshot DOM — snapshot penuh halaman DOM secara berkala agar pemutaran ulang sesi dapat merekonstruksi keadaan visual yang tepat kapan saja.
• Kejadian khusus — kejadian apa pun yang secara eksplisit dipancarkan aplikasi melalui panggilan clarity("event", "name").
• Data kinerja dan kesalahan — kesalahan JavaScript, kegagalan jaringan, dan pengaturan waktu core web vitals.
• Data pengenal — cookie milik Clarity ditambah geolokasi berbasis IP dan fingerprinting agen pengguna.

Kombinasi tersebut — terutama snapshot DOM dan penangkapan bidang formulir — membuat Clarity setara secara fungsional dengan rekaman video sesi pengunjung. Klasifikasi regulasi di bawah GDPR sudah jelas: ini adalah pemrosesan data pribadi, cookie bersifat non-esensial, data melintas batas ke infrastruktur AS Microsoft, dan dasar hukum yang diperlukan adalah persetujuan. Panduan CNIL 2024 tentang perekaman sesi tidak ambigu pada poin ini dan secara eksplisit menyebut alat-alat dalam kategori Clarity.

Risiko Data Sensitif

Alat perekaman sesi memiliki bahaya privasi khusus yang tidak dimiliki alat analitik lain: mereka dapat menangkap data pribadi sensitif secara tidak sengaja. Pengguna yang mengetik nomor kartu kredit, kondisi kesehatan, afiliasi agama, atau pengenal nasional ke bidang formulir mana pun akan direkam oleh Clarity jika bidang tersebut tidak secara eksplisit disamarkan. Di bawah GDPR ini adalah pemrosesan data pribadi sensitif Article 9, yang memerlukan persetujuan opt-in eksplisit dan jarang dicakup oleh keputusan persetujuan pemasaran umum.

Clarity mendukung konfigurasi masking konten yang menyembunyikan bidang tertentu dari perekaman, tetapi perilaku default merekam segalanya. Pendekatan yang tahan audit adalah dengan melakukan masking secara agresif — menganggap setiap bidang formulir sensitif sampai terbukti sebaliknya — dan mendokumentasikan keputusan masking secara eksplisit.

Kontrol Privasi Asli Clarity

Microsoft telah berinvestasi dalam kontrol privasi Clarity selama dua tahun terakhir. Platform ini kini mengekspos beberapa primitif yang dapat dimanfaatkan oleh integrasi CMP.

Atribut mask

Menambahkan data-clarity-mask="true" ke elemen DOM menyembunyikan kontennya dari perekaman sesi. Menambahkan data-clarity-unmask="true" ke elemen anak menggantikan mask untuk subtree tersebut. Default yang tepat untuk bidang formulir apa pun yang mungkin berisi data pribadi adalah masking, kemudian unmask secara eksplisit di tempat yang aman.

API persetujuan

Clarity mengekspos panggilan clarity("consent") yang, ketika dipanggil, menandakan bahwa persetujuan telah diberikan dan SDK boleh melanjutkan. Tanpa panggilan ini, SDK dapat dikonfigurasi untuk berhenti setelah pemuatan awal. Ini adalah primitif yang tepat untuk integrasi CMP di sisi aktivasi.

Masking IP dan penanganan pengenal

Pengaturan proyek Clarity mengekspos opsi untuk pemotongan IP dan masking pengenal. Mengaktifkan ini adalah tindakan pertahanan berlapis di atas pembatasan CMP; ini tidak menggantikan persetujuan.

Masking otomatis konten sensitif

Rilis Clarity terbaru mencoba mendeteksi otomatis bidang sensitif (pola kartu kredit, bidang kata sandi, bidang bernama “ssn” atau serupa) dan melakukan masking secara default. Deteksinya heuristik dan tidak lengkap; jangan mengandalkannya sebagai satu-satunya lini pertahanan.

Integrasi CMP Langkah demi Langkah

Arsitektur yang andal adalah menunda Clarity SDK sepenuhnya hingga persetujuan diberikan, lalu mengaktifkannya secara eksplisit melalui API persetujuan.

1. Hapus tag default dari kepala dokumen

Cuplikan instalasi Clarity adalah skrip inline tunggal yang menginisialisasi SDK saat halaman dimuat. Ganti dengan elemen skrip placeholder yang type-nya adalah text/plain dan data-category-nya adalah analytics atau marketing tergantung bagaimana CMP Anda mengategorikan alat perekaman sesi.

2. Tentukan pemetaan kategori

Perekaman sesi adalah kategori yang diperdebatkan. CNIL telah memperlakukannya secara beragam sebagai analitik (ketika data digunakan untuk penelitian UX internal) dan sebagai pemasaran (ketika data memberi makan keputusan personalisasi atau berbagi eksternal). Pemetaan konservatif adalah pemasaran; posisi yang tahan audit mengharuskan Anda spesifik tentang bagaimana rekaman sebenarnya digunakan.

3. Konfigurasikan masking agresif sebelum aktivasi

Tambahkan data-clarity-mask="true" ke setiap elemen formulir, setiap bidang input, setiap kontainer yang bisa menyimpan data pribadi. Kebijakan default adalah mask-by-default dengan pengecualian unmask eksplisit untuk elemen yang diketahui aman (judul halaman, label navigasi, blok konten publik).

4. Aktifkan Clarity dari callback persetujuan

Ketika CMP memicu kejadian kategori-diterima yang relevan, tulis ulang tag skrip placeholder dan panggil clarity("consent") untuk memberikan izin SDK melanjutkan. Kejadian yang diantrekan yang telah di-buffer selama periode pra-persetujuan kemudian akan dikosongkan.

5. Tangani pencabutan secara eksplisit

Jika pengguna mencabut persetujuan, Clarity SDK tidak memiliki panggilan bersih untuk menghentikan perekaman yang setara dengan API aktivasi. Pola praktisnya adalah memanggil clarity("consent", false) jika didukung di versi SDK Anda, dan juga menghapus cookie Clarity di sisi klien. Untuk penghapusan lengkap rekaman historis, gunakan alur kerja penghapusan data di UI admin Clarity atau API penghapusan.

Jebakan Umum

Empat kesalahan integrasi menyumbang sebagian besar temuan audit pada penerapan Clarity.

Memasang Clarity hanya untuk melihat apa yang dilakukan pengunjung

Pola paling umum: manajer produk memasang Clarity untuk meneliti masalah UX, tidak pernah mengaktifkan pembatasan persetujuan, tidak pernah mengonfigurasi masking, dan melupakan skrip tersebut. Permukaan perekaman terus menumpuk. Remediasinya adalah menghapus Clarity sepenuhnya atau membawanya di bawah arsitektur persetujuan yang sama seperti setiap pelacak lainnya.

Mempercayai auto-masking

Deteksi bidang sensitif heuristik Clarity menangkap kasus-kasus yang jelas tetapi melewatkan yang spesifik domain — textarea gejala situs layanan kesehatan, bidang nomor rekening situs keuangan dengan nama yang tidak biasa. Lakukan masking secara eksplisit; jangan mengandalkan deteksi.

Memperlakukan perekaman sesi sebagai analitik

CNIL telah secara eksplisit menyatakan bahwa kategori perekaman sesi lebih dekat ke pemasaran daripada analitik pihak pertama dari perspektif persetujuan. Membatasi Clarity di bawah persetujuan analitik-saja hanya dapat dipertahankan jika rekaman digunakan secara eksklusif untuk penelitian UX internal dan tidak pernah dibagikan di luar organisasi.

Melupakan muatan kejadian khusus

Kode aplikasi yang memanggil clarity("event", "name", customProperties) dapat membocorkan data pribadi ke dalam aliran Clarity melalui muatan customProperties. Audit setiap situs panggilan dan hindari meneruskan pengenal pengguna, alamat email, atau data pribadi apa pun dalam properti kejadian.

Daftar Periksa Audit

Enam pertanyaan konkret untuk dijawab untuk penerapan Clarity apa pun yang menyentuh lalu lintas EU, UK, Brasil, atau California.

• Apakah Clarity menunggu persetujuan? Buka halaman di jendela pribadi dan konfirmasi tidak ada permintaan clarity.ms yang terpicu sebelum spanduk diterima.
• Apakah masking agresif? Konfirmasi setiap bidang formulir dan setiap kontainer dengan konten yang berpotensi pribadi memiliki data-clarity-mask yang diterapkan.
• Apakah pemetaan kategori terdokumentasi? Konfirmasi ada catatan tertulis tentang apakah Clarity dibatasi di bawah analitik atau pemasaran, beserta alasannya.
• Apakah API persetujuan terhubung? Konfirmasi callback CMP memanggil clarity("consent") saat diberikan dan yang setara saat dicabut.
• Apakah kejadian khusus diaudit? Konfirmasi panggilan clarity("event", ...) tidak meneruskan data pengenal atau sensitif dalam muatan propertinya.
• Apakah penghapusan diotomatiskan? Konfirmasi permintaan DSAR memicu alur kerja penghapusan Clarity, bukan tiket dukungan manual.

Di Mana Clarity Cocok dalam Tumpukan Utamakan Persetujuan

Perekaman sesi adalah permukaan pelacakan perilaku dengan kepadatan informasi tertinggi dalam penerapan umum, dan Clarity adalah alat yang paling agresif mendemokratisasinya. Tingkatan harga gratis dan instalasi tanpa hambatan menjadikannya jalan dengan hambatan paling sedikit bagi tim mana pun yang ingin visibilitas ke dalam perilaku UX. Instalasi tanpa hambatan yang sama itulah yang membuat Clarity menjadi alat analitik yang paling sering salah dikonfigurasi dalam audit 2026. Arsitektur yang tepat memperlakukan Clarity seperti setiap pelacak pengidentifikasi lainnya: membatasinya di balik persetujuan eksplisit, melakukan masking bidang formulir secara agresif secara default, mendokumentasikan pemetaan kategori, dan menghubungkan API persetujuan sehingga primitif SDK sendiri menegakkan apa yang dicatat CMP. Jika dilakukan dengan benar, nilai penelitian UX yang menjadi alasan pembelian alat ini dipertahankan sementara paparan regulasi turun menjadi sebagian kecil dari apa yang dibawa oleh instalasi default.