สรุปสั้น ๆ

TCF v2.3 เป็นวิวัฒนาการต่อจาก v2.2 ไม่ใช่การออกแบบสถาปัตยกรรมใหม่ TC String ยังคงใช้รูปแบบที่เข้ากันได้ จุดประสงค์ (purposes) และฟีเจอร์เดิมยังคงอยู่ และข้อกำหนดด้าน UI ที่หันหน้าเข้าหาผู้เผยแพร่ส่วนใหญ่ยังใช้ต่อได้โดยแทบไม่เปลี่ยน การเปลี่ยนแปลงที่มีนัยสำคัญจะกระจุกอยู่ใน 4 ด้านหลัก:

• กฎที่ชัดเจนขึ้นเกี่ยวกับวิธีที่ CMP ต้องแสดง ข้อมูลของ vendor และ ระยะเวลาเก็บรักษาข้อมูล (retention periods)
• ข้อกำหนดใหม่สำหรับ การควบคุมแบบละเอียดในเลเยอร์ที่สอง ซึ่งหน่���ยงานกำกับดูแลเรียกร้องมาตั้งแต่คำตัดสินของ Belgian DPA ในปี 2022
• การบังคับใช้ นโยบาย ที่เข้มงวดขึ้นเกี่ยวกับ dark pattern ความเด่นเท่าเทียมกันของปุ่ม และการห้ามตัวเลือกที่ถูกติ๊กไว้ล่วงหน้า
• การปรับโครงสร้างของ Global Vendor List (GVL) และ flow การเปิดเผยข้อมูล vendor

เหตุผลที่มี v2.3

ทุกเวอร์ชันของ TCF เป็นการประนีประนอมระหว่าง 3 กลุ่มหลัก: ผู้เผยแพร่ที่ต้องการรักษารายได้โฆษณา vendor ที่ต้องการอินเทอร์เฟซทางเทคนิคที่เสถียร และหน่วยงานกำกับดูแลที่ยังคงพบช่องโหว่ด้านการปฏิบัติตามกฎหมายอย่างต���อเนื่อง v2.3 เป็นการตอบสนองโดยตรงต่อแรงกดดัน 3 ด้าน:

1. มาตรการบังคับใช้ต่อการใช้ฐานกฎหมาย "legitimate interest" เกินความจำเป็น ภายใต้ v2.2 หน่วยงานคุ้มครองข้อมูลส่วนบุคคลในยุโรปหลายแห่งเห็นว่า vendor จำนวนมากอ้าง LI สำหรับวัตถุประสงค์ที่ในความเป็นจริงต้องใช้ฐานความยินยอมเท่านั้น v2.3 จึงเข้มงวดขึ้นกับการเปิดเผยฐานกฎหมายที่ vendor ประกาศใช้ และดันข้อมูลนี้ขึ้นมาให้เห็นเร็วขึ้นใน UI ขอความยินยอม
2. ข้อร้องเรียนต่อ dark pattern ที่ยังมีอย่างต่อเนื่อง นโยบายที่อัปเดตทำให้กฎเรื่องความเด่นเท่าเทีย��กัน (equal prominence) ชัดเจนขึ้น และปิดช่องโหว่เกี่ยวกับ toggle ที่ถูกติ๊กไว้ล่วงหน้าในเลเยอร์ที่สอง
3. ข้อเสนอแนะเชิงปฏิบัติการจาก CMP และผู้เผยแพร่รายใหญ่ v2.2 เพิ่มข้อกำหนดการเปิดเผยข้อมูลหลายรายการที่นำไปใช้ได้ยากบนมือถือและ CTV v2.3 จึงปรับชุดข้อมูลที่ต้องเปิดเผยให้กระชับขึ้น และอนุญาตให้ย้ายส่วนหนึ่งไปอยู่ในมุมมองแบบเลเยอร์ได้มากขึ้น

ความเข้ากันได้ของ TC String

ตัว TC String เองยังคงเข้ากันได้ย้อนหลัง CMP ที่ใช้ v2.3 จะสร้างสตริงที่ vendor ฝั่ง v2.2 อ่านได้ และ vendor ที่รองรับ v2.3 ก็ยังสามารถอ่านสตริง v2.2 ได้ในช่วงเปลี่ยนผ่าน ตัวบ่งชี้เวอร์ชันใน segment หลักของสตริงจะระบุว่า CMP อ้างว่าปฏิบัติตามนโยบายเวอร์ชันใด และตัวชี้ไปยังเวอร์ชันของ GVL ก็จะขยับไปข้างหน้าอย่างอิสระจากกัน

ความหมายในทางปฏิบัติคือ: คุณไม่จำเป็นต้องอัปเดต vendor ทุกเจ้าพร้อมกัน และไม่จำเป็นต้องบังคับให้ผู้ใช้ทุกคนให้ความยินยอมใหม่ในวันที่คุณดีพลอย v2.3 การ rollout แบบค่อยเป็นค่อยไปได้รับการรองรับอย่างชัดเจน

การเปลี่ยนแปลงทางเทคนิคหลัก

1. การเปิดเผยข้อมูล vendor และระยะเวลาเก็บรักษา

v2.3 กำหนดให้ CMP ต้องแสดง ระยะเว��าเก็บรักษาข้อมูล ที่ vendor แต่ละรายประกาศไว้ใน UI แบบเลเยอร์ ไม่ใช่เฉพาะในหน้ารายการ vendor แยกต่างหาก ค่า retention นี้มีอยู่ใน GVL มาตลอด แต่ v2.2 ไม่ได้บังคับว่าผู้ใช้ต้องเห็นควบคู่กับจุดประสงค์การประมวลผล v2.3 ปิดช่องว่างนี้ เพราะหน่วยงานกำกับดูแลให้เหตุผลว่าผู้ใช้ไม่สามารถตัดสินใจอย่างมีข้อมูลเพียงพอได้ หากไม่รู้ว่าข้อมูลของตนจะถูกเก็บไว้นานเท่าใด

2. การควบคุมในเลเยอร์ที่สองที่เข้มงวดขึ้น

ในเลเยอร์ที่สอง — มุมมอง "จัดการการตั้งค่า" — v2.3 ระบุอย่างชัดเจนว่า toggle สำหรับวัตถุประสงค์และ vendor ที่ไม่จำเป็นต้องใช้เพื่อการทำงานของบริการ ต้องตั้งค่าเริ่มต้นเป็น ปิด กล่องที่ถูกติ๊กไว้ล่วงหน้าหรือสไลเดอร์ที่เปิดไว้ล่วงหน้าถือเป็นการละเมิดนโยบาย แม้ผู้ใช้จะไม่เคยกด "ยอมรับ" โดยตรงก็ตาม CMP ที่เคยใช้รูปแบบ "soft opt-in" จะต้องเรนเดอร์เลเยอร์ที่สองใหม่

3. การบังคับใช้กฎความเด่นเท่าเทียมกัน

กฎเรื่องความเด่นเท่าเทียมกันมีมาตั้งแต่ v2.1 แต่ v2.3 กำหนดรายละเอียดให้ตีความได้น้อยลง: ปุ่ม "ปฏิเสธทั้งหมด" ต้องอยู่ในเลเยอร์เดียวกัน มีน้ำหนักทางสายตาเดียวกัน อยู่ในคลาสสีและ��อนทราสต์เดียวกัน และอยู่ในระยะการโต้ตอบเดียวกันกับปุ่ม "ยอมรับทั้งหมด" การซ่อนปุ่มปฏิเสธไว้หลังลิงก์ ปุ่มที่เล็กกว่า หรือหน้าจอรอง ถูกระบุอย่างชัดเจนแล้วว่าเป็นการไม่ปฏิบัติตาม ไม่ใช่เรื่องดุลยพินิจอีกต่อไป

4. การส่งสัญญาณฐานกฎหมาย Legitimate Interest

vendor ที่ประกาศใช้ legitimate interest เป็นฐานกฎหมายภายใต้ v2.3 ต้องประกาศเพิ่มเติมด้วยว่าตนได้ประเมิน LI สำหรับจุดประสงค์ใดบ้าง และได้ทำ Legitimate Interests Assessment เสร็จสิ้นสำหรับจุดประสงค์ใด CMP ต้องส่งต่อข้อมูลการประกาศนี้ไปยังส่วนติดต่อผู้ใช้ เพื่อให้ผู้ใช้สามารถคัดค้านได้โดยมีข้อมูลครบถ้วน ในทางปฏิบัติหมายความว่า flow การ "คัดค้าน" ตอนนี้จะแสดงสถานะ LIA ราย vendor แทนที่จะเป็นเพียง toggle ทั่วไป

5. การอัปเดตสคีมาของ GVL

สคีมาของ Global Vendor List เพิ่มฟิลด์สำหรับความละเอียดของการระบุระยะเวลาเก็บรักษา สถานะ LIA และลิงก์แบบ machine-readable ไปยังส่วนของนโยบายความเป็นส่วนตัวของ vendor แต่ละรายที่เกี่ยวข้องกับจุดประสงค์ที่ประกาศ CMP ที่แคช GVL ไว้ต้องอัปเดตตัว parser ของสคีมาให้รองรับฟิลด์ใหม่เหล่านี้ก่อนจะชี้ไปยัง GVL เวอร์ชัน v2.3

การเปลี่ยนแปลงด้านนโยบายที่กระทบ UX

TCF เป็นท��้งสเปกทางเทคนิคและชุดของนโยบาย การเปลี่ยนแปลงนโยบายหลายข้อใน v2.3 ส่งผลโดยตรงต่อ UI ขอความยินยอม:

• ไม่ใช้ "ดำเนินการต่อโดยไม่ยอมรับ" แทนปุ่มปฏิเสธอีกต่อไป เว้นแต่จะมีหน้าตาเหมือนปุ่มยอมรับ และสร้าง TC String แบบเดียวกับการปฏิเสธทั้งหมดจริง ๆ
• ความเท่าเทียมด้านภาษา — ข้อความขอความยินยอมต้องมีให้ในทุกภาษาที่เว็บไซต์มีให้บริการ ไม่ใช่เฉพาะภาษาที่เบราว์เซอร์ของผู้ใช้ตั้งไว้ CMP ต้องรองรับการเลือก locale แทนค่าจากผู้ใช้
• การเข้าถึงที่ต่อเนื่อง — ผู้ใช้ต้องสามารถเข้าถึงศูนย์จัดการการตั้งค่าความยินยอมจากทุกหน้าของเว็บไซต์ ไม่ใช่เฉพาะหน้าแรก และลิงก์เข้าถึงต้องมีข้อความที่ผู้ใช้ทั่วไปเข้าใจได้ว่าเกี่ยวข้องกับการจัดการความยินยอม

สิ่งที่ผู้เผยแพร่ต้องทำ

1. ยืนยันการรองรับ v2.3 จากผู้ให้บริการ CMP ของคุณ ขอวันที่แน่นอนที่ build ซึ่งได้รับการรับรอง v2.3 จะพร้อมใช้งาน และดูว่าเวอร์ชันสตริงที่รายงานคืออะไร
2. รีเฟรช logic การแคช GVL ของคุณ หากคุณโฮสต์มิเรอร์ GVL เอง ให้ปรับปรุง parser ของสคีมาก่อนที่ GVL เวอร์ชัน v2.3 จะ rollout ไม่เช่นนั้น CMP ของคุ���จะไม่สามารถตรวจสอบความถูกต้องของ vendor รายใหม่ได้
3. เขียน UI เลเยอร์ที่สองใหม่ เพื่อให้ทุก toggle ตั้งค่าเริ่มต้นเป็นปิด บังคับใช้ความเด่นเท่าเทียมกันอย่างชัดเจน และแสดงระยะเวลาเก็บรักษาควบคู่กับจุดประสงค์
4. รันการตรวจสอบการปฏิบัติตามอีกครั้ง ช่องโหว่ที่หน่วยงานกำกับดูแลตรวจเจอง่ายที่สุดคือ dark pattern ที่ v2.3 ระบุชื่ออย่างชัดเจนแล้ว แก้ไขให้เรียบร้อยก่อนการตรวจสอบรอบถัดไป
5. วางแผนกลยุทธ์การขอความยินยอมใหม่ (re-prompt) แม้ TC String จะยังเข้ากันได้ย้อนหลัง แต่นโยบายสนับสนุนใ���้ผู้เผยแพร่ขอความยินยอมใหม่เมื่อขอบเขตหรือการเปิดเผยการประมวลผลเปลี่ยนไปอย่างมีนัยสำคัญ พิจารณาว่าการ rollout v2.3 ของคุณเข้าข่าย "มีนัยสำคัญ" สำหรับผู้ใช้ของคุณหรือไม่

สิ่งที่ vendor ต้องทำ

1. ทำ Legitimate Interests Assessment ให้ครบ สำหรับทุกจุดประสงค์ที่คุณประกาศใช้ LI และส่งผลการประเมินไปยัง GVL
2. อัปเดตรายการของคุณใน GVL ด้วยฟิลด์ตามสคีมา v2.3: ความละเอียดของการระบุระยะเวลาเก็บรักษา การประกาศ LIA และ deep link ไปยังนโยบายความเป็นส่วนตัว
3. ทดสอบตัว parser TC String ของคุณ กับสตริงอ้างอิง v2.3 ที่ IAB Europe จัดเตรียมไว้
4. ประสานงานกับพาร์ตเนอร์ CMP ของคุณ เพื่อกำหนดวันที่สลับการใช้งานร่วมกัน เพื่อไม่ให้คำขอซื้อครั้งแรกที่พกสตริง v2.3 ไปถึง vendor ที่รองรับเฉพาะ v2.2

หลุมพรางที่พบบ่อยในการย้ายเวอร์ชัน

• ใช้ v2.3 เป็นโอกาสรีดีไซน์ UI ทั้งหมด การจับการอัปเดตแบรนด์มารวมกับ rollout v2.3 นั้นล่อตาล่อใจ แต่จะทำให้การทดสอบการปฏิบัติตามซับซ้อนขึ้น ปล่อยเวอร์ชัน v2.3 ที่เน้นแค่ความสอดคล้องตามนโยบายก่อน แล้วค่อยปรับดีไซน์ภายหลัง
• ลืมข้อกำหนดเรื่องการแสดงระยะเวลาเก็บรักษา หล��ยทีมอัปเดตเฉพาะมุมมองรายการ vendor แต่ลืมไปว่าตอนนี้ต้องแสดง retention ในมุมมองแบบเลเยอร์ตามจุดประสงค์ด้วย
• คิดว่าแค่มี TC String ก็เพียงพอ สตริงที่ถูกต้องตามสเปกแต่สร้างจาก UI ที่ไม่ปฏิบัติตามนโยบาย ก็ยังถือว่าไม่ปฏิบัติตาม หน่วยงานกำกับดูแลเคยปรับผู้ให้บริการที่มีสตริงดูปกติ แต่แบนเนอร์ซ่อนปุ่มปฏิเสธมาแล้วหลายครั้ง
• ปล่อยให้ CTV และมือถืออยู่นอกขอบเขต v2.3 ใช้กับทุกแพลตฟอร์มที่สร้างสัญญาณ TCF ผู้เผยแพร่ที่อัปเดตเฉพาะเว็บแต่ไม่แตะ CTV หรือแอปมือถือ จะสร้างสภาพแวดล้อมแบบผสมที��ไม่ปฏิบัติตามในบางส่วน

บทสรุป

TCF v2.3 ไม่ใช่การเปลี่ยนแปลงแบบพลิกโฉมจาก v2.2 แต่เป็นการขันนอตกฎเกณฑ์ให้แน่นขึ้นอย่างมีนัยสำคัญ เพื่อค้ำจุนระบบนิเวศโฆษณาโปรแกรมแมติกของยุโรป ทิศทางชัดเจน: โปร่งใสมากขึ้น ลด dark pattern เพิ่มการควบคุมแบบละเอียดให้ผู้ใช้ และลดพื้นที่ให้กรณีชายขอบที่เคยเล็ดรอด CMP และผู้เผยแพร่ที่มอง v2.3 เป็นแค่แพตช์ด่วนจะพบว่าตัวเองกลับไปอยู่หน้าหน่วยงานกำกับดูแลอีกครั้ง ในทางกลับกัน ผู้ที่ใช้โอกาสนี้ปรับ UX เลเยอร์ที่สองให้สะอาด ตัดทางลัดแบบ legitimate interest ที่ไม่เหมาะสม และสร้าง flow การขอความยินยอมที่มีความเด่นเท่าเทียมกันอย่างแท้จริง จะผ่านยุค v2.3 ไปพร้อม inventory ที่ขายได้จริง — และท่าทีด้านความยินยอมที่พร้อมรับมือกับสิ่งที่ v2.4 จะนำมาในอนาคต