ในบทความนี้
- คอมโพเนนต์ของความยินยอมเพิ่มเติม
- รูปแบบสตริง "ความยินยอมเพิ่มเติม" (AC)
- CMP ที่รองรับความยินยอมเพิ่มเติม
- การขยายการใช้งานไปยัง CMP API
- วิธีที่ควรใช้จัดเก็บสตริง AC
- วิธีส่งสตริง AC ผ่านเชนการโฆษณาดิจิทัล
- แหล่งข้อมูลที่เกี่ยวข้อง
เอกสารนี้อธิบายข้อกำหนดทางเทคนิคเกี่ยวกับความยินยอมเพิ่มเติมของ Google ซึ่งมีวัตถุประสงค์เพียงเพื่อนำมาใช้ควบคู่ไปกับกรอบความโปร่งใสและความยินยอม (TCF) เวอร์ชัน 2 ของ IAB Europe เท่านั้นเพื่อส่งสัญญาณความโปร่งใสและ/หรือสัญญาณความยินยอมไปยังผู้ให้บริการที่ยังไม่ได้จดทะเบียนในรายชื่อผู้ให้บริการทั่วโลก (GVL) ของ IAB Europe ข้อกำหนดนี้จะช่วยให้ผู้เผยแพร่โฆษณา แพลตฟอร์มการจัดการความยินยอม (CMP) และพาร์ทเนอร์สามารถเก็บรวบรวมและเผยแพร่ความยินยอมเพิ่มเติมควบคู่ไปกับการใช้ TCF สำหรับบริษัทที่ยังไม่ได้จดทะเบียนในรายชื่อผู้ให้บริการทั่วโลกของ IAB Europe แต่อยู่ในรายชื่อผู้ให้บริการด้านเทคโนโลยีโฆษณา (ATP) ของ Google
คอมโพเนนต์ของความยินยอมเพิ่มเติม
ความยินยอมเพิ่มเติมประกอบด้วยสตริง addtl_consent (สตริง AC) ขนาดเล็ก ซึ่งมีรายชื่อของผู้ให้บริการเทคโนโลยีโฆษณา (ATP) ของ Google ที่ได้รับความยินยอมและ/หรือเปิดเผยแล้วซึ่งไม่ได้จดทะเบียนในรายชื่อผู้ให้บริการทั่วโลก (GVL) ของ IAB
วิธีสร้างสตริง "ความยินยอมเพิ่มเติม" เวอร์ชัน 2 (ACv2)
ข้อมูลที่จัดเก็บในสตริง AC
สตริง AC ประกอบด้วยคอมโพเนนต์ต่อไปนี้
-
ส่วนที่ 1: หมายเลขเวอร์ชันของข้อกำหนด เวอร์ชันปัจจุบันคือ "
2" -
ส่วนที่ 2: สัญลักษณ์คั่น "
~" -
ส่วนที่ 3: รายการรหัสของผู้ให้บริการด้านเทคโนโลยีโฆษณา (ATP) ของ Google ซึ่งผู้ใช้ให้ความยินยอมแล้ว โดยมีการคั่นด้วยจุด เช่น "
1.35.41.101" -
ส่วนที่ 4: สัญลักษณ์คั่น "
~" -
ส่วนที่ 5: "dv." ตามด้วยรายการรหัสของผู้ให้บริการด้านเทคโนโลยีโฆษณา (ATP) ของ Google ที่เปิดเผย โดยมีการคั่นด้วยจุด เช่น "
dv.9.21.81"เพื่อลดความยาวของสตริง ผู้ให้บริการที่รวมอยู่ในส่วนที่ 3 ไม่ควรรวมอยู่ในส่วนที่ 5
ตัวอย่างสตริง AC
หากผู้ให้บริการ ATP ที่มีรหัส 1, 2, 3, 4 และ 10 ได้รับการเปิดเผยต่อผู้ใช้
- …และผู้ใช้เห็นข้อความ CMP ที่เปิดเผยผู้ให้บริการเหล่านี้ แต่ยังไม่ได้ตัดสินใจว่าจะให้ความยินยอมหรือไม่: สตริง ACv2 ที่เกี่ยวข้องจะเป็น
2~~dv.1.2.3.4.10 -
…และผู้ใช้ให้ความยินยอมแก่ผู้ให้บริการทั้งหมด: สตริง ACv2 ที่เกี่ยวข้องจะเป็น
2~1.2.3.4.10~dv.โปรดทราบว่า "." หลัง dv นั้นเป็นตัวเลือกในกรณีนี้เท่านั้น ดังนั้น2~1.2.3.4.10~dvจึงเป็นสตริง ACv2 ที่ยอมรับได้เช่นกัน - …และผู้ใช้ปฏิเสธการให้ความยินยอมแก่ผู้ให้บริการทั้งหมด สตริง ACv2 ที่เกี่ยวข้องควรระบุว่ามีการเปิดเผยผู้ให้บริการทั้งหมดแล้ว แต่ไม่มีผู้ให้บริการรายใดได้รับความยินยอม สตริง ACv2 ที่เกี่ยวข้องจะเป็น
2~~dv.1.2.3.4.10 - …และผู้ใช้ได้ให้ความยินยอมแก่ผู้ให้บริการ
1และ10แต่ปฏิเสธที่จะให้ความยินยอมแก่ผู้ให้บริการรายอื่นๆ ทั้งหมด สตริง ACv2 ที่เกี่ยวข้องจะเป็น2~1.10~dv.2.3.4
ผู้ที่ควรสร้างสตริง 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 เก็บรวบรวม แชร์ และใช้ข้อมูลส่วนตัวเพื่อการปรับโฆษณาตามโปรไฟล์ของผู้ใช้ รวมถึงการปฏิบัติตามข้อกำหนดอื่นๆ ทั้งหมดในนโยบายความยินยอมของผู้ใช้ 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
ระบบยังรองรับสตริงความยินยอมเพิ่มเติมเวอร์ชัน 1 อยู่ไหม
ความยินยอมเพิ่มเติมเวอร์ชัน 2 เป็นเวอร์ชันความยินยอมเพิ่มเติมมาตรฐานตั้งแต่เดือนธันวาคม 2023 ระบบจะยังคงรองรับสตริงความยินยอมเพิ่มเติมที่สร้างขึ้นตามข้อกำหนดเวอร์ชัน 1 ต่อไป อย่างไรก็ตาม สตริงดังกล่าวไม่สามารถระบุได้ว่ามีการสร้างความโปร่งใสให้กับ ATP หรือไม่ CMP ควรเปลี่ยนไปใช้ข้อกําหนดเวอร์ชัน 2 เพื่อรองรับกรณีการใช้งานที่ไม่จําเป็นต้องได้รับความยินยอม
CMP ที่ได้รับการรับรองซึ่งรองรับความยินยอมเพิ่มเติม
รายการนี้ประกอบด้วย CMP ที่ได้รับการรับรองซึ่งรองรับข้อกำหนดทางเทคนิคเกี่ยวกับความยินยอมเพิ่มเติมของ Google รวมถึงเวอร์ชันความยินยอมเพิ่มเติมที่รองรับ
หากคุณเป็น CMP ที่รองรับความยินยอมเพิ่มเติม และ (1) ไม่ได้อยู่ในรายการนี้ หรือ (2) มีการแสดงเวอร์ชันความยินยอมเพิ่มเติมที่ไม่ถูกต้อง โปรดไปที่แบบฟอร์มข้อมูลเบื้องต้นของ CMP แล้วเลือกประเภทคำขอ "ฉันต้องการถามคําถามหรืออัปเดตสถานะ" เราจะพยายามอย่างเต็มที่เพื่ออัปเดตข้อมูลให้แสดงสถานะของคุณอย่างทันท่วงที
คําแนะนําเกี่ยวกับข้อมูลในรายการนี้
รายการนี้มีข้อมูลต่อไปนี้เกี่ยวกับ CMP ที่ได้รับการรับรองแต่ละรายการ
- CMP ที่ได้รับการรับรอง: ชื่อของ CMP ที่ได้รับการรับรอง
- รหัส CMP ของ TCF: ตัวระบุที่ไม่ซ้ำกันซึ่ง IAB กําหนดให้กับ CMP ที่ผ่านการตรวจสอบ TCF แล้ว
- ความยินยอมเพิ่มเติม: เวอร์ชันความยินยอมเพิ่มเติมที่ CMP รองรับ
รายการ CMP ที่ได้รับการรับรองซึ่งรองรับความยินยอมเพิ่มเติม
การขยายการใช้งานไปยัง CMP API
CMP ที่รองรับความยินยอมเพิ่มเติมควรส่งคืนสตริงความยินยอมเพิ่มเติมเป็นส่วนหนึ่งของออบเจ็กต์ JSON ของ JavaScript API ของ CMP ที่สอดคล้องกับ TCF เวอร์ชัน 2 ที่มีอยู่ ซึ่งได้แก่ TCData และ InAppTCData
TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
วิธีที่ควรใช้จัดเก็บสตริง AC
เว็บไซต์
CMP จะเลือกกลไกการเก็บข้อมูล
ในแอป
NSUserDefaults (iOS) หรือ SharedPreferences (Android) ใช้เพื่อจัดเก็บสตริง AC ที่สร้างโดย CMP SDK ซึ่งคล้ายกับ API ในแอปสำหรับ TCFv2 กลไกนี้ช่วยให้ทำสิ่งต่อไปนี้ได้
-
ผู้ให้บริการเข้าถึงสตริง AC ได้โดยง่าย
-
สตริง AC คงอยู่ในเซสชันแอปต่างๆ
-
เพื่อความสามารถในการถ่ายโอนได้ของสตริง AC ในกรณีที่ผู้เผยแพร่โฆษณาเปลี่ยน CMP
หมายเหตุ: หากผู้เผยแพร่โฆษณาเลือกที่จะนำ 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 คือ 2~1.35.41.101~dv.
ตัวเรียกหรือตัวแสดงผลครีเอทีฟโฆษณาจะแทนที่มาโครใน URL ที่มีสตริง AC จริง เพื่อให้พิกเซลที่วางไว้ตั้งแต่แรกซึ่งมีมาโครได้รับการแก้ไขดังนี้เมื่อเรียกไปยังเซิร์ฟเวอร์ที่ระบุ
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=2~1.35.41.101~dv.