รายงานความคิดเห็น - ไตรมาสที่ 4 ปี 2023

รายงานรายไตรมาสสำหรับไตรมาสที่ 4 ปี 2023 ซึ่งสรุปความคิดเห็นเกี่ยวกับระบบนิเวศที่ได้รับเกี่ยวกับข้อเสนอ Privacy Sandbox และการตอบสนองของ Chrome

Google ตกลงที่จะจัดทำรายงานรายไตรมาสเกี่ยวกับกระบวนการมีส่วนร่วมของผู้มีส่วนเกี่ยวข้องสำหรับข้อเสนอ Privacy Sandbox ของตน (ดูวรรคที่ 12 และ 17(ค)(2) ของสัญญาผูกมัด) ซึ่งเป็นส่วนหนึ่งของความมุ่งมั่นที่มีต่อ CMA รายงานสรุปความคิดเห็นเกี่ยวกับ Privacy Sandbox เหล่านี้สร้างขึ้นจากการรวบรวมความคิดเห็นที่ Chrome ได้รับจากแหล่งที่มาต่างๆ ตามที่ระบุไว้ในภาพรวมความคิดเห็น ซึ่งรวมถึงแต่ไม่จำกัดเพียงปัญหาเกี่ยวกับ GitHub, แบบฟอร์มความคิดเห็นที่มีให้ใน privacysandbox.com, การประชุมกับผู้มีส่วนเกี่ยวข้องในอุตสาหกรรม และฟอรัมมาตรฐานเว็บ Chrome ยินดีรับความคิดเห็นที่ได้รับจากระบบนิเวศและกำลังดำเนินการสำรวจวิธีผสานรวมสิ่งที่ได้เรียนรู้เข้ากับการตัดสินใจด้านการออกแบบ

ธีมความคิดเห็นจะจัดอันดับตามความแพร่หลายต่อ API ซึ่งสามารถทำได้โดยรวบรวมความคิดเห็นที่ทีม Chrome ได้รับจากธีมที่กำหนดและจัดระเบียบตามปริมาณจากมากไปน้อย เราระบุธีมความคิดเห็นที่พบบ่อยได้จากการทบทวนหัวข้อการสนทนาจากการประชุมสาธารณะ (W3C, PatCG, IETF), ความคิดเห็นโดยตรง, GitHub และคำถามที่พบบ่อยซึ่งแสดงผ่านทีมภายในของ Google และแบบฟอร์มสาธารณะ

กล่าวอย่างเจาะจงก็คือ รายงานการประชุมสำหรับการประชุมของหน่วยงานรัฐมาตรฐานบนเว็บได้รับการตรวจสอบ และสำหรับความคิดเห็นโดยตรง จะมีการพิจารณาบันทึกการประชุมผู้มีส่วนเกี่ยวข้องแบบ 1:1 ของ Google, อีเมลที่วิศวกรแต่ละคนได้รับ, รายชื่ออีเมล API และแบบฟอร์มแสดงความคิดเห็นสาธารณะ จากนั้น Google ได้ประสานงานระหว่างทีมต่างๆ ที่เกี่ยวข้องกับกิจกรรมการติดต่อเพื่อพิจารณาความแพร่หลายของธีมที่เกิดขึ้นโดยสัมพันธ์กับ API แต่ละรายการ

คำอธิบายคำตอบของ Chrome ที่มีต่อความคิดเห็นนั้นพัฒนาขึ้นจากคำถามที่พบบ่อยที่เผยแพร่ คำตอบที่เกิดขึ้นจริงต่อปัญหาที่ผู้มีส่วนเกี่ยวข้องหยิบยกขึ้นมา และการกำหนดจุดยืนโดยเฉพาะสำหรับวัตถุประสงค์ของแบบฝึกหัดการรายงานต่อสาธารณะนี้ เมื่อพูดถึงประเด็นสำคัญในปัจจุบันของการพัฒนาและการทดสอบ เราได้รับคำถามและความคิดเห็นเกี่ยวกับ Topics, Protected Audience และ Attribution Reporting API

ความคิดเห็นที่ได้รับหลังจากสิ้นสุดระยะเวลาการรายงานปัจจุบันอาจยังไม่ได้รับคำตอบจาก Chrome

อภิธานศัพท์ของตัวย่อ

ชิป

คุกกี้ที่มีสถานะแบ่งพาร์ติชันอิสระ

DSP

แพลตฟอร์มฝั่งดีมานด์

FedCM

การจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์

FPS

ชุดบุคคลที่หนึ่ง

IAB

Interactive Advertising Bureau

ผู้ให้บริการข้อมูลประจำตัว

ผู้ให้บริการข้อมูลประจำตัว

IETF

คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต

อินนิ่ง

ที่อยู่ Internet Protocol

openRTB

การเสนอราคาแบบเรียลไทม์

OT

ช่วงทดลองใช้จากต้นทาง

PatCG

กลุ่มชุมชนเทคโนโลยีการโฆษณาส่วนบุคคล

RP

ฝ่ายอ้างอิง

SSP

แพลตฟอร์มฝั่งซัพพลาย

TEE

สภาพแวดล้อมการดำเนินการที่เชื่อถือได้

UA

สตริง User Agent

UA-CH

คำแนะนำสำหรับไคลเอ็นต์ User Agent

W3C

World Wide Web Consortium

อยู่ระหว่างดำเนินการ

การตาบอด IP โดยเจตนา

ความคิดเห็นทั่วไป ไม่มี API หรือเทคโนโลยีที่เฉพาะเจาะจง

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
ไทม์ไลน์แบบ 3PCD	แชร์ข้อมูลเพิ่มเติมเกี่ยวกับไทม์ไลน์ 3PCD	Chrome ได้จำกัดการใช้ 3PC ของผู้ใช้ 1% โดยค่าเริ่มต้นตั้งแต่วันที่ 4 มกราคม 2024 เพื่ออำนวยความสะดวกในการทดสอบ เพื่อจัดการกับข้อกังวลที่เหลืออยู่เกี่ยวกับ CMA ทาง Chrome วางแผนที่จะค่อยๆ ยกเลิกการรองรับ 3PC ตั้งแต่ไตรมาสที่ 3 ปี 2024 และดำเนินการต่อไปตลอดปี 2024
ไทม์ไลน์แบบ 3PCD	ผลกระทบจากช่วงเวลาของ 3PCD ในไตรมาสที่ 4 ปี 2024 เนื่องจากตรงกับช่วงเทศกาลวันหยุดและอาจส่งผลกระทบด้านลบต่อผู้เผยแพร่โฆษณา	ไม่มีเวลาที่เหมาะที่สุดในการเลิกใช้งาน 3PC เราเข้าใจอย่างชัดเจนว่าเราตั้งใจที่จะเลิกใช้งาน 3PC ในช่วงครึ่งหลังของปี 2024 ความมุ่งมั่นของเราต่อ CMA ซึ่งรวมถึงช่วงเวลาที่เป็นไปได้สำหรับระยะหยุดนิ่งจะไม่มีการเปลี่ยนแปลง แม้ว่าเราจะเข้าใจถึงความกังวลเรื่องเวลาในไตรมาสที่ 4 แต่การเปลี่ยนแปลงลำดับเวลาทำให้มีการเตรียมความพร้อมด้านอุตสาหกรรมน้อยลง
การทดสอบ Chrome (โหมด a/b)	มีการตั้งค่าการทดสอบสำหรับโหมด A และโหมด B ต่ออินสแตนซ์หรือต่อโปรไฟล์ Chrome	เราได้เผยแพร่คำชี้แจงไว้ในเอกสารประกอบแล้วที่นี่ว่าเบราว์เซอร์ Chrome ในบริบทนี้หมายถึงไคลเอ็นต์ Chrome นั่นคือการติดตั้ง Chrome ในอุปกรณ์ ไดเรกทอรีข้อมูลผู้ใช้แต่ละรายจะประกอบด้วยไคลเอ็นต์ที่แตกต่างกัน
ช่วงทดลองใช้การเลิกใช้งาน	แชร์ข้อมูลเพิ่มเติมเกี่ยวกับการทดลองใช้ 3PCD	เราได้แชร์ข้อมูลเพิ่มเติมเกี่ยวกับการทดลองใช้ 3PCD ที่นี่
ช่วงทดลองใช้การเลิกใช้งาน	มีเวลาไม่เพียงพอที่จะมอบโทเค็นสำหรับช่วงทดลองใช้การเลิกใช้งานในทุกเว็บไซต์ก่อนเดือนมกราคม 2024	เราทราบว่าช่วงเวลาสั้นๆ ระหว่างช่วงที่เปิดให้ลงทะเบียนทดลองเลิกใช้งานและเมื่อระยะเวลาการทดสอบที่อำนวยความสะดวกโดย Chrome เริ่มบล็อกคุกกี้ 1% เพื่อจัดการกับข้อจำกัดด้านเวลาเหล่านี้ Chrome จะให้ระยะเวลาผ่อนผันสำหรับต้นทางที่เข้าร่วมในขณะที่กำลังทำให้โทเค็นการทดลองใช้การเลิกใช้งานใช้งานได้ ในช่วงระยะเวลาผ่อนผัน ซึ่งจะเกิดขึ้นจนถึงวันที่ 1 เมษายน 2024 ต้นทางที่ลงทะเบียนสำหรับช่วงทดลองใช้การเลิกใช้งานจะมีสิทธิ์เข้าถึง 3PC ใน Chrome แม้ว่าจะยังไม่ได้ใช้งานโทเค็นก็ตาม วัตถุประสงค์ของระยะเวลาผ่อนผันนี้คือเพื่อป้องกันปัญหาความเข้ากันได้กับเว็บในช่วงการเปลี่ยนผ่าน ต้นทางที่เข้าร่วมต้องติดตั้งใช้งานโทเค็นช่วงทดลองใช้ที่เลิกใช้งานแล้วก่อนสิ้นสุดระยะเวลาผ่อนผัน เพื่อให้เข้าถึง 3PC ต่อไปได้หลังจากระยะเวลาผ่อนผันสิ้นสุดลง
การทดสอบ Chrome (โหมด a/b)	โหมด B มีขนาดเล็กเกินกว่าที่จะวัดประสิทธิภาพที่ลดลงได้อย่างถูกต้องแม่นยำ	เราต้องรักษาสมดุลระหว่างเปอร์เซ็นต์ของการเข้าชมและความเสี่ยงที่จะส่งผลต่อผู้ใช้และฟังก์ชันการทำงานในเว็บ
การควบคุมการทดสอบ	มีเพียงผู้เผยแพร่โฆษณารายใหญ่ที่สุดที่มีทรัพยากรด้านการพัฒนาจำนวนมากเท่านั้นที่จะสามารถทำความเข้าใจประสิทธิภาพระหว่างการทดสอบและส่งต่อให้กับ CMA ได้	เราพบว่าผู้ให้บริการผู้เผยแพร่โฆษณาได้แชร์ข้อมูลเชิงลึกแบบสาธารณะกับระบบนิเวศที่กว้างขึ้นอยู่แล้ว และคาดว่าการดำเนินการนี้จะดำเนินต่อไปเมื่อการทดสอบ Privacy Sandbox เพิ่มขึ้น นอกจากนี้ เรายังคาดหวังให้บริษัทเทคโนโลยีโฆษณาที่พัฒนาจาก Privacy Sandbox API พัฒนาฟีเจอร์ที่ลูกค้าต้องการต่อไป เช่น การรายงานตามป้ายกำกับ
ข้อมูลจากบุคคลที่สาม	ข้อกังวลเกี่ยวกับบริษัทข้อมูลบุคคลที่สาม	บริษัทข้อมูลบุคคลที่สามมีหลายประเภทด้วยกัน บางรายอาจลดลงเป็น 2 เท่า โดยเปลี่ยนไปใช้วิธีการติดตามข้ามเว็บไซต์ที่คลุมเครือมากขึ้น ขณะที่รายอื่นๆ อาจใช้เทคโนโลยีที่ช่วยเพิ่มความเป็นส่วนตัวและพัฒนาคุณค่าใหม่ๆ ที่นำเสนอกับลูกค้า เราหวังว่าจะมีทางเลือกมากขึ้นในการดำเนินการอย่างหลัง และการเดินทางไปในทิศทางที่ทั้งผู้ใช้และหน่วยงานกำกับดูแลมีความต้องการมากขึ้น การเปลี่ยนแปลงจะเพิ่มโอกาสสำหรับวิวัฒนาการและนวัตกรรม
Google Ad Manager	ต้องการคำแนะนำเพิ่มเติมเกี่ยวกับ Google Ad Manager เกี่ยวกับวิธีที่ผู้เผยแพร่โฆษณาสามารถทดสอบ Privacy Sandbox ได้ การรายงานไม่เพียงพอให้ผู้เผยแพร่โฆษณาเข้าใจผลกระทบที่เกิดขึ้น	คำตอบจาก Google Ad Manager: Google Ad Manager ได้อธิบายวิธีดำเนินการทดสอบโดยใช้ป้ายกำกับการทดสอบที่อำนวยความสะดวกโดย Chrome ในศูนย์ช่วยเหลือ ปัจจุบัน Ad Manager มีการรายงานทั้งเกี่ยวกับ Topics และ Protected Audience ให้แก่ผู้เผยแพร่โฆษณา ณ เวลาของรายงานความคิดเห็นนี้ Ad Manager สามารถรายงานการแสดงผลที่แสดงผ่าน Protected Audience API และระบุได้ว่าข้อมูลจาก Topics API นั้นแสดงอยู่ในการแสดงผลหนึ่งๆ หรือไม่ ผู้เผยแพร่โฆษณาที่สนใจการรายงานที่ซับซ้อนมากขึ้น เช่น การแบ่งกลุ่มการรายงานตามป้ายกำกับที่สนับสนุนของ Chrome สามารถอ่านป้ายกำกับจาก Chrome ได้โดยตรง (โดยใช้เอกสารประกอบของ Chrome) และส่งเป็นคีย์-ค่าในคำขอโฆษณาไปยัง Ad Manager และการรายงานคีย์-ค่าเพื่อรายงานป้ายกำกับ
สิ่งจูงใจในการทดสอบ	ผู้ลงโฆษณากังวลเรื่องเวลาที่เพียงพอในการทดสอบ Privacy Sandbox รวมถึงศักยภาพของการเปลี่ยนแปลง Material API ที่อาจเกิดขึ้น	เราทราบดีว่าบางคนต้องการเวลามากกว่านี้ แต่เราได้รับทราบมาหลายครั้งจากอุตสาหกรรมว่าการเลื่อนไทม์ไลน์อาจทำให้การเตรียมพร้อมของระบบนิเวศลดลง ไม่ใช่มากขึ้น แม้ว่าลำดับเวลาในการเลิกใช้งาน 3PC จะขึ้นอยู่กับการแก้ไขข้อกังวลด้านการแข่งขันที่เหลืออยู่จาก CMA แต่เราขอสนับสนุนให้ทุกคนเตรียมพร้อมสำหรับ 3PCD ในปี 2024 Privacy Sandbox API จะยังคงพัฒนาต่อไปเช่นเดียวกับเทคโนโลยีอื่นๆ วิวัฒนาการดังกล่าวเกิดจากความก้าวหน้าทางเทคโนโลยีและอินพุตของระบบนิเวศ เราจะยังคงรับผิดชอบในการเปลี่ยนแปลงต่างๆ ต่อไป และคิดว่าการเปลี่ยนแปลงทางเทคโนโลยีจะไม่ขัดขวางการใช้งานอย่างไม่มีที่สิ้นสุด
CTV	ไม่มีเส้นทางที่รองรับวิดีโอเชิงเส้นหรือวิดีโอ CTV	เราหวังเป็นอย่างยิ่งว่าจะได้สำรวจกรณีการใช้งาน CTV เพิ่มเติม แต่จะไม่คิดว่า API สำหรับอุปกรณ์ CTV จะเข้ามาขัดขวางการทำงานของ 3PCD ใน Chrome
เซิร์ฟเวอร์โฆษณาของผู้ลงโฆษณา	ดูเหมือนว่า Google จะเปลี่ยนการกำหนดเป้าหมายโฆษณาไปยัง DV360 จะมีการสนับสนุนอะไรสำหรับเซิร์ฟเวอร์โฆษณาของผู้ลงโฆษณา	การตอบสนองจาก Chrome: PA API ออกแบบมาเพื่อให้เซิร์ฟเวอร์โฆษณาของผู้ลงโฆษณาแสดงและวัดโฆษณาที่แสดงต่อผู้ใช้ผ่านการใช้การรายงาน iFrames / Fenced Frame และ Beacon นอกจากนี้ เอเจนซียังจะทำงานร่วมกับฝ่ายต่างๆ ทั้งต้นทางและปลายทางเพื่อผสานรวมเข้ากับขั้นตอนการแสดงโฆษณาเช่นเดียวกับในปัจจุบัน
ผู้จัดการข้อมูลของ Google Ads	"เครื่องมือจัดการข้อมูลของ Google Ads" ที่เพิ่งประกาศไปนี้สร้างขึ้นจากการจับคู่ข้อมูลลูกค้าและ Conversion ที่ปรับปรุงแล้ว ซึ่งช่วยให้ผู้ลงโฆษณาแชร์ข้อมูลลูกค้าบุคคลที่หนึ่งกับ Google เพื่อคงฟังก์ชันการทำงานทางการตลาดทั้งหมดที่ดำเนินการโดย 3PC ไว้ได้ ฟีเจอร์ใหม่นี้สอดคล้องกับความมุ่งมั่นของ Google ที่มีต่อ CMA อย่างไร	การตอบสนองจาก Google Ads: ผู้จัดการข้อมูลของ Google Ads ช่วยอำนวยความสะดวกในการอัปโหลดข้อมูลจากบุคคลที่หนึ่งจากระบบพื้นที่เก็บข้อมูลของผู้ลงโฆษณา (ระบบระบบคลาวด์) ที่ผู้ลงโฆษณานำไปใช้ในการจับคู่ข้อมูลลูกค้า (CM) และ Conversion ที่ปรับปรุงแล้ว (EC) ซึ่งทำให้ธุรกิจขนาดเล็กถึงขนาดกลางที่ใช้ทรัพยากรทางเทคนิคน้อยลงเป็นเรื่องง่าย เครื่องมือจัดการข้อมูล Google Ads ไม่ได้ทำให้ CM หรือ EC มีความสามารถใหม่ๆ ในด้านความสามารถในการระบุที่อยู่หรือการวัดผลโฆษณาบน Google O&O หรือผู้เผยแพร่โฆษณาบุคคลที่สาม แพลตฟอร์มโฆษณาของ Google มีสิทธิ์เข้าถึงความสามารถที่มีอยู่ในเทคโนโลยี Privacy Sandbox เหมือนกับบริษัทเทคโนโลยีโฆษณาอื่นๆ
การตั้งค่า Chrome	หน้าการตั้งค่าภายในของ Chrome ควรให้ข้อมูลเพิ่มเติมเกี่ยวกับขนาดของคุกกี้	ฟังก์ชันที่ขอพร้อมให้ใช้งานอยู่แล้วในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Chrome เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ควรให้ความสำคัญกับฟีเจอร์นี้ในหน้าการตั้งค่าด้วยเช่นกัน
ระบบศึกษาตัวเลือก	Chrome นำการเรียนรู้แบบใดบ้างมาใช้เพื่อรักษาประสบการณ์ที่สำคัญของผู้ใช้ในระหว่าง 3PCD	ดูการตอบกลับของเราต่อคำถามนี้ใน GitHub
เวอร์ชันของเบราว์เซอร์	ต้องการแยกความเสถียรจากเบราว์เซอร์ Chrome ที่ไม่เสถียรใช่ไหม	การจับคู่เวอร์ชันหลักของ Chrome กับเวอร์ชันเสถียรอย่างคร่าวๆ จะใช้งานได้
ฝ่ายการปฏิบัติตามข้อกำหนด	Chrome สามารถให้รายงานที่เกี่ยวข้องกับ SOX ได้ไหม	Chrome จะไม่แสดงรายงานเกี่ยวกับ SOX Privacy Sandbox API เป็นหนึ่งใน API ของเว็บที่ Chrome ให้บริการแก่เว็บไซต์ที่ผู้ใช้เข้าชม เช่นเดียวกับ API ของเว็บทั้งหมด ตัวเรียกใช้ API ไม่ได้ทำข้อตกลงกับ Chrome เพื่อใช้ Privacy Sandbox API การเข้าถึงจะขึ้นอยู่กับว่าตัวเรียกใช้ API มีคุณสมบัติตรงตามข้อกำหนดทางเทคนิคใดๆ และผู้ใช้เปิดใช้การตั้งค่าที่เหมาะสมหรือไม่ หากเป็นเช่นนั้น ตัวเรียกใช้ API จะเป็นตัวกำหนดวิธีใช้ API รวมถึงข้อมูลที่จะจัดเก็บ ราคาเสนอที่ควรระบุ การรายงานที่จะขอ เป็นต้น
ฝ่ายการปฏิบัติตามข้อกำหนด	การขยายคำถามที่พบบ่อยเกี่ยวกับการปฏิบัติตามข้อกำหนดของ Privacy Sandbox เพื่อตอบคำถามเพิ่มเติม	เรายินดีรับฟังความคิดเห็นและวางแผนที่จะสร้างคำถามที่พบบ่อยเพิ่มเติม
คำถามเกี่ยวกับ Chrome	การเลิกใช้งาน 3PC ใน Chrome ส่งผลต่อความพร้อมใช้งานของ 3PC ใน Android WebView (เบราว์เซอร์แบบฝัง) หรือไม่	ขณะนี้เรายังไม่รวม WebView ในขั้นตอนนี้ของการเปิดตัวและทดสอบ 3PCD หรือ Privacy Sandbox API นอกเหนือจากการเปิดใช้การวัดผลการระบุแหล่งที่มาข้ามแอปและเว็บ
คำถามเกี่ยวกับ API	ระบบติดตามจำนวนคลิกและการแสดงผลของผลิตภัณฑ์ที่ได้รับการสนับสนุนได้อย่างไร	กรณีการใช้งานนี้ครอบคลุมโดย Attribution Reporting API
ไทม์ไลน์	เหตุใดลำดับเวลาของ 3PCD จึงเปลี่ยนไป	เราได้อธิบายเหตุผลไว้ที่นี่
SSO ของส่วนขยาย Chrome	อนุญาตให้ใช้การลงชื่อเพียงครั้งเดียวระหว่างเว็บไซต์กับส่วนขยาย Chrome หลังจาก 3PCD	เรากำลังพูดถึงปัญหานี้และยินดีรับฟังความคิดเห็นเกี่ยวกับกรณีการใช้งานเพิ่มเติม
การใช้งาน API	Google ยืนยันรายชื่อพาร์ทเนอร์ที่จะใช้ทดสอบ API ได้ไหม	รายละเอียดของผู้ทดสอบที่ระบุตนเองแบบสาธารณะจะอยู่ใน GitHub สำหรับ API ต่อไปนี้ - Topics API - Protected Audience API - Attribution Reporting API - พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน - CHIP
โครงการริเริ่ม Utiq	Chrome มีมุมมองอย่างไรต่อโครงการริเริ่ม Utiq	เราพูดคุยเกี่ยวกับเรื่องนี้ที่นี่
คำถามเกี่ยวกับ Chrome	วิธีตรวจหาผู้ใช้ที่ท่องเว็บโดยไม่มี 3PC	โดยไม่มีการตั้งค่าที่ชัดเจนในการตรวจหาการบล็อก 3PC สำหรับวิธี "การตรวจหาฟีเจอร์" โดยทั่วไป เราขอแนะนำให้สร้างคำขอ iframe / คำขอข้ามเว็บไซต์ และพยายามตั้งค่าคุกกี้ที่คล้ายกับ Use Case ที่จำเป็นซึ่งเป็นวิธีแก้ปัญหาที่ใกล้เคียงที่สุด
คำถามเกี่ยวกับ Chrome	การท่องเว็บในโหมดไม่ระบุตัวตนเหมือนกับการเรียกใช้การทดสอบ Flag หรือไม่ (เปิด Chrome โดยใช้ --test- third-party-cookie-phaseout แฟล็กบรรทัดคำสั่ง) ใช่ไหม	โหมดไม่ระบุตัวตนแตกต่างจากการตั้งค่าสถานะ แฟล็กนี้ไม่เพียงแต่บล็อก 3PC เท่านั้น แต่ยังเปิดใช้ FedCM และการแบ่งพาร์ติชันพื้นที่เก็บข้อมูลของบุคคลที่สามด้วย
คำถามเกี่ยวกับ Chrome	ดูรายละเอียดเพิ่มเติมเกี่ยวกับผลกระทบของ 3PCD ที่คาดหวังสำหรับแต่ละภูมิภาค/ประเทศเมื่อ 1% เกิดขึ้น	ลูกค้าทั่วโลกจะอยู่ใน 1% แบบสุ่ม แต่อาจมีความแตกต่างในแต่ละภูมิภาค เช่น การเผยแพร่อุปกรณ์และเวอร์ชันของ Chrome อาจแตกต่างกัน
เทคโนโลยีทางเลือกในการเพิ่มความเป็นส่วนตัว	เทคโนโลยีทางเลือกในการเพิ่มความเป็นส่วนตัวควรได้รับอนุญาตให้ดำเนินการติดตามผลแบบข้ามโดเมนเพื่อรักษาความเป็นส่วนตัว เพื่อป้องกันการผูกขาดข้อมูลใน Chrome และ Android	นักพัฒนาแอปมีโอกาสมากมายในการสร้างข้อเสนอด้านเทคโนโลยีที่ช่วยเพิ่มความเป็นส่วนตัว นอกเหนือจากองค์ประกอบพื้นฐานที่เรานำเสนอ รวมถึงองค์ประกอบที่ไม่ใช่ Privacy Sandbox
การศึกษากราฟคุกกี้	Chrome มีมุมมองอย่างไรต่อวิธีการ Cookie Graph ตามที่อธิบายไว้ในบทความนี้ในเฟรมเวิร์ก Privacy Sandbox	เรากำลังตรวจสอบเอกสารนี้และยินดีรับฟังความคิดเห็นเพิ่มเติม

การลงทะเบียนและเอกสารรับรอง

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
การลงทะเบียนถูกจำกัด	Google ได้เปิดตัวข้อกำหนดในการใช้งานสำหรับ Privacy Sandbox API โดยเฉพาะ ข้อกำหนดจะป้องกันไม่ให้บริษัทที่มีความเชี่ยวชาญในการช่วยให้ผู้เผยแพร่โฆษณาจดจำผู้เข้าชมในการทดสอบและ/หรือผสานรวมฟีเจอร์ของ Privacy Sandbox ไว้ในโซลูชันการระบุตัวตนของตนได้อย่างมีประสิทธิภาพ ข้อกำหนดและเงื่อนไขจำกัดความสามารถในการดำเนินการภายใน Privacy Sandbox อย่างไม่เป็นธรรม	กระบวนการลงทะเบียนและเอกสารรับรองไม่เกี่ยวข้องกับการยอมรับข้อกำหนดในการให้บริการของ API การลงทะเบียนและเอกสารรับรองเป็นกลไกที่มีไว้เพื่อเพิ่มความโปร่งใสเกี่ยวกับรายชื่อนักพัฒนาซอฟต์แวร์ที่เรียกใช้ Privacy Sandbox API และวิธีที่พวกเขาใช้ข้อมูลที่ตนเข้าถึง กล่าวอย่างเจาะจงคือ เอกสารรับรองคือคำแถลงต่อสาธารณะว่านักพัฒนาแอปที่รับรองไม่ได้ใช้ API เพื่อระบุผู้ใช้ในเว็บไซต์หรือแอป และไม่ได้หลีกเลี่ยงการคุ้มครองความเป็นส่วนตัวของ API เอกสารรับรองไม่จำเป็นต้องแสดงการรับรองเกี่ยวกับการใช้ข้อมูลหรือเทคโนโลยีอื่นๆ ของนักพัฒนาซอฟต์แวร์
การลงทะเบียน Privacy Sandbox	วิธีอัปเดตผู้ติดต่อ / อีเมลสำหรับเอกสารรับรอง	คุณอัปเดตข้อมูลการลงทะเบียนได้โดยใช้แบบฟอร์มการลงทะเบียน อ่านรายละเอียดเพิ่มเติมได้ที่นี่
การลงทะเบียน Privacy Sandbox	โปรดอธิบายสถานการณ์การตัดการเข้าถึงในกรณีที่เอกสารรับรองไม่พร้อมใช้งาน	Privacy Sandbox จะอนุญาตให้ผู้ติดต่อด้านเทคนิคมีเวลา 3 สัปดาห์ในการสร้างไฟล์เอกสารรับรองสำหรับเว็บไซต์ที่ลงทะเบียนอีกครั้ง ก่อนที่จะปฏิเสธการเข้าถึง (API การวัดผลและความเกี่ยวข้อง) ของบริษัทที่ลงทะเบียนไว้
การลงทะเบียน Privacy Sandbox	เราจะทดสอบ API ในสภาพแวดล้อมในเครื่องโดยใช้ปลายทางที่ไม่ได้ใช้งานจริงได้อย่างไร	เราได้ตอบคำถามนี้ที่นี่

แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง

หัวข้อ

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
ความมีประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ	ผู้เผยแพร่โฆษณากังวลเกี่ยวกับผลกระทบของหัวข้อต่างๆ ต่อการขายจากข้อมูล เว็บไซต์ขนาดใหญ่จะได้รับการกำหนดหัวข้อ "ข่าว" ทั่วไป โดยไม่มีข้อมูลใดที่เชื่อมโยงไปยังผู้เผยแพร่เนื้อหานั้น ผู้เผยแพร่โฆษณาที่เชี่ยวชาญให้ข้อมูลของตนเพื่อแลกกับข้อมูลแบบจำกัด	เราทราบว่าเว็บไซต์ที่มีโดเมนความสนใจทั่วไปมากกว่ามีแนวโน้มที่จะให้หัวข้อที่ละเอียดน้อยกว่าเว็บไซต์ที่มีโดเมนความสนใจแบบเฉพาะกลุ่มมากกว่า อย่างไรก็ตาม เว็บไซต์เฉพาะกลุ่มไม่ได้สนับสนุนหัวข้อที่มีคุณค่าในเชิงพาณิชย์เสมอไป นอกจากนี้ การเปลี่ยนแปลงนี้ยังสะท้อนถึงสถานภาพปัจจุบันที่ว่าเว็บไซต์บางแห่งให้คุณค่ามากกว่าเว็บไซต์อื่นๆ ในระบบความเกี่ยวข้องของโฆษณา 3PC Topics (และ Privacy Sandbox โดยรวม) ช่วยให้ผู้เผยแพร่โฆษณาควบคุมวิธีที่บริษัท AdTech ที่เป็นพาร์ทเนอร์ด้วยใช้ข้อมูลของตนได้มากขึ้น นอกจากนี้ ข้อมูลที่มีผ่าน Topics นั้นหยาบกว่าสัญญาณที่มีอยู่มาก
เซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา	เซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาที่ใช้เซิร์ฟเวอร์โฆษณาเฉพาะอาจสังเกต Topics API โดยตรงไม่ได้	เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การรับรอง	ขยายข้อกำหนดเกี่ยวกับเอกสารรับรองเพื่อจัดการกับผลกระทบที่ไม่พึงประสงค์ที่ทราบจากการโอนข้อมูลข้ามบริบท	ขณะนี้เอกสารรับรองไม่ได้ครอบคลุมความเสี่ยงในหมวดหมู่กว้างๆ นี้ แต่ใช้เพื่อจัดการกับการละเมิด API เท่านั้น
ปริมาณการเข้าชมจาก Topics	ปริมาณการแสดงผลที่ได้รับในปัจจุบันไม่เพียงพอสำหรับการทดสอบ	Chrome รับทราบความคิดเห็นเกี่ยวกับปริมาณของ Topics ที่มีอยู่ในระบบนิเวศแบบเป็นโปรแกรม เรากำลังตรวจสอบสาเหตุที่เป็นไปได้ ทั้งจากภายในเบราว์เซอร์และจากผู้ทดสอบที่เกี่ยวข้อง หากจำเป็น Chrome จะประเมินการเปลี่ยนแปลงการออกแบบของ API ที่เป็นไปได้เพื่อเพิ่มอัตราการครอบคลุม และเปิดใช้การทดสอบในขอบเขตที่เพียงพอโดยที่ยังรักษาความเป็นส่วนตัวของผู้ใช้
การใช้งาน API	มีข้อจำกัดอัตรา Topics API ไหม	มีการใช้ขีดจำกัดอัตราของ Topics เพื่อป้องกันการละเมิดและปกป้องประสบการณ์การใช้งานของผู้ใช้บนเว็บ ดูรายละเอียดเพิ่มเติมได้ ที่นี่
การจัดหมวดหมู่ V2	หลักเกณฑ์จาก IAB ว่ารายละเอียดหัวข้อจะรวมอยู่ในโปรโตคอล RTB แบบเปิดหรือไม่	มี สามารถดูหลักเกณฑ์จาก IAB เกี่ยวกับการรวม Topics ภายในโปรโตคอล Open RTB ได้ ที่นี่
ผลกระทบต่อสัญญาณของบุคคลที่หนึ่ง	การจัดหมวดหมู่หัวข้อแบบละเอียด v2 ควบคู่กับกระบวนการแสดงผลค่าสูงสุดของการแบ่งกลุ่มลูกค้าแบบละเอียดนี้ (หัวข้อยอดนิยม) จะบิดเบือนตลาดสำหรับข้อมูลในการโฆษณา	ผลตอบรับของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่ 3: "แม้ว่าการจัดหมวดหมู่ Topics ที่ละเอียดยิ่งขึ้นอาจลดความน่าสนใจของโซลูชันอื่นๆ ในทางอ้อม เช่น โซลูชันที่อิงจากข้อมูลจากบุคคลที่หนึ่งของผู้เผยแพร่โฆษณาหรือที่อาศัยดีลโดยตรง เนื่องจากเราพัฒนา Topics API เป้าหมายหลักของเราคือการรองรับ Use Case การโฆษณาตามความสนใจหลังเกิด 3PCD ได้อย่างมีประสิทธิภาพมากที่สุดแก่ผู้มีส่วนเกี่ยวข้องทุกฝ่าย ความเชื่อของเราคือประโยชน์ที่มากขึ้นสำหรับ Topics จะช่วยปรับปรุงการแข่งขันโดยรวมและส่งผลดีต่อระบบนิเวศโดยรวม"
รายชื่อผู้ทดสอบ	ผู้เผยแพร่โฆษณาของคุณใช้งาน Topics และ PA API อย่างไร	เราแชร์ข้อมูลดังกล่าวไม่ได้ คุณอ้างอิง รายชื่อผู้ทดสอบได้ ซึ่งผู้เผยแพร่โฆษณาอาจเลือกที่จะแชร์สถานะการทดสอบของตนได้
การเลือกหัวข้อ	อนุญาตให้ผู้ใช้เลือกหัวข้อที่สนใจได้ในเชิงรุกไหม	เราได้พิจารณาที่จะอนุญาตให้ผู้ใช้เพิ่มหัวข้อได้ด้วยตัวเอง เราไม่มีแผนที่จะแก้ไขปัญหานี้ในระยะสั้น แต่พร้อมที่จะสำรวจเพิ่มเติมในระยะยาว
การเลือกหัวข้อ	หากเทคโนโลยีโฆษณามีโค้ดในเว็บไซต์สำหรับสังเกตหัวข้อ พวกเขาจะทราบได้ไหมว่ามีหัวข้อใดบ้างที่สังเกตได้	บริษัทเทคโนโลยีโฆษณาจะพิจารณาหัวข้อที่เกี่ยวข้องกับเว็บไซต์ได้ API ไม่ได้แชร์ข้อมูลนี้แบบเรียลไทม์เนื่องจากอาจทำให้เกิดต้นทุนสำหรับเวลาในการตอบสนอง
การจัดหมวดหมู่ V2	เนื่องจาก Topics แสดงหัวข้อได้สูงสุด 3 หัวข้อ ลักษณะการทำงานที่คาดหวังเมื่อการจัดหมวดหมู่เวอร์ชัน 2 เปิดตัวเป็นอย่างไร	API จะยังคงแสดงหัวข้อสูงสุด 3 รายการ และจะแสดงเวอร์ชันการจัดหมวดหมู่ที่เกี่ยวข้องสําหรับแต่ละหัวข้อในการตอบกลับ
(รายงานในไตรมาสก่อนหน้าด้วย) การสังเกตการณ์หัวข้อ	อนุญาตให้ผู้เผยแพร่เนื้อหาให้สิทธิ์ Chrome จัดหมวดหมู่หัวข้อตามเนื้อหาในหน้า (เช่น ศีรษะหรือร่างกาย)	ผลตอบรับของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่ 3: "ก่อนหน้านี้เราได้พิจารณาที่จะเสนอฟังก์ชันเพื่อจัดประเภทเว็บไซต์เป็นหัวข้อต่างๆ ตามเนื้อหาหน้าเว็บ และตัดสินใจที่จะไม่ดำเนินการต่อเนื่องด้วยข้อกังวลเกี่ยวกับความเป็นส่วนตัวและความปลอดภัย ข้อเสนอนี้อาจลดความกังวลลงได้บางส่วนแต่ยังไม่ชัดเจนว่าเกิดขึ้นมากน้อยเพียงใด เนื่องด้วยระยะเวลาการทดสอบ CMA ที่กําลังจะเกิดขึ้น เราคาดว่าการเปลี่ยนแปลงนี้จะเกิดขึ้นก่อน 3PCD เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่"
การเลือกหัวข้อ	โดเมนมีการจัดประเภทด้วยหัวข้ออย่างไรเนื่องจากเป็นโดเมนทั่วไป	เราใช้ชื่อโฮสต์เพื่อจัดประเภทเว็บไซต์เป็น Topics เท่านั้น เว็บไซต์ที่ได้รับการจัดประเภทอย่างกว้างๆ จะไม่ได้รับผลเสียจากการดำเนินการนี้ ทั้งนี้เนื่องจากข้อมูลตามบริบทของเว็บไซต์จะพร้อมให้ประมูลเสมอในเว็บไซต์ของตน ซึ่งจะให้ข้อมูลที่เจาะจงมากขึ้นสำหรับหัวข้อแบบกว้างๆ
การจัดหมวดหมู่ V2	ต้องการให้หัวข้อสอดคล้องกับมาตรฐานอื่นๆ มากขึ้น (เช่น IAB)	เราต้องการทราบข้อมูลเพิ่มเติมถึงเหตุผลที่พวกเขาหวังว่าจะใช้การจัดหมวดหมู่ของ IAB กับ Topics ให้สอดคล้องกันมากขึ้น ลูกค้าต้องทำตามขั้นตอนใดจึงจะใช้งาน Topics API ได้ และการจัดหมวดหมู่ที่แตกต่างกันมากขึ้นจะส่งผลต่อขั้นตอนเหล่านั้นอย่างไร เรากำลังพิจารณาที่จะเผยแพร่การแมประหว่างการจัดหมวดหมู่ Topics และการจัดหมวดหมู่เนื้อหาของ IAB เราขอแนะนำให้คุณทำความเข้าใจว่าการทำเช่นนั้นจะช่วยแก้ไขปัญหาที่ผู้เผยแพร่โฆษณาต้องเผชิญได้หรือไม่
พื้นที่เก็บข้อมูลและการใช้งาน	คุณมีข้อมูลเพิ่มเติมเกี่ยวกับวิธีจัดเก็บข้อมูลและที่ที่โอนข้อมูลหรือไม่	ระบบจะสร้างและจัดเก็บข้อมูล Topics ไว้ในอุปกรณ์ของผู้ใช้ เมื่อร้องขอ API จะส่ง Topics สูงสุด 3 Topics ไปให้ผู้โทร ในมุมมองของ Google ผู้โทรจะต้องรับผิดชอบต่อการปฏิบัติตามกฎระเบียบในท้องถิ่นเมื่อจัดการและจัดเก็บข้อมูล Topics นอกจากนี้ ผู้โทรทุกรายต้องยืนยันว่าไม่ได้ใช้ Topics เพื่อระบุตัวตนผู้ใช้อีกครั้งในเว็บไซต์ต่างๆ โปรดดูรายละเอียดเพิ่มเติมในคำถามที่พบบ่อยเกี่ยวกับการปฏิบัติตามข้อกำหนดที่เกี่ยวข้องกับความเป็นส่วนตัว
การจัดหมวดหมู่ V2	ผลกระทบของ Topics Taxonomy Upgrade และสถานะของเบราว์เซอร์ขณะเปลี่ยนจาก v1 เป็น v2	หัวข้อที่อนุมานจากการจัดหมวดหมู่ก่อนหน้าจะยังคงมีอยู่และเทคโนโลยีโฆษณาดึงข้อมูลได้ในท้ายที่สุดจนกว่าจะหมดอายุ (มีอายุ 4 สัปดาห์)
คำอธิบาย API	ประสบการณ์ของผู้ใช้ Topics API ทำให้เข้าใจผิด	เราได้แชร์ความคิดเห็นนี้กับทีม UX
คำถามเกี่ยวกับ API	โดเมน Yahoo ได้รับการจัดประเภทตามหัวข้อเมื่อพิจารณาทั่วไปอย่างไร	เราใช้ชื่อโฮสต์เพื่อจัดประเภทเว็บไซต์เป็น Topics เท่านั้น คุณควรเข้าใจว่าเว็บไซต์ที่ได้รับการจัดประเภทแบบกว้างไม่ได้รับผลเสียจากการกระทำนี้
อัตราความพร้อมใช้งานของ Topics ต่ำ	ผู้ทดสอบได้รับ Topics จาก Google Ad Manager ในปริมาณน้อย	Google Ad Manager ได้เปิดตัวการเพิ่มประสิทธิภาพหลายอย่างเพื่อเพิ่มการครอบคลุม โดยผู้ซื้อควรได้รับความครอบคลุมมากขึ้น มีปัจจัยที่คาดไว้บางประการที่อาจจำกัดความครอบคลุม (เช่น ค่ากำหนดของผู้ใช้ ข้อกำหนดในการสังเกตของผู้โทร และอาจมีเวลาในการตอบสนอง/หมดเวลาอยู่บ้าง)

Protected Audience API (เดิมคือ FLEDGE)

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
การแยกความแตกต่าง	ไม่มีความชัดเจนว่า SSP ช่วยสร้างความแตกต่างในการประมูลใหม่ได้อย่างไร	เราทราบมาว่าแผนกลยุทธ์หลายแผนมี Protected Audience และ/หรือ Privacy Sandbox API อื่นๆ เป็นสำคัญ ภาพที่ใหญ่ขึ้น การลดจำนวนตัวระบุข้ามเว็บไซต์ที่ใช้กันทั่วไปมักมองว่าฝั่งผู้ขายของระบบนิเวศเป็นขั้นตอนในเชิงบวกที่ไม่เพียงให้ความสำคัญกับความเป็นส่วนตัวเท่านั้น แต่ยังรวมถึงเชิงพาณิชย์ด้วย ธุรกิจทั้งขนาดเล็กและขนาดใหญ่ที่ยอมรับการเปลี่ยนแปลงนี้มีแนวโน้มที่จะมองหาโอกาส
การแสดงโฆษณา	Chrome เป็นช่องทางเดียวในการแสดงผลโฆษณาเพื่อขัดขวางนวัตกรรมใหม่ๆ การแสดงผลของ Protected Audience จะลดความสามารถในการทำงานของมาตรฐานปัจจุบันเกี่ยวกับโฆษณาเนทีฟ	การแสดงโฆษณาในเบราว์เซอร์มักใช้เทคโนโลยีเบราว์เซอร์ในการแสดงผล จะไม่เปลี่ยนแปลง ข้อกังวลนี้อาจเจาะจงเฉพาะแผนที่จำเป็นต้องใช้ Fenced Frame ร่วมกับ Protected Audience ในอนาคต ส่วนหนึ่งของเหตุผลของแผนเหล่านั้น "ในอนาคต" เป็นเพราะเราต้องการให้เทคโนโลยี Fenced Frames สนับสนุนนวัตกรรมของระบบนิเวศและการสร้างความแตกต่างเมื่อเป็นเรื่องของการแสดงโฆษณา นักพัฒนาซอฟต์แวร์และบริษัทที่สนใจได้มีโอกาสเข้าไปมีส่วนร่วมในการชี้นำแนวทางของ Fenced Frame ซึ่งรวมถึงวิธีสนับสนุนแนวทางของโฆษณาเนทีฟ
อินพุต	Caln Protected Audience API (PA API) แสดงผลเสร็จสมบูรณ์มากขึ้นหรือน้อยลงเมื่อถึงเวลาที่เทคโนโลยีโฆษณาจำนวนมากเริ่มสำรวจ Privacy Sandbox API	API จะพัฒนาอย่างต่อเนื่องตามสิ่งที่เราเรียนรู้จากการใช้งาน รวมถึงแนวคิดใหม่ๆ ที่มาจากทั้งภายในและภายนอก Chrome ความเกี่ยวข้องและ API การวัดผลที่ใช้ได้โดยทั่วไปในปัจจุบันมีความเสถียร แต่ไม่ได้หมายความว่าการพัฒนาหยุดชะงัก และเรายินดีรับฟังความคิดเห็นเพิ่มเติม
การออกแบบการประมูล	การออกแบบกลุ่มเป้าหมายที่มีการป้องกันทำให้แพลตฟอร์มฝั่งซื้ออยู่ในมือของแพลตฟอร์มฝั่งซื้อ ทำให้ SSP นำเสนอตรรกะการสร้างกลุ่มเป้าหมายและการเลือกโฆษณาสำหรับแคมเปญที่ดำเนินการบนแพลตฟอร์มไม่ได้	กลุ่มเป้าหมายที่มีการป้องกันคือผู้ใดที่สร้างกลุ่มเป้าหมายและเสนอราคาในกลุ่มเป้าหมาย และ SSP จะสร้างกลุ่มความสนใจ (IG) ที่ SSP ใช้ในการเสนอราคาได้ นอกจากนี้ SSP ยังอาจให้ตรรกะการเสนอราคา ซึ่งดูเหมือนว่าจะสอดคล้องกับทิศทางที่ SSP จำนวนมากมุ่งเป้าไปยังเอเจนซีโดยตรง แม้ว่าคุณจะยังสามารถรองรับ Use Case เพิ่มเติมได้เสมอ แต่พื้นฐานของ Protected Audience นั้นมีความยืดหยุ่นมากพอที่จะรองรับการสร้างกลุ่มเป้าหมายและการเปิดใช้งานด้วยวิธีต่างๆ มากมาย นอกจากนี้ ลักษณะความเป็นส่วนตัวของรากฐานเหล่านั้นยังหมายความว่าไม่มีการแชร์ข้อมูลระดับผู้ใช้ดิบระหว่างเว็บไซต์อีกด้วย
การออกแบบการประมูล	การประมูล Protected Audience ทำงานขัดต่อความพยายามในการเพิ่มประสิทธิภาพเส้นทางการจัดหา (SPO) ของระบบนิเวศเพื่อลดจำนวนตัวกลางทั้งหมดระหว่างผู้ลงโฆษณากับผู้เผยแพร่โฆษณา และ/หรือความซ้ำซ้อนของโอกาสในการโฆษณาหนึ่งๆ หรือไม่	ไม่ โฆษณาที่ชนะใน Protected Audience จะส่งผ่านเอนทิตีผู้ขายไม่เกิน 2 รายการ (เช่น SSP และเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา) และผ่านน้อยครั้งเพียงใด หากผู้ซื้อสร้างการผสานรวมกับผู้เผยแพร่โฆษณาโดยตรง การทำซ้ำคำขอเดียวกันผ่านตัวกลางหลายรายจะยังคงเป็นตัวเลือกของผู้เผยแพร่โฆษณา Protected Audience ไม่ควรส่งผลกระทบในทางใดทางหนึ่ง การประมูลสำหรับ Protected Audience เกิดขึ้นนอกระบบแบบเรียลไทม์แบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ในปัจจุบันเพื่อไม่ให้ข้อมูลผู้ใช้แบบข้ามเว็บไซต์รั่วไหล ผู้ใช้บางรายอาจระบุว่าซ้ำกับคำขอโฆษณา การเข้าถึงความเป็นส่วนตัวที่สาธิตในทางเทคนิคได้นั้นต้องมีข้อดีข้อเสียบางอย่าง อย่างไรก็ตาม เป็นไปได้ในระยะยาวที่ระบบนิเวศจะตัดสินใจใช้ Protected Audience โดยไม่มีการประมูลฝั่งเซิร์ฟเวอร์แบบเดิม ตัวเลือกนี้อาจนำไปสู่การเพิ่มประสิทธิภาพเส้นทางการจัดหาให้มากขึ้น
การออกแบบการประมูล	Protected Audience จะเปลี่ยนไปใช้รูปแบบที่ SSP มักไม่ใช่การประมูล "ครั้งสุดท้าย" ที่แสดงในหน้า แต่ถูกบังคับให้ใช้รูปแบบของ API รูปแบบนี้	เราไม่เห็นด้วย จากเราพบว่าการใช้งานของผู้ใช้รายแรกๆ นำไปใช้ทำให้ SSP ที่เข้าร่วมการประมูลคอมโพเนนต์สามารถเอาชนะผลลัพธ์ของการประมูลตามบริบท ซึ่งเกิดขึ้นก่อนการประมูลสำหรับกลุ่มเป้าหมายที่มีการป้องกันจะทำงานได้ เอาต์พุตการประมูลคอมโพเนนต์ SSP ใน Protected Audience จะเป็นลำดับสุดท้ายหลังจากเรียกใช้การประมูลตามบริบทโดยสมบูรณ์
การออกแบบการประมูล	การประมูลตามบริบทอาจเกี่ยวข้องเพื่อแสดงสัญญาณข้อมูลเกี่ยวกับโอกาสในการประมูลเพื่อแจ้งแก่การประมูล Protected Audience เท่านั้น	เราคาดว่าการประมูลตามบริบทจะยังคงมีความเกี่ยวข้องกับเหตุผลหลายประการ เช่น ดีล แคมเปญที่กำหนดเป้าหมายไปยังกลุ่มเป้าหมายที่ไม่ใช่บุคคลที่หนึ่ง และสถานการณ์ตามบริบทที่หลากหลาย การที่ไม่มี IG ไว้หรือราคาเสนอใน Protected Audience ไม่ถึงเกณฑ์ขั้นต่ำหรือเป็นไปตามกฎคุณภาพของโฆษณาก็มีประโยชน์เช่นกัน
การกำหนดรูปแบบการเข้าชม	DSP กำลังทำงานที่ QPS คงที่ การประมูล Protected Audience ที่เหมาะสมจะลดประโยชน์ใช้ของโครงสร้างพื้นฐานเดิม	ตามที่เราเข้าใจ สิ่งที่เปลี่ยนแปลงเกี่ยวกับจำนวนคำค้นหาต่อวินาทีคือ SSP จำนวนมากใช้รหัสข้ามเว็บไซต์เป็นฟีเจอร์ในการพิจารณาว่าจะส่งคำขอให้กับ DSP หรือไม่ กรณีนี้จะเป็นจริงไม่ว่าผู้เผยแพร่โฆษณาต้องการเรียกใช้การประมูล Protected Audience หรือไม่ เราได้สำรวจการกำหนดรูปแบบการเข้าชมด้วย SSP มากมายและพบโซลูชันซึ่งรวมถึงการแคชและการกรองตามบริบท เมื่อเวลาผ่านไป เราคาดหวังให้นักพัฒนาซอฟต์แวร์ใช้ประโยชน์จากการรวมส่วนตัวเพื่อช่วยให้เข้าใจค่ากำหนดการเสนอราคา DSP เพิ่มเติมและกรองข้อมูลให้สอดคล้องกัน ท้ายที่สุดแล้ว โครงสร้างพื้นฐานเดิมบางส่วนที่สร้างขึ้นจากตัวระบุข้ามเว็บไซต์จะไม่มีประโยชน์อีกต่อไป
สัญญาณที่ใช้ได้	ขาดความชัดเจนของสัญญาณทั้งหมดที่มีเมื่อมีการประมูลเกิดขึ้น และการเรียงลำดับโดยมีข้อเสียของการประมูลตามบริบทที่แย่ลงอย่างไร	โดยทั่วไปแล้ว สำหรับผู้เสนอราคา ระบบจะส่งข้อมูลเมื่อมีการสร้าง IG จากการประมูลตามบริบทและจากการค้นหาคีย์-ค่าแบบเรียลไทม์ สำหรับผู้ให้คะแนน ระบบจะสามารถให้ข้อมูลได้เมื่อกำหนดค่าการประมูล ซึ่งรวมถึงข้อมูลตามบริบทเกี่ยวกับหน้าเว็บและการประมูลตามบริบท ตลอดจนจากการค้นหาคีย์-ค่าแบบเรียลไทม์ในRenderUrls
(รายงานในไตรมาสที่ผ่านมา) การแสดงผลวิดีโอ	รองรับการแสดงภาพวิดีโอโดยใช้ Protected Audience และ Fenced Frame	การตอบสนองของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่แล้ว "Protected Audience API รองรับการแสดงผลวิดีโอโดยใช้กลไกที่ใช้ iframe อย่างไรก็ตาม เรายังไม่ได้ออกแบบโซลูชันที่เข้ากันได้กับ Fenced Frames และนี่คือหนึ่งในเหตุผลที่เราตัดสินใจยกเลิกการบังคับใช้ Fenced Frames กลับไปในปี 2026 ซึ่งหมายความว่าหากพาร์ทเนอร์ตัดสินใจบังคับใช้ Fenced Frames ตอนนี้ พาร์ทเนอร์รายนั้นจะไม่รองรับวิดีโอ"
การแสดงผลวิดีโอ	การรองรับ PA API สําหรับวิดีโอใน iframe จํากัดไว้ที่วิดีโอ HTML5 เท่านั้น และไม่รองรับมาตรฐาน VAST ที่ใช้กันอย่างแพร่หลาย	คุณจะติดตั้งใช้งานโฆษณาที่ใช้ VAST ได้โดยใช้กลไกการแสดงผล iframe ที่มีอยู่ใน Protected Audience ในปัจจุบัน Google รับทราบว่าการดำเนินการดังกล่าวต้องอาศัยวิศวกรรมใหม่ในส่วนของผู้ซื้อ ผู้ขาย และแพลตฟอร์มโฆษณาของผู้เผยแพร่โฆษณา และเราจะยังคงเดินหน้าลดความยุ่งยากในการเปลี่ยนจากการทำงานของ VAST ก่อนหน้านี้
(รายงานในไตรมาสที่แล้ว) การประมูลระดับบนสุด	ความสามารถในการใช้เซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาของ Google โดยไม่ต้องให้ Google Ad Manager ควบคุมการประมูล PA API ระดับบนสุด	การตอบสนองของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่แล้ว "คำตอบจาก Google Ad Manager: แผนของ Google Ad Manager สําหรับ Protected Audience API ไม่รวมการรองรับเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาของ Google โดยไม่ควบคุมการประมูล Protected Audience ระดับบนสุดด้วยเหตุผลต่อไปนี้ เซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาต้องคงการควบคุมการประมูล Protected Audience ระดับบนสุดไว้เพื่อให้บริการลูกค้าในตลาดการแสดงโฆษณาของผู้เผยแพร่โฆษณาอย่างเหมาะสม ในฐานะเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา บทบาทของเราคือให้การคาดการณ์แก่ผู้เผยแพร่โฆษณา เพื่อให้สามารถเจรจาต่อรองแคมเปญแบบขายตรงโดยไม่ต้องจองมากกว่าจำนวนที่มี รวมถึงกำหนดอัตราการแสดงโฆษณาและการจองโดยตรงได้อย่างมีประสิทธิภาพ ซึ่งจะต้องทำการประมูลครั้งสุดท้ายเพื่อเปรียบเทียบดีมานด์ทั้งทางตรงและทางอ้อมที่มีสิทธิ์ทั้งหมด การคาดการณ์และการกำหนดอัตราการแสดงโฆษณาเป็นฟังก์ชันหลักที่ผู้เผยแพร่โฆษณาคาดหวังจากเซิร์ฟเวอร์โฆษณา หากไม่มีการคาดการณ์ที่แม่นยำ ผู้เผยแพร่โฆษณาอาจขายพื้นที่โฆษณาของตนเกินจริง ซึ่งทำให้เกิดความเสี่ยงต่อชื่อเสียงทางธุรกิจ ความเร็วในการดำเนินการก็มีความสำคัญเช่นกัน เพราะการไม่สามารถปฏิบัติตามสัญญาการจองกับผู้ลงโฆษณายังเสี่ยงต่อความเสียหายต่อความสัมพันธ์โดยตรงระหว่างผู้เผยแพร่โฆษณากับผู้ลงโฆษณาด้วย ซึ่งอาจส่งผลกระทบต่อธุรกิจของผู้เผยแพร่โฆษณาอย่างมาก โดยสรุปแล้ว เราจะไม่ถือว่ากิจกรรมของเซิร์ฟเวอร์โฆษณาผู้เผยแพร่โฆษณาของผู้เผยแพร่โฆษณาที่ทำการประมูล Protected Audience ระดับบนสุดแตกต่างจากกิจกรรมอื่นๆ ของเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา"
(รายงานในไตรมาสที่ผ่านมา) directFrom SellerSignals	DirectFromSellerSignals ช่วยให้ Google Ad Manager ป้องกันไม่ให้ผู้เผยแพร่โฆษณาเห็นราคาของการประมูลตามบริบท	การตอบสนองของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่แล้ว: "การตอบสนองของ Chrome: ข้อมูลที่ส่งผ่านไปยัง runAdAuction() นั้นไม่ได้มาจากผู้ขาย เว้นแต่ผู้ขายจะเรียกใช้ runAdAuction() จาก iframe ของตนเอง ในการประมูลของผู้ขายหลายราย ผู้ขายทุกรายจะสร้างเฟรมที่เรียกใช้ runAdAuction() ไม่ได้ ซึ่งdirectFromSellerSignals จะแก้ปัญหานี้โดยการโหลดเนื้อหาจากกลุ่มทรัพยากรย่อยที่โหลดจากต้นทางของผู้ขาย ซึ่งช่วยให้มั่นใจว่าจะช่วยให้มั่นใจว่าข้อมูลที่ผ่านเข้าสู่การประมูลจากการกำหนดค่าของผู้ขายกับการประมูลนั้นไม่สามารถปรับเปลี่ยนได้ หากผู้เผยแพร่โฆษณาต้องการใช้ Protected Audience API เพื่อทำความเข้าใจข้อมูลที่ผู้ให้บริการเทคโนโลยีของตนกำลังส่งไปยังการประมูล Protected Audience ผู้เผยแพร่โฆษณาสามารถขอฟังก์ชันการทำงานนี้จากผู้ให้บริการเทคโนโลยีเหล่านั้น คำตอบจาก Google Ad Manager: เรามุ่งเน้นที่หลักความเป็นธรรมในการประมูลมาเป็นเวลาหลายปีแล้ว รวมถึงสัญญาว่าจะไม่มีการแชร์ราคาจากแหล่งที่มาของโฆษณาที่ไม่มีการรับประกันใดๆ ของผู้เผยแพร่โฆษณา รวมถึงราคารายการโฆษณาที่ไม่รับประกันการแสดงผลกับผู้ซื้อรายอื่นก่อนเสนอราคาในการประมูล ซึ่งต่อมาเราจะยืนยันอีกครั้งในสัญญาผูกมัดกับหน่วยงานการแข่งขันของฝรั่งเศส สำหรับการประมูล Protected Audienceการประมูล เราตั้งใจที่จะรักษาสัญญาของเราไว้ด้วยการใช้ประโยชน์จาก DirectFromSellerSignals และจะไม่แชร์ราคาเสนอของผู้เข้าร่วมการประมูลกับผู้เข้าร่วมการประมูลรายอื่นก่อนที่การประมูลในการประมูลผู้ขายหลายรายจะเสร็จสิ้น กล่าวให้ชัดเจนคือเราจะไม่แชร์ราคาของการประมูลตามบริบทกับการประมูลส่วนประกอบของเราเองตามที่อธิบายไว้ในการอัปเดตนี้"
(รายงานในไตรมาสก่อนหน้า) ค่า K-anonymity	ค่า "K" ถึง "k-anon" จะนำไปใช้อย่างไรและจะเผยแพร่เมื่อใด	เราเผยแพร่ค่า K-anonymity ในเดือนธันวาคม 2023 หลังจากกระบวนการ 3PCD เริ่มต้นขึ้น เราจะเพิ่มเกณฑ์ k-anonymity เป็นค่าสุดท้ายที่ 50 (k=50) และกำหนดระยะเวลาการอัปเดตเป็น 1 ชั่วโมง (p=1) ค่า K-anonymity ที่ 50 ได้รับการประเมินว่าให้ความสมดุลสูงสุดระหว่างยูทิลิตีและความเป็นส่วนตัว ค่านี้เพียงพอที่จะป้องกันการโจมตีบ็อตพื้นฐานและคง Differential Privacy ไว้ รวมถึงให้ค่าอยู่ในระดับต่ำพอที่จะทำให้ API ยังคงมีประโยชน์สำหรับ Use Case ที่ต้องการต่อไป
(รายงานในไตรมาสก่อนหน้า) forDebuggingOnly	โอกาสที่จะมีการใช้ forDebuggingOnly.reportAdAuctionWin ในทางที่ผิดหากยังคงไว้หลังเวอร์ชัน 3PCD	เราได้แชร์ข้อเสนอเกี่ยวกับวิธีการสนับสนุนกรณีการใช้งานการแก้ไขข้อบกพร่องอย่างต่อเนื่องในระยะยาวที่นี่ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับข้อเสนอ
(รายงานในไตรมาสก่อนหน้า) นโยบายต้นทางเดียวกัน	คำขอผ่อนปรนนโยบายต้นทางเดียวกันเพื่ออนุญาตโดเมนย่อย	คำขอนี้อยู่ระหว่างการพิจารณาและเราได้พูดคุยเกี่ยวกับเรื่องนี้ที่นี่
(รายงานในไตรมาสที่แล้ว) ขนาดคอมโพเนนต์โฆษณา	เพิ่มจำนวนองค์ประกอบโฆษณาจาก 20 เป็น 40	เราได้พูดคุยถึงคำขอนี้ระหว่าง การโทรติดต่อ WICG ในวันที่ 4 ต.ค. และในประเด็นของ GitHub นี้ และวางแผนที่จะจัดการกับคำขอดังกล่าวภายในสิ้นไตรมาส 1 ปี 2024
(รายงานในไตรมาสที่แล้ว) วันหมดอายุของคีย์เซิร์ฟเวอร์ค่าคีย์	การหารือเกี่ยวกับการนำคีย์เซิร์ฟเวอร์ออกเมื่อ IG ที่เกี่ยวข้องหมดอายุแล้ว	การจัดการ TTL จะดีกว่าเมื่ออยู่นอก TEE เพื่อลดความซับซ้อน อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ทริกเกอร์กลุ่มความสนใจ	IG เดียวทริกเกอร์ generateBids หลายรายการภายในการประมูล (คอมโพเนนต์) เดียวได้ไหม	ทุกครั้งที่เบราว์เซอร์เรียกฟังก์ชัน generateBid() ของ IG จะได้รับอนุญาตให้แสดงผลมูลค่าราคาเสนอ เช่น ในการประมูลผู้ขายหลายรายจะมีการเรียก IG หลายครั้ง แต่ละครั้งในการประมูลคอมโพเนนต์รายการใดรายการหนึ่ง เจ้าของ IG ไม่จำเป็นต้องดำเนินการใดๆ เพื่อเปิดใช้งาน/รองรับลักษณะการทำงานนี้
คำถามเกี่ยวกับการปฏิบัติตามข้อกำหนด	ขอบเขตของความยินยอมที่เก็บรวบรวมผ่านเบราว์เซอร์ Chrome ของผู้ใช้เป็นอย่างไร	โปรดดูรายละเอียดที่ "Privacy Sandbox ส่งเสริมการปฏิบัติตามข้อกำหนดที่เกี่ยวข้องกับความเป็นส่วนตัวใน Chrome อย่างไร" ในคำถามที่พบบ่อยเกี่ยวกับการปฏิบัติตามข้อกำหนดเกี่ยวกับความเป็นส่วนตัว
การประมูลหลายแท็ก	วิธีรองรับการประมูลหลายแท็ก	เรากำลังประเมินคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ความพร้อมใช้งานของการป้องกัน IP	หากการป้องกัน IP ไม่พร้อมใช้งานภายในวันที่ประกาศ ผลกระทบต่อไทม์ไลน์ของฟีเจอร์ Protected Audience เช่น การบังคับใช้เฟรมรั้วและการนำการรายงานระดับเหตุการณ์ออกหรือนําการรายงานระดับเหตุการณ์ออก	ดังที่ได้กล่าวไว้ที่นี่ เราเชื่อว่าไทม์ไลน์ของ Protected Audience ควรเชื่อมโยงกับลำดับเวลาการเปิดตัวของฟีเจอร์การคุ้มครองความเป็นส่วนตัวอื่นๆ
modelingSignals	ขอฟิลด์ใหม่นอกเหนือจากการสร้างแบบจำลองสัญญาณที่สามารถเข้ารหัสได้เฉพาะข้อมูลการแสดงผลและการคลิกเท่านั้น	เราเข้าใจถึงประโยชน์ที่จะได้รับจากการเปลี่ยนแปลงนี้ และขณะนี้เรากำลังประเมินคำขอดังกล่าวและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
IG เชิงลบ	เป็นไปได้ไหมที่จะอนุญาตให้ IG ปกติระบุชื่อ IG เชิงลบ	ปัจจุบันฟีเจอร์นี้ยังไม่สามารถทำได้ตามคำอธิบาย แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศว่าเหตุใดจึงต้องมีข้อกำหนดนี้
การใช้งาน API	สร้างรายงานรวมที่ผ่านระดับ generateBid()	คุณจะเรียกใช้การรวมส่วนตัวใน generateBid ได้
มาโคร	กำหนดเส้นทางสัญญาณจาก perBuyerSignals ผ่านมาโครใน IFrames ไปยัง 3P	เราจะพูดคุยเกี่ยวกับกรณีการใช้งานนี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้งาน API	หากข้อผิดพลาดในการดึงข้อมูลสัญญาณการให้คะแนนที่เชื่อถือได้ ระบบจะยังคงเรียกใช้ scoreAd() หรือไม่	ScoreAd() ควรยังคงทำงานอยู่หากการเรียกการดึงข้อมูลไม่สำเร็จ
การใช้งาน API	การเขียนmetadata.shard_num ในไฟล์ riegeli สำหรับไฟล์เดลต้า/สแนปชอต	เรากำลังเพิ่มการรองรับ shard_num เพื่อเลิกบล็อก Riegeli ไม่ได้ถูกนำไปใช้งานได้ดีเท่ากับ Avro แต่นั่นก็ยังไม่ถูกทิ้งร้าง และเนื่องจาก TEE มีข้อจำกัดและค่าใช้จ่ายมากกว่า เราจึงตัดสินใจอย่างเต็มที่เพื่อให้ความสำคัญกับประสิทธิภาพมากกว่าประสบการณ์ของผู้ใช้ เรากำลังพิจารณาให้บริการ gRPC เพื่อสร้างไฟล์จากคำขอ นอกจากนี้ เราอาจประเมินรูปแบบอื่นๆ เช่น Avro เกี่ยวกับผลกระทบด้านประสิทธิภาพ
การทดสอบ API	PA API และ Measurement API จะรองรับการทดสอบส่วนเพิ่มได้อย่างไร	Privacy Sandbox ไม่มีวิธีวัดส่วนเพิ่มด้วยการโต้แย้งที่เกิดขึ้นจริงก่อนการประมูล คุณสามารถใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันและการรวมส่วนตัวได้ แต่สิ่งที่ตรงข้ามกับความจริงจะเกิดขึ้นหลังการประมูลเท่านั้น
การใช้งาน API	การใช้ BiddingWasmHelperURL สำหรับการอัปเดตรายวันส่งผลต่อเกณฑ์ k-anonymity หรือไม่	เนื่องจาก ไม่พิจารณา k-anonymity สำหรับการอัปเดต IG อีกต่อไป คุณจึงอัปเดต BiddingWasmHelperURL ได้โดยไม่ส่งผลกระทบต่อเกณฑ์
การใช้งาน API	เราสามารถรับการแจ้งเตือนข้อผิดพลาดเกี่ยวกับ PA API ได้ไหม	เรายินดีรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับการแจ้งเตือนข้อผิดพลาดประเภทใดที่บริษัทเหล่านี้ต้องการแก้ปัญหาเกี่ยวกับ PA API
ขนาดโฆษณา	ขนาดโฆษณาจะไม่แสดงในการประมูลและการรายงานที่เป็นไปได้	เรากำลังแก้ไขปัญหาของคำขอพุลนี้
การใช้งาน API	หากไม่ได้เข้าร่วมการประมูลนี้ จะมีการเรียกใช้ปลายทาง IG ที่อัปเดตสำหรับ IG ไหม	ใช่ มีการเรียก UpdateURL สำหรับ IG ทั้งหมดของเจ้าของรายหนึ่งๆ แม้ว่าเจ้าของดังกล่าวจะไม่ได้เสนอราคาในการประมูลดังกล่าวก็ตาม ข้อกำหนดเพียงอย่างเดียวคือ - เจ้าของจะต้องรวมอยู่ในการประมูลหนึ่งๆ (กล่าวคือ รวมอยู่ในการประมูลผ่านการกำหนดค่า) -InterestGroup ของเจ้าของธุรกิจรายนั้นๆ ต้องยังไม่ได้รับการอัปเดตภายใน 24 ชั่วโมงที่ผ่านมา
Prebid ใน PA API	ต้องใช้ Prebid.js เวอร์ชันใดในระยะทดสอบ	เอกสารทางเทคนิคของเราระบุว่าเวอร์ชันควรเป็น >= 8.9.0
การเปิดใช้งานข้อมูลจากบุคคลที่หนึ่งใน PA API	นักการตลาดจะเปิดใช้งานข้อมูลจากบุคคลที่หนึ่งของตนเองสำหรับคำจำกัดความและการใช้งานของ IG ได้อย่างไร	คุณจะใช้ "การมอบสิทธิ์" และ "กลุ่มความสนใจเชิงลบ" สำหรับงานนี้ได้
PA API และการติดแท็กฝั่งเซิร์ฟเวอร์	PA API ทํางานร่วมกับการติดแท็กฝั่งเซิร์ฟเวอร์อย่างไร	แท็กพื้นฐานในเบราว์เซอร์ของผู้ใช้จะต้องเปลี่ยนเส้นทางการเรียก API ไปยังแท็กที่เหลือในฝั่งเซิร์ฟเวอร์ ซึ่งจะช่วยให้ผู้ใช้ลงทะเบียนการเรียกได้ด้วย
การทดสอบ Chrome (โหมด a/b)	SSP คาดหวังว่า SSP จะส่งป้ายกำกับเหล่านี้ในคำขอราคาเสนอ RTB ด้วยเช่นกัน และหากเป็นเช่นนั้น	ใช่ เราคาดว่าจะส่งป้ายกำกับจาก SSP ไปยัง DSP ขอแนะนำให้เอนทิตีเข้าถึงป้ายกำกับและแชร์ค่าที่ไม่ได้แก้ไขกับพาร์ทเนอร์ผ่านส่วนขยายอุปกรณ์นี้
พื้นที่เก็บข้อมูลและการใช้งาน	คุณมีข้อมูลเพิ่มเติมเกี่ยวกับวิธีจัดเก็บข้อมูลและที่ที่โอนข้อมูลหรือไม่	เราจะไม่ให้คำแนะนำทางกฎหมาย แต่เป็นการแจ้งเพิ่มเติมเพื่อหาแนวทาง/การคิดทั่วไปเกี่ยวกับการจัดเก็บข้อมูล การเก็บรักษา และปัญหาด้านความเป็นส่วนตัวอื่นๆ โปรดดูคำถามที่พบบ่อยเกี่ยวกับการปฏิบัติตามข้อกำหนดที่เกี่ยวข้องกับความเป็นส่วนตัวที่นี่ซึ่งอาจเป็นประโยชน์สำหรับคุณ
ความปลอดภัยของ API	ข้อกังวลเกี่ยวกับโค้ดฝั่งไคลเอ็นต์ที่เป็นอันตรายซึ่งบิดเบือนมูลค่าที่แสดงผลของฟังก์ชัน generateBid()	เราได้พูดคุยเกี่ยวกับปัญหาที่นี่ และได้รวบรวมความคิดเห็นบางส่วนไว้ในข้อเสนอการรวบรวมข้อมูลส่วนตัวแล้ว
ปลายทางที่กำหนดเอง	เมื่อใช้การเรียก reportEvent ปลายทางที่กำหนดเอง คุณทราบหรือไม่ว่าต้นทางการรายงานที่กำหนดเอง (ไม่ใช่กับผู้ซื้อหรือผู้ขาย) ที่ลงทะเบียนล่วงหน้าเป็นส่วนหนึ่งของ IG ใน allowedReportingOrigins จำเป็นต้องประกาศโดย DSP ใน reportWin โดยใช้ registrationAdBeacon หรือไม่	ไม่ คุณไม่จำเป็นต้องลงทะเบียนอีกครั้งใน reportWin และสามารถใช้ใน reportEvent โดยตรงตามที่อธิบายไว้ที่นี่
ข้อจำกัด API	ขนาด IG ระหว่างการสร้างและอัปเดต	ขนาดการอัปเดตได้รับการอัปเดตเป็น 1 MB เท่ากับขีดจำกัดใหม่ 1 MB (จาก 50 KB) สําหรับการสร้าง IG
ข้อจำกัดของ K-Anon	K-anon สำหรับโฆษณาที่มีขนาดแตกต่างกัน	เราเผยแพร่ค่า K-anonymity ในเดือนธันวาคม 2023 โดยระบุว่า K-anonymity จะเริ่มตรวจสอบขนาดโฆษณา "บางครั้งหลังปี 2025" ซึ่งวิธีการยกเว้นขนาดนั้นไม่ใช่วิธียกเว้นขนาด เนื่องจากอาจเป็นเวกเตอร์การติดตามข้ามเว็บไซต์ ตามที่อธิบายไว้ในการเรียกใช้ WICG เมื่อวันที่ 11 ต.ค.
ความปลอดภัยของ API	ผู้เล่นที่เป็นอันตรายสามารถปลอมแปลง "ชื่อโฮสต์" ของหน้าได้ไหม	API รองรับคีย์ย่อยที่ตั้งค่าเป็นชื่อโฮสต์ของผู้เผยแพร่โฆษณา เนื่องจากเบราว์เซอร์กำลังตั้งค่าคีย์ จึงดูเหมือนว่าจะหลีกเลี่ยงกลไกนี้ได้ยาก
การใช้งาน API	ไม่ควรแนะนำให้ใช้ฟังก์ชัน ForDebuggingOnly สำหรับการใช้งานจริง	เรากำลังจะยืนยันกับระบบนิเวศว่าฟังก์ชัน forDebuggingOnly นั้นไม่เหมาะสมกับการทำงานอื่นๆ เลย นอกเหนือจากการแก้ปัญหาหลังการ 3PCD
ต้องการเครื่องมือแก้ไขข้อบกพร่องเพิ่มเติม	ForDebuggingOnly ไม่เพียงพอต่อการทำความเข้าใจปัญหาที่อาจเกิดขึ้นก่อน scoreAd()	เรากำลังรวบรวมความคิดเห็นเพิ่มเติมเกี่ยวกับช่องว่างนี้และยินดีรับฟังข้อมูลเพิ่มเติมที่นี่
กลุ่มความสนใจที่เลือกไม่ใช้อย่างถาวร	คำขออนุญาตให้ผู้ใช้เลือกไม่ใช้การสร้าง IG พิเศษอย่างถาวร	กลยุทธ์ของเราคือไม่อนุญาตให้ผู้ใช้เลือกไม่ให้เข้าร่วมในระดับ IG เนื่องจากผู้ใช้ไม่เข้าใจความหมายที่แท้จริง
ปรับปรุงเอกสารประกอบ	ใช้อักษรตัวพิมพ์ใหญ่เดียวกันสำหรับพารามิเตอร์RenderUrls ในข้อกำหนดและคำอธิบาย	เรายินดีรับฟังความคิดเห็นและติดตามผลในการอัปเดตเอกสาร
การสนับสนุนดีลกลุ่มเป้าหมายที่มีการป้องกัน	ขอตัวเลือกเพิ่มเติมสําหรับการสนับสนุนดีลของกลุ่มเป้าหมายที่มีการป้องกัน	ขณะนี้ทีม Chrome กำลังประเมินสิ่งที่เราทำได้เพื่อสนับสนุน 3PCD
มาโคร	จำเป็นต้องรองรับมาโครเพื่อทำให้ขนาดของ IG ต่ำกว่าขนาด IG สูงสุด	การอัปเดตล่าสุดสำหรับผู้อธิบายแก้ไขคำขอนี้บางส่วน
ReportLoss API ระดับเหตุการณ์	คำขอ ReportLoss API ระดับเหตุการณ์	แม้ว่ารายงานการสูญเสียระดับเหตุการณ์จะทำให้เกิดความเสี่ยงด้านความเป็นส่วนตัวขั้นรุนแรง แต่เราเชื่อว่าเป้าหมายที่แท้จริงของคำขอนี้สามารถบรรลุได้ด้วยการแก้ไข Private Aggregation API ที่เหมาะสม เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การใช้งาน API	เมธอด forDebuggingOnly จะทํางานอย่างไรเมื่อไม่มีคะแนนราคาเสนอ > 0	หากคะแนน <= 0 แสดงว่าเป็นการสูญเสียโดยอัตโนมัติ ดังนั้น ระบบจะเรียกใช้ reportAdAuctionloss
การกำหนดมาตรฐาน	ไม่มีการปรับความสอดคล้องระหว่างผู้ใช้ของค่าอินพุต/เอาต์พุตของฟังก์ชัน generateBid() ของ PA API	เราขอแนะนำให้พาร์ทเนอร์ทุกรายแจ้งปัญหานี้ (หรือที่คล้ายกัน) ไปยัง IAB Tech Lab กลุ่มนี้ทำงานตามมาตรฐานอุตสาหกรรมสำหรับ API เช่น Protected Audience โดยเฉพาะ
ความปลอดภัยของ API	Google เห็นข้อมูลอะไรจาก IG ของเราบ้าง	K-anonymity พึ่งพาการคุ้มครองความเป็นส่วนตัวที่รัดกุมเพื่อไม่ให้ข้อมูลที่ละเอียดอ่อนของผู้ใช้รั่วไหลไปสู่ฝ่ายใดฝ่ายหนึ่ง ซึ่งรวมถึง Google ด้วย นอกจากนี้ Google ยังกำลังพัฒนาการใช้งานเลเยอร์นี้ของบุคคลที่สาม (อย่างรวดเร็ว) เพื่อลดความเสี่ยงนี้ด้วย
การทดสอบ Chrome (โหมด a/b)	ผู้ใช้ที่ถูกจำกัด "k-anon" จะสามารถแยกออกจากการทดสอบได้หรือไม่	เราจะแสดงสถานะ k-anonymity ในการรายงานตามที่อธิบายไว้ที่นี่
ความปลอดภัยของแบรนด์	สนับสนุนกรณีการใช้งานด้านความปลอดภัยของแบรนด์ในกรณีที่โฆษณาไม่แสดง โดยขึ้นอยู่กับรายการเว็บไซต์หรือคีย์เวิร์ดที่ถูกบล็อก	กรณีการใช้งานด้านความปลอดภัยของแบรนด์ดังกล่าวควรเป็นไปได้ด้วย PA API สำหรับแคมเปญโฆษณาที่กำหนดเป้าหมายชุดโดเมนบางส่วนในเชิงลบ แคมเปญอาจจัดเก็บรายการที่บล็อกของโดเมนไว้ใน IG เอง หรืออาจใช้ตัวกรอง Bloom ก็ได้หากการระบุโดเมนแต่ละรายการใช้พื้นที่มากเกินไป หรืออาจส่งคืนการตัดสินใจอนุญาตหรือปฏิเสธจากเซิร์ฟเวอร์ค่าคีย์ของตน โดยใช้ UDF ที่จะค้นหาคำตอบตามชุดค่าผสมของคีย์ที่ระบุแคมเปญโฆษณาและชื่อโดเมนที่รวมอยู่ในคำขอค่าคีย์ นอกจากนี้ Protected Audience API ยังอนุญาตให้ทั้ง SSP และ DSP ผ่านข้อมูลใดๆ เกี่ยวกับบริบทหน้าเว็บไปยังการประมูล ซึ่งอาจรวมถึงรายการหัวข้อที่ละเอียดอ่อนหรือคีย์เวิร์ดในหน้าเว็บ เป็นต้น ตรรกะการเสนอราคาของ DSP สามารถเปรียบเทียบข้อมูลนี้กับข้อมูลที่จัดเก็บไว้เกี่ยวกับที่ที่โฆษณาไม่ควรปรากฏ และเลือกที่จะไม่เสนอราคาตามความเหมาะสม เรายินดีรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับ Use Case ที่เฉพาะเจาะจงซึ่งเชื่อว่าเป็นไปไม่ได้
การมอบสิทธิ์	การมอบสิทธิ์สิทธิ์ทำงานอย่างไร	เราได้แชร์เอกสารประกอบเกี่ยวกับการมอบสิทธิ์ที่นี่
คำขอแบบกลุ่ม	ใช้คำขอ POST สำหรับ URL ของ PA API บางรายการเพื่อรองรับคำขอแบบกลุ่ม	เรายินดีดำเนินการตามข้อเสนอและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ปรับปรุง API	ช่องที่ไม่ควรใช้ (เช่น X-fledge-bidding-signals-format-version)	เรากำลังพูดคุยเกี่ยวกับปัญหาและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ปรับปรุง API	คําขอให้ส่งความยินยอมตาม GDPR ไปยังผู้ให้บริการวัดผลและการแสดงโฆษณาบุคคลที่สาม	เรารองรับฟังก์ชันนี้โดยใช้ API การแทนที่มาโครที่เลิกใช้งานแล้วแทนมาโคร ตามที่อธิบายไว้ที่นี่
การเพิ่มประสิทธิภาพโฆษณาแบบไดนามิก	Protected Audience รองรับการเพิ่มประสิทธิภาพโฆษณาแบบไดนามิกอย่างไร	เราจะพูดคุยถึงกรณีการใช้งานนี้และแชร์โซลูชันที่เป็นไปได้ที่นี่
ปรับปรุง API	คำขอสำหรับ URL การแสดงโฆษณาของบุคคลที่สามที่สามารถขอบริบท IG เป็นหลัก ชื่อ IG ที่สอดคล้องกับ IG ที่ชนะการประมูล	คำขอดังกล่าวอาจเพิ่มความเสี่ยงในการติดตามผู้ใช้ เรามีการพูดคุยเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ความปลอดภัยของ API	กังวลว่าขนาดของ "IG blob" จะทำให้ข้อมูลเกี่ยวกับ IG ที่เลือกรั่วไหล	ดังที่กล่าวไว้ในส่วนข้อควรพิจารณาเกี่ยวกับความเป็นส่วนตัวในตัวอธิบาย Chrome B&A API ขนาดของ BLOB ไม่ได้ขึ้นอยู่กับอินพุตใดๆ ที่จะ navigator.getInterestGroupAdAuctionData() ได้ แต่จะจัดแพ็กเกจ IG ทั้งหมดในอุปกรณ์เท่านั้น วิธีนี้ช่วยให้มั่นใจว่าขนาดของ blob จะค่อนข้างสม่ำเสมอในหน้าเว็บและจำกัดความสามารถในการทำให้ข้อมูลข้ามเว็บไซต์รั่วไหล เราออกแบบแพลตฟอร์มนี้มาด้วยเหตุผลนี้
การทดสอบ Chrome (โหมด a/b)	SSP อื่นๆ มีจุดยืนอย่างไรในการพลาดการโหลดครั้งแรกเกี่ยวกับการตั้งค่าคุกกี้และการทดสอบที่อำนวยความสะดวกโดย Chrome	เราไม่รับทราบข้อกังวลที่สำคัญใดๆ (แม้ว่าคนอื่นๆ จะรับทราบสถานการณ์นี้) แต่เรายินดีรับฟังความคิดเห็นเกี่ยวกับระบบนิเวศหากเรื่องนี้เป็นปัญหาสำคัญ
การรองรับการทดสอบ A/B	ขอรับการสนับสนุนสําหรับการทดสอบ A/B ของ PA API	เราได้พูดคุยเกี่ยวกับคำขอนี้ในการประชุม WICG เดือนพฤศจิกายน และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ขนาดโฆษณา	ใครเลือกขนาดการประมูลของ Protected Audience	ดูคําถามนี้ได้ใน คําถามที่พบบ่อยนี้
ปรับปรุง API	ขอกำหนดค่าบริการคีย์-ค่าให้ยอมรับเส้นทาง /bidding-signals/v1/getvalues	เราได้เพิ่มคำนำหน้าเส้นทางการสนับสนุนในคำขอพุลนี้
การใช้งาน API	ผู้เผยแพร่โฆษณาจะสร้าง IG ด้วยโค้ดของตนได้อย่างไรหากควรอยู่ในฐานของผู้ลงโฆษณา เพื่อให้ผู้ลงโฆษณาสามารถเสนอราคาได้	คำตอบต้องมาจากพาร์ทเนอร์เทคโนโลยีโฆษณาบางราย ซึ่งก็คือ DSP หรือ SSP ที่ต้องการเข้าร่วมการประมูลสำหรับ Protected Audience และสร้างวิธีที่กลุ่มเป้าหมายเหล่านั้นมาจากแหล่งที่มาภายนอก เราได้พูดคุยเรื่องนี้เพิ่มเติมในปัญหาเกี่ยวกับ GitHub นี้แล้ว
ปรับปรุง API	ขอลิงก์ IG เชิงลบกับโฆษณาใน "กลุ่มความสนใจเชิงบวก" ได้	เรากำลังพิจารณาคำขอนี้และแชร์ข้อเสนอที่เป็นไปได้เกี่ยวกับวิธีสนับสนุนที่นี่
จำนวนชาร์ด	คำขอรับการสนับสนุนเกี่ยวกับการส่ง "การสนับสนุน shard_num" ในข้อมูลเมตา	เราได้เพิ่มการรองรับ shard_num ตามความคิดเห็นนี้
การใช้งาน API	ขอการประมาณค่าโอเวอร์เฮดของคีย์ในเซิร์ฟเวอร์ K/V	เราได้แชร์ความคิดเห็นและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
K-anonymity	ขอคำชี้แจงและเพิ่มประสิทธิภาพรายละเอียดในตัวนับการไม่ระบุตัวตน	เราได้ชี้แจงเกี่ยวกับรายละเอียดของการยื่นเรื่องโต้แย้งการไม่ระบุตัวตนที่นี่
การแก้ไขข้อบกพร่อง	คำขอปรับปรุงความสามารถในการแก้ไขข้อบกพร่องของ PA API หลังจากการเปลี่ยนแปลงที่เสนอล่าสุดสำหรับ forDebuggingOnly	เราอยากพูดคุยเกี่ยวกับคำขอดังกล่าว และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ขนาดโฆษณา	คำขอขนาดช่องโฆษณาเป็นสัญญาณ BTS เพิ่มเติม	เราได้แชร์ข้อเสนอเพื่อสนับสนุนคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ความปลอดภัยของ API	เป็นไปได้ไหมที่จะจำกัดการใช้งาน "runAdAuction()" ตามต้นทาง	เราได้แชร์คำตอบโดยละเอียดไว้ที่นี่
อายุการใช้งานของ IG	คำขอต่ออายุ IG จาก 30 เป็น 90 วัน	เรากำลังพิจารณาคำขอดังกล่าวและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การใช้งาน API	เป็นไปได้ไหมที่จะเรียกใช้การประมูล Protected Audience ควบคู่ไปกับการเสนอราคาส่วนหัวและการเรียกเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา	เรากำลังพูดคุยเกี่ยวกับคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การแก้ไขข้อบกพร่อง	ขอการสนับสนุนที่ดียิ่งขึ้นสำหรับส่วนขยายการแก้ไขข้อบกพร่องของ Chrome PA API ที่พูดคุยกับเครื่องมือสำหรับนักพัฒนาเว็บ	เรายินดีมอบเครื่องมือแก้ไขข้อบกพร่องเพิ่มเติมและยินดีรับฟังคำแนะนำเพิ่มเติมที่นี่
การใช้งาน API	การแจ้งเตือนการสูญหายจะไม่ได้รับการทริกเกอร์หากไม่มีราคาเสนอจากผู้ขายส่วนประกอบที่จะส่งไปยังผู้ขายยอดนิยม	เราได้อธิบายสาเหตุของการดำเนินการดังกล่าวไว้ที่นี่
ปรับปรุง API	คำขอรองรับ TextEncrypter ใน Worklet การเสนอราคาสำหรับ Protected Audience	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การใช้งาน API	การเรียกใช้เครือข่ายและการเรียกใช้ตรรกะในตัวไคลเอ็นต์สามารถบล็อกเทรดหลัก และทําให้เกิดความท้าทายในการดำเนินการ JS ที่ส่งผลต่อ SEO ได้	เรามีการพูดคุยเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การใช้งาน API	เป็นไปได้ไหมที่ DSP จะใช้ Funnel การเสนอราคาฝั่งเซิร์ฟเวอร์ปัจจุบันของตนเพื่อประเมินและส่งตัวเลือกโฆษณาซึ่งเป็นส่วนหนึ่งของ PerBuyerSignal เพื่อใช้สำหรับการประมูลในอุปกรณ์	เรากำลังสนทนาเกี่ยวกับคำถามนี้ และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ขยายข้อมูลโอกาสการเสนอราคา	คำขอขยายข้อมูลโอกาสการเสนอราคาที่ส่งผ่านเบราว์เซอร์ไปยัง SSP ด้วยรายการโดเมนต้นทางที่ไม่ซ้ำกันของ IG ที่ใช้งานอยู่ในเบราว์เซอร์	เรากำลังพูดคุยเกี่ยวกับคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ORTB	ส่งคำขอฮุกใหม่ 2 รายการสำหรับ publisherConfig และการปรับเปลี่ยนการเสนอราคาตอบของ generateBid ใน ORTB	เรากำลังตรวจสอบปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ชัยชนะก่อนหน้า	คำขอสำหรับ IG ที่กำหนด PrevWinsTransformer ซึ่งเอาชนะ IG ก่อนหน้านี้และเอาต์พุตที่ต่อเนื่องได้	เรากำลังตรวจสอบปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ประเภทเนื้อหา	กลยุทธ์ในการวิวัฒนาการของประเภทเนื้อหา เช่น การแปลง JSON เป็น CBOR	เรากำลังตรวจสอบปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
Prebid ใน Protected Audience API	ขอตัวอย่างหน้าของผู้เผยแพร่โฆษณาที่ใช้การเสนอราคาล่วงหน้าเพื่อเรียกใช้ขั้นตอนตั้งแต่ต้นจนจบสำหรับการประมูล Protected Audience	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศเกี่ยวกับเหตุผลที่ควรให้ความสำคัญในเรื่องนี้ นอกจากนี้ เรายังเห็นผู้เข้าร่วมในระบบนิเวศสร้างตัวอย่างหน้าเว็บของผู้เผยแพร่โฆษณาที่ให้ผู้อื่นในระบบนิเวศสาธิตด้วย

บริการประมูลที่มีการคุ้มครอง

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)	การใช้ Trusted Execution Environments ในระบบคลาวด์สาธารณะมีราคาแพงกว่าการใช้ศูนย์ข้อมูลเทคโนโลยีโฆษณาภายในองค์กร	โมเดลการรักษาความปลอดภัย TEE ในปัจจุบันของเราได้ประโยชน์จากการติดตั้งใช้งานระบบคลาวด์สาธารณะ โดยเฉพาะอย่างยิ่ง TEE ที่ใช้ฮาร์ดแวร์ในปัจจุบันไม่ได้ป้องกันการโจมตีทางกายภาพใดๆ เลย ผู้ให้บริการระบบคลาวด์สาธารณะที่รองรับอยู่แล้ว คือ AWS และ GCP ได้ออกแบบและใช้การลดความเสี่ยงในการเข้าถึงทางกายภาพ รวมถึงจากพนักงานด้วย โปรดดูรายละเอียดเพิ่มเติมเกี่ยวกับการสนับสนุนภายในองค์กรด้านล่าง เทคโนโลยีโฆษณาแจ้งเราว่าการให้บริการระบบคลาวด์มีราคาแพงกว่าศูนย์ข้อมูลเทคโนโลยีโฆษณาภายในองค์กร แม้เราจะไม่อยู่ในฐานะที่จะประเมินใบแจ้งยอดเหล่านั้น แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับค่าใช้จ่ายและประเมินทางเลือกต่างๆ ในการขยายการรองรับ TEE ต่อไป
(รายงานในไตรมาสที่แล้ว) TEE ภายในองค์กร	ข้อกำหนดในการเป็นผู้ให้บริการ TEE นั้นมีอะไรบ้าง	ผลตอบรับของเราคล้ายคลึงกับไตรมาสก่อนหน้า "ในขณะที่เรากำลังสำรวจการสนับสนุนสำหรับตัวเลือกที่นอกเหนือจากโซลูชันระบบคลาวด์สาธารณะ รวมถึงพิจารณาว่าการติดตั้งใช้งานแบบใดจะยอมรับได้ในแง่ของความปลอดภัย แต่เรายังไม่มีแผนปัจจุบันที่จะสนับสนุน TEE ภายในองค์กร ในขั้นนี้ เมื่อพิจารณาจากข้อกำหนดด้านความปลอดภัยของ Privacy Sandbox และความท้าทายที่สำคัญจากการติดตั้งใช้งานภายในองค์กร เราเชื่อว่าการขยายและปรับปรุงการติดตั้งใช้งานในระบบคลาวด์ต่อไปจะเป็นประโยชน์มากที่สุดสำหรับระบบนิเวศ อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับสาเหตุที่ข้อกำหนดดังกล่าวจำเป็นและเป็นไปได้เนื่องจากมีข้อจำกัดด้านความเป็นส่วนตัวและความปลอดภัย"
ขีดจำกัดของคีย์/ค่าเซิร์ฟเวอร์	ขีดจำกัดคีย์ต่อการประมูลต่อเซิร์ฟเวอร์	เรามีการพูดคุยเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ข้อจำกัดของ K-Anon	การยืนยันว่าจะไม่มีการบังคับใช้ K-anonymity ในอนาคตบนคีย์ K/V	เราไม่มีแผนที่จะบังคับใช้ K-anon กับคีย์คำขอของเซิร์ฟเวอร์ K/V เนื่องจากเรามีแผนที่จะย้ายเซิร์ฟเวอร์ K/V ไปยัง TEE ในอนาคต
บริการ K/V ในการก่อสร้าง	Google มีอาร์ติแฟกต์ที่สร้างไว้ล่วงหน้าสำหรับบริการ K/V ไหม	ปัจจุบันเรายังไม่มีอาร์ติแฟกต์ที่สร้างไว้ล่วงหน้าสำหรับเซิร์ฟเวอร์คีย์/ค่า Protected Audience แม้ว่าเราอาจพิจารณาให้อาร์ติแฟกต์เหล่านี้หากได้รับความต้องการที่สูงจากระบบนิเวศ
การสนับสนุน EgId ใน B&A	คำขอรองรับ testGroupId ฟิลด์ในโค้ดการเสนอราคาและการประมูล และส่งคำขอบริการ KeyValue จาก BuyerFrontEnd	ปัจจุบัน B&A ยังไม่รองรับ experimentGroupId แต่ตั้งเป้าไว้ว่าจะเปิดตัวแพลตฟอร์มนี้ภายในเวอร์ชันเบต้า 2 (ปัจจุบันกำหนดไว้ในเดือนกุมภาพันธ์ 2024) เราได้แชร์ข้อมูลเพิ่มเติมไว้ที่นี่
การใช้งาน API	การส่งคำขอการรวมใน HTTP จะช่วยป้องกันการโจมตีในระหว่างเส้นทางได้ แต่โอเปอเรเตอร์ของ TEE จะเรียนรู้เกี่ยวกับขนาดต่างๆ	เรากำลังพูดคุยเกี่ยวกับคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ปรับปรุงเอกสารประกอบ	ข้อกำหนดไม่ชัดเจนว่าจะมีการจัดการเซิร์ฟเวอร์ k-v อย่างไร	เรามีการพูดคุยเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การใช้งาน API	"Ad-Auction- Results" และ adAuctionHeaders คืออะไร	เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
ปรับปรุงเอกสารประกอบ	ไม่แน่ใจว่ามีการเผยแพร่การออกแบบ v2 ไปยัง FLEDGE.md หรือไม่	FLEDGE.md พูดถึงวิธีที่ Chrome ส่งคําขอไปยัง BYOS-KV การออกแบบโปรโตคอล V2 จำกัดไว้ให้ใช้กับ TEE-KV เท่านั้น และปัจจุบัน Chrome ยังไม่รองรับ

การวัดผลโฆษณาดิจิทัล

Attribution Reporting (และ API อื่นๆ)

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
การวัดแบบข้ามสภาพแวดล้อม	Chrome วางแผนรองรับการวัดผลข้ามสภาพแวดล้อมอย่างไรในระยะชั่วคราวที่มีการนำ 3PC ออกจาก Chrome บนอุปกรณ์เคลื่อนที่ แต่ Privacy Sandbox สำหรับ Android ยังไม่พร้อมให้บริการ	ทาง Android เรากำลังดำเนินการขยายการครอบคลุม PSB/ARA โดย Attribution Reporting API (ARA) พร้อมให้บริการใน Android 13 และ 14 และเราวางแผนที่จะเริ่มขยายการให้บริการไปยัง Android 11 และ 12 ภายในปีนี้ แม้ว่าอาจมีการเปลี่ยนแปลง เราจะขยายการให้บริการไปยัง Android 10 หรือเก่ากว่าไม่ได้ แต่เราคาดว่าเปอร์เซ็นต์ของอุปกรณ์ Android ที่ยังใช้ Android 10 หรือต่ำกว่านั้นจะลดลงใน 3PCD และลดลงตามปกติในขณะที่ผู้ใช้อัปเกรด เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศทางช่องนี้
การกรอง	การกรอง "Conversion" ออกจากการสแกนครีเอทีฟโฆษณา	เราได้ติดต่อผู้มีส่วนเกี่ยวข้องรายนี้เพื่อทำความเข้าใจคำขอของพวกเขาให้ดียิ่งขึ้น และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศเกี่ยวกับปัญหานี้
เซิร์ฟเวอร์โฆษณาบุคคลที่สาม	PA API และ ARA จะทำงานร่วมกับแท็กเซิร์ฟเวอร์โฆษณาของบุคคลที่สามอย่างไร	เซิร์ฟเวอร์โฆษณาสามารถตั้งค่าแหล่งที่มาและทริกเกอร์การลงทะเบียนสำหรับ ARA ด้วยตนเอง (รวมถึงจากการประมูลของ Protected Audience) หรือตั้งค่าการเปลี่ยนเส้นทางให้ส่งและยอมรับแหล่งที่มาและทริกเกอร์การลงทะเบียนสำหรับ ARA ซึ่งคล้ายกับการทำงานของพิกเซลกับแท็กการแสดงผลและแท็กการคลิกในปัจจุบัน
DCM	การรองรับ Attributionsrc โดย DCM และเซิร์ฟเวอร์โฆษณาบุคคลที่สามอื่นๆ	นี่เป็นปัญหาที่เกี่ยวข้องกับ DCM และทีม DCM ได้จัดการให้แล้วในปัญหาเกี่ยวกับ GitHub นี้
คีย์การรวมลำดับขั้น	จำเป็นต้องแบ่งงบประมาณการสนับสนุนทั้งหมดออกเป็นคีย์ตามลำดับชั้นทั้งหมดนี้ใช่ไหม	เราได้พูดคุยและให้คำตอบแก่ผู้มีส่วนเกี่ยวข้องรายนี้แล้ว เมื่อใช้โครงสร้างคีย์แบบลําดับชั้น เทคโนโลยีโฆษณาต้องคํานึงถึงงบประมาณการสนับสนุนที่มีการแชร์กันในคีย์เอาต์พุตทั้งหมดสำหรับการแสดงผล
ใช้โดเมนย่อยที่ต่างกัน	ทำให้การรายงานการระบุแหล่งที่มาทำงานกับแหล่งที่มาและทริกเกอร์ที่จดทะเบียนในโดเมนย่อยที่ต่างกัน แต่เป็น eTLD+1 เดียวกันไหม	เราได้พูดคุยเรื่องนี้กับผู้มีส่วนเกี่ยวข้องและเสนอวิธีแก้ปัญหาต่อไปนี้ ผู้เผยแพร่โฆษณาจะเปลี่ยนการตั้งค่า URL ให้มีต้นทางการรายงานเดียวกันเกี่ยวกับแหล่งที่มาและทริกเกอร์ หรือเปลี่ยนเส้นทางจาก URL ปัจจุบันไปยัง URL ทั่วไปก่อนดำเนินการลงทะเบียนก็ได้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศหากโซลูชันที่เสนอใช้งานไม่ได้กับ Use Case ของพวกเขา
(รายงานในไตรมาสก่อนหน้าด้วย) การสนับสนุนเวอร์ชันที่ใช้งานจริง	บริการระดับใดที่ให้การสนับสนุนพาร์ทเนอร์ที่ใช้ ARA ได้	ผลตอบรับของเราไม่มีการเปลี่ยนแปลงจากไตรมาสที่แล้ว "Google มีช่องทางต่างๆ ที่จะช่วยให้เทคโนโลยีโฆษณารายงานปัญหาทางเทคนิคได้และช่วยให้มีการส่งต่อปัญหาที่จำเป็นเพื่อแก้ไขปัญหาดังกล่าว นอกจากนี้ Chrome ยังคาดว่าจะสร้างและปรับขนาดกระบวนการเพิ่มเติมเพื่อแก้ไขปัญหาทางเทคนิคและการส่งต่อซึ่งส่งผลกระทบต่อความสมบูรณ์ของระบบนิเวศอีกด้วย Chrome มุ่งมั่นที่จะรับรองทรัพยากรต่างๆ สำหรับความพยายามนี้ โปรดไปที่โพสต์สำหรับนักพัฒนาซอฟต์แวร์เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับฟอรัมสาธารณะและส่วนตัวสำหรับความคิดเห็นและการส่งต่อเรื่อง"
(รายงานในไตรมาสก่อนหน้าด้วย) ไทม์ไลน์	Google จะมี "ระดับเหตุการณ์แบบยืดหยุ่นที่สมบูรณ์ระยะที่ 2" พร้อมก่อนเริ่มการทดสอบเชิงปริมาณของ CMA หรือไม่	ระดับกิจกรรมแบบยืดหยุ่นระยะที่ 2 ทั้งหมดคาดว่าจะพร้อมใช้งานใน Chrome ในไตรมาสที่ 1 ปี 2024 คุณติดตามสถานะได้ที่นี่
(รายงานในไตรมาสก่อนหน้าด้วย) Conversion Funnel	รายงานหลายโดเมนที่ใช้ใน Conversion	กรณีการใช้งานนี้เป็นไปได้เนื่องจากมีการเพิ่มปลายทางหลายแห่ง เรายินดีรับฟังความคิดเห็นเพิ่มเติม
การรายงานป้ายกำกับการทดสอบ	ความสามารถในการรายงานจะอนุญาตให้ผู้ทดสอบรายงานกลุ่มที่ผู้ใช้ (เบราว์เซอร์ Chrome) เป็นส่วนหนึ่งของ (โหมด A/B) หรือไม่	เรากำลังดำเนินการเผยแพร่คู่มือการทดสอบในการบันทึกป้ายกำกับการทดสอบ Chrome ใน ARA
เอกสารประกอบ	เอกสารประกอบว่าด้วยการระบุการระบุแหล่งที่มา-การรายงาน-การลงทะเบียน-แหล่งที่มาว่าจะหมดอายุ ระบบจะปัดเศษเป็นวันที่ใกล้ที่สุด แล้วระบบจะปัดเศษอย่างไร	ปัดเศษเป็นวันที่ใกล้ที่สุดหมายความว่า 1.5 วันจะปัดเศษเป็น 2 วัน
ใช้โดเมนย่อยที่ต่างกัน	ขอรับรายงาน Attribution Reporting API ในโดเมนย่อยอื่นเป็นแหล่งที่มาและเรียกการลงทะเบียนของแหล่งที่มา	เป็นไปไม่ได้ ใช้การเปลี่ยนเส้นทางด้วย HTTP ได้ แต่ไม่มีการตั้งค่าการเปลี่ยนเส้นทาง เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศว่าเพราะเหตุใดคำขอนี้จึงมีประโยชน์
ความล่าช้าในการรายงานระดับเหตุการณ์	การระบุแหล่งที่มาและกรอบเวลาการรายงาน 7 วัน แต่เนื่องจากความล่าช้าในการรายงานระดับเหตุการณ์ จึงอาจใช้เวลานานกว่า 8 วันในการแสดงรายงานทั้งหมด	เรารับทราบความคิดเห็นและยินดีให้ข้อมูลเพิ่มเติมจากระบบนิเวศว่าความล่าช้าในการรายงานระดับเหตุการณ์นี้เป็นปัญหาหรือไม่ โดยเฉพาะอย่างยิ่งการย้ายจากกรอบเวลาการรายงานเหตุการณ์แบบคงที่ไปเป็นที่ยืดหยุ่น
ทริกเกอร์ Conversion	ทริกเกอร์ Conversion ที่เกิดขึ้นระหว่างสิ้นสุด event_report_window แรก (1h) และเวลาหมดอายุ (1 วัน) จะไม่สร้างรายงาน	เราได้เริ่มใช้การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นซึ่งเปลี่ยนจากกรอบเวลาการรายงานเหตุการณ์แบบคงที่ไปเป็นที่ยืดหยุ่น
เสียงรบกวน	รายงานระดับเหตุการณ์เป็น Conversion ปลอมที่มีเสียงดังรบกวนตามที่อธิบายไว้ในวิดีโออธิบายของ GitHub ไหม	มี ระบบจะใช้ข้อมูลรบกวนกับรายงานระดับเหตุการณ์และเป็นตัวแทนของสถานะเอาต์พุตที่เป็นไปได้ทั้งหมด ซึ่งรวมถึงtrigger_data ที่แตกต่างกัน ไม่รายงานอะไรเลยเมื่อทริกเกอร์เกิดขึ้นจริง หรืออาจแสดงรายงานปลอมหลายรายการสําหรับเหตุการณ์นั้น % สัญญาณรบกวนเป็นแบบโอเพนซอร์สและยืดหยุ่นได้ผ่านการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น
การกรอง	การใช้การกรองด้วย Attribution Reporting API จะยังคงใช้งบประมาณการมีส่วนร่วมแม้ว่าจะไม่ได้บันทึกคีย์การรวมก็ตาม	การทํางานนี้เป็นไปตามที่ต้องการเนื่องจาก aggregatable_trigger_data รองรับเฉพาะการกรองในส่วนคีย์ทริกเกอร์เท่านั้น ไม่ใช่ตัวกรองในค่า / คีย์ ตัวกรองระดับบนสุดจะรองรับการกรองคีย์เอง แต่ระบบจะแชร์คีย์นี้โดยเหตุการณ์และการรวมข้อมูล ดังนั้นจึงไม่เกี่ยวข้องที่นี่ เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศที่นี่ หากจำเป็นต้องกรองคีย์
ขีดจำกัดการเก็บข้อมูล	คำขอแนะนำขีดจำกัดพื้นที่เก็บข้อมูลที่พิจารณาถึงต้นทางการรายงานด้วย	การเพิ่มขีดจำกัดนี้จาก 1,024 เป็น 4,096 จะมีผลตั้งแต่เวอร์ชัน M120 และเรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศที่นี่
การระบุแหล่งที่มาโดยตรง	วิธีดูเมตริกในกรณีที่ผู้ใช้เข้าชมผู้ลงโฆษณาโดยตรงโดยไม่ผ่านผู้เผยแพร่โฆษณา เนื่องจากขั้นตอนการรายงานการระบุแหล่งที่มาแบบมาตรฐานไม่ครอบคลุมสถานการณ์นี้	ARA ออกแบบมาเพื่อกู้คืนข้อมูลแบบข้ามเว็บไซต์เท่านั้น (นั่นคือ การผนวกข้อมูลระหว่างเว็บไซต์ของผู้เผยแพร่/ผู้ลงโฆษณา) เท่านั้น หากไม่มีข้อมูลแบบข้ามเว็บไซต์ ARA จะไม่ช่วยเหลือคุณ เรามีการพูดคุยเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
เวลาในการรายงาน	รับ schedule_report_time เวลาจากเซิร์ฟเวอร์เวลาแทนการใช้เวลาในเครื่อง	ปัจจุบันเรายังไม่มีแผนที่จะใช้ Timeserver และไม่ได้ยินความต้องการจาก Ad Tech มากนัก เราอยากรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศว่าฟีเจอร์นี้จะเป็นฟีเจอร์ที่มีประโยชน์หรือไม่

บริการรวบรวม

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
(รายงานในไตรมาสก่อนหน้าด้วย) โซลูชันภายในองค์กร	สามารถติดตั้งใช้งานบริการรวบรวมข้อมูลในศูนย์ข้อมูลภายในองค์กรได้ไหม	แม้ว่าเรากำลังสำรวจตัวเลือกที่อาจสนับสนุนนอกเหนือจากโซลูชันในระบบคลาวด์ แต่ขณะนี้ก็ยังไม่สามารถรองรับ TEE ภายในองค์กรได้ เนื่องจากมีข้อจำกัดด้านความปลอดภัยภายในองค์กร ซึ่งจำเป็นต้องมีการประเมิน Privacy Sandbox ซึ่งใช้เวลามาก เมื่อพิจารณาจากข้อกำหนดด้านความปลอดภัยของ Privacy Sandbox และความท้าทายที่สำคัญจากการติดตั้งใช้งานภายในองค์กร เราเชื่อว่าการขยายและปรับปรุงการติดตั้งใช้งานในระบบคลาวด์อย่างต่อเนื่อง (เช่น การรองรับ GCP และ AWS) จะเป็นประโยชน์ต่อระบบนิเวศนี้มากที่สุด อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่เกี่ยวกับสาเหตุที่ข้อกำหนดดังกล่าวมีความจำเป็น
เครือข่ายที่ปลอดภัย	หากเครือข่ายไม่เปิดขึ้นหรือเกิดข้อผิดพลาดในทันทีนั้น Aggregation Service API จะจัดการกับเครือข่ายนี้อย่างไร	เราจะใช้การดำเนินการซ้ำหากเครือข่ายที่ปลอดภัยล้มเหลวเมื่อเริ่มต้นใช้งาน และการปรับขนาดอัตโนมัติเพื่อเรียกอินสแตนซ์ใหม่หากพบว่าอินสแตนซ์มีประสิทธิภาพไม่ดี AdTech ยังสามารถตรวจสอบความล้มเหลวโดยใช้บันทึกได้อีกด้วย หากต้องการแก้ไขข้อบกพร่องของเครือข่ายที่ปลอดภัยใน AWS เทคโนโลยีโฆษณาสามารถตรวจสอบสถานะของอินสแตนซ์ EC2 ของตนได้โดยเข้าสู่ระบบผู้จัดการคอนโซล AWS เทคโนโลยีโฆษณายังสามารถเข้าสู่ระบบอินสแตนซ์โฮสต์ Nitro Enclave และตรวจสอบสถานะเครือข่ายได้ด้วยเครื่องมือ nitro-cli หากมีข้อผิดพลาด/ข้อผิดพลาด ผู้ใช้จะใช้อินเทอร์เฟซบรรทัดคำสั่ง AWS เพื่อดูบันทึกและตรวจสอบเพิ่มเติมได้ Adtechs สามารถตรวจสอบสถานะของอินสแตนซ์ผ่าน Cloud Console เพื่อแก้ไขข้อบกพร่องของเครือข่ายที่ปลอดภัยใน GCP นอกจากนี้ยังตรวจสอบข้อผิดพลาดโดยใช้คำสั่งข้อผิดพลาดรายการได้ด้วย
ใช้โดเมนย่อยที่ต่างกัน	ขอจดทะเบียนโดเมน (ย่อย) หลายโดเมนเพื่อใช้อินสแตนซ์หลายรายการของบริการ Aggregation ทั้งในสภาพแวดล้อม dev และ prod	มีการเปิดตัวการลงทะเบียนเว็บไซต์แล้วเพื่อให้เทคโนโลยีโฆษณาสามารถลงทะเบียนโดเมนย่อยหลายรายการของเว็บไซต์เดียวกันในบัญชี AWS หรือโปรเจ็กต์ GCP เดียวได้ นอกจากนี้ยังจดทะเบียนโดเมนเดียวกันในบัญชี AWS หรือโปรเจ็กต์ GCP หลายรายการได้อีกด้วย เรายินดีรับฟังความคิดเห็นจากระบบนิเวศ
งบประมาณด้านความเป็นส่วนตัว	วิธีที่ดีขึ้นเพื่อแก้ไขข้อบกพร่องที่เกี่ยวข้องกับงบประมาณความเป็นส่วนตัวที่หมดไป	ขณะนี้เรากำลังหาโซลูชันเพื่อให้รายละเอียดเพิ่มเติมเกี่ยวกับงบประมาณที่หมดแล้ว รวมถึงปรับปรุงเอกสารประกอบเพื่อสรุปกลยุทธ์ที่ AdTech สามารถใช้เพื่อลดการเกิดข้อผิดพลาดนี้ให้น้อยที่สุด เราจะอัปเดตหน้า Aggregation Service GitHub เมื่อมีข้อเสนอแล้ว
ค่า Epsilon	คำขอเพิ่มค่า epsilon	ค่า epsilon ของ Aggregation Service จะเก็บไว้เป็นช่วงสูงสุด 64 ตัวเพื่ออำนวยความสะดวกในการทดสอบและให้ฟีดแบ็กเกี่ยวกับพารามิเตอร์ต่างๆ ระหว่าง 3PCD เราจะแจ้งล่วงหน้าให้ระบบนิเวศทราบก่อนที่จะอัปเดตค่าช่วง epsilon
ไบนารี	เผยแพร่ชุดไบนารีที่สมบูรณ์มากขึ้นสำหรับรุ่นบริการรวบรวมข้อมูล	เรากำลังตรวจสอบคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้งาน API	การแชร์ข้อมูลกับผู้ประสานงาน โดยเป็นไปตามข้อกำหนดในการให้บริการของผู้ประสานงาน	เราต้องการคำชี้แจงเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติม

API การรวมส่วนตัว

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
การแก้ไขข้อบกพร่อง	เปิดใช้ตัวเลือกเพิ่มเติมสำหรับการแก้ไขข้อบกพร่องระหว่างการทดสอบโหมด B	ตามที่ได้แจ้งไว้ในปัญหา GitHub นี้ เรากำลังดำเนินการอนุญาตโหมดแก้ไขข้อบกพร่องในโหมด B การมีสิทธิ์นี้จะเปลี่ยนแปลงใน M121 รุ่นเบต้าที่ 50% ของการเข้าชมในโหมด B ตั้งแต่วันที่ 31/1 เราจะแจ้งให้ทราบก่อนเปลี่ยนเป็นเวอร์ชันเสถียร

จำกัดการติดตามโดยไม่เปิดเผย

การลด User Agent/คำแนะนำไคลเอ็นต์ User Agent

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
ChromeOS	รองรับคําแนะนําของไคลเอ็นต์ User Agent สําหรับบิตของ Chrome OS	เราได้แชร์การตอบกลับคำขอนี้ที่นี่

การป้องกัน IP (เดิมคือ Gnatcatcher)

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
การละเมิด	Google อาจดูข้อมูลการท่องเว็บของผู้ใช้ผ่านการปกป้อง IP ได้	อุโมงค์ข้อมูลการป้องกัน IP จะรับส่งข้อมูลผ่านพร็อกซี 2 รายการ (เครือข่ายหนึ่งดำเนินการโดย Google และโดยบริษัทอื่น) วิธีนี้ช่วยให้มั่นใจว่า Google จะไม่เห็นข้อมูลการท่องเว็บ การจราจรของข้อมูลจะถูกเข้ารหัสระหว่าง Chrome และพร็อกซี ดังนั้นพร็อกซีของ Google จึงไม่มีข้อมูลเกี่ยวกับเว็บไซต์ที่เรียกดูอยู่ นอกจากนี้ ระบบยังใช้โทเค็นการตรวจสอบสิทธิ์แบบปิดบังตัวตนเพื่อลดการเข้าถึงตัวระบุผู้ใช้ที่พร็อกซีด้วย พร็อกซี Google ทั้งหมดจะเห็นว่ามีไคลเอ็นต์ที่ไม่รู้จักใน IP ที่ระบุกำลังใช้ระบบพร็อกซีอยู่ ไม่มีข้อมูลเกี่ยวกับเว็บไซต์ที่เข้าชมหรือโฆษณาที่โหลด
รองรับโหมดไม่มีส่วนหัว	บ็อตที่ใช้ปลั๊กอินและโหมดไม่มีส่วนหัวจะจัดการอย่างไร	การลดการละเมิดการป้องกัน IP คือสิ่งสำคัญสำหรับทีม เราได้พิจารณาสถานการณ์เหล่านี้อย่างรอบคอบแล้ว (ท่ามกลางภัยคุกคามอื่นๆ ที่อาจเกิดขึ้นอีกจำนวนมาก) และกําลังหาตัวเลือกที่จะช่วยลดความเป็นไปได้ที่การละเมิดหรือการประพฤติมิชอบจะประสบความสำเร็จ แม้เราจะให้รายละเอียดเพิ่มเติมไม่ได้ในขณะนี้ แต่เราคาดว่าจะแจ้งให้ทราบได้ในอนาคตอันใกล้และหวังว่าจะได้หารือกันต่อไป
พร็อกซีที่มีอยู่	การปกป้อง IP จะทํางานอย่างไรกับการตั้งค่าพร็อกซีที่มีอยู่ใน Chrome	ระบบจะยังคงรองรับการกำหนดค่าพร็อกซีที่มีอยู่ ผู้ใช้จะกำหนดค่าพร็อกซีที่กำหนดเองได้เหมือนเดิม
การรายงานการละเมิด	การรายงานการละเมิดจะได้รับการจัดการอย่างไร	เราจะให้รายละเอียดเพิ่มเติมในเร็วๆ นี้ แต่เราวางแผนที่จะให้องค์กรและผู้ใช้แชร์รายงานและหลักฐานการละเมิด
กฎระเบียบ	การปกป้อง IP จะปฏิบัติตามกฎหมายและข้อบังคับท้องถิ่นอย่างไร	Google มุ่งมั่นที่จะปฏิบัติตามกฎหมายและข้อบังคับท้องถิ่น และอาจไม่อนุญาตให้มีการหลีกเลี่ยงการบล็อกระดับประเทศดังกล่าว ฟีเจอร์นี้ไม่ได้มีไว้เพื่อการหลบเลี่ยง
การจำกัดความสามารถ	การป้องกัน IP จะบล็อกการตอบสนองทางไซเบอร์ของเราไหม	เราพยายามรักษาความสมดุลระหว่างการปกป้องผู้ใช้จากการถูกติดตามข้ามเว็บตามที่อยู่ IP ในขณะเดียวกันก็ช่วยลดการหยุดชะงักในการทำงานตามปกติของเซิร์ฟเวอร์ ซึ่งรวมถึงการใช้ที่อยู่ IP เพื่อต่อต้านการละเมิดด้วย แม้เราจะให้รายละเอียดเพิ่มเติมไม่ได้ในขณะนี้ แต่เราคาดว่าจะแจ้งให้ทราบได้ในอนาคตอันใกล้และหวังว่าจะได้หารือกันต่อไป
ไทม์ไลน์	หากเรื่องนี้จะบังคับใช้ก่อนสิ้นปี 2024 ก็แทบจะเป็นไปไม่ได้เลยที่จะเตรียมพร้อมสำหรับการเปลี่ยนแปลงนี้	ในช่วงแรก Chrome จะเปิดตัวการปกป้อง IP เป็นการตั้งค่าแบบเลือกใช้สำหรับผู้ใช้ในบางภูมิภาค และเข้าใจว่านี่อาจเป็นการเปลี่ยนแปลงที่สำคัญต่อวิธีที่บริษัทบางแห่งอาศัยที่อยู่ IP และต้องการลดการหยุดชะงักในขณะที่ระบบนิเวศกำลังเปลี่ยนแปลงไป การปกป้อง IP จะเปลี่ยนไปเป็นค่าเริ่มต้นในปี 2025
การใช้งาน API	ผู้ใช้จะมีตัวเลือกในการเปิด/ปิดการป้องกัน IP ในครั้งแรกที่เปิด Chrome ไหม	เรามีแผนที่ให้ผู้ใช้เลือกได้ว่าจะใช้การป้องกัน IP หรือไม่ กลไกในการนำเสนอตัวเลือกนี้แก่ผู้ใช้ยังอยู่ระหว่างการพัฒนา
การใช้งาน API	จะมีการบันทึกข้อมูลไว้มากน้อยแค่ไหน และเก็บข้อมูลนั้นไว้นานเท่าใด	เราจะให้รายละเอียดเพิ่มเติมในอนาคต แต่เราวางแผนที่จะบันทึกข้อมูลปริมาณน้อยที่สุด
ความคิดเห็นเชิงลบ	ผู้ใช้สามารถใช้ VPN ได้หากต้องการ ไม่จำเป็นต้องใช้ PS API	เป้าหมายของการป้องกัน IP คือเพื่อป้องกันการใช้ที่อยู่ IP เพื่อการติดตามข้ามเว็บไซต์ แต่ไม่ได้มีไว้เพื่อเป็นบริการ VPN
ความปลอดภัยของ API	วิธีป้องกันไม่ให้บุคคลที่หนึ่งเข้าถึงที่อยู่ IP และส่งต่อข้อมูลผ่านพารามิเตอร์ของส่วนหัว	ในขั้นต้น เรามุ่งเน้นไปที่บุคคลที่สามเนื่องจากเห็นว่ามีผลกระทบมากที่สุด เราจะยังคงติดตามดูระบบนิเวศข่าวต่อไปเพื่อพิจารณาว่าเราจำเป็นต้องพัฒนาแนวทางของเราในการป้องกันการหลบเลี่ยงในวงกว้างหรือไม่
การใช้งาน API	ต้องยืนยันหากความเข้าใจการใช้งาน API ถูกต้อง	การปกป้อง IP ใช้วิธีการแบบรายการเพื่อระบุว่าการเข้าชมของบุคคลที่สามรายการใดจะต้องผ่านพร็อกซี ต้นทางที่อยู่ในรายการแต่เข้าถึงในบริบทของบุคคลที่หนึ่งจะไม่ผ่านพร็อกซีผ่านบริการนี้สำหรับการเชื่อมต่อเหล่านั้น ตัวอย่างเช่น หากบริษัทการวิเคราะห์อยู่ในรายการโดเมนและผู้ใช้เข้าไปยังเว็บไซต์โดยตรง เว็บไซต์ดังกล่าวจะยังสังเกตที่อยู่ IP ของผู้ใช้ได้แทนที่จะเป็นที่อยู่ IP ผ่านพร็อกซี อย่างไรก็ตาม หากโดเมนนั้นในรายการส่งคำขอเครือข่ายในบริบทของบุคคลที่สาม การเชื่อมต่อจะเป็นผ่านพร็อกซี และเว็บไซต์จะไม่เห็นที่อยู่ IP เดิมของผู้ใช้ เป้าหมายสูงสุดของเราคือการป้องกันไม่ให้มีการติดตามผู้ใช้แบบข้ามเว็บไซต์ในอินเทอร์เน็ต เรากำลังดูรายละเอียดต่างๆ ก่อนแชร์ข้อมูลเพิ่มเติมเกี่ยวกับโดเมนของบุคคลที่สามที่เราวางแผนจะมุ่งเน้นในช่วงแรก
VPN	กังวลว่าข้อเสนอของ Google อาจส่งผลเสียต่อผู้ให้บริการ VPN รายอื่น	เป้าหมายของการป้องกัน IP คือเพื่อป้องกันการใช้ที่อยู่ IP เพื่อการติดตามข้ามเว็บไซต์ แต่ไม่ได้มีไว้เพื่อเป็นบริการ VPN
ไทม์ไลน์	การป้องกัน IP มีไทม์ไลน์เป็นอย่างไร	การปกป้อง IP จะเลือกใช้ในตอนแรก วิธีนี้ช่วยให้ผู้ใช้ควบคุมการตัดสินใจด้านความเป็นส่วนตัวได้และ Google จะตรวจสอบพฤติกรรมในปริมาณที่ลดลงได้ การปกป้อง IP จะเปิดตัวโดยแบ่งเป็นช่วงๆ และจะเปลี่ยนไปใช้ค่าเริ่มต้นภายในปี 2025 เช่นเดียวกับข้อเสนอด้านความเป็นส่วนตัวทั้งหมด เราอยากจะแน่ใจว่าเราจะเรียนรู้ขณะที่เรียนรู้และตระหนักดีว่าอาจมีข้อควรพิจารณาในระดับภูมิภาคที่ต้องพิจารณาด้วยเช่นกัน เราใช้วิธีการแบบอิงตามรายการและมีเพียงโดเมนในรายการในบริบทของบุคคลที่สามเท่านั้นที่จะได้รับผลกระทบ เราตระหนักดีว่าข้อเสนอเหล่านี้อาจทำให้เกิดการหยุดชะงักที่ไม่พึงประสงค์ต่อกรณีการใช้งานที่เหมาะสม เราจึงมุ่งเน้นไปที่สคริปต์และโดเมนที่ถือว่าติดตามผู้ใช้เท่านั้น
การจำกัดความสามารถ	ค้นหาที่อยู่ IP ของผู้ใช้ใน WHOIS ไม่ได้อีกต่อไป	จุดยืนของเราคือ ที่อยู่ IP เป็นตัวระบุที่เสถียร ซึ่งการใช้งานอาจมีผลกระทบต่อความเป็นส่วนตัวของผู้ใช้ รวมถึงการใช้ข้อมูลเมตาที่เกี่ยวข้อง เช่น ASN การปกป้อง IP เราพยายามรักษาสมดุลที่เหมาะสมระหว่างความเป็นส่วนตัวกับการสนับสนุนประสบการณ์ของผู้ใช้ที่เป็นประโยชน์บนเว็บ เช่น แนวทางการค้นหาตำแหน่งทางภูมิศาสตร์จาก IP ของเรา หากข้อมูลเมตานี้ไม่เพียงพอสำหรับ Use Case ของคุณ เรายินดีที่จะพูดคุยเพิ่มเติม
URL ที่มา HTTP	ระบบจะเก็บรักษา URL ที่มา HTTP เดิมไว้ไหม	ทั้งนี้ เรายังไม่มีแผนที่จะเปลี่ยนแปลงส่วนหัวผู้อ้างอิงโดยเป็นส่วนหนึ่งของการปกป้อง IP ตามที่อธิบายไว้ที่นี่
โอเพนซอร์ส	ซอร์สโค้ดของการปกป้อง IP จะเป็นโอเพนซอร์สไหม	ซอฟต์แวร์ส่วนใหญ่ในตัวอย่างนี้เป็นซอฟต์แวร์โอเพนซอร์สเป็นส่วนหนึ่งของโปรเจ็กต์ Chromium และ Envoy Proxy แต่คอมโพเนนต์บางส่วนก็เป็นซอฟต์แวร์แบบปิดตามที่อธิบายไว้ที่นี่

การลดการติดตามการเข้าออก

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
การลบพื้นที่เก็บข้อมูล	การลดการติดตามการเข้าออก (BTM) ลบพื้นที่เก็บข้อมูลที่ใช้ร่วมกันและพื้นที่เก็บข้อมูล Attribution Reporting หรือไม่	เราไม่ได้ต้องการให้ BTM ลบพื้นที่เก็บข้อมูล Privacy Sandbox API (ARA, PA API, พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน, การรวมส่วนตัว, หัวข้อ) BTM ควรลบเฉพาะประเภทพื้นที่เก็บข้อมูลที่มีความเสี่ยงด้านความเป็นส่วนตัวเมื่อเข้าถึงในบริบทของบุคคลที่สาม การแก้ไขข้อบกพร่องอยู่ระหว่างดำเนินการ
การใช้งาน API	BTM จะเปิดใช้งาน Chrome เวอร์ชันใด การติดตามการเปลี่ยนเส้นทาง/ตีกลับหลังจากผ่านไป 10 วินาทีจะถือว่าเป็นการติดตามการตีกลับโดย BTM หรือไม่	ใน M116 ได้เปิดตัว BTM กับผู้ใช้ 100% โดยบล็อก 3PC ไว้ ขณะนี้การเปลี่ยนเส้นทางหลังจาก 10 วินาทีไม่ถือว่าเป็นการตีกลับ
กรณีการใช้งานการลงชื่อเข้าใช้	ซิงค์/รักษาสถานะการลงชื่อเข้าใช้ในหลายโดเมนโดยอัตโนมัติ โดยไม่ถูกลงโทษจากพฤติกรรมที่คล้ายกับการติดตามหรือไม่	เราพูดคุยเกี่ยวกับคำขอนี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
เส้นทางของผู้ใช้	ปัจจุบัน BTM ส่งผลให้เส้นทางของผู้ใช้มีความซับซ้อน	เรากำลังพูดคุยถึงปัญหาและแชร์ความคิดเห็นเกี่ยวกับเรื่องนี้ได้ที่นี่
API การเข้าถึงพื้นที่เก็บข้อมูล	BTM ใน Chromium จะยึดตามการให้สิทธิ์ 3PC จาก API การเข้าถึงพื้นที่เก็บข้อมูล (SAA)	เราได้พูดคุยถึงปัญหานี้กับผู้เข้าร่วมในระบบนิเวศที่งาน TPAC 2023 และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ผลกระทบต่อการรายงานโฆษณา	การลดการติดตามการเข้าออกอาจนำไปสู่บริษัทขนาดเล็กในระบบนิเวศที่อาศัย Privacy Sandbox API อื่นๆ เช่น ARA ในการใช้งานโฆษณา	การลดการติดตามการเข้าออกมีไว้เพื่อป้องกันการหลบเลี่ยง 3PCD ARA เป็นหนึ่งในโซลูชันการวัดผลทางเลือกที่บริษัทจะใช้ได้หลังจาก 3PCD แต่ไม่จำเป็นต้องใช้

งบประมาณด้านความเป็นส่วนตัว

ยังไม่มีความคิดเห็นสำหรับไตรมาสนี้

เสริมสร้างขอบเขตความเป็นส่วนตัวข้ามเว็บไซต์

ชุดเว็บไซต์ที่เกี่ยวข้อง (เดิมคือชุดโดเมนของบุคคลที่หนึ่ง)

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
(รายงานในไตรมาสก่อนหน้าด้วย) ขีดจํากัดโดเมนของชุดเว็บไซต์ที่เกี่ยวข้อง (RWS)	คำขอขยายจำนวนโดเมนที่เชื่อมโยง	ในปัจจุบัน เราคาดว่าจะเพิ่มขีดจำกัดตัวเลข ขีดจำกัดนี้กำหนดขึ้นตามข้อควรพิจารณาเกี่ยวกับความเป็นส่วนตัวของผู้ใช้ ความคิดเห็นจากผู้มีส่วนเกี่ยวข้องในระบบนิเวศใน W3C และการพิจารณาถึงการติดตั้งใช้งานที่คล้ายกันในเบราว์เซอร์อื่นๆ สำหรับข้อมูลเพิ่มเติม โปรดดูบล็อกโพสต์ของเรา (1, 2) เราขอแนะนำให้ตรวจสอบกรณีการใช้งานที่ต้องเข้าถึงคุกกี้ข้ามเว็บไซต์เกินขีดจำกัดตัวเลข และพิจารณาใช้ประโยชน์จากคำแนะนำของเราเกี่ยวกับกรณีการใช้งานของข้อมูลประจำตัว การฝังที่ตรวจสอบสิทธิ์ และ กรณีการใช้งานการโฆษณา
ขอบเขตของการเข้าถึงคุกกี้	ข้อกังวลว่าโดเมนทั้งหมดใน RWS จะได้รับสิทธิ์เข้าถึงเพื่ออ่านและเขียนคุกกี้ทั้งหมดจากทุกโดเมน	การเป็นสมาชิกใน RWS ไม่ได้ส่งผลให้สมาชิกเข้าถึงคุกกี้ของกันและกันได้ การเปลี่ยนแปลงนี้จะทำให้สมาชิกเข้าถึงคุกกี้ของตนเองได้เมื่อฝังในเว็บไซต์ RWS เดียวกันอื่นๆ แทน (หลังจากเรียกใช้ Storage Access API)
(รายงานในไตรมาสก่อนหน้าด้วย) การผสานรวม RWS + CHIPS	ส่งคำขอผสานรวม RWS + CHIPS เพื่อรองรับกรณีการใช้งาน เช่น การทดสอบ A/B	เรายังคงขอ Use Case และคำขอฟีเจอร์สำหรับฟีเจอร์นี้อยู่ ที่นี่ สำหรับตอนนี้ เรากำลังชั่งน้ำหนักความจำเป็นของฟีเจอร์นี้กับความเสี่ยงในการทำงานร่วมกันข้ามเบราว์เซอร์
การใช้งาน API	จะเกิดอะไรขึ้นหากผู้ใช้นำเว็บไซต์ออกจากการตั้งค่า Chrome ในเครื่องด้วยตนเอง	ขณะนี้เรายังไม่มีวิธีให้ผู้ใช้ลบเว็บไซต์ออกจากกลุ่มด้วยตนเอง ผู้ใช้สามารถเลือกที่จะปิดฟีเจอร์ "เว็บไซต์ที่เกี่ยวข้อง" โดยใช้ปุ่มสลับด้านล่าง "บล็อกคุกกี้ของบุคคลที่สาม" หรือ "บล็อกคุกกี้ของบุคคลที่สามทั้งหมด" ในแผงการตั้งค่าการป้องกันการติดตามใหม่
การสื่อสารข้ามโดเมน	RWS อนุญาตให้มีการสื่อสารข้ามโดเมนหรือไม่	ขณะนี้เรากำลังทดลองใช้จากต้นทางเพื่อขยายการเข้าถึงพื้นที่เก็บข้อมูลบางประเภทที่ไม่ได้แบ่งพาร์ติชัน (รวมถึง localStorage และช่องทางการออกอากาศ) ผ่าน Storage Access API ซึ่งจะเปิดใช้การสื่อสารนี้ได้ ความสามารถนี้พร้อมให้ใช้งานในการกำหนดค่า Storage Access API ที่รองรับทั้งหมดใน RWS เดียวกันและ ในเว็บไซต์ที่ไม่ใช่ RWS บล็อกโพสต์นี้มีข้อมูลเพิ่มเติม
requestStorageAccessFor	document.requestStorageAccessFor(origin) แสดงผลสัญญาที่แก้ไขด้วยคุกกี้ข้ามเว็บไซต์ของต้นทางได้ไหม	เป็นไปไม่ได้ เนื่องจากการเรียกใช้เกิดขึ้นจากต้นทางระดับบนสุด (ซึ่งแตกต่างจากต้นทางที่ส่งผ่านเป็นอาร์กิวเมนต์) การดำเนินการดังกล่าวจะละเมิดนโยบายต้นทางเดียวกัน

Fenced Frames API

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
(รายงานในไตรมาสก่อนหน้าด้วย) โฆษณาเนทีฟ	การรองรับเฟรมที่มีการปิดกั้นสำหรับโฆษณาเนทีฟ	เราเคยแชร์ก่อนหน้านี้ว่าในอนาคตจะต้องใช้เทคโนโลยี Privacy Sandbox บางอย่างเพื่อเพิ่มประสิทธิภาพให้กับการคุ้มครองความเป็นส่วนตัวมากขึ้น เช่น สำหรับ Protected Audience เราจะกำหนดให้ใช้ Fenced Frame ในการแสดงโฆษณา และเปลี่ยนจากการรายงานระดับเหตุการณ์ก่อนปี 2026 เราได้ระบุวันที่ "ไม่เร็วกว่า" สำหรับข้อกำหนดในอนาคตแต่ละข้อ ดังนั้นอุตสาหกรรมนี้จึงมีความชัดเจนเกี่ยวกับการพัฒนาของ API ที่ต้องการ เวลาที่เพิ่มขึ้นนี้จะช่วยให้เราทำงานร่วมกับอุตสาหกรรมต่อไปเพื่อออกแบบและใช้การสนับสนุนสำหรับกรณีการใช้งานที่สำคัญในวงกว้างยิ่งขึ้น เช่น เราจะพัฒนา Fenced Frame ก่อนข้อกำหนดในปี 2026 ขึ้นไปเพื่อคงการรองรับโฆษณาวิดีโอและโฆษณาเนทีฟด้วย Protected Audience API ตามความมุ่งมั่นของเรา CMA จะได้รับการปรึกษาเกี่ยวกับการเปลี่ยนแปลงดังกล่าว และเราจะรับฟังความคิดเห็นจากระบบนิเวศต่อไปก่อนที่จะปฏิบัติตามข้อกำหนด "เร็วกว่า"
ขนาดที่ต่างกันในแต่ละแพลตฟอร์ม	รายงานว่าขนาดของเนื้อหาที่แสดงในเฟรมที่มีการปิดกั้นนั้นดูต่างกันระหว่างเดสก์ท็อปและสมาร์ทโฟน	เรากำลังตรวจสอบปัญหาดังกล่าวและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
แสดงคอมโพเนนต์โฆษณา	ระบุโค้ดตัวอย่างเกี่ยวกับวิธีแสดงผล adElements ใน Fenced Frame ไหม	เราจะจัดหาเอกสารเกี่ยวกับวิธีใช้ navigator.adAuctionElements(numส่วนประกอบ) ภายในเฟรมที่ล้อมรั้วเพื่อแสดงโฆษณาที่ประกอบด้วยชิ้นส่วนหลายชิ้น
ปรับปรุง API	ส่งสัญญาณเพิ่มเติมไปยัง FencedFrames (ปรับปรุงเช่น ความปลอดภัยของแบรนด์)	เรายินดีดำเนินการตามข้อเสนอและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่

API พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
กรณีการใช้งานเพื่อต่อต้านการละเมิด / ป้องกันการทุจริต	ศักยภาพในการใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันเพื่อตรวจจับการประพฤติมิชอบหรือความผิดปกติ	เราพูดคุยเกี่ยวกับความเป็นไปได้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การกำหนดความถี่สูงสุด	ระบุวิธีกำหนดความถี่สูงสุดข้ามเว็บไซต์ภายนอก PA API	เราขอขอบคุณสำหรับความคิดเห็นที่ว่าการกำหนดความถี่สูงสุดข้ามเว็บไซต์นอก PA API เป็นกรณีการใช้งานที่มีประโยชน์ ในตอนนี้ Privacy Sandbox ยังคงมุ่งเน้นที่ API ชุดปัจจุบันสำหรับ 3PCD อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศเกี่ยวกับกรณีการใช้งานนี้ที่นี่

ชิป

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
ป๊อปอัป/การเปลี่ยนเส้นทาง	CHIP จะรองรับ Use Case ของการตรวจสอบสิทธิ์แบบฝังที่เกี่ยวข้องกับป๊อปอัปและการเปลี่ยนเส้นทางได้อย่างไร	เมื่อเร็วๆ นี้เราได้แชร์คําแนะนําเกี่ยวกับการตรวจสอบผลกระทบของการยกเลิกการใช้งาน 3PC ที่มีต่อเวิร์กโฟลว์การลงชื่อเข้าใช้ และเรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ขีดจำกัดพาร์ติชัน	ลดขีดจำกัดต่อเว็บไซต์โดยรวมต่อพาร์ติชันเป็น 1 KiB	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่ เราจะติดตามความคิดเห็นต่อไปเมื่อเปิดตัว 3PCD และนักพัฒนาแอปใช้ CHIP และแสดงความคิดเห็น
การย้ายข้อมูลคุกกี้	กระบวนการที่แนะนำสำหรับการย้ายข้อมูลเว็บแอปเพื่อออกคุกกี้ตามการแบ่งพาร์ติชันที่ไม่ทำให้คุกกี้/เซสชันที่ดำเนินอยู่เสียหาย	เราเสนอแผนการย้ายข้อมูลที่เป็นไปได้ในการตอบกลับ ที่นี่ แต่นักพัฒนาแอปสามารถกำหนด โซลูชันทางเลือกที่ทำงานได้ดีกว่าในการกำหนดค่า
การใช้งาน API	การเข้าถึงพื้นที่เก็บข้อมูลที่แบ่งพาร์ติชันจะถูกปิดใช้เมื่อผู้ใช้ไม่ได้เลือกใช้การตั้งค่า Ad Privacy API ใช่ไหม	จะมีการเปิดใช้พื้นที่เก็บข้อมูลที่แบ่งพาร์ติชันและคุกกี้ที่แบ่งพาร์ติชัน (CHIP) แม้ว่าผู้ใช้จะไม่ได้เลือกใช้การตั้งค่า Ad Privacy API เนื่องจากไม่ได้เปิดใช้การโอนข้อมูลข้ามเว็บไซต์ ตามหลักการทั่วไป การโอนข้อมูลข้ามเว็บไซต์จะมีข้อจำกัด การตรวจสอบ หรือการเลือกใช้ของผู้ใช้ แต่ในปัจจุบันวิธีการนี้ยังใช้ไม่ได้กับ CHIPS
การใช้งาน API	อะไรคือเหตุผลในการบล็อกคุกกี้ที่ไม่ได้แบ่งพาร์ติชันในที่สุด แทนที่จะให้เบราว์เซอร์ทำการแบ่งพาร์ติชันแบบ "เงียบ" เพียงอย่างเดียว	คุณไม่สามารถดำเนินการนี้ในระยะสั้นและระยะกลางได้ ตามที่อธิบายไว้ที่นี่

FedCM

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
การใช้งาน API	แสดง "ไฟล์ที่รู้จักกันดี" บน eTLD+1 ภายในสภาพแวดล้อมการพัฒนาไม่ได้	เราได้อัปเดต Chrome Canary ให้ข้ามการดึงข้อมูลฟีเจอร์ดังที่กล่าวถึงที่นี่
การใช้งาน API	มีข้อกำหนดการโต้ตอบของผู้ใช้ที่เฉพาะเจาะจงให้ขอสิทธิ์การลงชื่อเข้าใช้ของบุคคลที่สามหรือการใช้ FedCM ไหม	เราไม่มีข้อกำหนดที่เฉพาะเจาะจงในการโต้ตอบของผู้ใช้ตามที่อธิบายไว้ที่นี่
ความปลอดภัยของ API	มีแผนการใช้กระบวนการที่ช่วยให้ไคลเอ็นต์เริ่มต้น FedCM หรือไม่ แต่โดยพื้นฐานแล้ว โทเค็นจะถูกโอนจาก IdP ไปยังระบบแบ็กเอนด์ของ RP หรือไม่	ตอนนี้เรากำลังพูดคุยอยู่และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
เลือกใช้	อนุญาตให้ IDP เลือกรับรหัสไคลเอ็นต์ของ RP เพื่อให้ผู้ใช้ตัดสินใจได้ว่าจะเชื่อถือ IdP หรือไม่	เรากำลังพูดคุยเกี่ยวกับคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การใช้งาน API	ขอเอกสารเพิ่มเติมเกี่ยวกับ FedCM	เรารับทราบความคิดเห็นนี้และจะปรับปรุงเอกสารประกอบต่อไปในขณะที่พัฒนา API นี้อย่างต่อเนื่อง

ต่อสู้กับสแปมและการประพฤติมิชอบ

Private State Token API (และ API อื่นๆ)

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
เอกสารประกอบ	ขอคู่มือนักพัฒนาซอฟต์แวร์โดยละเอียดเกี่ยวกับโทเค็นสถานะส่วนตัวเพื่อช่วยในการทดสอบ	เราได้เผยแพร่คู่มือนักพัฒนาซอฟต์แวร์สำหรับโทเค็นสถานะส่วนตัวในไตรมาสที่ 4 ปี 2023
การยืนยันอายุ/เพศ	การยืนยัน "อายุและเพศ" ของผู้ชมหลังโพสต์ 3PCD ทำได้ยาก	ปัจจุบันโทเค็นสถานะส่วนตัวไม่ได้ออกแบบมาเพื่อการยืนยันอายุและเพศ เราต้องการทำความเข้าใจเกี่ยวกับกรณีการใช้งานให้ดียิ่งขึ้น และอยากทราบว่าสถานการณ์นี้บรรลุผลอย่างไรในปัจจุบัน และยินดีรับฟังความคิดเห็นเพิ่มเติม