TC string คืออะไรกันแน่

IAB Transparency & Consent Framework สร้างโทเค็นกะทัดรัดเพียงหนึ่งเดียว — TC string — ที่เดินทางไปกับทุกคำขอโฆษณาและบอกผู้ขายอย่างแม่นยำว่าผู้ใช้ได้ตกลงและไม่ได้ตกลงในสิ่งใด มันถูกเข้ารหัสแบบ Base64-URL และบรรจุในระดับบิต จึงดูเหมือนอักขระสับสน (CPxy...AAA) แต่เข้ารหัสบันทึกที่แม่นยำและตรวจสอบได้

เซกเมนต์ต่างๆ

TC string ฉบับเต็มมีหลายเซกเมนต์คั่นด้วยจุด เซกเมนต์แรกคือสตริงหลัก ส่วนที่เหลือเป็นทางเลือก:

• หลัก — CMP ID, เวอร์ชัน CMP, การประทับเวลาความยินยอม, เวอร์ชันนโยบาย และที่สำคัญคือบิตฟิลด์ของความยินยอมตามวัตถุประสงค์และความยินยอมต่อผู้ขาย
• ผู้ขายที่เปิดเผย — ผู้ขายรายใดที่แสดงให้ผู้ใช้เห็น
• Publisher TC — ความยินยอมเฉพาะสำหรับคุณ ผู้เผยแพร่

บิตฟิลด์คือหัวใจของมัน: บิต N ที่ตั้งค่าเป็น 1 หมายถึงความยินยอมสำหรับวัตถุประสงค์ N หรือผู้ขาย N วัตถุประสงค์ 1 คือ “จัดเก็บ/เข้าถึงข้อมูลบนอุปกรณ์” วัตถุประสงค์ 3 และ 4 ครอบคลุมโฆษณาที่ปรับให้เป็นส่วนตัว และอื่นๆ

การถอดรหัสในทางปฏิบัติ

คุณแทบไม่ถอดรหัสบิตด้วยมือ ใช้ไลบรารีที่ IAB จัดเตรียมไว้หรือตัวถอดรหัสสาธารณะ:

• แยกที่ . และถอดรหัส Base64-URL เซกเมนต์หลัก
• อ่านฟิลด์ส่วนหัวที่มีความกว้างคงที่ (version, created, lastUpdated, cmpId, cmpVersion)
• เดินผ่านบิตฟิลด์ของวัตถุประสงค์และผู้ขายเพื่อดูอย่างแม่นยำว่ารายการใดได้รับการอนุญาต

ใน JavaScript การเรียก __tcfapi('getTCData', 2, cb) จะคืนค่าอ็อบเจกต์ที่แยกวิเคราะห์แล้ว — tcData.purpose.consents และ tcData.vendor.consents เป็นแมปของ id → boolean นั่นคือความจริงพื้นฐานของคุณในขณะรันไทม์

ข้อผิดพลาดที่ทำลายรายได้

เมื่ออุปสงค์ที่ปรับให้เป็นส่วนตัวหายไปอย่างเงียบๆ มักเป็นเพราะ TC string:

• สตริงหายไป — คำขอโฆษณาไม่มี gdprApplies/TC string ดังนั้น SSP ที่ปฏิบัติตามจึงตกลงสู่แบบไม่ปรับให้เป็นส่วนตัว
• ผู้ขายไม่ได้รับความยินยอม — บิต ID ผู้ขายของพาร์ทเนอร์อุปสงค์ของคุณเป็น 0 ดังนั้นจึงประมูลด้วยการปรับให้เป็นส่วนตัวไม่ได้
• สตริงหมดอายุหรือค้างเก่า — การประทับเวลาเก่าทำให้แพลตฟอร์มปลายน้ำไม่ไว้วางใจ
• CMP ID ผิด — CMP ID ที่ไม่ได้ลงทะเบียนหรือเป็นแบบทดสอบทำให้ทั้งสตริงเป็นโมฆะ

ขั้นตอนการดีบัก

จำลองความยินยอมของผู้ใช้ ดึง TC string สดจาก __tcfapi หรือคำขอโฆษณา รันผ่านตัวตรวจสอบความถูกต้อง และเปรียบเทียบวัตถุประสงค์/ผู้ขายที่ถอดรหัสแล้วกับสิ่งที่พาร์ทเนอร์ของคุณต้องการ เก้าในสิบครั้งช่องว่างคือบิตผู้ขายเพียงตัวเดียวหรือวัตถุประสงค์ 1 ที่หายไป

FlexyConsent เข้ามามีบทบาทตรงไหน

FlexyConsent สร้าง TC string ที่ถูกต้องตามข้อกำหนดด้วย CMP ID ที่ลงทะเบียนแล้ว รักษาให้สดอยู่เสมอ เปิดเผยสถานะที่ถอดรหัสแล้วสำหรับการดีบัก และรายงานว่าวัตถุประสงค์และผู้ขายรายใดได้รับการอนุญาตจริงทั่วทราฟฟิกของคุณ — เพื่อให้คุณเห็น ไม่ใช่เดา ว่าความยินยอม (และรายได้) รั่วไหลที่ไหน

ประเด็นสำคัญ

• TC string เป็นบันทึกที่บรรจุระดับบิตและตรวจสอบได้ของทุกตัวเลือกความยินยอม
• บิตฟิลด์ของวัตถุประสงค์และผู้ขายตัดสินว่าพาร์ทเนอร์สามารถให้บริการโฆษณาที่ปรับให้เป็นส่วนตัวได้หรือไม่
• รายได้ที่ตกส่วนใหญ่สืบย้อนไปถึงสตริงที่หายไป ผู้ขายที่ไม่ได้รับความยินยอม หรือ CMP ID ที่ค้างเก่า/ไม่ถูกต้อง
• ขณะดีบัก ให้ถอดรหัสสตริงสดด้วย __tcfapi และตรวจสอบความถูกต้องเทียบกับข้อกำหนดของพาร์ทเนอร์