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

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

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

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

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

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

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

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

ชิป

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

DSP

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

FedCM

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

FPS

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

IAB

สมาคมโฆษณาอินเทอร์แอกทีฟ (Interactive Advertising Bureau)

IdP

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

IETF

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

อินนิ่ง

ที่อยู่ Internet Protocol

openRTB

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

OT

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

PatCG

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

RP

ฝ่ายพึ่งพา

SSP

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

TEE

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

UA

สตริง User Agent

UA-CH

คำแนะนำไคลเอ็นต์ User Agent

W3C

World Wide Web Consortium

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

การตาบอด IP แบบจงใจ

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
การทดสอบและการทดลองใช้	ความเกี่ยวข้องของการทดสอบเพื่อแจ้งการประเมินของ CMA หาก Privacy Sandbox API ไม่เสร็จสมบูรณ์ก่อนถึงเวลาที่การทดสอบเริ่ม	การพัฒนา Privacy Sandbox API กำลังดำเนินไปอย่างรวดเร็ว ซึ่งพร้อมให้ใช้งานแล้วในช่วงทดลองใช้จากต้นทางสำหรับทดสอบ และโดยทั่วไปแล้วจะพร้อมให้บริการสำหรับการเข้าชมทั้ง 100% ในฤดูร้อนนี้ นอกจากนี้ เรายังได้ชี้แจงลำดับเวลาสำหรับฟีเจอร์บางอย่าง (เช่น การรายงานระดับเหตุการณ์ FLEDGE, การแสดงผล FLEDGE ด้วย iframe) ที่จะไม่ได้รับผลกระทบหลังปี 2026 เราขอแนะนำให้ระบบนิเวศทดสอบ API และให้ความคิดเห็นแก่ CMA โดยอิงตามสิ่งที่ผู้ทดสอบคาดว่าจะต้องใช้เมื่อเลิกใช้งานคุกกี้ของบุคคลที่สาม ซึ่งอาจส่งผลต่อการประเมินผลกระทบที่อาจเกิดขึ้นจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม
การควบคุมของผู้ใช้	คำแนะนำที่ชัดเจนเกี่ยวกับระบบนิเวศเกี่ยวกับผลกระทบด้านการควบคุมของผู้ใช้ของ Privacy Sandbox API	เราไม่สามารถให้คำแนะนำทางกฎหมายเกี่ยวกับสิ่งที่ผู้ใช้สามารถควบคุมที่ระบบนิเวศสามารถใช้ได้ ในขณะเดียวกัน Chrome กำลังทดสอบการแสดงส่วนควบคุม Privacy Sandbox ("นโยบายความเป็นส่วนตัวของโฆษณาขั้นสูง") ที่อัปเดตแก่ผู้ใช้ในเปอร์เซ็นต์ที่น้อยมาก ซึ่งเป็นส่วนหนึ่งของความพยายามอย่างต่อเนื่องในการปรับปรุงเทคโนโลยี Privacy Sandbox การอัปเดตจะมีภาษาและเลย์เอาต์ที่ชัดเจนและเป็นประโยชน์มากขึ้น เมื่อประเมินการปรับปรุงเหล่านี้และตัดสินใจว่าจะขยายการปรับปรุงให้ครอบคลุมจำนวนประชากรมากขึ้นหรือไม่ Chrome ก็จะแชร์ข้อมูลเพิ่มเติมกับระบบนิเวศได้
การรั่วไหลของข้อมูล	ความเสี่ยงในการรั่วไหลของข้อมูลจากบุคคลที่หนึ่งไปยัง Google และบริษัทอื่นๆ ในกรณีที่เบราว์เซอร์ถูกบุกรุก	คำอธิบาย FLEDGE ของเราแสดงให้เห็นว่าข้อมูลของเทคโนโลยีโฆษณาหนึ่งมีการแชร์กับเทคโนโลยีโฆษณาเดียวกันนั้นเท่านั้น (กับเวิร์กเล็ตหรือเซิร์ฟเวอร์ที่เชื่อถือได้) หรือเมื่อมีการแชร์อย่างชัดแจ้งโดยเทคโนโลยีโฆษณานั้น (เช่น ผู้ซื้อแสดง URL โฆษณาที่ผู้ขายต้องการแสดง) ข้อยกเว้นอย่างหนึ่งคือการตรวจสอบ k-anonymity จะต้องดำเนินการโดยเซิร์ฟเวอร์ส่วนกลางที่เป็นสากล ซึ่งเป็นพื้นที่ที่เรายังคงทุ่มเททรัพยากรที่สำคัญต่อไป ดูคำอธิบายเกี่ยวกับ K-anonymity เพื่อดูมุมมองโดยละเอียดเกี่ยวกับความคิดของเราเกี่ยวกับความเป็นส่วนตัว นอกจากนี้ เรายินดีที่จะให้รายละเอียดเพิ่มเติมเกี่ยวกับวิธีการทำงานของการป้องกันเทคโนโลยีโฆษณาในการออกแบบเซิร์ฟเวอร์ k-anonymity
ฟอรัมเพิ่มเติมสำหรับการสนทนา	ขอฟอรัมเพิ่มเติมไปยัง W3C เพื่อให้ผู้เล่นที่ดูแลระบบนิเวศที่ไม่ใช่ด้านเทคนิค แชร์ความคิดเห็น	แบบฟอร์มความคิดเห็นเกี่ยวกับ Privacy Sandbox เหมาะสำหรับความคิดเห็นทั่วไปและเฉพาะเจาะจง ทั้งในแง่เทคนิคและไม่ใช่เทคนิค การปรับปรุงกลุ่มธุรกิจการโฆษณาบนเว็บเป็นฟอรัมสำหรับการพูดคุยผ่านการโทรรายสัปดาห์และที่เก็บของ GitHub หน้าความคิดเห็นของ Privacy Sandbox ใน developer.chrome.com อธิบายกลไกอื่นๆ ในการแสดงความคิดเห็นและการมีส่วนร่วมในการสนทนา Chrome จะยังคงจัดกิจกรรมต่างๆ เช่น เวลาทำการสาธารณะ เพื่ออำนวยความสะดวกในการถามคำถามและแชร์เนื้อหา นอกจากนี้ Chrome ยังได้จัดหรือเข้าร่วมกิจกรรม ในวงการกว่า 10 งานในไตรมาสที่ผ่านมา
การชี้แจงไทม์ไลน์	การชี้แจงวันที่ที่แน่นอนสำหรับความพร้อมให้บริการทั่วไปในไตรมาสที่ 3 ปี 2023	ตามลำดับเวลาที่เผยแพร่ใน PrivacySandbox.com กำหนดให้ความพร้อมทั่วไปได้รับเป้าหมายเพื่อ เริ่มต้นการเปิดตัวพร้อมกับการเปิดตัว Chrome เวอร์ชัน 115
reCAPTCHA	ผลกระทบของ Sandbox API สําหรับ Use Case การตรวจจับสแปมของ reCATPCHA	เราได้รับความคิดเห็นจาก reCAPTCHA เป็นระยะๆ เพื่อให้มั่นใจว่าข้อเสนอ Privacy Sandbox จะไม่ส่งผลอย่างมากต่อความปลอดภัยของเว็บหรือการฉ้อโกง พวกเขากำลังพัฒนาแผนการของตนเองเพื่อเตรียมพร้อมและปรับการเลิกใช้งานคุกกี้ของบุคคลที่สาม พวกเขาจึงควรตอบคำถามนี้ได้ดีที่สุด
ส่วนขยาย Chrome	เทคโนโลยี Privacy Sandbox เช่น มาตรการ Anti Covert Tracking (ACT) จะมีผลกับส่วนขยาย Chrome ไหม	เรายังไม่ได้ประกาศใดๆ ว่า ACT สามารถใช้กับส่วนขยาย Chrome ได้ไหม อย่างไรก็ตาม หากเทคโนโลยีรวบรวมข้อมูลเกี่ยวกับผู้ใช้ โดยไม่เปิดเผย สิ่งนี้ไม่สอดคล้องกับหลักการด้านความเป็นส่วนตัวของเรา

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

หัวข้อ

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
ตรวจสอบการออกแบบแท็ก	TAG เผยแพร่การตรวจสอบการออกแบบขั้นต้นสำหรับหัวข้อ	เรายังคงมุ่งมั่นที่จะพัฒนา Topics และได้แชร์ข้อมูลอัปเดตเกี่ยวกับความมุ่งมั่นที่เรามีต่อ Topics ในหน้าอัปเดตล่าสุดและเกี่ยวกับปัญหานี้ เราตอบกลับทีละประเด็นเพื่อตรวจสอบ TAG และแชร์วิสัยทัศน์ระดับสูงที่นี่ Topics API จะยังคงเป็นส่วนหนึ่งของคอลเล็กชัน API ที่ระบบนิเวศของโฆษณาควรทดสอบในช่วงปี 2023 และหวังว่าความคิดเห็นในการทดสอบที่เราได้ยินและประสบการณ์ของผู้ติดตั้งใช้งานที่เราได้รับจะเป็นประโยชน์อย่างยิ่งต่อความพยายามในการปฏิบัติตามมาตรฐานข้ามเบราว์เซอร์ในอนาคตในพื้นที่นี้ เราหวังว่าจะมีส่วนร่วมกับระบบนิเวศนี้ต่อไปเกี่ยวกับวิธีลดความซับซ้อนของการเปลี่ยนรุ่นที่เป็นไปได้ โดย Topics API อาจเป็นมาตรฐานที่ตกลงกันเรื่องความสามารถในการทำงานร่วมกันข้ามเบราว์เซอร์
การจัดการ Topics	การสนับสนุนแนวทางแบบเปิดที่ Chrome มีในการพัฒนา Topics API	เรารู้สึกซาบซึ้งในความร่วมมือ และหวังว่าจะได้ร่วมงานกับกลุ่มอุตสาหกรรมเพื่อพัฒนา Topics API ที่มีคุณค่าต่อระบบนิเวศโดยรวมต่อไป
(มีการรายงานในไตรมาสที่ 3 ปี 2022 ด้วย) การจัดหมวดหมู่หัวข้อไม่ละเอียดเพียงพอ	การจัดหมวดหมู่หัวข้อแบบกว้างจะไม่รวมหัวข้อที่ละเอียดยิ่งขึ้น ซึ่งรวมถึงเฉพาะภูมิภาค	ข้อมูลอัปเดตในไตรมาสที่ 1: เรากำลังปรับปรุงการจัดหมวดหมู่อย่างต่อเนื่อง และในไตรมาสที่ 2 เราจะเปิดตัวการจัดหมวดหมู่ที่อัปเดตสำหรับ Topics API เราทำงานอย่างใกล้ชิดกับบริษัทต่างๆ จากทั่วทั้งระบบนิเวศเพื่อสร้างการจัดหมวดหมู่ใหม่นี้ เรายินดีรับฟังความคิดเห็นเกี่ยวกับการจัดหมวดหมู่ ซึ่งจะเป็นประโยชน์กับระบบนิเวศมากที่สุด ในการประเมินว่าจะขยายหัวข้อหรือรวมหัวข้อที่ละเอียดยิ่งขึ้นหรือไม่นั้น เราพิจารณา 2-3 ข้อ ได้แก่ 1) ผลกระทบด้านความเป็นส่วนตัวที่อาจเกิดขึ้น (หัวข้ออื่นๆ อาจทําให้เกิดความเสี่ยงในการเก็บลายนิ้วมือ) และ 2) ความสามารถในการดึงข้อมูลหัวข้อที่สังเกตก่อนหน้านี้ (เช่น เมื่อมีหัวข้อมากขึ้น เทคโนโลยีโฆษณาที่เคยเห็นหัวข้อที่เลือกไว้ในอดีตอาจน้อยลง)
(มีการรายงานในไตรมาสที่ 4 ปี 2022 ด้วย) ผลกระทบต่อสัญญาณของบุคคลที่หนึ่ง	สัญญาณของ Topics อาจมีค่าสูง จึงทําให้สัญญาณตามความสนใจของบุคคลที่หนึ่งอื่นๆ ลดลง	เราเชื่อว่าการโฆษณาตามความสนใจเป็นกรณีการใช้งานที่สำคัญสำหรับเว็บ และ Topics ได้รับการออกแบบมาเพื่อรองรับ Use Case นั้น เราเข้าใจว่าผู้เผยแพร่โฆษณารายใหญ่บางรายกังวลว่า Topics จะส่งผลเสียต่อกลยุทธ์ด้านข้อมูลจากบุคคลที่หนึ่ง เราจะคอยทดสอบระบบนิเวศ ซึ่งจะให้ข้อมูลเชิงลึกเกี่ยวกับผลกระทบที่ Topics มีต่อผู้เผยแพร่โฆษณา
กรณีการใช้งานของ Topics ที่ไม่เกี่ยวข้องกับโฆษณา	การใช้ Topics เพื่อจุดประสงค์อื่นนอกเหนือจากการแสดง การโฆษณาตามความสนใจ	Topics ออกแบบมาเพื่อระบุ Use Case การโฆษณาตามความสนใจ ซึ่งเราเชื่อว่าเป็น Use Case ที่สำคัญสำหรับเว็บแบบเปิดและไม่มีค่าใช้จ่าย ขณะนี้เรากำลังขอความคิดเห็นเกี่ยวกับกรณีการใช้งานอื่นๆ และกำลังประเมินผล
สถานะการเลือกใช้เริ่มต้น	ผลของนิติบัญญัติระดับภูมิภาคที่มีผลต่อค่าเริ่มต้นความยินยอมของ Topics	เราไม่ควรแสดงความคิดเห็นต่อความคิดเห็นทางกฎหมาย
(นอกจากนี้ยังมีการรายงานในไตรมาส 3 ปี 2022) เว็บไซต์ผิดหมวดหมู่	การกำหนดเป้าหมายโฆษณาเมื่อมีการจัดหมวดหมู่หัวข้อไม่ถูกต้องสำหรับเว็บไซต์หนึ่งๆ	ข้อมูลอัปเดตไตรมาสที่ 1: ในไตรมาสที่ 2 เราจะประกาศตัวแยกประเภทที่อัปเดตสำหรับ Topics API และหวังว่าจะได้มีส่วนร่วมกับระบบนิเวศในตัวนี้ เราจะจัดประเภทเว็บไซต์ตามความคิดเห็นในปัจจุบันของรายการการลบล้างที่ดูแลจัดการโดยมนุษย์ ซึ่งประกอบด้วยเว็บไซต์ยอดนิยมและโมเดล ML ในอุปกรณ์ Chrome จะยังคงประเมินตัวเลือกของเว็บไซต์ต่างๆ เพื่อนำมาใช้ในการจัดประเภทหัวข้อ การปรับปรุงยูทิลิตีใดๆ จะต้องคำนึงถึงความเสี่ยงด้านความเป็นส่วนตัวและการละเมิด ตัวอย่างเช่น ความเสี่ยงบางประการ ได้แก่ เว็บไซต์ที่ใช้การติดป้ายกำกับตัวเองเป็นวิธีการเข้ารหัสความหมายที่แตกต่างกัน (และอาจเป็นเรื่องละเอียดอ่อน) เป็นหัวข้อต่างๆ เว็บไซต์นำเสนอหัวข้อของตนเพื่อผลประโยชน์ทางการเงิน เว็บไซต์โจมตีหัวข้อของตนเพื่อหวังให้ผู้อื่นไม่มีประโยชน์ (เช่น การสแปมหัวข้อของผู้ใช้ด้วยเสียงรบกวนที่ไม่มีความหมาย) บุคคลทั่วไปสามารถตรวจสอบองค์ประกอบเหล่านี้ได้โดยใช้เครื่องมือผ่าน chrome://topics-internals หรือ Colab นี้ จากการทดสอบ เราคาดหวังว่าการจัดหมวดหมู่จะได้รับการปรับปรุงเมื่อเวลาผ่านไป และเรายินดีรับฟังความคิดเห็นเกี่ยวกับตัวอย่างเว็บไซต์ที่อาจจัดอยู่ในหมวดหมู่ที่ไม่ถูกต้อง
ตัวแยกประเภทหัวข้อ	ขอให้ส่งคืนข้อมูลเพิ่มเติมที่แสดงเหตุผลเมื่อข้อความ "ไม่มีหัวข้อ" แสดงให้ผู้โทรเห็นเพื่อแก้ไขข้อบกพร่อง	เราเข้าใจและชื่นชมที่เครื่องมือแก้ไขข้อบกพร่องมีประโยชน์สำหรับนักพัฒนาซอฟต์แวร์เนื่องจากผสานรวม Topics API เข้ากับระบบของตนได้ อย่างไรก็ตาม การแสดงข้อมูลเพิ่มเติม (เช่น เหตุผลที่ไม่แสดง Topics) เราอาจแชร์ข้อมูลที่ทำให้ผู้อื่นรับทราบรายละเอียดเพิ่มเติมโดยไม่ได้ตั้งใจ (เช่น หากผู้ใช้อยู่ในโหมดไม่ระบุตัวตน ปิดใช้ API ฯลฯ) ที่นอกเหนือจากจุดประสงค์ที่ตั้งใจจะส่งผลเสียต่อความเป็นส่วนตัวของผู้ใช้ แม้เราจะยังไม่มีแผนที่จะจัดหาเครื่องมือแก้ไขข้อบกพร่องเพิ่มเติมในตอนนี้ แต่เราก็ยินดีรับฟังความคิดเห็นว่าเครื่องมือใดจะเป็นประโยชน์
การดึงข้อมูลส่วนตัว (PIR)	คำขอ Topics API เพื่อใช้การดึงข้อมูลส่วนตัว	เราได้ตรวจสอบโดยใช้ PIR ก่อนหน้านี้แล้ว และได้แชร์ข้อดีข้อเสียไว้ที่นี่
สตรีมราคาเสนอ	หัวข้อจะได้รับการแสดงออกจากกลุ่มเป้าหมายที่ผู้ขายกำหนดอย่างชัดเจน ในการเสนอราคาหรือไม่	Topics API เป็นข้อเสนอ Privacy Sandbox ที่พัฒนาโดย Chrome ซึ่งแตกต่างจากข้อเสนอกลุ่มเป้าหมายที่ผู้ขายกำหนดของ IAB Tech Lab เราคาดว่ากลยุทธ์การเสนอราคาทั้งสองนี้จะมีการนำเสนออย่างชัดเจนภายในสตรีมการเสนอราคา ดูว่า Topics จะถูกนำเสนอในคำขอราคาเสนอ OpenRTB อย่างไร

Protected Audience API (ก่อนหน้านี้เรียกว่า FLEDGE)

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
ความพร้อมใช้งานของฟีเจอร์ FLEDGE	คำชี้แจงเกี่ยวกับไทม์ไลน์สำหรับการทดสอบและการใช้งานฟีเจอร์ FLEDGE เช่น การบังคับใช้ Fenced Frame, K-Anonymity ฯลฯ	เราได้แชร์บล็อกโพสต์เกี่ยวกับฟีเจอร์ FLEDGE ต่างๆ ที่มีขอบเขตและช่วงเวลาที่ระบบจะรองรับฟีเจอร์ดังกล่าว เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับประกาศนี้ในระหว่างที่เรากำลังพัฒนา FLEDGE อย่างต่อเนื่อง
ข้อจำกัดในการแสดงผลิตภัณฑ์	คำขอคลายโฆษณาที่ประกอบด้วยข้อจำกัดหลายชิ้นสำหรับเฟรมที่มีการปิดกั้น FLEDGE	ตามที่ได้ประกาศไปเมื่อเดือนกุมภาพันธ์ การใช้ Fenced Frames จะยังคงไม่บังคับจนถึงปี 2026 เป็นอย่างน้อย และ urn-iframe จะรองรับลักษณะการทำงานของ iframe เรายินดีรับการสนทนาเกี่ยวกับหัวข้อนี้เพิ่มเติม
ปัญหาเกี่ยวกับความสามารถในการปรับขนาด	ประสิทธิภาพของ FLEDGE ตามขนาดการใช้งาน	เรากำลังติดตามความคิดเห็นและทำความเข้าใจบริบทเพิ่มเติมอยู่เสมอเพื่อเสนอวิธีแก้ปัญหาที่นำไปใช้ได้จริง ขั้นตอนแรกคือการแยกความคิดเห็นออกเป็น 2 หมวดหมู่ ซึ่งเราได้ทำดังต่อไปนี้ การกรองที่ขับเคลื่อนโดย SSP เพื่อเพิ่มประสิทธิภาพการค้นหาต่อวินาที (QPS) จะโหลดทั้ง ก) เองและ ข) DSP ตรรกะ DailyUpdate ของกลุ่มความสนใจเพื่อเพิ่มประสิทธิภาพให้การโหลด QPS บน DSP
(มีการรายงานในไตรมาสที่ 3 ปี 2022 ด้วย) ระดับการเข้าถึงตรรกะการเสนอราคา	ข้อกังวลว่าตรรกะการเสนอราคา DSP จะแสดงใน JavaScript	ข้อมูลอัปเดตในไตรมาสที่ 1: เราได้แชร์ข้อเสนอที่จะจำกัดความสามารถของฝ่ายตรงข้ามในการขอข้อมูลจากเซิร์ฟเวอร์ในลักษณะการสำรวจ (บังคับให้ท่องเว็บ) และเรายินดีให้ผู้เล่นเกี่ยวกับระบบนิเวศแชร์ความคิดเห็นหรือการสนับสนุนข้อเสนอ
ความยากลำบากในการทดสอบ	ความสามารถสำหรับ DSP ขนาดเล็กในการทดสอบ FLEDGE อย่างเหมาะสม และลดความเสี่ยงที่ผู้ลงโฆษณาสนใจทดสอบกับ DSP ขนาดใหญ่เท่านั้น	เรามุ่งมั่นที่จะทำงานร่วมกับ DSP ขนาดเล็กและกระตุ้นให้มีการทดสอบเพิ่มเติมระหว่าง DSP และผู้ลงโฆษณาทุกขนาด เนื่องจาก FLEDGE ย้ายไปพร้อมให้บริการทั่วไป เราอยากทราบว่าจะช่วยเหลือคุณให้ดีที่สุดในการทดสอบ FLEDGE กับคนอื่นๆ ในระบบนิเวศได้อย่างไร รวมถึงยินดีรับฟังแนวคิดและความพยายามของอุตสาหกรรมที่จะกระตุ้นให้ผู้ลงโฆษณาทดสอบกับ DSP ขนาดเล็ก
รีมาร์เก็ตติ้งแบบไดนามิก	รีมาร์เก็ตติ้งแบบไดนามิกจะยังใช้ได้ใน FLEDGE หลังการเลิกใช้งานคุกกี้ของบุคคลที่สามไหม	เรากำลังพิจารณาตอบคำถามนี้และยินดีให้ผู้เล่นเกี่ยวกับระบบนิเวศมาแชร์ข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับวิธีที่พวกเขาตั้งใจจะใช้รีมาร์เก็ตติ้งแบบไดนามิก
การประพฤติมิชอบ/การละเมิด	ระบบนิเวศจะลดความเสี่ยงและยับยั้งผู้ไม่ประสงค์ดีหรือผู้ซื้อไม่ให้แสดงตัวเป็นกลุ่มเป้าหมายที่ต้องการได้อย่างไร	เราหวังว่าจะได้มีส่วนร่วมกับผู้เล่นในระบบนิเวศเพิ่มเติมเกี่ยวกับการประพฤติมิชอบและการละเมิด และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเรื่องนี้
ค่ากำหนดของผู้ใช้	ขั้นตอนการบันทึกค่ากำหนดของผู้ใช้และใช้ในการเลือกโฆษณา	สำหรับโฆษณาบางอย่าง เทคโนโลยีโฆษณาที่เกี่ยวข้องคือฝ่ายที่เหมาะสมที่สุดในการให้การควบคุมครีเอทีฟโฆษณาที่จะแสดงและวิธีเลือกครีเอทีฟโฆษณา
ข้อเสนอการทดสอบเชิงปริมาณ	สำหรับการทดสอบเชิงปริมาณอย่างเป็นธรรม คุณควรทำการทดสอบกับการเข้าชมโดยไม่ใช้คุกกี้ของบุคคลที่สามหรือ SSP ที่ใช้เพียง FLEDGE ไหม คุณจะหลีกเลี่ยงการผสมสัญญาณจากคุกกี้ของบุคคลที่สามได้อย่างไร	เราขอขอบคุณสำหรับความคิดเห็นนี้ และเรากำลังทำงานร่วมกับ CMA เพื่อออกแบบการทดสอบที่จะมอบภาพที่เชื่อถือได้ของผลกระทบจากการเลิกใช้งานคุกกี้ของบุคคลที่สามและการแนะนำข้อเสนอ Privacy Sandbox ในระบบนิเวศ เราขอแนะนำให้แชร์ความคิดเห็นเพิ่มเติมเกี่ยวกับข้อเสนอการทดสอบเชิงปริมาณของ CMA กับ CMA โดยตรง
เอกสารประกอบที่ชัดเจนยิ่งขึ้น	ขอเอกสารประกอบที่ชัดเจนยิ่งขึ้นเกี่ยวกับการกำหนดค่าการประมูล	เราหวังว่าจะได้แชร์บล็อกโพสต์ที่มีภาพรวมเพิ่มเติมเกี่ยวกับการรายงานการประมูลของ FLEDGE ในอีกไม่กี่สัปดาห์ข้างหน้า
โหลดพร้อมกัน	บริการการเสนอราคาและการประมูล (B&A) รองรับการโหลดพร้อมกันไหม	เทคโนโลยีโฆษณาที่ใช้เซิร์ฟเวอร์การเสนอราคา / การประมูลจะสามารถเริ่มต้นเซิร์ฟเวอร์หลายรายการที่แสดงผลลัพธ์พร้อมกันได้
การบรรเทาการละเมิด	เซิร์ฟเวอร์ k-anonymity ของ FLEDGE ที่ใช้โทเค็นสถานะส่วนตัวจะเพียงพอหรือไม่เพื่อรับรองความเป็นส่วนตัวของผู้ใช้	แรงจูงใจของ K-anonymity ไม่ค่อยมุ่งเน้นที่การกำหนดเป้าหมายขนาดเล็กและมีเวลาน้อยลงในช่วงที่ FLEDGE ช่วยให้มีการรายงานระดับเหตุการณ์ เราได้แชร์ความคิดเห็นเพิ่มเติมและยินดีรับความคิดเห็นเพิ่มเติม
โมดูล ES ขัดแย้งกัน	คำขอละเว้น generateBid เป็นฟังก์ชันส่วนกลางเนื่องจากขัดแย้งกับโมดูล ES	เรากำลังพูดคุยเกี่ยวกับคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติม
การประมูลคอมโพเนนต์	ขอให้ผู้เผยแพร่โฆษณาควบคุมรูปแบบการประมูลได้มากขึ้น	การเสนอราคาและแผนการประมูลรองรับการประมูลคอมโพเนนต์เช่นเดียวกับ Chrome ในอุปกรณ์
ไทม์ไลน์ของ B&A	ความชัดเจนของไทม์ไลน์สำหรับเทคโนโลยีโฆษณาที่สนใจการทดสอบเซิร์ฟเวอร์ B&A	เราเพิ่งอัปเดตคำอธิบายเกี่ยวกับ B&A และได้อัปเดตส่วนไทม์ไลน์ให้รวมคำจำกัดความที่ชัดเจนของไทม์ไลน์ของการทดสอบ Chrome-B&A ในระยะต่างๆ หลังจากให้สอดคล้องกับ CMA แล้ว
รูปแบบการควบคุมการหมดเวลา	การปรับปรุงรูปแบบการควบคุมระยะหมดเวลาที่พร้อมใช้งานสำหรับ FLEDGE	นี่เป็นข้อเสนอที่น่าสนใจ เราจะเพิ่มลงในคิวข้อเสนอที่จะศึกษา และรายงานการพัฒนาของเรา
สตรีมราคาเสนอของครีเอทีฟโฆษณา	ความสามารถในการตรวจสอบและกรองราคาเสนอที่ชนะโดยพิจารณาจากครีเอทีฟโฆษณา	นี่เป็นข้อเสนอที่น่าสนใจ เราจะเพิ่มลงในคิวข้อเสนอที่จะศึกษา และรายงานการพัฒนาของเรา
reportWin	ข้อเสนอเพื่อให้ข้อมูลเพิ่มเติมเกี่ยวกับราคาเสนอที่ได้คะแนนสูงสุดจากเจ้าของกลุ่มความสนใจรายอื่นที่ไม่ใช่ผู้ชนะในฟังก์ชัน reportWin	นี่เป็นข้อเสนอที่น่าสนใจ เราจะพิจารณาเพิ่มสัญญาณอื่นๆ ในการรายงานรวม และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ประเภทกิจกรรม	ทำให้ประเภทเหตุการณ์ใน API การวัดผลเป็นมาตรฐานต่างๆ เมื่อผสานรวมกับ FLEDGE	นี่เป็นข้อเสนอที่น่าสนใจ เราจะเพิ่มลงในคิวข้อเสนอที่จะศึกษา และรายงานการพัฒนาของเรา การดำเนินการนี้จำเป็นต้องมีการประสานงานกับความพยายามในวงกว้างของเราในด้านนี้ เนื่องจากจะส่งผลต่อ Privacy Sandbox API อื่นๆ นอกเหนือจาก FLEDGE เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
โซลูชันระยะยาวสำหรับการรายงานระดับเหตุการณ์	ความสนใจที่จะเก็บรักษาข้อมูลบางอย่างไว้ เช่น highestScoringOtherBid ต่อไป แม้ว่าจะมีการเลิกใช้งานคุกกี้ของบุคคลที่สามแล้ว	ตามที่เราได้แจ้งให้ทราบในบล็อกโพสต์เดือนกุมภาพันธ์ ระบบจะรองรับการรายงานการชนะการประมูลในระดับเหตุการณ์จนถึง "อย่างน้อยปี 2026" เราไม่มีรายละเอียดเพิ่มเติมที่จะแชร์ในตอนนี้ แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับความสำคัญของการเก็บรักษาข้อมูลบางอย่างไว้หลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม
ขีดจำกัดกลุ่มความสนใจ	จำนวนกลุ่มความสนใจที่ต้นทางสามารถเพิ่มเบราว์เซอร์เดียวได้จำกัดเท่าใด	Chrome อนุญาตให้มีกลุ่มความสนใจได้สูงสุด 1,000 กลุ่มต่อเจ้าของ 1 คน และเจ้าของกลุ่มความสนใจได้สูงสุด 1,000 คน เป้าหมายเหล่านี้จะเป็นแนวทาง ไม่ใช่ การทำงานตามปกติ
สัญญาณระดับเหตุการณ์	การรองรับข้อเสนอให้มีสัญญาณระดับเหตุการณ์สำหรับ generateBid และ reportWin ซึ่งนำไปใช้ในการฝึกแมชชีนเลิร์นนิงได้	เราได้แจ้งการตัดสินใจเกี่ยวกับสัญญาณที่ออกแบบโดยเบราว์เซอร์และสัญญาณที่กำหนดโดยเทคโนโลยีโฆษณาไว้ที่นี่แล้ว และยินดีรับฟังความคิดเห็นเพิ่มเติม
สคริปต์การเสนอราคา	ใส่รหัสผู้ใช้ใน URL ลงในสคริปต์การเสนอราคา	ซึ่งเป็นไปไม่ได้ เนื่องจาก FLEDGE มีข้อกำหนดเพิ่มเติมว่า Tuple ของเจ้าของกลุ่มความสนใจ, URL สคริปต์การเสนอราคา และครีเอทีฟโฆษณาที่แสดงผลต้องเป็น k-anonymous โฆษณาจึงจะแสดงได้
การบังคับใช้ K-anon	มีการบังคับใช้ k-anonymity ในคู่ (componentAd, ขนาด) ไหม	แน่นอน โปรดไปที่ turtledove/issues/312
ข้อกำหนดของบริการเสนอราคาและบริการประมูล	บริการ B&A ช่วยสนับสนุนผู้เข้าร่วมที่ผสานรวม FLEDGE ในอุปกรณ์และบริการอื่นๆ กับบริการ B&A อย่างไร	เรายังคงพยายามออกแบบขั้นสุดท้ายและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การระบุแหล่งที่มาหลังการดู	จะมีการรองรับการระบุแหล่งที่มาหลังการดูไหม	ปัจจุบันเรายังไม่มีคำจำกัดความมาตรฐานใดๆ ของความสามารถในการแสดงตัวโฆษณา และอาศัยตัวครีเอทีฟโฆษณาเองในการทำเครื่องหมายเหตุการณ์การดู โปรดไปที่ turtledove/issues/452
การกำหนดเป้าหมายที่คล้ายกัน	Privacy Sandbox รองรับ "การกำหนดเป้าหมายที่คล้ายกันไหม" ได้ไหม	เรากำลังพูดถึงกรณีการใช้งานที่นี่และยินดีให้ข้อมูลเพิ่มเติม
API การตรวจสอบแบบเรียลไทม์	ข้อเสนอสําหรับแนวทางการตรวจสอบ FLEDGE แบบเรียลไทม์	เรากำลังพูดถึงข้อเสนอนี้และยินดีให้ข้อมูลเพิ่มเติมที่นี่
การรายงาน FLEDGE	ควรสร้าง reportWin และ reportResult ขึ้นมาแบบสุ่มเพื่อป้องกันการรายงานมากเกินไปหรือน้อยเกินไป	ผู้ซื้อต้องเรียกใช้ reportResult() ก่อน reportWin() เพื่อให้สัญญาณของผู้ขายจาก reportResult() รวมอยู่ใน reportWin() ได้ ดูข้อมูลเพิ่มเติมได้ที่ผู้อธิบาย
เซิร์ฟเวอร์ค่าคีย์ที่กำหนดเอง (K/V)	ในอนาคตจะมีการรองรับเซิร์ฟเวอร์ K/V ที่กำหนดเองไหม	เรากำลังพูดคุยเกี่ยวกับคำถามที่นี่ และยินดีรับฟังข้อมูลเพิ่มเติม
การประมูลระดับบนสุด	เซิร์ฟเวอร์โฆษณาจะต้องเรียกใช้กลไกการประมูลระดับบนสุดไหม	FLEDGE API ไม่ได้ระบุว่าฝ่ายใดต้องเรียกใช้ FLEDGE ไม่ได้มีข้อกำหนดดังกล่าวในการออกแบบดังกล่าว ทุกคนสามารถเรียกใช้การประมูล FLEDGE ได้ (รวมถึงการประมูลกับผู้ขายหลายราย) ตามที่ได้กล่าวไว้ในรายงานไตรมาสที่ 4 ปี 2022 FLEDGE ช่วยให้ผู้เผยแพร่โฆษณาแต่ละรายเลือกโครงสร้างการประมูล รวมถึงตัวเลือกผู้ขายระดับบนสุดและผู้ขายคอมโพเนนต์ได้
ขอบเขต API	FLEDGE ตั้งใจจะทํางานกับข้อมูลจากบุคคลที่หนึ่งไหม	เราจะเผยแพร่เนื้อหาในไตรมาสที่ 2 ปี 2023 เพื่อชี้แจงว่าข้อมูลจากบุคคลที่หนึ่งจะใช้กับ FLEDGE ได้จริงกับทั้ง 1) ใช้เป็นตรรกะในการกำหนดการเป็นสมาชิกกลุ่มความสนใจ และ 2) เพื่อป้อนเป็นสัญญาณการเสนอราคาของผู้ใช้เพื่อใช้ในการสร้างตรรกะการเสนอราคาครั้งต่อๆ ไป
กลุ่มความสนใจข้ามโดเมน	ความเป็นไปได้ที่จะสร้างกลุ่มความสนใจแบบข้ามโดเมน	ข้อมูลใดๆ ที่มีอยู่ในขณะที่เพิ่มเบราว์เซอร์ลงในกลุ่มความสนใจสามารถใช้เพื่อแจ้งให้ผู้ชมทราบได้ เมื่อคุกกี้ของบุคคลที่สามยุติการให้บริการ ความพร้อมใช้งานข้อมูลข้ามเว็บไซต์เพื่อบอกการสร้างกลุ่มความสนใจจะถูกจำกัด
ตรรกะการเสนอราคาฝั่งไคลเอ็นต์	การย้ายตรรกะการเสนอราคาฝั่งเซิร์ฟเวอร์ที่มีอยู่ไปยังฝั่งไคลเอ็นต์	เราต้องการข้อมูลเพิ่มเติมเกี่ยวกับประเด็นที่ท้าทายหรือยังไม่มีกระบวนการย้ายในขณะนี้ และยินดีรับฟังความคิดเห็นเพิ่มเติมหรือข้อมูลเชิงลึกเพิ่มเติม
ค่าเซิร์ฟเวอร์ K/V	ค่าเซิร์ฟเวอร์ K/V ต้องเป็นสตริงประเภทไหม	ค่าต้องเป็นสตริง แต่สามารถจัดเก็บออบเจ็กต์เป็น JSON หรือบัฟเฟอร์โปรโตคอลและเรียงอันดับเป็นสตริงได้
รายการที่บล็อกของผู้ลงโฆษณา	สัญญาณใดที่เหมาะสมในการระบุผู้ซื้อให้กับรายการที่บล็อกของผู้ลงโฆษณา	สถานที่ที่เหมาะสมคือใน auctionSignals หรือใน perBuyerSignals
หน่วยการเสนอราคา	การรองรับหน่วยการเสนอราคาต่างๆ เช่น CPI และ CPM	เราต้องการเรียนรู้เพิ่มเติมเกี่ยวกับสาเหตุที่ต้องมีการออกแบบในปัจจุบัน และยินดีรับฟังความคิดเห็นเพิ่มเติม
ตรรกะการประมูล	เบราว์เซอร์หรือเซิร์ฟเวอร์โฆษณาตัดสินผู้ชนะการประมูลหรือไม่	การเลือกผู้ชนะทั้งหมดจะดำเนินการภายในแซนด์บ็อกซ์ และโค้ดของผู้ขายจะเป็นผู้ตัดสินทั้งหมด เบราว์เซอร์จะให้สภาพแวดล้อมที่เป็นส่วนตัวซึ่งปิดผนึกไว้ภายในโค้ดของผู้ซื้อและผู้ขาย
นโยบายสิทธิ์	นโยบายสิทธิ์ FLEDGE ปัจจุบันจะยังคงบังคับใช้ต่อไปไหมหลังจากช่วงทดลองใช้จากต้นทางสิ้นสุดลง	สำหรับช่วงทดลองใช้จากต้นทาง รายการที่อนุญาตเริ่มต้นในปัจจุบันของทั้ง 2 ฟีเจอร์เป็นแบบชั่วคราวและจะมีการเปลี่ยนแปลง เราอยากทราบว่าเทคโนโลยีโฆษณาจะต้องเตรียมรับการเปลี่ยนแปลงนี้นานเท่าใดก่อนที่จะเริ่มบังคับใช้
ข้อจำกัดด้านขนาดสัญญาณ	ระบบจะรวมคำขอสัญญาณการเสนอราคาที่เชื่อถือได้ไว้ในกลุ่มความสนใจหลายกลุ่มที่มี trustedBiddingSignalsUrl เดียวกัน โดยขีดจำกัดขนาด 2 MB นั้นจะเป็นข้อจำกัด	ข้อจำกัดนี้มีขึ้นสำหรับผู้โทรในอุปกรณ์เพื่อป้องกันไม่ให้ทรัพยากรในอุปกรณ์ล้นเกินไป ผู้โทรจากเซิร์ฟเวอร์ B&A จะมีข้อจำกัดมากขึ้น
สัญญาณการรายงาน	เพิ่มสัญญาณเพิ่มเติม ซึ่งก็คือข้อผิดพลาดสคริปต์ เพื่อให้ดึงข้อมูลจำนวนข้อผิดพลาดฝั่งไคลเอ็นต์ต่อเจ้าของกลุ่มความสนใจ 1 รายและตาม computeBid หรือ reportWin / reportResult	เรากำลังพิจารณาข้อกังวลที่อาจเกิดขึ้นเกี่ยวกับความเป็นส่วนตัวในข้อเสนอนี้และยินดีให้ผู้เล่นในระบบนิเวศมาแชร์ข้อมูลเชิงลึกเพิ่มเติมถึงเหตุผลที่ต้องดำเนินการนี้
ขนาดหน้าต่าง K-Anon	เพิ่มขนาดกรอบเวลา K-Anon จากขีดจํากัด 7 วันปัจจุบัน	เรื่องนี้อยู่ระหว่างการพิจารณา และเรากำลังรอ (และยินดีรับฟัง) ข้อมูลเพิ่มเติมจากระบบนิเวศ
ประสิทธิภาพของอุปกรณ์	FLEDGE จะจัดการประสิทธิภาพของอุปกรณ์อย่างไรหากผู้ใช้อยู่ในกลุ่มความสนใจจำนวนมาก	FLEDGE มีตัวเลือกการหมดเวลา การจัดลำดับความสำคัญ และขีดจำกัดมากมายสำหรับทั้ง SSP และ DSP ที่ให้การควบคุมแบบละเอียดแก่เทคโนโลยีโฆษณาในกรณีที่ประสิทธิภาพของอุปกรณ์อาจเป็นเหตุผลหนึ่งที่จะจำกัดการเข้าร่วมการประมูลเมื่ออุปกรณ์อยู่ในกลุ่มความสนใจจำนวนมาก
การทดสอบบริการ B&A	ขอให้ผู้เล่นระบบนิเวศใช้เซิร์ฟเวอร์ของตนเองในระหว่างขั้นตอนการทดสอบเพื่อให้มีบันทึกมากขึ้นสำหรับการแก้ไขข้อบกพร่อง	B&A ช่วยให้ผู้ใช้เปิดใช้งานและปรับขนาดเซิร์ฟเวอร์จากผู้ให้บริการคลาวด์ที่ได้รับอนุมัติได้ เราบังคับให้มีการดำเนินการในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) เพื่อรักษาความเป็นส่วนตัวของผู้ใช้ เราจะเผยแพร่คำอธิบายเกี่ยวกับการแก้ไขข้อบกพร่องของ B&A TEE เร็วๆ นี้ และกำลังพัฒนาฟีเจอร์เพื่อรองรับเรื่องนี้ เราต้องการความคิดเห็นเพิ่มเติมเกี่ยวกับหัวข้อนี้
ข้อกำหนดด้านการกำกับดูแล	FLEDGE จะทำงานร่วมกับผู้ให้บริการระบบคลาวด์ในประเทศต่างๆ เพื่อสนับสนุนการปฏิบัติตามข้อกำหนดทางกฎหมายท้องถิ่นไหม	เราพร้อมให้คำแนะนำแก่ผู้ให้บริการระบบคลาวด์รายอื่นๆ อยู่เสมอ แต่ขณะนี้เรามีแผนที่จะรองรับ GCP และ AWS เป็นอย่างน้อยเมื่อมีการบังคับใช้การเลิกใช้งานคุกกี้ของบุคคลที่สาม ดูข้อมูลเพิ่มเติมได้ในเครื่องมืออธิบายนี้

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

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
การวิเคราะห์ข้อมูลผลกระทบจากเสียงรบกวน	คำแนะนำเกี่ยวกับวิธีวิเคราะห์ข้อมูลเกี่ยวกับผลกระทบของ Noise	เราได้แชร์เอกสารประกอบเพิ่มเติมเกี่ยวกับการตัดสินใจด้านการออกแบบและข้อผิดพลาดที่อาจนำไปใช้เปลี่ยนแปลงผลกระทบของสัญญาณรบกวนต่อข้อมูลเทคโนโลยีโฆษณาได้ นอกจากนี้ยังมีคำแนะนำโดยละเอียดด้วย
การรายงานว่างเปล่า	ความชัดเจนเกี่ยวกับการใช้งานรายงาน Null	ขณะนี้เรากำลังดำเนินการเกี่ยวกับข้อเสนอสำหรับการใช้รายงาน Null และจะมีรายละเอียดเพิ่มเติมจะแจ้งให้คุณทราบเร็วๆ นี้ การใช้รายงาน Null จะช่วยให้เราลดความล่าช้าในการรายงานได้โดยไม่ส่งผลกระทบต่อความเป็นส่วนตัว
ระดับเสียงรบกวน	การปรับระดับสัญญาณรบกวนตามความยาวของกรอบเวลาการระบุแหล่งที่มา	เรายินดีรับข้อเสนอนี้และกำลังดำเนินการเพิ่มในข้อกำหนด เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่
ขนาดของข้อมูลทริกเกอร์	เหตุใดข้อมูลทริกเกอร์จึงจำกัดไว้ที่ 3 บิต	ขนาดจะจำกัดอยู่ที่ 3 บิตและค่าที่แตกต่างกัน 8 ค่าเพื่อให้มั่นใจว่าข้อมูลข้ามเว็บไซต์/บริบทเกี่ยวกับผู้ใช้จะมีปริมาณจำกัด เรายินดีให้ผู้เล่นในระบบนิเวศส่งความคิดเห็นว่าการใช้พารามิเตอร์ปัจจุบันสำหรับการรายงานระดับเหตุการณ์เหมาะสมหรือไม่
ทริกเกอร์การรายงานระดับเหตุการณ์	อนุญาตการจัดลำดับความสำคัญภายในคีย์การกรองข้อมูลที่ซ้ำกันออก	เรากำลังสำรวจวิธีแก้ปัญหาสำหรับปัญหานี้ และยินดีรับข้อมูลเพิ่มเติม
การสนับสนุนการแก้ไขข้อบกพร่อง	ความชัดเจนเกี่ยวกับการแก้ไขข้อบกพร่องหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม	เราต้องการสนับสนุนการแก้ไขข้อบกพร่องหลังจากเลิกใช้งานคุกกี้ของบุคคลที่สาม และเรากำลังพิจารณาตัวเลือกต่างๆ เราต้องการความคิดเห็นและแนวคิดเพิ่มเติม
ทางเลือกอื่นของ Conversion การคลิกผ่าน	ขอคำแนะนำเพิ่มเติมเกี่ยวกับทางเลือกอื่นๆ สำหรับ Conversion การคลิกผ่าน	เราแนะนําให้ระบบนิเวศใช้ Attribution Reporting API เป็นระบบการวัดผลส่วนตัวที่ยั่งยืนสําหรับ Use Case การวัด Conversion ที่เกี่ยวข้อง ยังมีทางเลือกอื่นๆ และผู้ให้บริการเทคโนโลยีโฆษณาจะต้องตัดสินใจเลือกโซลูชันที่เหมาะสมโดยพิจารณาจากความต้องการด้านความเป็นส่วนตัวและประโยชน์ใช้สอยที่ตนเองต้องการ
กรณีการใช้งานการเรียกเก็บเงิน	ความชัดเจนเกี่ยวกับขอบเขตที่การรายงานการระบุแหล่งที่มาจะรองรับ กรณีการใช้งานการเรียกเก็บเงินตาม Conversion	เรากำลังดำเนินการโพสต์แบบสาธารณะเพื่อชี้แจงขอบเขตของ Attribution Reporting API สำหรับการเรียกเก็บเงิน ในตอนแรก Attribution Reporting API ไม่ได้กำหนดขอบเขตด้วยวิธีที่สนับสนุนการเรียกเก็บเงินแบบ CPA โดยตรง แต่รองรับการเรียกเก็บเงินแบบ CPC และ CPM ซึ่งเป็นโครงสร้างการเรียกเก็บเงินที่เทคโนโลยีส่วนใหญ่ใช้ หากมีความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศ เราอาจให้การสนับสนุนในส่วนนี้ในอนาคต
การสนับสนุนกรณีการใช้งาน	เอกสารประกอบเกี่ยวกับกรณีการใช้งานสำหรับ Measurement API	เรากำลังดำเนินการชี้แจงเอกสารประกอบสำหรับแพลตฟอร์มการรายงาน Privacy Sandbox ทั้งหมด
คุณภาพคลิก	ขอให้เพิ่มสัญญาณเพื่อแยกระหว่างการคลิกที่ตั้งใจกับ การคลิกที่ไม่ตั้งใจบนโฆษณา	เรากำลังพูดคุยเกี่ยวกับคำขอ และยินดีรับข้อมูลเพิ่มเติม
โซลูชันการวัดผล	การสนับสนุนสำหรับโซลูชันการวัดผลใน DSP หลายแห่ง	ผู้ให้บริการวัดผลอาจใช้ Attribution Reporting API เพื่อกรองข้อมูลที่ซ้ำกันออกระหว่าง DSP หลายแห่ง นอกจากนี้ เราขอเสนอ การสนับสนุนสำหรับรายการ URL ใน attributionsrc ซึ่งจะช่วยให้ DSP รองรับคำขอ Attribution Reporting API ในการวัดผลได้ง่ายขึ้น เรายินดีรับฟังความคิดเห็นเพิ่มเติม เกี่ยวกับข้อเสนอข้างต้น
การรายงานระดับเหตุการณ์	ขอให้มีการระบุจำนวนวันก่อนที่รายงานจะส่งมาโดยตรง	เทคโนโลยีโฆษณาคำนวณคําขอนี้ได้โดยใช้ข้อมูลที่มีอยู่ในปัจจุบัน เรายังไม่ได้รับความคิดเห็นอื่นๆ เกี่ยวกับระบบนิเวศ เกี่ยวกับคำขอนี้ แต่เราก็ยินดีรับฟังความคิดเห็น
source_registration_time	เพิ่ม source_registration_time ในการรายงานการระบุแหล่งที่มาระดับเหตุการณ์	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมว่า ผู้เล่นในระบบนิเวศคิดว่าเป็นฟีเจอร์ที่มีประโยชน์หรือไม่
โหมดไม่ระบุตัวตน	ผู้ใช้จะเลือกใช้โซลูชันการวัดผลได้หรือไม่ เมื่อผู้ใช้อยู่ในโหมดไม่ระบุตัวตน	ไม่ โซลูชันการวัดผลจะใช้งานไม่ได้เมื่อผู้ใช้อยู่ในโหมดไม่ระบุตัวตน คุกกี้ของบุคคลที่สามจะปิดใช้งานโดยค่าเริ่มต้นในโหมดไม่ระบุตัวตน
Data Clean Room	Measurement API จะใช้ร่วมกับห้องสะอาดได้ไหม	ห้องทำความสะอาดข้อมูลทั่วไปคือสภาพแวดล้อมที่มีการอัปโหลดข้อมูลตัวระบุแต่ละแหล่งจากแหล่งที่มาต่างๆ ลงในฐานข้อมูลเพื่อทำการวิเคราะห์ตามการรวมข้อมูลที่จำเป็นดังกล่าว เฟรมเวิร์กการวัดผล 2 แบบสำหรับ Privacy Sandbox API คือรายงานระดับเหตุการณ์และรายงานสรุป รายงานระดับเหตุการณ์จะมีรหัสเหตุการณ์ที่ได้จากเทคโนโลยีโฆษณาซึ่งใช้ในห้องสะอาดข้อมูลได้ แต่ข้อมูลฝั่ง Conversion ที่เกี่ยวข้องจะมีจำกัดและมีเสียงดัง รายงานสรุปรวมที่เข้ารหัสจะใช้โดยตรงในห้องที่ปลอดภัยไม่ได้ แต่สามารถใช้ผลสรุปที่ได้จากบริการรวบรวมข้อมูลเป็นอินพุตสำหรับการวิเคราะห์ที่คุณทำหรือเป็นข้อมูลเสริมได้

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
(มีการรายงานในไตรมาสที่ 4 ปี 2022 ด้วย) ความล่าช้าของการรายงาน	เราคาดว่าการรายงานจะล่าช้าเพียงใด	ข้อมูลอัปเดตไตรมาสที่ 1 ปี 2023: เราได้แชร์ข้อเสนอเพื่อลดความล่าช้า และลดผลกระทบของความล่าช้าตามความคิดเห็นของพาร์ทเนอร์ ข้อเสนอทั้ง 2 รายการได้รับการสนับสนุนจากเทคโนโลยีโฆษณาในระหว่างการเรียกใช้ WICG
ไม่มีกฎที่ซ้ำกัน	คุณจะจัดการกับ "รายงานที่รวบรวมได้แบบล่าช้า" อย่างไร หากรายงานที่รวบรวมได้ซึ่งมีรหัสที่แชร์เดียวกันได้รับการประมวลผลแล้ว	เราได้แชร์ข้อเสนอในการเพิ่มความล่าช้าของรายงานเพิ่มเติมลงในข้อมูลที่แชร์ของรายงานที่รวบรวมได้ และคำจำกัดความของรหัสที่แชร์สำหรับบริการรวบรวมข้อมูลเพื่อแก้ไขผลกระทบจากความล่าช้าที่สูญเสียไปใน API แบบรวมบางส่วน เรายินดีรับฟังความคิดเห็น เกี่ยวกับข้อเสนอนี้
การประมวลผลข้อมูล	ส่งคำขอเปิดใช้การรองรับการรับส่งข้อมูลหลายชุด โดยเคารพ Differential Privacy โดยใช้งบประมาณด้านความเป็นส่วนตัว	เรากำลังพูดคุยถึงความเป็นไปได้ในการใช้งบประมาณความเป็นส่วนตัวที่มีความยืดหยุ่นมากขึ้นเพื่อเปิดใช้กรณีการใช้งานนี้ และยินดีรับความคิดเห็นเพิ่มเติม
(มีการรายงานในไตรมาส 2 ปี 2022 ด้วย) หลักการยศาสตร์ของการค้นหา	เปิดใช้การค้นหาการรวมคีย์	ข้อมูลอัปเดตไตรมาสที่ 1 ปี 2023: คำขอฟีเจอร์ยังคงอยู่ระหว่างการพิจารณา แต่เรายังไม่มีข้อเสนอที่จะแชร์ในขณะนี้
ข้อจำกัดช่วงทดลองใช้จากต้นทาง	อธิบายขอบเขตของบริการรวบรวมข้อมูล เช่น "ไม่มีกฎที่ซ้ำกัน" ซึ่งปัจจุบันไม่ได้ใช้ในช่วงทดลองใช้จากต้นทาง	เรากำลังดำเนินการอัปเดตเอกสารประกอบเพื่อชี้แจงสิ่งที่จะใช้งานได้ในช่วงทดลองใช้จากต้นทางและใน GA

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
งบประมาณการมีส่วนร่วมแบบสรุปรวมแบบส่วนตัว	งบประมาณการมีส่วนร่วม L1 จำกัดเกินไป	การเรียก Private Aggregation API แต่ละครั้งเรียกว่าการมีส่วนร่วม เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้ จะมีการจำกัดจำนวนการมีส่วนร่วมที่สามารถรวบรวมได้จากแต่ละคน เมื่อรวมค่าที่สรุปได้ทั้งหมดในคีย์การรวมทั้งหมด ผลรวมจะต้องน้อยกว่างบประมาณการมีส่วนร่วม ในส่วนการออกแบบปัจจุบัน เราได้กำหนดขีดจำกัดการมีส่วนร่วมสำหรับต้นทางการรายงานหนึ่งๆ ในช่วงประมาณ 24 ชั่วโมงที่ผ่านมา (เป็นกรอบเวลาต่อเนื่อง) นั่นคืองบประมาณการมีส่วนร่วม L1 ที่กล่าวถึงในความคิดเห็น เราขอแนะนำให้นักพัฒนาซอฟต์แวร์ปรับขนาดค่าที่ให้โดยอิงตามปริมาณที่คาดไว้ (ไม่ใช่แค่ใช้ค่า 1) ดังนั้น ขอแนะนำให้คุณใช้ค่าที่น้อยกว่ากับเหตุการณ์ทั่วไปเพื่อหลีกเลี่ยงการใช้งบประมาณจนหมด เราต้องการความคิดเห็นบางอย่างเกี่ยวกับงบประมาณการสนับสนุนของ API สำหรับการรวมแบบส่วนตัว ทั้งด้านตัวเลขและขอบเขต เรากำลังพิจารณาย้ายขอบเขตจากตามต้นทางไปยังแต่ละไซต์ และย้ายขอบเขตที่มีอยู่ไปยังกรอบเวลา 10 นาทีที่มีขอบเขตรายวันมากขึ้น

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

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
การใช้งาน UA-R	จากเว็บไซต์ยอดนิยม 10,000 แห่งในสหราชอาณาจักร มีเว็บไซต์เพียง 1% ที่ใช้การโฆษณาแบบเป็นโปรแกรมที่ส่งเคล็ดลับไคลเอ็นต์ HTTP DSP ที่ยังไม่ได้ย้ายข้อมูลอาจมีผลต่อความสามารถในการป้องกันการประพฤติมิชอบ	หลังจากเรียกใช้การวิเคราะห์ในชุดข้อมูลเดียวกัน เราพบว่าหากคุณให้ข้อมูลเกี่ยวกับการใช้งาน UA-CH ผ่านแท็ก HTML <meta> และ JavaScript API จำนวนเว็บไซต์ที่ใช้ UA-CH จะสูงกว่าตัวเลข 1% ที่ระบุไว้ในความคิดเห็นอย่างมาก จากข้อมูลนี้และข้อเท็จจริงอื่นๆ รวมถึงความคิดเห็นเกี่ยวกับระบบนิเวศ เรามั่นใจว่าจะเดินหน้าการทยอยเปิดตัวการลด UA เฟส 6 ตามไทม์ไลน์ที่เผยแพร่ ในขณะที่คอยแจ้งให้ CMA ทราบอยู่เสมอ เราทราบว่าเว็บไซต์ต้องใช้เวลาเกือบ 2 ปีเพื่อเตรียมพร้อมสำหรับการเปลี่ยนแปลง และการทดลองใช้การเลิกใช้งานยังคงมีอยู่สำหรับเว็บไซต์ที่รู้สึกว่ายังไม่พร้อม
คำแนะนำสำหรับรูปแบบของอุปกรณ์เพิ่มเติม	คำขอให้ UA-CH ระบุรูปแบบของอุปกรณ์เพิ่มเติม เช่น TV, VR	เรายินดีรับข้อเสนอนี้และพิจารณาที่จะนำมาใช้ในการออกแบบ เรายินดีรับความคิดเห็นเพิ่มเติม
การทดสอบอัตโนมัติ	คำขอแก้ไขข้อบกพร่อง UA-CH ใน Chrome แบบไม่มีส่วนหัวก่อนจัดส่ง UAR ระยะที่ 6	ข้อบกพร่องที่เป็นปัญหาได้รับการแก้ไขแล้ว
การรองรับ UA-CH ใน iOS	เว็บไซต์ซึ่งอาศัยข้อมูล UA แบบละเอียดสําหรับกรณีการใช้งานโฆษณาระบุว่าระบบไม่รองรับ Chrome ใน iOS	สำหรับเบราว์เซอร์ iOS ที่ไม่ใช่ Safari (รวมถึง Chrome ใน iOS) โปรเจ็กต์ WebKit จะต้องเพิ่มการรองรับ UA-CH ก่อนจึงจะเปิดใช้ได้ (เนื่องจากควบคุมสแต็กเครือข่าย)

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
(มีการรายงานในไตรมาสที่ 4 ด้วย) กรณีการใช้งานตำแหน่งทางภูมิศาสตร์	การป้องกัน IP อาจป้องกันไม่ให้มีการใช้งานกรณีการใช้งานตำแหน่งทางภูมิศาสตร์ที่ถูกต้องในอนาคต เช่น การปรับเปลี่ยนเนื้อหาตามตำแหน่งที่ตั้งทางภูมิศาสตร์	ผลตอบรับของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่ 4 ปี 2022 "เรากําลังทํางานร่วมกับผู้มีส่วนเกี่ยวข้องเพื่อให้ Chrome ยังคงรองรับ Use Case ที่ถูกต้องสําหรับที่อยู่ IP ต่อไป เราต้องการความคิดเห็นเกี่ยวกับระบบนิเวศเกี่ยวกับรายละเอียดเกี่ยวกับตำแหน่งทางภูมิศาสตร์ของ IP"
การปฏิบัติตามข้อบังคับ	หากภูมิภาคหนึ่งมีประชากรต่ำกว่า 1 ล้านคน เกณฑ์การปกป้อง IP ในปัจจุบันอยู่ที่ 1 ล้านคนจะทำให้เว็บไซต์ใช้ที่อยู่ IP เพื่อการปฏิบัติตามข้อกำหนดไม่ได้	เรากำลังทำงานร่วมกับผู้มีส่วนเกี่ยวข้องเพื่อดูแลให้ Chrome รองรับกรณีการใช้งานที่อยู่ IP ที่ถูกกฎหมายต่อไป เราต้องการความคิดเห็นเกี่ยวกับระบบนิเวศเพื่อให้สอดคล้องกับกฎระเบียบด้านการปกป้องทรัพย์สินทางปัญญา
การบรรเทาการละเมิด	คู่สัญญาสามารถหลบเลี่ยงการป้องกัน IP ด้วยการแชร์ที่อยู่ IP ที่ไม่ได้มาสก์ไว้กับผู้อื่น	เราตระหนักดีถึงความเสี่ยงที่ข้อเสนอการปกป้อง IP ปัจจุบันอาจไม่ได้ป้องกันไม่ให้บุคคลอื่นๆ แชร์ที่อยู่ IP ที่ไม่ได้มาสก์ข้อมูลไว้กับผู้อื่น เรากำลังดำเนินการบรรเทาความเสี่ยงที่จะหลีกเลี่ยงความเสี่ยงจากการละเมิดนี้ ขณะที่เราตรวจสอบข้อเสนออีกครั้ง เราแนะนำให้แสดงความคิดเห็นและปรึกษาหารือกันเพิ่มเติม โดยเฉพาะอย่างยิ่ง เราต้องการทราบเกี่ยวกับกรณีการใช้งานต่างๆ ที่บุคคลที่เชื่อว่าจำเป็นจะต้องแชร์ที่อยู่ IP ที่ไม่ได้มาสก์แก่บุคคลอื่น
การบล็อกเครือข่าย	คู่สัญญาสามารถหลบเลี่ยงการบล็อกเครือข่ายโดยใช้พร็อกซีการป้องกัน IP	เอนทิตีที่ดำเนินการบล็อกจะต้องปิดใช้การป้องกัน IP สำหรับสถานการณ์นี้ เราได้แก้ไขปัญหาและยินดีรับฟังความคิดเห็นเพิ่มเติม
รายการบล็อกที่อยู่ IP ที่ได้รับผลกระทบจากข้อเสนอการปกป้อง IP	บริษัทเทคโนโลยีโฆษณาจำนวนมากใช้รายการที่อยู่ IP พื้นฐานที่บล็อกไว้ เช่น รายการ IP ของศูนย์ข้อมูลของ TAG เพื่อป้องกันการเสนอราคาสำหรับพื้นที่โฆษณาที่มีแนวโน้มสูงว่าจะเป็นการฉ้อโกง (หรืออย่างน้อยก็ไม่สามารถสร้างรายได้) ในกรณีที่เทคโนโลยีโฆษณาเป็นเครื่องมือติดตามและอาจได้รับข้อเสนอการป้องกัน IP บริษัทดังกล่าวอาจไม่สามารถตรวจสอบโฆษณาเบื้องต้นก่อนซื้อพื้นที่โฆษณาได้	เราขอแนะนำให้มีความคิดเห็นเพิ่มเติมและหารือกันเกี่ยวกับข้อเสนอการปกป้อง IP เกี่ยวกับปัญหาและวิธีแก้ไขที่อาจเกิดขึ้น ตัวเลือกหนึ่งคือการนำรายการดังกล่าวไปใช้กับการป้องกัน IP ซึ่งเราไม่ได้ใช้พร็อกซี่ไคลเอ็นต์ที่มาจากที่อยู่ IP ที่มีการติดธงทำเครื่องหมายก่อนหน้านี้

ขยายขอบเขตความเป็นส่วนตัวแบบข้ามเว็บไซต์

ชุดโดเมนของบุคคลที่หนึ่ง

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
(มีการรายงานในไตรมาสที่ 4 ด้วย) ขีดจํากัดโดเมน	คำขอขยายจำนวนโดเมนที่เชื่อมโยง	การตอบสนองของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่ 4 ปี 2022 "เราได้ชี้แจงในการโทรของ WICG ว่า Chrome มุ่งมั่นที่จะ นำเสนอโซลูชันที่ใช้งานได้โดยคำนึงถึงความสนใจด้านความเป็นส่วนตัวของผู้ใช้ด้วย ด้วยเหตุนี้ เราจึงขอขอบคุณความคิดเห็นจากชุมชนเกี่ยวกับกรณีการใช้งานบางอย่างที่ได้รับผลกระทบจากขีดจำกัดโดเมน เพื่อให้ทีมสามารถพิจารณาวิธีจัดการ Use Case เหล่านี้ไปพร้อมๆ กับปกป้องความเป็นส่วนตัวของผู้ใช้ต่อไป"
การส่ง FPS สำรอง	ข้อเสนอสำหรับทางเลือกในการส่งรายการทั่วโลกสำหรับ FPS	ขณะนี้เรากำลังเตรียมจัดส่งชุดบุคคลที่หนึ่ง (FPS) ใน Chrome และได้ตั้งค่าที่เก็บ GitHub ส่วนกลางเพื่อยอมรับการส่งชุด เนื่องจากเราหวังว่า FPS จะเติมเต็มช่องว่างด้วยโซลูชันแพลตฟอร์มเว็บที่มีอยู่เพื่อเตรียมพร้อมสำหรับการเลิกใช้งานคุกกี้ของบุคคลที่สาม เราจึงคาดหวังที่จะเรียนรู้จากพวกเขาว่าผู้เขียนเว็บไซต์ใช้ประโยชน์จาก FPS อย่างไร เนื่องจากชุดรายการค่อยๆ เพิ่มขึ้นและระบบนิเวศปรับตัวให้เข้ากับโลกของคุกกี้ของบุคคลที่สาม เราสามารถพัฒนากระบวนการนี้ให้เติบโตจนถึงจุดที่สามารถพิจารณาแผนการแบบกระจายศูนย์ที่เป็นทางเลือกดังเช่นรูปแบบที่นำเสนอ ด้วยขั้นตอนปัจจุบัน เราคาดหวังว่าจะตั้งขีดจำกัดเวลาซึ่งจะทำให้เราพัฒนากระบวนการรับได้เมื่อเวลาผ่านไป เราจะกลับมาทบทวนแนวคิดนี้อีกครั้งเมื่อกระบวนการส่งเนื้อหามาถึงแล้ว
การดูแลที่เก็บ	ออกคำสั่งให้ชุมชนเก็บที่เก็บการส่ง FPS เข้าชุมชนเพื่อป้องกันการละเมิด ผู้ไม่ประสงค์ดีสามารถทำให้เกิดความหนักใจในกระบวนการที่ใช้จุดเริ่มการเขียนเพื่อเสนอฉากต่างๆ ได้ และคำขอจำนวนมากอาจส่งผลต่อการดำเนินการสำหรับข้อเสนอชุดจริง	เราพยายามทำให้การตรวจสอบนี้เป็นไปตามวัตถุประสงค์มากที่สุดโดยใช้การตรวจสอบความถูกต้องทางเทคนิค เราคิดว่านี่คือวิธีการ ที่รองรับการปรับขนาดมากที่สุดสำหรับกระบวนการส่ง เพื่อให้เป็นไปตามเป้าหมายนี้ เรายังมีเป้าหมายที่จะดูแลให้กระบวนการมีความยืดหยุ่นต่อการส่งสแปม / โปรแกรมเบิร์น
ชุดย่อยที่เกี่ยวข้อง	FPS จะรองรับ Use Case เกี่ยวกับกระบวนการ/SaaS ของบุคคลที่สามผ่านชุดย่อยที่เกี่ยวข้องได้ไหม	ขั้นตอนผู้ให้บริการ / SaaS ของบุคคลที่สามไม่ใช่กรณีการใช้งานที่ปัจจุบันได้รับการพิจารณาว่าอยู่ในขอบเขตของชุดบุคคลที่หนึ่ง เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับวิธีการใช้คุกกี้ข้ามเว็บไซต์สำหรับกรณีการใช้งานเหล่านี้
การผสานรวม FPS + CHIPS	คำขอผสานรวม FPS + CHIPS เพื่อรองรับ Use Case เช่น การทดสอบ A/B	เรากำลังหารือกันเกี่ยวกับกรณีการใช้งานนี้ และก็กำลังพิจารณาหารือเรื่องนี้เพิ่มเติมในการติดต่อ WICG และยินดีรับข้อมูลเพิ่มเติมที่นี่
GDPR	จะมีการสร้างข้อเสนอสำหรับชุดย่อยของ FPS ใหม่ตามแนวคิด GDPR	เราได้หารือเกี่ยวกับข้อเสนอนี้เป็นการภายในและพิจารณากับความคิดเห็นอื่นๆ ที่ได้รับ รวมถึงเป้าหมายด้านความเป็นส่วนตัวของเรา เราได้ให้คำตอบเพื่ออธิบายเหตุผลที่เราจะไม่ดำเนินการตามข้อเสนอนี้ในขณะนี้
หน่วยความจำ	การเปลี่ยนแปลงขนาดหน่วยความจำของเบราว์เซอร์ที่คาดไว้เมื่อมีการรวมรายการ FPS	ก่อนหน้านี้เบราว์เซอร์ต้องจัดเก็บรายการประเภทเหล่านี้โดยใช้หน่วยความจำน้อยที่สุด เช่น รายการป้องกันการติดตามการยกเลิกการเชื่อมต่อ แม้ว่าระบบจะคัดลอกรายการชุดบุคคลที่หนึ่งไปยังไคลเอ็นต์ Chrome แต่ละไคลเอ็นต์ในเครื่อง แต่เราจะยังคงตรวจสอบขนาดไฟล์และมั่นใจว่าเราสามารถเพิ่มประสิทธิภาพการใช้หน่วยความจำได้

Fenced Frames API

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
ขีดจำกัดเฟรมที่มีการปิดกั้น	ความชัดเจนเกี่ยวกับข้อจำกัดที่กำหนดโดย Fenced Frames	เมื่อเดือนมีนาคม เราได้อัปเดตคำอธิบายเกี่ยวกับ Fenced Frame ซึ่งให้ข้อมูลเกี่ยวกับความสามารถของเฟรม และยินดีรับความคิดเห็นเพิ่มเติม
ขยายข้อมูลการเข้าถึง	ขอขยายการเข้าถึงข้อมูล ในเฟรมใกล้เคียง	เรากำลังทำความเข้าใจเพิ่มเติมถึงเหตุผลที่สิ่งนี้เป็นข้อกำหนดจากระบบนิเวศ และยินดีรับความคิดเห็นเพิ่มเติม
เฟรมที่มีการปิดกั้นและ iframe	คำถามเกี่ยวกับความเท่าเทียมกันของฟีเจอร์ระหว่าง Fenced Frame และ iframe	API และรายงาน Privacy Sandbox ทั้งหมดที่มีอยู่จะพร้อมใช้งานสำหรับ iframe และ FencedFrames ในลักษณะเดียวกัน
การปรับขนาดเฟรมที่มีการปิดกั้น	การจำกัดการเปลี่ยนแปลงขนาดเฟรมจะมีผลต่อกรณีการใช้งานบางกรณี	เราต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับประเภท Use Case ที่ได้รับผลกระทบจากข้อจำกัด เรายินดีรับฟังความคิดเห็นเพิ่มเติม

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
เวิร์กเลตของบุคคลที่สาม	บุคคลที่สามจะเขียนไปยังพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งแบ่งพาร์ติชันตามต้นทางได้ไหม หรือเรียกใช้ Worklet อื่นๆ สำหรับการวัดผลโดยบุคคลที่สาม	ต้นทางของบริบทการท่องเว็บที่เรียกใช้โค้ดจะกำหนดพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งเขียนข้อมูลดังกล่าว เมื่อมีการเพิ่มโค้ดของบุคคลที่สามในหน้าเว็บ โค้ดของบุคคลที่สามจะฝังเป็น iframe พร้อมบริบทการท่องเว็บของตัวเองได้ ซึ่งจะช่วยให้โค้ดของบุคคลที่สามเขียนไปยังต้นทางของตัวเองได้ นอกจากนี้โค้ดของบุคคลที่สามยังฝังเป็นสคริปต์แทนที่จะเป็น iframe ได้ ซึ่งไม่ได้เปลี่ยนบริบทการท่องเว็บ และบุคคลที่สามสามารถเขียนลงในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของการฝังได้ โปรดทราบว่ามีเพียงเจ้าของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันเท่านั้นที่สามารถอ่านจากพื้นที่เก็บข้อมูลที่ใช้ร่วมกันนั้นได้
การนำออกข้อมูลซ้ำซ้อน	การโต้ตอบนอกระบบนิเวศของ Chrome จะกรองข้อมูลที่ซ้ำกันออกไม่ได้	พื้นที่เก็บข้อมูลที่ใช้ร่วมกันมีไว้เพื่อให้เอาต์พุต Unique Reach ที่อิงตามเบราว์เซอร์ของ Chrome ภายใน Chrome เราสนใจที่จะทำงานร่วมกับเทคโนโลยีโฆษณาเพื่อทำความเข้าใจวิธีใช้ผลลัพธ์เหล่านี้เป็นส่วนหนึ่งของรูปแบบการเข้าถึงที่กว้างขึ้น เราเข้าใจดีว่าผลลัพธ์เองก็อาจนำมาซึ่งการโต้ตอบเพียงบางส่วนเท่านั้น และสนใจที่จะทำงานร่วมกับเทคโนโลยีโฆษณาเพื่อสำรวจวิธีการสร้างรูปแบบเพิ่มเติมที่อาจนำมาต่อยอดได้
กรอบเวลามองย้อนกลับของ Conversion	ขอให้มีกรอบเวลามองย้อนกลับสำหรับอัตรา Conversion เพื่อดูการเปลี่ยนแปลงของ Conversion เมื่อเวลาผ่านไป	ซึ่งทำได้ด้วยการประมวลผลเส้นทาง Conversion ต่างๆ ในฝั่งไคลเอ็นต์โดยใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน ซึ่งให้ความยืดหยุ่นมากขึ้นสำหรับการวิเคราะห์ขั้นสูงมากกว่าพื้นที่เก็บข้อมูลของเบราว์เซอร์แบบไม่ได้แบ่งพาร์ติชันที่มีความปลอดภัย
กรอบเวลาหมดอายุของสินค้า	คำขอขยายกรอบเวลาหมดอายุเป็น 90 วัน	นโยบายการเก็บรักษาข้อมูลได้รับอัปเดตเมื่อเดือนพฤศจิกายน 2022 และระบุว่าระบบจะล้างแต่ละคีย์หลังจากการเขียนครั้งล่าสุด 30 วัน เรายินดีรับฟังความคิดเห็นเพิ่มเติมเพื่อ ทำความเข้าใจว่านโยบายใหม่จะใช้กับระบบนิเวศได้หรือไม่
การหมุนเวียนโฆษณา	กรณีการใช้งานการหมุนเวียนครีเอทีฟโฆษณาไม่ได้สะท้อนถึงการดำเนินการจริงหลังการประมูล	เราต้องการรับฟังความคิดเห็นจากบริษัทเทคโนโลยีโฆษณาฝั่งซื้อมากขึ้นว่าเอกสารการหมุนเวียนครีเอทีฟโฆษณาถูกต้องหรือไม่

ชิป

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

FedCM

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
ปลายทางการยืนยันข้อมูลประจำตัว	อนุญาตให้ส่งคำขอตามอำเภอใจไปยังปลายทางการยืนยันข้อมูลประจำตัวอย่างชัดเจน	เราได้ทำงานร่วมกับ Mozilla ในคำขอแบบพุลนี้เพื่อจำกัดความสามารถของเว็บไซต์ในการส่งคำขอข้อมูลเข้าสู่ระบบแบบข้ามต้นทางอย่างเงียบๆ โดยไม่ก่อให้เกิดความรำคาญแก่ผู้ใช้ และจะตรวจสอบและดำเนินการกับความคิดเห็นอื่นๆ ต่อไปเช่นกัน
ป้อนข้อมูลข้อมูลประจำตัวล่วงหน้า	FedCM สามารถใช้เพื่อป้อนข้อมูลแบบฟอร์มการลงชื่อเข้าใช้ที่มีผู้ให้บริการข้อมูลประจำตัวจากรายชื่อ FedCM ไว้ล่วงหน้าได้ไหม	ข้อกังวลสำหรับกรณีการใช้งานนี้คืออาจส่งผลให้ข้อมูลรั่วไหลเมื่อเว็บไซต์ที่ไม่ได้มีส่วนร่วมกับผู้ใช้ค้นหา IdP ล่าสุดที่ผู้ใช้ใช้อยู่ได้ เรากำลังพูดคุยเกี่ยวกับปัญหานี้เพิ่มเติมและยินดีรับฟังความคิดเห็นเพิ่มเติม
การเลือกบัญชีตามบริบท	ข้อเสนอให้เพิ่มสัญญาณบริบทใน UI การเลือกบัญชี	เรากำลังพิจารณาข้อเสนอนี้และยินดีรับการสนทนาเพิ่มเติม

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

API โทเค็นสถานะส่วนตัว (และ API อื่นๆ)

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