รายงานรายไตรมาสสําหรับไตรมาสที่ 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 หมวดหมู่ ซึ่งเราได้ทำดังต่อไปนี้
|
(มีการรายงานในไตรมาสที่ 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 เราก็อยากพิจารณาการเปลี่ยนแปลงเหล่านี้ แต่เราคิดว่าวิธีที่ดีที่สุดในอนาคตคือเปิดตัวเวอร์ชันสำหรับผู้ใช้ทั่วไปและรับฟังความคิดเห็นจากนักพัฒนาแอปรายอื่นๆ โดยตรง หวังว่าเราจะสามารถพูดคุยเกี่ยวกับเรื่องนี้ต่อไปและเดินหน้าตามมาตรฐานของเบราว์เซอร์ หากและเมื่อมีมาตรฐานใหม่เกิดขึ้น เราจะพิจารณาปรับใช้และพัฒนาแผนการเพื่อเปลี่ยนไปใช้มาตรฐานนี้อย่างระมัดระวัง |