ข้อกำหนดทางเทคนิคเกี่ยวกับความยินยอมเพิ่มเติมของ Google

ผู้เผยแพร่โฆษณาที่ต้องการทํางานร่วมกับผู้ให้บริการเทคโนโลยีโฆษณา (ATP) ที่ไม่ใช่ TCF ควรทํางานร่วมกับ CMP ของตนโดยตรง

เอกสารนี้ระบุข้อกําหนดทางเทคนิค (เรียกว่า "ความยินยอมเพิ่มเติม") สำหรับใช้ควบคู่กับกรอบความโปร่งใสและความยินยอม (TCF) ของ IAB Europe เวอร์ชัน 2 เท่านั้น เพื่อส่งสัญญาณความโปร่งใสและ/หรือความยินยอมไปยังผู้ให้บริการที่ยังไม่ได้จดทะเบียนในรายชื่อผู้ให้บริการทั่วโลก (GVL) ของ IAB Europe ข้อกำหนดนี้จะช่วยให้ผู้เผยแพร่โฆษณา แพลตฟอร์มการจัดการความยินยอม (CMP) และพาร์ทเนอร์สามารถเก็บรวบรวมและเผยแพร่ความยินยอมเพิ่มเติมควบคู่ไปกับการใช้ TCF สำหรับบริษัทที่ยังไม่ได้จดทะเบียนในรายชื่อผู้ให้บริการทั่วโลกของ IAB Europe แต่อยู่ในรายชื่อผู้ให้บริการด้านเทคโนโลยีโฆษณา (ATP) ของ Google

การเปลี่ยนแปลงความยินยอมเพิ่มเติม เวอร์ชัน 2

Google รองรับข้อกําหนดเกี่ยวกับความยินยอมเพิ่มเติมเวอร์ชัน 2 ตั้งแต่เดือนธันวาคม 2023 เป็นต้นไป การเปลี่ยนแปลงหลักๆ มีดังนี้

อัปเดตสตริงความยินยอมเพิ่มเติม (AC) เพื่อรองรับผู้ให้บริการที่เปิดเผยใน CMP
อัปเดตเป็น CMP API เพื่ออนุญาตความสามารถในการทำงานร่วมกันของ CMP ที่รองรับทั้ง TCF และโหมดความยินยอมของผู้ลงโฆษณา

เราจะยังคงรองรับสตริง AC ที่สร้างขึ้นตามข้อกำหนดเวอร์ชัน 1 ต่อไป

คอมโพเนนต์ของความยินยอมเพิ่มเติม

เรารองรับทั้ง 2 ข้อต่อไปนี้ใน "ความยินยอมเพิ่มเติม"

สตริงความโปร่งใสและความยินยอม (สตริง TC) ดังที่ระบุไว้ในข้อกำหนด TCF เวอร์ชัน 2.2 ของ IAB ซึ่งมีความโปร่งใสและความยินยอมที่สร้างขึ้นมาสำหรับผู้ให้บริการที่อยู่ในรายชื่อผู้ให้บริการทั่วโลก (GVL) ของ IAB และ
สตริง addtl_consent (สตริง AC) ขนาดเล็ก ซึ่งมีรายชื่อของผู้ให้บริการเทคโนโลยีโฆษณา (ATP) ของ Google ที่ได้รับความยินยอมและ/หรือเปิดเผยแล้วซึ่งไม่ได้จดทะเบียนกับ IAB

ข้อกำหนดนี้ระบุสิ่งต่อไปนี้

รูปแบบสตริง AC
การขยายการใช้งานไปยัง CMP API เวอร์ชัน 2.2 ของ TCF เพื่อรองรับสตริง AC และการควบคุมเมื่อมีทั้ง TCF และโหมดความยินยอมของผู้ลงโฆษณา
วิธีที่ควรจัดเก็บสตริง AC
วิธีส่งสตริง AC ผ่านเชนการโฆษณาดิจิทัล

รูปแบบสตริง "ความยินยอมเพิ่มเติม" (AC)

ข้อมูลที่จัดเก็บในสตริง AC

สตริง AC ประกอบด้วยคอมโพเนนต์ต่อไปนี้

ส่วนที่ 1: หมายเลขเวอร์ชันของข้อกำหนด เช่น "2"
ส่วนที่ 2: สัญลักษณ์คั่น "~"
ส่วนที่ 3: รายการรหัสของผู้ให้บริการด้านเทคโนโลยีโฆษณา (ATP) ของ Google ซึ่งผู้ใช้ให้ความยินยอมแล้ว โดยมีการคั่นด้วยจุด เช่น "1.35.41.101"
ส่วนที่ 4: สัญลักษณ์คั่น "~"
ส่วนที่ 5: "dv." ตามด้วยรายการรหัสของผู้ให้บริการด้านเทคโนโลยีโฆษณา (ATP) ของ Google ที่เปิดเผย โดยมีการคั่นด้วยจุด เช่น "dv.9.21.81"

เพื่อลดความยาวของสตริง ผู้ให้บริการที่รวมอยู่ในส่วนที่ 3 ไม่ควรรวมอยู่ในส่วนที่ 5

ตัวอย่างสตริง AC

สตริง AC 2~1.35.41.101~dv.9.21.81 หมายความว่าผู้ใช้ให้ความยินยอมแก่ ATP ที่มีรหัส 1, 35, 41 และ 101 ขณะที่ ATP ที่มีรหัส 9, 21 และ 81 ได้รับการเปิดเผยต่อผู้ใช้ และสตริงสร้างขึ้นโดยใช้รูปแบบที่ระบุไว้ในข้อกำหนดเวอร์ชัน 2

ผู้ที่ควรสร้างสตริง AC

สตริง AC สร้างได้โดย CMP ที่จดทะเบียน TCF ของ IAB Europe โดยใช้หมายเลขรหัส CMP ที่กำหนดให้ซึ่งเป็นไปตามนโยบายของ IAB เท่านั้น ผู้ให้บริการหรือผู้ให้บริการบุคคลที่สามรายอื่นๆ จะสร้างสตริง AC เองไม่ได้

แหล่งที่เผยแพร่ ATP ของ Google

Google จะเผยแพร่รายชื่อและรหัสของผู้ให้บริการเทคโนโลยีโฆษณาที่ไม่ได้ลงทะเบียนกับ IAB ไว้ที่

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

กรณีที่ควรสร้างสตริง AC

การสร้างสตริง AC จะทำได้ต่อเมื่อผู้เผยแพร่โฆษณาปฏิบัติตามนโยบายความยินยอมของผู้ใช้ EU ของ Google เท่านั้น

ควรถือว่าผู้ให้บริการที่ได้รับความยินยอมเป็นส่วนหนึ่งเฉพาะในกรณีที่ผู้ใช้ให้ความยินยอมที่ถูกต้องตามกฎหมาย

เมื่อใช้คุกกี้หรือพื้นที่เก็บข้อมูลอื่นๆ ในเครื่องตามที่กฎหมายกำหนด และ
เมื่อ ATP เก็บรวบรวม แชร์ และใช้ข้อมูลส่วนตัวเพื่อการปรับโฆษณาตามโปรไฟล์ของผู้ใช้ รวมถึงกรณีที่ผู้เผยแพร่โฆษณาหรือ CMP ที่ขอความยินยอมได้ปฏิบัติตามข้อกำหนดอื่นๆ ทั้งหมดในนโยบายความยินยอมของผู้ใช้ EU ของ Google

ผู้ให้บริการที่เปิดเผยซึ่งไม่ได้รับความยินยอม

เมื่อใช้คุกกี้หรือพื้นที่เก็บข้อมูลอื่นๆ ในเครื่องตามที่กฎหมายกำหนด และ
เมื่อเก็บรวบรวม แชร์ และใช้ข้อมูลส่วนตัวเพื่อการปรับโฆษณาตามโปรไฟล์ของผู้ใช้เฉพาะในกรณีที่มีการแสดงความโปร่งใสอย่างเหมาะสมแก่ผู้ใช้เกี่ยวกับตัวตนของ ATP แต่ละราย รวมถึงการลิงก์ไปยังนโยบายความเป็นส่วนตัวของ ATP ตามที่ระบุไว้ในรายชื่อ ATP ของ Google

สตริง AC ต้องสร้างขึ้นเพื่อเป็นสตริงเสริมของสตริง TC เท่านั้น ไม่ใช่แทนที่สตริง TC Google จะไม่ดำเนินการตามคำขอและจะนำสตริง AC ในคำขอที่ได้รับออก หากสตริง TC ไม่พร้อมใช้งานสำหรับคำขอเดียวกัน

CMP ที่ใช้ข้อกำหนดนี้ต้องตรวจสอบว่าสตริง AC ที่สร้างมีเฉพาะรหัสจากไฟล์ Google ATP ที่เผยแพร่อยู่ (ผู้ให้บริการที่ไม่ได้อยู่ใน GVL) เท่านั้น เมื่อ Google ได้รับสตริง TC เราจะตรวจสอบเวอร์ชันของ GVL ที่ระบุไว้ในสตริง TC ดังกล่าว หาก GVL เวอร์ชันนั้นมีการลงทะเบียนสำหรับผู้ให้บริการ การควบคุมสตริง TC และรายการในสตริง AC ของผู้ให้บริการรายนั้นจะไม่มีผล ในกรณีเช่นนี้ Google ขอสงวนสิทธิ์ในการนำรายการที่ "ซ้ำกัน" ดังกล่าวออกจากสตริง AC และส่งสตริง AC ที่แก้ไขแล้วไปพร้อมกับสตริง TC ผู้ให้บริการรายอื่นที่ไม่ใช่ Google ไม่ได้รับอนุญาตให้แก้ไขสตริง AC

แหล่งข้อมูลที่เกี่ยวข้อง

การขยายการใช้งานไปยัง CMP API

เราเสนอที่จะขยายการใช้งาน JavaScript API ของ CMP สำหรับ TCF เวอร์ชัน 2.2 ที่มีอยู่เพื่ออนุญาตให้มีการส่งกลับสตริง AC กล่าวอย่างเจาะจงก็คือ เราเสนอที่จะขยายการใช้งานออบเจ็กต์ JSON TCData และ InAppTCData เพื่อส่งข้อมูลนี้กลับ

TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

วิธีที่ควรใช้จัดเก็บสตริง AC

เว็บไซต์

CMP จะเลือกกลไกการเก็บข้อมูล

ในแอป

CMP SDK จะใช้ NSUserDefaults (iOS) หรือ SharedPreferences (Android) เพื่อจัดเก็บสตริง AC วิธีนี้ทำให้

ผู้ให้บริการเข้าถึงสตริง AC ได้โดยง่าย
สตริง AC คงอยู่ในเซสชันแอปต่างๆ
สตริง AC สามารถถ่ายโอนระหว่าง CMP เพื่อช่วยให้ผู้เผยแพร่โฆษณาแลกเปลี่ยน CMP SDK รายการหนึ่งกับอีกรายการได้อย่างยืดหยุ่น

หากผู้เผยแพร่โฆษณาเลือกที่จะนำ CMP SDK ออกจากแอป ก็ต้องเป็นผู้ล้างค่า AddtlConsent ให้กับผู้ใช้เพื่อให้ผู้ให้บริการหยุดใช้สตริง AC ที่รวมไว้

คีย์การเก็บข้อมูลและการค้นหาใน NSUserDefaults และ SharedPreferences	ค่า
`IABTCF_AddtlConsent`	สตริง: สตริง AC ที่มีเวอร์ชันข้อกำหนดและรหัสของผู้ให้บริการเทคโนโลยีโฆษณาที่ผู้ใช้ให้ความยินยอมแล้ว

วิธีส่งสตริง AC ผ่านเชนการโฆษณาดิจิทัล

คำขอราคาเสนอ

เราจะใช้ ConsentedProvidersSettings ซ้ำเพื่อเผยแพร่ผู้ให้บริการที่ไม่ได้อยู่ใน GVL ภายหลัง

ใน protocol ส่วนขยายของ OpenRTB
Protocolbuffer เวอร์ชันเดิม

message ConsentedProvidersSettings { // Set of IDs corresponding to providers for whom the publisher has told // Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local // storage where legally required; and 2) the collection, sharing, and use of personal data for // personalization of ads by an ATP in accordance with Google’s EU User Consent Policy. // A mapping of provider ID to provider name is posted at providers.csv. repeated int64 consented_providers = 2 [packed = true]; }

// Information about the providers for whom the publisher has told Google // that its EEA users have consented to the use of their personal data for // ads personalization in accordance with Google's EU User Consent Policy. // This field will only be populated when regs_gdpr is true. optional ConsentedProvidersSettings consented_providers_settings = 42;

บริการผ่าน URL

เมื่อครีเอทีฟโฆษณาแสดงผล อาจมีพิกเซลจำนวนหนึ่งอยู่ในแท็ก <img> เช่น <img src="http://vendor-a.com/key1=val1&key2=val2"> ซึ่งจะส่งคำขอ HTTP GET จากเบราว์เซอร์ไปยังโดเมนของผู้ให้บริการ

พิกเซลจะอยู่ในแท็ก <img> โดยไม่สามารถเรียกใช้ JavaScript ได้ จึงไม่สามารถใช้ CMP API เพื่อรับสตริง TC เรามีพารามิเตอร์ของ URL และมาโครมาตรฐานให้ใน URL พิกเซลที่ควรแทรกสตริง AC ซึ่งคล้ายกับการรองรับสตริง TC

พารามิเตอร์ของ URL	มาโครที่ตรงกัน	การแทนใน URL
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

ตัวอย่างที่ 1

ผู้ให้บริการ ก จะได้รับสตริง AC ต่อเมื่อ URL ของรูปภาพมีคู่คีย์-ค่าพร้อมกับพารามิเตอร์ของ URL และมาโคร &addtl_consent=${ADDTL_CONSENT} ดังนั้น URL ที่ได้คือ

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

ตัวอย่างที่ 2

ในคำขอหนึ่ง หากสตริง AC คือ 1~1.35.41.101

ตัวเรียกหรือตัวแสดงผลครีเอทีฟโฆษณาจะแทนที่มาโครใน URL ที่มีสตริง AC จริง เพื่อให้พิกเซลที่วางไว้ตั้งแต่แรกซึ่งมีมาโครได้รับการแก้ไขดังนี้เมื่อเรียกไปยังเซิร์ฟเวอร์ที่ระบุ

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

ข้อมูลนี้มีประโยชน์ไหม

เราจะปรับปรุงได้อย่างไร