Mengapa PostHog memerlukan consent — dan mengapa jawabannya tidak sama untuk setiap modul

SDK web PostHog bukan tag halaman pasif. Pada inisialisasi default, SDK menetapkan satu atau lebih entri persistensi pihak pertama — secara default skema kombinasi cookie plus localStorage yang dikunci di bawah ph_{projectKey}_posthog — menghasilkan pengenal berbeda yang stabil, menangkap tampilan halaman awal dengan referrer, parameter UTM, dan pengenal klik, serta membuka saluran peristiwa berumur panjang ke host ingesti yang dikonfigurasi. Jika pemutaran ulang sesi diaktifkan di tingkat proyek, SDK juga mulai mengalirkan rekaman berkelanjutan dari DOM yang dirender, koordinat mouse, dan peristiwa input. Jika feature flag dikonfigurasi, SDK mengevaluasinya terhadap pengenal berbeda, mempertahankan keputusan untuk sesi tersebut, dan memancarkan peristiwa $feature_flag_called untuk setiap evaluasi.

Setiap aktivitas ini memetakan ke gerbang consent yang berbeda. Mempertahankan pengenal berbeda adalah operasi penyimpanan-dan-akses di bawah Pasal 5(3) Direktif ePrivacy dan memerlukan consent sebelumnya, yang diberikan secara bebas, spesifik, terinformasi, dan tidak ambigu di seluruh EEA, UK, dan yurisdiksi mana pun yang telah mengimpor standar yang sama. Menangkap peristiwa perilaku adalah pemrosesan data pribadi di bawah GDPR karena kombinasi pengenal, alamat IP, dan jejak perilaku cukup untuk mengidentifikasi seorang individu. Pemutaran ulang sesi berada dalam kategori yang lebih ketat dan terpisah di bawah panduan pemutaran ulang sesi EDPB — replay menangkap DOM yang dirender dan bidang input apa pun yang tidak disensor, serta memerlukan consent yang eksplisit dan granular yang berbeda dari consent analitik umum. Evaluasi feature flag adalah yang paling halus: pemeriksaan flag yang mengembalikan boolean tidak sendirinya memerlukan consent, tetapi mempertahankan penugasan flag pengguna ke pengenal stabil di seluruh sesi memang memerlukan, karena itulah cara eksperimentasi berbasis flag membuat data tingkat pengguna yang dapat dilacak.

Apa yang ditulis PostHog sebelum consent — dan apa yang harus disupres

SDK Browser PostHog default menulis hal berikut saat inisialisasi: satu entri cookie dan localStorage gabungan di bawah ph_{projectKey}_posthog yang berisi pengenal berbeda, pengenal sesi, dan keputusan feature flag, ditambah, ketika pemutaran ulang sesi diaktifkan, buffer perekaman dalam memori tambahan yang di-flush ke endpoint ingesti setiap beberapa detik. SDK juga mengirim peristiwa $pageview segera dan, jika autocapture aktif, setiap klik, interaksi formulir, dan rage-click berikutnya di halaman.

Pola yang direkomendasikan adalah menginisialisasi PostHog dengan opt_out_capturing_by_default: true dan disable_session_recording: true, kemudian membalik kedua flag tersebut setelah banner consent mengembalikan sinyal positif. Ini adalah postur integrasi yang kini direkomendasikan oleh dokumentasi PostHog, dan ini adalah postur yang bertahan dari tinjauan regulator karena membalik defaultnya: tidak ada yang ditangkap hingga consent dicatat, dan SDK menyediakan transisi yang bersih daripada retrofit stateful.

Cookie, entri localStorage, dan pengenal yang dipertahankan PostHog

SDK Browser 1.x menulis satu entri persistensi per proyek, dikunci di bawah ph_{projectKey}_posthog, dengan kedaluwarsa 365 hari secara default. Opsi init persistence mengontrol mekanisme yang mendasarinya: hanya cookie, hanya localStorage, localStorage+cookie (defaultnya), sessionStorage, atau memory. Untuk deployment yang mengutamakan consent, persistensi memory adalah default yang tepat ketika consent belum diberikan — ini memastikan tidak ada pengenal yang bertahan lebih dari sesi halaman — dengan transisi ke localStorage+cookie setelah consent diaktifkan. SDK juga menulis penanda opt-in atau opt-out di bawah __ph_opt_in_out_{projectKey} untuk mengingat pilihan pengguna di seluruh kunjungan; penanda itu sendiri adalah cookie yang diperlukan secara ketat karena mempertahankan keputusan consent.

Memetakan modul PostHog ke kerangka consent

PostHog tidak secara native mengimplementasikan IAB TCF atau IAB Global Privacy Platform, dan tidak dibangun sebagai vendor ad-tech. Namun, ia terintegrasi dengan Google Consent Mode v2 melalui bridging sisi publisher, mengekspos API opt-in dan opt-out native, dan menghormati header Do Not Track melalui opsi init respect_dnt. Pola yang berfungsi dalam produksi memperlakukan setiap modul PostHog sebagai gerbang terpisah yang terikat ke sinyal CMP tertentu.

• Peristiwa analitik produk terikat ke tujuan analitik. Dalam istilah TCF, ini paling umum adalah tujuan 8 (mengukur kinerja konten) dikombinasikan dengan tujuan 1 (menyimpan dan/atau mengakses informasi). Untuk Consent Mode, ini memetakan ke analytics_storage.
• Pemutaran ulang sesi berada di balik gerbang yang lebih ketat. Pemutaran ulang sesi PostHog menangkap DOM yang dirender dan bidang input apa pun yang tidak disensor, sehingga opt-in tingkat preferensi atau penelitian yang berbeda dari analitik adalah postur yang dapat dipertahankan di bawah panduan EDPB.
• Feature flag dan eksperimentasi dapat berjalan dengan evaluasi efemer dalam memori di bawah dasar legitimate interest ketika tujuannya hanya untuk memvariasikan halaman yang dirender. Penugasan flag persisten yang terikat ke pengenal stabil di seluruh sesi memerlukan consent yang sama dengan analitik, karena itulah saat flag menjadi titik data tingkat pengguna yang dapat dilacak.
• Survei dan umpan balik terikat ke gerbang yang sama dengan pemutaran ulang sesi ketika mereka mengumpulkan input teks bebas, atau ke gerbang analitik ketika mereka hanya mengumpulkan penilaian atau respons pilihan tunggal.

Pola integrasi yang berfungsi

Deployment referensi memiliki empat bagian: CMP yang mengekspos peristiwa perubahan consent secara real-time, bootstrap yang ditunda yang menginisialisasi PostHog dengan capture dan replay dinonaktifkan, pendengar consent yang membalik opt_in_capturing dan sakelar perekaman ketika gerbang yang relevan terbuka, dan jalur penarikan yang memanggil opt_out_capturing, menghentikan buffer replay, dan menghapus pengenal persisten melalui API reset SDK.

Implementasi web

Pola paling bersih adalah memuat SDK PostHog di setiap halaman tetapi memanggil posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) sebagai bootstrap awal. Berlangganan ke peristiwa perubahan consent CMP. Ketika kategori analitik beralih ke true, panggil posthog.set_config({ persistence: 'localStorage+cookie' }) diikuti oleh posthog.opt_in_capturing(); ini mengaktifkan kembali pengambilan peristiwa dan transisi persistensi mulai menulis pengenal berbeda. Ketika kategori pemutaran ulang sesi beralih ke true, panggil posthog.startSessionRecording(). Ketika salah satu gerbang ditarik, panggil posthog.opt_out_capturing() untuk gerbang analitik atau posthog.stopSessionRecording() untuk gerbang replay, kedaluwarsa entri persistensi yang relevan melalui posthog.reset(), dan kirim permintaan penghapusan melalui API GDPR PostHog jika pengguna telah menggunakan hak penghapusannya.

Pemilihan wilayah: PostHog Cloud AS vs EU vs self-hosted

PostHog mengoperasikan dua wilayah cloud — AS (us.posthog.com) dan EU (eu.posthog.com) — dan mendukung instalasi self-hosted di infrastruktur pelanggan sendiri. Untuk lalu lintas EEA dan UK, cloud EU adalah default yang tepat; ini menjaga ingesti, pemrosesan, dan penyimpanan di dalam EEA dan mengurangi paparan Schrems II yang dibawa oleh deployment analitik wilayah AS mana pun. Opsi init api_host menetapkan wilayah. PostHog self-hosted memindahkan seluruh tumpukan ke infrastruktur publisher sendiri, yang merupakan postur residensi data terkuat tetapi tidak menghapus kewajiban consent — dasar hukum mengikuti data, bukan operator. Pilihan mana pun yang dipilih harus tercermin dalam pemberitahuan privasi dan catatan pemrosesan pengontrol.

Pengambilan sisi server

PostHog mendukung ingesti peristiwa sisi server melalui SDK Python, Node, Go, Ruby, dan PHP. Peristiwa sisi server tidak dikecualikan dari consent — dasar hukum mengikuti data — tetapi ingesti sisi server memberi publisher kontrol penuh atas bidang mana yang dipancarkan dan kapan. Pola umum adalah menangkap set peristiwa minimal yang hanya esensial sisi server di bawah legitimate interest, kemudian memperkaya peristiwa tersebut dengan detail perilaku dari klien hanya setelah pengguna memberikan consent analitik. Peristiwa sisi server dan sisi klien bergabung pada pengenal berbeda yang sama ketika consent telah diaktifkan; sebelum consent, peristiwa sisi server dipancarkan dengan pengenal anonim dan efemer yang direset pada setiap sesi.

Memvalidasi integrasi dan jejak audit

Langkah validasi adalah apa yang diperiksa regulator dan yang paling sering dilewati publisher. Deployment PostHog yang terintegrasi dengan benar harus lulus empat pengujian secara berurutan. Pertama, sesi browser bersih dengan banner ditampilkan tetapi tidak ada pilihan yang dibuat harus menghasilkan nol permintaan ke api_host yang dikonfigurasi di luar pengambilan file SDK, nol cookie ph_ di document.cookie, dan nol entri ph_ di localStorage. Kedua, menolak analitik harus mempertahankan status tersebut — tidak ada pengambilan, tidak ada perekaman, tidak ada pengenal persisten. Ketiga, menerima analitik harus menghasilkan peristiwa $opt_in segera, entri persistensi ph_{projectKey}_posthog yang diharapkan dengan atribut SameSite yang benar, dan lalu lintas peristiwa yang mengalir ke host yang dikonfigurasi. Keempat, menarik consent setelah itu harus segera menghentikan pengambilan dan replay lebih lanjut, kedaluwarsa pengenal persisten, dan memicu permintaan penghapusan melalui API GDPR PostHog jika pengguna telah menggunakan penghapusan.

Ekspektasi jejak audit di bawah panduan banner cookie EDPB 2023 dan prioritas gugus tugas 2026 yang diperbarui adalah bahwa publisher dapat membuktikan, untuk peristiwa apa pun dalam proyek PostHog, bahwa pengguna yang menghasilkannya telah memberikan consent yang valid pada saat pengambilan. Pola standar adalah menetapkan versi consent dan stempel waktu sebagai properti orang pada ID berbeda melalui posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) sehingga setiap peristiwa individual dapat ditelusuri kembali ke entri log consent tertentu. Deployment yang digerbang dengan benar, dipasangkan dengan pemilihan wilayah yang sesuai dengan audiens, persistensi yang default ke memori, dan jalur penghapusan yang diaktifkan saat penarikan, adalah apa yang mengubah PostHog dari risiko konsentrasi regulasi menjadi pusat tumpukan analitik produk yang dapat dipertahankan.