Segment ทำอะไรจริงๆ

Segment SDK (โหลดจาก cdn.segment.com/analytics.js) เริ่มต้นอ็อบเจกต์ analytics แบบ global และระบุผู้เยี่ยมชมด้วยคุกกี้ที่ Segment เป็นเจ้าของชื่อ ajs_anonymous_id โค้ดแอปพลิเคชันเรียก analytics.identify(), analytics.track(), analytics.page() และ analytics.group() และ SDK จะส่งต่อการเรียกแต่ละครั้งไปยังจุดสิ้นสุดการนำเข้าของ Segment จากนั้น Segment จะแพร่กระจายเหตุการณ์ออกไป — แบบเรียลไทม์หรือผ่านแบตช์ — ไปยังปลายทางใดก็ตามที่เปิดใช้งานบนแหล่ง: Google Analytics, Facebook Pixel, Customer.io, Iterable, Amplitude, Mixpanel, Snowflake, BigQuery และอื่นๆ อีกหลายสิบแห่ง

การส่งต่อแต่ละครั้งไปยังปลายทางดาวน์สตรีมเป็นกิจกรรมการประมวลผลที่แยกจากกันจากมุมมองของ GDPR ฐานทางกฎหมายสำหรับการส่งเหตุการณ์ไปยัง Google Analytics ไม่เหมือนกับฐานทางกฎหมายสำหรับการส่งเหตุการณ์เดียวกันไปยัง Customer.io และไม่เหมือนกับการเขียนเหตุการณ์เดียวกันลงใน Snowflake warehouse แบนเนอร์การยินยอมที่บันทึก "ฉันยอมรับการตลาด" เพียงครั้งเดียวไม่สามารถอนุมัติทั้งหมดนี้โดยลำพังได้ เว้นแต่การจำแนกประเภทของปลายทางจะตรงกับการจำแนกประเภทของการยินยอม

Primitives การยินยอมดั้งเดิมของ Segment

Segment ได้ลงทุนอย่างหนักในการพัฒนา primitives การจัดการการยินยอมในช่วงสองปีที่ผ่านมา ณ ปี 2569 แพลตฟอร์มเปิดเผยพื้นผิวที่มีความหมายสามแห่งสำหรับการบังคับใช้การยินยอม

Consent Management (เดิมชื่อ Consent Stamping)

คุณสมบัติ Consent Management ช่วยให้คุณแนบเพย์โหลดการยินยอมกับทุกเหตุการณ์ที่ Segment นำเข้า เพย์โหลดบันทึกว่าผู้ใช้ยอมรับประเภทการประมวลผลใดบ้าง — โดยทั่วไปคือสตริง IAB TCF v2.3 สตริง GPP หรือการจำแนกประเภทของ Segment แบบกำหนดเอง ปลายทางดาวน์สตรีมสามารถกำหนดค่าให้ส่งต่อหรือบล็อกตามสถานะการยินยอมในแต่ละเหตุการณ์

ตัวกรองปลายทางพร้อมการควบคุมการยินยอม

ตัวกรองปลายทางช่วยให้คุณเขียนนิพจน์ JavaScript หรือ Lua ขนาดเล็กที่ทำงานกับทุกเหตุการณ์ก่อนที่จะถูกส่งต่อไปยังปลายทางที่เฉพาะเจาะจง ตัวกรองสามารถตรวจสอบเพย์โหลดการยินยอมและลัดวงจรการส่งต่อหากหมวดหมู่ที่เกี่ยวข้องยังไม่ได้รับอนุญาต นี่คือ primitive ที่เหมาะสมสำหรับการบังคับใช้การยินยอมแบบละเอียด รายปลายทาง

การตั้งค่า integrations ระดับแหล่ง

สำหรับการควบคุมที่หยาบกว่า อ็อบเจกต์ integrations ระดับแหล่งสามารถปิดใช้งานปลายทางทั้งหมดในแต่ละเหตุการณ์: analytics.track(event, properties, { integrations: { "All": false, "Segment.io": true } }) สิ่งนี้มีประโยชน์สำหรับกรณีทั้งหมดหรือไม่มีอะไรเลย แต่ไม่สามารถจัดการกับความละเอียดของระดับหมวดหมู่ได้ดี

การผสานรวม CMP ทีละขั้นตอน

สถาปัตยกรรมที่เชื่อถือได้คือการแมปการตัดสินใจเรื่องหมวดหมู่ของ CMP กับการจำแนกประเภทปลายทางของ Segment แนบเพย์โหลดการยินยอมกับทุกเหตุการณ์ และใช้ตัวกรองปลายทางเพื่อบังคับใช้การควบคุมรายปลายทาง

1. จำแนกประเภทปลายทาง

ตรวจสอบรายการปลายทางที่เปิดใช้งานในพื้นที่ทำงาน Segment ของคุณและกำหนดแต่ละแห่งให้กับหมวดหมู่ CMP ปลายทางอย่าง Google Analytics, Mixpanel และ Amplitude มักเป็นการวิเคราะห์ ปลายทางอย่าง Facebook Pixel, TikTok และ Pinterest มักเป็นการตลาด ปลายทางอย่าง Snowflake หรือ BigQuery (คลังข้อมูลของคุณเอง) มักจำเป็นหรือใช้งานได้จริง — แต่เฉพาะเมื่อการวิเคราะห์ที่ประมวลผลดาวน์สตรีมของคลังข้อมูลก็ถูกจัดหมวดหมู่อย่างถูกต้องด้วย บันทึกการแมปนี้ไว้ที่ใดที่หนึ่งที่ตรวจสอบได้ การป้องกันการตรวจสอบขึ้นอยู่กับสิ่งนี้

2. เลื่อนการเริ่มต้น SDK จนกว่าจะจับการตัดสินใจเรื่องการยินยอมได้

Segment SDK สามารถกำหนดค่าให้ไม่ส่งเหตุการณ์จนกว่าจะเรียก analytics.load() เลื่อนการเรียกโหลดจนกว่า CMP จะจับการตัดสินใจของผู้ใช้ เพื่อที่ว่าจะไม่มีเหตุการณ์ใดทำงานก่อนการยินยอม หรือใช้รูปแบบคิวของ analytics.ready() พร้อมการควบคุมสถานะการยินยอมในตัวจัดการเหตุการณ์เอง

3. แนบเพย์โหลดการยินยอมกับทุกเหตุการณ์

กำหนดค่าคุณสมบัติ Consent Management เพื่อประทับสตริง IAB TC สตริง GPP หรือการจำแนกประเภทแบบกำหนดเองของคุณบนทุกเหตุการณ์ที่นำเข้า ตราประทับเดินทางพร้อมกับเหตุการณ์ผ่านไปป์ไลน์ของ Segment และพร้อมใช้งานสำหรับตัวกรองปลายทาง

4. เขียนตัวกรองปลายทางสำหรับการบังคับใช้ระดับหมวดหมู่

สำหรับแต่ละปลายทาง ให้เขียนตัวกรองที่ตรวจสอบเพย์โหลดการยินยอมเทียบกับหมวดหมู่ที่ปลายทางนั้นต้องการ หากผู้ใช้ยอมรับการตลาดแต่ปฏิเสธการวิเคราะห์ ปลายทางหมวดหมู่การตลาดจะรับเหตุการณ์ และปลายทางหมวดหมู่การวิเคราะห์จะถูกละทิ้งอย่างเงียบๆ ตรรกะของตัวกรองมักอ่านจาก event.context.consent.categoryPreferences หรือเส้นทางที่เทียบเท่าในสคีมาเพย์โหลดการยินยอม

5. เผยแพร่การเพิกถอน

เมื่อผู้ใช้เพิกถอนการยินยอม สิ่งสองอย่างจำเป็นต้องเกิดขึ้น: SDK หยุดส่งเหตุการณ์ใหม่ภายใต้หมวดหมู่ที่ถูกเพิกถอน (จัดการโดยสวิตช์ integrations ระดับแหล่ง) และโปรไฟล์ผู้ใช้ที่มีอยู่ในปลายทางดาวน์สตรีมจำเป็นต้องได้รับการอัปเดตหรือลบ Privacy API ของ Segment รองรับทั้งคำขอลบและแฟล็กการระงับ กำหนดค่า CMP ให้เรียกจุดสิ้นสุด Privacy API ที่เหมาะสมเมื่อมีการเพิกถอน

กับดักทั่วไป

ข้อผิดพลาดในการผสานรวมสี่ประการคิดเป็นส่วนใหญ่ของผลการตรวจสอบในการปรับใช้ Segment

การปฏิบัติต่อ Segment เหมือนตัวติดตามตัวเดียว

ข้อบกพร่องที่พบบ่อยที่สุด: การควบคุม Segment ภายใต้หมวดหมู่เดียว (มักเป็นการวิเคราะห์) และสมมติว่านั่นตอบสนองทุกอย่างที่อยู่ดาวน์สตรีม ไม่ใช่เช่นนั้น หาก Facebook Pixel เปิดใช้งานเป็นปลายทาง เหตุการณ์ที่ส่งต่อไปยัง Facebook ต้องการการยินยอมหมวดหมู่การตลาด ไม่ใช่การวิเคราะห์ การจำแนกประเภทรายปลายทางเป็นสิ่งจำเป็น

ลืมปลายทางคลังข้อมูล

หลายทีมเปิดใช้งาน Snowflake หรือ BigQuery เป็นปลายทาง Segment และปฏิบัติต่อคลังข้อมูลเสมือนได้รับการยกเว้นเพราะ "เป็นโครงสร้างพื้นฐานภายใน" ตัวคลังข้อมูลอาจเป็นภายในได้ แต่การประมวลผลที่ตามมา — แดชบอร์ด BI การสร้างแบบจำลอง lookalike การแบ่งกลุ่มลูกค้า — ป้อนฟังก์ชันการตลาดและการวิเคราะห์ การจำแนกประเภทการยินยอมของคลังข้อมูลควรสะท้อนถึงการใช้งานที่อนุญาตมากที่สุดที่ข้อมูลคลังข้อมูลไหลเข้าในที่สุด

แหล่งฝั่งเซิร์ฟเวอร์ที่ไม่มีบริบทการยินยอม

Segment รองรับแหล่งฝั่งเซิร์ฟเวอร์ (แบ็คเอนด์ของคุณเรียก Segment โดยตรง) เหตุการณ์จากแหล่งเหล่านี้ไม่ได้รับการสืบทอดสถานะการยินยอมฝั่งเบราว์เซอร์โดยอัตโนมัติ แอปพลิเคชันต้องค้นหาสถานะการยินยอมของผู้ใช้ในเวลาที่ส่งเหตุการณ์และแนบไปกับการเรียก หากไม่มีสิ่งนี้ เหตุการณ์ฝั่งเซิร์ฟเวอร์จะผ่าน CMP ทั้งหมด

การเพิกเฉยต่อการรวมตัวตนข้ามแหล่ง

การแก้ไขตัวตนของ Segment รวมโปรไฟล์ที่ไม่ระบุชื่อและระบุตัวตนแล้ว และสามารถทำเช่นนั้นได้ข้ามแหล่งเว็บ มือถือ และฝั่งเซิร์ฟเวอร์ หากสถานะการยินยอมแตกต่างกันระหว่างพื้นผิวเหล่านี้ โปรไฟล์ที่รวมกันจะรับช่วงการตีความที่อนุญาตมากที่สุดตามค่าเริ่มต้น กำหนดค่าการแก้ไขตัวตนให้ใช้สถานะการยินยอมที่จำกัดที่สุดในตัวตนที่รวมกัน ไม่ใช่ที่อนุญาตมากที่สุด

รายการตรวจสอบการตรวจสอบ

คำถามหกข้อที่เป็นรูปธรรมเพื่อตอบสำหรับการปรับใช้ Segment ใดๆ ที่สัมผัสทราฟฟิก EU, UK หรือแคลิฟอร์เนีย

• การจำแนกประเภทปลายทางได้รับการบันทึกไว้หรือไม่? สำหรับทุกปลายทางที่เปิดใช้งาน มีบันทึกเป็นลายลักษณ์อักษรว่าหมวดหมู่ CMP ใดควบคุมมัน?
• SDK รอการยินยอมหรือไม่? เปิดหน้าเว็บในหน้าต่างส่วนตัวและยืนยันว่าไม่มีการเรียก analytics.track ใดส่งไปยัง api.segment.io ก่อนที่แบนเนอร์จะได้รับการยอมรับ
• เพย์โหลดการยินยอมถูกประทับบนทุกเหตุการณ์หรือไม่? ตรวจสอบตัวอย่างเหตุการณ์ที่นำเข้าใน Segment debugger และยืนยันว่าเพย์โหลดการยินยอมมีอยู่และสมบูรณ์
• ตัวกรองปลายทางเคารพหมวดหมู่หรือไม่? ยืนยันว่าการปิดใช้งานหมวดหมู่ใน CMP ส่งผลให้เหตุการณ์ไม่ถูกส่งต่อไปยังปลายทางในหมวดหมู่นั้น
• แหล่งฝั่งเซิร์ฟเวอร์มีการยินยอมหรือไม่? ยืนยันว่าการเรียกฝั่งเซิร์ฟเวอร์ค้นหาและแนบสถานะการยินยอมปัจจุบันของผู้ใช้ในเวลาส่ง
• Privacy API ทำงานเมื่อมีการเพิกถอนหรือไม่? ยืนยันว่าการเพิกถอนที่เริ่มต้นโดย CMP เรียก API การระงับหรือการลบของ Segment ไม่ใช่แค่การยกเลิกการสมัคร SDK ในเครื่อง

Segment เหมาะกับสแตคที่เน้นการยินยอมอย่างไร

CDP ครองตำแหน่งที่มีอิทธิพลมากที่สุดในสถาปัตยกรรมความเป็นส่วนตัว: การตัดสินใจครั้งเดียวที่แบนเนอร์ CMP จะต้องแพร่กระจายไปยังปลายทางดาวน์สตรีมหลายสิบแห่ง แต่ละแห่งมีท่าทีทางกฎหมายของตัวเอง สถาปัตยกรรมที่ถูกต้องปฏิบัติต่อ CMP เป็นแหล่งของความจริงสำหรับการตั้งค่าหมวดหมู่ของผู้ใช้ แนบความจริงนั้นกับทุกเหตุการณ์ที่ Segment นำเข้า และใช้ primitives ตัวกรองปลายทางของ Segment เพื่อบังคับใช้การควบคุมระดับหมวดหมู่ที่ชั้นการกำหนดเส้นทางแทนที่จะเป็นปลายทางแต่ละแห่ง ทำถูกต้องแล้ว งานวิศวกรรมจะเพิ่มขึ้นเชิงเส้นตรงตามจำนวนปลายทาง — การเพิ่มปลายทางใหม่คือการตัดสินใจจำแนกประเภทและกฎตัวกรอง ไม่ใช่การผสานรวมใหม่ ทำผิดแล้ว CDP จะกลายเป็นตัวคูณความเป็นส่วนตัว ส่งต่อเหตุการณ์ที่ละเมิดการยินยอมไปยังพาร์ทเนอร์หางยาวเร็วกว่าที่การตรวจสอบด้วยตนเองจะตามทัน