ทำไม PostHog จึงต้องการความยินยอม — และทำไมคำตอบจึงไม่เหมือนกันสำหรับทุกโมดูล

Web SDK ของ PostHog ไม่ใช่แท็กหน้าเว็บแบบ passive ในการเริ่มต้นแบบมาตรฐาน SDK จะตั้งค่ารายการความคงทนของฝ่ายแรกหนึ่งรายการหรือมากกว่า โดยค่าเริ่มต้นคือสคีมคุกกี้รวมบวก localStorage ที่มีคีย์ภายใต้ ph_{projectKey}_posthog สร้างตัวระบุที่แตกต่างที่เสถียร บันทึกการดูหน้าเว็บเริ่มต้นพร้อมผู้อ้างอิง พารามิเตอร์ UTM และตัวระบุคลิก และเปิดช่องสัญญาณเหตุการณ์ที่ยาวนานไปยังโฮสต์การนำเข้าที่กำหนดค่าไว้ หากเปิดใช้การเล่นซ้ำเซสชันในระดับโปรเจกต์ SDK จะเริ่มสตรีมบันทึกต่อเนื่องของ DOM ที่แสดงผล พิกัดเมาส์ และเหตุการณ์การป้อนข้อมูลเพิ่มเติม หากกำหนดค่าธงคุณสมบัติ SDK จะประเมินพวกมันกับตัวระบุที่แตกต่าง รักษาการตัดสินใจสำหรับเซสชัน และส่งออกเหตุการณ์ $feature_flag_called สำหรับการประเมินแต่ละครั้ง

แต่ละกิจกรรมเหล่านี้แมปกับประตูความยินยอมที่แตกต่างกัน การรักษาตัวระบุที่แตกต่างคือการดำเนินการจัดเก็บและเข้าถึงภายใต้มาตรา 5(3) ของคำสั่ง ePrivacy และต้องการความยินยอมก่อน ที่ให้อย่างอิสระ เฉพาะเจาะจง มีข้อมูล และไม่คลุมเครือทั่วทั้ง EEA, UK และเขตอำนาจศาลใดๆ ที่นำมาตรฐานเดียวกันมาใช้ การบันทึกเหตุการณ์พฤติกรรมคือการประมวลผลข้อมูลส่วนบุคคลภายใต้ GDPR เพราะการรวมกันของตัวระบุ ที่อยู่ IP และร่องรอยพฤติกรรมเพียงพอที่จะระบุตัวบุคคล การเล่นซ้ำเซสชันอยู่ในหมวดหมู่แยกต่างหากที่เข้มงวดกว่าภายใต้แนวทาง EDPB เกี่ยวกับการเล่นซ้ำเซสชัน การเล่นซ้ำบันทึก DOM ที่แสดงผลและช่องป้อนข้อมูลที่ไม่มีหน้ากากใดๆ และต้องการความยินยอมที่ชัดเจนและละเอียดซึ่งแตกต่างจากความยินยอมการวิเคราะห์ทั่วไป การประเมินธงคุณสมบัติเป็นสิ่งที่ละเอียดอ่อน: การตรวจสอบธงที่ส่งคืนค่าบูลีนไม่ต้องการความยินยอมในตัวเอง แต่การรักษาการกำหนดธงของผู้ใช้ไว้กับตัวระบุที่เสถียรข้ามเซสชันต้องการ เพราะนั่นคือวิธีที่การทดลองตามธงสร้างข้อมูลที่ติดตามได้ระดับผู้ใช้

สิ่งที่ PostHog เขียนก่อนความยินยอม — และสิ่งที่ต้องถูกระงับ

PostHog Browser SDK แบบมาตรฐานเขียนสิ่งต่อไปนี้เมื่อเริ่มต้น: รายการคุกกี้และ localStorage รวมหนึ่งรายการภายใต้ ph_{projectKey}_posthog ที่มีตัวระบุที่แตกต่าง ตัวระบุเซสชัน และการตัดสินใจธงคุณสมบัติ บวกกับเมื่อเปิดใช้การเล่นซ้ำเซสชัน บัฟเฟอร์การบันทึกในหน่วยความจำเพิ่มเติมที่ล้างไปยังจุดสิ้นสุดการนำเข้าทุกไม่กี่วินาที SDK ยังส่งเหตุการณ์ $pageview ทันทีและหากเปิดใช้การบันทึกอัตโนมัติ ทุกคลิกถัดไป การโต้ตอบกับแบบฟอร์ม และการคลิกโกรธบนหน้าเว็บ

รูปแบบที่แนะนำคือเริ่มต้น PostHog ด้วย opt_out_capturing_by_default: true และ disable_session_recording: true จากนั้นพลิกธงทั้งสองเมื่อแบนเนอร์ความยินยอมส่งสัญญาณบวก นี่คือท่าทีการผสานรวมที่เอกสาร PostHog แนะนำตอนนี้ และเป็นท่าทีที่รอดการตรวจสอบของหน่วยงานกำกับดูแลเพราะมันกลับค่าเริ่มต้น: ไม่มีอะไรถูกบันทึกจนกว่าจะบันทึกความยินยอม และ SDK มอบการเปลี่ยนผ่านที่สะอาดแทนที่จะเป็นการปรับค่าใหม่ที่มีสถานะ

คุกกี้ รายการ localStorage และตัวระบุที่ PostHog รักษาไว้

Browser SDK 1.x เขียนรายการความคงทนหนึ่งรายการต่อโปรเจกต์ โดยมีคีย์ภายใต้ ph_{projectKey}_posthog ด้วยอายุหมดอายุเริ่มต้น 365 วัน ตัวเลือกการเริ่มต้น persistence ควบคุมกลไกพื้นฐาน: cookie เท่านั้น localStorage เท่านั้น localStorage+cookie (ค่าเริ่มต้น) sessionStorage หรือ memory สำหรับการปรับใช้ที่ความยินยอมมาก่อน ความคงทนของ memory คือค่าเริ่มต้นที่ถูกต้องเมื่อยังไม่ได้รับความยินยอม ซึ่งทำให้แน่ใจว่าไม่มีตัวระบุใดมีชีวิตอยู่นานกว่าเซสชันของหน้าเว็บ โดยมีการเปลี่ยนไปยัง localStorage+cookie เมื่อความยินยอมเปลี่ยน SDK ยังเขียนเครื่องหมาย opt-in หรือ opt-out ภายใต้ __ph_opt_in_out_{projectKey} เพื่อจดจำตัวเลือกของผู้ใช้ข้ามการเยี่ยมชม เครื่องหมายนั้นเองเป็นคุกกี้ที่จำเป็นอย่างเคร่งครัดเพราะมันรักษาการตัดสินใจความยินยอม

การแมปโมดูล PostHog กับกรอบความยินยอม

PostHog ไม่ได้ใช้งาน IAB TCF หรือ IAB Global Privacy Platform แบบดั้งเดิม และไม่ได้สร้างขึ้นมาเป็นผู้ขายเทคโนโลยีโฆษณา อย่างไรก็ตาม มันผสานรวมกับ Google Consent Mode v2 ผ่านการเชื่อมต่อฝั่งผู้เผยแพร่ เปิดเผย API opt-in และ opt-out แบบดั้งเดิม และเคารพส่วนหัว Do Not Track ผ่านตัวเลือกการเริ่มต้น respect_dnt รูปแบบที่ใช้งานได้ในการผลิตถือว่าแต่ละโมดูล PostHog เป็นประตูแยกต่างหากที่ผูกกับสัญญาณ CMP เฉพาะ

• เหตุการณ์การวิเคราะห์ผลิตภัณฑ์ ผูกกับวัตถุประสงค์การวิเคราะห์ ในแง่ TCF มักเป็นวัตถุประสงค์ 8 (วัดประสิทธิภาพเนื้อหา) ร่วมกับวัตถุประสงค์ 1 (จัดเก็บและ/หรือเข้าถึงข้อมูล) สำหรับ Consent Mode นี่แมปกับ analytics_storage
• การเล่นซ้ำเซสชัน อยู่หลังประตูที่เข้มงวดกว่า การเล่นซ้ำเซสชันของ PostHog บันทึก DOM ที่แสดงผลและช่องป้อนข้อมูลที่ไม่มีหน้ากากใดๆ ดังนั้น opt-in ระดับการตั้งค่าหรือการวิจัยที่แตกต่างจากการวิเคราะห์คือท่าทีที่สามารถป้องกันได้ภายใต้แนวทาง EDPB
• ธงคุณสมบัติและการทดลอง สามารถทำงานด้วยการประเมินชั่วคราวในหน่วยความจำภายใต้ฐานผลประโยชน์ที่ชอบธรรมเมื่อเป้าหมายคือเพียงแค่เปลี่ยนหน้าที่แสดงผล การกำหนดธงถาวรที่เชื่อมกับตัวระบุที่เสถียรข้ามเซสชันต้องการความยินยอมเดียวกับการวิเคราะห์ เพราะนั่นคือเมื่อธงกลายเป็นจุดข้อมูลที่ติดตามได้ระดับผู้ใช้
• แบบสำรวจและข้อเสนอแนะ ผูกกับประตูเดียวกับการเล่นซ้ำเซสชันเมื่อรวบรวมการป้อนข้อมูลข้อความอิสระ หรือกับประตูการวิเคราะห์เมื่อรวบรวมเพียงการให้คะแนนหรือการตอบสนองแบบเลือกตัวเลือกเดียว

รูปแบบการผสานรวมที่ใช้งานได้

การปรับใช้อ้างอิงมีสี่ส่วน: CMP ที่เปิดเผยเหตุการณ์การเปลี่ยนแปลงความยินยอมแบบเรียลไทม์ การบูตสแตรปแบบเลื่อนออกไปที่เริ่มต้น PostHog ด้วยการบันทึกและการเล่นซ้ำที่ถูกปิดใช้งาน ตัวฟังความยินยอมที่พลิก opt_in_capturing และสวิตช์การบันทึกเมื่อประตูที่เกี่ยวข้องเปิด และเส้นทางการถอนที่เรียก opt_out_capturing หยุดบัฟเฟอร์การเล่นซ้ำ และล้างตัวระบุถาวรผ่าน reset API ของ SDK

การนำไปใช้บนเว็บ

รูปแบบที่สะอาดที่สุดคือโหลด PostHog SDK ในทุกหน้าแต่เรียก posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) เป็นการบูตสแตรปเริ่มต้น สมัครรับเหตุการณ์การเปลี่ยนแปลงความยินยอมของ CMP เมื่อหมวดหมู่การวิเคราะห์เปลี่ยนเป็น true ให้เรียก posthog.set_config({ persistence: 'localStorage+cookie' }) ตามด้วย posthog.opt_in_capturing() ซึ่งจะเปิดใช้การบันทึกเหตุการณ์ใหม่และการเปลี่ยนผ่านความคงทนจะเริ่มเขียนตัวระบุที่แตกต่าง เมื่อหมวดหมู่การเล่นซ้ำเซสชันเปลี่ยนเป็น true ให้เรียก posthog.startSessionRecording() เมื่อประตูใดประตูหนึ่งถูกถอน ให้เรียก posthog.opt_out_capturing() สำหรับประตูการวิเคราะห์หรือ posthog.stopSessionRecording() สำหรับประตูการเล่นซ้ำ ทำให้รายการความคงทนที่เกี่ยวข้องหมดอายุผ่าน posthog.reset() และส่งคำขอลบผ่าน GDPR API ของ PostHog หากผู้ใช้ได้ใช้สิทธิ์การลบของตน

การเลือกภูมิภาค: PostHog Cloud US เทียบกับ EU เทียบกับ self-hosted

PostHog ดำเนินการสองภูมิภาคคลาวด์ — US (us.posthog.com) และ EU (eu.posthog.com) — และรองรับการติดตั้งแบบ self-hosted บนโครงสร้างพื้นฐานของลูกค้าเอง สำหรับการรับส่งข้อมูล EEA และ UK คลาวด์ EU คือค่าเริ่มต้นที่ถูกต้อง มันรักษาการนำเข้า การประมวลผล และการจัดเก็บภายใน EEA และลดการเปิดรับ Schrems II ที่การปรับใช้การวิเคราะห์ในภูมิภาค US ทุกครั้งนำมา ตัวเลือกการเริ่มต้น api_host ตรึงภูมิภาค PostHog แบบ self-hosted ย้ายสแต็กทั้งหมดไปยังโครงสร้างพื้นฐานของผู้เผยแพร่เอง ซึ่งเป็นท่าทีที่อยู่อาศัยของข้อมูลที่แข็งแกร่งที่สุด แต่ไม่ได้ลบภาระผูกพันความยินยอม ฐานทางกฎหมายตามข้อมูล ไม่ใช่ผู้ดำเนินการ ตัวเลือกใดก็ตามที่เลือกต้องสะท้อนในประกาศความเป็นส่วนตัวและบันทึกการประมวลผลของผู้ควบคุม

การบันทึกฝั่งเซิร์ฟเวอร์

PostHog รองรับการนำเข้าเหตุการณ์ฝั่งเซิร์ฟเวอร์ผ่าน SDK ของ Python, Node, Go, Ruby และ PHP เหตุการณ์ฝั่งเซิร์ฟเวอร์ไม่ได้รับการยกเว้นจากความยินยอม ฐานทางกฎหมายตามข้อมูล แต่การนำเข้าฝั่งเซิร์ฟเวอร์ให้ผู้เผยแพร่ควบคุมได้อย่างเต็มที่ว่าฟิลด์ใดถูกส่งออกและเมื่อใด รูปแบบทั่วไปคือบันทึกชุดเหตุการณ์จำเป็นขั้นต่ำฝั่งเซิร์ฟเวอร์ภายใต้ผลประโยชน์ที่ชอบธรรม จากนั้นเสริมเหตุการณ์เหล่านั้นด้วยรายละเอียดพฤติกรรมจากไคลเอนต์หลังจากที่ผู้ใช้ให้ความยินยอมการวิเคราะห์เท่านั้น เหตุการณ์ฝั่งเซิร์ฟเวอร์และฝั่งไคลเอนต์รวมกันบนตัวระบุที่แตกต่างเดียวกันเมื่อความยินยอมเปลี่ยน ก่อนความยินยอม เหตุการณ์ฝั่งเซิร์ฟเวอร์จะถูกส่งออกด้วยตัวระบุที่ไม่ระบุตัวตนและชั่วคราวซึ่งถูกรีเซ็ตในทุกเซสชัน

การตรวจสอบการผสานรวมและเส้นทางการตรวจสอบ

ขั้นตอนการตรวจสอบคือสิ่งที่หน่วยงานกำกับดูแลตรวจสอบและผู้เผยแพร่มักข้ามไปบ่อยที่สุด การปรับใช้ PostHog ที่ผสานรวมอย่างถูกต้องต้องผ่านการทดสอบสี่รายการตามลำดับ ประการแรก เซสชันเบราว์เซอร์ที่สะอาดที่แสดงแบนเนอร์แต่ยังไม่มีการเลือกต้องสร้างคำขอเป็นศูนย์ไปยัง api_host ที่กำหนดค่าไว้นอกเหนือจากการดาวน์โหลดไฟล์ SDK คุกกี้ ph_ เป็นศูนย์ใน document.cookie และรายการ ph_ เป็นศูนย์ใน localStorage ประการที่สอง การปฏิเสธการวิเคราะห์ต้องรักษาสถานะนั้น ไม่มีการบันทึก ไม่มีการบันทึกซ้ำ ไม่มีตัวระบุถาวร ประการที่สาม การยอมรับการวิเคราะห์ต้องสร้างเหตุการณ์ $opt_in ทันที รายการความคงทนที่คาดหวัง ph_{projectKey}_posthog พร้อมแอตทริบิวต์ SameSite ที่ถูกต้อง และการรับส่งข้อมูลเหตุการณ์ที่ไหลไปยังโฮสต์ที่กำหนดค่าไว้ ประการที่สี่ การถอนความยินยอมหลังจากนั้นต้องหยุดการบันทึกและการเล่นซ้ำเพิ่มเติมทันที ทำให้ตัวระบุถาวรหมดอายุ และเรียกใช้คำขอลบผ่าน GDPR API ของ PostHog หากผู้ใช้ได้เรียกใช้การลบ

ความคาดหวังเส้นทางการตรวจสอบภายใต้แนวทางแบนเนอร์คุกกี้ 2023 ของ EDPB และลำดับความสำคัญของคณะทำงาน 2026 ที่ต่ออายุคือผู้เผยแพร่สามารถพิสูจน์ได้สำหรับเหตุการณ์ใดๆ ในโปรเจกต์ PostHog ว่าผู้ใช้ที่สร้างมันได้ให้ความยินยอมที่ถูกต้องในขณะที่บันทึก รูปแบบมาตรฐานคือตั้งค่าเวอร์ชันความยินยอมและการประทับเวลาเป็นคุณสมบัติบุคคลบน ID ที่แตกต่างผ่าน posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) เพื่อให้เหตุการณ์แต่ละรายการสามารถติดตามกลับไปยังรายการบันทึกความยินยอมเฉพาะได้ การปรับใช้ที่มีประตูอย่างถูกต้อง จับคู่กับการเลือกภูมิภาคที่ตรงกับผู้ชม ความคงทนที่ค่าเริ่มต้นเป็นหน่วยความจำ และเส้นทางการลบที่เปิดใช้งานเมื่อถอน คือสิ่งที่เปลี่ยน PostHog จากความเสี่ยงด้านการกำกับดูแลที่เข้มข้นไปเป็นศูนย์กลางที่สามารถป้องกันได้ของสแต็กการวิเคราะห์ผลิตภัณฑ์