Panduan Integrasi Persetujuan Kuki Analitik Produk PostHog: Buku Panduan Penggunaan Sendiri dan Awan untuk 2026
PostHog ialah platform analitik produk yang dicapai oleh pasukan kejuruteraan apabila mereka mahukan analitik produk, main semula sesi, bendera ciri, percubaan, tinjauan, dan analitik web dalam satu tumpukan dan bukannya lima vendor yang dicantumkan bersama. Penggabungan itulah proposisi nilai. Itulah juga sebabnya mengapa penggunaan PostHog lalai membawa lebih banyak kewajipan persetujuan yang tertumpu berbanding hampir mana-mana alat lain yang akan dipasang oleh penerbit. Panggilan posthog.init() yang sama yang menangkap peristiwa produk boleh mula merekodkan sesi, menilai bendera ciri terhadap pengecam tetap, dan membaris tayangan tinjauan — dan setiap aktiviti tersebut melibatkan asas undang-undang yang berbeza di bawah GDPR, ePrivacy, dan CCPA. Berita baiknya ialah PostHog menghantar salah satu API persetujuan yang paling terperinci dalam ekosistem analitik; kerjanya adalah benar-benar menggunakannya. Panduan ini menerangkan cara menggunakan PostHog supaya pendirian undang-undang sepadan dengan realiti teknikal merentasi pemasangan sendiri dan PostHog Cloud, merentasi rantau AS dan EU, serta merentasi seluruh permukaan analitik, main semula, bendera, dan tinjauan.
Mengapa PostHog memerlukan persetujuan — dan mengapa jawapannya tidak sama untuk setiap modul
SDK web PostHog bukan tag halaman yang pasif. Pada permulaan lalai, SDK menetapkan satu atau lebih entri ketekunan pihak pertama — secara lalai skema gabungan kuki dan localStorage yang dikunci di bawah ph_{projectKey}_posthog — menghasilkan pengecam berbeza yang stabil, menangkap paparan halaman awal dengan perujuk, parameter UTM, dan pengecam klik, serta membuka saluran peristiwa jangka panjang ke hos pengingesan yang dikonfigurasi. Jika main semula sesi didayakan di peringkat projek, SDK juga mula mengalirkan rekod berterusan DOM yang dirender, koordinat tetikus, dan peristiwa input. Jika bendera ciri dikonfigurasi, SDK menilainya terhadap pengecam berbeza, menyimpan keputusan untuk sesi, dan memancarkan peristiwa $feature_flag_called bagi setiap penilaian.
Setiap aktiviti ini memetakan ke get persetujuan yang berbeza. Menyimpan pengecam berbeza ialah operasi penyimpanan dan akses di bawah Article 5(3) Arahan ePrivacy dan memerlukan persetujuan terdahulu, bebas diberikan, khusus, bermaklumat, dan tidak samar-samar di seluruh EEA, UK, dan mana-mana bidang kuasa yang telah mengimport standard yang sama. Menangkap peristiwa tingkah laku ialah pemprosesan data peribadi di bawah GDPR kerana gabungan pengecam, alamat IP, dan jejak tingkah laku mencukupi untuk mengasingkan individu. Main semula sesi berada dalam kategori yang lebih ketat di bawah panduan main semula sesi EDPB — main semula menangkap DOM yang dirender dan mana-mana medan input yang tidak bertopeng dan memerlukan persetujuan eksplisit, terperinci yang berbeza daripada persetujuan analitik generik. Penilaian bendera ciri adalah yang halus: semakan bendera yang mengembalikan boolean tidak sendirinya memerlukan persetujuan, tetapi menyimpan tugasan bendera pengguna ke pengecam stabil merentasi sesi memerlukan, kerana itulah cara percubaan berasaskan bendera mencipta data peringkat pengguna yang boleh dikesan.
Apa yang PostHog tulis sebelum persetujuan — dan apa yang mesti disekat
SDK Pelayar PostHog lalai menulis perkara berikut semasa permulaan: satu entri kuki dan localStorage gabungan di bawah ph_{projectKey}_posthog yang mengandungi pengecam berbeza, pengecam sesi, dan keputusan bendera ciri, ditambah, apabila main semula sesi didayakan, penimbal rakaman dalam ingatan tambahan yang mengosongkan ke titik akhir pengingesan setiap beberapa saat. SDK juga menghantar peristiwa $pageview segera dan, jika tangkapan automatik dihidupkan, setiap klik seterusnya, interaksi borang, dan klik marah di halaman.
Corak yang disyorkan adalah untuk memulakan PostHog dengan opt_out_capturing_by_default: true dan disable_session_recording: true, kemudian balikkan kedua-dua bendera setelah sepanduk persetujuan mengembalikan isyarat positif. Ini adalah pendirian integrasi yang kini disyorkan oleh dokumentasi PostHog, dan ia adalah pendirian yang bertahan daripada semakan pengawal selia kerana ia membalikkan lalai: tiada apa yang ditangkap sehingga persetujuan direkodkan, dan SDK menyediakan peralihan yang bersih dan bukannya modernisasi berasaskan keadaan.
Kuki, entri localStorage, dan pengecam yang disimpan oleh PostHog
SDK Pelayar 1.x menulis satu entri ketekunan setiap projek, dikunci di bawah ph_{projectKey}_posthog, dengan tamat tempoh lalai 365 hari. Pilihan init persistence mengawal mekanisme asas: cookie sahaja, localStorage sahaja, localStorage+cookie (lalai), sessionStorage, atau memory. Untuk penggunaan persetujuan-pertama, ketekunan memory adalah lalai yang betul apabila persetujuan belum diberikan — ia memastikan tiada pengecam yang melebihi sesi halaman — dengan peralihan ke localStorage+cookie setelah persetujuan ditukar. SDK juga menulis penanda opt-in atau opt-out di bawah __ph_opt_in_out_{projectKey} untuk mengingati pilihan pengguna merentasi lawatan; penanda itu sendiri ialah kuki yang diperlukan kerana ia menyimpan keputusan persetujuan.
Memetakan modul PostHog ke rangka kerja persetujuan
PostHog tidak melaksanakan IAB TCF atau IAB Global Privacy Platform secara asli, dan ia tidak dibina sebagai vendor ad-tech. Namun, ia berintegrasi dengan Google Consent Mode v2 melalui jambatan sisi penerbit, mendedahkan API opt-in dan opt-out asli, dan menghormati pengepala Do Not Track melalui pilihan init respect_dnt. Corak yang berfungsi dalam pengeluaran merawat setiap modul PostHog sebagai get berasingan yang terikat dengan isyarat CMP tertentu.
- Peristiwa analitik produk terikat dengan tujuan analitik. Dalam istilah TCF ini paling kerap ialah tujuan 8 (mengukur prestasi kandungan) digabungkan dengan tujuan 1 (menyimpan dan/atau mengakses maklumat). Untuk Consent Mode ini memetakan ke analytics_storage.
- Main semula sesi berada di belakang get yang lebih ketat. Main semula sesi PostHog menangkap DOM yang dirender dan mana-mana medan input yang tidak bertopeng, jadi opt-in peringkat keutamaan atau penyelidikan yang berbeza daripada analitik ialah pendirian yang boleh dipertahankan di bawah panduan EDPB.
- Bendera ciri dan percubaan boleh berjalan dengan penilaian dalam ingatan yang sementara di bawah asas kepentingan sah apabila matlamatnya hanya untuk mengubah halaman yang dirender. Tugasan bendera tetap yang terikat dengan pengecam stabil merentasi sesi memerlukan persetujuan yang sama seperti analitik, kerana itulah apabila bendera menjadi titik data peringkat pengguna yang boleh dikesan.
- Tinjauan dan maklum balas terikat dengan get yang sama seperti main semula sesi apabila mereka mengumpul input teks bebas, atau ke get analitik apabila mereka hanya mengumpul penilaian atau respons pilihan tunggal.
Corak integrasi yang berfungsi
Penggunaan rujukan mempunyai empat bahagian: CMP yang mendedahkan peristiwa perubahan persetujuan masa nyata, bootstrap tertunda yang memulakan PostHog dengan tangkapan dan main semula dilumpuhkan, pendengar persetujuan yang membalikkan opt_in_capturing dan suis rakaman apabila get yang berkaitan dibuka, dan laluan penarikan balik yang memanggil opt_out_capturing, menghentikan penimbal main semula, dan mengosongkan pengecam berterusan melalui API set semula SDK.
Pelaksanaan web
Corak paling bersih adalah untuk memuatkan SDK PostHog pada 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. Langgan peristiwa perubahan persetujuan CMP. Apabila kategori analitik beralih ke true, panggil posthog.set_config({ persistence: 'localStorage+cookie' }) diikuti dengan posthog.opt_in_capturing(); ini mendayakan semula tangkapan peristiwa dan peralihan ketekunan mula menulis pengecam berbeza. Apabila kategori main semula sesi beralih ke true, panggil posthog.startSessionRecording(). Apabila mana-mana get ditarik balik, panggil posthog.opt_out_capturing() untuk get analitik atau posthog.stopSessionRecording() untuk get main semula, luputkan entri ketekunan yang berkaitan melalui posthog.reset(), dan hantar permintaan pemadaman melalui API GDPR PostHog jika pengguna telah menggunakan hak pemadaman mereka.
Pemilihan rantau: PostHog Cloud AS vs EU vs sendiri
PostHog mengendalikan dua rantau awan — AS (us.posthog.com) dan EU (eu.posthog.com) — dan menyokong pemasangan sendiri pada infrastruktur sendiri pelanggan. Untuk trafik EEA dan UK, awan EU adalah lalai yang betul; ia mengekalkan pengingesan, pemprosesan, dan penyimpanan di dalam EEA dan mengurangkan pendedahan Schrems II yang dibawa oleh mana-mana penggunaan analitik rantau AS. Pilihan init api_host menetapkan rantau. PostHog sendiri memindahkan keseluruhan tumpukan ke infrastruktur sendiri penerbit, yang merupakan pendirian kediaman data terkuat tetapi tidak menghapuskan kewajipan persetujuan — asas undang-undang mengikut data, bukan pengendali. Pilihan mana-mana yang dipilih mesti dicerminkan dalam notis privasi dan rekod pemprosesan pengawal.
Tangkapan sisi pelayan
PostHog menyokong pengingesan peristiwa sisi pelayan melalui SDK Python, Node, Go, Ruby, dan PHP. Peristiwa sisi pelayan tidak dikecualikan daripada persetujuan — asas undang-undang mengikut data — tetapi pengingesan sisi pelayan memberi penerbit kawalan penuh ke atas medan yang dipancarkan dan bila. Corak biasa adalah untuk menangkap set peristiwa minimum hanya penting sisi pelayan di bawah kepentingan sah, kemudian memperkaya peristiwa tersebut dengan perincian tingkah laku daripada klien hanya setelah pengguna memberikan persetujuan analitik. Peristiwa sisi pelayan dan sisi klien bergabung pada pengecam berbeza yang sama apabila persetujuan telah beralih; sebelum persetujuan, peristiwa sisi pelayan dipancarkan dengan pengecam tanpa nama, sementara yang ditetapkan semula pada setiap sesi.
Mengesahkan integrasi dan jejak audit
Langkah pengesahan adalah apa yang diperiksa oleh pengawal selia dan apa yang paling kerap dilangkau oleh penerbit. Penggunaan PostHog yang diintegrasikan dengan betul mesti lulus empat ujian secara berurutan. Pertama, sesi pelayar yang bersih dengan sepanduk yang ditunjukkan tetapi tiada pilihan yang dibuat mesti menghasilkan sifar permintaan ke api_host yang dikonfigurasi di luar pengambilan fail SDK, sifar kuki ph_ dalam document.cookie, dan sifar entri ph_ dalam localStorage. Kedua, menolak analitik mesti mengekalkan keadaan itu — tiada tangkapan, tiada rakaman, tiada pengecam tetap. Ketiga, menerima analitik mesti menghasilkan peristiwa $opt_in segera, entri ketekunan ph_{projectKey}_posthog yang dijangka dengan atribut SameSite yang betul, dan trafik peristiwa yang mengalir ke hos yang dikonfigurasi. Keempat, menarik balik persetujuan selepas fakta mesti segera menghentikan tangkapan dan main semula lanjut, luputkan pengecam tetap, dan mencetuskan permintaan pemadaman melalui API GDPR PostHog jika pengguna telah menggunakan pemadaman.
Jangkaan jejak audit di bawah garis panduan sepanduk kuki EDPB 2023 dan keutamaan pasukan petugas 2026 yang diperbaharui adalah bahawa penerbit boleh membuktikan, untuk mana-mana peristiwa tertentu dalam projek PostHog, bahawa pengguna yang menjana peristiwa itu telah memberikan persetujuan yang sah pada saat tangkapan. Corak standard adalah untuk menetapkan versi persetujuan dan cap waktu sebagai sifat orang pada ID berbeza melalui posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) supaya mana-mana peristiwa individu boleh dikesan kembali ke entri log persetujuan tertentu. Penggunaan yang digerbang dengan betul, digabungkan dengan pemilihan rantau yang sepadan dengan penonton, ketekunan yang lalai kepada memori, dan laluan pemadaman yang diaktifkan semasa penarikan balik, adalah apa yang mengubah PostHog daripada risiko kepekatan kawal selia menjadi pusat tumpukan analitik produk yang boleh dipertahankan.