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

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

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

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

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

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

ความคิดเห็นที่ได้รับเมื่อเร็วๆ นี้อาจยังไม่มีคำตอบจาก Chrome

อภิธานศัพท์เกี่ยวกับตัวย่อ

ARA

Attribution Reporting API

CHIPS

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

DSP

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

FedCM

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

IAB

Interactive Advertising Bureau

IDP

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

IETF

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

IP

ที่อยู่ Internet Protocol

openRTB

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

OT

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

PA API

Protected Audience API (เดิมเรียกว่า FLEDGE)

PatCG

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

RP

ผู้เชื่อถือ

RWS

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

SSP

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

UA

สตริง User Agent

UA-CH

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

W3C

World Wide Web Consortium

WIPB

การจงใจปิดบัง IP

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การคอมมิต	ส่วน ก ของข้อผูกมัดมีความสําคัญต่อความเป็นไปได้ของ Privacy Sandbox หากไม่มีการรับประกันว่าธุรกิจโฆษณาของ Google จะทํางานบนเทคโนโลยีแซนด์บ็อกซ์แต่เพียงอย่างเดียว ความเสี่ยงที่ประโยชน์ของเทคโนโลยีจะลดลงเรื่อยๆ และโอกาสที่ Google จะขายเทคโนโลยีนี้ออกก็จะมีมากขึ้น การขายหรือลดประสิทธิภาพดังกล่าวจะเป็นภัยคุกคามต่อที่อยู่แบบเน้นความเป็นส่วนตัวในเว็บแบบเปิด	ความมุ่งมั่นดังกล่าวไม่ได้รับประกันว่าธุรกิจโฆษณาของ Google จะดำเนินงานแต่เพียงผู้เดียว บนเทคโนโลยี Privacy Sandbox Google ตั้งใจที่จะใช้แนวทางแบบพอร์ตโฟลิโอในการระบุตัวตน ซึ่งจะรวมเทคโนโลยี Privacy Sandbox ไว้ด้วย เช่นเดียวกับที่บุคคลที่สามใช้อยู่ เราเข้าใจว่าแนวทางแบบพอร์ตโฟลิโอเป็นแนวทางที่ใช้กันทั่วไปในระบบนิเวศโฆษณา เราเชื่อว่านักพัฒนาแอปยังคงต้องใช้เครื่องมือและเทคโนโลยีการรักษาความเป็นส่วนตัว เราจะให้บริการ Privacy Sandbox API ต่อไปและลงทุนใน API ดังกล่าวเพื่อปรับปรุงความเป็นส่วนตัวและการใช้งานฟีเจอร์ต่างๆ ต่อไป
การกำกับดูแล	รูปแบบการกํากับดูแลที่เสนอนี้ไม่มีกลไกที่เฉพาะเจาะจงสําหรับความรับผิดชอบในกระบวนการปรึกษาหารืออย่างเป็นทางการหรือการอุทธรณ์	ข้อมูลนี้ไม่ถูกต้อง ทั้ง (1) ระบบการตัดสินและการเผยแพร่ที่เกี่ยวข้อง และ (2) กระบวนการอุทธรณ์มีกลไกที่เฉพาะเจาะจงสำหรับการแสดงความรับผิดชอบ นอกจากนี้ ผู้รับมอบสิทธิ์ในการตรวจสอบจะควบคุมดูแลการทํางานโดยละเอียด
การกำกับดูแล	ความคิดเห็นว่าโมเดลไม่มีบทบัญญัติสำหรับการสร้างและบำรุงรักษามาตรฐานข้ามแพลตฟอร์ม	ไม่มีรูปแบบการกํากับดูแลใดบังคับให้ผู้เล่นรายอื่นๆ ซึ่งในกรณีนี้คือเบราว์เซอร์ ใช้มาตรฐาน เราจึงไม่ได้เสนอรูปแบบที่ต้องใช้มาตรฐานข้ามแพลตฟอร์ม Google จะยังคงมีส่วนร่วมในฟอรัมมาตรฐานต่อไป ซึ่งการเสนอและแชร์ประสบการณ์ในการใช้งานข้อเสนอเป็นกิจกรรมทั่วไปในกระบวนการนี้
การกำกับดูแล	เราขอแนะนำให้ขยายระยะเวลาให้คำปรึกษาเป็นอย่างน้อย 2 เดือน รูปแบบการกํากับดูแลที่เสนอไม่ได้ให้เวลาระบบนิเวศมากพอในการวิเคราะห์ผลกระทบของการเปลี่ยนแปลงที่เสนอ	ระยะเวลา 3 สัปดาห์ไม่ใช่ระยะเวลาทั้งหมดของการแสดงความคิดเห็นสำหรับการเปลี่ยนแปลงหนึ่งๆ เนื่องจากรอบการแสดงความคิดเห็นที่มีอยู่ (ซึ่งนานกว่ามาก) จะยังคงดำเนินต่อไป กระบวนการให้คําปรึกษาจะเสนอกรอบเวลาใหม่อย่างเป็นทางการสําหรับความคิดเห็นภายในกระบวนการที่มีอยู่สําหรับการตัดสินใจเชิงกลยุทธ์แทน ดังนั้น บุคคลที่สามจะยังคงสามารถให้ข้อมูลผ่านฟอรัมต่างๆ (รวมถึง GitHub, W3C และหน่วยงานด้านมาตรฐานโฆษณา เช่น IAB Tech Lab) ในระหว่างการพัฒนาฟีเจอร์ต่อไป การจัดโครงสร้างรอบความคิดเห็นด้วยวิธีนี้ช่วยให้ระบบนิเวศมีโอกาสวิเคราะห์และแชร์มุมมองเกี่ยวกับการเปลี่ยนแปลงที่เสนอโดยไม่มีการชะลอกระบวนการพัฒนาอย่างมีนัยสำคัญ
การกำกับดูแล	ขอรายละเอียดเกี่ยวกับแผนการจัดการในอนาคต	สรุปรูปแบบการกํากับดูแลที่เสนอระบุไว้ในรายงานไตรมาสที่ 2/3 ปี 2024 ของ CMA (หน้า 3-5 ที่นี่)
คำขอยกเว้น	ขอรับการยกเว้นเพื่อเข้าถึงคุกกี้ของบุคคลที่สาม (3PC) สําหรับผู้ใช้ที่ให้ความยินยอม	การให้ความยินยอมในการเข้าถึงอุปกรณ์และพื้นที่เก็บข้อมูลเพื่อวัตถุประสงค์ในการประมวลผลข้อมูลบางอย่างไม่ได้หมายความว่าผู้ใช้ต้องการลบล้างการตั้งค่า 3PC ใน Chrome การอนุญาตให้ลบล้างการตั้งค่า 3PC ของผู้ใช้ที่ระดับเว็บไซต์จะทำให้เกิดความเสี่ยงสูงต่อการใช้งานในทางที่ผิด และ Chrome จะไม่สามารถตรวจสอบลักษณะการทำงานของเว็บไซต์ทั้งหมดที่อาจนำไปสู่การขอการยกเว้นได้
Privacy Sandbox	ขอราคาอัตราค่าสมัครใช้บริการ Privacy Sandbox API	เราไม่มีแผนที่จะแชร์ข้อมูลนี้กับระบบนิเวศ นักพัฒนาซอฟต์แวร์สามารถเรียกใช้ API ที่ตนมีโค้ดที่ติดตั้งใช้งานอยู่ในปัจจุบันเพื่อประเมินความพร้อมให้บริการของ Privacy Sandbox API
ช่วงทดลองใช้จากต้นทาง	มีแผนที่จะขยายช่วงทดลองใช้ต้นทางไหม	ช่วงทดลองใช้จากต้นทางขยายเวลาไปจนถึงวันที่ 14 เมษายน 2025
Privacy Sandbox	ขอคำอธิบายสั้นๆ เกี่ยวกับ Privacy Sandbox ที่ไม่เกี่ยวข้องกับเทคนิค ซึ่งจะไฮไลต์คุณค่าทางธุรกิจและช่วยให้ผู้บริหารยอมรับ	เมื่อเร็วๆ นี้เราได้เพิ่มส่วนแหล่งข้อมูลทางธุรกิจลงใน privacysandbox.com ที่นี่ ซึ่งให้ข้อมูลนี้
โหมด B	เมื่อเบราว์เซอร์อยู่ใน "โหมด B" คุกกี้ Jar ปัจจุบัน (1PC, 3PC, พื้นที่เก็บข้อมูลในเครื่อง) จะยังคงอยู่หรือถูกลบออก	ระบบจะไม่ล้างคุกกี้ปัจจุบัน 3PC จะยังคงเข้าถึงได้ในบริบทของบุคคลที่หนึ่ง
แนวทางที่อัปเดตสำหรับ 3PC ใน Chrome	ในอนาคตเราจะนำ 3PC ออกจาก Chrome ทั้งหมดไหม	เราขอเสนอแนวทางที่อัปเดตซึ่งจะเพิ่มทางเลือกให้กับผู้ใช้ ตามที่ได้ระบุไว้ที่นี่ เราจะเปิดตัวประสบการณ์การใช้งานแบบใหม่ใน Chrome แทนการเลิกใช้งาน 3PC ซึ่งจะช่วยให้ผู้ใช้มีทางเลือกที่รอบรู้ซึ่งใช้ได้กับการท่องเว็บ และผู้ใช้จะปรับตัวเลือกดังกล่าวได้ทุกเมื่อ เรากำลังหารือเกี่ยวกับเส้นทางใหม่นี้กับหน่วยงานกำกับดูแล และจะมีส่วนร่วมกับอุตสาหกรรมก่อนเปิดตัว
การทดสอบ Chrome	คำขอป้ายกำกับการทดสอบที่ดำเนินการโดย Chrome (Chrome Facilitated Testing) ใช้งานได้ต่อไป	ทีม Privacy Sandbox เข้าใจดีว่าบริษัทต่างๆ ต้องการใช้ป้ายกํากับการเลิกใช้งานคุกกี้ต่อไป กระบวนการขยายเวลาความพร้อมใช้งานของป้ายกํากับจะคล้ายกับขยายเวลาช่วงทดลองใช้จากต้นทาง ในกระบวนการนี้ การทดสอบจะขยายเวลาได้สูงสุด 3 ระยะของ Chrome ต่อครั้ง ตัวอย่างเช่น เจตนาที่จะขยายการทดสอบ (I2EE) ล่าสุดของ Chrome สำหรับป้ายกำกับการเลิกใช้งานคุกกี้ได้ขยายเวลาสำหรับ Chrome M130-M132 แล้ว ซึ่งจะช่วยให้รองรับป้ายกำกับดังกล่าวได้จนกว่าจะมีการเปิดตัว M133 เวอร์ชันเสถียรในช่วงต้นเดือนกุมภาพันธ์ ส่วนส่วนขยายเพิ่มเติมจะทำงานผ่านขั้นตอนเดียวกันนี้ เราจึงขอแนะนำให้ติดตามข้อมูลอัปเดตในกลุ่มอีเมล blink-dev

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

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

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

หัวข้อ

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ข้อกำหนด	โมเดลการจัดประเภทแชร์ระหว่าง Android (ตามชื่อแอป) กับ Chrome (ตามชื่อโฮสต์) ไหม	ไม่ โฆษณา Search และโฆษณา Display เป็นโมเดลแยกกันเนื่องจากมีการจัดหมวดหมู่ต่างกัน
รายละเอียดของการจัดหมวดหมู่ Topics	หัวข้อมีความกว้างเกินไปที่จะมีประโยชน์เมื่อใช้ร่วมกับข้อมูลจากบุคคลที่หนึ่ง	การจัดหมวดหมู่ Topics มุ่งเน้นที่การสร้างความสมดุลระหว่างประโยชน์และความเป็นส่วนตัว แม้ว่าเราจะได้ประเมินกลไกที่เป็นไปได้ในการทำให้ Topics มีความเฉพาะเจาะจงมากขึ้น แต่สุดท้ายเราก็ตัดสินใจที่จะไม่ทำเช่นนั้นเนื่องจากข้อกังวลด้านความปลอดภัยและความเป็นส่วนตัว รวมถึงข้อกังวลอื่นๆ เทคโนโลยีโฆษณาสามารถปลดล็อกผลลัพธ์ที่ดีที่สุดได้ด้วยการรวมเครื่องมือที่มีทั้งหมดเข้าด้วยกัน เช่น แมชชีนเลิร์นนิงและสัญญาณที่ไม่ละเมิดความเป็นส่วนตัวจาก Privacy Sandbox API รวมถึงข้อมูลตามบริบท ข้อมูลครีเอทีฟโฆษณา และข้อมูลจากบุคคลที่หนึ่ง ดูคำแนะนำเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ที่นี่
การใช้ API	Topics API มีความครอบคลุมต่ำ	สาเหตุทั่วไปของความครอบคลุมต่ำ ได้แก่ - การควบคุม/การเลือกไม่ใช้ของผู้ใช้ - การควบคุม/การเลือกไม่ใช้ของผู้เผยแพร่โฆษณา - การมีสิทธิ์ของเว็บไซต์ (เว็บไซต์ต่อไปนี้ไม่ได้รับอนุมัติให้จับคู่กับ Topics: เว็บไซต์ที่ไม่ปลอดภัย, WebView, Chrome ใน iOS และโหมดไม่ระบุตัวตน) - ข้อจํากัดของผู้ใช้ (ผู้ใช้ Chrome ที่มีอายุต่ำกว่า 18 ปีหรือใช้โหมดไม่ระบุตัวตนจะไม่สามารถสังเกตการณ์และกำหนด Topics ได้) - ข้อกําหนดในการสังเกตการณ์ของผู้ขาย (ผู้โทรต้องเคยเห็นผู้ใช้ในเว็บไซต์ที่เชื่อมโยงกับ Topics ที่มีสิทธิ์) - ความใหม่ของการใช้งาน (ใช้เวลาประมาณ 4 สัปดาห์ในการเพิ่มจำนวนผู้โทรที่สังเกตการณ์)
การใช้ API	ขอข้อมูลเกี่ยวกับการใช้ Topics API เนื่องจากแท็บการทํางานของเครือข่ายดูเหมือนจะแสดงว่ามีการส่งและจับการเรียก แต่ chrome://topics-internals/ ไม่ได้แสดงการบันทึกผู้สังเกตการณ์	เมื่อใช้กลไกส่วนหัว HTTP เพื่อโต้ตอบกับ Topics API ระบบจะส่งหัวข้อในส่วนหัวคำขอ Sec-Browsing-Topics แต่ระบบจะสังเกตหัวข้อก็ต่อเมื่อเซิร์ฟเวอร์ตอบกลับด้วยส่วนหัวการตอบกลับ Observe-Browsing-Topics: ?1 เท่านั้น โปรดดูรายละเอียดเพิ่มเติมที่นี่
การมีส่วนร่วมใน Chromium	สำหรับเดสก์ท็อป Chrome จะแชร์บริบทการสังเกตการณ์และการจัดอันดับเดียวกันกับเบราว์เซอร์อื่นๆ ที่ใช้ Chromium ไหม สำหรับอุปกรณ์เคลื่อนที่ Chrome บน Android จะแชร์บริบทการสังเกตการณ์และการจัดอันดับเดียวกันกับเบราว์เซอร์อื่นๆ บน Android ที่ใช้ Chromium / Chromium ในแอปไหม	Chrome จะไม่แชร์ข้อมูล Topics กับเบราว์เซอร์อื่นๆ ในอุปกรณ์
ข้อกำหนด	Topics API พิจารณาอย่างไรว่าหน้าเว็บที่ผู้ใช้ดูถือเป็น "รายการประวัติหัวข้อ" หรือไม่	การเข้าชมหน้าเว็บต้องมีคอล "observe" (มาจากผู้เรียกใดก็ได้) จึงจะมีสิทธิ์รับการคำนวณหัวข้อรายสัปดาห์ หากไม่มีการเรียกใช้ "สังเกตการณ์" ระบบจะไม่พิจารณาการเข้าชมนั้นสำหรับประวัติหัวข้อ
ความปลอดภัย	Topics API ป้องกันไม่ให้ผู้โทรรายหนึ่งเห็นหัวข้อที่สังเกตของผู้โทรรายอื่นได้อย่างไร	เรามีคำอธิบายไว้ที่นี่
การจัดหมวดหมู่	ระบบใช้การจัดหมวดหมู่โครงสร้างต้นไม้ภายใน Topics API ในการสังเกตการณ์ในแต่ละยุคอย่างไร	เมื่อคํานวณหัวข้อ 5 อันดับแรก ระบบจะพิจารณาเฉพาะหัวข้อเดิมที่ได้จากตัวแยกประเภท และการจัดอันดับจะพิจารณาจาก (1) ความถี่ในการเข้าชมหน้าเว็บ และ (2) คะแนนการจัดลําดับความสําคัญ (ดูข้อกําหนด) เมื่อคำนวณหัวข้อที่ผู้ใช้เห็นของแต่ละหัวข้อใน 5 อันดับแรก ระบบจะรวมผู้ใช้ที่เห็นหัวข้อหลักหรือหัวข้อย่อยของหัวข้อนั้นๆ ด้วย
ข้อกำหนด	ขอข้อมูลเพิ่มเติมเกี่ยวกับสัญญาณรบกวนแบบสุ่ม 5% ในคำตอบ	แต่ละ Epoch จะมีหัวข้อยอดนิยม 5 หัวข้อเสมอ หากประวัติการท่องเว็บมีหัวข้อไม่ถึง 5 หัวข้อ ระบบจะสุ่มเลือกหัวข้อจนกว่าจะครบ 5 หัวข้อ เราเรียกหัวข้อเหล่านี้ว่าหัวข้อที่มีการเพิ่ม ผู้เรียกใช้จะไม่ได้รับการเพิ่มหัวข้อแบบสุ่มเหล่านี้ เว้นแต่ว่าผู้เรียกใช้จะสังเกตเห็น (เรียกใช้ API) ผู้ใช้ในเว็บไซต์ที่มีหัวข้อดังกล่าวในช่วง 2-3 สัปดาห์ที่ผ่านมา เมื่อเรียกใช้ API ระบบจะคํานวณแฮชต่อผู้ใช้ ต่อเว็บไซต์ ต่อยุค หากแฮชนั้นน้อยกว่าความน่าจะเป็นที่จะแสดงหัวข้อที่มีการรบกวน ระบบจะเลือกหัวข้อแบบสุ่มต่อผู้ใช้ ต่อเว็บไซต์ ต่อ Epoch เพื่อแสดง อย่างไรก็ตาม ระบบจะแสดงหัวข้อที่มีสัญญาณรบกวน (เช่น ไม่กรอง) เฉพาะในกรณีที่ผู้เรียกใช้สังเกตเห็นหัวข้อที่เกี่ยวข้องที่ไม่มีสัญญาณรบกวนสำหรับผู้ใช้/เว็บไซต์/ช่วงเวลานั้น (ดูคำอธิบาย) การกรองนี้ช่วยให้มั่นใจได้ว่าระบบจะแสดงหัวข้อที่มีเสียงรบกวน 5% ของเวลาสําหรับผู้เรียกสายหนึ่งๆ โดยไม่คำนึงถึงความสามารถในการสังเกต
ข้อกำหนด	หัวข้อที่ซ้ำกันข้ามสัปดาห์ทำงานอย่างไร API เลือกข้อมูลแต่ละสัปดาห์แยกกัน แล้วผสานข้อมูลเข้าด้วยกันใช่ไหม	ระบบจะคํานวณหัวข้อของสัปดาห์ (หรือยุค) แต่ละสัปดาห์แยกกัน หัวข้อที่เลือกให้แสดงจากแต่ละ Epoch จะขึ้นอยู่กับเว็บไซต์ที่ผู้เรียกใช้อยู่ เราไม่คำนึงถึงว่าหัวข้ออาจซ้ำกันในแต่ละยุคสําหรับผู้โทรหนึ่งๆ (และควรพิจารณาเลือกหัวข้ออื่น) แต่เรายินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้ที่นี่

Protected Audience API

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การทดสอบ A/B	โซลูชันพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งอธิบายไว้ที่นี่จะเพิ่มเวลาในการตอบสนองและมีอัตราความล้มเหลวสูง (กล่าวคือ การเข้าชมส่วนใหญ่จะจบลงโดยไม่มีรหัสประชากร) รหัสที่มีความผันผวนต่ำ (เช่น 3 บิต) ก็เพียงพอสำหรับการทดสอบ A/B ที่มีประสิทธิภาพโดยไม่ส่งผลกระทบต่อความเป็นส่วนตัวอย่างมีนัยสำคัญ	เราเชื่อว่าโซลูชันพื้นที่เก็บข้อมูลที่ใช้ร่วมกันยังคงเป็นแนวทางที่ใช้งานได้ แต่เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศหากฟีเจอร์นี้เป็นสิ่งสําคัญมาก
การรายงาน	ขอบิตเพิ่มเติมใน reportWin() โดยเฉพาะอย่างยิ่งเมื่อเข้าใจว่าการรายงานการคลิกและการแสดงผลแบบใหม่ใน PA API จะใช้บิต 6-8 บิต ซึ่งจะลดบิตที่เหลือสำหรับการรายงาน PA API อื่นๆ อย่างมีประสิทธิภาพ	เราจะไม่พิจารณาเพิ่มจำนวนบิตของ modelingSignals เกิน 12 บิตที่ใช้อยู่ในปัจจุบันอีกต่อไปเนื่องจากข้อกังวลด้านความเป็นส่วนตัว เราขอเชิญชวนให้ระบบนิเวศแสดงความคิดเห็นเกี่ยวกับข้อเสนอการฝึกโมเดลแบบส่วนตัวของเรา ซึ่งมีจุดประสงค์เพื่อรองรับความต้องการด้านการฝึก ML ในสภาพแวดล้อมที่ปลอดภัยโดยไม่มีขีดจํากัดของบิตตามข้อกําหนดของ Privacy Sandbox
กลุ่มความสนใจ	ขอวงจรชีวิตของกลุ่มความสนใจ (IG) เป็น 90 วัน เนื่องจาก 30 วันนั้นไม่เพียงพอ	ตามที่ได้แจ้งไว้ในบล็อกโพสต์ เรามีแผนที่จะขยายอายุของ IG เป็น 90 วัน และเราได้จัดทำคำอธิบายไว้ที่นี่ ขณะนี้เรากําลังดําเนินการเพื่อติดตั้งใช้งาน และจะแชร์ลําดับเวลาการเปิดตัวเมื่อพร้อม
กลุ่มความสนใจ	ขอการอัปเดตแบบไดนามิกสำหรับการมอบสิทธิ์ IG	เราทราบถึงคำขอนี้จากผู้มีส่วนเกี่ยวข้องหลายรายและกำลังหาวิธีแก้ปัญหา เราจะแชร์ข้อมูลอัปเดตใน GitHub ขณะพัฒนาฟีเจอร์นี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
ในอุปกรณ์	แสดงให้เห็นถึงคุณค่าเพิ่มเติมสําหรับระบบนิเวศเพื่อลงทุนในโซลูชัน PA API ในอุปกรณ์ต่อไป	ทีม Privacy Sandbox ยังคงพัฒนา API ที่ใช้เทคโนโลยีเพื่อความเป็นส่วนตัว (PET) ซึ่งรวมถึง PA API เพื่อมอบตัวเลือกการรักษาความเป็นส่วนตัวเพิ่มเติมในเบราว์เซอร์ให้แก่นักพัฒนาซอฟต์แวร์ โดยทั่วไปแล้ว เทคโนโลยีเหล่านี้พร้อมใช้งานในเบราว์เซอร์ Chrome จำนวนมากแล้วในตอนนี้ (ไม่ใช่แค่ 1% ตามที่นักพัฒนาแอปบางรายเข้าใจผิด) ไม่ว่าผู้ใช้จะเปิดใช้ 3PC หรือไม่ นักพัฒนาซอฟต์แวร์อาจเลือกที่จะรวมโซลูชันที่อิงตาม PET ไว้ในผลิตภัณฑ์ของตน เช่นเดียวกับที่บริษัทจํานวนมากเลือกใช้โซลูชันอื่นๆ ที่อิงตาม PET นอกเบราว์เซอร์ นักพัฒนาแอปจํานวนมากได้รับประโยชน์จากการลงทุนในโซลูชัน PA API ในอุปกรณ์อยู่แล้ว โดยการขยายสัญญาณกลุ่มเป้าหมายบุคคลที่หนึ่งที่แน่นอนเพื่อปรับปรุงการเข้าถึงในเว็บไซต์ต่างๆ เราเข้าใจดีว่านักพัฒนาแอปบางรายจะเลือกใช้ Privacy Sandbox API หรือโซลูชันอื่นๆ ที่ใช้ PET เฉพาะในกรณีที่มีการปิดใช้ 3PC เพิ่มเติม และนักพัฒนาแอปเหล่านี้กำลังรอข้อมูลที่จะทําให้คาดการณ์ได้ว่าเบราว์เซอร์จํานวนเท่าใดที่จะเก็บ 3PC ไว้ เราตระหนักดีว่านักพัฒนาแอปเหล่านั้นจะรอจนกว่าจะพบข้อมูลที่ตนต้องการเพื่อตัดสินใจเกี่ยวกับผลิตภัณฑ์
กลุ่มความสนใจ	อนุญาตให้ SSP มีส่วนร่วมในการสร้าง IG และบทบาทที่เกี่ยวข้องกับ IG SSP มองว่านี่เป็นส่วนสําคัญของมูลค่าเพิ่ม และต้องการช่วยให้ผู้เผยแพร่โฆษณาขาย IG ผ่าน SSP ได้	เราได้รับคําขอให้รองรับการมอบสิทธิ์ IG ขั้นสูงขึ้นจากผู้มีส่วนเกี่ยวข้องหลายราย และเราเห็นคุณค่าที่เพิ่มขึ้นของ SSP ที่มีส่วนร่วมในกระบวนการนี้ เรากําลังค้นคว้าหาวิธีแก้ปัญหาที่ดีที่สุดซึ่งช่วยให้บุคคลต่างๆ มีส่วนร่วมในกระบวนการขยายกลุ่มเป้าหมาย เราจะแชร์ข้อมูลอัปเดตใน GitHub ขณะพัฒนาฟีเจอร์นี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การรายงาน	ความคลาดเคลื่อนของจํานวนรายงาน "ราคาเสนอที่ไม่ใช่ 0" ระหว่าง forDebuggingOnly กับ Private Aggregation API	เราคาดว่าความคลาดเคลื่อนจะเกิดขึ้นเนื่องจากสาเหตุ 2 ข้อ ดังนี้ ประการแรก โหมดแก้ไขข้อบกพร่องของ Private Aggregation API จะพร้อมใช้งานก็ต่อเมื่อมี 3PC ที่อนุญาตในอุปกรณ์เท่านั้น ส่วน forDebuggingOnly API จะพร้อมใช้งานแบบไม่สุ่มตัวอย่างเสมอ (ลักษณะการทำงานสุดท้ายนี้จะเปลี่ยนแปลงในท้ายที่สุดตามที่อธิบายไว้อย่างละเอียดที่นี่) ประการที่ 2 Private Aggregation API มีขีดจํากัดการมีส่วนร่วม ขณะที่ forDebuggingOnly ไม่มี อย่างไรก็ตาม ความคิดเห็นนี้บ่งชี้ว่าอาจมีสิ่งอื่นที่ทำให้เกิดความคลาดเคลื่อนที่ไม่คาดคิด และเรากำลังทำงานร่วมกับผู้มีส่วนเกี่ยวข้องบุคคลที่สามเพื่อแก้ไขปัญหานี้
ความสามารถในการดึงดูดให้คลิก	ดังที่กล่าวไว้ในข้อเสนอฉบับปรับปรุงสำหรับสัญญาณคลิก ระบบจะบันทึกยอดดูและการคลิกโดยการส่งส่วนหัวการตอบกลับ HTTP ใหม่ไปยังคำขอที่เริ่มต้นโดยแอตทริบิวต์ "attributionsrc" ที่มีสิทธิ์" และส่วนหัวการตอบกลับนี้จะมีรายการแหล่งที่มาซึ่งสามารถใช้เพื่อระบุว่าบุคคลอื่นใดสามารถรวมยอดดูและการคลิกเหล่านี้ไว้ในจํานวนรวมได้ หมายความว่าเทคโนโลยีโฆษณาสามารถกำหนดต้นทางโดยพลการได้ใช่ไหม	มีการระบุไว้ในคำอธิบายความน่าสนใจของคลิกว่าเทคโนโลยีโฆษณาที่ส่งเหตุการณ์การดูหรือคลิกไปยังยอดดูและจำนวนคลิกที่รวบรวม ("ต้นทางที่ระบุ") อาจมีพารามิเตอร์ที่ไม่บังคับที่มีส่วนหัวคำตอบ ซึ่งช่วยให้ระบุ "ต้นทางเจ้าของ IG อย่างน้อย 1 รายการที่เหตุการณ์นี้อาจรวมอยู่ในยอดดูและจำนวนคลิกที่คำนวณแล้วซึ่งจะส่งไปยังการเรียกใช้ generateBid() ในการประมูลกลุ่มเป้าหมายที่มีการป้องกัน" ("ต้นทางที่มีสิทธิ์") อย่างไรก็ตาม การดูและการคลิกเหล่านี้จะไม่รวมอยู่ในจํานวนการดูและการคลิกโดยอัตโนมัติ แต่เทคโนโลยีโฆษณาแต่ละรายต้องระบุชุด "ต้นทางที่ระบุ" ใน IG ของตนว่าควรรวมเหตุการณ์การดูและการคลิกจากต้นทางใด และเฉพาะข้อมูลจากต้นทางที่ระบุเหล่านี้เท่านั้นที่จะมีสัดส่วนในจํานวนการดูและการคลิกที่แสดงในการเรียก generateBid() ของเทคโนโลยีโฆษณานั้น กลไกนี้กำหนดให้ทั้ง 2 ฝ่ายทำข้อตกลง และป้องกันไม่ให้ผู้ไม่ประสงค์ดีมีอิทธิพลต่อยอดดูและจำนวนคลิกสำหรับเทคโนโลยีโฆษณาอื่นๆ และยังหมายความว่าเทคโนโลยีโฆษณาที่ "ให้ข้อมูล" ซึ่งตั้งค่า "ต้นทางที่มีสิทธิ์" โดยพลการจะไม่ส่งผลต่อยอดดูและการคลิกของต้นทางที่มีสิทธิ์เหล่านั้น เว้นแต่ต้นทางที่มีสิทธิ์เหล่านั้นจะระบุแหล่งที่มาที่ให้ข้อมูลนั้นไว้ใน IG อย่างชัดเจนและตั้งใจ
การฝึกโมเดลส่วนตัว	ในบางกรณี DP-SGD (Differential Privacy - Stochastic Gradient Descent) อาจทําให้กระบวนการฝึกช้าลงอย่างมาก เนื่องจากจะทำลายความเบาบางของ Gradient ที่คำนวณระหว่าง Backprop มีเทคนิคใดที่อยู่ระหว่างการพิจารณาเพื่อจัดการกับปัญหานี้หรือความคิดเห็นเกี่ยวกับข้อกังวลนี้ไหม	เราทราบเทคนิคบางอย่างในการรักษาความเบาบางใน DP-SGD (เช่น เทคนิคนี้) และกำลังพิจารณาที่จะรองรับเทคนิคประเภทนี้ในโครงสร้างพื้นฐานการฝึกโมเดลส่วนตัว เราจะแชร์ข้อมูลอัปเดตเมื่อการพัฒนาดำเนินไป และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การกําหนดเป้าหมายเชิงลบ	ขอข้อมูลอัปเดตเกี่ยวกับการเปิดตัวฟังก์ชันการกรองเนื้อหาเชิงลบของ IG ที่อธิบายไว้ที่นี่	ตามที่ได้ระบุไว้ในคําตอบที่นี่ เรามีแผนที่จะรองรับ IG เชิงลบในการเสนอราคา PA API เราจะแชร์ลำดับเวลาการเปิดตัวเมื่อพร้อมใช้งาน และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การเสนอราคา	ฉันจะรวม IG หลายรายการเมื่อเสนอราคาได้ไหม	ซึ่งปัจจุบัน PA API ยังไม่สามารถทำได้ PA API ออกแบบมาเพื่อให้ IG เชื่อมโยงกับข้อมูลของผู้ใช้ที่เว็บไซต์หนึ่งๆ ทราบ ซึ่งถือเป็นหัวใจสําคัญในการพูดคุยกับระบบนิเวศโดยรวม แนวทางนี้ช่วยให้ AdTech สร้างโซลูชันที่หลากหลายซึ่งช่วยให้ผู้ลงโฆษณาขยายกลุ่มเป้าหมายบุคคลที่หนึ่งของตนไปทั่วทั้งเว็บได้ เราทราบดีว่าข้อเสนอ Ads Selection API ของ Microsoft เสนอการออกแบบที่แตกต่างออกไป โดยกลุ่มเป้าหมายจะอิงตามข้อมูลจากเว็บไซต์ต่างๆ แม้ว่าเราจะติดตามแนวทางของ Google ต่อไป แต่เราต้องการเห็นการพูดคุยเพิ่มเติมจากระบบนิเวศ รวมถึงชุมชนด้านความเป็นส่วนตัว ก่อนที่จะพิจารณาทำการเปลี่ยนแปลงที่คล้ายกันใน Chrome
โฆษณาเนทีฟ	ข้อกังวลเกี่ยวกับ PA API ว่าจะรองรับรูปแบบและข้อกําหนดการแสดงผลที่หลากหลายของโฆษณาเนทีฟอย่างเพียงพอหรือไม่ และ PA API จะช่วยให้ครีเอทีฟโฆษณามีความยืดหยุ่นและการเพิ่มประสิทธิภาพที่จําเป็นสําหรับการโฆษณาเนทีฟที่มีประสิทธิภาพหรือไม่	เรากําลังหาวิธีรองรับโฆษณาเนทีฟเพิ่มเติมและยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การรายงาน	คำขอปรับปรุงความเสถียรของสคริปต์การรายงานซึ่งแย่งทรัพยากรกับสคริปต์การเสนอราคาและอาจหายไปเมื่อออกจากกรอบการประมูลที่ทำงานอยู่	เราหวังว่าจะโพสต์คำตอบใน GitHub เร็วๆ นี้ แต่เราไม่คิดว่าข้อกังวลเหล่านี้จะส่งผลต่อความถูกต้องในการรายงานในทางปฏิบัติอย่างมีนัยสำคัญ
การเปลี่ยนมาโคร	การแทนที่มาโครที่ส่งผ่านการกำหนดค่าการประมูลไม่ทำงานกับการกําหนดค่าของบุคคลที่สามบางรายการ	สาเหตุหลักคือการเข้าชมที่ติดป้ายกํากับโหมด A/B บางรายการไม่ได้เปิดใช้ฟีเจอร์นี้ เมื่อเร็วๆ นี้เราตัดสินใจที่จะเปิดใช้ฟีเจอร์นี้ (และฟีเจอร์อื่นๆ ในสถานการณ์เดียวกัน) ในการเข้าชมที่ติดป้ายกํากับ "โหมด A/B" ทั้งหมด เราคาดว่าจะทำการเปลี่ยนแปลงนี้ในช่วงไตรมาสที่ 1 ปี 2025 เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
เอกสารประกอบ	ขอคำชี้แจงเนื่องจากดูเหมือนว่าเอกสารประกอบจะมีความคลาดเคลื่อนเกี่ยวกับหน่วยวัดของค่าความใหม่ในออบเจ็กต์ browserSignals ภายใน generateBid()	เราได้ตอบกลับเรื่องนี้โดยละเอียดแล้วที่นี่ และอัปเดตเอกสารประกอบของเราให้สอดคล้องกับเรื่องนี้ คำตอบที่ถูกต้องคือหน่วยวัดคือมิลลิวินาที
การรายงาน	คำขอการรายงานของบุคคลที่สาม แม้ว่า DSP และ SSP จะได้รับข้อความแจ้งการแสดงผลจาก Chrome แต่ผู้ให้บริการด้านเทคนิคระดับกลางจะไม่ได้รับโดยค่าเริ่มต้น	ขณะนี้เรากำลังพูดคุยเกี่ยวกับคำขอฟีเจอร์นี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
กลุ่มความสนใจ	ขอคําแนะนําเกี่ยวกับวิธียกเว้น interestGroupBuyers แบบไดนามิกเมื่อใช้เวิร์กโฟลว์การประมูล IG แบบขนาน	เรามีคำแนะนำเกี่ยวกับเรื่องนี้ที่นี่
โฆษณาเนทีฟ	การประมูล PA API อิสระสำหรับการโหลดหน้าเว็บหนึ่งๆ จะป้องกันไม่ให้กรองโฆษณาในหน้าเดียวกัน	การรองรับโฆษณาเนทีฟเพิ่มเติม รวมถึงวิดเจ็ตคำแนะนำที่เรียกว่า "เนทีฟ" และมีโฆษณาหลายรายการในหน่วยเดียว เป็นเรื่องที่เรากําลังศึกษาอยู่และเราทราบว่าการออกแบบปัจจุบันอาจไม่รองรับการกรองโฆษณาในหน้าเดียวกัน และการป้องกันอื่นๆ เช่น เฟรมที่มีรั้วล้อมอาจป้องกันปัญหานี้เพิ่มเติมได้
โฆษณาเนทีฟ	ฟีเจอร์ PA API ที่มีอยู่ เช่น การสแกนครีเอทีฟโฆษณา การรายงาน ฯลฯ ที่ต้องอาศัยสัญญาณที่อิงตาม URL อาจต้องปรับเปลี่ยนเพื่อจัดการออบเจ็กต์ JSON ที่ใช้กับครีเอทีฟโฆษณาเนทีฟ	การรองรับโฆษณาเนทีฟเพิ่มเติมเป็นพื้นที่การวิจัยที่กําลังดำเนินอยู่ และเรากําลังประเมินความเป็นไปได้ในการปรับ PA API เพื่อสนับสนุนการแสดงโฆษณาเนทีฟ
การยืนยันโฆษณา	ความปลอดภัยของแบรนด์บุคคลที่สามใน PA API จะได้รับผลกระทบเนื่องจากเวลาในการตอบสนองและข้อจํากัดในการแคชของ perBuyerSignals ซึ่งจะทําให้เกิดปัญหากับเนื้อหาแบบไดนามิก	เราตระหนักดีว่า SSP และ DSP จำเป็นต้องกำหนด TTL ที่เหมาะสมสำหรับการแคชเพื่อรักษาสมดุลระหว่างเป้าหมายด้านการกำหนดปริมาณการเข้าชมและ TTL สูงสุดเพื่อความปลอดภัยของแบรนด์ เพื่อให้ข้อมูลที่แคชไว้ยังคงมีความเกี่ยวข้องกับความปลอดภัยของแบรนด์ เรากำลังตรวจสอบปัญหานี้และจะแชร์ข้อมูลอัปเดตเมื่อปัญหาได้รับการแก้ไข
การยืนยันโฆษณา	SSP จำเป็นต้องใช้การเปลี่ยนมาโคร FullpageURL เพื่อทำการวัดความปลอดภัยของแบรนด์หลังการเสนอราคา	deprecatedReplaceInURN เป็นคําแนะนําปัจจุบันสําหรับ SSP ในการส่งสัญญาณนี้
การยืนยันโฆษณา	รูปแบบมาโครที่ SSP ใช้สำหรับการยืนยันหลังการเสนอราคาที่ไม่มีมาตรฐานอาจทำให้เกิดความไม่สอดคล้องและข้อผิดพลาดในการประมวลผลและวิเคราะห์ข้อมูล	SSP และโปรแกรมตรวจสอบโฆษณาควรทํางานร่วมกันโดยตรงเพื่อกําหนดหลักเกณฑ์และข้อกําหนดเฉพาะที่ชัดเจนสําหรับการใช้มาโคร เพื่อผลักดันมาตรฐานรูปแบบมาโครใน SSP ต่างๆ เพื่อให้เกิดความสอดคล้องกันและป้องกันข้อผิดพลาดในการประมวลผลและการวิเคราะห์ข้อมูล ซึ่งเป็นกิจกรรมที่องค์กรด้านมาตรฐานโฆษณาอย่าง IAB Tech Lab เหมาะที่จะดำเนินการ
การยืนยันโฆษณา	ผู้ลงโฆษณาและผู้ตรวจสอบโฆษณาต้องมีกลไกในการลิงก์การตรวจสอบก่อนการเสนอราคาและหลังการเสนอราคาสำหรับบริบทของผู้เผยแพร่โฆษณาเดียวกันเพื่อแก้ไขข้อบกพร่องและแก้ปัญหา	ตัวเลือกหนึ่งสำหรับการยืนยันหลังการเสนอราคาคือผ่านสัญญาณที่อิงตามการประมูลและแคมเปญซึ่งรวมอยู่ในการรายงานระดับเหตุการณ์ ซึ่งอาจเปิดใช้การรวมกับบันทึกการตัดสินใจก่อนการเสนอราคา เรากำลังสำรวจรูปแบบที่เป็นไปได้ในการบรรลุเป้าหมายนี้ และจะแชร์ข้อมูลอัปเดตเมื่อการพัฒนาดำเนินไป
การยืนยันโฆษณา	คำขอสํารวจโซลูชันเซิร์ฟเวอร์คีย์-ค่าที่เชื่อถือได้ (TKV) (ของ DSP และของโปรแกรมตรวจสอบโฆษณา) สําหรับการเสนอราคาก่อนการเสนอราคา และการแก้ไขข้อจํากัดของเฟรมที่มีรั้วล้อมสําหรับการเสนอราคาหลังการเสนอราคา	เรากําลังประเมินคําขอนี้และยินดีรับความคิดเห็นเพิ่มเติมจากระบบนิเวศที่นี่เพื่อค้นหาโซลูชันที่รองรับความปลอดภัยของแบรนด์ก่อนการเสนอราคา และลดความซับซ้อนของข้อกําหนดในการประสานงานระหว่างฝ่ายต่างๆ
โฆษณาเนทีฟ	คำขอตรวจสอบการแสดงผลหลังการเสนอราคาฝั่งขายสําหรับโฆษณาเนทีฟ	การสนับสนุนโฆษณาเนทีฟเพิ่มเติมเป็นหัวข้อที่กําลังอยู่ในระหว่างการวิจัย และเรากําลังพิจารณาปรับใช้ฟีเจอร์ที่มีอยู่ เช่น ฟีเจอร์นี้ เพื่อสนับสนุนการแสดงโฆษณาเนทีฟ

การประมูลที่มีการป้องกัน (บริการ B&A)

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
เวลาในการตอบสนอง	มีการลดเวลาในการตอบสนองไม่เพียงพอ แม้ว่าบริการ B&A อาจช่วยลดปัญหานี้ได้ในระยะยาว แต่ Google ไม่ได้ให้สัญญาว่าจะให้บริการนี้อย่างแพร่หลายก่อนการเปลี่ยนแปลง 3PC ใน Chrome	เราได้ทําการปรับปรุงเวลาในการตอบสนองในอุปกรณ์หลายอย่างในช่วงไม่กี่ไตรมาสที่ผ่านมา นอกจากนี้ เรายังสร้างและปรับขนาดบริการถามและตอบตามความจำเป็น เมื่อเร็วๆ นี้ เราได้อัปเดตคู่มือแนวทางปฏิบัติแนะนำเกี่ยวกับเวลาในการตอบสนองซึ่งมีข้อมูลเพิ่มเติมเกี่ยวกับวิธีใช้ประโยชน์จากฟีเจอร์เหล่านี้ นอกจากนี้ เรายังพัฒนาการปรับปรุงเวลาในการตอบสนองใหม่ๆ อย่างต่อเนื่อง ซึ่งบางส่วนดูได้ที่นี่
(รายงานในไตรมาสก่อนหน้าด้วย) การรักษาความปลอดภัยในการประมูล	คำขอคำชี้แจงเพิ่มเติมเกี่ยวกับแนวทางการป้องกัน/ลดการพยายามแทรกแซงการประมูลในอุปกรณ์ (เช่น Google พิจารณาว่านี่เป็นความเสี่ยงที่สำคัญหรือไม่)	คำตอบของเราไม่มีการเปลี่ยนแปลงจากไตรมาสก่อนหน้า "กลไกการรายงานของโฆษณา PA API จะเก็บข้อมูลที่ใช้แยกความแตกต่างระหว่างการเข้าชมจากผู้ใช้กับการเข้าชมจากบ็อตไว้ในปัจจุบัน นอกจากนี้ คุณยังใช้เทคนิคปัจจุบันในการรวมหรือยกเว้นโดเมนตามโดเมนใน PA API ได้ ซึ่งอธิบายไว้อย่างละเอียดในการตอบกลับรายงานของ IAB Tech Lab เกี่ยวกับ Privacy Sandbox"
โซลูชันในองค์กร	ข้อกังวลเกี่ยวกับการที่ผู้ให้บริการรายใหญ่ที่สุดอาจไม่ใช้ Privacy Sandbox หรือ B&A เนื่องจากไม่มีการสนับสนุนระบบคลาวด์ส่วนตัว และแผนงานการสนับสนุนที่ยาวนานและคลุมเครือ	เรามุ่งมั่นที่จะขยายโครงสร้างพื้นฐานที่บริการ Privacy Sandbox ทำงานอยู่ โดยเมื่อเร็วๆ นี้เราได้ประกาศการรองรับระบบคลาวด์ Azure และยังคงตรวจสอบโซลูชันที่เป็นไปได้เพื่อมอบการปกป้องความเป็นส่วนตัวและความปลอดภัยที่คล้ายกันสำหรับระบบคลาวด์ส่วนตัว นับตั้งแต่การแจ้งข้อมูลเมื่อเดือนตุลาคม เราได้ดำเนินการวิจัยแนวทางต่างๆ ที่เป็นไปได้เพื่อรักษาความเป็นส่วนตัวของผู้ใช้ Chrome ในสภาพแวดล้อมการทำงานที่เชื่อถือได้ (TEE) ในเครื่องต่อไป ตอนนี้เราอยู่ในจุดที่เราต้องการตรวจสอบแนวทางต่างๆ กับผู้มีส่วนเกี่ยวข้องในระบบนิเวศ และวางแผนที่จะเริ่มรวบรวมข้อมูลในไตรมาสที่ 1 ความคิดเห็นและการทำงานร่วมกันในระบบนิเวศจะช่วยปรับแต่งโซลูชันที่เป็นไปได้
การทดสอบ	ฉันจะสร้าง TEE เพื่อทดสอบโซลูชันการรายงาน PA API (การรายงานแบบเรียลไทม์และการรวมข้อมูลส่วนตัว) ได้ไหม	สําหรับการทดสอบบริการรวบรวมข้อมูล ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาสามารถใช้ข้อมูลทดสอบและเครื่องมือการทดสอบในเครื่องเพื่อสร้างรายงานสรุปสําหรับการทดสอบฟังก์ชันการทำงาน โปรดดู Codelab การทดสอบในพื้นที่ที่นี่ หากต้องการทดสอบการรวมข้อมูลใน TEE ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาจะต้องทําตามขั้นตอนการลงทะเบียนให้เสร็จสมบูรณ์ตามที่ระบุไว้ในข้อกําหนดเบื้องต้นของ Codelab ด้านบน เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับคำขอนี้ ที่นี่
การผสานรวมคีย์/ค่าของดีล	ขอความสามารถในการดึงข้อมูลตามดีลจาก KV สำหรับกรณีการใช้งานทางธุรกิจ	เรากำลังประเมินคำขอฟีเจอร์นี้และจะแจ้งข้อมูลอัปเดตใน GitHub
การวัดผลดีลแบบไม่มีผู้ชนะ	การขอสัญญาณหรือความสามารถในการทําความเข้าใจเมื่อ SSP ไม่ได้เป็นผู้ชนะและสาเหตุ	เรากำลังประเมินคำขอนี้และจะแจ้งข้อมูลอัปเดตใน GitHub
คำขอฟีเจอร์	ส่งคําขอให้ Privacy Sandbox ระบุโครงสร้างพจนานุกรมเพื่อช่วยจับคู่กลุ่มโฆษณากับชุดรหัสดีลที่เกี่ยวข้อง	เรากำลังประเมินคำขอนี้ควบคู่ไปกับวิธีอื่นๆ ในการจัดการกับขนาด IG เกี่ยวกับการจัดเก็บรหัสดีล เราจะแจ้งข้อมูลอัปเดตใน GitHub
ประสิทธิภาพ	โซลูชันในการวัดโอกาสในการประมูลโฆษณาที่อาจพลาดไป ซึ่งอาจเกิดจากขนาดสคริปต์การเสนอราคา	เรากำลังประเมินคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ข้อกำหนด	ปัจจุบัน B&A จะอ่านเฉพาะช่อง prevWins แทนช่อง prevWinMs ล่าสุดที่เข้ามาแทนที่ prevWins ในข้อกำหนด	ถูกต้องแล้วที่ B&A ไม่ได้ส่งระยะเวลาเป็นมิลลิวินาทีใน prevWins ไปยัง generatebid() Chrome ส่งระยะเวลาเป็นวินาทีเพื่อให้มีภาระงานน้อยลง วิธีการแก้ไขคือให้ B&A แปลงจากวินาทีเป็นมิลลิวินาที B&A จะระบุทั้ง prevWins และ prevWinsMs ใน browserSignals เพื่อให้เข้ากันได้กับการประมูลในอุปกรณ์ โปรดทราบว่าแม้สำหรับการประมูลในอุปกรณ์สําหรับเว็บ prevWins และ prevWinsMs จะเป็นค่าเดียวกันและ prevWinsMs = prevWins * 1000 เรากำลังหาวิธีแก้ไขอยู่
เอกสารประกอบ	เอกสารประกอบไม่ชัดเจนเกี่ยวกับวิธีทดสอบ Seller Front End (SFE) จึงควรมีคำแนะนำการทดสอบเพิ่มเติมทันทีหลังจากการทำให้ใช้งานได้เสร็จสมบูรณ์ รวมถึงวิธีใช้ Bazel สำหรับบิลด์	Codelab นี้เผยแพร่เพื่อเป็นแนวทางให้ระบบนิเวศในวงกว้างทดสอบ SFE ได้ง่ายขึ้น
การทำให้ใช้งานได้	มีแผนที่จะจัดเตรียมไบนารีที่สร้างไว้ล่วงหน้าสําหรับ B&A ไหม	เรากำลังพิจารณาที่จะจัดหาไบนารีที่สร้างไว้ล่วงหน้าสำหรับ B&A แต่ยังไม่มีลำดับเวลาที่แน่ชัด ในระหว่างนี้ เทคโนโลยีโฆษณาสามารถสร้างไบนารีด้วยตนเองและตรวจสอบโดยใช้แฮชที่ระบุ
การทำให้ใช้งานได้	ควรรองรับการประสานงานทุกประเภท (เซิร์ฟเวอร์ ไคลเอ็นต์ แบบผสม) หรือควรให้ความสำคัญกับประเภทใดมากกว่าประเภทอื่นๆ	เราไม่มีคําแนะนําที่เจาะจงเกี่ยวกับโหมดที่เทคโนโลยีโฆษณาใช้ ตัวเลือกนี้ขึ้นอยู่กับปัจจัยหลายอย่าง แต่สุดท้ายแล้วขึ้นอยู่กับสิ่งที่เป็นประโยชน์ต่อลูกค้ามากที่สุด
การทดสอบ	ขอคำชี้แจงเกี่ยวกับการทดสอบที่ไม่สําเร็จระหว่างการสร้าง B&A	ปัญหานี้อาจเกิดจากผลการทดสอบที่ไม่เสถียร เราได้แนะนําให้เทคโนโลยีโฆษณาใช้ Flag --no-tests กับคําสั่งสร้าง build_and_test_all_in_docker ทั้งหมดเพื่อข้ามการเรียกใช้การทดสอบ
บันทึก	ขอคำชี้แจงว่าเหตุใดบันทึกในเครื่องมือสำรวจบันทึกใน GCP จึงติดแท็กกับอินสแตนซ์ VM ที่เรียกใช้ SFE เมื่ออยู่ในโหมดทดสอบ แต่ไม่ได้ติดแท็กบันทึกกับอินสแตนซ์ VM ในโหมดเวอร์ชันที่ใช้งานจริง	เป็นเรื่องยากที่จะสรุปโดยทั่วไปเนื่องจากขึ้นอยู่กับสิ่งที่เห็น แต่โดยทั่วไปแล้ว - บันทึกจาก non_prod อาจเป็นบันทึก stderr ที่ผู้ให้บริการระบบคลาวด์เปลี่ยนเส้นทาง (ในกรณีนี้คือ GCP) และ GCP เพิ่มแท็ก - โดยทั่วไปแล้ว บันทึกที่ VM สร้างขึ้นจะมีแท็กอินสแตนซ์ VM ส่วนบันทึกที่ไบนารีสร้างขึ้นจะไม่มีแท็กจาก GCP - บันทึกจาก prod ส่งออกโดย Open Telemetry ใน TEE ซึ่งมีแท็กต่างกัน รายละเอียดบางส่วนของสิ่งที่มีอยู่ใน non_prod และ prod มีดังนี้
B&A	ข้อผิดพลาด 403 เกี่ยวกับข้อมูลลับที่ขาดหายไปเมื่อปิดใช้การบันทึก OTEL	ปัญหานี้ได้รับการแก้ไขแล้วในการอัปเดต 4.1 และเอกสารประกอบได้รับการแก้ไขตามความเหมาะสม
B&A	ไฟล์ outputs.tf สำหรับการกำหนดค่า Terraform ของ GCP ขาดหายไปจึงทำให้เกิดข้อผิดพลาด	ซึ่งตอนนี้ปัญหาได้รับการแก้ไขแล้ว
การทดสอบ	เกิดข้อผิดพลาดเมื่อดึงข้อมูลคีย์ส่วนตัวในโหมดทดสอบ	ในกรณีเหล่านี้ โปรดตรวจสอบว่าเซิร์ฟเวอร์ทำงานด้วย TEST_MODE=true ดูคำอธิบายที่นี่
แผนการใช้งาน	มีแผนที่จะให้ getInterestGroupAdAuctionData ยอมรับต้นทางผู้ขายมากกว่า 1 รายการและแสดงผลแผนที่ของต้นทางผู้ขายเป็นข้อความที่เข้ารหัสของเพย์โหลด B&A ไหม	ได้ เราวางแผนที่จะเพิ่มการรองรับเพื่อให้ navigator.getInterestGroupAdAuctionData() ยอมรับผู้ขายหลายราย
ข้อกำหนด KV	KV URL (trustedScoringSignalsURL) สามารถส่งเป็นสัญญาได้ไหม	ดูคำอธิบายที่ระบุไว้ที่นี่
B&A	ขอสร้างส่วนหัวแพลตฟอร์มใหม่เพื่อแจ้งให้ฝั่งผู้ขาย B&A ทราบว่าไคลเอ็นต์ (เบราว์เซอร์) ต้องการความสามารถใดบ้างเพื่อให้เกิดการประมูลส่วนตัว	ขณะนี้เรากำลังพูดคุยเกี่ยวกับคำขอฟีเจอร์นี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การกำหนดรูปแบบการเข้าชม	ข้อเสนอเพื่อลดค่าใช้จ่ายที่เพิ่มขึ้นจากโฮสติ้งเซิร์ฟเวอร์ B&A โดยเฉพาะสำหรับ DSP	เรากำลังพูดคุยเกี่ยวกับข้อเสนอนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
Bring-Your- Own-Binary	ลองอัปเดตคำอธิบายเพื่อให้ชัดเจนว่ารองรับไบนารีทั้งหมด	เราได้อัปเดตข้อมูลแล้ว โปรดดูคำอธิบายที่นี่
การโทร KV	generateBid() รอให้คําเรียกร้านค้าคีย์-ค่า (KV) ทั้งหมดเสร็จสิ้นหรือทํางานอย่างอิสระ การรวม KV ส่งผลต่อเวลาในการดำเนินการอย่างไร	ดูคำอธิบายที่ระบุไว้ที่นี่
ประสิทธิภาพ	ขอเอกสารประกอบเพิ่มเติมเกี่ยวกับการใช้สคริปต์การเสนอราคาซ้ำและการแนะนําให้ตั้งค่าส่วนหัวการควบคุมแคชในสคริปต์	เราได้เพิ่มเอกสารประกอบไว้ที่นี่
ประสิทธิภาพ	ขอให้พิจารณาและสำรวจความสามารถในการโหลดทรัพยากร (เช่น สคริปต์การเสนอราคา) แบบไม่พร้อมกันเพื่อลดเวลาในการตอบสนองของการประมูลในอุปกรณ์	ขณะนี้เรากำลังพูดคุยเกี่ยวกับคำขอฟีเจอร์นี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การบันทึกความยินยอม	ต้องมีการชี้แจงเกี่ยวกับข้อผิดพลาดที่พบเมื่อพยายามใช้การบันทึกความยินยอมโดยการตั้งค่า CONSENTED_DEBUG_TOKEN	ในกรณีเหล่านี้ ให้ตรวจสอบว่า CONSENTED_DEBUG_TOKEN อยู่ในเครื่องมือจัดการข้อมูลลับ ตั้งค่า ENABLE_OTEL_BASED_LOGGING เป็น true และตั้งค่า TELEMETRY_CONFIG เป็น mode: PROD ดูคำอธิบายที่นี่ซึ่งอ้างอิงแหล่งที่มาที่นี่
บันทึก	เหตุการณ์ forDebuggingOnly พร้อมใช้งานผ่าน B&A ไหม	forDebuggingOnly สำหรับ B&A พร้อมใช้งานสำหรับการประมูลของผู้ขายรายเดียวตั้งแต่เดือนเมษายน 2024 เราวางแผนที่จะเปิดใช้ฟีเจอร์นี้สำหรับการประมูลแบบผู้ขายหลายรายในเร็วๆ นี้
บันทึกของ Worklet	คำขอทําให้การบันทึกของ Worklet เข้ากันได้กับ ChromeDriver	เรากำลังประเมินคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่

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

การรายงานการระบุแหล่งที่มา (และ API อื่นๆ)

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
รายงานการแก้ไขข้อบกพร่อง	รายงานการแก้ไขข้อบกพร่องของ ARA จะพร้อมใช้งานสําหรับนักเทคโนโลยีโฆษณาอย่างไรเมื่อใช้แนวทางที่อัปเดตแล้วสําหรับ 3PC ใน Chrome เทคโนโลยีโฆษณาควรมีสิทธิ์เข้าถึงรายงานการแก้ไขข้อบกพร่อง ARA สําหรับผู้ใช้ที่เก็บ 3PC ไว้และเปิดใช้ Privacy Sandbox API อยู่ไหม	เทคโนโลยีโฆษณาจะมีสิทธิ์เข้าถึงโซลูชันการแก้ไขข้อบกพร่องแบบใช้คุกกี้และแบบไม่ใช้คุกกี้สำหรับผู้ใช้ที่เปิดใช้ทั้ง 3PC และ ARA เมื่อปิดคุกกี้ ผู้ใช้จะมีสิทธิ์เข้าถึงเฉพาะโซลูชันแก้ไขข้อบกพร่องแบบรวม ดูรายละเอียดเพิ่มเติมเกี่ยวกับวิธีแก้ไขข้อบกพร่องได้ที่นี่และที่นี่
การตรวจจับองค์ประกอบ	ขอคําแนะนําเกี่ยวกับวิธีตรวจหาฟีเจอร์สําหรับ ARA ในฝั่งเซิร์ฟเวอร์	ปัจจุบันการรองรับฟีเจอร์ ARA จะระบุได้โดยใช้เวอร์ชัน Chrome ที่แสดงในสตริง User Agent เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศนี้
คำขอฟีเจอร์	ขอให้ source_registration_time ที่ใช้ใน shared_info แบบรวมของ ARA มีความละเอียดมากขึ้น เช่น ปัดเศษลงเป็น 1 ชั่วโมงหรือ 1 นาที (แทนที่จะเป็น 1 วัน) รวมถึงกําหนดค่าให้พิจารณาเขตเวลาได้ด้วย (ปัจจุบันมีเพียง UTC)	การปัดเศษฟิลด์ source_registration_time เป็นวันที่ที่ใกล้ที่สุดเป็นกลไกด้านความเป็นส่วนตัวที่ใช้ในการลดความสามารถของเทคโนโลยีโฆษณาในการเชื่อมโยงผู้ใช้ที่เฉพาะเจาะจงกับการลงทะเบียนแหล่งที่มาที่เฉพาะเจาะจง ปัจจุบัน source_registration_time จะอิงตามเขตเวลา UTC และเทคโนโลยีโฆษณาสามารถปรับรายงานโฆษณาเพื่อพิจารณาเรื่องนี้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศเกี่ยวกับคำขอนี้ที่นี่
ข้อกำหนด	คำขอชี้แจงข้อกำหนดของ "trigger_data" และ "priority" โดยเฉพาะเมื่อใช้กับค่าอาร์เรย์	ช่องเหล่านี้ไม่ยอมรับค่าอาร์เรย์ วงเล็บเหลี่ยมในคำอธิบายไม่ได้แสดงอาร์เรย์ แต่บ่งบอกว่าข้อความไม่ใช่ค่าตัวอย่าง แต่เป็นตัวยึดตำแหน่งที่มีคำอธิบาย ดังที่ข้อความในวงเล็บเหลี่ยมบอกไว้ - trigger_data เป็น int-64 - priority เป็น int-64 ที่มีเครื่องหมาย ทั้ง 2 ช่องไม่ยอมรับค่าอาร์เรย์ นอกจากนี้ คุณยังควรพิจารณาใช้เครื่องมือตรวจสอบส่วนหัวสําหรับ ARA เพื่อทดสอบค่าต่างๆ และดูว่ามีข้อผิดพลาดหรือไม่หากเอกสารประกอบมีความสับสน
การรองรับโฆษณา Accelerated Mobile Pages (AMP)	ARA รองรับโฆษณา AMP ไหม	คุณสามารถดูข้อเสนอเกี่ยวกับวิธีที่เรารองรับ AMP ที่นี่ และเรายินดีรับฟังความคิดเห็นเพิ่มเติม
ข้อกำหนด	ระบบจะถือว่า URL ใดเป็น "source-site" สําหรับโฆษณาแบบฝังหลายเลเยอร์สําหรับ ARA	URL จากเว็บไซต์ระดับบนสุด
(รายงานในไตรมาสก่อนหน้าด้วย) คำขอฟีเจอร์	ขอให้ลดค่าต่ำสุดของ event_report_window จาก 3600 วินาที (1 ชั่วโมง) เป็น 1800 วินาที (30 นาที)	การกำหนดกรอบเวลาการรายงานขั้นต่ำต้องพิจารณาถึงความสมดุลระหว่างประโยชน์และความเป็นส่วนตัว กรอบเวลาการรายงานขั้นต่ำ 1 ชั่วโมงสําหรับรายงานระดับเหตุการณ์มีความจําเป็นเพื่อรักษาความเป็นส่วนตัวและลดการโจมตีแบบสร้างประวัติขึ้นมาใหม่บางประเภท เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับคำขอนี้ที่นี่
เสียงรบกวน	ต้องการทําความเข้าใจเพิ่มเติมเกี่ยวกับวิธีใช้สัญญาณรบกวนในรายงานระดับเหตุการณ์ ARA เพื่อให้แน่ใจว่าการตีความและการใช้ข้อมูลมีความแม่นยำ	ดูรายละเอียดเพิ่มเติมได้ที่นี่และที่นี่
การรายงาน	shared_info ของรายงานสรุปจะไม่มี source_registration_time โดยค่าเริ่มต้นอีกต่อไป	การเปลี่ยนแปลงนี้เกิดจากการเปลี่ยนแปลง API และมีการระบุรายละเอียดเพิ่มเติมไว้ที่นี่
การรายงาน	filtering_id ไม่อยู่ในแท็บ "รายงานที่รวบรวมได้" ของ UI chrome://attribution-internals/	ขณะนี้ filtering_id จะแสดงในรายละเอียดแท็บ "การลงทะเบียนทริกเกอร์" เมื่อคุณคลิกแถว ซึ่งจะช่วยให้คุณยืนยันความถูกต้องได้ เราทราบดีว่าการแสดงข้อมูลดังกล่าวในแท็บ "รายงานที่รวบรวมได้" มีประโยชน์เพียงใด และเราได้จัดการเรื่องนี้แล้วที่นี่
แหล่งที่มาของการระบุแหล่งที่มา	ขอคำชี้แจงเกี่ยวกับวิธีการทำงานของแหล่งที่มาของการระบุแหล่งที่มา	ดูคำอธิบายได้ที่นี่
การระบุแหล่งที่มาจากแอปไปยังเว็บ	คำขอคำแนะนำสำหรับการติดตั้งใช้งานในกรณีที่ไม่แน่ใจว่าแหล่งที่มาจะเป็นระบบปฏิบัติการหรือเว็บ	ดูคำแนะนำได้ที่นี่

บริการรวมข้อมูล

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
คำขอฟีเจอร์	ขอการหมดเวลาที่กําหนดค่าได้สําหรับ AgS และ/หรือการแสดงสถานะงานเพิ่มเติมสําหรับการทํางานในระยะยาว	เรากำลังพิจารณาฟีเจอร์เพื่อรองรับการตรวจสอบงานที่ทำงานต่อเนื่องเป็นเวลานาน เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศนี้
Terraform	Terraform พยายามแก้ไขนโยบาย IAM ของบัญชีแม้ว่าจะไม่ได้ตั้งค่า service_account_token_creator_list ก็ตาม	นักพัฒนาแอปสามารถเพิ่มสิทธิ์ที่เพิ่มลงในไฟล์ modules/adtech_setup/main.tf ในพื้นที่
คำขอเอกสารประกอบ	การขอเอกสารประกอบหรือ Codelab ที่อธิบายวิธีตรวจสอบประสิทธิภาพของบริการรวบรวมข้อมูล	ดูคำอธิบายของสัญญาณเตือนที่มีอยู่ซึ่งสามารถใช้ตรวจสอบบริการและสถานะงานได้ในไฟล์ Terraform ของผู้ให้บริการที่เกี่ยวข้อง (alarms.tf และ monitoring.tf) ในที่เก็บข้อมูล coordinator-services-and-shared-libraries เราจะเผยแพร่เอกสารประกอบและคำแนะนำเพิ่มเติมเกี่ยวกับวิธีตรวจสอบงานบริการรวบรวมข้อมูล
การปรับสเกล	วิธีตรวจสอบปัญหาการปรับขนาด	เราได้เผยแพร่คำแนะนำนี้เวอร์ชันอัปเดต ซึ่งอธิบายบริการรวบรวมข้อมูลในระดับที่สูงขึ้น ขณะนี้ไม่มีสัญญาณโดยตรงที่บ่งบอกว่าเกิดข้อผิดพลาดขึ้นเนื่องจากเครื่องไม่รองรับขนาดของงาน สัญญาณโดยอ้อม ได้แก่ การใช้หน่วยความจํา 90% ก่อนเกิดความล้มเหลว งานที่ไม่สําเร็จซ้ำๆ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศเกี่ยวกับความจำเป็นในสัญญาณดังกล่าว
ข้อกำหนด	รันไทม์ทั่วไปของกลุ่มรายงาน AgS คือเท่าใด	โปรดดูคำแนะนำที่นี่

Private Aggregation API

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
คำขอฟีเจอร์	คำขออนุญาตให้มีส่วนร่วมของค่า float (รวมถึงค่าเชิงลบ) กับ contributeToHistogramOnEvent ที่มีความละเอียดอ่อน 2^16	เรากำลังพูดคุยเกี่ยวกับข้อเสนอนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม

จำกัดการติดตามแอบแฝง

การลด User Agent/คําแนะนําสําหรับไคลเอ็นต์ User Agent

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

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ตำแหน่งทางภูมิศาสตร์	คำขอไฟล์ตำแหน่งทางภูมิศาสตร์สำหรับการปกป้องทรัพย์สินทางปัญญา	ไฟล์การแมป IP กับตำแหน่งโดยประมาณสำหรับการปกป้อง IP มีอยู่ที่นี่ โปรดทราบว่าไฟล์นี้ได้รับการอัปเดตเป็นระยะ

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

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

เพิ่มความเข้มงวดให้กับขอบเขตความเป็นส่วนตัวข้ามเว็บไซต์

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
(รายงานในไตรมาสก่อนหน้าด้วย) ขีดจํากัดโดเมนของชุดเว็บไซต์ที่เกี่ยวข้อง (RWS)	ขีดจํากัดปัจจุบันของโดเมนที่เชื่อมโยง 5 รายการนั้นไม่เพียงพอที่จะบรรลุ Use Case การวัดผลข้ามเว็บไซต์	คำตอบของเราจะคล้ายกับในไตรมาสก่อน ปัจจุบันเรายังไม่คาดว่าจะเพิ่มขีดจำกัดตัวเลข ขีดจํากัดนี้กําหนดขึ้นโดยพิจารณาจากความเป็นส่วนตัวของผู้ใช้ ความคิดเห็นจากผู้มีส่วนเกี่ยวข้องในระบบนิเวศของ W3C และการพิจารณาการใช้งานที่เปรียบเทียบได้ ในเบราว์เซอร์อื่นๆ ดูข้อมูลเพิ่มเติมได้ในบล็อกโพสต์ (1, 2) เราขอแนะนําให้ตรวจสอบกรณีการใช้งานที่จําเป็นต้องใช้สิทธิ์เข้าถึงคุกกี้ข้ามเว็บไซต์เกินขีดจํากัดตัวเลข และพิจารณาใช้ประโยชน์จากคําแนะนําสําหรับกรณีการใช้งานเกี่ยวกับข้อมูลระบุตัวตน การฝังที่ตรวจสอบสิทธิ์แล้ว และกรณีการใช้งานเกี่ยวกับโฆษณา เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้ที่นี่

Fenced Frames API

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
โฆษณาเนทีฟ	การแสดงผลโฆษณาเนทีฟในเฟรมที่มีการป้องกันก่อให้เกิดปัญหาเนื่องจากมีการจำกัดการรับค่ารูปแบบของผู้เผยแพร่โฆษณาเนื่องจากข้อจำกัดในการสื่อสารระหว่าง iframe กับหน้าของผู้เผยแพร่โฆษณา	การรองรับเพิ่มเติมสําหรับโฆษณาเนทีฟ รวมถึงการรองรับหลังจากการบังคับใช้เฟรมที่มีรั้วล้อมเป็นพื้นที่การวิจัยที่กําลังดําเนินการ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้ที่นี่

Shared Storage API

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

CHIPS

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
คุกกี้ที่แบ่งพาร์ติชัน	การจัดการคุกกี้ในพอร์ต localhost ต่างๆ ใน Chrome และ Firefox ไม่สอดคล้องกัน โดยเฉพาะอย่างยิ่งเมื่อใช้แอตทริบิวต์ "แบ่งพาร์ติชัน"	Firefox จะถือว่า localhost ที่มีพอร์ตต่างกันเป็นคีย์พาร์ติชันที่แตกต่างกัน แม้ว่าลักษณะการทำงานนี้จะสอดคล้องกับหลักการด้านความปลอดภัย แต่ก็ไม่ได้เป็นไปตามข้อกำหนดและแนวทางของ Chrome เราคาดว่าจะพูดคุยเรื่องนี้กับเบราว์เซอร์อื่นๆ ในการสนทนาเกี่ยวกับข้อกำหนด HTML และจะแจ้งให้ระบบนิเวศทราบหากเรื่องนี้ส่งผลให้มีการเปลี่ยนแปลงคีย์พาร์ติชัน CHIPS เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้ที่นี่
คุกกี้ที่แบ่งพาร์ติชัน	ฉบับร่างของ Clear-Site-Data อนุญาตให้ล้างข้อมูลเกินพาร์ติชันของเว็บไซต์ที่ส่งออกอย่างไม่ถูกต้อง ซึ่งขัดแย้งกับการสนทนาก่อนหน้านี้ที่อ้างอิงไว้ที่นี่	ข้อผิดพลาดนี้อยู่ในเอกสารข้อกำหนดมาตรฐาน ซึ่งเราตั้งใจจะแก้ไขในเร็วๆ นี้ ลักษณะการทำงานที่ถูกต้องระบุไว้ในส่วนนี้ของคำอธิบาย และสอดคล้องกับลักษณะการทำงานที่สอดคล้องกับเบราว์เซอร์อื่นๆ ในที่เก็บคำอธิบายการแบ่งพาร์ติชันพื้นที่เก็บข้อมูล การติดตั้งใช้งาน Chrome ทำงานได้อย่างถูกต้องแล้ว

FedCM

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

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

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

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