รายงานความคิดเห็น - ไตรมาสที่ 2 และ 3 ปี 2024

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

Google ได้ตกลงที่จะจัดทำรายงานรายไตรมาสเกี่ยวกับกระบวนการมีส่วนร่วมกับผู้มีส่วนเกี่ยวข้องสำหรับข้อเสนอ Privacy Sandbox เป็นรายไตรมาส (ดูวรรคที่ 12 และ 17(ค)(2) ของความมุ่งมั่น) ซึ่งเป็นส่วนหนึ่งของความมุ่งมั่นต่อ CMA ในวันที่ 22 กรกฎาคม 2024 Google ได้ประกาศว่าจะไม่เลิกใช้งานคุกกี้ของบุคคลที่สาม (3PC) ใน Chrome และเสนอที่จะเปิดตัวแนวทางที่อัปเดตใหม่เพื่อยกระดับตัวเลือกของผู้ใช้แทน ดังนั้น Google จึงไม่ได้ส่งรายงานสาธารณะสำหรับไตรมาสที่ 2 ปี 2024 ไปยัง CMA ตามข้อตกลงของ CMA เพื่อให้ Google และ CMA มีเวลาเพียงพอในการพิจารณาผลกระทบจากการประกาศของ Google

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

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

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

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

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

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

ARA

Attribution Reporting API

CHIPS

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

DSP

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

FedCM

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

FPS

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

IAB

Interactive Advertising Bureau

IDP

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

IETF

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

IP

ที่อยู่ Internet Protocol

openRTB

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

OT

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

PAT API

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

PatCG

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

RP

ฝ่ายที่ต้องพึ่งพา

RWS

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

SSP

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

TEE

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

UA

สตริง User Agent

UA-CH

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

W3C

World Wide Web Consortium

WIPB

การจงใจปิดใช้ IP

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การเลิกใช้งานคุกกี้ของบุคคลที่สาม (3PCD)	Google มีแผนอย่างไรสําหรับ 3PCD และประเมินผลกระทบระยะยาวต่ออุตสาหกรรมโฆษณาดิจิทัลแล้วหรือยัง	เรากำลังเสนอแนวทางที่อัปเดตเพื่อยกระดับตัวเลือกของผู้ใช้ ตามที่ได้ระบุไว้ที่นี่ เราจะเปิดตัวประสบการณ์การใช้งานแบบใหม่ใน Chrome แทนการเลิกใช้งาน 3PC ซึ่งจะช่วยให้ผู้ใช้มีทางเลือกที่รอบรู้ซึ่งใช้ได้กับการท่องเว็บ และผู้ใช้จะปรับตัวเลือกดังกล่าวได้ทุกเมื่อ เรากำลังหารือเกี่ยวกับเส้นทางใหม่นี้กับหน่วยงานกำกับดูแล และจะมีส่วนร่วมกับอุตสาหกรรมก่อนเปิดตัว
ตัวเลือกของผู้ใช้	การประกาศเกี่ยวกับทางเลือกของผู้ใช้ส่งผลต่อความสนใจของระบบนิเวศในการใช้โซลูชัน Privacy Sandbox เราได้รับความคิดเห็นที่หลากหลายเกี่ยวกับการประกาศเรื่องทางเลือกของผู้ใช้ รวมถึงคำขอฟีเจอร์ต่างๆ เช่น ความสามารถในการตรวจสอบ	แนวทางที่อัปเดตใหม่นี้ช่วยเพิ่มทางเลือกให้แก่ผู้ใช้ แต่นักพัฒนาแอปก็ยังคงต้องหาทางเลือกที่เพิ่มความเป็นส่วนตัวแทนตัวระบุข้ามเว็บไซต์ แม้ว่าเราจะยังไม่มีรายละเอียดที่จะแชร์เกี่ยวกับประสบการณ์การใช้งานแบบใหม่ แต่เราคาดว่าการเข้าชมแบบไม่มีคุกกี้ใน Chrome จะเพิ่มขึ้นอย่างมาก ซึ่งหมายความว่า Privacy Sandbox API จะยังคงมีความสำคัญต่อธุรกิจ เราจะลงทุนในเทคโนโลยี Privacy Sandbox ต่อไปเพื่อปรับปรุงความเป็นส่วนตัวและการใช้งานฟีเจอร์ต่างๆ ในอนาคต
UI ตัวเลือกของผู้ใช้	คำถามเกี่ยวกับลำดับเวลาของฟีเจอร์การเลือกไม่ใช้/ความยินยอม ประเภทตัวเลือกของผู้ใช้ที่พิจารณา และผลกระทบที่ UI จะมีต่อสภาพแวดล้อมการทดสอบอัตโนมัติ	เรายังไม่มีการอัปเดตไทม์ไลน์ที่จะแชร์ในตอนนี้ เมื่อเราตัดสินใจที่จะไม่ดำเนินการตาม 3PCD เราจึงต้องการให้มีการอัปเดตระบบนิเวศโดยเร็วที่สุด เราจะแจ้งข้อมูลอัปเดตเรื่องลำดับเวลาสำหรับทางเลือกของผู้ใช้ทันทีที่มี
การทดสอบ Chrome	คำขอป้ายกำกับการทดสอบที่อำนวยความสะดวกโดย Chrome ให้มีให้บริการต่อไปเพื่อวัดการยอมรับในตลาดและผลกระทบทางเศรษฐกิจของ 3PCD หลังครึ่งปีแรก 2024	เราทราบดีว่าผู้ทดสอบจะต้องใช้กลุ่มเบราว์เซอร์ที่มีป้ายกำกับสำหรับการทดสอบและการประสานงานต่อไป แม้ว่าการทดสอบที่อำนวยความสะดวกโดย Chrome ในปี 2024 จะสิ้นสุดลงแล้ว เรากำลังประเมินขั้นตอนถัดไปสำหรับป้ายกำกับตามประกาศทางเลือกของผู้ใช้ ในระหว่างนี้ ทีม Chrome ได้เผยแพร่ความตั้งใจเพื่อขยายการรองรับกลุ่มเบราว์เซอร์ที่ติดป้ายกำกับผ่าน Chrome Milestone 132 ไปจนถึงเดือนมกราคม 2025
Privacy Sandbox ใน Android	Privacy Sandbox ใน Android และ Privacy Sandbox ใน Chrome เชื่อมโยงกันอย่างแยกไม่ออก และเราไม่สามารถประเมิน Privacy Sandbox ได้อย่างถูกต้องหากไม่มี Android เส้นทางของลูกค้าทั่วไปซึ่งเกี่ยวข้องกับอุปกรณ์หลายเครื่องและหลายทัชพอยต์มีความสําคัญต่อทั้ง Privacy Sandbox ใน Chrome และ Privacy Sandbox ใน Android	โปรดทราบว่า Privacy Sandbox ใน Android ไม่อยู่ในขอบเขตสัญญาผูกมัดของ Google ต่อ CMA หากความคิดเห็นนี้เกี่ยวกับไทม์ไลน์และการเปิดตัวของ Android โดยเฉพาะ เราก็ไม่มีข้อมูลอัปเดตที่จะแชร์ในตอนนี้ นอกเหนือจากความคืบหน้าของ Android ซึ่งเราถือว่าเป็นสตรีมงานอิสระเพื่อปรับปรุงความเป็นส่วนตัว ดังที่ได้แจ้งไปก่อนหน้านี้ ความพร้อมใช้งานของ Privacy Sandbox API ใน Android จะขึ้นอยู่กับอัตราการอัปเดตอุปกรณ์ของผู้ใช้ด้วย ซึ่ง Google ไม่สามารถควบคุมได้
โหมด ข การเข้าชมถูกจํากัด	การเข้าชมจากการประมูลโฆษณาที่มีให้จากโหมด B ต่ำกว่าที่คาดไว้	มีหลายสาเหตุที่ปริมาณการประมูลสำหรับ Protected Audience API (PA API) อาจต่ำกว่าที่คาดไว้ เช่น - บริษัทที่เรารู้จักซึ่งผสานรวม PA API ได้รวมเฉพาะรูปแบบแบนเนอร์เท่านั้น - แพลตฟอร์มฝั่งขายอาจไม่ได้เริ่มการประมูลเสมอไป - เบราว์เซอร์อาจไม่มีกลุ่มความสนใจ (IG) - อาจไม่มีการเสนอราคา อย่างไรก็ตาม เราไม่ทราบว่ามีผู้ใช้รายใดพยายามทดสอบ PA API แต่ไม่ได้รับการเข้าชม
ระดับการมองเห็นการหยุดทำงาน	ระดับการเข้าถึงเกี่ยวกับการหยุดทำงานและปัญหาที่ส่งผลต่อ Privacy Sandbox API	มี หน้าสถานะสาธารณะสำหรับ Privacy Sandbox API ที่มีบริการนอกเบราว์เซอร์ ทีม Chrome ให้ความสำคัญกับความน่าเชื่อถือของแพลตฟอร์มและ API ที่สำคัญทั้งหมดที่เว็บไซต์และบริการหลักๆ ทั่วทั้งเว็บใช้ รวมถึงเทคโนโลยี Privacy Sandbox เป็นลำดับต้นๆ จนถึงตอนนี้มีการหยุดทำงานเพียงครั้งเดียว ปัญหานี้เกี่ยวข้องกับการกำหนดค่าชั่วคราวสำหรับการทดสอบที่ 1% อีกไม่นานเราจะไม่ต้องใช้การกำหนดค่าเวอร์ชันทดลองที่เกี่ยวข้องกับการหยุดทำงานนี้อีกต่อไป เราจึงมั่นใจว่าปัญหานี้จะไม่เกิดขึ้นเมื่อเปิดใช้ API ในลักษณะปกติใน Chrome
การศึกษากราฟคุกกี้	Chrome มองเมธอด CookieGraph อย่างไรตามที่อธิบายไว้ในเอกสารนี้ภายในเฟรมเวิร์ก Privacy Sandbox	บทความฉบับนี้ชี้ให้เห็นประเด็นที่น่าสนใจเกี่ยวกับการตรวจจับและความแพร่หลายของคุกกี้ของบุคคลที่หนึ่ง (1P) ซึ่งกำหนดโดยโดเมนที่แตกต่างจากโดเมนที่ผู้ใช้เข้าชม ดังที่บทความชี้ให้เห็น คุกกี้เหล่านี้มีประโยชน์อย่างยิ่งในการรวบรวมข้อมูลวิเคราะห์และข้อมูลเกี่ยวกับวิธีที่ผู้ใช้โต้ตอบกับเว็บไซต์ ข้อมูลนี้มีความสำคัญต่อนักพัฒนาซอฟต์แวร์ในการมอบประสบการณ์การท่องเว็บที่ดียิ่งขึ้นให้แก่ผู้ใช้ การโต้แย้งหลักของบทความนี้มีข้อบกพร่องเนื่องจากถือว่าคุกกี้ของบุคคลที่หนึ่งเป็นเวกเตอร์การติดตามข้ามเว็บไซต์ อย่างไรก็ตาม ข้อมูลนี้ใช้ได้เฉพาะภายใต้สมมติฐานที่รุนแรงมากซึ่งระบุไว้ในบทความ ผู้ใช้ยินดีแชร์ PII กับเว็บไซต์ อุปกรณ์มีลายนิ้วมือที่เสถียรซึ่งสามารถใช้ติดตามผู้ใช้ในเว็บไซต์ต่างๆ ได้ โปรดทราบว่าสิ่งเหล่านี้เป็นเวกเตอร์ของการระบุตัวตนอีกครั้งที่อาจถูกนำไปใช้ประโยชน์ได้โดยไม่ต้องใช้คุกกี้ของบุคคลที่หนึ่ง (เช่น ผ่านการแชร์ข้อมูลจากฝั่งเซิร์ฟเวอร์) และต้องจัดการแยกจากแนวทางที่เราดำเนินการอยู่ในปัจจุบันซึ่งมุ่งเน้นที่กลไกการติดตามตามสถานะ เช่น 3PC สุดท้ายนี้ เราขอชี้แจงว่าบทความดังกล่าวระบุว่าคุกกี้วิเคราะห์และคุกกี้โฆษณาเทียบเท่ากับคุกกี้การติดตาม และคุกกี้ที่จําเป็นอย่างยิ่งเทียบเท่ากับคุกกี้ที่ไม่ติดตาม ซึ่งอาจไม่ใช่เช่นนั้นเสมอไป ข้อมูลวิเคราะห์ของบุคคลที่หนึ่งหรือบริการของผู้ให้บริการที่มีการแบ่งพาร์ติชันตามเว็บไซต์ เช่น วิดเจ็ตระบุตำแหน่งร้านค้า วิดเจ็ตแชท หรือคุกกี้ของโปรแกรมควบคุมโหลด มักจำกัดไว้ที่โดเมนเดียว และในทางกลับกัน คุกกี้ที่จําเป็นอย่างยิ่งบางรายการอาจเป็นการติดตามข้ามเว็บไซต์เพื่อวัตถุประสงค์ในการป้องกันการประพฤติมิชอบ
การเปลี่ยนแปลง UX	การเปลี่ยนแปลง UX ใน Chrome 112 ซึ่งวางการควบคุมคุกกี้ของบุคคลที่หนึ่งไว้ในส่วน "ข้อมูลเว็บไซต์ในอุปกรณ์" ของการตั้งค่า Chrome อาจทําให้ผู้ใช้บล็อกคุกกี้ทั้งหมดได้ยากขึ้น	การเปลี่ยนแปลงนี้เกิดขึ้นเพื่อแยกและยกระดับการควบคุม 3PC (หรือพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชัน) ออกจากข้อมูลเว็บไซต์ประเภทอื่นๆ ทั้งหมด การควบคุม 3PC จะอยู่ในแผงความเป็นส่วนตัวและความปลอดภัย ส่วนการควบคุมคุกกี้ของบุคคลที่หนึ่งและข้อมูลเว็บไซต์ประเภทอื่นๆ ทั้งหมด ซึ่งฟังก์ชันการทำงานที่สำคัญของเว็บไซต์มักต้องใช้ จะรวมอยู่ใน "ข้อมูลเว็บไซต์ในอุปกรณ์" เราจะติดตามความคิดเห็นเกี่ยวกับเรื่องนี้ต่อไป แต่เชื่อว่าการแยกส่วนในปัจจุบันช่วยให้ผู้ใช้ค้นพบการควบคุมความเป็นส่วนตัวที่มีความหมายได้ และคงประสบการณ์การท่องเว็บที่ใช้งานได้
การเรียกเก็บเงินและการชําระเงิน	การเรียกเก็บเงินและการชําระเงินยังไม่ได้รับการทดสอบอย่างเต็มรูปแบบ เนื่องจากผู้ทดสอบมุ่งเน้นที่การทดสอบด้านอื่นๆ ของ Privacy Sandbox API มากกว่า	เวลาและส่วนที่นักพัฒนาซอฟต์แวร์และบริษัทเลือกที่จะทดสอบคือทางเลือกของตน API พร้อมให้ใช้งานในเวอร์ชันสำหรับผู้ใช้ทั่วไปแล้วตั้งแต่เดือนกันยายน 2023
การทดสอบ	การเข้าชมจากการทดสอบที่ DSP ได้รับจาก SSP ไม่ได้ติดป้ายกำกับเสมอไป DSP บางรายได้ส่งข้อมูลว่าส่วนแบ่งการแสดงผลการทดสอบที่ไม่มีป้ายกำกับอาจแตกต่างกันไปในกลุ่มทดสอบและกลุ่มควบคุม	Chrome ไม่สามารถควบคุมได้ว่าบริษัทจะส่งต่อป้ายกำกับในคำขอราคาเสนอหรือไม่ เรามีวิธีการรับป้ายกำกับจากเบราว์เซอร์ จากนั้นระบบนิเวศจะเป็นผู้ส่งป้ายกำกับไปยังพาร์ทเนอร์ หากพาร์ทเนอร์ไม่สามารถอ่านป้ายกำกับเหล่านั้นได้โดยตรง
3PCD ใน Android WebView	ขอคําแนะนําเกี่ยวกับการเปิดใช้ Flag "ทดสอบการเลิกใช้งานคุกกี้ของบุคคลที่สาม" ใน Android WebView เพื่อทดสอบการเลิกใช้งาน	3PC จะถูกบล็อกโดยค่าเริ่มต้นใน Android WebView
Differential Privacy เพื่อลดความเสี่ยงในการฝึกโมเดล	เหตุใดจึงใช้ Differential Privacy ในการฝึกโมเดล	ความเป็นส่วนตัวแบบที่แตกต่างกันเมื่อใช้ร่วมกับสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) เป็นสิ่งจําเป็นในการฝึกโมเดลเพื่อป้องกันการรั่วไหลของข้อมูลและรักษาข้อมูลที่ละเอียดอ่อนให้ปลอดภัยจากภัยคุกคาม วิธีนี้ช่วยให้มั่นใจได้ว่าน้ำหนักของโมเดลจะไม่เปิดเผยข้อมูลผู้ใช้แต่ละราย

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การลงทะเบียน	ขอคำชี้แจงเกี่ยวกับวิธีการทำงานของการลงทะเบียนการรับรองระหว่างต้นทางที่ลงทะเบียนกับต้นทางของเทคโนโลยีโฆษณาที่มีโดเมนย่อย www	เทคโนโลยีโฆษณาจะต้องเริ่มใช้งานในวันที่ https://example.com เท่านั้น เมื่อมีการรับรองใน https://example.com/.well-known/privacy-sandbox-attestations.json ระบบจะครอบคลุม https://www.example.com ด้วยเนื่องจากเป็นโดเมนย่อย
ข้อกำหนดของ API	คำแนะนำในการเพิ่มสคีมา JSON สำหรับไฟล์เอกสารรับรองไปยังที่เก็บ	เรากำลังประเมินคำแนะนำนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่

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

หัวข้อ

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การถ่วงน้ำหนักหัวข้อ	สิ่งสำคัญที่สุดที่ต้องทำความเข้าใจใน Topics คือความหายากของสัญญาณหนึ่งๆ การออกแบบปัจจุบันควรพัฒนาเพื่อให้สามารถเพิ่มค่าน้ำหนักข้างหัวข้อที่สังเกตได้แต่ละรายการ น้ำหนักจะเป็นน้ำหนักสัมพัทธ์ของหัวข้อหนึ่งๆ สําหรับเบราว์เซอร์หนึ่งๆ เมื่อเทียบกับเบราว์เซอร์ทั้งหมดที่ใช้หัวข้อนั้น	เราต้องการทำความเข้าใจเพิ่มเติมว่าเหตุใดความหายากของสัญญาณจึงเป็นสัญญาณที่สำคัญที่สุด เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศเกี่ยวกับประโยชน์ของกรณีการใช้งานนี้ที่นี่
ความน่าเชื่อถือของหัวข้อ	Google จำเป็นต้องให้การรับรองที่ชัดเจนยิ่งขึ้นเกี่ยวกับความน่าเชื่อถือของ Topics เมื่อเวลาผ่านไป	เราจะเปลี่ยนแปลง API ต่อไปตามความคิดเห็นที่ได้รับจากระบบนิเวศ และจะพูดคุยเรื่องนี้แบบสาธารณะก่อนการเปลี่ยนแปลง ข้อเสนอของเราสำหรับโครงสร้างการกำกับดูแลที่ปรับปรุงใหม่จะให้การรับรองเพิ่มเติม
ตัวแยกประเภท	เว็บไซต์ของผู้เผยแพร่โฆษณามักได้รับการจัดประเภทไม่ถูกต้องหรือถูกกำหนด Topics ในระดับที่มากเกินกว่าที่จะบรรลุวัตถุประสงค์สำคัญได้	ตามที่ระบุไว้ในคำอธิบายเกี่ยวกับการแยกประเภท Topics เว็บไซต์ได้รับการจัดประเภทโดยใช้ทั้งรายการการลบล้างที่ดูแลจัดการโดยเจ้าหน้าที่ซึ่งมีเว็บไซต์ยอดนิยมที่สุด และโมเดลแมชชีนเลิร์นนิงในอุปกรณ์ Chrome จะประเมินตัวเลือกสำหรับเว็บไซต์ที่จะมีส่วนร่วมในการจัดประเภท Topics ต่อไป การปรับปรุงยูทิลิตีต้องชั่งน้ำหนักกับความเสี่ยงด้านความเป็นส่วนตัวและการละเมิด ตัวอย่างความเสี่ยงบางส่วนมีดังนี้ - เว็บไซต์ที่ใช้การติดป้ายกำกับด้วยตนเองเป็นวิธีการเข้ารหัสความหมายที่แตกต่างกัน (และอาจเป็นเรื่องละเอียดอ่อน) ลงในหัวข้อ และ - เว็บไซต์ที่โจมตีหัวข้อเพื่อลดความมีประโยชน์ของหัวข้อสำหรับผู้อื่น (เช่น การส่งสแปมหัวข้อของผู้ใช้ด้วยเนื้อหาที่ไม่มีความหมาย) บุคคลทั่วไปสามารถตรวจสอบคอมโพเนนต์เหล่านี้ได้ด้วยเครื่องมือที่พร้อมให้ใช้งานใน chrome://topics-internals หรือ Colab นี้ จากการทดสอบ เราคาดหวังว่าการจัดหมวดหมู่จะดีขึ้นเมื่อเวลาผ่านไป และเรายินดีรับฟังความคิดเห็นเกี่ยวกับตัวอย่างเว็บไซต์ที่อาจถูกจัดอยู่ในหมวดหมู่ที่ไม่ถูกต้อง
คำถามเกี่ยวกับ API	ข้อกังวลที่ว่า Topics API ให้สิทธิประโยชน์ที่คงอยู่และขัดต่อการแข่งขันแก่ SSP ที่สร้างรายได้จากเนื้อหาที่ไม่ดี	เช่นเดียวกับ 3PC เบราว์เซอร์จะไม่สนใจว่าใครเป็นผู้ได้รับ Topics ตราบใดที่บุคคลนั้นลงทะเบียนและได้รับการรับรอง
(รายงานในไตรมาสก่อนหน้าด้วย) ประโยชน์สําหรับ ผู้มีส่วนเกี่ยวข้อง ประเภทต่างๆ	เนื่องจากปัจจุบันตัวจัดประเภท Topics ใช้เพียงชื่อโฮสต์ของหน้าเว็บเพื่อกำหนดหัวข้อที่เกี่ยวข้อง เว็บไซต์ขนาดใหญ่ที่มีเนื้อหาหลากหลายจึงมีส่วนร่วมในหัวข้อทั่วไป ขณะที่เว็บไซต์ขนาดเล็กมีส่วนร่วมในหัวข้อเฉพาะกลุ่มที่มีมูลค่าการโฆษณามากกว่า	คําตอบของเราคล้ายกับในไตรมาสก่อน เช่นเดียวกับ 3PC ข้อมูลที่มีคุณค่าซึ่งได้จากเว็บไซต์ต่างๆ จะแตกต่างกันไป เว็บไซต์ที่มีความสนใจเฉพาะกลุ่มให้คุณค่าอย่างไม่สอดคล้องกัน เนื่องจากเว็บไซต์ที่มีความสนใจเฉพาะกลุ่มบางแห่งไม่มีบริบทที่มีคุณค่าเชิงพาณิชย์ จึงให้คุณค่าน้อยกว่า เว็บไซต์เหล่านี้จะได้รับประโยชน์จาก Topics API เราได้พิจารณาความเป็นไปได้ในการแยกระดับหน้าเว็บแทนระดับเว็บไซต์ แต่การแยกระดับดังกล่าวมีข้อกังวลด้านความเป็นส่วนตัวและความปลอดภัยที่สำคัญหลายประการ
ตัวแยกประเภท	เว็บไซต์ขนาดเล็กมักได้รับการจัดประเภทที่ไม่ถูกต้องหรือไม่ได้รับการจัดประเภท จึงไม่สามารถเข้าร่วมการแลกเปลี่ยนมูลค่าได้	เกี่ยวกับอันตรายที่ถูกกล่าวหา เว็บไซต์หนึ่งๆ ซึ่งอาจถูกจัดประเภทอย่างไม่ถูกต้องจะไม่ได้รับอันตรายจากสิ่งนี้มากกว่าเว็บไซต์อื่นๆ เนื่องจากข้อมูลบริบทของเว็บไซต์จะพร้อมใช้งานสำหรับการประมูลในเว็บไซต์ของตนเสมอ ซึ่งจะให้ข้อมูลที่ใกล้เคียงกับหัวข้อที่ถูกต้อง แม้ว่าจะเป็นกรณีที่ผิดประเภทก็ตาม โดยปกติแล้ว หัวข้อจะใช้เพื่อรวบรวมข้อมูลการโฆษณาที่อาจเป็นประโยชน์จากเว็บไซต์ภายนอกแทนเว็บไซต์ของตนเอง
เวอร์ชันการจัดหมวดหมู่	เราจะเข้าถึงเวอร์ชันการจัดหมวดหมู่เพื่อให้แน่ใจว่าเข้ากันได้กับเวอร์ชันเก่าได้อย่างไร	เวอร์ชันการจัดหมวดหมู่เป็นส่วนหนึ่งของส่วนหัวคำขอที่ส่งไปพร้อมกับคำขอดึงข้อมูลซึ่งเปิดใช้ Topics เช่น หากส่วนหัวคือ "(1 2);v=chrome.1:2:5, ();p=P000000000" เวอร์ชันคือ chrome.1:1:2 โดยที่ chrome.1 คือเวอร์ชันการกําหนดค่า, 2 คือเวอร์ชันการจัดหมวดหมู่ และ 5 คือเวอร์ชันโมเดล ข้อมูลนี้อธิบายไว้ในข้อกำหนดและเพิ่มไว้ในคำอธิบายด้วย
ข้อมูล Topics	ขอคำชี้แจงเกี่ยวกับวิธีอัปเดตข้อมูล Topics	ไม่ได้ระบุการอัปเดตการจัดหมวดหมู่ ซึ่งช่วยให้ผู้ให้บริการเบราว์เซอร์มีความยืดหยุ่นในการใช้งาน อย่างไรก็ตาม ต่อไปนี้เป็นแนวทางในการอัปเดตการจัดหมวดหมู่ของ Chrome จาก V1 เป็น V2 - ระบบจะดูแลรักษาต้นไม้การจัดหมวดหมู่เดียวสำหรับหัวข้อจากทั้ง V1 และ V2 - รหัสหัวข้อเดียวกันมีความหมายเดียวกัน - ต้นไม้จะเติบโตขึ้นเรื่อยๆ โดยเพิ่มหัวข้อหรือการเชื่อมต่อใหม่ๆ แต่จะไม่มีการหดตัว - อย่างไรก็ตาม หัวข้อหรือลิงก์บางรายการอาจ "ไม่ได้ใช้งาน" ในเวอร์ชันหนึ่ง ซึ่งอาจทำให้ดูเหมือนว่ามีการลบหรือจัดระเบียบใหม่ ตัวอย่าง - ตอนนี้ "รถกระบะ" มี "รถบรรทุก รถตู้ และ SUV" เป็นผู้ปกครองระดับกลางแล้ว - ตอนนี้ "การศึกษาภาษาต่างประเทศ" มี "การศึกษา" เป็นรายการหลักลำดับที่ 2 และรายการหลักเดิมอย่าง "ข้อมูลอ้างอิง" จะใช้งานไม่ได้ ผลกระทบของหัวข้อ "ไม่ได้ใช้งาน": ระบบจะไม่ใช้หัวข้อเหล่านี้ในการแยกประเภทใหม่ อย่างไรก็ตาม ระบบจะยังคงพิจารณาหัวข้อย่อยเหล่านี้เมื่อบังคับใช้การบล็อกของผู้ใช้ หากผู้ใช้บล็อกหัวข้อในเวอร์ชัน 1 หัวข้อย่อยของหัวข้อนั้นจะยังคงถูกบล็อกในเวอร์ชัน 2 (แม้ว่าหัวข้อย่อยจะปรากฏภายใต้หัวข้อหลักอื่นในเวอร์ชัน 2)
ตัวแยกประเภท	ต้องการทำความเข้าใจสาเหตุและตัวเลือกการแก้ไขที่มีเกี่ยวกับการจัดประเภทที่ผิดพลาด	ก่อนอื่น เราขอชี้แจงว่าการกำหนดหัวข้อของเว็บไซต์โดย Chrome มีไว้เพื่อใช้เป็นอินพุตสำหรับอัลกอริทึมของ Topics เพื่อกำหนดความสนใจของผู้ใช้เพื่อวัตถุประสงค์ในการโฆษณาเท่านั้น ไม่ได้พัฒนาขึ้นเพื่อวัตถุประสงค์การจัดประเภทอื่นๆ ทั่วไป เราให้ความสำคัญกับความถูกต้องโดยรวมของรูปแบบการจัดประเภท และพยายามปรับปรุงความแม่นยำ/ความอ่อนไหวเมื่อทำได้ แต่ให้ความสำคัญกับความแม่นยำในระดับโลกเมื่อเทียบกับระดับการจัดประเภทเว็บไซต์แต่ละระดับ เนื่องจากการจัดประเภทที่ไม่ถูกต้อง (หากเกิดขึ้น) จะไม่ส่งผลเสียต่อเว็บไซต์ที่การจัดประเภทไม่ถูกต้อง แต่จะทำให้สัญญาณ Topics มีคุณภาพลดลงเมื่อเลือกโฆษณาในเว็บไซต์อื่นๆ เมื่อเลือกโฆษณาในเว็บไซต์ที่มีการจัดประเภทไม่ถูกต้อง เว็บไซต์นั้นจะรู้หัวข้อจริงของเว็บไซต์อยู่แล้ว และสามารถใช้เป็นอินพุตในการค้นหาโฆษณาได้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การทดสอบ API	Topics และ Privacy Sandbox API โดยทั่วไปสามารถทดสอบกับ Chromium ได้ไหม	Topics API ไม่ได้มาพร้อมกับ Chromium แต่จัดส่งมาพร้อมกับ Chrome
ผู้โทรหัวข้อ	คำขอปรับปรุงมูลค่าเพิ่มของ Topics โดยใช้บริการ TEE สำหรับเทคโนโลยีโฆษณาเพื่อรองรับค่าใช้จ่ายในการวิเคราะห์ขั้นสูงในลักษณะที่เป็นไปตามนโยบายความเป็นส่วนตัว	เราได้ตอบกลับความคิดเห็นที่คล้ายกันที่นี่ เราได้พิจารณาความถี่ผกผัน และสุดท้ายหลังจากสร้างรูปแบบความถี่ผกผันแล้ว เราพบว่าความถี่ผกผันนั้นไม่สัมพันธ์กับมูลค่าของหัวข้อมากนักตามมูลค่าที่ผู้ซื้อและผู้ขายระบุ เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ข้อกำหนดของ API	การตั้งค่ากลุ่มความสนใจของเบราว์เซอร์จะบล็อก Topics API ได้ไหม	เราได้ตอบกลับความคิดเห็นนี้ที่นี่ Topics API เป็นการพัฒนาของ FLoC และเป็นไปตามนโยบายสิทธิ์ของ FLoC ตามที่ระบุไว้ในคำอธิบาย "หมายเหตุ: Permissions-Policy เดิม:Interest-cohort=() จาก FLoC จะไม่อนุญาตการคำนวณหัวข้อด้วย"
การจัดอันดับหัวข้อ	เมื่อได้รับ "หัวข้อ 5 อันดับแรก" เราจะนับความถี่ของการเข้าชมเว็บไซต์ตามผู้โทรที่มีสิทธิ์แต่ละคน หรือจะนับตามประวัติการเข้าชมทั้งหมดของเบราว์เซอร์ นอกจากนี้ หัวข้อจะได้รับการจัดอันดับเพิ่มเติมสำหรับผู้โทรแต่ละรายแยกกันหรือไม่	ซึ่งจะอิงตามความถี่ของประวัติการท่องเว็บชุดย่อย รายการประวัติการท่องเว็บ (หน้า) จะมีสิทธิ์เข้าร่วมก็ต่อเมื่อหน้าเว็บมี Topics Call อย่างน้อย 1 คน ดูรายละเอียดเพิ่มเติมเกี่ยวกับพื้นที่เก็บข้อมูลประวัติหัวข้อได้ที่นี่ การจัดอันดับจะขึ้นอยู่กับความถี่และระดับความสำคัญแบบ 2 ค่า (ดูรายละเอียดเพิ่มเติมได้ที่ที่นี่และที่นี่) ตามที่ระบุไว้ในประกาศเกี่ยวกับการปรับปรุง Topics API อย่างไรก็ตาม จำนวนดังกล่าวไม่ได้ขึ้นอยู่กับความถี่ของผู้โทร โปรดทราบว่าไม่ได้หมายความว่าผู้โทรทุกคนจะดูหัวข้อยอดนิยม 5 อันดับแรกได้ใน Epoch ถัดไป ตามที่ระบุไว้ในคำอธิบาย "มีเพียงผู้เรียกที่สังเกตเห็นผู้ใช้เข้าชมเว็บไซต์เกี่ยวกับหัวข้อที่เป็นปัญหาภายใน 3 สัปดาห์ที่ผ่านมาเท่านั้นที่จะรับหัวข้อได้" เบราว์เซอร์ไม่จำเป็นต้องติดตามว่าผู้โทรดูหัวข้อยอดนิยม 5 อันดับแรก (สอดคล้องกับหัวข้อ 5 อันดับแรกที่มีโดเมนของผู้โทรในข้อมูลจำเพาะ) เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้ที่นี่

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
(รายงานในไตรมาสก่อนหน้าด้วย) ค่าใช้จ่าย	การใช้ TEE ในระบบคลาวด์สาธารณะมีค่าใช้จ่ายสูงกว่าเมื่อเทียบกับศูนย์ข้อมูลเทคโนโลยีโฆษณาในสถานที่ตั้งจริงหรือไม่	โมเดลความปลอดภัย TEE ปัจจุบันของเราได้รับประโยชน์จากแนวทางปฏิบัติของการติดตั้งใช้งานระบบคลาวด์สาธารณะ (ดูรายละเอียดเพิ่มเติมในคำอธิบายข้อกำหนดของ TEE ระบบคลาวด์สาธารณะ) ตัวอย่างเช่น TEE ที่ใช้ฮาร์ดแวร์ในปัจจุบันไม่สามารถป้องกันการโจมตีทางกายภาพทั้งหมด AWS และ GCP ผู้ให้บริการระบบคลาวด์สาธารณะที่เรารองรับอยู่แล้ว ได้รับการออกแบบและดำเนินการลดความเสี่ยงในการเข้าถึงร่างกาย รวมถึงการดำเนินการจากพนักงาน แม้ว่าเทคโนโลยีโฆษณาบางรายการจะแจ้งให้เราทราบว่าการใช้บริการระบบคลาวด์มีค่าใช้จ่ายสูงกว่าศูนย์ข้อมูลเทคโนโลยีโฆษณาในองค์กร แต่เทคโนโลยีโฆษณาอื่นๆ ก็ทํางานบนระบบคลาวด์สาธารณะ ไม่ว่าจะเป็นเพื่อประหยัดค่าใช้จ่ายหรือเพื่อประโยชน์อื่นๆ เราจะยังคงประเมินตัวเลือกในการขยายการสนับสนุน TEE ของเราต่อไป ซึ่งรวมถึงภายนอกระบบคลาวด์สาธารณะ ด้วยเหตุนี้ เราจึงค้นคว้าเกี่ยวกับศูนย์ข้อมูลในสถานที่ตั้ง และมีส่วนร่วมกับระบบนิเวศเพื่อสำรวจโซลูชันที่เป็นไปได้ในการให้การสนับสนุนดังกล่าว ในขั้นตอนของการวิจัยในปัจจุบัน เราไม่สามารถรับประกันได้ว่าวิธีนี้จะทำให้เกิดโซลูชันที่ใช้งานได้สำหรับระบบนิเวศ
PA API และ Google Ad Manager (GAM)	GAM ไม่สามารถบรรลุผลลัพธ์ที่เป็นธรรมในตลาด GAM แสดงโฆษณาไม่ทันท่วงที รายงานจํานวนโฆษณาที่แสดงโดยใช้ PA API และไม่เสนอการกำหนดค่าว่าจะใช้เมธอดใดเพื่อแสดงโฆษณา เช่น ปิด PA API สําหรับบางช่อง	คําตอบจาก Google Ad Manager: GAM พยายามเพิ่มประสิทธิภาพเวลาในการตอบสนองเมื่อแสดงโฆษณาผ่าน PA API อย่างต่อเนื่องเพื่อให้รายได้เพิ่มเติมที่ได้จากผู้เผยแพร่โฆษณาจากดีมานด์ PA API มากกว่าต้นทุนที่เกิดขึ้นจากเวลาในการตอบสนองในการประมูล PA API เพิ่มเติม การทดสอบเบื้องต้นของเราแสดงให้เห็นว่าผู้เผยแพร่โฆษณาได้รับรายได้สุทธิจาก PA API ในการเข้าชมโดยไม่มีบุคคลที่สาม ซึ่งแสดงให้เห็นว่าความต้องการเพิ่มเติมจาก PA API นั้นสูงกว่าต้นทุนใดๆ ที่เกิดจากเวลาในการตอบสนอง ดูรายละเอียดเพิ่มเติมเกี่ยวกับแนวทางของเราได้ในคำถามที่พบบ่อย นอกจากนี้ GAM ยังให้บริการรายงานสำหรับผู้เผยแพร่โฆษณาเกี่ยวกับโฆษณาที่แสดงผ่าน PA API ด้วย ซึ่งรวมถึงโฆษณาที่แสดงเมื่อ GAM เป็นผู้ขายคอมโพเนนต์ และโฆษณาที่แสดงผ่านผู้ขายคอมโพเนนต์รายอื่นๆ เมื่อ GAM เป็นผู้ขายระดับบนสุด ดูรายละเอียดเพิ่มเติมเกี่ยวกับการรายงานได้ในศูนย์ช่วยเหลือ สุดท้ายนี้ GAM อนุญาตให้ผู้เผยแพร่โฆษณาเปิดใช้หรือปิดใช้ PA API กับการเข้าชมของตนผ่านการควบคุมใน UI (ดูรายละเอียดในศูนย์ช่วยเหลือ) เรายินดีพิจารณาความคิดเห็นเกี่ยวกับการควบคุมเพิ่มเติมที่ผู้เผยแพร่โฆษณาอาจต้องการ และจะจัดลําดับความสําคัญของคําขอฟีเจอร์ให้สอดคล้องกับกระบวนการจัดลําดับความสําคัญของฟีเจอร์มาตรฐาน
PA API และ GAM/AdX	ดูเหมือนว่า Google จะยึดถือแนวทางที่จะไม่ซื้อการแสดงผล PA API ใดๆ ที่ GAM ไม่ได้เป็นผู้ตัดสินใจขายขั้นสุดท้าย เช่นเดียวกับที่ AdWords ซื้อเฉพาะจากในแพลตฟอร์ม การดำเนินการนี้ดูเหมือนว่าเป็นการละเมิดตำแหน่งทางการตลาดอย่างแท้จริง เนื่องจาก GAM/AdX สามารถส่งการกำหนดค่าการประมูลคอมโพเนนต์ไปยังผู้ขายระดับบนรายอื่นได้เช่นเดียวกับพาร์ทเนอร์ Exchange รายอื่นๆ	คําตอบจากผู้จัดการแพลตฟอร์ม Google Ads: นี่ไม่ใช่จุดยืนของ Google แพลตฟอร์มฝั่งซื้อของ Google (Google Ads และ DV360) ซื้อการแสดงผลจากการแลกเปลี่ยนที่ไม่ใช่ของ Google ซึ่งจะเป็นแบบนี้สําหรับทั้งการแสดงผล PA API และการแสดงผลที่ไม่ใช่ PA API
การตอบสนองของตลาด	ข้อกังวลของ Mozilla: กลุ่มเป้าหมายที่ได้รับการคุ้มครองของ Google ปกป้องผู้ลงโฆษณา (และ Google) มากกว่าที่จะปกป้องคุณ	ขอขอบคุณสำหรับการประเมินของ Mozilla และเราจะมีส่วนร่วมกับความคิดเห็นของ Mozilla ในฟอรัมมาตรฐานสาธารณะต่อไป ประเด็นการประเมินคือการใช้งาน PA API ในปัจจุบันยังไม่ได้บังคับใช้การป้องกันทั้งหมดที่วางแผนไว้ แนวทางในการเปิดตัว PA API ของเรามุ่งเน้นที่การสร้างความสมดุลที่เหมาะสมระหว่างการส่งเสริมการใช้งานและการใช้การคุ้มครองความเป็นส่วนตัวโดยเร็วที่สุด ด้วยเหตุนี้ เราจึงได้จัดทำแผนงานในการบังคับใช้ข้อจำกัดด้านความเป็นส่วนตัวในอนาคต เพื่ออำนวยความสะดวกในการผสานรวมกับ API ให้ดียิ่งขึ้น รวมถึงเพื่อให้เรามีเวลารวบรวมความคิดเห็นเพิ่มเติมเพื่อนำไปใช้ในการปกป้องความเป็นส่วนตัวในอนาคต (เช่น ฟีเจอร์ VAST ในเฟรมที่มีการกำหนดเขต) เรายินดีรับฟังการสื่อสารล่าสุดของ Mozilla เกี่ยวกับแนวทางด้านความเป็นส่วนตัวและการโฆษณาดิจิทัลของตนด้วย ซึ่งได้แก่ "อินเทอร์เน็ตที่เสรีและเปิดกว้างไม่ควรแลกมาด้วยความเป็นส่วนตัว" และ "การปรับปรุงการโฆษณาออนไลน์ผ่านผลิตภัณฑ์และโครงสร้างพื้นฐาน"
(รายงานในไตรมาสก่อนหน้าด้วย) ผลลัพธ์การประมูล	คำขอการประมูลครั้งเดียวเพื่อส่ง URL การแสดงผลหลายรายการพร้อมคะแนนที่สอดคล้องกัน ทำให้โฆษณาแบบเนทีฟกรองข้อมูลที่ซ้ำกันออกได้ง่ายขึ้นและหลีกเลี่ยงปัญหา UX และเวลาในการตอบสนอง	คำตอบของเราคล้ายกับไตรมาสที่แล้ว เราพิจารณาใช้ RenderURL หลายรายการและคะแนนที่เกี่ยวข้องจากการประมูล PA API เพียงครั้งเดียว แต่ก็ไม่ได้นำมาใช้เนื่องจากข้อกังวลเกี่ยวกับความเป็นส่วนตัว เราเข้าใจดีว่าคุณต้องการหลีกเลี่ยงการแสดงโฆษณาเดิมต่อผู้ใช้หลายครั้งในหน้าเดียว และกำลังประเมินคําขอนี้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศที่นี่เกี่ยวกับการสนับสนุนเพิ่มเติมที่จำเป็นใน PA API เพื่อรองรับกรณีการใช้งานโฆษณาเนทีฟอย่างเหมาะสม
ประสิทธิภาพ	ข้อกังวลเกี่ยวกับเวลาในการตอบสนองที่ส่งผลต่อ PA API	เราทราบดีถึงความกังวลเกี่ยวกับเวลาในการตอบสนอง และนี่เป็นหนึ่งในเหตุผลที่เราได้พัฒนาฟีเจอร์ต่างๆ เป็นส่วนหนึ่งของ PA API ซึ่งจะช่วยให้ SSP กำหนดขีดจำกัดเวลาในการตอบสนองของ DSP รวมถึงทำการปรับปรุงเพื่อลดเวลาในการตอบสนองได้ เมื่อเร็วๆ นี้เราได้อัปเดต คู่มือแนวทางปฏิบัติแนะนำสำหรับเวลาในการตอบสนอง ซึ่งมีข้อมูลเพิ่มเติมเกี่ยวกับวิธีใช้ประโยชน์จากฟีเจอร์เหล่านี้ นอกจากนี้ เรายังพัฒนาการปรับปรุงเวลาในการตอบสนองใหม่ๆ อย่างต่อเนื่อง ซึ่งบางส่วนดูได้ ที่นี่
ผู้ขายระดับบนสุด	Google ควรเปิดให้ผู้เผยแพร่โฆษณาเลือกผู้ขายการประมูล PA API ระดับบนสุดรายอื่น	PA API จะไม่สนใจว่าใครเป็นผู้เริ่มการประมูล ทั้งในรูปแบบผู้ขายรายเดียวและผู้ขายหลายราย แต่ละบริษัทมีสิทธิ์เลือกว่าจะรองรับการประมูลผ่าน PA API หรือไม่ และรองรับอย่างไร
(รายงานในไตรมาสก่อนหน้าด้วย) การกำหนดเป้าหมายเชิงลบ	ขอวิธีแก้ปัญหาสำหรับกรณีการใช้งานที่ผู้ลงโฆษณาไม่ต้องการแสดงโฆษณาต่อกลุ่มเป้าหมายบางกลุ่ม	เรารองรับการกำหนดเป้าหมาย IG เชิงลบผ่านราคาเสนอเพิ่มเติม (ตามบริบท) ซึ่งตอบสนองความต้องการที่ผู้ลงโฆษณาไม่ต้องการแสดงโฆษณาต่อกลุ่มเป้าหมายบางกลุ่ม ดูรายละเอียดได้ในคำอธิบายนี้และปัญหาเกี่ยวกับ GitHub นี้ นอกจากนี้ เรายังกําลังหาวิธีรองรับการกําหนดเป้าหมายเชิงลบของ IG สําหรับราคาเสนอ PA API และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
(รายงานในไตรมาสก่อนหน้าด้วย) โฆษณาเนทีฟ	คำขอการสนับสนุนเฟรมที่มีการกำหนดขอบเขตสำหรับโฆษณาเนทีฟ	เรากำลังพิจารณาที่จะรองรับ Use Case นี้และกำลังหาวิธีแก้ปัญหาชั่วคราวและวิธีแก้ปัญหาที่เป็นไปได้ ที่นี่
WebView	เราต้องการคำชี้แจงเกี่ยวกับสถานการณ์ที่ IG เข้าร่วมที่ Chrome ไม่พร้อมใช้งานสำหรับการประมูลที่ดำเนินการบน WebView	เราต้องการรองรับกรณีการใช้งานเหล่านี้เมื่อมีโครงสร้างพื้นฐานด้านความเป็นส่วนตัวที่เพียงพอ เราไม่มีประกาศเพิ่มเติมในขณะนี้ แต่ยินดีรับฟังความคิดเห็นเพิ่มเติม ที่นี่
IG เชิงลบ	คำขออัปเดตการประมวลผล URL เพื่อรองรับ IG เชิงลบผ่านฟีเจอร์ส่วนหัวที่เพิ่งเปิดตัว	เรากำลังประเมินคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การกรองเพื่อความหลากหลาย	ขอคำแนะนำเกี่ยวกับวิธีใช้การกรองความหลากหลายเมื่อใช้งานโฆษณาเนทีฟใน PA API กับผู้ขายหลายรายและการประมูลหลายรายการ	เรากำลังพูดคุยเกี่ยวกับคำขอนี้ ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
(รายงานในไตรมาสก่อนหน้าด้วย) ตัวกรองการบล็อก	ขอคําแนะนําเกี่ยวกับวิธีบังคับใช้กฎ "การบล็อกผู้เผยแพร่โฆษณา" (ตัวกรอง) เมื่อแสดงโฆษณาเนทีฟใน PA API กับผู้ขายหลายราย	เราได้แชร์คําแนะนํา ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
ข้อจำกัด	คำขออนุญาตการจํากัดที่ระดับโดเมนแทนที่จะเป็นระดับโดเมนย่อย	ข้อจำกัดในระดับโดเมนย่อยหรือต้นทางเป็นไปตามโมเดลการรักษาความปลอดภัยพื้นฐานของเว็บนั่นจึงเป็นการออกแบบเริ่มต้นของเรา เราได้อธิบายเรื่องนี้อย่างละเอียดแล้วที่นี่และที่นี่
การเสนอราคาที่เชื่อถือได้	คำขอ User Agent และคำแนะนำสำหรับไคลเอ็นต์ที่เกี่ยวข้องในคำขอสัญญาณการเสนอราคาที่เชื่อถือได้	เรากําลังติดตามคําขอฟีเจอร์นี้ และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
(รายงานในไตรมาสก่อนหน้าด้วย) IG หลายรายการ	ใช้ IG หลายรายการในการเสนอราคาเดียวกัน	ปัจจุบัน PA API ไม่รองรับการดำเนินการนี้ เนื่องจากจะส่งผลให้รูปแบบความเป็นส่วนตัวพื้นฐานมีการเปลี่ยนแปลง เรายินดีให้พูดคุยเพิ่มเติม ที่นี่
(รายงานในไตรมาสก่อนหน้าด้วย) ประสิทธิภาพ	การย้ายตรรกะไปยังไคลเอ็นต์มากขึ้นอาจส่งผลเสียต่อประสิทธิภาพหน้าเว็บและ UX ซึ่งอาจส่งผลเสียต่อคะแนน SEO ของเว็บไซต์	เรากำลังพูดคุยเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติม ที่นี่
การเปลี่ยนแปลงที่เกิดขึ้นในระหว่างการประมูล	PA API ลดข้อมูลเกี่ยวกับการเปลี่ยนแปลงที่เกิดขึ้นในระหว่างการประมูล (เช่น ผู้ที่เข้าร่วม ผู้ที่ชนะการประมูลแต่ละคอมโพเนนต์ เป็นต้น) ซึ่งลดความสามารถในการตรวจสอบของผู้เผยแพร่โฆษณาและทำให้ยากที่จะรู้ได้ว่ายังมีดีลอยู่ไหม	เราได้เสนอวิธีแก้ปัญหาการติดตามดีลไว้ที่นี่ เราวางแผนที่จะแก้ไขช่องที่มีอยู่บางช่องและสร้างช่องใหม่ภายในออบเจ็กต์ IG เพื่อจัดเก็บ DealID และ SeatID และอนุญาตให้ช่องเหล่านี้เผยแพร่จาก generateBid ไปยัง scoreAd หรือการส่งออกผ่านการรายงานระดับเหตุการณ์ ซึ่งควรรองรับ Use Case ของดีลอย่างเพียงพอ เรายินดีรับฟังความคิดเห็นเกี่ยวกับข้อมูลเมตาอื่นๆ ที่เทคโนโลยีโฆษณาพิจารณาว่าสําคัญต่อการเปลี่ยนแปลงของการประมูลและเพื่อติดตามผลผู้เผยแพร่โฆษณาต่อไป เราแนะนําให้เทคโนโลยีโฆษณายกตัวอย่างข้อมูลเมตาที่เจาะจงซึ่งใช้อ้างอิงและจากฝ่ายที่ควรส่งไปให้
GAM	ข้อกังวลเกี่ยวกับข้อกำหนดในการใช้ GAM เป็นเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาเพื่อเข้าถึงดีมานด์ของ AdX	คําตอบจาก Google Ad Manager: GAM ไม่ได้กําหนดให้ผู้เผยแพร่โฆษณาใช้ฟังก์ชันเซิร์ฟเวอร์โฆษณาเพื่อเข้าถึงฟังก์ชันการแลกเปลี่ยน
(รายงานในไตรมาสก่อนหน้าด้วย) การประมูลคอมโพเนนต์	ผู้ชนะการประมูลคอมโพเนนต์ PA API จะปรากฏต่อ GAM ซึ่งทำให้เกิดข้อกังวลเกี่ยวกับการเข้าถึงข้อมูลอย่างไม่เท่าเทียม	คำตอบของเรายังคงเหมือนเดิมจากไตรมาสที่แล้ว คำตอบจาก Google Ad Manager มีดังนี้ "เราให้ความสำคัญอย่างยิ่งกับความเป็นธรรมในการประมูลมาหลายปี รวมถึงคำมั่นสัญญาที่จะไม่แชร์ราคาจากแหล่งที่มาของโฆษณาที่ไม่รับประกันการแสดงผลใดๆ ของผู้เผยแพร่โฆษณา ซึ่งรวมถึงราคารายการโฆษณาที่ไม่รับประกันการแสดงผล กับผู้ซื้อรายอื่นก่อนที่ผู้ซื้อเหล่านั้นจะเสนอราคาในการประมูล ซึ่งในเวลาต่อมาเราได้ยืนยันในความมุ่งมั่นของเราต่อหน่วยงานการแข่งขันของฝรั่งเศส สําหรับการประมูล PA API เราตั้งใจที่จะรักษาสัญญาและไม่แชร์ราคาเสนอของผู้เข้าร่วมการประมูลกับผู้เข้าร่วมการประมูลรายอื่นจนกว่าการประมูลจะเสร็จสมบูรณ์ในการประมูลแบบผู้ขายหลายราย เพื่อความชัดเจน เราจะไม่แชร์ราคาของการประมูลตามบริบทกับการประมูลองค์ประกอบใดๆ รวมถึงการประมูลของเราเอง ตามที่อธิบายไว้ในข้อมูลอัปเดตนี้ นอกจากนี้ เราไม่ใช้ข้อมูลเกี่ยวกับการกําหนดค่าการประมูลของคอมโพเนนต์ รวมถึงสัญญาณที่ผู้ซื้อให้ SSP เป็นส่วนหนึ่งของการประมูลของเราเอง ทั้งนี้ เรายินดีรับการเปลี่ยนแปลงใน PA API ที่อนุญาตให้ผู้ขายคอมโพเนนต์สามารถระบุการกำหนดค่าการประมูลคอมโพเนนต์ในลักษณะที่มีการสร้างความสับสนจากผู้ขายระดับสูง"
GAM	GAM จะขอส่วนแบ่งรายได้สำหรับการเรียกใช้/การรายงานการประมูลระดับบนสุดไหมหากไม่ได้มีส่วนร่วมในการสร้างการประมูลคอมโพเนนต์ IG หรือ PA API	คําตอบจาก Google Ad Manager: เมื่อผู้เผยแพร่โฆษณาเลือกใช้ GAM เป็นเซิร์ฟเวอร์โฆษณา GAM จะทำการประมูลระดับบนสุดและเรียกเก็บค่าธรรมเนียมการแสดงโฆษณาสําหรับฟังก์ชันการทํางานของเซิร์ฟเวอร์โฆษณา (ค่าธรรมเนียมการแสดงโฆษณาเดียวกันกับที่ใช้นอกการประมูล PA API) แต่หากโฆษณาที่ชนะมาจากผู้ขายคอมโพเนนต์ที่ไม่ใช่ GAM ซึ่งหมายความว่า GAM ไม่ได้เข้าร่วมการสร้างการประมูลคอมโพเนนต์ IG หรือ PA API ทาง GAM จะไม่จัดการการเรียกเก็บเงินและจะไม่เรียกเก็บค่าธรรมเนียมสื่อเป็นเปอร์เซ็นต์
ความสามารถในการดึงดูดให้คลิก	การลงทะเบียนเหตุการณ์การคลิกอยู่ภายใต้ความเป็นส่วนตัวแบบที่แตกต่างกันเดียวกันหรือไม่	ปัจจุบันเราไม่ได้วางแผนที่จะจำกัดฟีเจอร์นี้ด้วยข้อจำกัด "k-anon" เนื่องจาก "จํานวนการคลิก" จะพร้อมใช้งานเป็น browserSignal ภายในฟังก์ชัน generateBid() เท่านั้น และไม่พร้อมใช้งานเป็นแอตทริบิวต์ใหม่ในการรายงานระดับเหตุการณ์
ประสิทธิภาพ	ต้นทุนขาออกสูงเนื่องจากการตอบกลับคำขอราคาเสนอตามบริบทแบบไม่มีเงื่อนไข	เราไม่สามารถให้ข้อมูลว่า DSP ใดมี IG ได้โดยตรงเนื่องด้วยข้อกังวลเกี่ยวกับความเป็นส่วนตัว อย่างไรก็ตาม เรากำลังสำรวจโซลูชันอื่นๆ ที่สามารถให้ข้อมูลเชิงลึกในขณะที่รักษาความเป็นส่วนตัวไว้ได้
โฆษณาเนทีฟและโฆษณานอกสตรีม	ขอข้อมูลอัปเดตเกี่ยวกับมุมมองของ Chrome เกี่ยวกับโฆษณาเนทีฟและนอกสตรีม	ตำแหน่งของ Chrome จะขึ้นอยู่กับกรณีการใช้งานที่เป็นประเด็น สำหรับวิดีโอ มุมมองของ Chrome คือหน้าที่ของเราคือการส่งเสริมให้ระบบนิเวศรวมตัวกันเพื่อหาโซลูชันวิดีโอในสตรีมที่ใช้งานได้โดยใช้ API ของเรา จนถึงตอนนี้ ข้อเสนอที่เป็นรูปธรรมเพียงอย่างเดียวที่เราทราบคือข้อเสนอของ GAM สําหรับโฆษณาเนทีฟ เรากําลังรวบรวมความคิดเห็นที่นี่และวางแผนที่จะดึงดูดเทคโนโลยีโฆษณาด้วยขั้นตอน Discovery เพิ่มเติมในเร็วๆ นี้
การตรวจสอบแบบเรียลไทม์ (RTM)	การรับส่งข้อมูลที่ติดป้ายกำกับจะไม่ส่งรายงาน RTM	เราตระหนักถึงช่องโหว่นี้และกำลังดำเนินการเพื่อหาทางแก้ไข เราจะแชร์ข้อมูลอัปเดตเมื่อพร้อมให้บริการที่นี่
การสนับสนุนส่วนขยายกลุ่มเป้าหมาย	คำขอข้อมูลอัปเดตเกี่ยวกับการรองรับชิ้นงานกลุ่มเป้าหมาย/กลุ่มเป้าหมายที่ดูแลจัดการโดยผู้ขายใน PA API	เรากำลังหาทางแก้ไขสำหรับกรณีการใช้งานนี้ เรากำลังรวบรวมความคิดเห็นจากระบบนิเวศเกี่ยวกับสิ่งที่ควรสร้างและรองรับ เราจะแชร์ข้อมูลอัปเดตเมื่อพร้อมใช้งานและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การแก้ไขข้อบกพร่อง	ในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของ Chrome ไม่มีแผงสำหรับตรวจสอบประสิทธิภาพโดยละเอียดของ PA API เช่น ประสิทธิภาพโดยรวมอาจได้รับผลกระทบจากจํานวน IG หรือจํานวนผู้ซื้อ	แม้ว่าความคิดเห็นที่เฉพาะเจาะจงนี้เกี่ยวข้องกับความสามารถของ UI เครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ของ Chrome ในการช่วยตรวจสอบ แต่เมื่อวันที่ 7 ตุลาคม เราได้เปิดตัวความสามารถของผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาในการกําหนดค่าเหตุการณ์ที่กําหนดเองซึ่งสามารถใช้เป็นพื้นฐานสําหรับการตรวจสอบและการแจ้งเตือน อ่านรายละเอียดเพิ่มเติมได้ที่นี่ และเราหวังว่าการอัปเดตนี้จะแก้ไขข้อเสนอแนะส่วนใหญ่นี้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับฟีเจอร์นี้ ไม่ว่าจะเป็นเรื่องจุดข้อมูลที่รองรับหรือประสบการณ์การใช้งานของนักพัฒนาแอปในบทสนทนา GitHub ที่เกี่ยวข้องที่นี่
สัญญาณ	ข้อกังวลว่า DSP สามารถตรวจสอบว่าระบบส่ง PerBuyerSignals ไปยัง SSP โดยไม่ขึ้นกับผลการประมูลตามบริบทหรือไม่	ระบบจะถือว่าการประมูลตามบริบทมีราคาเสนอที่ชนะเพียงรายการเดียวจาก DSP รายการเดียว หรือกล่าวคือมีราคาเสนอรายการเดียวที่จะพยายามเอาชนะในการประมูล PA API ที่ตามมา สำหรับขั้นตอน PA API นั้น SSP ตัดสินใจเชิญ DSP ทั้งหมดที่ตนต้องการเพื่อดูว่ามีความต้องการส่งหรือไม่ (ในรูปแบบ IG ในอุปกรณ์) เป็นไปได้และมีความเป็นไปได้สูงมากที่ DSP ที่แพ้การประมูลตามบริบทจะได้รับ "คำเชิญอีกครั้ง" ให้เข้าร่วมการประมูล PA API ใน "คำเชิญอีกครั้ง" นี้เป็นกรณีที่ DSP หากตัดสินใจยอมรับ จะส่งต่อสัญญาณที่ผู้ตรวจสอบโฆษณาต้องการต่อไปยัง SSP เพื่อให้มั่นใจว่า DSP จะพิจารณา หากมีสำหรับแคมเปญนั้น กล่าวคือ ในการประมูล PA API จะมีวิธีให้ DSP ส่ง PerBuyerSignals ไปยัง SSP ได้เสมอ ไม่ว่าการประมูลตามบริบทจะเป็นอะไรก็ตาม
สัญญาณ	คำขอเพิ่ม prevClicks ไปยังออบเจ็กต์ browserSignals ที่ส่งไปยัง generatedBid()	คําขอนี้สามารถแก้ไขได้ด้วยข้อเสนอของเราในการสนับสนุนสัญญาณความน่าสนใจในการคลิก เราได้ประกาศฟีเจอร์นี้ในบล็อกโพสต์ล่าสุดและคําอธิบายที่สอดคล้องกัน เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับข้อเสนอนี้ที่นี่
(รายงานในไตรมาสก่อนหน้าด้วย) สัญญาณการประมาณ	ส่งคำขอเพิ่มจำนวนบิตของสัญญาณการประมาณจาก 12 บิตเป็น 30 บิต	เราได้ตอบกลับความคิดเห็นนี้ด้วยข้อเสนอโต้แย้งที่นี่ เรามีส่วนร่วมกับอุตสาหกรรมอย่างสม่ำเสมอเพื่อทําความเข้าใจมุมมองของอุตสาหกรรมต่อข้อเสนอของเรา และกำลังชั่งน้ำหนักประโยชน์ต่ออุตสาหกรรมเทียบกับผลกระทบต่อผู้ใช้ Chrome และผู้มีส่วนเกี่ยวข้องอื่นๆ
เอกสารประกอบ	ขอคำแนะนำเกี่ยวกับวิธีใช้เซิร์ฟเวอร์คีย์/ค่า (K/V) และ TEE	คำแนะนำสำหรับการใช้ TEE ในบริบทของ K/V มีอยู่ในรายละเอียดการออกแบบโมเดลความน่าเชื่อถือของบริการ K/V ที่นี่
อายุการใช้งานของ IG เชิงลบ	ขอขยายอายุการใช้งานของ IG เชิงลบเป็น 365 วัน	ระบบจะใช้ IG เชิงลบเพื่อป้องกันการแสดงโฆษณา แต่ผู้ไม่ประสงค์ดียังสามารถใช้เพื่อเปิดเผยข้อมูลเกี่ยวกับผู้ใช้ ซึ่งทำให้เกิดความเสี่ยงในการระบุตัวตนซ้ำ (เช่น วิธีหนึ่งที่ผู้ไม่ประสงค์ดีจะโจมตีคือ เพียงแค่ใส่ราคาเสนอสูงที่มี IG เชิงลบซ้ำๆ เพื่อดูว่าผู้ใช้เคยหรือไม่ได้เข้าชมเว็บไซต์บางแห่งหรือไม่) หากใช้ TTL 365 วัน ผู้ไม่ประสงค์ดีจะมีข้อมูลเกี่ยวกับ IG เชิงลบมากขึ้น ซึ่งจะทำให้เกิดความเสี่ยงด้านความเป็นส่วนตัวมากขึ้นอย่างมาก ด้วยเหตุนี้ เราจึงไม่สามารถรองรับคําขอนี้เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้
ข้อกำหนดของ API	อะไรบ้างที่แทรกเป็นค่าที่จะส่งเป็นส่วนหนึ่งของ perBuyerSignals ได้ ผู้ขายกำหนดค่านี้โดยพลการได้ไหม	perBuyerSignals คือที่ที่ผู้ขายจะให้ข้อมูลแก่ผู้ซื้อตามที่ผู้ขายต้องการแสดงในการประมูล ระบบนิเวศจะเป็นผู้ตัดสินใจว่าต้องการแทรกข้อมูลใดลงไป แต่เรายินดีให้พูดคุยเพิ่มเติมที่นี่
การแทนที่มาโครขนาดโฆษณา	ขอคําแนะนําเกี่ยวกับมาโครขนาดโฆษณาที่ใช้งานไม่ได้	เราจะแชร์รายละเอียดเพิ่มเติมต่อสาธารณะในเร็วๆ นี้
การแทนที่มาโคร SSP หลังการเสนอราคา: URL ระดับบนสุดที่มีการปลอมแปลง	Chrome สามารถใช้กลไกใดเพื่อให้ผู้ให้บริการการยืนยันยืนยัน URL ระดับบนสุดภายในเฟรมเวิร์ก Privacy Sandbox ได้ มีจุดข้อมูลหรือสัญญาณอื่นที่สามารถใช้ภายในเฟรมที่มีการกำหนดเขตเพื่อตรวจสอบความถูกต้องของ URL ระดับบนสุดที่ SSP ระบุหรือไม่	ขณะนี้เรากำลังพูดคุยเรื่องความคิดเห็นเพิ่มเติมเพื่อต้อนรับที่นี่
คำขอฟีเจอร์	คำขอระบุ UACH ที่มีความผันผวนต่ำในการดึงข้อมูล updateURL และในการรายงานผลแบบเรียลไทม์	คำขอเหล่านี้อยู่ระหว่างการสนทนาที่นี่ และเรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่และที่นี่
คำขอฟีเจอร์	ส่งคําขอเปิดใช้งานการออกแบบการแก้ไขข้อบกพร่องที่ได้รับความยินยอมจากเซิร์ฟเวอร์ที่เชื่อถือได้เมื่อมีการทริกเกอร์ไคลเอ็นต์หนึ่งๆ ให้ส่งรายงานระดับเหตุการณ์ที่ลดขนาดแล้วสำหรับ "การแก้ไขข้อบกพร่องเท่านั้น" ผ่าน forDebuggingOnly.reportAdAuctionWin() และ forDebuggingOnly.reportAdAuctionLoss()	นี่เป็นคำขอที่รอดำเนินการซึ่งเรากำลังติดตามอยู่ และจะแจ้งข้อมูลอัปเดตเกี่ยวกับระบบนิเวศให้ทราบเมื่อพร้อมใช้งาน เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การใช้ API	ขอคําแนะนําเกี่ยวกับวิธีนับการเข้าถึงผู้ใช้ที่ไม่ซ้ำและการเข้าถึงการแสดงผล	เรากำลังหารือถึงข้อเสนอเกี่ยวกับวิธีอ่าน IG จากภายในเวิร์กเล็ตพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน ซึ่งคุณจะส่งรายงานสรุปรวมแบบส่วนตัวได้ ดูรายละเอียดเพิ่มเติมได้ที่นี่ และเรายินดีรับฟังความคิดเห็นเกี่ยวกับข้อเสนอและประโยชน์ต่อระบบนิเวศ
การใช้ API	ความไม่ชัดเจนว่าผู้เผยแพร่โฆษณาควรทดสอบอะไร API ใดสำคัญ ควรเปิดใช้ API ใด และมีอะไรบ้างที่จะเกิดขึ้น	เรากำลังดำเนินการเพื่อสนับสนุนผู้เผยแพร่โฆษณา รวมถึงบทบาทของตนในระบบนิเวศให้ดีขึ้น
การใช้ API	เป็นไปได้ไหมที่จะเพิ่ม Listener เหตุการณ์ลงในเหตุการณ์ Worklet การประมูลเพื่อแสดงโฆษณา	ซึ่งทำผ่านเหตุการณ์ปกติไม่ได้ แต่เหตุการณ์โปรโตคอลของ Chrome Devtools Protocol จะจัดการ Use Case นี้เพียงบางส่วน โปรดทราบว่าเหตุการณ์ปกติมีแนวโน้มที่จะส่งผลต่อพร็อพเพอร์ตี้การแยก/ความเป็นส่วนตัว แต่ดูรายละเอียดได้ที่นี่
K-Anonymity	ขอคำชี้แจงเกี่ยวกับข้อกำหนดการแสดงผลโฆษณา (เช่น ผู้ใช้อย่างน้อย 50 คนจะเห็นโฆษณาหากได้รับอนุญาตให้แสดง)	เอกสารประกอบสําหรับนักพัฒนาซอฟต์แวร์จะแสดงภาพรวมความคาดหวังของเราสําหรับการพัฒนาในอนาคต โดยเฉพาะอย่างยิ่ง อธิบายว่าเกณฑ์ k-anonymity เริ่มต้นคือ k=10 คน รายชื่ออีเมล blink-dev จะให้ข้อมูลอัปเดตเกี่ยวกับสิ่งที่เกิดขึ้นใน Chrome ตามที่ได้ระบุไว้ในชุดข้อความของรายชื่ออีเมล k-anonymity ตอนนี้เรากำลังทดลองบังคับใช้ข้อกำหนด k-anonymity กับการเข้าชมแบบเสถียรของ Chrome ประมาณ 1% และจะไม่บังคับใช้กับส่วน "โหมด A" และ "โหมด B") ที่ติดป้ายกำกับไว้อย่างชัดเจน
การสึกกร่อน	สามารถนำการสร้างความสับสนของ TEE K/V ออกชั่วคราวหรือลดจำนวนการเรียกข้อมูล N ชาร์ดทั้งหมดให้เหลือจำนวนที่สมดุลระหว่างการคุ้มครองความเป็นส่วนตัวกับประโยชน์ (เช่น ประสิทธิภาพ/ต้นทุนของ K/V)	คำขอประเภทเหล่านี้จะจัดการสำหรับอินสแตนซ์ที่ไม่ใช่เวอร์ชันที่ใช้งานจริงเท่านั้นซึ่งสามารถควบคุมการขัดสีได้ สำหรับอินสแตนซ์เวอร์ชันที่ใช้งานจริง คุณยังคงต้องใส่การป้องกัน เราจะประเมินสถานการณ์ได้เมื่อได้รับความคิดเห็นจากการใช้งานที่ไม่ใช่เวอร์ชันที่ใช้งานจริง
การสึกกร่อน	คำขอเพิ่ม Flag เพื่อปิดใช้ chaffing จากไบนารี K/V ที่เป็นการแก้ไขข้อบกพร่อง/ไม่ใช่ prod	ธงนี้มาพร้อมกับรุ่น 1.0.0
ข้อบกพร่องของ API	API หยุดทํางานหลังจากอัปเกรดเป็น Chrome 126 แม้ว่าจะเปิดใช้ API ในการตั้งค่าแล้วก็ตาม	เราพบว่าปัญหานี้เกี่ยวข้องกับ Flag "enable-fenced-frames" ของ Chrome ซึ่งผู้ใช้เปิดใช้เพื่อวัตถุประสงค์ในการพัฒนา การรีเซ็ตการแจ้งว่าไม่เหมาะสมนี้เป็นค่าเริ่มต้นจะช่วยแก้ปัญหาได้
การรายงาน	คำขอเพื่อให้ผู้ซื้อเลือกใช้ Real-time Reporting API ได้โดยไม่ต้องอาศัยผู้ขาย	คำขอนี้อยู่ระหว่างการพิจารณาที่นี่ เราเพิ่งเปิดตัวโซลูชัน RTM และยินดีรับฟังความคิดเห็นจากนักพัฒนาเทคโนโลยีโฆษณาที่เริ่มใช้งานฟีเจอร์นี้
การรายงาน	คำขอสำหรับการรายงาน 3P ในขณะที่ DSP และ SSP ได้รับการแจ้งเตือนการแสดงผลจาก Chrome โดยค่าเริ่มต้นผู้ให้บริการทางเทคนิคชั้นกลางจะไม่ได้รับการแจ้งเตือน	เรากำลังพูดคุยเกี่ยวกับคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
TEEs	ข้อกําหนดของ Google ในการเริ่มต้นใช้งานด้วยตนเองภายใต้มาตรฐานทางเทคนิคเป็นข้อจํากัดที่เข้มงวดเกี่ยวกับตัวเลือกผู้ให้บริการระบบคลาวด์ คุณปฏิบัติตามมาตรฐานทางเทคนิคที่ใช้ได้โดยไม่ต้องไปที่สำนักงานผู้ให้บริการระบบคลาวด์ตามที่ Google ดูเหมือนจะคิดไว้ การเลื่อนกำหนดเวลาของผู้ให้บริการรายอื่นในปี 2025 (เร็วที่สุด) เป็นสิ่งที่ยอมรับไม่ได้ เนื่องจากจะทำให้เกิดผลเครือข่ายที่กระตุ้นให้ผู้ใช้หันมาใช้โซลูชันของ Google	บริการรวบรวมข้อมูลเป็นบริการเดียวที่ต้องทำงานในบริการ TEE เพื่อจัดการกับกรณีการใช้งานด้านเทคโนโลยีโฆษณาบางกรณี บริการรวบรวมข้อมูลรองรับทั้ง Amazon Web Services (AWS) และ Google Cloud Platform (GCP) จากความคิดเห็นที่ได้รับจากเทคโนโลยีโฆษณา เราเชื่อว่าการสนับสนุนดังกล่าวเพียงพอแล้วในตอนนี้ สำหรับผู้ให้บริการระบบคลาวด์รายอื่นๆ - Google ได้เผยแพร่เกณฑ์โดยละเอียดสำหรับ TEE ในผู้ให้บริการระบบคลาวด์สาธารณะ วัตถุประสงค์ของข้อกำหนดเหล่านี้คือเพื่อให้มั่นใจว่าโซลูชัน TEE เป็นไปตาม เป้าหมายด้านความเป็นส่วนตัวและความปลอดภัยของ Privacy Sandbox กล่าวโดยละเอียดคือ เซิร์ฟเวอร์ TEE ของ Privacy Sandbox จะประมวลผลข้อมูลผู้ใช้แบบข้ามเว็บไซต์ที่ไม่ได้เข้ารหัส (เช่น ข้อมูลจากเว็บไซต์ของผู้เผยแพร่โฆษณาและผู้ลงโฆษณาสําหรับบริการรวบรวมข้อมูล) ข้อมูลเหล่านี้ต้องปลอดภัยเพื่อบรรลุเป้าหมายด้านความเป็นส่วนตัวของผู้ใช้สำหรับ API สภาพแวดล้อมที่ปลอดภัยก็จำเป็นเช่นกันเพื่อให้มั่นใจว่า API จะปกป้องข้อมูลทางธุรกิจที่เป็นความลับของบริษัทต่อไป (เช่น ป้องกันไม่ให้ผู้เข้าร่วมการประมูล PA API รายอื่นๆ เข้าถึงข้อมูลทางธุรกิจที่เป็นกรรมสิทธิ์ของผู้ซื้อ) เท่าที่ทราบในปัจจุบันยังไม่มีเทคโนโลยี TEE ที่ปกป้องข้อมูลผู้ใช้จากผู้ให้บริการที่อาจเป็นศัตรูได้อย่างสมบูรณ์ เราจึงกำหนดข้อกำหนดหลายประการเพื่อตรวจสอบความน่าเชื่อถือของผู้ให้บริการระบบคลาวด์ เราไม่แน่ใจว่า "Bureau of Cloud Providers" หมายถึงอะไร และข้อกำหนดนี้ไม่ได้เป็นส่วนหนึ่งของข้อกำหนด เรายินดีรับฟังความคิดเห็นเกี่ยวกับข้อกำหนด นอกจากนี้ เรายังประเมินการสนับสนุนผู้ให้บริการรายใหม่ๆ อย่างต่อเนื่อง โดยพิจารณาจากคำขอที่ส่งเข้ามาโดยใช้กระบวนการที่ระบุไว้ในคำอธิบาย จนถึงตอนนี้ เราได้รับคำขอให้รองรับ Azure เท่านั้น ซึ่งเรากำลังประเมินอยู่
B&A	การประเมินความซับซ้อนทางเทคนิคและความเป็นไปได้ของบริการ B&A นั้นเป็นเรื่องยาก เนื่องจากการออกแบบยังคงพัฒนาอย่างต่อเนื่อง	เพื่อแก้ไขข้อกังวลเหล่านี้ เราได้จัดเตรียมคำอธิบายอย่างละเอียดไว้ใน GitHub ซึ่งอธิบายการออกแบบ B&A, ลำดับเวลาที่พร้อมให้บริการ และแผนกลยุทธ์ของฟีเจอร์ที่รองรับ PA API เราให้การสนับสนุนเทคโนโลยีโฆษณาที่ต้องการติดตั้งใช้งาน B&A และรวบรวมความคิดเห็นจากระบบนิเวศใน GitHub
ที่พัก	กำลังมองหาคำแนะนำและวิธีที่ดีกว่าในการคำนวณค่าใช้จ่ายในการใช้ TEE สำหรับ B&A เพื่อเริ่มใช้หรือย้ายข้อมูลไปใช้จากอุปกรณ์	เมื่อเร็วๆ นี้เราได้เผยแพร่คำแนะนำการปรับขนาดอินสแตนซ์เซิร์ฟเวอร์ K/V ซึ่งมีเครื่องมือในการวัดต้นทุนที่แม่นยำยิ่งขึ้น
เซิร์ฟเวอร์ K/V	ผู้ตรวจสอบโฆษณาจะขอให้สามารถใช้ URL แบบเต็มของหน้าเว็บไปยังเซิร์ฟเวอร์ K/V เพื่อทำการยืนยันโฆษณา	ขณะนี้เรากำลังประเมินความเป็นไปได้ในการระบุ URL หน้าเว็บแบบเต็มไปยังเซิร์ฟเวอร์ K/V ที่ทำงานใน TEE เพื่อวัตถุประสงค์ในการยืนยันโฆษณา URL แบบเต็มจะใช้ใน K/V BYOS ไม่ได้
การรักษาความปลอดภัยในการประมูล	การมองหาฟีเจอร์ความปลอดภัยของการประมูลเพื่อให้มั่นใจว่าผู้ไม่ประสงค์ดีจะไม่เข้าถึงข้อมูลที่ละเอียดอ่อนหรือทำหน้าที่เป็นผู้ที่แอบอ้างเป็นบุคคลอื่น ฟีเจอร์ใดที่ปกป้องการประมูลจากการโจมตีซ้ำและจะนำมาตรการป้องกันด้านความปลอดภัยไปใช้ได้อย่างไร	รูปแบบการรักษาความปลอดภัยปัจจุบันของ B&A จะช่วยปกป้องความสมบูรณ์ในการประมูลได้ B&A ทํางานใน TEE ที่ปกป้องความลับของสัญญาณและโค้ดของเทคโนโลยีโฆษณาจากผู้ไม่ประสงค์ดี ในสถาปัตยกรรมของ B&A น้ำหนักบรรทุกคำขอ B&A ที่เข้ารหัส (ข้อความที่เข้ารหัสของคำขอ) จะส่งผ่านจากไคลเอ็นต์ผ่านเซิร์ฟเวอร์โฆษณาที่ไม่น่าเชื่อถือไปยังบริการ SellerFrontEnd (SFE ซึ่ง SSP ดำเนินการใน TEE) ข้อความที่เข้ารหัสของคำขอมีรหัสการสร้างตามการประทับเวลา SFE จะตรวจสอบการประทับเวลาของคำขอและปฏิเสธคำขอที่เล่นซ้ำซึ่งไม่ได้อยู่ภายใน +/- n วินาทีของเวลาของเซิร์ฟเวอร์ นอกจากนี้ B&A ยังแสดงผลเพย์โหลดการตอบกลับที่มีขนาดคงที่และมีการถอดรหัสสำหรับการสื่อสารระหว่างเซิร์ฟเวอร์ได้ โซลูชันเหล่านี้จะช่วยบรรเทาการโจมตีแบบเล่นซ้ำผ่านระบบได้ เมื่อผู้ไม่ประสงค์ดีพยายามเล่นซ้ำเพย์โหลดคำขอเดิมเพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับเนื้อหา B&A อยู่ระหว่างการบันทึกและอัปเดตโมเดลการรักษาความปลอดภัยในคำอธิบาย
สัญญาณผ่าน เซิร์ฟเวอร์ K/V	คำขอรวม perBuyerSignals ที่ส่งผ่านบริการ K/V เป็นส่วนหนึ่งของคำขอสัญญาณการเสนอราคาที่เชื่อถือได้จาก Chrome	เรากําลังประเมินความเป็นไปได้ในการรวมข้อมูลจาก perBuyerSignals ที่โอนไปยังเซิร์ฟเวอร์ K/V ที่ทํางานใน TEE รวมถึง URL แบบเต็ม
เซิร์ฟเวอร์ K/V	ขอแจ้งไทม์ไลน์การปรับใช้มากขึ้นสำหรับข้อจำกัดด้านความเป็นส่วนตัวใน K/V และ B&A	เราเข้าใจความต้องการในการใช้แนวทางแบบเป็นขั้นๆ มากขึ้นในการนำ TKV มาใช้ และขอขอบคุณสำหรับคำขอที่เฉพาะเจาะจงเกี่ยวกับ K/V และ B&A อย่างไรก็ตาม หลังจากประเมินอย่างรอบคอบแล้ว เราได้ตัดสินใจที่จะไม่ผ่อนปรนการคุ้มครองความเป็นส่วนตัวใน API เหล่านี้ในขณะนี้ เราเชื่อว่ามาตรการเหล่านี้ เช่น การนำระบบออกใหม่ (Chaffing) เป็นสิ่งสำคัญต่อการปกป้องความเป็นส่วนตัวของผู้ใช้และรักษาความเชื่อมั่นใน Privacy Sandbox
เซิร์ฟเวอร์ K/V	รับคำแนะนำเกี่ยวกับวิธีปรับขนาดที่เก็บ K/V ผ่านการกำหนดค่าที่เข้ากันได้	คู่มือการกำหนดขนาดอินสแตนซ์ของเซิร์ฟเวอร์ K/V ที่เผยแพร่ล่าสุดช่วยคุณได้ที่นี่ เครื่องมือจะระบุ QPS (ที่ระบุเป็น "RPS" ในคำอธิบาย) ในแต่ละชุดค่าผสมของพารามิเตอร์
เซิร์ฟเวอร์ K/V	เพิ่มข้อมูลผู้ขายในคำขอเซิร์ฟเวอร์ K/V	เรากำลังสนทนาเกี่ยวกับเรื่องนี้ และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
บริการ K/V + B&A	ขอชี้แจงเกี่ยวกับไทม์ไลน์หรือแผนการเปิดตัวสำหรับเพลง K/V และ B&A	ทั้ง K/V และ B&A ต่างก็มีระยะและไทม์ไลน์ดังนี้ สำหรับเซิร์ฟเวอร์ K/V ที่ใช้ร่วมกับการประมูล PA API ในอุปกรณ์ (เทียบกับ B&A) ไทม์ไลน์สาธารณะมีที่นี่ ในแง่ของการกําหนด "ความพร้อมให้บริการทั่วไป" สําหรับ K/V โปรดดูส่วนแผนกลยุทธ์ ซึ่งจะกําหนดชุดฟีเจอร์สําหรับเวอร์ชันเบต้าและ GA สําหรับ B&A โปรดดูลำดับเวลาสาธารณะที่นี่และแผนกลยุทธ์ที่นี่ เรากำหนดการทดสอบการปรับขนาดเป็น "การทดสอบเวอร์ชันที่ใช้งานจริงที่สมบูรณ์และเสถียร" ดูชุดฟีเจอร์ที่เฉพาะเจาะจงในระยะนี้ได้ที่นี่ B&A ยังมีระยะอัลฟ่าและเบต้าด้วย ดังนั้นการทดสอบแบบปรับขนาดจึงจะมีชุดฟีเจอร์ที่รวมของระยะก่อนหน้า สําหรับทั้ง K/V และ B&A โปรดแจ้งให้เราทราบว่าคําจํากัดความของระยะเหล่านี้ช่วยระบุอย่างชัดเจนว่าจะให้บริการเมื่อใด หากยังพบช่องว่างอยู่ โปรดแจ้งให้เราทราบ เรายินดีที่จะระบุข้อมูลเหล่านี้ให้เฉพาะเจาะจงมากขึ้นเพื่อช่วยในการวางแผน

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

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
การตอบสนองของตลาด	ข้อกําหนดให้ระบบการระบุแหล่งที่มาที่แข่งขันกันใช้เฉพาะการรายงานระดับเหตุการณ์และการรายงานสรุป/การรายงานแบบรวมภายในขอบเขตที่จำกัดเป็นข้อจํากัดการแข่งขันที่กําหนดขึ้นโดยพลการ โดยจะป้องกันการกําหนดเป้าหมายใหม่และการระบุแหล่งที่มาเฉพาะอุปกรณ์แบบเรียลไทม์ที่ระดับเหตุการณ์ แม้ว่าจะมีการป้องกันเพื่อปฏิบัติตามข้อกําหนดการคุ้มครองข้อมูล (เช่น การลบการระบุตัวตน) ก็ตาม	การออกแบบที่กล่าวถึงนี้อิงตามเป้าหมายด้านความเป็นส่วนตัวของ API เช่น การปกป้องข้อมูลที่ข้ามเว็บไซต์ซึ่งส่งจากเว็บไซต์หนึ่งไปยังอีกเว็บไซต์หนึ่ง เช่น ARA รองรับการระบุแหล่งที่มาระดับเหตุการณ์ผ่านรายงานเหตุการณ์ รายงานเหตุการณ์จะล่าช้าอย่างน้อย 1 ชั่วโมง ซึ่งจำเป็นในการทำให้การเชื่อมโยงรายงานระดับเหตุการณ์กับข้อมูลประจำตัวของผู้ใช้บนเว็บไซต์ของผู้ลงโฆษณาทำได้ยาก เนื่องจากการโจมตีแบบช่องทางด้านข้างตามที่ระบุไว้ที่นี่ นอกจากนี้ ยังมีวิธีอื่นๆ ในการระบุแหล่งที่มานอกเหนือจาก ARA เช่น การเก็บรวบรวมข้อมูลจากผู้ใช้ที่รู้ตัวว่าให้ข้อมูลระบุตัวตนโดยตรง เรายินดีรับฟังความคิดเห็นเกี่ยวกับกรณีการใช้งานที่ไม่สามารถดำเนินการได้ภายใต้ขอบเขตความเป็นส่วนตัวปัจจุบันของ Privacy Sandbox API
หลายพื้นผิว	ขอการยืนยันว่า ARA และ Shared Storage API รองรับ Use Case หลายแพลตฟอร์มหรือไม่ และขอหลักฐานที่แสดงถึงกรณีนี้	ขณะนี้ ARA และพื้นที่เก็บข้อมูลที่ใช้ร่วมกันไม่รองรับการระบุแหล่งที่มาแบบหลายพื้นผิว (ข้ามอุปกรณ์) ระบบรองรับการระบุแหล่งที่มาแบบข้ามแอปและเว็บในอุปกรณ์เครื่องเดียวกัน (ผ่าน ARA)
(รายงานในไตรมาสก่อนหน้าด้วย) จากหลายอุปกรณ์	ARA รองรับ Conversion จากหลายอุปกรณ์ไหม	คําตอบของเราคล้ายกับในไตรมาสก่อน การทํางานข้ามอุปกรณ์ก่อให้เกิดปัญหาด้านความเป็นส่วนตัวใหม่ๆ นอกเหนือจาก 3PC และยังเพิ่มปัญหาการเผยแพร่เทคโนโลยีด้วยเนื่องจากอุปกรณ์และแพลตฟอร์มที่หลากหลายที่ผู้ใช้อาจใช้ เรากำลังสำรวจโซลูชันที่เป็นไปได้ แต่เรามุ่งเน้นที่กรณีการใช้งานที่สำคัญซึ่ง ARA รองรับในปัจจุบัน และยังไม่มีลำดับเวลาสำหรับการรองรับข้ามอุปกรณ์
การปรับสเกล	ข้อกังวลว่าปัจจุบัน Attribution Report API (ARA) ได้รับการกำหนดค่าหรือไม่ รวมถึงสามารถทยอยนำไปใช้และปรับขนาดเพื่อให้บริการผู้ใช้ Chrome ทุกคนได้อย่างน่าเชื่อถือ	ปัจจุบัน ARA พร้อมให้บริการแก่ผู้ใช้ Chrome ทุกคนและทำงานได้ตามที่คาดไว้ นอกจากนี้ เรายังทดสอบและตรวจสอบความน่าเชื่อถือและความสามารถในการปรับขนาดของ ARA อย่างต่อเนื่อง เนื่องจากจํานวนบริษัทเทคโนโลยีโฆษณาที่ทดสอบ ARA เพิ่มขึ้นอย่างต่อเนื่อง เรายินดีรับฟังความคิดเห็นเพิ่มเติมสำหรับระบบนิเวศเกี่ยวกับเรื่องนี้ที่นี่
(รายงานในไตรมาสที่แล้วด้วย) การกรองข้อมูลที่ซ้ำกันออก	ข้อกังวลเกี่ยวกับวิธีที่ ARA เสนอให้จํากัดกลไกการระบุแหล่งที่มาในอุปกรณ์ เช่น ผู้เผยแพร่โฆษณาไม่สามารถใช้ตรรกะหลังการระบุแหล่งที่มาได้อย่างมีประสิทธิภาพสําหรับรายงานสรุป รวมถึงการกรองข้อมูล Conversion ประเภทเดียวกันหลายรายการสําหรับการคลิกโฆษณาเดียวกันออก	คําตอบของเรายังคงเหมือนเดิมจากไตรมาสก่อน การกรองข้อมูลที่ซ้ำกันออกในอุปกรณ์และไปป์ไลน์การวัดผลเป็นปัญหาที่ทราบและเกิดขึ้นในปัจจุบัน ซึ่งเทคโนโลยีโฆษณาก็พบปัญหานี้เช่นกันใน 3PC ARA จะช่วยให้เทคโนโลยีโฆษณาตัดสินใจได้ว่าเมื่อใดที่จะลงทะเบียน Conversion ที่ต้องการ และเพิ่มข้อมูลเมตาที่เจาะจงเพื่อระบุไปป์ไลน์การวัดผลที่ใช้ติดตาม Conversion (เช่น ส่วนหนึ่งของคีย์การรวม) ซึ่งนำไปเปรียบเทียบกับไปป์ไลน์การวัดผลอื่นๆ ได้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศนี้ที่นี่
เครื่องมือวัด Conversion	คำขอความสามารถในการทํางานกับ Conversion จากหลายโดเมน	เรากำลังพูดคุยเกี่ยวกับคำขอนี้ ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศ
การรายงาน	เบราว์เซอร์จะรออย่างน้อย 2 วัน แต่ไม่เกิน 30 วันเพื่อส่ง Conversion ซึ่งอาจทำให้เกิดข้อกังวลเนื่องจากผู้ลงโฆษณาที่เป็นกลุ่มผู้มีส่วนเกี่ยวข้องส่วนใหญ่เป็นผู้ลงโฆษณาที่เน้นประสิทธิภาพ ซึ่งทํางานแบบเกือบเรียลไทม์	การตั้งค่าเริ่มต้นสําหรับรายงานระดับเหตุการณ์จะมีกรอบเวลาการรายงานเริ่มต้น 2 วัน 7 วัน และ 30 วัน เทคโนโลยีโฆษณาสำหรับการรายงานระดับเหตุการณ์ที่ยืดหยุ่นจะเปลี่ยนแปลงจำนวนและระยะเวลาของกรอบเวลาการรายงานจากค่าเริ่มต้นได้ คุณเปลี่ยนกรอบเวลาการรายงานเป็นอย่างน้อย 1 ชั่วโมงได้ ซึ่งอาจช่วยใน Use Case ของผู้ลงโฆษณาที่เน้นประสิทธิภาพ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศนี้ที่นี่
การระบุแหล่งที่มาออนไลน์สู่ออฟไลน์	จะมีตัวเลือกการติดตั้งใช้งานสําหรับการโฆษณาออนไลน์สู่ออฟไลน์ใน ARA ไหม หรือมีคําแนะนําอื่นๆ สําหรับการวัดการระบุแหล่งที่มาแบบออฟไลน์สู่ออนไลน์ไหม	ขณะนี้ยังไม่มีแผนที่จะรองรับกรณีการใช้งานการวัดผลแบบออนไลน์สู่ออฟไลน์ใน ARA การสนับสนุนประเภทนี้มีความท้าทายด้านความเป็นส่วนตัวและความปลอดภัยที่สำคัญที่ต้องพิจารณา เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศสำหรับกรณีการใช้งานของการสนับสนุนนี้ที่นี่
การรายงานการแก้ไขข้อบกพร่อง	วิธีจัดเก็บและ/หรือเรียกข้อมูล AdID ในลักษณะที่เข้าถึงได้สําหรับการลงทะเบียน Chrome (แหล่งที่มา/ทริกเกอร์) เพื่อการระบุแหล่งที่มาจากแอปไปยังเว็บ	หากต้องการเปิดใช้รายงานการแก้ไขข้อบกพร่อง เทคโนโลยีโฆษณาต้องพิสูจน์กับเราว่าสามารถรวมผู้ใช้ในแอปและเว็บได้แล้ว การดำเนินการนี้ช่วยให้มั่นใจว่ารายงานการแก้ไขข้อบกพร่องจะไม่เปิดเผยข้อมูลใหม่ เทคโนโลยีโฆษณาสามารถพิสูจน์การเข้าร่วมได้โดยระบุคีย์การเข้าร่วมที่ไม่ซ้ำกันต่อผู้ใช้แต่ละราย คีย์การเข้าร่วมนี้อาจเป็น AdID หรือคีย์การเข้าร่วมของบุคคลที่หนึ่งก็ได้ หากเทคโนโลยีโฆษณาใช้ AdID นั้น Chrome จะไม่รองรับการเข้าถึง AdID จากเบราว์เซอร์โดยค่าเริ่มต้น และ API คาดว่าเทคโนโลยีโฆษณาแต่ละรายการจะมีวิธีส่ง AdID เป็นของตนเองในระหว่างการลงทะเบียนเว็บ
รายละเอียดของที่เก็บข้อมูล	เป็นไปได้ไหมที่จะใช้กลยุทธ์กลุ่มเป้าหมายที่แตกต่างกันต่อผู้ลงโฆษณาแต่ละราย	เราขอแนะนําให้ทดสอบแนวทางการปรับขนาดงบประมาณการมีส่วนร่วมแบบต่างๆ เพื่อหาแนวทางที่เหมาะกับกรณีการใช้งานของคุณมากที่สุด ARA สร้างขึ้นโดยมีจุดประสงค์ให้มีความยืดหยุ่นและปรับแต่งได้เพื่อตอบสนองกรณีการใช้งานเทคโนโลยีโฆษณาที่หลากหลาย เราจึงขอแนะนําให้ลองใช้กลยุทธ์การแบ่งกลุ่มที่แตกต่างกันตามผู้ลงโฆษณาหรือตามประเภทธุรกิจ การใช้กลยุทธ์การแบ่งกลุ่มที่ต่างกันจะมีประโยชน์เมื่อผู้ลงโฆษณามีค่าการวัดผลที่ต้องการติดตามและปริมาณของค่าการวัดผลที่แตกต่างกัน
เอกสารประกอบ	ขอเอกสารเพิ่มเติมสำหรับการใช้แอป<>เว็บสำหรับ ARA	เราได้เผยแพร่เอกสารประกอบเกี่ยวกับแอป<>เว็บสำหรับ ARA แล้วที่นี่
ประสิทธิภาพ	จํานวนคําขอที่เกี่ยวข้องกับ ARA อาจทําให้เซิร์ฟเวอร์ของผู้เผยแพร่โฆษณามีภาระงานมากเมื่อเทียบกับจํานวนคําขอ Keepalive ที่จําเป็นต่อการทำงานของเว็บไซต์ดังกล่าว การรวมเหตุการณ์แหล่งที่มาเป็นกลุ่มในคําขอเดียวจะช่วยลดความจําเป็นในเซิร์ฟเวอร์ แนวคิดหนึ่งที่เป็นไปได้คือการอนุญาตให้ใช้อาร์เรย์ของออบเจ็กต์ที่เข้ารหัส JSON	การสร้างเหตุการณ์ต้นทางแบบกลุ่มโดยอิงตามตรรกะที่เฉพาะเจาะจงสามารถทำได้ในระดับหนึ่งโดยใช้ตรรกะ JavaScript ร่วมกับ API เรากำลังประเมินคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศที่นี่
คำขอฟีเจอร์	คําแนะนําสําหรับข้อเสนอวิธีแก้ปัญหาเนื่องจากระบบไม่รองรับการผสานรวมแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์	ขณะนี้ เราไม่มีแผนที่จะใช้การสนับสนุนสำหรับการผสานรวมแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ใน ARA มีปัญหาด้านความเป็นส่วนตัวหลายประการที่ต้องพิจารณาเพิ่มเติมเพื่อรองรับการผสานรวมแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ เรายินดีรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับกรณีการใช้งานเพิ่มเติมสำหรับการสนับสนุนแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ที่นี่
เอกสารประกอบ	ขอคู่มือ "เริ่มต้นใช้งาน" ที่อธิบายส่วนสําคัญของ ARA/วิธีเริ่มต้นใช้งานพร้อมกรณีการใช้งานง่ายๆ 2-3 รายการ	ดูคู่มือเริ่มใช้งานฉบับย่อสำหรับ ARA ได้ที่นี่ เรากำลังปรับปรุงเอกสารประกอบนี้เพิ่มเติมในปีนี้ และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับกรณีการใช้งานหรือสถานการณ์ที่เฉพาะเจาะจงซึ่งต้องใช้เอกสารประกอบเพิ่มเติมที่นี่
การใช้ API	คำขอคําแนะนําในการปรับขนาดการมีส่วนร่วมสําหรับค่าเล็กๆ จำนวนมาก	เราขอแนะนําให้ทดสอบแนวทางการปรับขนาดงบประมาณการมีส่วนร่วมแบบต่างๆ เพื่อหาแนวทางที่เหมาะกับกรณีการใช้งานของคุณมากที่สุด สำหรับสถานการณ์ที่มีค่าเล็กๆ จำนวนมาก เราขอแนะนำให้ทดสอบค่าต่างๆ ของ epsilon เพื่อระบุจุดเปลี่ยนแปลงที่ยอมรับสัญญาณรบกวนจาก epsilon สำหรับกรณีการใช้งานของคุณได้ ดูรายละเอียดเพิ่มเติมได้ในเอกสารงานวิจัยของเราในหัวข้อการเพิ่มประสิทธิภาพรายงานสรุปใน ARA
ระดับกิจกรรมที่ยืดหยุ่น	จะมีการใช้ระดับเหตุการณ์ที่ยืดหยุ่น (ข้อกำหนดทริกเกอร์หลายรายการ) เมื่อใด	ปัจจุบันระดับเหตุการณ์แบบยืดหยุ่นรองรับการปรับแต่งการกำหนดค่าการลงทะเบียนในด้านต่อไปนี้ จำนวนรายงานที่สร้างได้ต่อแหล่งที่มา จำนวนและระยะเวลาของกรอบเวลาการรายงาน และ Cardinality ของข้อมูลทริกเกอร์ ขณะนี้เรากําลังรวบรวมความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศเพื่อปรับปรุงระดับเหตุการณ์แบบยืดหยุ่นเพิ่มเติม แต่ยังไม่มีแผนที่จะใช้งานในขณะนี้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับกรณีการใช้งานที่อาจได้รับประโยชน์จากการปรับปรุงระดับเหตุการณ์ที่ยืดหยุ่นบางส่วนที่ระบุไว้ที่นี่
การประมวลผลที่เก็บข้อมูล	ขอให้พิจารณาจำกัดการมีส่วนร่วมแบบรวมสำหรับที่เก็บข้อมูล รวมถึงความสามารถในการขยายการให้บริการในอนาคตและการรองรับการทำงานร่วมกันย้อนหลัง	เรากำลังหารือเกี่ยวกับคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
Epsilon	จะเกิดอะไรขึ้นกับช่วง epsilon เมื่อ ARA เปลี่ยนเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไป	ARA พร้อมให้บริการแก่ผู้ใช้ทั่วไปใน Chrome แล้วในไตรมาสที่ 3 ปี 2023 ในขณะนี้ยังไม่มีแผนที่จะแก้ไขกรอบเวลาค่า epsilon ข้อเสนอของเราสำหรับโครงสร้างการกำกับดูแลฉบับปรับปรุงจะให้ความมั่นใจมากขึ้นในกรณีที่มีการปรับเปลี่ยน
การรายงาน	รายงานข้อผิดพลาดของทริกเกอร์ที่ไม่รู้จักไม่มีแอตทริบิวต์แหล่งที่มาในเนื้อหาของรายงาน	ตามที่กำหนดไว้ในข้อกำหนด ไม่จำเป็นต้องมีฟิลด์อื่นๆ ในเนื้อหารายงานสำหรับ trigger-unknown-error เราตระหนักดีว่าตารางที่อธิบายช่องในเนื้อหารายงานอาจทำให้เข้าใจผิดได้ เนื่องจากช่องที่เกี่ยวข้องกับแหล่งที่มาอาจหรือไม่ปรากฏขึ้น ทั้งนี้ขึ้นอยู่กับสาเหตุของข้อผิดพลาด ตัวอย่างเช่น ข้อผิดพลาดภายในอาจเกิดขึ้นก่อนที่ตรรกะการจับคู่แหล่งที่มาจะทำงาน ซึ่งหมายความว่าจะไม่มีข้อมูลแหล่งที่มาสำหรับป้อนข้อมูลในรายงานการแก้ไขข้อบกพร่อง ตอนนี้เราได้อัปเดตเอกสารประกอบเพื่อชี้แจงเรื่องนี้แล้ว
การใช้ API	เมื่อทํางานกับเป้าหมายการวัดผล 2 รายการ ได้แก่ จํานวน และมูลค่า สิ่งบ่งชี้คือต้องแยกทั้งงบประมาณการมีส่วนร่วมและค่า epsilon ใช่ไหม	เมื่อใช้เป้าหมายการวัดผล 2 เป้าหมาย เราขอแนะนําให้แบ่งงบประมาณการมีส่วนร่วมระหว่างเป้าหมายเหล่านั้น
การรายงาน	ARA รองรับการระบุแหล่งที่มาแบบหลายทัชพอยต์หรือรายงานความช่วยเหลือ (หรือที่เรียกว่าการรายงานการมีส่วนร่วม) ไหม	ปัจจุบัน ARA ยังไม่รองรับการระบุแหล่งที่มาแบบหลายทัชพอยต์หรือรายงานความช่วยเหลือ ขณะนี้เราไม่มีแผนที่จะใช้ฟีเจอร์นี้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับกรณีการใช้งานและลำดับความสำคัญที่นี่
ข้อบกพร่องของ API	สําหรับ ARA เอกสารระบุว่ามีการใช้ XOR เพื่อรวมชิ้นส่วนคีย์การรวมแหล่งที่มาและทริกเกอร์ แต่ในทางปฏิบัติจะใช้ OR ความคลาดเคลื่อนนี้ทำให้เกิดความสับสนและข้อผิดพลาดที่อาจเกิดขึ้นในการใช้งาน	เราได้อัปเดตเอกสารประกอบเพื่อระบุว่านี่เป็นข้อผิดพลาด

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
งานการรวบรวม	คำขออนุญาตใช้คำนำหน้าหลายรายการในงานการรวม	เรากำลังตรวจสอบความคิดเห็นนี้และได้โพสต์ข้อเสนอไว้ที่นี่ เรายินดีรับฟังความคิดเห็นเกี่ยวกับข้อเสนอที่นี่
คำขอฟีเจอร์	คำขอเปลี่ยนสคริปต์ terraform เพื่อที่ว่าหากไม่ได้ตั้งค่า service_account_token_creator_list (หรือว่างเปล่าไว้) ระบบจะข้ามการแก้ไขนโยบาย IAM ของบัญชี	เรากำลังตรวจสอบปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศ
การใช้ API	ต้องการคำชี้แจงเกี่ยวกับแผน Terraform ที่แสดงการเปลี่ยนแปลงอยู่เสมอ	ปัญหานี้ได้รับการแก้ไขแล้วในรุ่น AgS 2.8
การใช้ API	การขอคำแนะนำในการตั้งค่าต่อผู้ลงโฆษณาแต่ละรายสำหรับความถี่ในการรวมด้วยการกรองการมีส่วนร่วมที่ยืดหยุ่น	ปัจจุบันการแบ่งกลุ่มตามผู้ลงโฆษณาทําได้โดยใช้ ARA การกรองการมีส่วนร่วมที่ยืดหยุ่นอาจใช้กับกรณีที่ซับซ้อนมากขึ้นเมื่อเทคโนโลยีโฆษณาต้องการแบ่งกลุ่มการมีส่วนร่วมของรายงานตามความถี่ที่แตกต่างกัน ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาดูข้อมูลเพิ่มเติมเกี่ยวกับการจัดกลุ่มได้ที่นี่ และการใช้รหัสการกรองกับ ARA ได้ที่นี่ นอกจากนี้เรากำลังเพิ่มเอกสารประกอบเพิ่มเติมสำหรับการกรองรหัสด้วย
คำขอฟีเจอร์	ขอรับการสนับสนุนสําหรับ `log_sum_exp` ในบริการรวมข้อมูล (AgS)	เราได้ติดต่อผู้มีส่วนเกี่ยวข้องรายนี้เพื่อขอรายละเอียดเพิ่มเติมเกี่ยวกับกรณีการใช้งานแล้ว เราจะแจ้งข้อมูลอัปเดตเมื่อได้รับรายละเอียดเพิ่มเติม
คำขอฟีเจอร์	ขอดูบันทึก/ข้อมูลเชิงลึก/เมตริกอื่นๆ เพิ่มเติมเมื่อมีปัญหาเกี่ยวกับ AgS และปัญหาที่อาจเกิดขึ้นกับ AgS ที่ติดตั้งใช้งาน	เราได้เผยแพร่การอัปเดตเอกสารประกอบเพื่อรวมข้อผิดพลาด มาตรการบรรเทา และคำอธิบายเพิ่มเติมไว้ที่นี่ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับข้อผิดพลาด/เมตริก/บันทึก ฯลฯ ที่ไม่ได้บันทึกไว้หรือมีให้ใช้งาน และรายละเอียดที่เป็นประโยชน์ ที่นี่
การทดสอบ API	ค่าสุดท้ายของ epsilon หลังจากระยะเวลาการทดสอบจะเป็นเท่าใด	ในขณะนี้ยังไม่มีแผนที่จะแก้ไขกรอบเวลาค่า epsilon เราขอแนะนำให้ผู้ทดสอบลองใช้พารามิเตอร์ต่างๆ และแสดงความคิดเห็น
การรายงาน	กำลังสร้างรายงาน แต่ยังคงได้รับ PRIVACY_BUDGET_AUTHORIZATION_ERROR ในโค้ดส่งกลับ	เรามีคําแนะนําเกี่ยวกับการระบุแหล่งที่มาของการรายงานที่ถูกต้องและรายงานที่รวบรวมได้เพื่อหลีกเลี่ยงข้อผิดพลาดนี้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้ โดยเฉพาะในกรณีที่เกิดข้อผิดพลาดซ้ำ
การค้นพบคีย์	แผนสำหรับข้อเสนอการค้นพบที่สำคัญมีอะไรบ้าง	เรายังไม่มีไทม์ไลน์สำหรับการเปิดตัวข้อเสนอการค้นพบคีย์ แต่เรากำลังรวบรวมความคิดเห็นจากระบบนิเวศเกี่ยวกับข้อเสนอที่นี่
การปรับแต่ง	มองหาตัวเลือกการปรับแต่งที่ใช้ได้กับบริการรวมข้อมูล	คุณจะปรับแต่งบริการรวบรวมข้อมูลภายใน TEE ไม่ได้ แต่ปรับแต่งคอมโพเนนต์บางอย่างนอก TEE ได้ สาเหตุเป็นเพราะมาตรฐานด้านความเป็นส่วนตัวและความปลอดภัยที่เราจำเป็นต้องรักษาภายใน TEE เรากําลังอัปเดตเอกสารประกอบเพื่อช่วยนักเทคโนโลยีโฆษณาทําความเข้าใจสถาปัตยกรรมและองค์ประกอบที่กําหนดเองได้ เราไม่สามารถรองรับการปรับแต่งบางอย่างได้ จึงขอแนะนําให้เทคโนโลยีโฆษณาใช้การกําหนดค่ามาตรฐานของเราหากเป็นไปได้
อินสแตนซ์สปอตเทียบกับอินสแตนซ์แบบออนดีมานด์	ระบบได้รับการทดสอบโดยใช้อินสแตนซ์แบบ Spot เทียบกับอินสแตนซ์แบบออนดีมานด์หรือไม่ การใช้อินสแตนซ์แบบ Spot มีข้อเสียที่เฉพาะเจาะจงนอกเหนือจากการที่อาจไม่พร้อมใช้งานชั่วคราวไหม	เราไม่ได้ให้ความสําคัญกับการทดสอบในอินสแตนซ์แบบออนดีมานด์ เนื่องจากเราแนะนําให้เทคโนโลยีโฆษณาใช้อินสแตนซ์แบบออนดีมานด์ ข้อเสียของอินสแตนซ์แบบไม่ระบุแหล่งที่มาคืองานจะหยุดชะงักระหว่างการใช้งบประมาณ หากงบประมาณถูกใช้ไปและงานถูกขัดจังหวะก่อนที่เทคโนโลยีโฆษณาจะได้รับรายงานสรุป เทคโนโลยีโฆษณาจะไม่สามารถลองทำงานอีกครั้งได้ แต่จะต้องทำเรื่องขอการกู้คืนงบประมาณ ขอแนะนำให้กู้คืนงบประมาณเฉพาะในกรณีที่เกิดความล้มเหลวครั้งใหญ่เท่านั้น เพื่อรักษาความเป็นส่วนตัว เราขอแนะนำให้เทคโนโลยีโฆษณากำหนดค่าการปรับขนาดอัตโนมัติเพื่อช่วยลดค่าใช้จ่าย การเลือก 0 สำหรับการปรับขนาดอัตโนมัติหมายความว่าจะไม่มีอินสแตนซ์ที่ทำงานอยู่จนกว่าจะมีการส่งคำของาน (โปรดทราบว่าการดำเนินการนี้อาจเพิ่มเวลาในการตอบสนองเนื่องจากระบบจะสร้างอินสแตนซ์ขึ้นเมื่อได้รับคำขอ)
ข้อผิดพลาดและวิธีแก้ไขที่ทราบ	ต้องการคำชี้แจงเกี่ยวกับงานบริการรวมข้อมูลซึ่งแสดง "ข้อผิดพลาดในการให้บริการ"	ปัญหานี้ได้รับการแก้ไขแล้วที่นี่ นอกจากนี้ เรายังได้อัปเดตข้อความแสดงข้อผิดพลาดบางรายการเพื่อให้สื่อความหมายมากขึ้น ตัวอย่างเช่น เราเริ่มแสดงข้อผิดพลาดเกี่ยวกับสิทธิ์/การตรวจสอบสิทธิ์ที่เฉพาะเจาะจงมากขึ้นใน AWS แทนที่จะแสดงข้อผิดพลาดเหล่านี้เป็นข้อผิดพลาดภายใน เราได้อัปเดตเอกสารประกอบเกี่ยวกับรหัสข้อผิดพลาดและขั้นตอนการลดผลกระทบที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับข้อผิดพลาดที่ไม่มีเอกสารประกอบหรือข้อมูลไม่พร้อมใช้งาน รวมถึงรายละเอียดที่เป็นประโยชน์ ที่นี่

Private Aggregation API

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
Key Design	ขอคําแนะนําในการออกแบบคีย์การรวมข้อมูลส่วนตัว	แม้ว่าเราจะไม่มีคู่มือเฉพาะสำหรับการรวบรวมข้อมูลส่วนตัว แต่คุณใช้ทั้งเฟรมเวิร์กการทดสอบการโหลดบริการรวบรวมข้อมูลและคู่มือการจัดการคีย์ขั้นสูงเป็นทรัพยากรได้
งบประมาณการมีส่วนร่วม	งบประมาณการมีส่วนร่วมคํานวณและจํากัดในระดับใด	งบประมาณการมีส่วนร่วมคือ 2^16 ในกรอบเวลา 10 นาทีต่อเนื่อง และ 2^20 ในกรอบเวลา 24 ชั่วโมงต่อเนื่อง

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

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

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

การปกป้อง IP (เดิมเรียกว่า Gnatcatcher)

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

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

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

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

ตามที่ระบุไว้ในคำอธิบายเกี่ยวกับ GitHub และเว็บไซต์สำหรับนักพัฒนาซอฟต์แวร์ เราไม่ได้พิจารณางบประมาณความเป็นส่วนตัวเป็นส่วนหนึ่งของข้อเสนอ Privacy Sandbox อีกต่อไป

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

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
(รายงานในไตรมาสก่อนหน้าด้วย) ขีดจํากัดโดเมนของชุดเว็บไซต์ที่เกี่ยวข้อง (RWS)	คำขอเพิ่มขีดจำกัดโดเมนที่เชื่อมโยงภายใน RWS	คำตอบของเราจะคล้ายกับในไตรมาสก่อนหน้า ปัจจุบันเรายังไม่คาดว่าจะเพิ่มขีดจำกัดตัวเลข ขีดจํากัดนี้กําหนดขึ้นโดยพิจารณาจากความเป็นส่วนตัวของผู้ใช้ ความคิดเห็นจากผู้มีส่วนเกี่ยวข้องในระบบนิเวศของ W3C และการพิจารณาการใช้งานที่เปรียบเทียบได้ ในเบราว์เซอร์อื่นๆ ดูข้อมูลเพิ่มเติมได้ในบล็อกโพสต์ (1, 2) เราขอแนะนําให้ตรวจสอบกรณีการใช้งานที่จําเป็นต้องใช้สิทธิ์เข้าถึงคุกกี้ข้ามเว็บไซต์เกินขีดจํากัดตัวเลข และพิจารณาใช้ประโยชน์จากคําแนะนําสําหรับกรณีการใช้งานเกี่ยวกับข้อมูลระบุตัวตน การฝังที่ตรวจสอบสิทธิ์แล้ว และกรณีการใช้งานเกี่ยวกับโฆษณา หากเซสชันของผู้ใช้เชื่อมโยงกับการดำเนินการเข้าสู่ระบบ เราขอแนะนำให้ใช้ Federated Credential Management (FedCM) API เพื่อคงฟังก์ชันการทำงานไว้ เรายินดีรับฟังความคิดเห็นเกี่ยวกับกรณีการใช้งานอื่นๆ ที่อาจจำเป็นต้องดำเนินการที่นี่
การจัดการคุกกี้ข้ามเว็บไซต์	ระบบจะไม่ส่งคุกกี้ข้ามเว็บไซต์ที่โดเมนย่อยตั้งไว้ในคำขอที่ตามมาจากโดเมนหลัก ปัญหาจะยังคงอยู่แม้จะกำหนดค่า CORS และการกำหนดค่าข้อมูลเข้าสู่ระบบที่ถูกต้องแล้วก็ตาม	เรามีคําแนะนําที่นี่เกี่ยวกับการใช้ requestStorageAccessFor API อย่างถูกต้อง ซึ่งต้องระบุต้นทางแบบเต็ม (เช่น รวมโดเมนย่อย) เพื่อให้ระบบส่งคุกกี้ข้ามเว็บไซต์ในคําขอดึงข้อมูลในภายหลัง
ตัวเลือกของผู้ใช้	ขอข้อมูลเพิ่มเติมเกี่ยวกับ requestStorageAccessFor ที่ RWS ใช้งานหลังจากเปิดตัวทางเลือกของผู้ใช้ โดยเฉพาะวิธีที่ท่าทางสัมผัสของผู้ใช้แบบโดยนัยหรืออย่างโจ่งแจ้งซึ่งปัจจุบันอนุญาตการเข้าถึงของบุคคลที่สาม จะทำงานในระบบใหม่	เราคาดว่าลักษณะการทํางานของ RWS ในโหมดทางเลือกของผู้ใช้ (ไม่ว่าจะเลือกเก็บหรือจํากัด 3PC) จะสอดคล้องกับลักษณะการทํางานที่มีอยู่/ใช้งานจริงใน Chrome ที่อนุญาต 3PC เทียบกับ 3PC ที่ถูกบล็อกโดยเปิดใช้ RWS ("อนุญาตให้เว็บไซต์ที่เกี่ยวข้องดูกิจกรรมของคุณในกลุ่ม") เราขอแนะนำให้เรียกใช้ hasStorageAccess ก่อนเพื่อตรวจสอบว่าการฝังมีสิทธิ์เข้าถึงคุกกี้ข้ามเว็บไซต์ที่ไม่ได้แบ่งพาร์ติชันแล้วหรือไม่ก่อนที่จะเรียกใช้ requestStorageAccess เมธอด hasStorageAccess จะแสดงผลเป็น "จริง" หากผู้ใช้เลือกอนุญาต 3PC ปัจจุบัน requestStorageAccessFor ไม่จำเป็นต้องใช้ท่าทางสัมผัสของผู้ใช้หากอนุญาต 3PC เราได้เปิดปัญหาใหม่ใน GitHub เพื่อพูดคุยและระบุลักษณะการทำงานที่ถูกต้องในกรณีนี้ และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การใช้ API	ข้อกังวลเกี่ยวกับความคลุมเครือในการใช้ RWS เพื่อวัตถุประสงค์ "เชิงพาณิชย์" ซึ่งขัดขวางการนำไปใช้ ผู้มีส่วนเกี่ยวข้องแสดงความสนใจในการจัดกลุ่มสิ่งพิมพ์สําหรับการโฆษณาที่กําหนดเป้าหมาย	วัตถุประสงค์ในการใช้ RWS คือเพื่อรองรับฟังก์ชันหลักของเว็บไซต์และเส้นทางหลักของผู้ใช้ เราขอแนะนำให้ใช้ API การโฆษณาที่สร้างขึ้นสำหรับกรณีใช้งานที่เกี่ยวข้องกับการโฆษณาที่ตรงเป้าหมาย
การใช้ API	รายงานปัญหาเกี่ยวกับ requestStorageAccess ที่ผู้ใช้สามารถตั้งค่าข้อมูล localStorage แต่ตั้งค่าคุกกี้ไม่ได้	ปัญหานี้เกิดจากพิมพ์ผิดในแอตทริบิวต์ SameSite ตรวจสอบว่าการสะกดถูกต้อง และตั้งค่าเป็น "ไม่มี" สำหรับ 3PC อย่างชัดเจน
ข้อกำหนดของ API	สคีมา JSON ในที่เก็บมีความคลาดเคลื่อน เช่น ตำแหน่งของช่อง "รายชื่อติดต่อ" ที่ไม่ถูกต้องและคำแนะนำสำหรับการปรับปรุง รวมถึงการใช้คีย์เวิร์ด "oneOf" เพื่อให้มั่นใจว่ามีความสอดคล้องกัน	เรากําลังตรวจสอบความคิดเห็นนี้และจะพิจารณาปรับปรุงสคีมาเหล่านี้ในอนาคตอันใกล้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
สิทธิ์เข้าถึง RWS ของบุคคลที่สาม (3P)	หากได้รับความยินยอมจากผู้ใช้ ให้อนุญาตช่องทางระบุโดเมนของบุคคลที่สามที่จะมีสิทธิ์เข้าถึงข้อมูล RWS API ดังกล่าวด้วย	การอนุญาตให้บุคคลที่สามรวมข้อมูลของตนเองที่ไม่ได้แบ่งพาร์ติชันเข้ากับข้อมูลเว็บไซต์ RWS จะบั่นทอนการปกป้องการติดตามข้ามเว็บไซต์ของ Privacy Sandbox อย่างไรก็ตาม เรากำลังพิจารณาความเป็นไปได้ในการอนุญาตให้บุคคลที่สามดูแลรักษาข้อมูลที่แบ่งพาร์ติชันไปยัง RWS และกำลังมองหาความคิดเห็นเกี่ยวกับการออกแบบโซลูชันดังกล่าว ที่นี่

Fenced Frames API

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
คำถามเกี่ยวกับ API	กังวลว่า Fenced Frame ที่ไม่มีการเข้าถึงเครือข่ายจะทำลายความปลอดภัยของแบรนด์และการป้องกันการฉ้อโกงสำหรับผู้ลงโฆษณาได้อย่างไร	เรากำลังติดตามข้อกังวลนี้ในบริบทของแผนที่จะบังคับใช้ Fenced Frame เราจะเริ่มค้นหาโซลูชันที่เหมาะสมกับการบังคับใช้ Fenced Frames ในเร็วๆ นี้ และทันทีที่มีข้อเสนอที่มีข้อมูลมากพอ เราจะแชร์แนวคิดดังกล่าว
คำถามเกี่ยวกับ API	Fenced Frames API ยังคงมีกำหนดการเปิดตัวในปี 2026 ใช่ไหม	ตามที่ระบุไว้ในประกาศสาธารณะ การใช้เฟรมที่มีการกำหนดเขตแดนจะบังคับใช้ไม่เร็วกว่าปี 2026
ข้อบกพร่องของ API	เมื่อ reportEvent() ส่งข้อมูลคลิกจากเฟรมย่อยข้ามแหล่งที่มาได้สําเร็จ setReportEventDataForAutomaticBeacons() จะไม่เขียนทับข้อมูลของเฟรมด้านบน	เรากำลังพูดคุยเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่

Shared Storage API

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การโฆษณาแอป	ไม่มี API พื้นที่เก็บข้อมูลที่ใช้ร่วมกันที่เทียบเท่าใน Privacy Sandbox บน Android	เรากำลังประเมินโซลูชันต่างๆ บน Android โดยอิงตามความต้องการด้าน Use Case และข้อจำกัดของแพลตฟอร์ม ขณะนี้เรายังไม่มีแผนที่จะแชร์ แต่ยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศเกี่ยวกับปัญหานี้
การใช้ API	ความสับสนเกี่ยวกับความจำเป็นในการใช้เวิร์กเลต JavaScript เพิ่มเติมเพื่อติดตั้งใช้งาน Shared Storage API	เรากำลังตรวจสอบความคิดเห็นนี้และพิจารณาที่จะอัปเดตเอกสารประกอบเพื่ออธิบายความจำเป็นของสคริปต์เวิร์กเลตเพิ่มเติมสำหรับ Share Storage API
ความไม่เสถียร	Shared Storage API อาจเปลี่ยนแปลงอย่างมากหรือถูกลบตามการวิพากษ์วิจารณ์ด้านความเป็นส่วนตัว ทำให้เป็นพื้นฐานที่ไม่น่าเชื่อถือในการต่อยอด	เราไม่มีแผนที่จะเปลี่ยนแปลงหรือเลิกใช้โครงสร้างพื้นฐานของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันอย่างมีนัยสำคัญ การเปลี่ยนแปลงหลักที่ประกาศไว้คือการเปลี่ยนแปลงใน Select URL Output Gate ซึ่งจะต้องมีเฟรมที่มีการกำหนดขอบเขตและการรายงานระดับเหตุการณ์จะเลิกใช้งาน อย่างไรก็ตาม การเปลี่ยนแปลงเหล่านี้จะไม่มีผลจนกว่าจะถึงปี 2026 เป็นอย่างน้อย

CHIPS

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
คุกกี้ที่แบ่งพาร์ติชัน	Chrome ไม่ได้แยกความแตกต่างของคีย์พาร์ติชันตามบรรพบุรุษของเฟรม ซึ่งแตกต่างจาก Firefox จึงทําให้เกิดความไม่สอดคล้อง	Chrome ใช้ "บิตเชนบรรพบุรุษ" เพื่อแก้ไขข้อกังวลด้านความปลอดภัยและความคลาดเคลื่อนกับลักษณะการทำงานของ Firefox เราได้อธิบายเรื่องนี้อย่างละเอียดยิ่งขึ้นที่นี่
คุกกี้ที่แบ่งพาร์ติชัน	iframe ที่ฝังซึ่งมีระดับการเข้าถึงพื้นที่เก็บข้อมูลต่างกันจะแชร์และเขียนทับคุกกี้ที่มีการแบ่งพาร์ติชันเดียวกัน ซึ่งทําให้สถานะการตรวจสอบสิทธิ์ไม่สอดคล้องกัน	สําหรับการกําหนดค่านี้ เราขอแนะนําให้ใช้คุกกี้ที่ไม่ได้แบ่งพาร์ติชันกับการเรียกใช้ Storage Access API เราได้พูดคุยอย่างละเอียดเกี่ยวกับเรื่องนี้ที่นี่
คุกกี้ที่แบ่งพาร์ติชัน	ระบบจะล้างโฟลเดอร์คุกกี้ที่แบ่งพาร์ติชันออกไหมเมื่อปิดใช้ 3PC มีวิธีทดสอบการทำงานนี้ไหม	เรายังไม่มีแผนที่จะแจ้งให้ทราบในขณะนี้ อย่างไรก็ตาม นักพัฒนาซอฟต์แวร์สามารถทดสอบฟังก์ชันนี้ได้โดยการลบคุกกี้ที่มีการแบ่งพาร์ติชันด้วยตนเองผ่านแผงแอปพลิเคชัน>คุกกี้ของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

FedCM

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ขอบเขตการลงทะเบียนผู้ให้บริการข้อมูลประจำตัว (IdP) และเครื่องมือเลือกองค์กร	คำถามเกี่ยวกับการขยายการลงทะเบียน IdP จากนโยบายต้นทางเดียวกันปัจจุบันเป็นนโยบายเว็บไซต์เดียวกัน การเปลี่ยนแปลงนี้จะช่วยให้การจัดการข้อมูลประจำตัวในวงกว้างและมีความยืดหยุ่นมากขึ้น เช่น การเปิดใช้หน้ายินดีต้อนรับของมหาวิทยาลัยเพื่อลงทะเบียนผู้ให้บริการข้อมูลประจำตัวที่ใช้โดเมนย่อยหลายราย โดยไม่จำเป็นต้องจดทะเบียนเฉพาะต้นทางแยกต่างหาก ความคิดเห็นเกี่ยวกับการปรับปรุงความสามารถในการแก้ไขข้อบกพร่อง การจัดการลูกค้าที่อนุมัติแล้วสําหรับสื่อกลางแบบเงียบ การชี้แจงลักษณะการทํางานของคุกกี้ อนุญาตให้ปรับแต่งข้อความป๊อปอัป และการแก้ไขปัญหาการหมดเวลา	เรารับทราบความคิดเห็นนี้และกำลังพิจารณาวิธีรวมเครื่องมือเลือกองค์กรไว้ใน FedCM เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ ที่นี่ขณะที่เราปรับแต่งแนวทางนี้ต่อไป
คุกกี้ IdP	การพูดคุยเกี่ยวกับผลกระทบของการใช้คุกกี้เซสชันที่มีอายุสั้นซึ่งเป็นส่วนหนึ่งของข้อเสนอข้อมูลเข้าสู่ระบบเซสชันที่ผูกกับอุปกรณ์ (DBSC) มีข้อกังวลเกี่ยวกับประสบการณ์ของผู้ใช้ใน FedCM ซึ่งคุกกี้ IdP ที่หมดอายุต้องใช้โมดัลที่ผู้ใช้มองเห็นได้สำหรับการต่ออายุ	DBSC ที่เสนอควรอนุญาตให้ต่ออายุคุกกี้ได้โดยไม่ต้องมีการโต้ตอบของผู้ใช้ เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานอย่างต่อเนื่อง เราได้พูดคุยเกี่ยวกับปัญหานี้โดยละเอียดยิ่งขึ้นที่นี่
ข้อกำหนดของ API	คำถามเกี่ยวกับความเหมาะสมในการใช้ "NetworkError" ในข้อกำหนดของ FedCM API เมื่อขนาดของอาร์เรย์ "providers" ไม่เท่ากับ 1	เราเห็นด้วยว่า "TypeError" เหมาะสมกับสถานการณ์นี้มากกว่า เนื่องจากแสดงถึงข้อผิดพลาดในการเขียนโค้ด ไม่ใช่ปัญหาเกี่ยวกับเครือข่าย เราจะพิจารณาการเปลี่ยนแปลงนี้และศึกษาความเป็นไปได้ในการนำข้อจำกัดนี้ออกในการอัปเดตในอนาคตเมื่อเราเดินหน้าสนับสนุนผู้ให้บริการระบุตัวตนหลายราย เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่

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

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

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