ทำไม Amplitude จึงต้องการความยินยอม

SDK เบราว์เซอร์ Amplitude เริ่มต้นและ SDK มือถือ Amplitude ทำมากกว่าการบันทึกการดูหน้า ในการเริ่มต้นระบบ จะตั้งค่าตัวระบุอุปกรณ์ในที่จัดเก็บของบุคคลที่หนึ่ง สร้างตัวระบุเซสชัน บันทึกตัวอ้างอิง แยกวิเคราะห์ UTM และตัวระบุคลิกจาก URL และเริ่มต้นการเข้าคิวเหตุการณ์ที่บันทึกอัตโนมัติ ได้แก่ การดูหน้า การคลิกองค์ประกอบ การโต้ตอบกับฟอร์ม การดาวน์โหลดไฟล์ และในรุ่นล่าสุด การเล่นซ้ำเซสชัน นอกจากนี้จะเสริมสร้างเหตุการณ์เหล่านั้นด้วยการระบุตำแหน่งทางภูมิศาสตร์ที่ได้มาจาก IP ข้อมูลอุปกรณ์ที่ได้มาจาก user agent และหากกำหนดค่าไว้ การเสริมสร้างจากบุคคลที่สามจากพันธมิตรด้านข้อมูล

แต่ละขั้นตอนเหล่านั้นเกี่ยวข้องกับฐานทางกฎหมายที่แยกจากกันของความยินยอม การจัดเก็บตัวระบุอุปกรณ์เป็นการดำเนินการจัดเก็บและเข้าถึงภายใต้มาตรา 5(3) ของ Directive ePrivacy ซึ่งต้องการความยินยอมล่วงหน้า ให้อย่างอิสระ เฉพาะเจาะจง ได้รับการแจ้ง และชัดเจนในเขตเศรษฐกิจยุโรป สหราชอาณาจักร และเขตอำนาจศาลใดๆ ที่นำเข้ามาตรฐานเดียวกัน การบันทึกเหตุการณ์พฤติกรรมที่เชื่อมโยงกับตัวระบุนั้นเป็นการประมวลผลข้อมูลส่วนบุคคลภายใต้ GDPR การเสริมสร้างด้วยข้อมูลจากบุคคลที่สามนำเสนอความสัมพันธ์ระหว่างผู้ควบคุมที่สอง CCPA และ CPRA จัดประเภทการประมวลผลเดียวกันว่าเป็นการขายหรือการแบ่งปัน เว้นแต่ผู้เผยแพร่มีสัญญาผู้ให้บริการที่มีขอบเขตเหมาะสมกับ Amplitude ซึ่งมีให้ แต่เฉพาะในกรณีที่การผสานรวมได้รับการกำหนดค่าเพื่อปิดใช้งานคุณสมบัติโฆษณา

สิ่งที่ Amplitude รวบรวมก่อนความยินยอม และสิ่งที่คุณต้องระงับ

ข้อผิดพลาดในการใช้งานที่พบบ่อยที่สุดคือการปฏิบัติต่อ Amplitude ราวกับเป็นเครื่องมือวิเคราะห์แบบเบาที่สามารถทำงานควบคู่กับแบนเนอร์คุกกี้ได้ ไม่สามารถทำได้ ด้วยการเรียกใช้ amplitude.init() เริ่มต้น SDK จะภายในการแสดงผลครั้งแรกของหน้า เขียนคุกกี้อย่างน้อยหนึ่งรายการหรือรายการที่จัดเก็บในเครื่อง ส่งการเรียกระบุตัวตน และเริ่มบัฟเฟอร์เหตุการณ์ ไม่มีสิ่งใดที่ได้รับอนุญาตก่อนที่ผู้ใช้จะยืนยันการยอมรับหมวดหมู่ความยินยอมที่เกี่ยวข้อง

ดังนั้นการผสานรวมที่สอดคล้องต้องเลื่อนเวลา amplitude.init() จนกว่า CMP จะส่งสัญญาณว่าหมวดหมู่ความยินยอมในการวิเคราะห์ได้รับการอนุมัติ SDK ไม่ควรถูกโหลดเลยจากแท็ก <script> ที่ป้องกันด้วยความยินยอมซึ่งขึ้นอยู่กับสัญญาณวัตถุประสงค์ 8 (การวิเคราะห์) หรือวัตถุประสงค์ 1 (การจัดเก็บและการเข้าถึง) ของ CMP ขึ้นอยู่กับกรอบงานที่ CMP เปิดเผย หาก SDK ต้องโหลดก่อนหน้านี้ ตัวอย่างเช่น เพราะมันถูกรวมไว้ในโค้ดแอปพลิเคชันและไม่สามารถดึงมาได้แบบ lazy การเรียกเริ่มต้นระบบควรส่ง defaultTracking: false และ optOut: true เพื่อไม่ให้มีเหตุการณ์ใดถูกส่งออกจนกว่าจะบันทึกความยินยอม จากนั้นเหตุการณ์ opt-in ที่เลื่อนเวลาควรพลิกแฟล็กเหล่านั้น

คุกกี้และที่จัดเก็บที่ Amplitude เขียน

Browser SDK 2.x เขียนคุกกี้บุคคลที่หนึ่งเดียวชื่อ AMP_{apiKey} ตามค่าเริ่มต้น โดยมีอายุหมดอายุหนึ่งปี ซึ่งประกอบด้วยตัวระบุอุปกรณ์และข้อมูลเมตาของเซสชัน เวอร์ชันเก่ายังเขียน amplitude_id_{apiKey} อีกด้วย SDK มือถือเก็บตัวระบุเดียวกันภายในที่จัดเก็บแบบ sandbox ของแอปพลิเคชัน การเล่นซ้ำเซสชันเพิ่มคุกกี้ที่สอง AMP_MKTG_{apiKey} และพันธมิตรการเสริมสร้างของ Amplitude อาจตั้งค่าคุกกี้บุคคลที่สามเพิ่มเติมหากเปิดใช้งานโมดูลการกำหนดเป้าหมายการทดลองหรือกลุ่มเป้าหมาย ทั้งหมดเหล่านี้ไม่จำเป็นและต้องการความยินยอม

การแมป Amplitude กับกรอบงานความยินยอม

Amplitude ไม่ได้ใช้งาน Google Consent Mode v2, IAB TCF หรือ IAB Global Privacy Platform โดยธรรมชาติ นั่นไม่ใช่ข้อบกพร่อง Amplitude คือแพลตฟอร์มวิเคราะห์บุคคลที่หนึ่ง ไม่ใช่ผู้จำหน่ายเทคโนโลยีโฆษณา แต่หมายความว่าความรับผิดชอบในการผสานรวมอยู่ที่ผู้เผยแพร่ รูปแบบที่ใช้ได้จริงคือการปฏิบัติต่อโมดูล Amplitude แต่ละตัวว่าเป็นประตูความยินยอมที่แยกจากกัน และผูกมันเข้ากับสัญญาณเฉพาะที่ CMP เปิดเผยอยู่แล้ว

• เหตุการณ์วิเคราะห์หลัก ผูกกับวัตถุประสงค์ด้านการวิเคราะห์ ในแง่ TCF นี่มักเป็นวัตถุประสงค์ที่ 8 (วัดประสิทธิภาพเนื้อหา) รวมกับวัตถุประสงค์ที่ 1 (จัดเก็บและ/หรือเข้าถึงข้อมูล) สำหรับ Google Consent Mode นี่แมปกับ analytics_storage
• การเล่นซ้ำเซสชัน ควรอยู่เบื้องหลังสัญญาณที่เข้มงวดกว่า การเล่นซ้ำจะบันทึก DOM ที่แสดงผล รวมถึงค่าฟอร์มเว้นแต่จะมาสก์โดยชัดเจน ดังนั้นการ opt-in แบบ preferences หรือ functional แยกต่างหากจึงเหมาะสม และการเล่นซ้ำควรปิดเป็นค่าเริ่มต้นแม้จะได้รับการวิเคราะห์
• กลุ่มเป้าหมาย กลุ่ม และการเสริมสร้างจากบุคคลที่สาม ผูกกับวัตถุประสงค์ทางการตลาด ในแง่ TCF นี่คือวัตถุประสงค์ที่ 7 (วัดประสิทธิภาพโฆษณา) หรือวัตถุประสงค์ที่ 9 (ใช้การวิจัยตลาด) สำหรับ Google Consent Mode นี่แมปกับ ad_storage และ ad_user_data
• การทดลอง Amplitude Experiment สามารถทำงานด้วยการจัดสรรแบบไม่ระบุชื่อ ชั่วคราว ภายใต้ฐานประโยชน์ที่ชอบด้วยกฎหมาย แต่การจัดสรรถาวรที่เชื่อมโยงกับตัวระบุผู้ใช้ต้องการความยินยอมเช่นเดียวกับการวิเคราะห์หลัก

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

การใช้งานอ้างอิงที่ผ่านการตรวจสอบของหน่วยงานกำกับดูแลมีส่วนประกอบที่เคลื่อนไหวสี่ส่วน ได้แก่ CMP ที่เปิดเผยเหตุการณ์แบบเรียลไทม์เมื่อผู้ใช้เปลี่ยนความยินยอม ตัวโหลด SDK ที่เลื่อนเวลาซึ่งดึง Amplitude เฉพาะหลังจากที่เหตุการณ์นั้นเกิดขึ้นสำหรับหมวดหมู่ที่เกี่ยวข้อง การป้องกันระดับเซสชันที่เคารพการ opt-out โดยไม่สูญเสียตัวระบุอุปกรณ์ที่ไม่ระบุชื่อก่อนหน้าของผู้ใช้ที่กฎหมายอนุญาต และสะพานฝั่งเซิร์ฟเวอร์สำหรับเหตุการณ์ที่ต้องการการรวบรวมอย่างแท้จริงโดยไม่คำนึงถึงความยินยอม เช่น การวัดความปลอดภัยหรือการตรวจจับการฉ้อโกง ที่กำหนดเส้นทางผ่านจุดสิ้นสุดแยกต่างหากพร้อมฐานทางกฎหมายของตนเอง

การใช้งานบนเว็บ

บนเว็บ รูปแบบที่สะอาดที่สุดคือการเปิดเผยสถานะความยินยอมของ CMP ผ่านออบเจ็กต์ window.__cmp_consent หรือการเรียกกลับ __tcfapi มาตรฐาน จากนั้นมีสคริปต์ bootstrap ขนาดเล็กที่สมัครรับการเปลี่ยนแปลงความยินยอม เมื่อความยินยอมในการวิเคราะห์เปลี่ยนจาก false เป็น true bootstrap จะดึง SDK ของ Amplitude จาก CDN ที่จัดการโดย CMP เรียก amplitude.init(apiKey, undefined, { defaultTracking: true }) และเล่นซ้ำเหตุการณ์ที่ถูกเข้าคิวไว้ในหน่วยความจำในขณะที่รอความยินยอม เมื่อความยินยอมเปลี่ยนกลับเป็น false bootstrap จะเรียก amplitude.setOptOut(true) ล้างคุกกี้ AMP_ ผ่านการหมดอายุของ document.cookie และลบสถานะในหน่วยความจำ สิ่งสำคัญคือ bootstrap ต้องไม่เริ่มต้น Amplitude แบบ lazy ในการไหลของคำขอเดียวกับการแสดงผลแบนเนอร์ SDK ต้องรอการอนุมัติโดยชัดเจน

การใช้งานบนมือถือ

บน iOS เทียบเท่าคือการเก็บเฟรมเวิร์ก Amplitude ที่นำเข้าไว้ แต่เลื่อน Amplitude.instance().initialize(apiKey: apiKey) จนกว่าขั้นตอนความยินยอมในแอปจะส่งคืนสัญญาณการวิเคราะห์เชิงบวก พร้อมท์ ATT เป็นเรื่องแยกต่างหาก ATT ควบคุม IDFA ในขณะที่ตัวระบุของ Amplitude คือ UUID ของ SDK เองที่จัดเก็บไว้ใน sandbox ของแอป ทั้งคู่ต้องการความยินยอมใน EEA แต่ฐานทางกฎหมายและพร้อมท์แตกต่างกัน บน Android ตรรกะเดียวกันนี้ใช้กับ Amplitude.getInstance().initializeApolloClient() หรือเทียบเท่าขึ้นอยู่กับเวอร์ชัน SDK

โหมดฝั่งเซิร์ฟเวอร์

Amplitude รองรับการนำเข้าฝั่งเซิร์ฟเวอร์ผ่าน HTTP V2 API เหตุการณ์ฝั่งเซิร์ฟเวอร์ไม่ได้รับการยกเว้นจากความยินยอม ฐานทางกฎหมายติดตามข้อมูล ไม่ใช่การขนส่ง แต่การนำเข้าฝั่งเซิร์ฟเวอร์ให้ผู้เผยแพร่ควบคุมได้อย่างสมบูรณ์ว่าจะส่งฟิลด์ใด ซึ่งทำให้ง่ายต่อการปฏิบัติตามความยินยอมบางส่วน รูปแบบทั่วไปคือการบันทึกชุดเหตุการณ์ขั้นต่ำที่จำเป็นเท่านั้นฝั่งเซิร์ฟเวอร์ภายใต้ประโยชน์ที่ชอบด้วยกฎหมาย และเสริมสร้างเหตุการณ์เหล่านั้นด้วยรายละเอียดพฤติกรรมเฉพาะหลังจากที่ผู้ใช้ได้รับความยินยอมการวิเคราะห์บนไคลเอ็นต์เท่านั้น

การตรวจสอบความถูกต้องของการผสานรวม

ขั้นตอนการตรวจสอบความถูกต้องคือขั้นตอนที่ผู้เผยแพร่มักจะข้ามมากที่สุดและหน่วยงานกำกับดูแลมักตรวจสอบมากที่สุด การปรับใช้ Amplitude ที่ผสานรวมอย่างถูกต้องควรผ่านการตรวจสอบสี่รายการ ประการแรก เบราว์เซอร์ที่มีแบนเนอร์ความยินยอมแสดงอยู่แต่ยังไม่มีการเลือกควรให้คำขอเป็นศูนย์ไปยัง api.amplitude.com หรือ api.eu.amplitude.com และคุกกี้ AMP_ เป็นศูนย์ใน document.cookie ประการที่สอง การปฏิเสธหมวดหมู่การวิเคราะห์ควรรักษาสถานะนั้น ไม่มีเหตุการณ์ ไม่มีคุกกี้ ไม่มีรายการที่จัดเก็บในเครื่องที่มีคำนำหน้า AMP_ ประการที่สาม การยอมรับการวิเคราะห์ควรสร้าง identify เดียวตามด้วยการรับส่งข้อมูลเหตุการณ์ และคุกกี้ AMP_ ควรปรากฏพร้อมแอตทริบิวต์ SameSite ที่สอดคล้องกับนโยบาย CMP ของผู้เผยแพร่ ประการที่สี่ การถอนความยินยอมภายหลังควรหยุดเหตุการณ์เพิ่มเติมทันทีและล้างตัวระบุที่จัดเก็บ การล้างข้อมูลที่ล่าช้าถือเป็นการค้นพบ

เส้นทางการตรวจสอบมีความสำคัญแยกกัน ภายใต้แนวทางการใช้แบนเนอร์คุกกี้ของ EDPB ปี 2023 และลำดับความสำคัญของคณะทำงานที่ต่ออายุสำหรับปี 2026 หน่วยงานกำกับดูแลคาดหวังให้ผู้เผยแพร่สามารถพิสูจน์ได้สำหรับเหตุการณ์ใดๆ ในโครงการ Amplitude ว่าผู้ใช้ที่สร้างมันได้ให้ความยินยอมที่ถูกต้องในขณะที่บันทึก นั่นต้องการให้บันทึกความยินยอมของ CMP สามารถค้นหาได้โดยตัวระบุอุปกรณ์หรือตัวระบุเซสชัน และเพย์โหลดเหตุการณ์ Amplitude ต้องพกพาฟิลด์เวอร์ชันความยินยอมที่เชื่อมโยงกลับไปยังบันทึกนั้น การจัดเก็บสตริงความยินยอมเป็นคุณสมบัติผู้ใช้แบบกำหนดเองในทุกเหตุการณ์เป็นวิธีที่ง่ายที่สุดในการทำให้การเชื่อมโยงนั้นตรวจสอบได้

การเลือกภูมิภาคที่เหมาะสมและที่พำนักข้อมูล

Amplitude ดำเนินการสองภูมิภาคการผลิต ได้แก่ US (api.amplitude.com) และ EU (api.eu.amplitude.com) สำหรับการรับส่งข้อมูล EEA และ UK ภูมิภาค EU เป็นค่าเริ่มต้นที่ถูกต้อง ซึ่งเก็บข้อมูลไว้ภายใน EEA และลดพื้นที่เสี่ยงการถ่ายโอนที่คำตัดสิน Schrems II และ EU-US Data Privacy Framework ทำให้เป็นศูนย์กลางในการตรวจสอบการวิเคราะห์ใดๆ การเปลี่ยนภูมิภาคไม่ใช่ย้อนหลัง ข้อมูลที่มีอยู่จะอยู่ที่ที่นำเข้าครั้งแรก สำหรับผู้เผยแพร่ที่วางแผนการเปิดตัว CMP จึงควรยืนยันภูมิภาคก่อนปรับขนาด และควรบันทึกทางเลือกในประกาศความเป็นส่วนตัวเพื่อให้ห่วงโซ่ฐานทางกฎหมายสะอาดตั้งแต่การรวบรวมไปจนถึงการจัดเก็บ ภูมิภาคที่เลือกอย่างถูกต้อง คู่กับ SDK ที่ควบคุมอย่างถูกต้องและบันทึกความยินยอมที่ค้นหาได้ คือสิ่งที่เปลี่ยนการปรับใช้ Amplitude จากความเสี่ยงด้านกฎระเบียบให้เป็นส่วนหนึ่งที่สามารถพิสูจน์ได้ของกองการวิเคราะห์