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

จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

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

Google ตกลงที่จะเผยแพร่รายงานรายไตรมาสเกี่ยวกับกระบวนการมีส่วนร่วมของผู้มีส่วนเกี่ยวข้องสำหรับข้อเสนอ Privacy Sandbox ของตนต่อสาธารณะ (ดูย่อหน้า 12 และ 17(ค)(ii) ของความมุ่งมั่น) ตามข้อตกลงกับ CMA รายงานสรุปความคิดเห็นเกี่ยวกับ 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
การกำกับดูแล	สนใจเข้าร่วมช่วงแสดงความคิดเห็นสาธารณะสำหรับข้อมูลอัปเดตเกี่ยวกับกฎระเบียบของ Privacy Sandbox	เรายินดีรับฟังความคิดเห็นที่สมเหตุสมผลจากผู้มีส่วนเกี่ยวข้องเกี่ยวกับการพัฒนาที่สำคัญเกี่ยวกับ Privacy Sandbox รวมถึงการกํากับดูแล Privacy Sandbox ในอนาคต
การทดสอบ	ระยะการทดสอบเพิ่มเติมสําหรับ 3PCD นอกเหนือจากการทดสอบที่อำนวยความสะดวกโดย Chrome 1% ในปัจจุบัน	เราไม่มีเจตนาที่จะเสนอการทดสอบที่อำนวยความสะดวกโดย Chrome นอกเหนือจากการเข้าชม Chrome 1% ปัจจุบันที่เปิดใช้ตั้งแต่ต้นเดือนมกราคม
Web to App	ไม่ควรใช้ 3PCD บนอุปกรณ์เคลื่อนที่จนกว่าเว็บและแอปจะทำงานร่วมกันได้อย่างสมบูรณ์	เราเห็นด้วยว่าควรรองรับการทำงานร่วมกันของแอปและเว็บ และได้เปิดตัวการวัดการระบุแหล่งที่มาแบบข้ามแอปและเว็บ รวมถึงกำลังสำรวจโซลูชันการกำหนดเป้าหมายจากเว็บไปยังแอป อย่างไรก็ตาม เราไม่มีแผนที่จะเลื่อนกำหนดเวลาเปิดตัว 3PCD ในเว็บบนอุปกรณ์เคลื่อนที่ เราไม่มีเป้าหมายในการครอบคลุม 100% เมื่อสิ้นสุด 3PCD แต่เราคาดว่าความเข้ากันได้ใน Android สําหรับการวัดผลข้ามแอปและเว็บจะสูงพอที่ 3PCD และเพิ่มขึ้นเมื่อเวลาผ่านไปเมื่อผู้ใช้อัปเดตโทรศัพท์
บทบาทของเบราว์เซอร์	ดูเหมือนว่า Chrome กำลังทำหน้าที่เป็นเซิร์ฟเวอร์โฆษณาหรือ SSP	Chrome ไม่ได้ทำหน้าที่เป็นเซิร์ฟเวอร์โฆษณาหรือ SSP เมื่อใช้ PA API ทาง Chrome จะจัดเตรียมคอนเทนเนอร์สําหรับเซิร์ฟเวอร์โฆษณา, SSP, DSP และเทคโนโลยีโฆษณาอื่นๆ เพื่อนําตรรกะการเสนอราคาและการให้คะแนนของตนเองมาใช้
คำแนะนำเกี่ยวกับกรณีการใช้งาน	คำแนะนำที่ชัดเจนยิ่งขึ้นเกี่ยวกับกรณีการใช้งานที่ Privacy Sandbox API จะรองรับ	ในช่วงเริ่มต้นของโปรเจ็กต์ Privacy Sandbox เอกสารของนักพัฒนาซอฟต์แวร์มุ่งเน้นที่การนํานักพัฒนาซอฟต์แวร์เข้าสู่กระบวนการพูดคุยและแสดงความคิดเห็นเกี่ยวกับข้อเสนอทั้งหมดเป็นหลัก ซึ่งหมายความว่าโดยทั่วไปเนื้อหาจะมีโครงสร้างที่เน้นทำความเข้าใจแรงจูงใจและแนวคิดเบื้องหลังโปรเจ็กต์ ตามด้วยรายละเอียดการพัฒนาในช่วงแรกและรายละเอียดการทดสอบสำหรับข้อเสนอแต่ละรายการ วิธีนี้มีประสิทธิภาพในการสร้างการทำงานร่วมกันในระบบนิเวศจริงในการพัฒนาข้อเสนอ แต่เนื่องจาก API พัฒนาขึ้นจนพร้อมให้บริการแก่ผู้ใช้ทั่วไปแล้ว จึงมีกลุ่มเป้าหมายใหม่ซึ่งเป็นนักพัฒนาแอปที่เข้ามาเพื่อใช้ API เป็นหลัก มากกว่าที่จะมีส่วนร่วมในการพัฒนาเบื้องหลัง เมื่อเร็วๆ นี้เราได้อัปเดตการนําทางของเว็บไซต์สําหรับนักพัฒนาแอป Privacy Sandbox ให้มุ่งเน้นที่กรณีการใช้งาน โดยใช้การจัดหมวดหมู่ที่คล้ายกับ IAB Tech Lab ในรายงานล่าสุดของคณะทำงาน Privacy Sandbox เราจะใช้แนวทางที่อิงตาม Use Case นี้กับเอกสารประกอบต่อไป
สภาพแวดล้อมการพัฒนาในเครื่อง	เราจะพัฒนาและทดสอบส่วนหน้าในเครื่องบน http://localhost ต่อได้อย่างไรเมื่อคุกกี้มี SameSite=Secure และ CDN อยู่หน้าแบ็กเอนด์	เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การลด 3PCD	มีวิธีแบบเป็นโปรแกรมในการทราบว่า 3PC ถูกบล็อกหรือเมื่อใช้วิธีการเฮิวริสติกอยู่ไหม	ใน Chrome ทั้งการตรวจหาฟีเจอร์และ document.hasStorageAccess ที่เรียกใช้ใน iframe จะช่วยให้นักพัฒนาซอฟต์แวร์ทราบว่าต้นทางใน iframe มีสิทธิ์เข้าถึง 3PC หรือไม่
การทดสอบวิดีโอ	ขณะนี้ทดสอบโฆษณาวิดีโอใน Privacy Sandbox ไม่ได้	Chrome ได้โพสต์การพูดคุยและการสาธิตวิธีต่างๆ ที่เป็นไปได้ในการใช้วิดีโอกับ PA API ในปัจจุบัน (ดู 242 และ 254 ในที่เก็บข้อมูลเดโมบน GitHub) โปรดทราบว่าโค้ดเหล่านี้ไม่ได้มีไว้เพื่อเป็นตัวอย่างโค้ดที่เทคโนโลยีโฆษณาจะนำไปใช้โดยรวม แต่มีไว้เพื่อพิสูจน์แนวคิดและสาธิตเทคนิคที่รองรับการแสดงผลวิดีโอ VAST ด้วย PA API ในระหว่างการพูดคุยนี้ เราพบว่าแม้ปัจจุบันการแสดงผลวิดีโอจะเป็นไปได้แล้ว แต่ Chrome ก็สามารถทําการเปลี่ยนแปลงที่จะช่วยให้การติดตั้งใช้งาน PA API ง่ายขึ้น ตัวอย่างเช่น การอัปเดตการแทนที่มาโคร (ซึ่งได้พูดคุยกัน ที่นี่) ซึ่งเราวางแผนที่จะดำเนินการอยู่แล้วตามความคิดเห็นเกี่ยวกับ Use Case ความปลอดภัยของแบรนด์ในโปรแกรมตรวจสอบโฆษณาของบุคคลที่สาม ก็จะจัดการกับความคิดเห็นใน Use Case วิดีโอด้วย โดยที่ผู้ซื้อจะมองหามาโครของผู้ขายที่จะใช้ในการแสดงผล การสนทนาส่วนใหญ่จนถึงตอนนี้มุ่งเน้นที่การแสดงผลโฆษณาวิดีโอ VAST โดยเฉพาะ การแสดงผลโฆษณาเนทีฟอาจใช้แนวทางเดียวกันและทําได้ง่ายกว่าในหลายด้าน ปัจจุบันโฆษณาเนทีฟดูเหมือนว่าจะได้รับความสนใจน้อยกว่าวิดีโอ แต่นี่เป็นเพียงเรื่องของลำดับความสำคัญของอุตสาหกรรมเทคโนโลยีโฆษณา ไม่ใช่อุปสรรคทางเทคนิคในการใช้งาน
การวัดผลที่ไม่ใช่โฆษณา	3PCD อาจส่งผลต่อโซลูชันการวัดกลุ่มเป้าหมายที่ไม่เกี่ยวข้องกับโฆษณา	API การวัดผลไม่ได้กําหนดว่า Use Case จะต้องเกี่ยวข้องกับโฆษณา แม้ว่า ARA จะเจาะจงกับเส้นทางการโฆษณาทั่วไปมากกว่า แต่ การรวมข้อมูลส่วนตัวมีไว้เพื่อวัตถุประสงค์ทั่วไป องค์ประกอบพื้นฐาน 2 รายการนี้สามารถใช้เพื่อจัดการกิจกรรมการวัดผลที่หลากหลาย
ครีเอเตอร์เนื้อหา	Privacy Sandbox สร้างขึ้นเพื่อส่งเสริมให้ครีเอเตอร์สร้างเนื้อหาบน YouTube มากขึ้นและสร้างเนื้อหาในเว็บไซต์ของตนเองน้อยลง	โครงการริเริ่ม Privacy Sandbox มุ่งเน้นที่การรักษากิจกรรมของผู้ใช้ให้เป็นส่วนตัวบนอินเทอร์เน็ตแบบเปิดและเสรี เราทราบดีว่าผู้เผยแพร่โฆษณาใช้โฆษณาในการสร้างเนื้อหาและทำให้เนื้อหาพร้อมให้บริการในวงกว้างที่สุด ผู้ลงโฆษณาช่วยให้ผู้คนค้นพบผลิตภัณฑ์หรือข้อเสนอใหม่ๆ ที่อาจต้องการ ฟีเจอร์ Privacy Sandbox ช่วยให้เว็บไซต์ทุกประเภท รวมถึงเว็บไซต์ที่ทํางานร่วมกับครีเอเตอร์เนื้อหา สามารถแสดงโฆษณาที่เป็นประโยชน์ต่อผู้ใช้โดยอิงตามกิจกรรมของผู้ใช้กับบุคคลที่สามต่างๆ โดยไม่ต้องเปิดเผยตัวตนของผู้ใช้ต่อบุคคลเหล่านั้น
ไทม์ไลน์ที่ชัดเจนยิ่งขึ้น	กำหนดการเปิดตัวเทคโนโลยี Privacy Sandbox ที่ชัดเจนและละเอียดยิ่งขึ้น	เอกสารประกอบของ Privacy Sandbox API มีหน้าสถานะและความพร้อมให้บริการของ API หน้าเหล่านี้จะแสดงฟีเจอร์ที่กําลังจะมีให้บริการและลําดับเวลา (เช่น PA API, ARA) คุณสามารถดูสถานะเหล่านี้ได้ในมุมมองส่วนกลางที่นี่
แมชชีนเลิร์นนิง	เทคโนโลยีโฆษณาจะฝึกโมเดลแมชชีนเลิร์นนิงอย่างถูกต้องไม่ได้จนกว่า 3PCD จะมากกว่า 1%	การขยาย 3PCD ไปยังเบราว์เซอร์เพิ่มเติมเพื่อทดสอบไม่ได้รับประกันว่า API จะได้รับการใช้งานมากขึ้น ซึ่งเป็นสิ่งที่นักเทคโนโลยีโฆษณาต้องการเพื่อฝึกโมเดลแมชชีนเลิร์นนิงต่อไป หากการใช้ระบบนิเวศที่กว้างขึ้นไม่ใช่สิ่งที่เทคโนโลยีโฆษณาต้องการเพื่อฝึกโมเดลแมชชีนเลิร์นนิงในภายหลัง ก็ไม่มีเหตุผลที่จะขยาย 3PCD เนื่องจากเทคโนโลยีโฆษณาที่ต้องการฝึกโมเดลจากการเข้าชมมากขึ้นสามารถทำได้แล้วในปัจจุบันโดยไม่ต้องเพิ่ม 3PCD ซึ่งทำได้โดยไม่ต้องให้ Chrome ปรากฏขึ้นเพื่อเลื่อนไปข้างหน้าใน 3PCD ก่อนสิ้นสุดช่วงหยุดนิ่ง
กรณีการใช้งานที่ไม่รองรับ	ขณะนี้เรายังไม่พิจารณา Use Case ของ DSP แบบบริการตนเอง	มี DSP แบบบริการตนเองหลายรายที่แสดงความคิดเห็นต่อสาธารณะเกี่ยวกับ API เป็นประจำ DSP หลายรายที่แสดงความคิดเห็นต่อสาธารณะเป็นประจำได้ระบุว่าตนเองเป็นผู้ทดสอบด้วย นอกจากนี้ Chrome ยังมีส่วนร่วมในหัวข้อ DSP แบบบริการตนเองทั่วไป เช่น วิดีโอและเซิร์ฟเวอร์โฆษณาของบุคคลที่สาม การเรียก PA API รายสัปดาห์ล่าสุดครอบคลุมหัวข้อเหล่านี้
ช่วงทดลองใช้จากต้นทาง	ขอ OT สำหรับเว็บไซต์ที่ต้องการเพิ่มการเปิดตัวและทดสอบที่ครอบคลุมมากขึ้นสำหรับ 3PCD	ปัจจุบัน Chrome กำลังพัฒนา OT ของบุคคลที่หนึ่ง ซึ่งจะช่วยให้ต้นทางเลือกใช้ลักษณะการเลิกใช้งาน 3PC ได้ ต้นทางระดับบนสุดที่ลงทะเบียนเข้าร่วมช่วงทดลองใช้นี้และติดตั้งใช้งานโทเค็นจะมีการบล็อก 3PC เหมือนกับว่าอุปกรณ์ของผู้ใช้เปิดใช้การปกป้องการติดตาม OT นี้จะเปิดโอกาสอันล้ำค่าให้เว็บไซต์ทำการทดสอบทางเลือกระยะยาวที่ครอบคลุมมากขึ้นสำหรับ 3PC ก่อนที่จะเลิกใช้งาน 3PC ในที่สุดตามกำหนดการหลังจากการปรึกษา CMA เรากําลังกําหนดเวลาการเปิดตัว OT นี้ให้เสร็จสมบูรณ์
รายงานจากห้องทดลองเทคโนโลยีของ IAB	ความคิดเห็นเกี่ยวกับ Privacy Sandbox ที่ได้รับจากรายงานของ IAB Tech Lab	เราได้ตอบกลับรายงานของ IAB Tech Lab โดยละเอียดที่นี่ นอกจากนี้ เรายังรับทราบว่า "รายงานนี้ทำให้เกิดคำถามเกี่ยวกับเอกสารประกอบที่กระจัดกระจาย ข้อกำหนดทางธุรกิจ การตรวจสอบโดยบุคคลที่สาม การรับรองอุตสาหกรรม ความสามารถในการปรับขนาด ความโปร่งใส และการจัดการในอนาคต ซึ่งเราจะมีส่วนร่วมกับระบบนิเวศและอัปเดตคําถามที่พบบ่อยแบบสาธารณะของเราตามความเหมาะสม" เราได้จัดการเอกสารประกอบที่กระจัดกระจายก่อนหน้านี้ เราจัดการข้อกําหนดทางการค้าในส่วน "การรับประกันข้อมูล" ที่นี่ และผลิตภัณฑ์ Google Ads บางรายการได้แชร์แนวทางปฏิบัติของตน เราได้กล่าวถึงการตรวจสอบโดยบุคคลที่สามในส่วน "การรับประกันความสมบูรณ์ของอัลกอริทึม" ที่นี่ ในส่วนของการรับรอง เราคาดหวังว่าหน่วยงานเหล่านั้นจะยังคงรับรองผลิตภัณฑ์ รวมถึงการใช้เทคโนโลยีของผลิตภัณฑ์ต่อไป แทนที่จะรับรองเทคโนโลยีเพียงอย่างเดียว ในส่วนของความสามารถในการปรับขนาด เรายังคงเปิดรับข้อมูลจากนักพัฒนาแอปที่แสดงให้เห็นถึงปัญหา ในด้านความโปร่งใสและการจัดการ เรายังคงพัฒนาแบบเปิดใน GitHub และในฟอรัมต่างๆ เช่น W3C ขณะมีส่วนร่วมกับ CMA ภายใต้ความมุ่งมั่น
Google Sign-In	การลงชื่อเข้าใช้ด้วย Google อาจทำให้ Google ใช้ข้อมูลการเข้าสู่ระบบที่มีการระบุตัวตนข้าม ซึ่งขัดต่อความมุ่งมั่น	ฟีเจอร์ลงชื่อเข้าใช้ด้วย Google ไม่ได้อนุญาตให้ Google ใช้ข้อมูลที่ขัดต่อความมุ่งมั่น
ความเข้ากันได้	แผนการสนับสนุน Privacy Sandbox API และความสามารถในการใช้งานร่วมกันแบบย้อนหลัง / ไปข้างหน้าเป็นอย่างไร	เมื่อ Chrome เปิดตัวฟีเจอร์ที่พร้อมให้บริการแก่ผู้ใช้ทั่วไปแล้ว เราจะมุ่งมั่นที่จะรองรับฟีเจอร์นั้นต่อไป แน่นอนว่าเราไม่สามารถคงความเข้ากันได้แบบย้อนหลังได้เสมอไป และในกรณีเช่นนี้ เรามีกระบวนการที่ชัดเจนสำหรับการเลิกใช้งานและนำฟีเจอร์ที่มีอยู่ออก ซึ่งอธิบายไว้ที่นี่ เราคาดว่าจะเพิ่มฟีเจอร์อื่นๆ ลงใน Privacy Sandbox API อย่างต่อเนื่องในอนาคต เพื่อตอบสนองต่อความคิดเห็นจากระบบนิเวศเกี่ยวกับกรณีการใช้งานที่จะได้รับประโยชน์จากการรองรับที่ดีขึ้น ในกรณีเช่นนี้ เรามักจะใส่เทคนิคการตรวจหาฟีเจอร์บางประเภท เพื่อให้เทคโนโลยีโฆษณาที่สนใจทดสอบฟีเจอร์ใหม่สามารถสอบถามเบราว์เซอร์ได้โดยตรงว่ารองรับฟีเจอร์ดังกล่าวหรือไม่ วิธีนี้ดีกว่าการขอให้นักพัฒนาซอฟต์แวร์ตรวจสอบหมายเลขเวอร์ชัน Chrome เนื่องจากฟีเจอร์บางอย่างอาจไม่ได้เปิดตัวให้ผู้ใช้ Chrome ทุกคนพร้อมกัน เช่น คุณสามารถดูงานการตรวจหาฟีเจอร์สําหรับ PA API ได้ที่นี่
การติดตั้งใช้งานเซิร์ฟเวอร์	Chrome ควรระบุลักษณะการทำงานที่เซิร์ฟเวอร์สัญญาณที่เชื่อถือ เซิร์ฟเวอร์การรวบรวม และคอมโพเนนต์อื่นๆ ที่ไม่เกี่ยวข้องกับเบราว์เซอร์ต้องมีคุณสมบัติตรงตามเพื่อให้การใช้งานมีประสิทธิภาพ แทนที่จะเชื่อมโยงกับการใช้งานของตนเอง ซึ่งจะช่วยให้เกิดนวัตกรรมภายในขอบเขตความเป็นส่วนตัวที่ยอมรับได้	เรายินดีและสนับสนุนความปรารถนาของบุคคลภายนอกที่ต้องการสร้างนวัตกรรม สําหรับ API และบริการทั้งหมด เรามุ่งมั่นที่จะมอบความยืดหยุ่นให้กับเทคโนโลยีโฆษณาในการใช้งานฟังก์ชันการทำงาน ตัวอย่างเช่น เราอนุญาตให้เทคโนโลยีโฆษณาใช้ข้อมูลทางธุรกิจที่เป็นความลับในการออกแบบตรรกะการเสนอราคาสำหรับการประมูล นอกจากนี้ เรายังรับฟังความคิดเห็นจากเทคโนโลยีโฆษณาอย่างต่อเนื่องและนําความคิดเห็นเหล่านั้นมาปรับใช้ในการออกแบบของเราเมื่อเห็นสมควร หากต้องการให้ผู้อื่นเรียกใช้โค้ดของตนเองในสภาพแวดล้อมการทํางานที่เชื่อถือได้ Privacy Sandbox จะต้องตรวจสอบโค้ด (และการเปลี่ยนแปลงทั้งหมด) เพื่อยืนยันว่าโค้ดเป็นไปตามการรับประกันความเป็นส่วนตัว ซึ่งต้องใช้ความพยายามอย่างมากจากทีม Privacy Sandbox เราจึงอยากทราบว่าผู้มีส่วนเกี่ยวข้องต้องการบรรลุประโยชน์ใดบ้างที่เรายังไม่สามารถทำได้ในปัจจุบัน
การคาดคะเน	แผนระยะยาวสำหรับวิธีการแก้ปัญหาแบบเฮuristic คืออะไร	เราตั้งใจที่จะเลิกใช้งานวิธีการเฮuristic เหล่านี้เมื่อโซลูชันอื่นๆ เริ่มมีการใช้งานอย่างแพร่หลาย ทั้งนี้ขึ้นอยู่กับการวิเคราะห์ความเป็นไปได้เพิ่มเติม เราได้แชร์ข้อมูลนี้ไว้ที่นี่
ปริมาณการทดสอบ	ปริมาณการเข้าชมที่แตกต่างกันเมื่อเปรียบเทียบมิติข้อมูลต่างๆ	การทดสอบ 1% มีเกณฑ์การยกเว้นที่ทําให้สิทธิ์ในการทดสอบแตกต่างกันไประหว่างกลุ่มผู้ใช้ Chrome แต่ละกลุ่ม เช่น การทดสอบไม่รวมผู้ใช้ Chrome Enterprise จึงคาดว่าส่วนแบ่งการเข้าชมที่มีป้ายกำกับการทดสอบจะสูงขึ้นในช่วงสุดสัปดาห์ เป็นเรื่องปกติที่จะเห็นเปอร์เซ็นต์การเข้าชมที่แตกต่างกันในข้อมูลส่วนต่างๆ (เช่น ภูมิศาสตร์ วันที่ และแพลตฟอร์ม) ซึ่งสอดคล้องกับสิ่งที่เราเห็นในข้อมูล Chrome
เปิดใช้ 3PC อีกครั้งด้วยตนเอง	เว็บไซต์จะทราบได้ไหมว่ามีผู้ใช้จำนวนเท่าใด (%) ที่เปิดใช้คุกกี้อีกครั้งด้วยตนเองหลังจากบังคับใช้ 3PCD	ผู้ใช้จะเปิดใช้การเข้าถึง 3PC อีกครั้งที่ระดับเว็บไซต์ได้ผ่าน User Bypass หากพบปัญหา นอกจากนี้ 3PC อาจเปิดใช้อีกครั้งได้ด้วยมาตรการอื่นๆ เช่น Storage Access API มีมาตรการทางเทคนิค เช่น hasStorageAccess() ที่ช่วยให้เว็บไซต์ตรวจได้ว่า 3PC เปิดหรือปิดใช้อยู่ อย่างไรก็ตาม Chrome จะไม่อำนวยความสะดวกให้เว็บไซต์ทราบเหตุผลในการเปิดใช้อีกครั้ง
การป้องกันการติดตาม	ฟีเจอร์ UI การป้องกันการติดตามของ Chrome จะพร้อมใช้งานต่อไปอีกนานเท่าใด	เราคาดว่า UI การป้องกันการติดตามในแถบที่อยู่จะยังคงอยู่หลังจากที่เลิกใช้งาน 3PC
(รายงานในไตรมาสก่อนหน้าด้วย) การรองรับข้ามเบราว์เซอร์	ผู้ให้บริการเบราว์เซอร์รายอื่นๆ ที่ใช้ Privacy Sandbox API	ผู้ให้บริการเบราว์เซอร์รายอื่นๆ เช่น Apple, Mozilla และ Microsoft เป็นผู้เข้าร่วมที่กระตือรือร้นในฟอรัมสาธารณะที่มีการพูดคุยเกี่ยวกับหลักการด้านความเป็นส่วนตัวและแนวทางตามเบราว์เซอร์ เรายินดีที่ได้เห็นว่าการสนทนาแบบร่วมมือกันในฟอรัมต่างๆ เช่น การประชุม TPAC ประจำปีของ W3C เมื่อเร็วๆ นี้และฟอรัม PATCG ของ W3C ที่ดำเนินอยู่นั้นแสดงให้เห็นถึงสัญญาณของการบรรจบกัน ตัวอย่างเช่น เมื่อเร็วๆ นี้ Microsoft Edge ได้ประกาศแผน "ที่มุ่งเน้นเพิ่มความเข้ากันได้ทางไวยากรณ์ให้มากที่สุด" กับ PA API และ ARA พร้อมกับนำเสนอฟีเจอร์เพิ่มเติมสำหรับนักพัฒนาซอฟต์แวร์ด้วย
ตัวเลือกสำรองสําหรับการฝังที่เข้ากันไม่ได้หลัง 3PCD	ระบุฮุก API เพื่อตรวจจับว่า iframe / การฝังของบุคคลที่สามเป็นไปตาม 3PCD หรือไม่	เรากำลังหารือเกี่ยวกับคำขอนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การทดสอบ	ขอ Flag เพิ่มเติมในอินสแตนซ์ Chrome ที่มีการจัดการซึ่งจะปิดลักษณะการทำงานที่กำหนดเองชั่วคราว	เรากำลังพิจารณาคำขอนี้สำหรับอินสแตนซ์ Chrome ที่มีการจัดการและยินดีรับข้อมูลเพิ่มเติมจากระบบนิเวศหากการแจ้งว่าไม่เหมาะสมดังกล่าวจะเป็นประโยชน์

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

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

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

หัวข้อ

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
(รายงานในไตรมาสก่อนหน้าด้วย) ลำดับเวลาและเอกสารประกอบเกี่ยวกับตัวจัดประเภท	ควรมีกลไกบางอย่างในการตรวจสอบการจัดประเภท หรืออย่างน้อยก็มีความโปร่งใสมากขึ้นเกี่ยวกับวิธีที่โหมดการจัดประเภทกำหนดหมวดหมู่	คำตอบของเราไม่มีการเปลี่ยนแปลงจากไตรมาสก่อนหน้า "การจัดประเภทเว็บไซต์ที่ไม่ถูกต้องอาจทําให้สัญญาณ Topics มีประโยชน์น้อยลงเล็กน้อยในฐานะสัญญาณโดยรวม แต่เว็บไซต์ที่การจัดประเภทไม่ถูกต้องจะไม่ได้รับผลกระทบมากหรือน้อยไปกว่าเว็บไซต์อื่นๆ เนื่องจากข้อมูลตามบริบทของเว็บไซต์จะพร้อมใช้งานสำหรับการประมูลในเว็บไซต์เสมอ ซึ่งจะให้ข้อมูลที่เปรียบเทียบได้กับหัวข้อที่ถูกต้อง แม้ว่าจะมีการจัดประเภทไม่ถูกต้องก็ตาม เรายินดีรับฟังความคิดเห็นเกี่ยวกับเรื่องนี้ที่นี่"
Google Ad Manager	Google Ad Manager ฝังอยู่ในเว็บไซต์ส่วนใหญ่อยู่แล้วและจะมีข้อมูลเกี่ยวกับหัวข้อของผู้ใช้ที่กว้างกว่าคู่แข่งที่แสดงในเว็บไซต์น้อยกว่า	ข้อกําหนดในการสังเกตมีไว้เพื่อให้มั่นใจว่า Topics API จะไม่ทําให้มีการแชร์ข้อมูลผู้ใช้กับเอนทิตีมากกว่าเทคโนโลยีที่ API จะมาแทนที่ (รวมถึง 3PC) โซลูชันอื่นๆ ในอุตสาหกรรม เช่น Prebid ทำงานร่วมกับเว็บไซต์หลายหมื่นแห่งและช่วยให้ผู้เข้าร่วมในตลาดเรียกใช้ Topics API ผ่านเทคโนโลยีของตนได้ นอกจากนี้ โปรดทราบว่าการจำกัดหัวข้อยอดนิยมสูงสุดไม่เกิน 5 หัวข้อต่อสัปดาห์อาจมีผลที่เท่าเทียมกัน เนื่องจากผู้เข้าร่วมในตลาดที่ปรากฏในเว็บไซต์หลายแห่งซึ่งอาจเรียนรู้หัวข้อได้มากกว่า 5 หัวข้อโดยใช้ 3PC จะถูกจำกัดไว้ที่ 5 หัวข้อ
(รายงานในไตรมาสก่อนหน้าด้วย) ประโยชน์สําหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ	ข้อกังวลเกี่ยวกับมูลค่าที่สร้างขึ้นและการกระจายมูลค่านั้นสําหรับเว็บไซต์ โดยขึ้นอยู่กับระดับการเข้าชมหรือความเชี่ยวชาญของเนื้อหา	เราตระหนักดีว่าเว็บไซต์เฉพาะทางมีแนวโน้มที่จะให้หัวข้อที่ละเอียดกว่าโดเมนความสนใจทั่วไป อย่างไรก็ตาม เว็บไซต์เฉพาะทางบางแห่งอาจไม่ได้นำเสนอหัวข้อที่มีคุณค่าเชิงพาณิชย์ นอกจากนี้ ข้อมูลนี้ยังแสดงถึงสถานะปัจจุบันและไม่ได้เกี่ยวข้องกับการหยุดรองรับ 3PC ใน Chrome แต่อย่างใด นอกจากนี้ ในสภาพแวดล้อมปัจจุบัน เว็บไซต์บางแห่งให้มูลค่ามากกว่าเว็บไซต์อื่นๆ ในระบบความเกี่ยวข้องของโฆษณาที่อิงตาม 3PC นอกจากนี้ หัวข้อในเว็บไซต์เฉพาะทางยังเป็นประโยชน์ต่อกันและกัน เนื่องจากผู้ลงโฆษณาที่หลากหลายสามารถใช้งานแคมเปญในหัวข้อที่หลากหลาย และตรรกะการเสนอราคาสามารถสังเกตมูลค่าในหัวข้อต่างๆ ได้มากมาย
ชื่อโฮสต์กับ URL แบบสมบูรณ์	การจัดประเภทตามชื่อโฮสต์ของเว็บไซต์มีประสิทธิภาพเพียงพอไหม และวิธีนี้ช่วยลดความเสี่ยงด้านความเป็นส่วนตัวเมื่อเทียบกับ URL แบบสมบูรณ์ไหม	เราได้พิจารณาใช้ URL ของข้อมูลหรือชื่อหน้าเว็บเพิ่มเติมจากชื่อโฮสต์ และพิจารณาแล้วว่าประโยชน์ที่อาจเกิดขึ้นมีน้อยกว่าความเสี่ยงด้านความเป็นส่วนตัวและความปลอดภัยของผู้ใช้ ตัวอย่างความเสี่ยงด้านความเป็นส่วนตัวของผู้ใช้ ได้แก่ การแยกประเภทข้อมูลที่ละเอียดอ่อนซึ่งรวมอยู่ใน URL หรือชื่อหน้าเว็บเป็นหัวข้อของผู้ใช้
หัวข้อเป็นสัญญาณ	ขอคําแนะนําเกี่ยวกับวิธีรวม Topics กับสัญญาณอื่นๆ และสัญญาณอื่นๆ ที่อาจมีประโยชน์	โซลูชันเทคโนโลยีโฆษณาจะปลดล็อกผลลัพธ์ที่ดีที่สุดได้ด้วยการรวมเครื่องมือที่มีทั้งหมดเข้าด้วยกัน เช่น แมชชีนเลิร์นนิงและสัญญาณที่ไม่ละเมิดความเป็นส่วนตัวจาก Privacy Preserving API รวมถึงข้อมูลตามบริบท ข้อมูลครีเอทีฟโฆษณา และข้อมูลจากบุคคลที่หนึ่ง ดูคำแนะนำเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ที่นี่

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
ปริมาณการเข้าชมทดสอบ	ผู้ทดสอบรายงานว่าการเสนอราคาตอบสำหรับการประมูล PA API มีปริมาณต่ำ	1. ความหนาแน่นของราคาเสนอสัมพันธ์กับการมีส่วนร่วมของระบบนิเวศใน PA API ซึ่งเราคาดว่าจะเพิ่มขึ้นอย่างต่อเนื่องตลอดปี 2024 และหลังจากนั้น ท้ายที่สุดแล้ว ผู้ลงโฆษณา เอเจนซี และผู้ให้บริการเทคโนโลยีเป็นผู้ตัดสินใจว่าจะจัดสรรงบประมาณแคมเปญอย่างไร เราคาดว่าผู้เข้าร่วมในระบบนิเวศบางรายอาจเลื่อนการลงทุนในโซลูชัน "แบบไม่มีคุกกี้" ต่างๆ ซึ่งรวมถึง PA API จนกว่าจะผ่านช่วง 3PCD ในเวลานั้น เราคาดว่าผู้ลงโฆษณาอาจเพิ่มการจัดสรรงบประมาณแคมเปญให้กับโซลูชันดังกล่าว 2. จำนวนคำขอราคาเสนอในการประมูล PA API อาจได้รับผลกระทบจาก (1) ตรงที่ผู้เผยแพร่โฆษณาและผู้ให้บริการเทคโนโลยีโฆษณาอาจตัดสินใจที่จะไม่เริ่มการประมูล PA API หากเห็นว่าดีมานด์ต่ำ ผู้เผยแพร่โฆษณาเป็นผู้กำหนดลำดับความสำคัญของการอัปเดตหน้าเว็บและการเข้าร่วม เราคาดว่าผู้เผยแพร่โฆษณาอาจใช้เวลาในการทดสอบและเพิ่มการเข้าชมทีละน้อยด้วยเหตุผลเหล่านี้ รายงานนี้ยังมีคําตอบจาก Google Ad Manager เกี่ยวกับการควบคุมของผู้เผยแพร่โฆษณาสําหรับการเข้าร่วม PA API ด้วย
(มีการรายงานในไตรมาสก่อนหน้าด้วย) การประพฤติมิชอบ / การละเมิด	ระบบนิเวศจะลดความเสี่ยงและหยุดผู้ไม่ประสงค์ดีหรือผู้ซื้อจากการวางตัวเป็นกลุ่มเป้าหมายที่ต้องการได้อย่างไร	กลไกการรายงานของโฆษณา PA API จะเก็บข้อมูลที่ใช้แยกความแตกต่างระหว่างการเข้าชมจากผู้ใช้กับการเข้าชมจากบ็อตไว้ในปัจจุบัน นอกจากนี้ คุณยังใช้เทคนิคปัจจุบันในการรวมหรือยกเว้นโดเมนตามโดเมนใน PA API ได้ ซึ่งอธิบายไว้อย่างละเอียดในคําตอบของเราต่อรายงานของ IAB Tech Lab เกี่ยวกับ Privacy Sandbox
ข้อจํากัดแหล่งที่มาเดียวกันใน URL ของเจ้าของ IG และตรรกะการเสนอราคา	เมื่อใช้ข้อกำหนดต้นทางเดียวกัน ระบบจะบังคับให้ปลายทางสำหรับเจ้าของ IG ต้องผ่านตัวจัดสรรภาระงานเดียวกัน ซึ่งอาจทำให้ระบบปฏิเสธการเปลี่ยนเส้นทาง	ข้อกำหนดต้นทางเดียวกันสำหรับการโหลดสคริปต์เป็นการป้องกันความปลอดภัยที่สำคัญ โปรดดูรายละเอียดบางอย่างเกี่ยวกับโซลูชันที่เสนอซึ่งช่วยรักษาสมดุลระหว่างความคิดเห็นเกี่ยวกับระบบนิเวศและการพิจารณาอื่นๆ ที่นี่
การประมูลส่วนตัวแบบหลายช่อง	มีการขยายขอบเขตให้อนุญาตการประมูลส่วนตัวแบบหลายช่องภายในขอบเขตความเป็นส่วนตัวได้โดยใช้สัญญาณรบกวนและการผสานรวมที่แน่นหนายิ่งขึ้นกับแนวทางปฏิบัติปัจจุบันของโฆษณา	เรากำลังพิจารณาความคิดเห็นนี้และประเมินคำขอการประมูลหลายแท็กเทียบกับความซับซ้อนที่เพิ่มขึ้นและความเสี่ยงด้านความเป็นส่วนตัวที่เกี่ยวข้องกับฟีเจอร์นี้ เราได้พูดคุยเกี่ยวกับปัญหานี้เพิ่มเติมในการโทรของกลุ่มชุมชน Web Incubator (WICG) ของ PA API ที่นี่
ผู้ขายระดับบนสุด	โครงสร้างปัจจุบันของ PA API ช่วยให้ผู้ขายระดับบนสุดมีข้อมูลและทำความเข้าใจเกี่ยวกับมูลค่าสัมพัทธ์ของการแสดงผลได้มากกว่าผู้เผยแพร่โฆษณาหรือผู้ขายคอมโพเนนต์	ในการประมูลแบบผู้ขายหลายราย ผู้ขายแต่ละรายจะมีราคาเสนอที่ดีที่สุด นอกจากนี้ เรายังได้ทราบจากระบบนิเวศว่าผู้เผยแพร่โฆษณาอาจต้องพิจารณาดีมานด์ที่ขายโดยตรงควบคู่ไปกับราคาเสนอที่ดีที่สุดของผู้ขายแต่ละรายที่ทำงานด้วย การพิจารณาโอกาสในการสร้างรายได้ที่เป็นไปได้ทั้งหมดเหล่านี้เป็นสิ่งจําเป็นต่อการเลือกโฆษณาที่จะแสดง สถานการณ์นี้ซึ่งผู้ดําเนินการบางรายจําเป็นต้องเห็นตัวเลือกทั้งหมดเพื่อเลือกโฆษณาที่จะแสดงนั้นเกิดขึ้นก่อน PA API PA API รองรับการประมูลของผู้ขายหลายรายและความต้องการของผู้เผยแพร่โฆษณาที่จะพิจารณาราคาเสนอที่ดีที่สุดของผู้ขายแต่ละรายควบคู่ไปกับแคมเปญโฆษณาที่ขายโดยตรง (หากมี) ซึ่งหมายความว่าจะต้องมีกลไกในการเลือกจากโอกาสการสร้างรายได้เหล่านั้นเช่นเดียวกับในปัจจุบัน เราเชื่อว่าเบราว์เซอร์ไม่ควรมีบทบาทในการเลือกโฆษณาที่จะแสดง ดังนั้น แนวคิดของผู้ขายระดับบนสุดจึงจําเป็นต่อการเลือกโฆษณาที่มีประสิทธิภาพสูงสุดจากตัวเลือกที่มีอยู่มากมาย ตรรกะของผู้ขายระดับบนสุดต้องพิจารณาราคาเสนอที่ดีที่สุดจากผู้ขายแต่ละรายที่ผู้เผยแพร่โฆษณาเลือกที่จะร่วมงานด้วย และตรรกะของผู้ขายรายนั้นอาจเลือกให้ข้อมูลเกี่ยวกับแคมเปญที่ผู้เผยแพร่โฆษณาขายโดยตรงหากมีข้อมูลดังกล่าว ข้อมูลทั้งหมดนี้อาจนำมาพิจารณาในตรรกะการเลือกโฆษณาระดับบนสุด ซึ่งหมายความว่าตรรกะระดับบนสุดจะเห็นราคาเสนอที่ดีที่สุดจากการประมูล PA API และตัวเลือกโฆษณาที่ขายโดยตรงจากผู้เผยแพร่โฆษณา (หากมี) เพื่อพิจารณาผู้ชนะ Google Ad Manager แสดงรายละเอียดการใช้งาน PA API ในฐานะผู้ขายระดับบนสุดในรายงานนี้ภายใต้ธีม "การเข้าถึงข้อมูล"
การแยกโฆษณาของคู่แข่ง	คำขอแยกโฆษณาคู่แข่ง เช่น ป้องกันไม่ให้โฆษณาจากแบรนด์คู่แข่งปรากฏอยู่ข้างกัน	เราไม่ทราบวิธีแยกการแข่งขันในระบบนิเวศการโฆษณาดิจิทัลแบบเป็นโปรแกรมที่มีการเสนอราคาจากผู้ขายหลายรายในปัจจุบัน อย่างไรก็ตาม PA API ช่วยให้ผู้ขายสามารถดึงข้อมูลสัญญาณแบบเรียลไทม์เพิ่มเติมโดยอิงตามการรวมกันของ renderURL และชื่อโฮสต์ (แสดงโดเมนของผู้เผยแพร่โฆษณา) ซึ่งสามารถใช้ในระหว่าง scoreAd() เมื่อให้คะแนนครีเอทีฟโฆษณา ผู้ขายอาจใช้ฟีเจอร์นี้เพื่อป้องกันไม่ให้โฆษณาจากแบรนด์คู่แข่งแสดงอยู่ข้างๆ กัน ในกรณีที่ผู้เผยแพร่โฆษณาต้องการบังคับใช้กฎนี้
ข้อมูลจํากัด	PA API จะลดข้อมูลที่เผยแพร่แก่ผู้เผยแพร่โฆษณา เช่น มูลค่าโฆษณา ชื่อผู้ซื้อคอมโพเนนต์ ชื่อผู้ลงโฆษณา URL ของหน้า Landing Page ขนาดครีเอทีฟโฆษณา เวลาในการตอบสนอง และอัตราราคาเสนอ รวมถึงราคาเสนอที่แพ้	เราได้เสนอโซลูชันที่เป็นไปได้บางส่วนไว้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การรายงานระดับเหตุการณ์	ผู้เผยแพร่โฆษณาไม่สามารถรับข้อมูลที่เพียงพอเกี่ยวกับโฆษณาที่แสดงหลังจากการเลิกใช้งาน PA API การรายงานระดับเหตุการณ์	เราทราบดีถึงกรณีการใช้งานการรายงานต่างๆ ที่เราจะต้องให้การสนับสนุนต่อไปเมื่อการรายงานระดับเหตุการณ์หยุดให้บริการ ด้วยเหตุนี้ เราจึงกําหนดวันที่หยุดให้บริการการรายงานระดับเหตุการณ์ไว้ไม่เร็วกว่าปี 2026 ในระหว่างนี้ เราขอเชิญชวนให้มีส่วนร่วมอย่างสม่ำเสมอขณะที่เรามีส่วนร่วมกับระบบนิเวศเพื่อพัฒนาเส้นทางที่ยั่งยืนต่อไป ซึ่งอาจรวมถึงแนวคิดใหม่ๆ ในการรับข้อมูลในลักษณะที่เคารพความเป็นส่วนตัว
SSP หลายรายการ	มูลค่าที่เพิ่มขึ้นจากการมี SSP หลายรายจะต่ำเกินไปสำหรับผู้เผยแพร่โฆษณา	เราเชื่อว่าข้อมูลนี้ไม่ถูกต้องและยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศเพื่อให้เข้าใจเหตุผลในการยืนยันนี้
กิจกรรมการดูแลจัดการ	PA API ไม่สามารถดำเนินการจัดการเนื้อหาได้	เราได้รับความคิดเห็นเกี่ยวกับความสามารถของผู้ขายในการใช้ PA API เพื่อแสดงข้อมูลกลุ่มเป้าหมายต่อผู้ซื้อทั่วทั้งเว็บ (หรือที่เรียกว่าชิ้นงานกลุ่มเป้าหมาย) เราเชื่อว่าการดำเนินการนี้ทำได้แล้วในปัจจุบันโดยใช้ฟังก์ชันการมอบสิทธิ์ของ PA ร่วมกับข้อตกลงทางธุรกิจ ในขณะเดียวกัน เรากำลังพิจารณาอย่างจริงจังว่าควรรองรับกรณีการใช้งานประเภทเหล่านี้อย่างไรและควรรองรับหรือไม่
การเลือกไม่ใช้ของผู้ซื้อ	การเลือกไม่ใช้เริ่มต้นของผู้ซื้อมีแนวโน้มที่จะทําให้ผลลัพธ์ของการประมูลคอมโพเนนต์ลดลง	ไม่ว่าผู้ขายจะกําหนดการประมูล PA ของผู้ขายรายเดียวหรือหลายราย ผู้ขายต้องระบุผู้ซื้ออย่างชัดเจนในช่อง interestGroupBuyers ของ AuctionConfig การดำเนินการนี้อิงตามความคิดเห็นเกี่ยวกับระบบนิเวศที่ผู้ขายมีข้อตกลงทางสัญญากับผู้ซื้อบางรายเท่านั้น จึงจำเป็นต้องมีการควบคุมอย่างชัดเจนว่าผู้ซื้อรายใดที่จะรวมไว้ในการประมูล เรายินดีให้พูดคุยกันต่อใน GitHub
ขนาดโฆษณา	กรองข้อมูลล่วงหน้าตาม adsize และ adSlotSize ไม่ได้	เรากำลังดำเนินการเพิ่มความสามารถนี้และดูรายละเอียดเพิ่มเติมได้ที่นี่
การรองรับการกำหนดเป้าหมายเชิงลบใน IG	API ที่รองรับการกำหนดเป้าหมาย IG เชิงลบ: แสดงโฆษณาเฉพาะในกรณีที่ผู้ใช้ไม่ได้อยู่ใน IG	ปัญหานี้ใน GitHub เสนอวิธีอื่นในการใช้การกำหนดเป้าหมายเชิงลบ ซึ่งเบราว์เซอร์จะบอกเซิร์ฟเวอร์โฆษณาโดยตรงว่ากฎการกำหนดเป้าหมายเชิงลบใดควรมีผลกับคำขอโฆษณาหนึ่งๆ แม้ว่าวิธีนี้ดูเหมือนจะเป็นแนวทางที่น่าสนใจ แต่ไอเดียนี้ทุกเวอร์ชันที่เราได้ตรวจสอบกลับทำให้เซิร์ฟเวอร์ระบุผู้ใช้ได้อย่างไม่ซ้ำกัน
กฎหมายบริการดิจิทัล	ผู้เผยแพร่โฆษณาจะใช้เฟรมที่มีการกำหนดขอบเขตแต่ยังป้องกันไม่ให้ระบบแสดงผลคำตอบที่มีข้อมูลที่อยู่ภายใต้กฎหมายบริการดิจิทัลได้อย่างไร	เช่นเดียวกับเทคโนโลยีใหม่อื่นๆ บริษัทแต่ละแห่งมีหน้าที่ตรวจสอบว่าการใช้ Privacy Sandbox เป็นไปตามกฎหมาย Google ไม่สามารถให้คําแนะนําทางกฎหมายแก่ผู้อื่น เรามีเอกสารประกอบทางเทคนิคที่ครอบคลุมสำหรับ API แต่ละรายการ ซึ่งควรเป็นพื้นฐานในการประเมินทางกฎหมายที่จำเป็น ไม่จำเป็นต้องใช้เฟรมที่มีการกำหนดขอบเขตใน PA API ก่อนปี 2026 เพื่อให้ผู้มีส่วนเกี่ยวข้องมีเวลาเพิ่มเติมในการตรวจสอบว่าการใช้เทคโนโลยีนี้เป็นไปตามนิติบัญญัติที่เกี่ยวข้องทั้งหมด
เอกสารประกอบ	updateAdInterestGroups() เป็นการดำเนินการชั่วคราวใช่ไหม	เรายังไม่ได้ประกาศแผนที่จะเลิกใช้งาน updateAdInterestGroup ในอนาคต เราอาจใช้การคุ้มครองความเป็นส่วนตัวที่คล้ายกับที่เราได้พูดถึงต่อสาธารณะสำหรับกลไกการอัปเดตอื่นๆ ของ IG เช่น การใช้ที่อยู่ IP เป็นพร็อกซีและเพิ่มการหน่วงเวลาก่อนที่จะมีการอัปเดต
การรองรับการเป็นเจ้าของข้อมูลเมตาและตรรกะฝั่งซื้อสำหรับที่ไม่ใช่ DSP	ขอวิธีทําหน้าที่เป็นพร็อกซีสําหรับ DSP	เราทราบความคิดเห็นนี้จากกลุ่มที่ไม่ใช่ DSP และกำลังพิจารณาคำขอนี้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การรายงาน	คําขอเพิ่มฟีเจอร์ตัวแฮนเดิลที่กําหนดเองสําหรับกลุ่ม / ค่าสัญญาณในการรายงานการรวมข้อมูลส่วนตัว	เราทราบมาและคำขอฟีเจอร์นี้อยู่ในคิวรอตรวจสอบเพิ่มเติม เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศที่นี่
เอกสารประกอบ	มีลิงก์ที่ฉันดูส่วนหัวการตอบกลับทั้งหมดที่ผู้ลงโฆษณาและโดเมนเจ้าของ (ที่มอบสิทธิ์) ต้องตั้งค่าไหม	เรากำลังวางแผนที่จะอัปเดตเอกสารประกอบเพื่อชี้แจงเรื่องนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การเสนอราคาหลายหอ	ขอคำอธิบายเวิร์กโฟลว์ (การฝึกและการทำนาย) ผ่านสถาปัตยกรรม / ผังบล็อกเกี่ยวกับวิธีมองแนวทางแบบหลายหอคอยในบริบท PA API	ขอบคุณสำหรับความคิดเห็น เรามีงานนำเสนอบางส่วนเกี่ยวกับเรื่องนี้ซึ่งเราคาดว่าจะสร้างเอกสารประกอบเพิ่มเติม
การกําหนดเป้าหมายเชิงลบ	ความสามารถของ Privacy Sandbox ในการปกป้องกลุ่มเป้าหมายที่มีความละเอียดอ่อนและเด็กๆ จากโฆษณาที่ไม่เหมาะสม เช่น การพนัน	PA API ไม่พิจารณาเนื้อหาของโฆษณาที่แสดง การดำเนินการนี้อยู่ภายใต้การควบคุมของนักพัฒนาเทคโนโลยีโฆษณาที่ใช้ PA โดยทั่วไปแล้ว ผู้เผยแพร่โฆษณาและผู้ให้บริการเทคโนโลยีโฆษณาสามารถบล็อกครีเอทีฟโฆษณาในการประมูลของกลุ่มเป้าหมายที่ได้รับการคุ้มครองได้โดยใช้ข้อมูลตามบริบทจากหน้าเว็บ รวมถึงชุดกฎของผู้เผยแพร่โฆษณา ซึ่งสอดคล้องกับความเข้าใจของเราเกี่ยวกับแนวทางของระบบนิเวศในการรับมือกับความท้าทายเหล่านี้ในปัจจุบัน สําหรับผู้ซื้อ ฟังก์ชันการกําหนดเป้าหมาย IG เชิงลบอาจมีประโยชน์สําหรับ Use Case การปฏิบัติตามข้อกําหนดบางรายการด้วย
การออกแบบ API	Google กำลังต่อต้านและต้องการให้เทคโนโลยีโฆษณาใช้ฟังก์ชันการเสนอราคาแบบ Universal ซึ่งจะเพิ่มเวลาในการตอบสนอง แทนที่จะใช้ biddingLogicURL ที่แตกต่างกันใน IG ต่างๆ ซึ่งได้รับอนุญาต	ในระหว่างการพูดคุยเรื่องเวลาในการตอบสนองของการประมูล เราได้เน้นย้ำว่าการใช้สคริปต์เดียวกันซ้ำใน IG ทั้งหมดของผู้ซื้อจะทำให้การเสนอราคาของผู้ซื้อรายนั้นทํางานได้เร็วขึ้น รายละเอียดเพิ่มเติมมีระบุไว้ที่นี่ พร้อมกับคําแนะนําอื่นๆ ในการปรับปรุงเวลาในการตอบสนองของการประมูล PA API
การตลาดตามบัญชี	PA API ไม่ใช่ API ที่สมบูรณ์แบบสําหรับกรณีการใช้งานการตลาดตามบัญชี	เรายินดีรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับ Use Case ที่เฉพาะเจาะจงซึ่งผู้เข้าร่วมเชื่อว่าไม่สามารถทำได้ และขอแนะนำให้ผู้เข้าร่วมในระบบนิเวศพูดคุยเรื่องนี้ต่อผ่านที่เก็บ GitHub สาธารณะหรือการโทรคุยกันรายสัปดาห์
การทดสอบ A/B	เมื่อกําหนดค่า PA API ใน GAM สําหรับผู้เผยแพร่โฆษณา ขณะนี้ต้องเปิดใช้ PA API สําหรับพื้นที่โฆษณาทั้งหมดหรือไม่เปิดใช้เลย ซึ่งจํากัดความสามารถของผู้เผยแพร่โฆษณาในการทําการทดสอบ A/B ที่ได้ผล	คําตอบจาก Google Ad Manager: การควบคุม PA API ภายใน Google Ad Manager (GAM) จะส่งผลต่อความสามารถของ GAM ในการใช้ API ดังกล่าว หาก API พร้อมใช้งาน ดังนั้น ผู้เผยแพร่โฆษณาจึงสามารถทำการทดสอบ A/B โดยใช้ฟังก์ชันการทำงานของนโยบายสิทธิ์ของ Chrome เพื่อปิดใช้ API ในการเข้าชมกลุ่มย่อยเพื่อใช้เป็นกลุ่มควบคุมสำหรับการทดสอบ A/B
แมชชีนเลิร์นนิง	ผู้เผยแพร่โฆษณาต้องการการควบคุมที่ดียิ่งขึ้นเกี่ยวกับการใช้แมชชีนเลิร์นนิงที่ GAM เสนอ	คําตอบจาก Google Ad Manager: ในเดือนมกราคม 2024 เราได้เปิดตัวการควบคุมที่ช่วยให้ผู้เผยแพร่โฆษณาปิดใช้ตัวควบคุมปริมาณการใช้แมชชีนเลิร์นนิงและเปิดใช้การประมูล PA API กับผู้ขายที่ไม่ใช่ Google ในการเข้าชมทั้งหมด ดูรายละเอียดเพิ่มเติมเกี่ยวกับการควบคุมนี้ได้ในศูนย์ช่วยเหลือ
(รายงานในไตรมาสก่อนหน้าด้วย) การประมูลระดับบนสุด	ความสามารถในการใช้เซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาของ Google โดยไม่ต้องให้สิทธิ์ GAM ควบคุมการประมูล PA API ระดับบนสุดด้วย	คําตอบจาก Google Ad Manager: ตามเหตุผลที่อธิบายไว้ในรายงานไตรมาสที่ 3 ปี 2023 ของ Google แผนการผสานรวม PA API ของ GAM ไม่ได้รองรับผู้เผยแพร่โฆษณาที่ใช้ GAM เป็นเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาโดยไม่มีการควบคุมการประมูลระดับบนสุด
การเข้าถึงข้อมูล	GAM มีสิทธิ์เข้าถึงข้อมูลที่มีค่าจากคู่แข่ง ซึ่งรวมถึงราคาการประมูลตามบริบท สัญญาณที่ผู้ซื้อระบุให้ SSP สําหรับการประมูล PA API และพารามิเตอร์การกําหนดค่าจาก SSP	คําตอบจาก Google Ad Manager: เรามุ่งเน้นที่ความยุติธรรมในการประมูลมาอย่างยาวนาน รวมถึงสัญญาว่าจะไม่มีการแชร์ราคาจากแหล่งโฆษณาที่ไม่รับประกันของผู้เผยแพร่โฆษณา รวมถึงราคารายการโฆษณาที่ไม่รับประกันกับผู้ซื้อรายอื่นก่อนที่จะเสนอราคาในการประมูล ซึ่งเราได้ยืนยันอีกครั้งในความมุ่งมั่นของเราต่อหน่วยงานกำกับดูแลการแข่งขันของฝรั่งเศส สําหรับการประมูล PA API เราตั้งใจที่จะรักษาสัญญาและไม่แชร์ราคาเสนอของผู้เข้าร่วมการประมูลกับผู้เข้าร่วมการประมูลรายอื่นจนกว่าการประมูลจะเสร็จสมบูรณ์ในการประมูลกับผู้ขายหลายราย เพื่อความชัดเจน เราจะไม่แชร์ราคาของการประมูลตามบริบทกับการประมูลองค์ประกอบใดๆ รวมถึงการประมูลของเราเอง ตามที่อธิบายในการอัปเดตนี้ นอกจากนี้ เราไม่ใช้ข้อมูลเกี่ยวกับการกําหนดค่าการประมูลคอมโพเนนต์ รวมถึงสัญญาณที่ผู้ซื้อให้ SSP เป็นส่วนหนึ่งของการประมูลของเราเอง เรายินดีรับการเปลี่ยนแปลง PA API ที่อนุญาตให้ผู้ขายคอมโพเนนต์ระบุการกำหนดค่าการประมูลคอมโพเนนต์ในลักษณะที่สร้างความสับสนให้กับผู้ขายระดับบนสุด
การประมูลคอมโพเนนต์	ในฐานะการประมูลระดับบนสุด GAM จะควบคุม SSP ที่จะทำการประมูลคอมโพเนนต์สําหรับโอกาสในการโฆษณาแต่ละรายการ	คําตอบจาก Google Ad Manager: ในฐานะเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา GAM มี API ขนาดเล็กสำหรับ SSP ที่ผู้เผยแพร่โฆษณาอาจทํางานด้วยเพื่อระบุการกําหนดค่าการประมูลคอมโพเนนต์ผ่าน API แท็กผู้เผยแพร่โฆษณาผ่าน Google (GPT) อ่านรายละเอียดเพิ่มเติมได้ที่นี่ หาก SSP ระบุการกําหนดค่าการประมูลคอมโพเนนต์ผ่าน API นี้ ระบบจะรวม SSP ดังกล่าวไว้ในรายการการประมูลคอมโพเนนต์สําหรับโอกาสโฆษณานั้น GAM ไม่มีข้อจํากัดใดๆ กับการประมูลคอมโพเนนต์ที่รวมอยู่ด้วย SSP ที่ต้องการเรียกใช้การประมูลคอมโพเนนต์จะทำได้หากผู้เผยแพร่โฆษณาอนุญาตให้เรียกใช้โค้ดที่จําเป็นในหน้าของผู้เผยแพร่โฆษณา
การประมูลคอมโพเนนต์	GAM อาจใช้ราคาเสนอขั้นต่ำที่เฉพาะเจาะจงและไม่เปิดเผยกับราคาเสนอที่ชนะการประมูลของคอมโพเนนต์แต่ละรายการ	คําตอบจาก Google Ad Manager: GAM มุ่งเน้นความยุติธรรมในการประมูลมาอย่างยาวนาน เราไม่รองรับราคาพื้นที่มีผลกับดีมานด์บางกลุ่มเท่านั้น เพื่อรักษาการประมูลที่ยุติธรรมและโปร่งใส ซึ่งเป็นหลักการที่สอดคล้องกันในผลิตภัณฑ์ของเราและจะยังคงเป็นเช่นนั้นสำหรับการประมูล PA API
เซิร์ฟเวอร์โฆษณาบุคคลที่สาม	เซิร์ฟเวอร์โฆษณาของบุคคลที่สามจะไม่มีสิทธิ์เข้าถึงการเข้าร่วมการประมูลระดับที่สูงขึ้นของ Google ซึ่งจํากัดความสามารถของเซิร์ฟเวอร์โฆษณาในการรับดีมานด์จาก SSP ของ Google ในบริบทของ PA API	คําตอบจาก Google Ad Manager: ปัจจุบัน GAM รองรับการทดสอบ PA API กับผู้ขายหลายรายใน GAM ผ่าน API ที่อธิบายไว้ที่นี่ ปัจจุบันระบบยังไม่รองรับการเข้าร่วมของ GAM ในการประมูลคอมโพเนนต์ในการประมูลระดับบนสุดอื่นๆ
(รายงานในไตรมาสก่อนหน้าด้วย) ประสิทธิภาพของการประมูล PA API	รายงานจากผู้ทดสอบระบุว่าการประมูล PA API มีเวลาในการตอบสนองสูง	เราทราบดีถึงความกังวลเกี่ยวกับเวลาในการตอบสนอง และนี่เป็นหนึ่งในเหตุผลที่เราได้พัฒนาฟีเจอร์หลายอย่างใน PA API ซึ่งจะช่วยให้ SSP กำหนดขีดจำกัดเวลาในการตอบสนองของ DSP รวมถึงทำการปรับปรุงเพื่อลดเวลาในการตอบสนองได้ เมื่อเร็วๆ นี้ เราได้อัปเดตคู่มือแนวทางปฏิบัติแนะนำเกี่ยวกับเวลาในการตอบสนองซึ่งมีข้อมูลเพิ่มเติมเกี่ยวกับวิธีใช้ประโยชน์จากฟีเจอร์เหล่านี้ นอกจากนี้ เรายังพัฒนาการปรับปรุงเวลาในการตอบสนองใหม่ๆ อย่างต่อเนื่อง ซึ่งบางส่วนดูได้ที่นี่
(รายงานในไตรมาสก่อนหน้าด้วย) การแสดงผลวิดีโอ	รองรับการแสดงผลวิดีโอโดยใช้ PA API และเฟรมที่มีรั้วล้อม	เมื่อเดือนมกราคม เราได้เผยแพร่การสาธิตวิธีที่วิดีโอในสตรีมอาจทำงานในการประมูล PA พร้อมรายละเอียดเพิ่มเติมเกี่ยวกับแนวทางอื่นๆ นอกจากนี้ เรายังเห็นว่าผู้เข้าร่วมในระบบนิเวศเริ่มเสนอวิธีการทำงานของการแสดงผลวิดีโอสำหรับพาร์ทเนอร์ที่ผสานรวมกับพวกเขา เช่น ข้อเสนอของ GAM เกี่ยวกับการสร้าง renderURL ที่ใช้งานร่วมกับวิดีโอได้หรือกระบวนการ E2E แบบสมบูรณ์ นอกจากนี้ เรายังรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับการเปลี่ยนแปลงที่เราทำได้เพื่อเพิ่มการใช้งาน และการเปลี่ยนแปลงดังกล่าวมีรายละเอียดอยู่ใน GitHub เรายังคงมีส่วนร่วมกับระบบนิเวศอย่างสม่ำเสมอเพื่อระบุอุปสรรคอื่นๆ ในการนำไปใช้งานที่เราอาจพบและแก้ไขอย่างทันท่วงที
(รายงานในไตรมาสก่อนหน้าด้วย) นโยบายการจัดการข้อมูล	นโยบายการจัดการข้อมูลสําหรับ IG / PA API คืออะไร	ในการออกแบบ PA API ข้อมูลทั้งหมดที่จัดเก็บไว้ใน IG หรือเกี่ยวกับสิ่งที่ผู้ใช้อยู่ใน IG (1) จะยังคงอยู่ในอุปกรณ์ หรือ (2) ได้รับการประมวลผลในบริการเสนอราคาและประมูล (B&A) ที่ทำงานภายในสภาพแวดล้อมการทํางานที่เชื่อถือได้ (TEE) ไม่ว่าในกรณีใด บุคคลอื่นจะอ่านข้อมูลดังกล่าวไม่ได้ หรือนำไปใช้ในลักษณะอื่นนอกเหนือจากการสร้างราคาเสนอในการประมูล การปรับปรุงความเป็นส่วนตัวบางอย่างที่ Chrome กำลังพัฒนาเกี่ยวข้องกับการโต้ตอบกับเซิร์ฟเวอร์แบบ K-anonymity ที่ Google เป็นผู้ดำเนินการ การโต้ตอบดังกล่าวได้รับการออกแบบอย่างรอบคอบเพื่อหลีกเลี่ยงการแชร์ข้อมูลเกี่ยวกับผู้ใช้ และเพื่อทํางานใน TEE เพื่อให้ข้อมูลในระบบนิเวศโฆษณามีความเท่าเทียมกัน Google มุ่งมั่นที่จะออกแบบและนําข้อเสนอ Privacy Sandbox ไปใช้กับ CMA ในลักษณะที่ไม่บิดเบือนการแข่งขันโดยการให้ความสําคัญกับธุรกิจของ Google เอง และพิจารณาผลกระทบต่อการแข่งขันในการโฆษณาดิจิทัล รวมถึงผู้เผยแพร่โฆษณาและผู้ลงโฆษณา เรายังคงทำงานร่วมกับ CMA อย่างใกล้ชิดเพื่อให้มั่นใจว่าการดำเนินการของเราเป็นไปตามภาระหน้าที่เหล่านี้
(รายงานในไตรมาสก่อนหน้าด้วย) อายุการใช้งานใน IG	คำขอขยายอายุของ IG จาก 30 เป็น 90 วัน	การเปลี่ยนแปลงดังกล่าวต้องได้รับการประเมินอย่างรอบคอบ โดยพิจารณาประโยชน์ต่ออุตสาหกรรมเทียบกับผลกระทบต่อผู้ใช้ Chrome และผู้มีส่วนเกี่ยวข้องอื่นๆ เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
(รายงานในไตรมาสก่อนหน้าด้วย) modelingSignals	ขอช่องใหม่นอกเหนือจาก modelingSignals ที่สามารถเข้ารหัสข้อมูลการแสดงผลและการคลิกได้เท่านั้น	เราได้ตอบกลับความคิดเห็นนี้ด้วยข้อเสนอโต้แย้งที่นี่ เรามีส่วนร่วมกับอุตสาหกรรมอย่างสม่ำเสมอเพื่อทําความเข้าใจมุมมองของอุตสาหกรรมต่อข้อเสนอของเรา และกำลังชั่งน้ำหนักประโยชน์ต่ออุตสาหกรรมเทียบกับผลกระทบต่อผู้ใช้ Chrome และผู้มีส่วนเกี่ยวข้องอื่นๆ
บิตเพิ่มเติมใน reportWin()	ระบุบิตเพิ่มเติมใน reportWin() จากขีดจํากัดปัจจุบันที่ 12 ก่อน 3PCD	เรากำลังหาแนวทางเพื่อรองรับกรณีการใช้งานนี้ การดำเนินการนี้ต้องใช้เวลาสักระยะ เนื่องจากเรากำลังมองหาแนวทางที่จะช่วยให้มั่นใจได้ว่าเรามีแผนความเป็นส่วนตัวในระยะยาว
การออกแบบการประมูล	คำขอการประมูลครั้งเดียวที่แสดงผล URL ที่มีคะแนนที่เกี่ยวข้อง	การแชร์ renderURL หลายรายการและคะแนนที่เกี่ยวข้องจากการประมูล PA รายการเดียวเป็นสิ่งที่เราพิจารณาแล้ว แต่ไม่ได้นำมาใช้งานเนื่องจากข้อกังวลด้านความเป็นส่วนตัว เราเข้าใจดีว่าคุณต้องการหลีกเลี่ยงการแสดงโฆษณาเดิมต่อผู้ใช้หลายครั้งในหน้าเดียว และยินดีให้พูดคุยกันต่อใน GitHub
reportWin	บันทึกฟิลด์ที่กำหนดเองในฟังก์ชัน reportWin()	ซึ่งเรากำลังดำเนินการอยู่ตลอดระยะเวลาการทดสอบ เมื่อ Chrome หยุดรองรับ 3PC แล้ว ระบบจะย้ายข้อมูล API เวอร์ชัน forDebuggingOnly เพื่อเปิดใช้การแก้ไขข้อบกพร่องแบบลดขนาด ซึ่งระบุไว้ที่นี่
ผู้ขายคอมโพเนนต์	มีกลไกอิสระในการนับการแสดงผลและเหตุการณ์อื่นๆ ของตนเอง และไม่จำเป็นต้องอาศัยรายงานของเทคโนโลยีโฆษณาเพียงอย่างเดียว	คำขอฟีเจอร์นี้อยู่ในคิวรอตรวจสอบเพิ่มเติม เราคาดว่าจะยังไม่แก้ไขปัญหานี้ในช่วงระยะเวลาการทดสอบที่อำนวยความสะดวกโดย Chrome
การเรียกเก็บเงินแบบต้นทุนต่อคลิก	ใช้การเรียกเก็บเงินแบบต้นทุนต่อคลิกใน PA API	เรากำลังพิจารณาคำขอนี้ที่นี่ และขณะนี้เราเห็นว่านี่เป็นคำขอคำแนะนำเกี่ยวกับวิธีติดตั้งใช้งานกับแพลตฟอร์ม API ปัจจุบัน
browserSignals	เพิ่ม incomingBidInSellerCurrency ลงในข้อกําหนดของ browserSignals สำหรับการรายงานสำหรับผู้ขาย	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การรองรับการเป็นเจ้าของข้อมูลเมตาและตรรกะฝั่งซื้อสำหรับที่ไม่ใช่ DSP	การออกแบบ API ปัจจุบันอาจทําให้เกิดการเปลี่ยนแปลงที่สําคัญในแคมเปญรีมาร์เก็ตติ้งระดับผลิตภัณฑ์ ซึ่งแคมเปญอาจต้องย้ายข้อมูลไปยังแพลตฟอร์มที่ทําหน้าที่เป็นทั้ง DSP และผู้ให้บริการ DCO	เรากำลังหารือเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การรองรับการเป็นเจ้าของข้อมูลเมตาและตรรกะฝั่งซื้อสำหรับที่ไม่ใช่ DSP	แชร์ตัวอย่างที่ DSP ไม่ใช่เจ้าของ IG	เราเข้าใจว่าผู้ที่ไม่ได้เสนอราคาต้องการใช้ฟังก์ชันบางอย่างของ IG แต่ไม่ได้ต้องการใช้ฟังก์ชันอื่นๆ เรากำลังประเมินตัวเลือกต่างๆ เพื่อจัดการกับ Use Case เหล่านี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การควบคุมระยะหมดเวลา	ผู้เผยแพร่โฆษณาควรกำหนดจำนวน IG ที่เข้าร่วมได้และระยะหมดเวลาระดับบนสุด / ระยะหมดเวลาทั่วโลก	เราเข้าใจดีว่าคุณต้องการการควบคุมและการแสดงผลการหมดเวลาที่ดียิ่งขึ้นระหว่างผู้ขายระดับบนสุดกับผู้ขายคอมโพเนนต์ และกำลังพิจารณาคำขอนี้
ขนาดโฆษณาหลายขนาด	การรองรับ PA API สําหรับกรณีการใช้งานขนาดโฆษณาหลายขนาด	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
เอกสารประกอบ	มีรายการแอตทริบิวต์ IG ที่อยู่ภายใต้ k-anon ไหม	เราได้ตอบคำถามนี้ที่นี่
การแก้ไขข้อบกพร่อง	ความสามารถในการแก้ไขข้อบกพร่องของ PA API ที่ดียิ่งขึ้น	เราตระหนักถึงความสำคัญของเครื่องมือแก้ไขข้อบกพร่องที่มีประสิทธิภาพสำหรับนักพัฒนาซอฟต์แวร์ที่ทํางานกับ PA API เรามุ่งมั่นที่จะปรับปรุงประสบการณ์ของนักพัฒนาแอปโดยสำรวจวิธีผสานรวมการดึงข้อมูลไฟล์ .well-known เข้ากับเครื่องมือของนักพัฒนาแอปได้ดียิ่งขึ้น เป้าหมายของเราคือการมอบความสามารถในการมองเห็นและแก้ปัญหาที่มากขึ้นภายในสภาพแวดล้อมการพัฒนา เรากำลังหารือปัญหานี้เพิ่มเติมที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
ป้ายกำกับ	ผู้ใช้ทั้งหมดในป้ายกำกับการจัดการโหมด B เปิดใช้ Privacy Sandbox API ไหม	การกำหนดกลุ่มทดสอบของ Chrome จะกำหนดแบบสุ่มและไม่ขึ้นอยู่กับการตั้งค่า Chrome ที่ผู้ใช้กำหนด แม้ว่า API เหล่านี้อาจพร้อมใช้งานสำหรับผู้ใช้ในกลุ่มทดสอบที่เฉพาะเจาะจง (เช่น treatment_1.*) แต่คุณก็สามารถแก้ไขหรือปิดใช้ฟังก์ชันการทำงานของ API เหล่านี้ผ่านการตั้งค่า Chrome ได้ กลุ่ม control_2 ของโหมด B: การรวมอยู่ในกลุ่มนี้จะปิดใช้ API ที่เกี่ยวข้องกับการวัดผลและ Privacy Sandbox โดยปริยาย และผู้ใช้จะลบล้างการตั้งค่านี้ในการตั้งค่า Chrome ไม่ได้
การใช้ API	การเรียกใช้ reportWin() และการเรนเดอร์โฆษณาเกิดขึ้นพร้อมกันหรือทีละรายการ	ระบบจะเรียกใช้ reportWin() โดยตรงหลังจาก runAdAuction() เสร็จสมบูรณ์ ในขณะเดียวกัน กระบวนการแสดงโฆษณาอาจเริ่มต้นขึ้นเมื่อผลลัพธ์การประมูลวางอยู่ใน iframe หรือเฟรมที่มีการกำหนดขอบเขต หลังจากทั้ง reportWin() ดำเนินการเสร็จสิ้นและโฆษณาเริ่มแสดงผล ระบบจะดึงข้อมูล URL ที่ระบุไว้ใน sendReportTo()
(รายงานในไตรมาสก่อนหน้าด้วย) การสนับสนุนการทดสอบ A/B	ขอรับการสนับสนุนสําหรับการทดสอบ A/B ของ PA API	เรากำลังพูดคุยเกี่ยวกับคำขอนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การกำหนดรูปแบบการเข้าชม	ข้อเสนอจาก Google ในการจัดการการตัดสินใจที่จำเป็นผ่านเซิร์ฟเวอร์ KV นั้นไม่เป็นประโยชน์ เนื่องจากผู้ขายไม่สามารถโต้ตอบกับแบ็กเอนด์ได้ ทำให้การกำหนดปริมาณการเข้าชมเป็นเรื่องยาก	ตามที่เราได้พูดคุยกันในปัญหา GitHub การเปิดเผยว่า DSP แต่ละรายมี IG หรือไม่อาจทำให้เกิดข้อกังวลเกี่ยวกับการเก็บข้อมูลลายนิ้วมือของผู้ใช้ เราได้แนะนำทางเลือกอื่นๆ เกี่ยวกับปัญหานี้และพร้อมรับคำแนะนำเพิ่มเติม
การกำหนดรูปแบบการเข้าชม	กลไกการแคชจะเพิ่มความซับซ้อนอีกชั้นหนึ่งและทําให้ DSP ไม่ทราบรูปแบบการเข้าชมจริงที่จะเสนอราคา	กลไกการแคชเป็นเพียงคำแนะนำเท่านั้น เทคโนโลยีโฆษณาสามารถเลือกใช้คําแนะนําที่เหมาะกับกรณีการใช้งานของตนได้ และเรายินดีให้คําปรึกษาเพิ่มเติมที่นี่
ป้ายกำกับ	Chrome ควรแชร์ป้ายกำกับเป็นพารามิเตอร์ในคำขอไปยังเซิร์ฟเวอร์ที่เชื่อถือได้ของผู้ซื้อและผู้ขาย	ดูเหมือนว่าคำขอนี้สมเหตุสมผลเนื่องจากสอดคล้องกับเป้าหมายในการใช้ข้อมูล IG อย่างมีความรับผิดชอบในวงกว้าง อย่างไรก็ตาม เรากำลังพิจารณาคำขอนี้โดยขึ้นอยู่กับการตรวจสอบภายใน และจะแจ้งข้อมูลอัปเดตเกี่ยวกับเรื่องนี้ต่อสาธารณะเมื่อการพูดคุยดำเนินไป
การใช้ API	ชี้แจงคําจํากัดความที่ชัดเจนของกลุ่ม "control_1" ในเอกสาร "คําแนะนําเพิ่มเติมของ CMA สําหรับบุคคลที่สามเกี่ยวกับการทดสอบ" กล่าวโดยละเอียดคือ มีความกังวลว่าการเปลี่ยนแปลงถ้อยคำอาจถูกตีความว่าต้องมีการยกเว้น Privacy Sandbox API ทั้งหมดจาก control_1	เราได้แสดงความคิดเห็นเกี่ยวกับเรื่องนี้ใน ชุดข้อความ GitHub นี้ อย่างไรก็ตาม เราไม่สามารถให้ข้อมูลในนามของ CMA และขอแนะนำให้คุณแจ้งปัญหาเกี่ยวกับการตีความ หลักเกณฑ์การทดสอบกับ CMA โดยตรง
การใช้ API	Chrome จะอนุญาตให้เรียกใช้ joinAdInterestGroup() ในหน้าว่างขณะเปลี่ยนเส้นทางไปยังแหล่งข้อมูลอื่นหรือไม่	หากผู้ใช้เข้าชมเว็บไซต์ใด เจ้าของเว็บไซต์สามารถมอบสิทธิ์เรียกใช้ joinAdInterestGroup ให้กับบุคคลที่สามได้ การมอบสิทธิ์นี้ช่วยให้บุคคลที่สามสร้าง IG ได้โดยไม่ต้องเพิ่มการเปลี่ยนเส้นทางประเภทใดๆ ผ่านหน้าเว็บว่าง เรายินดีรับฟังความคิดเห็นเกี่ยวกับเหตุผลที่เฉพาะเจาะจงในการสร้าง IG ในช่วงกลางของการเปลี่ยนเส้นทางแทนที่จะใช้กลไกการมอบสิทธิ์ตามที่ตั้งใจไว้
การใช้ API	พาร์ทเนอร์การแลกเปลี่ยนควรเขียน IG ลงในหน้าเว็บที่ผู้เผยแพร่โฆษณาที่ตนทํางานด้วยเป็นเจ้าของ จากนั้นจึงมอบสิทธิ์ให้เสนอราคาใน IG นั้นแก่ผู้ซื้อหรือ DSP ที่ต้องการ	เราได้รับความคิดเห็นแล้วและกำลังประเมินว่าจะรองรับคำขอดังกล่าวได้หรือไม่ เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การใช้ API	ไม่มีการแจ้งเตือนการสูญเสียในการแก้ไขข้อบกพร่องหากไม่มีใครชนะการประมูล PA API	ฟังก์ชัน reportWin และ reportResult ของ Chrome ออกแบบมาเพื่อการรายงานการชนะระดับเหตุการณ์ภายในระบบการประมูลเพื่อความเป็นส่วนตัว (PA) ในกรณีที่ระบบปฏิเสธราคาเสนอทั้งหมดระหว่างการประมูล PA ระบบจะไม่เรียกใช้ฟังก์ชันเหล่านี้เนื่องจากไม่มีการกำหนดผู้ชนะ การอัปเดต Chrome ครั้งล่าสุดอาจอธิบายความคลาดเคลื่อนเมื่อ URL ที่ส่งไปยัง forDebuggingOnly.reportAdAuctionLoss() ไม่ปรากฏในแผงเครือข่ายของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ เราขอแนะนำให้ยืนยันฟังก์ชันนี้โดยใช้ Chrome รุ่น Canary หรือเวอร์ชันที่กำลังพัฒนา
การใช้ API	adCost ที่แสดงผลจาก generateBid จะเป็นค่าลบได้ไหม (ระบบปัดเศษแบบสุ่มเป็น 2 ไบต์อยู่แล้ว)	AdCost คือต้นทุนคลิกหรือต้นทุน Conversion ของผู้ลงโฆษณาที่ส่งจาก generateBid() ไปยัง reportWin() ค่านี้อาจเป็น Null หรือเลขทศนิยมก็ได้ ระบบจะไม่สนใจค่าติดลบและจะไม่ส่งค่าดังกล่าว ระบบจะปัดเศษค่าแบบสุ่มเมื่อส่งผ่าน
การปรับปรุง API	สามารถใช้เซิร์ฟเวอร์การเรียกใช้ที่เชื่อถือได้และเข้ารหัสเพื่อจัดการการกำหนดเป้าหมาย / กลุ่มประชากรตามรุ่น / การระบุแหล่งที่มาและการประมูลแทนเบราว์เซอร์ Chrome ได้ไหม	เราขอแนะนําให้ดูคอมโพเนนต์และตัวเลือกที่อิงตาม TEE ใน PA API (เช่น เซิร์ฟเวอร์ KV และบริการ B&A) รวมถึงคอมโพเนนต์ที่อิงตาม TEE ของการรายงานการระบุแหล่งที่มาและการรวมข้อมูลส่วนตัว (เช่น บริการการรวมข้อมูล) ซึ่งช่วยตอบคําถามนี้ได้
การปรับปรุง API	การตอบกลับการประมูลของ Privacy Sandbox อาจเป็นคำเสนอราคาตอบ (เช่น การเสนอราคาส่วนหัว) แทนการตอบกลับโฆษณา (เช่น แท็กโฆษณา) ได้ไหม	การเปลี่ยนแปลงประเภทนี้จะเปลี่ยนพร็อพเพอร์ตี้ความเป็นส่วนตัวของ PA API อย่างมาก เราจึงไม่ได้พิจารณาการดำเนินการดังกล่าว
การควบคุมผู้เผยแพร่โฆษณา	ผู้เผยแพร่โฆษณาบล็อกครีเอทีฟโฆษณา PA API ในหน้าเว็บของตนได้ไหม	Chrome มีข้อเสนอสําหรับการสแกนครีเอทีฟโฆษณาแบบเรียลไทม์ที่ยังไม่พร้อมให้ทดสอบ แม้ว่าฟีเจอร์นี้ยังไม่พร้อมใช้งาน แต่เราพบว่า SSP ส่วนใหญ่ได้สร้างโซลูชันเพื่อเปิดใช้ฟีเจอร์นี้
การใช้ API	perBuyerSignals มีขีดจํากัดขนาดเท่าใด	ในเวอร์ชันคลาสสิก perBuyerSignals ไม่มีขีดจํากัดขนาดภายใน Chrome ข้อจำกัดหลักคือข้อมูลยังคงเป็น JSON ที่ซีเรียลไลซ์ได้และไม่ทำให้หน่วยความจำสิ้นเปลืองมากเกินไป อย่างไรก็ตาม โปรดทราบว่า perBuyerSignals ที่มีขนาดใหญ่และซับซ้อนมากอาจส่งผลเสียต่อประสิทธิภาพ มีวิธีอื่นในการส่ง perBuyerSignals ผ่าน directFromSellerSignalsHeaderAdSlot แนวทางนี้จะส่ง perBuyerSignals ภายในส่วนหัว โดยจำกัดขนาดสูงสุดไว้ที่ 10 KB สําหรับการตอบกลับส่วนหัวทั้งหมด นอกจากนี้ เซิร์ฟเวอร์แต่ละเครื่องอาจกำหนดข้อจำกัดของตนเองเกี่ยวกับขนาดส่วนหัวสูงสุด
เอกสารประกอบ	เอกสารประกอบเกี่ยวกับการเรียกใช้ registerAdBeacon จากภายใน generateBid ต้องเปลี่ยนแปลง	เราได้อัปเดตเอกสารประกอบ นี้เมื่อวันที่ 17 กุมภาพันธ์
การใช้ API	reportEvent เลือก URL บีคอนที่เหมาะสมจากตัวเลือกที่ลงทะเบียนไว้หลายรายการได้อย่างไร	การประมูลแต่ละครั้งจะส่งผลให้มีการกำหนดค่าแยกกัน ซึ่งจะส่งผลให้มีแผนที่การรายงานแยกกัน การประมูลแต่ละรายการ (และเฟรมที่เป็นผลลัพธ์) จะแยกจากกันโดยสิ้นเชิงและไม่แชร์ข้อมูล คำอธิบาย "การรายงานโฆษณาเฟรมที่มีรั้วล้อม" มีรายละเอียดเพิ่มเติมเกี่ยวกับหัวข้อนี้
UI ของ Chrome	เพิ่มตัวกรองในแท็บ "แอปพลิเคชัน -> "กลุ่มความสนใจ" ของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของ Chrome ซึ่งช่วยให้กรองตามเจ้าของ IG ได้ (หรืออาจกรองตามชื่อ IG ได้ด้วย)	เรากำลังประเมินคำขอนี้และยินดีรับความคิดเห็นเพิ่มเติมจากระบบนิเวศ
Chrome แบบ Headless	การรองรับ PA API ใน Chrome แบบ Headless	คอมโพเนนต์บางอย่างของ PA API เชื่อมโยงกับ Chrome เช่น การเรียกใช้ k-anon ไปยังเซิร์ฟเวอร์ของ Google ซึ่งอาจไม่ทำงานใน Headless Chrome "เวอร์ชันเก่า" เราเชื่อว่าปัญหานี้อาจแก้ไขได้ด้วย Headless Chrome เวอร์ชัน "ใหม่" ที่เปิดตัวใน Chrome 112
การใช้ API	ในกรณีของการรายงานการสูญเสียด้วย reportAdAuctionLoss เราเห็น "topLevelWinningBid=0" ในหลายกรณี ผลลัพธ์นี้หมายความว่าอย่างไร	ค่า topLevelWinningBid มาจากฟังก์ชัน scoreAd() ภายในคอมโพเนนต์ผู้ขายระดับบนสุด ค่านี้ช่วยในการกําหนดผลลัพธ์ของการประมูลระดับบนสุด ค่า topLevelWinningBid ที่เท่ากับ 0 หรือจํานวนติดลบหมายความว่าโฆษณาที่เกี่ยวข้องไม่มีสิทธิ์ชนะการประมูล กลไกนี้อาจนําไปใช้กรองโฆษณาที่กําหนดเป้าหมายตามกลุ่มความสนใจซึ่งไม่มีประสิทธิภาพกว่าโฆษณาที่กําหนดเป้าหมายตามบริบท แม้ว่า topLevelWinningBid ที่มีค่าเป็น 0 อาจบ่งชี้ว่าการประมูลตามบริบทมีผล แต่ข้อกําหนดของ PA API ยอมรับว่าปัจจัยอื่นๆ อาจส่งผลต่อผลลัพธ์นี้
การทดสอบ A/B ของโหมด	การชี้แจงเกี่ยวกับข้อความแจ้งให้เลือกและเลือกไม่ใช้ข้อมูลการจราจรในโหมด B และโหมด A	เกณฑ์การคัดเลือกสำหรับโหมด A และโหมด B เหมือนกัน โดยมีเป้าหมายเพื่อให้มีกลุ่มที่แสดงถึงการเข้าชม Chrome ปกติ ตราบใดที่กลุ่มรองรับ Privacy Sandbox API และวิธีการติดป้ายกํากับ เนื่องจากการกำหนดค่าไคลเอ็นต์บางรายการใช้ร่วมกันไม่ได้ ในการทดสอบ คุณควรเปรียบเทียบเฉพาะการเข้าชมที่ติดป้ายกำกับกับการเข้าชมที่ติดป้ายกำกับอื่นๆ ผู้ใช้ในโหมด B เปิดใช้ฟีเจอร์การป้องกันการติดตามไว้ จึงได้รับการแจ้งเตือนเกี่ยวกับฟีเจอร์ดังกล่าว
การปรับปรุง API	"lifetimeMs" สามารถรวมเป็นพร็อพเพอร์ตี้โดยตรงภายในการเรียก joinAdInterestGroup หรือจัดการเป็นอาร์กิวเมนต์แยกต่างหากได้ไหม	เรากำลังพิจารณาความคิดเห็นจากชุมชนการพัฒนาเว็บเกี่ยวกับฟังก์ชัน "joinAdInterestGroup" ในข้อเสนอ PA API อย่างรอบคอบ จุดสนทนาหลักมุ่งเน้นที่วิธีที่ดีที่สุดในการจัดการอายุการใช้งานของ IG เรากําลังประเมินประโยชน์ของอาร์กิวเมนต์แยกต่างหากสําหรับพารามิเตอร์ "lifetimeMs" เนื่องจากช่วยเพิ่มความยืดหยุ่นและความสามารถในการปรับตัวสําหรับการปรับปรุงข้อกําหนดในอนาคต เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	มีโอกาสที่อัตราผลลบที่ผิดพลาดในเฟรมเวิร์ก PA API จะเพิ่มขึ้นเนื่องจากมีการทับซ้อนกับรหัสเบราว์เซอร์ที่มีความผันผวนต่ำ	ทีม Chrome มีส่วนร่วมอย่างต่อเนื่องในการปรับแต่งเฟรมเวิร์ก PA API ขอขอบคุณที่พูดคุยเกี่ยวกับอัตราผลลบที่ผิดพลาดที่อาจเกิดขึ้นจากการทับซ้อนกันของรหัสเบราว์เซอร์ เรากำลังประเมินความคิดเห็นนี้อย่างรอบคอบ และจะพยายามทำให้การวิเคราะห์ที่อัปเดตแล้วครอบคลุมปัจจัยที่เกี่ยวข้องทั้งหมด เรามุ่งมั่นที่จะนำเสนอโซลูชันที่บรรลุผลลัพธ์ด้านความเป็นส่วนตัวที่ต้องการไปพร้อมกับคงความถูกต้องและความน่าเชื่อถือไว้ เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	จำเป็นต้องใช้ตัวระบุเบราว์เซอร์ที่มีเอนโทรปีต่ำเพื่อป้องกันไม่ให้ไคลเอ็นต์ส่งคำขอ "เข้าร่วม" สำหรับออบเจ็กต์เดียวกันซ้ำๆ ในระบบการระบุตัวตนแบบ k-anonymity หรือไม่	เรารับทราบและขอขอบคุณการสนทนาอย่างต่อเนื่องเกี่ยวกับการใช้ตัวระบุเบราว์เซอร์ในการใช้งานระบบการลบข้อมูลระบุตัวบุคคลแบบ k เราเข้าใจข้อกังวลเกี่ยวกับผลกระทบด้านความเป็นส่วนตัวที่อาจเกิดขึ้นจากตัวระบุดังกล่าว แม้ว่าการใช้งานครั้งแรกของเราจะใช้ตัวระบุที่มีความผันผวนต่ำเป็นกลไกป้องกันการละเมิด แต่เราก็กำลังสำรวจเทคนิคอื่นๆ อย่างสม่ำเสมอ เช่น โทเค็นการนับแบบไม่ระบุตัวตน ซึ่งให้ความสำคัญกับความเป็นส่วนตัวของผู้ใช้ไปพร้อมกับการรักษาความสมบูรณ์ของระบบ เรามุ่งมั่นที่จะค้นหาโซลูชันที่ให้ความสำคัญกับการใช้ข้อมูลอย่างมีความรับผิดชอบควบคู่ไปกับการป้องกันความเป็นส่วนตัวที่เข้มงวด และยินดีที่จะพูดคุยกับชุมชนวิจัยต่อไป เรากำลังพูดคุยเรื่องนี้อยู่ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	AMP (Accelerated Mobile Pages) รองรับ PA API ไหม	ปัจจุบัน AMP ยังไม่รองรับ PA API โดยกำเนิด เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศหากการสนับสนุนจาก AMP เป็นสิ่งสำคัญ
การปรับปรุง API	ลองนำประเภทนี้ออกจากการตรวจสอบ k-anonymity	เรากำลังพิจารณาความคิดเห็นเกี่ยวกับโครงสร้างคำขอการปกปิดข้อมูลบางส่วนตามจำนวนสมาชิก k อย่างรอบคอบเพื่อเพิ่มประสิทธิภาพ เราเข้าใจคำแนะนำในการรวมพารามิเตอร์และอาจรวมประเภทต่างๆ เพื่อปรับปรุงกระบวนการให้มีประสิทธิภาพมากขึ้น เป้าหมายของเราคือความมีประสิทธิภาพและการบำรุงรักษา และเรากำลังประเมินตัวเลือกทั้งหมดในขณะที่พัฒนาโซลูชันด้านความเป็นส่วนตัวต่อไป เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
UI ของ Chrome	ขอกลไกสำหรับผู้ใช้ที่ไม่เชี่ยวชาญด้านเทคนิคในการดูและจัดการ IG ของตนได้อย่างง่ายดาย รวมถึงการควบคุมระดับเว็บไซต์สำหรับการเลือกไม่ใช้	เราตระหนักถึงความสำคัญของการมอบเครื่องมือที่ใช้งานง่ายสำหรับทำความเข้าใจและจัดการ IG เราได้พิจารณาวิธีการต่างๆ อย่างรอบคอบแล้ว และพบว่าการระบุ IG ตามเว็บไซต์ที่เข้าร่วมจะให้ความสมดุลที่ดีที่สุดระหว่างความชัดเจนกับการคุ้มครองความเป็นส่วนตัว ปัจจุบันการจัดการ IG ทั่วโลกอยู่ในการตั้งค่าของ Chrome เรากำลังสำรวจวิธีต่างๆ เพื่อปรับปรุงประสบการณ์ของผู้ใช้ในด้านนี้ให้ดียิ่งขึ้นอย่างต่อเนื่อง เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
ความปลอดภัยของ API	PA API มีความเสี่ยงต่อการรั่วไหลความเป็นส่วนตัวผ่านการโต้ตอบกับครีเอทีฟโฆษณาไหม แม้ในบริบทของเฟรมที่มีรั้วล้อมก็ตาม	เราตระหนักถึงความเสี่ยงที่อาจเกิดการรั่วไหลของข้อมูลผ่านการโต้ตอบกับโฆษณาที่ซับซ้อน เรากำลังตรวจสอบการโต้ตอบระหว่างเฟรมที่มีรั้วล้อม, PA API และเวกเตอร์การโจมตีที่อาจเกิดขึ้น การลดความเสี่ยงด้านความเป็นส่วนตัวเป็นสิ่งสำคัญอันดับแรก และเรามุ่งมั่นที่จะพัฒนาโซลูชันที่มีประสิทธิภาพซึ่งสร้างความสมดุลระหว่างนวัตกรรมกับการปกป้องผู้ใช้ เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
เวลาในการตอบสนอง	ระยะหมดเวลาเริ่มต้น 50 มิลลิวินาทีสำหรับตรรกะการเสนอราคาของผู้ซื้อเป็นค่าที่สมจริงไหม	เรารับทราบข้อกังวลที่อาจเกิดขึ้นเกี่ยวกับความไม่สอดคล้องกันระหว่างข้อกําหนดและช่วงเวลาของคําขอเครือข่ายสําหรับตรรกะการเสนอราคา เรากําลังตรวจสอบข้อกําหนดอย่างสม่ำเสมอเพื่อให้แน่ใจว่าถูกต้อง และตรวจสอบการตั้งค่าการหมดเวลาเริ่มต้นที่ดีที่สุดเพื่อรักษาสมดุลระหว่างประสิทธิภาพและความเป็นไปได้ เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
เอกสารประกอบ	การเปิดเผยข้อมูลเวลาโดยไม่ได้ตั้งใจในข้อกําหนดซึ่งเว็บไซต์อาจอนุมานได้ว่าโฆษณาไม่ผ่านเกณฑ์ k-anonymity หรือไม่ และผลกระทบที่อาจเกิดขึ้นกับการติดตามข้ามเว็บไซต์	เราทราบปัญหาที่แจ้งมาเกี่ยวกับการรั่วไหลของเวลา เรายืนยันแล้วว่าข้อมูลจำเพาะมีความคลาดเคลื่อนและกำลังดำเนินการเพื่อกำหนดสถานะการไม่ระบุตัวตนแบบ k ของโฆษณาก่อนการประมูลเพื่อป้องกันการรั่วไหลดังกล่าว เราให้ความสำคัญกับข้อกังวลเหล่านี้และจะอัปเดตข้อกำหนดให้สอดคล้องกับการเปลี่ยนแปลงเหล่านี้ เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	วิธีใช้รายการที่บล็อก SSP ภายใน PA API	เราตระหนักถึงความจำเป็นในการใช้กลไกเพื่อจัดการข้อจํากัดโฆษณาโดย SSP เราขอแนะนําให้ลองใช้โซลูชันที่ให้ความสําคัญกับการประเมินในอุปกรณ์และใช้ประโยชน์จากข้อมูลเมตาโฆษณาที่มีอยู่เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้ไปพร้อมกับมอบความยืดหยุ่น เรามุ่งมั่นที่จะทํางานร่วมกับนักพัฒนาแอปเพื่อค้นหาแนวทางที่ดีที่สุดภายใน PA API เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	ผู้ใช้บอกเบราว์เซอร์ให้แอบอ้างใช้ PA API ในลักษณะที่เว็บไซต์ตรวจไม่พบได้ไหม	เรารับทราบว่าเว็บไซต์อาจตรวจพบการเลือกใช้ PA API ในรูปแบบปัจจุบัน เรากําลังพัฒนาฟีเจอร์ต่างๆ เช่น การเสนอราคาเพิ่มเติมและการกําหนดเป้าหมายเชิงลบ รวมถึงการแสดงผลเฟรมที่มีรั้วล้อม เพื่อปรับปรุงความเป็นส่วนตัวและพยายามมอบตัวเลือกในการเลือกไม่ใช้ที่ตรวจไม่พบ เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การทดสอบ A/B ของโหมด	การเข้าชมศูนย์ข้อมูลที่อ้างว่าเป็นการรักษา 1.1	ทีม Chrome ได้ยืนยันกับทีม GAM แล้วว่าตอนนี้มีการกรองการเข้าชมนี้ออกจากการทดสอบแล้ว เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	ประสิทธิภาพและความยุติธรรมของการใช้งาน interestGroupBuyers ใน PA API	เราทราบดีว่าการประมูล PA API มีการพูดคุยกันอย่างต่อเนื่องเกี่ยวกับประสิทธิภาพและความยุติธรรมของช่อง "interestGroupBuyers" เราตระหนักดีถึงข้อดีข้อเสียระหว่างประสิทธิภาพ ความเป็นส่วนตัว และความเป็นธรรมในตลาด แม้ว่าผู้ขายจะต้องจัดการความสัมพันธ์ทางธุรกิจกับผู้ซื้อ แต่เราก็กำลังหาวิธีเพิ่มประสิทธิภาพกระบวนการจับคู่ ซึ่งอาจรวมถึงการปรับแบบไดนามิกตามข้อมูลแบบเรียลไทม์และโมเดลแบบผสม เรายังคงมุ่งมั่นที่จะค้นหาโซลูชันที่ให้ความสำคัญกับความเป็นส่วนตัวของผู้ใช้และสนับสนุนระบบนิเวศการโฆษณาที่แข่งขันได้ เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
UI ของ Chrome	ข้อกังวลเกี่ยวกับหน่วยความจำที่อาจเกิดขึ้นและความชัดเจนของ UI ที่เกี่ยวข้องกับ IG ใน Chrome	เราเข้าใจข้อกังวลเกี่ยวกับการแสดง IG ในเครื่องมือสำหรับนักพัฒนาเว็บ แม้ว่ามุมมองปัจจุบันจะแสดงเหตุการณ์ IG ทั้งหมดสำหรับการติดตามที่ผ่านมา แต่เราก็ตระหนักดีว่าการแสดงสถานะปัจจุบันของ IG ที่เก็บไว้อย่างชัดเจนยิ่งขึ้นนั้นมีประโยชน์ เราจะสำรวจการเพิ่มประสิทธิภาพและการปรับปรุง UI ที่เป็นไปได้เพื่อเพิ่มข้อมูลเชิงลึกของนักพัฒนาแอป สำหรับการจัดการหน่วยความจำ การติดตั้งใช้งาน IG ได้รับการออกแบบมาเพื่อป้องกันไม่ให้หน่วยความจำรั่วไหล แต่เราตรวจสอบและเพิ่มประสิทธิภาพการใช้ทรัพยากรอย่างต่อเนื่อง เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
เอกสารประกอบ	ผู้โพสต์ต้นฉบับพบข้อผิดพลาดเมื่อพยายามใช้ขนาดโฆษณาที่มีชื่อภายในช่อง "sizeGroup" ของฟังก์ชัน "joinAdInterestGroup" โดยตรง พวกเขาต้องการทราบว่านี่เป็นลักษณะการทำงานที่ต้องการหรือไม่	เราทราบดีว่าการปรับปรุงการกำหนดค่าโฆษณาภายในฟังก์ชัน "joinAdInterestGroup" มีประโยชน์เพียงใด เรากําลังดําเนินการอย่างจริงจังเพื่อแก้ไขข้อจํากัดนี้และวางแผนที่จะเปิดใช้ฟังก์ชันนี้ในการอัปเดตในอนาคต การปรับปรุงนี้สอดคล้องกับความมุ่งมั่นของเราในการจัดหาเครื่องมือที่ยืดหยุ่นและมีประสิทธิภาพสำหรับการจัดการโฆษณาให้แก่นักพัฒนาแอป เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
ป้ายกำกับการทดสอบที่อำนวยความสะดวกโดย Chrome	ขอข้อมูลโดยตรงเกี่ยวกับโหมด A เทียบกับ B และป้ายกำกับที่แน่นอนใน sendReportTo เพื่อให้เราติดตามการทดสอบได้อย่างสอดคล้องกัน	เรากำลังพูดคุยเกี่ยวกับคำขอนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
เอกสารประกอบ	ชื่อโดเมนของผู้ขายรวมอยู่ในคำขอที่ส่งไปยังเซิร์ฟเวอร์ที่เชื่อถือได้ของผู้ขายเพื่อวัตถุประสงค์ในการตรวจสอบหรือไม่	เรารับทราบว่ามีการละเว้นพารามิเตอร์ชื่อโฮสต์จากเอกสารประกอบของ Protected Audience KV Server API ในช่วงแรก เราขอรับรองกับนักพัฒนาแอปว่าระบบจะรวมชื่อโดเมนของผู้ขายไว้ในคำขอไปยังเซิร์ฟเวอร์ที่เชื่อถือได้ของผู้ขายโดยอัตโนมัติ ฟังก์ชันการทำงานนี้จำเป็นต่อกระบวนการตรวจสอบโฆษณาที่มีประสิทธิภาพ เราได้อัปเดตเอกสารประกอบเพื่อแก้ไขข้อบกพร่องนี้ และจะยังคงให้ความสำคัญกับความชัดเจนและความโปร่งใสสำหรับชุมชนนักพัฒนาแอปต่อไป เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	วิธีการที่เป็นไปได้ในการรวมชื่อ IG ไว้ในการเรียกใช้การติดตามการแสดงโฆษณาเพื่อวัตถุประสงค์ในการรายงาน	เรามุ่งมั่นที่จะรักษาสมดุลระหว่างความจำเป็นในการใช้กลไกการรายงานที่มีประสิทธิภาพกับหลักการพื้นฐานด้านความเป็นส่วนตัวของผู้ใช้ การรวมชื่อ IG ไว้ในเครื่องมือวัดการแสดงโฆษณาอยู่ภายใต้การป้องกันแบบ k-anonymity ที่ออกแบบมาเพื่อป้องกันการระบุตัวบุคคล เราจะยังคงมองหาโซลูชันการรายงานที่สร้างสรรค์ภายใต้ข้อจำกัดด้านความเป็นส่วนตัวเหล่านี้ต่อไป เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
ฟีเจอร์ API	ส่งคําขอไปยังเซิร์ฟเวอร์ที่เชื่อถือได้ของผู้ซื้อเพื่อรับส่วนหัว HTTP ของ Client Hints	เราติดตามคำขอฟีเจอร์นี้ที่นี่
การใช้ API	ไฟล์การมอบสิทธิ์ควรกำหนดให้โหลดส่วนหัว "Access-Control-Allow-Origin" หรือไม่ เนื่องจากไฟล์ดังกล่าวกำหนดลักษณะการเป็นสมาชิก IG สำหรับเบราว์เซอร์	เรามุ่งมั่นที่จะปรับให้สอดคล้องกับแนวทางปฏิบัติแนะนำด้านความปลอดภัยบนเว็บ ข้อกำหนดของส่วนหัว "Access-Control-Allow-Origin" สำหรับไฟล์การมอบสิทธิ์ช่วยให้มั่นใจว่าไฟล์ดังกล่าวสอดคล้องกับหลักการ CORS และป้องกันการเปิดเผยข้อมูลที่ละเอียดอ่อนโดยไม่ตั้งใจ เรากำลังหาวิธีเพิ่มประสิทธิภาพกระบวนการนี้ไปพร้อมกับรักษาสถานะความปลอดภัยที่เข้มงวด เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	เปิดใช้เซิร์ฟเวอร์โฆษณาเพื่อปรับเปลี่ยนครีเอทีฟโฆษณาภายในเฟรมเวิร์ก PA API	เราตระหนักดีถึงบทบาทที่เซิร์ฟเวอร์โฆษณามีต่อการปรับครีเอทีฟโฆษณาตามโปรไฟล์ของผู้ใช้ เรากําลังสํารวจโซลูชันต่างๆ เพื่อเพิ่มประสิทธิภาพเซิร์ฟเวอร์โฆษณาภายใน PA API เช่น รูปแบบ "IG ร่วม" ที่รวมตรรกะการเสนอราคาและการเลือกครีเอทีฟโฆษณาเข้าด้วยกัน เป้าหมายของเราคือการสร้างความสมดุลระหว่างการเปิดใช้ความสามารถของครีเอทีฟโฆษณาที่มีประสิทธิภาพกับการปกป้องความเป็นส่วนตัวของผู้ใช้ เรายินดีรับฟังความคิดเห็นและการทำงานร่วมกันเพิ่มเติมเกี่ยวกับการพัฒนา API เพื่อตอบสนองความต้องการของผู้มีส่วนเกี่ยวข้องทั้งหมดที่นี่
ข้อกังวลเกี่ยวกับความเป็นส่วนตัว	ความพร้อมใช้งานของตัวระบุอื่น (เช่น RampID, ID5) ในคําขอราคาเสนอตามบริบทอาจทําให้เป้าหมายด้านความเป็นส่วนตัวของ PA API เสียไปด้วยการอำนวยความสะดวกในการรวบรวมข้อมูลจากหลายเว็บไซต์	เราตระหนักดีถึงความขัดแย้งที่อาจเกิดขึ้นระหว่างตัวระบุข้ามเว็บไซต์กับวัตถุประสงค์ด้านความเป็นส่วนตัวของ PA API แม้ว่าผู้เผยแพร่โฆษณาจะเลือกแชร์ตัวระบุดังกล่าวได้ แต่การออกแบบ PA API มีจุดมุ่งหมายพื้นฐานเพื่อแยกการเลือกโฆษณาออกจากความจำเป็นในการติดตามข้ามเว็บไซต์ เรามุ่งมั่นที่จะส่งเสริมระบบนิเวศการโฆษณาที่เน้นความเป็นส่วนตัว และสนับสนุนให้นักพัฒนาแอปให้ความสำคัญกับแนวทาง PA API เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การแคช	มีวิธีป้องกันไม่ให้ใช้สคริปต์การเสนอราคาซ้ำในการประมูลหลายรายการไหม	เรารับทราบลักษณะการแคชของสคริปต์การเสนอราคาภายในเฟรมเวิร์ก PA API ที่สังเกตได้ แม้ว่าระบบจะรองรับกลไกการแคช HTTP มาตรฐาน แต่ก็มีแนวโน้มที่จะนําสคริปต์มาใช้ซ้ำในการประมูลเนื่องจากลักษณะการระงับอุปกรณ์และการออกแบบผู้ดําเนินการเสนอราคา ทีมกําลังตรวจสอบโซลูชันเพื่อให้ผู้ซื้อควบคุมการแคชสคริปต์ได้มากขึ้นเพื่อจัดการกลยุทธ์การเสนอราคาได้อย่างมีประสิทธิภาพ เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	รายงานกิจกรรมการเสนอราคาจาก IG ทั้งหมดของ DSP ไว้ในที่เดียว ขณะเดียวกันก็เคารพความเป็นส่วนตัวของผู้ใช้	เราให้ความสำคัญกับความเป็นส่วนตัวของผู้ใช้เมื่อออกแบบ PA API แม้ว่าการรายงานเหตุการณ์การเสนอราคาแต่ละรายการโดยตรงจะเป็นไปไม่ได้เนื่องจากความเสี่ยงในการติดตามข้ามเว็บไซต์ แต่เรามีกลไกต่างๆ เช่น พื้นที่เก็บข้อมูลที่ใช้ร่วมกันและการรวบรวมข้อมูลส่วนตัว ข้อมูลเหล่านี้ช่วยให้ DSP ได้รับข้อมูลเชิงลึกแบบรวมเกี่ยวกับกิจกรรมการเสนอราคาในลักษณะที่เคารพความเป็นส่วนตัวของผู้ใช้
การใช้ API	การดึงข้อมูลจาก sendReportTo() ใน reportResult() เกิดขึ้นเพียง 94% ของเวลาเมื่อเทียบกับการดึงข้อมูลที่ลงทะเบียนด้วย forDebuggingOnly.reportAdAuctionWin()	แม้ว่า URL ทั้งสองอาจไม่ได้ดึงข้อมูลพร้อมกัน แต่ก็มีสิทธิ์ที่จะดึงข้อมูลพร้อมกันได้ ในบางกรณี ระบบจะทิ้งเวิร์กเลตของผู้ขายคอมโพเนนต์และจำเป็นต้องโหลดซ้ำเพื่อเรียกใช้ฟังก์ชัน reportResult() อย่างไรก็ตาม ระยะเวลาในการดึงข้อมูลตรรกะการให้คะแนนหรือเวลาในการโหลดซ้ำของเวิร์กเลตจะไม่ส่งผลต่อระยะหมดเวลา 50 มิลลิวินาทีของ for reportResult() โปรดทราบว่า Chrome จะใช้ส่วนหัวการแคชเพื่อกำหนดลักษณะการดึงข้อมูลในกรณีที่ต้องโหลดเวิร์กเลตซ้ำ ดูข้อมูลเพิ่มเติมเกี่ยวกับระยะต่างๆ ของการประมูล PA ได้ที่นี่
K-anonymity	คำขอยืนยันว่าชื่อของ interestGroup จะไม่ส่งผลต่อความเป็นส่วนตัวแบบ k-anonymity ของการแสดงโฆษณา	ครีเอทีฟโฆษณาจะถือว่าไม่ระบุตัวตนแบบ k ได้ก็ต่อเมื่อชุดค่าผสมของ URL เจ้าของ IG, URL สคริปต์การเสนอราคา, URL ของครีเอทีฟโฆษณา และขนาดโฆษณาเป็นไปตามเกณฑ์ที่ระบุ (k) ในช่วงระยะเวลาที่ผ่านมา (w) สถานะ K-anonymity ได้รับการอัปเดตเป็นระยะ (p)
UI ของ Chrome	ข้อเสนอในการระบุประเภท "การแสดงผลภายใน" ที่เฟรมเวิร์ก MVC, ORM และอื่นๆ จำนวนมากมีให้ เช่น เริ่มต้นด้วยการบันทึกเหตุการณ์ภายในที่เลือกไว้อย่างง่ายดายลงในแผงใหม่ในส่วนเครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ --> แอปพลิเคชัน --> ส่วนแอปพลิเคชัน	เรากำลังพูดคุยเกี่ยวกับข้อเสนอที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
UI ของ Chrome	เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ IG Joining ไม่แสดงองค์ประกอบที่เกี่ยวข้องกับลําดับความสําคัญ	เราได้แก้ไขปัญหานี้ที่นี่
การปรับปรุง API	คุณควรอนุญาตให้เซิร์ฟเวอร์โฆษณาครีเอทีฟโฆษณาติดตามเหตุการณ์ของตนเอง รายการโดเมนการติดตามที่อนุญาตสามารถกําหนดค่าได้ไหม	เราได้แชร์ข้อเสนอที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
คำขอฟีเจอร์ API	PA API ขยายการให้บริการเพื่อรองรับธุรกรรมสื่อที่ไม่ใช่ RTB และคงกรณีการใช้งานที่สําคัญ เช่น การแสดงโฆษณาและ DCO ได้ไหม	เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
ระยะหมดเวลาการประมูลของผู้เผยแพร่โฆษณา	ผู้เผยแพร่โฆษณาต้องควบคุมระยะเวลาการประมูลเพื่อป้องกันไม่ให้มีการสูญเสียการแสดงผล โดยเฉพาะในการตั้งค่าการเสนอราคาส่วนหัวที่ระบบจะเลือกโฆษณาตามลําดับ	เราตระหนักถึงความสำคัญของการให้สิทธิ์แก่ผู้เผยแพร่โฆษณาในการควบคุมระยะหมดเวลาของการประมูลโฆษณาอย่างละเอียด เรากําลังหาวิธีใช้กลไกการหมดเวลาการประมูลทั่วโลก ซึ่งอาจอยู่ภายในออบเจ็กต์ "auctionConfig" พร้อมกับพิจารณากรณีขอบเขตอย่างรอบคอบ ฟีเจอร์นี้มีจุดประสงค์เพื่อเพิ่มประสิทธิภาพอัตราการแสดงโฆษณาที่ได้ผลสำหรับผู้เผยแพร่โฆษณา และเราจะร่วมมือกับชุมชนต่อไปเพื่อค้นหาโซลูชันที่ดีที่สุด เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การปรับปรุง API	การออกแบบ IG ในปัจจุบันใน PA API ทําให้ข้อมูลเมตามีขนาดใหญ่เนื่องจาก renderURL มีความยาว ผู้ทดสอบต้องการวิธีบีบอัด URL เหล่านี้เพื่อให้มีประสิทธิภาพมากขึ้น	เราตระหนักดีว่าการเพิ่มประสิทธิภาพขนาดข้อมูลเมตาของ IG มีความสําคัญอย่างยิ่ง โดยเฉพาะสําหรับการประมูลโฆษณาที่คำนึงถึงประสิทธิภาพ เราคิดว่าโซลูชันที่ใช้เทมเพลตในการบีบอัด renderURLs มีโอกาสเติบโตอย่างมาก เราจะประเมินการออกแบบเทมเพลตที่เสนออย่างละเอียด และตรวจสอบว่าโซลูชันที่ติดตั้งใช้งานมีกลไกการป้องกันการละเมิดที่มีประสิทธิภาพเพื่อรักษาเสถียรภาพของเบราว์เซอร์ การทำงานร่วมกับชุมชนมาตรฐานเว็บเพื่อพัฒนาแนวทางที่ดีที่สุดโดยคำนึงถึงข้อควรพิจารณาเหล่านี้ยังคงเป็นสิ่งที่เราให้ความสำคัญ เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	ผู้ทดสอบที่จัดการรูปแบบโฆษณาเนทีฟต้องการเพิ่มประสิทธิภาพกระบวนการประมูลของ Privacy Sandbox โดยการดึงข้อมูลโฆษณาหลายรายการในการเรียกใช้ครั้งเดียวเพื่อลดภาระเครือข่ายและปรับปรุงความเร็วในการแสดงผลโฆษณา	เราทราบดีถึงข้อกังวลด้านประสิทธิภาพที่เพิ่มขึ้นสําหรับการแสดงโฆษณาเนทีฟใน Privacy Sandbox เรามุ่งมั่นที่จะหาจุดสมดุลระหว่างประสิทธิภาพกับการคุ้มครองความเป็นส่วนตัวของผู้ใช้ที่เข้มงวด แม้ว่าการแสดงโฆษณาหลายรายการที่มีคะแนนเต็มจะลดความเป็นส่วนตัว แต่เราก็พยายามหาวิธีเพิ่มประสิทธิภาพกระบวนการประมูลอยู่เสมอ เรามุ่งมั่นที่จะปรับปรุงการรองรับ PA API สําหรับรูปแบบโฆษณาเนทีฟ และตรวจสอบกลไกอื่นๆ เพื่อปรับปรุงประสิทธิภาพภายใต้ข้อจํากัดด้านความเป็นส่วนตัวที่เข้มงวดของ Privacy Sandbox เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	ความยืดหยุ่นในการจัดลําดับและคะแนนราคาเสนอโฆษณาภายใน Privacy Sandbox โดยเฉพาะอย่างยิ่งเพื่อแสดงระดับลําดับความสําคัญหรือกฎของมาร์เก็ตเพลสส่วนตัว	เราเข้าใจดีว่าการควบคุมการให้คะแนนและการจัดเรียงโฆษณาอย่างละเอียดภายใน Privacy Sandbox มีความจําเป็นอย่างยิ่ง โดยเฉพาะในสถานการณ์การเสนอราคาที่ซับซ้อน เรารับทราบโซลูชันที่เสนอโดยใช้ทูเพลตและฟังก์ชันทางคณิตศาสตร์เพื่อให้ได้คะแนนแบบหลายมิติโดยไม่ละเมิดความเป็นส่วนตัวของผู้ใช้ แม้ว่าแนวทางเหล่านี้อาจเพิ่มความซับซ้อนให้กับนักพัฒนาแอป แต่ก็ช่วยให้แสดงออกได้อย่างที่ต้องการ เรามุ่งมั่นที่จะค้นหาวิธีปรับปรุงกระบวนการเหล่านี้ให้มีประสิทธิภาพมากขึ้น ซึ่งอาจทำได้ผ่านฟังก์ชันตัวช่วยหรือหลักเกณฑ์ เพื่อให้การใช้ฟีเจอร์ Privacy Sandbox กับตรรกะการประมูลขั้นสูงเป็นไปอย่างเหมาะสมที่สุด เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
reportEvent()	เพิ่มเหตุการณ์ที่สงวนไว้ใหม่ (อาจเป็นบีคอนอัตโนมัติ) ที่เรียกใช้โดยเบราว์เซอร์เมื่อเริ่มต้นเฟรมที่มีครีเอทีฟโฆษณา	เรากำลังพูดคุยเกี่ยวกับคำขอนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
adCost	อนุญาตให้แสดงรายละเอียดของ adCost	ค่าต้นทุนแต่ละค่าเป็นโอกาสในการส่งข้อมูลจํานวนจำกัดออกจากการประมูล การให้สิทธิ์รายการค่าใช้จ่าย N รายการทั้งหมดก็เพียงพอที่จะส่งตัวระบุผู้ใช้ทั้งหมด ซึ่งจะเปิดใช้การติดตามข้ามเว็บไซต์ เรากำลังพูดคุยเรื่องนี้อยู่ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
resolveToConfig	ควรรับค่า resolveToConfig มาจากระดับบนสุดและแสดงใน browserSignals ไหม	เรากำลังพูดคุยเกี่ยวกับคำขอนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
เครื่องมือที่ดีขึ้น	มีหน้าเว็บที่คล้ายกับ chrome://topics-internals สำหรับ PA API ไหม	ไม่มีอะไรเหมือนกันทุกประการ แต่มีเครื่องมือสําหรับนักพัฒนาซอฟต์แวร์มากมายสําหรับ PA API
ป้ายกำกับ	Chrome ใช้ป้ายกำกับเพื่อระบุประชากร k-anon 20% ได้ไหม	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
เอกสารประกอบ	ชิ้นงานการประมูลของ Privacy Sandbox จะกลายเป็นประเภทชิ้นงานมาตรฐานไหม	เวิร์กเลตเหล่านี้แตกต่างจากเวิร์กเลตประเภทมาตรฐานในเบราว์เซอร์อย่างมากเนื่องจากข้อกําหนดด้านความเป็นส่วนตัวและความปลอดภัยที่ไม่ซ้ำกัน เราจึงคาดว่าเวิร์กเลตเหล่านี้จะยังไม่กลายเป็นเวิร์กเลตประเภทมาตรฐานในข้อกําหนด HTML ในเร็วๆ นี้ เรามุ่งมั่นที่จะปรับปรุงแหล่งข้อมูลสําหรับนักพัฒนาซอฟต์แวร์ด้วยคําอธิบายที่ชัดเจนเกี่ยวกับการใช้งานและสภาพแวดล้อมการดําเนินการของเวิร์กเลตการประมูล เพื่อให้ผู้เข้าร่วมใน Privacy Sandbox เข้าถึงข้อมูลนี้ได้มากขึ้น เราได้พูดคุยเรื่องนี้เพิ่มเติมที่นี่
เซิร์ฟเวอร์คีย์-ค่า (KV) แบบนําเซิร์ฟเวอร์ของคุณเอง (BYOS)	บุคคลที่สามอาจดู IG หลายรายการ (จากผู้เป็นเจ้าของเดียวกัน) ที่ผู้ใช้เข้าร่วมได้ผ่านการค้นหาบริการ KV ในการตั้งค่าบริการ KV แบบ BYOS	ซึ่งจะใช้งานไม่ได้อีกต่อไปเมื่อเซิร์ฟเวอร์ KV ทำงานใน TEE และเรามั่นใจว่าเซิร์ฟเวอร์ดังกล่าวจะปฏิบัติตามรูปแบบความน่าเชื่อถือที่เผยแพร่
userBiddingSignals	อัปเดต "userBiddingSignals" บางส่วนขณะที่เก็บรักษารายการอื่นๆ	ซึ่งทำได้อยู่แล้วโดยที่ไม่ต้องเปลี่ยนแปลง API
การใช้ API	ใช้การกำหนดความถี่สูงสุดใน IG หลายรายการภายใน Privacy Sandbox ซึ่งอาจใช้เซิร์ฟเวอร์ KV หรือข้อมูล "prevWinsMs" ที่แก้ไขแล้ว	เราทราบดีว่าคุณต้องการความสามารถในการจำกัดความถี่ขั้นสูงใน Privacy Sandbox เราตระหนักดีว่าข้อจำกัดปัจจุบันเกี่ยวกับการแชร์ข้อมูลใน IG อาจทำให้เกิดปัญหาเมื่อนำกลยุทธ์เหล่านี้ไปใช้ แม้ว่าเซิร์ฟเวอร์ KV จะมีกลไกที่อาจเป็นไปได้พร้อมการปกป้องความเป็นส่วนตัวที่เหมาะสม แต่เราขอแนะนำให้นักพัฒนาซอฟต์แวร์สำรวจโซลูชันภายในโมเดล IG เดียว เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	ผู้ขายคอมโพเนนต์ (ผู้เข้าร่วมการประมูลที่ซ้อนกันภายใน Privacy Sandbox) จำเป็นต้องเห็นการหมดเวลาการประมูลระดับบนสุดเพื่อเพิ่มประสิทธิภาพการกำหนดค่าของตนเองและหลีกเลี่ยงความล่าช้าที่ไม่จำเป็น	เราตระหนักถึงความจำเป็นในการปรับปรุงการประสานงานเกี่ยวกับระยะหมดเวลาระหว่างผู้ขายระดับบนสุดกับผู้ขายคอมโพเนนต์ภายใน Privacy Sandbox เรากําลังตรวจสอบการเพิ่มกลไกการหมดเวลาใหม่ รวมถึงการหมดเวลาการประมูลทั้งหมดที่อาจเกิดขึ้น และหาวิธีใช้การหมดเวลาระดับบนสุดกับการประมูลคอมโพเนนต์ เป้าหมายของเราคือการปรับปรุงประสิทธิภาพและความคาดการณ์ได้สำหรับผู้เข้าร่วมทุกคนในกระบวนการประมูลของ Privacy Sandbox เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม

บริการ Protected Audience

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)	การใช้ TEE ในระบบคลาวด์สาธารณะมีค่าใช้จ่ายสูงกว่าเมื่อเทียบกับศูนย์ข้อมูลเทคโนโลยีโฆษณาในสถานที่ตั้งจริงหรือไม่	คำตอบของเราคล้ายกับในไตรมาสก่อนหน้า โมเดลการรักษาความปลอดภัย TEE ปัจจุบันของเราได้รับประโยชน์จากแนวทางการใช้งานระบบคลาวด์สาธารณะ โดยเฉพาะอย่างยิ่ง TEE ที่ใช้ฮาร์ดแวร์ในปัจจุบันไม่สามารถป้องกันการโจมตีทางกายภาพบางประเภทได้ ผู้ให้บริการระบบคลาวด์สาธารณะที่รองรับในปัจจุบันอย่าง AWS และ Google Cloud ได้ออกแบบและติดตั้งใช้งานมาตรการลดความเสี่ยงในการเข้าถึงอุปกรณ์จริง ซึ่งรวมถึงจากพนักงาน ดูรายละเอียดต่อไปนี้เกี่ยวกับการสนับสนุนในสถานที่ ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาแจ้งให้เราทราบว่าการใช้บริการระบบคลาวด์มีค่าใช้จ่ายสูงกว่าศูนย์ข้อมูลเทคโนโลยีโฆษณาในองค์กร แม้ว่าเราจะไม่สามารถประเมินข้อความเหล่านั้นได้ แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับค่าใช้จ่ายและจะประเมินตัวเลือกในการขยายการรองรับ TEE ต่อไป
TEEs	การรองรับ TEE ในสภาพแวดล้อมระบบคลาวด์ที่ไม่ใช่แบบสาธารณะ	คำตอบของเราจะคล้ายกับในไตรมาสก่อน แม้ว่าเราจะยังคงสำรวจการสนับสนุนตัวเลือกนอกเหนือจากโซลูชันที่ทำงานบนระบบคลาวด์สาธารณะ แต่ปัจจุบันเรายังไม่มีแผนที่จะรองรับ TEE ในระบบขององค์กร ในขั้นตอนนี้ เราเชื่อว่าการขยายและปรับปรุงการใช้งานบนระบบคลาวด์อย่างต่อเนื่อง (เช่น การรองรับ Google Cloud นอกเหนือจาก AWS) จะให้ประโยชน์สูงสุดต่อระบบนิเวศ เนื่องจากข้อกำหนดด้านความปลอดภัยของ Privacy Sandbox และข้อจำกัดที่สำคัญของการใช้งานในเครื่อง อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ข้อกำหนดดังกล่าวมีความจําเป็นและทําได้จริงเมื่อพิจารณาจากข้อจํากัดด้านความเป็นส่วนตัวและความปลอดภัย
ผู้ให้บริการระบบคลาวด์รายอื่นๆ	การสนับสนุนสำหรับผู้ให้บริการระบบคลาวด์รายอื่น	เรายินดีรับฟังคำแนะนำเกี่ยวกับผู้ให้บริการระบบคลาวด์รายอื่นๆ เสมอ แต่เราวางแผนที่จะรองรับ Google Cloud และ AWS เป็นอย่างน้อยเมื่อมีการบังคับใช้ 3PCD ดูข้อมูลเพิ่มเติมได้ในคำอธิบายนี้
B&A Services API	ทิศทางของ Google สําหรับ B&A Services API คืออะไร โฆษณาจะมีความสำคัญเหนือกว่าหรือต่ำกว่ากลุ่มเป้าหมายที่ได้รับการคุ้มครองของเบราว์เซอร์ Chrome ในการประมูลบนอุปกรณ์	คําตอบของเราคล้ายกับในไตรมาสก่อน เรายังคงมุ่งมั่นที่จะใช้การออกแบบการเสนอราคาในอุปกรณ์ของ Protected Audience ในปัจจุบัน บริการนี้เสนอขึ้นเพื่อสำรวจโซลูชันที่เป็นไปได้เพื่อรองรับกรณีการใช้งานย่อยที่อาจมีการจํากัดกำลังการประมวลผลหรือความเร็วของเครือข่ายของอุปกรณ์
มาตรฐาน	บริการ B&A ยังไม่ผ่านกระบวนการมาตรฐาน	ข้อเสนอบริการ B&A อยู่ในช่วงกลางของขั้นตอนหนึ่งของกระบวนการมาตรฐาน และเรายินดีรับการมีส่วนร่วมเพิ่มเติมเพื่อสนับสนุนเป้าหมายดังกล่าว ข้อเสนอนี้เริ่มต้นจากข้อเสนอ (ซึ่งอิงตามข้อเสนอก่อนหน้านี้) และกำลังได้รับการพัฒนาต่อยอดแบบสาธารณะผ่านการพูดคุยแบบเปิดกว้างที่ W3C และนักพัฒนาซอฟต์แวร์ที่มีความสนใจสามารถเริ่มทดลองใช้และแสดงความคิดเห็นได้ นี่เป็นรูปแบบปกติสำหรับการพัฒนาฟีเจอร์บนเว็บ ดังที่อธิบายไว้ในบล็อกโพสต์ที่นี่
เซิร์ฟเวอร์ KV	แสดง URL แบบเต็มต่อเซิร์ฟเวอร์ KV ของผู้ซื้อสําหรับการกําหนดเป้าหมายตามเนื้อหา / บริบท / เว็บไซต์	เรากำลังพูดคุยเกี่ยวกับคำขอนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
เอกสารประกอบ	เอกสารประกอบสําหรับ "คอมโพเนนต์ที่เชื่อถือได้/บังคับใช้เทียบกับไม่บังคับใช้" ใน GitHub ทําให้เกิดความสับสนสําหรับนักเทคโนโลยีโฆษณาบางรายที่มีชุดภาพและโครงสร้างพื้นฐานของการติดตั้งใช้งานของตนเอง	เราต้องการปรับปรุงเอกสารประกอบสําหรับ "คอมโพเนนต์ที่เชื่อถือได้/บังคับใช้เทียบกับคอมโพเนนต์ที่ไม่บังคับ" และอยากทราบความคิดเห็นจากระบบนิเวศว่าควรให้ความสําคัญกับงานดังกล่าวหรือไม่
การปรับปรุง API	รหัสสถานะ HTTP ของการเรียกเซิร์ฟเวอร์ KV ควรใช้เป็นพารามิเตอร์ของฟังก์ชัน scoreAd() ด้วย	เรากำลังประเมินคำขอนี้และยินดีรับความคิดเห็นเพิ่มเติมจากระบบนิเวศ
เอกสารประกอบ	ระบุข้อมูลเพิ่มเติมเกี่ยวกับวิธีจัดการเวิร์กโหลด JS และ WASM กับการเรียกใช้ UDF	เรากำลังพิจารณาที่จะให้ข้อมูลนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
เอกสารประกอบ	คำขออัปเดตชื่อที่เก็บ	เราได้เปลี่ยนชื่อที่เก็บข้อมูลเป็น "protected-auction-key-value-service" ซึ่งสอดคล้องกับคําที่ใช้เรียกคอลเล็กชันบริการที่เก็บข้อมูลนี้ ซึ่งยังมีที่เก็บข้อมูลอื่นๆ ด้วย เช่น ที่เก็บการสนทนาเกี่ยวกับบริการกลุ่มเป้าหมายที่ได้รับการคุ้มครอง และที่เก็บเอกสารประกอบเกี่ยวกับบริการการประมูลที่ได้รับการคุ้มครอง
เอกสารประกอบ	นำการอ้างอิงถึง Cloud Debugger API ออกใน bidding_auction_services_gcp_guide.md	เราได้อัปเดตเอกสารประกอบและนำข้อมูลอ้างอิงออกแล้ว
การใช้ API	เวลาในการตอบสนองที่เกิดจากการค้นหา KV ใช้เวลานานกว่า 50 มิลลิวินาที ใช้เวลาเกือบ 100 มิลลิวินาที คุณมีคำแนะนำเกี่ยวกับสิ่งที่ได้ผลดีสำหรับผู้ขายรายอื่นๆ ไหม คุณมีคำแนะนำเกี่ยวกับวิธีวัดการหมดเวลาและการกำหนดเวลาไหม	การเรียกเซิร์ฟเวอร์ KV เกิดขึ้นภายในบริบทของโปรแกรมรันสคริปต์ ซึ่งก็คือสภาพแวดล้อมที่ได้รับการปกป้องเป็นพิเศษภายในเบราว์เซอร์ Chrome โดยมีวัตถุประสงค์เพื่อปกป้องข้อมูลในโปรแกรมรันสคริปต์เหล่านี้จากการเข้าถึงที่ไม่ใช่ API เรามีคำอธิบายโดยละเอียดไว้ที่นี่
การใช้ API	เซิร์ฟเวอร์ KV มีการกำหนดเวลาหมดอายุในการตอบกลับภายในช่วงเวลาหนึ่งหรือไม่	ผู้ขายสามารถระบุช่อง "perBuyerCumulativeTimeouts" ในการกำหนดค่าการประมูล โดยระยะหมดเวลานี้รวมเวลาที่จำเป็นในการดึงข้อมูลสัญญาณการเสนอราคาที่เชื่อถือได้
เวลาในการตอบสนอง	ทีม Privacy Sandbox แก้ปัญหาเวลาในการตอบสนองอย่างไร	ดูกลยุทธ์ที่เรากำลังพัฒนาเพื่อรักษาเวลาในการตอบสนองให้อยู่ในขีดจำกัดที่ยอมรับได้ที่ที่นี่

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

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
การเพิ่มประสิทธิภาพแคมเปญด้วยตนเอง	ARA ไม่รองรับการเพิ่มประสิทธิภาพแคมเปญด้วยตนเอง	เราได้พูดคุยเกี่ยวกับสถานการณ์นี้กับเทคโนโลยีโฆษณาและแสดงวิธีใช้ ARA เพื่อรองรับการเพิ่มประสิทธิภาพแคมเปญด้วยตนเอง ARA สร้างขึ้นเพื่อให้ปรับแต่งเทคโนโลยีโฆษณาได้และมีความยืดหยุ่นในการแก้ปัญหา Use Case ต่างๆ ของเทคโนโลยีโฆษณา คําแนะนําบางส่วนที่ระบุไว้ ได้แก่ การใช้การกําหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นที่แตกต่างกัน และการใช้รายงานระดับเหตุการณ์กับรายงานสรุปเพื่อลดผลกระทบจากปัจจัยภายนอกและเพื่อให้บรรลุความต้องการในการเพิ่มประสิทธิภาพด้วยตนเองและแบบอัตโนมัติ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศในด้านการปรับแต่งและความยืดหยุ่นของการกำหนดค่า ARA
ประเภท Conversion	Google อนุญาตให้ใช้ Conversion ได้เพียง 8 ประเภทเท่านั้น	เราได้ติดตั้งใช้งาน การรายงานระดับเหตุการณ์แบบยืดหยุ่นส่วนใหญ่แล้ว ซึ่งช่วยให้นักเทคโนโลยีโฆษณามีความยืดหยุ่นมากขึ้นในแง่ของกรอบเวลาการรายงาน จํานวนรายงานการระบุแหล่งที่มา และข้อมูลทริกเกอร์บางส่วนที่สามารถใช้ ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาสามารถเลือกการกําหนดค่าที่อนุญาตให้วัด Conversion ประเภทต่างๆ ได้สูงสุด 32 ประเภท
ขีดจํากัดเหตุการณ์ของรายงานที่รวบรวมได้	เหตุการณ์ Conversion ขั้นต่ำ 20 รายการต่อรายงานที่รวบรวมได้นั้นใช้ไม่ได้กับผู้ลงโฆษณารายเล็กที่มีงบประมาณจํากัด	ไม่จำเป็นต้องมีเหตุการณ์ Conversion จำนวนขั้นต่ำต่อรายงานที่รวบรวมได้ นอกจากนี้ คุณยังทําการตัดสินใจด้านการออกแบบได้หลายอย่างเพื่อเพิ่มประสิทธิภาพรายงานที่รวบรวมได้สําหรับผู้ลงโฆษณารายเล็ก เช่น การเปลี่ยนโครงสร้างคีย์ / มิติข้อมูลที่ติดตาม การทดสอบ epsilon ระดับต่างๆ การทดสอบความถี่การแบ่งกลุ่มที่นานขึ้น และการทดสอบการจัดสรรงบประมาณการมีส่วนร่วมที่แตกต่างกันระหว่างเป้าหมายการวัดผล นอกจากนี้ เทคโนโลยีโฆษณาขนาดเล็กยังทดสอบการรวมรายงานระดับเหตุการณ์เข้ากับรายงานสรุปเพื่อลดผลกระทบจากปัจจัยภายนอกได้ด้วย
ข้อมูลแบบเรียลไทม์	การกีดกัน DSP ไม่ให้เข้าถึงข้อมูลแบบเรียลไทม์ (เช่น การคลิก เซสชัน และ Conversion) ซึ่ง DSP ใช้เพื่อปรับกลยุทธ์การเสนอราคาและทำให้แคมเปญมีประสิทธิภาพมากขึ้น ขัดต่อความมุ่งมั่นในการรักษาฟังก์ชันการทำงานที่มีอยู่	แม้จะใช้ ARA ก็ตาม การคลิกและเซสชันจะยังคงเป็นแบบเรียลไทม์ และ Conversion จะเป็นข้อมูลย้อนหลังเสมอแม้จะใช้ 3PC ก็ตาม
หัวข้อที่ขาดหายไป	ไม่มีข้อกําหนดในการเปิดตัวเหตุการณ์แบบยืดหยุ่นเต็มรูปแบบ ได้แก่ 1) ช่องสกุลเงิน และ 2) ช่อง orderID / TransactionID	ขณะนี้เราไม่มีแผนที่จะรองรับช่องสกุลเงินหรือช่องรหัสคำสั่งซื้อ / รหัสธุรกรรมในระดับเหตุการณ์แบบยืดหยุ่นทั้งหมด เนื่องจากมีวิธีดำเนินการนี้อยู่แล้วในการรายงานระดับเหตุการณ์ปัจจุบัน เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับช่องเหล่านี้ และจะพิจารณาอีกครั้งหากมีกรณีการใช้งานเพิ่มเติมที่ต้องใช้ช่องเหล่านี้ วิธีใช้การออกแบบปัจจุบันของ ARA เพื่อวัดข้อมูลประเภทสกุลเงินและรหัสคำสั่งซื้อ 1. จากความคิดเห็นที่ได้รับ สกุลเงินจะกำหนดโดยภูมิศาสตร์ของผู้ใช้ ซึ่งสามารถเพิ่มเป็นส่วนหนึ่งของ source_event_id เพื่อใช้เป็นวิธีระบุสกุลเงินที่ใช้ 2. จากความคิดเห็นที่ได้รับ ช่องรหัสคำสั่งซื้อจําเป็นต่อการตรวจสอบว่าระบบไม่ได้นับ Conversion และมูลค่าซ้ำโดยไม่ตั้งใจ ซึ่งทำได้โดยใช้คีย์การกรองข้อมูลที่ซ้ำกันออก
งบประมาณด้านความเป็นส่วนตัว	งบประมาณความเป็นส่วนตัวของ ARA จํากัดความสามารถในการวัดผลในหลายมิติข้อมูล	ARA ได้รับการออกแบบมาเพื่อให้นักเทคโนโลยีโฆษณาปรับแต่งการกําหนดค่า ARA ของตนเองให้ครอบคลุมสถานการณ์การระบุแหล่งที่มาที่หลากหลาย การออกแบบ ARA ปัจจุบันทำให้นักเทคโนโลยีโฆษณาต้องพิจารณาถึงข้อดีข้อเสียระหว่างมิติข้อมูลที่มีความสําคัญมากที่สุดในการวัดผลกับผลกระทบของสัญญาณรบกวนต่อข้อมูล การเพิ่มสัญญาณรบกวนลงในข้อมูลตามความละเอียดของมิติข้อมูลที่วัดเป็นสิ่งจําเป็นสําหรับความเป็นส่วนตัว เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศในด้านความสามารถในการวัดผลในมิติข้อมูลต่างๆ แต่จําเป็นต้องทําความเข้าใจกรณีการใช้งานที่ต้องใช้วิธีนี้
อัปเดตข้อกำหนด	แม้ว่า Google จะบอกว่าได้เปลี่ยนจากกรอบเวลาการรายงานเหตุการณ์แบบคงที่เป็นแบบยืดหยุ่นแล้ว แต่ข้อมูลนี้ยังไม่ปรากฏในข้อกําหนดทางเทคนิคของ Google ซึ่งปัจจุบันยังมีกรอบเวลาขั้นต่ำ 1 ชั่วโมง	ปัจจุบันการรายงานระดับเหตุการณ์ที่ยืดหยุ่นช่วยให้นักเทคโนโลยีโฆษณาเปลี่ยนจํานวนรายงานการระบุแหล่งที่มาต่อเหตุการณ์แหล่งที่มา ข้อมูลทริกเกอร์ และจํานวน/ระยะเวลาของกรอบเวลาการรายงานได้ ARA ยังคงมีกรอบเวลาการรายงานขั้นต่ำ 1 ชั่วโมงสำหรับรายงานระดับเหตุการณ์ ซึ่งจำเป็นต่อการรักษาความเป็นส่วนตัวและลดการโจมตีแบบสร้างประวัติขึ้นมาใหม่บางประเภท เนื่องจากรายงานสรุปรวมให้ข้อมูลแบบรวม เทคโนโลยีโฆษณาจึงเลือกรับรายงานแบบรวมได้ทันทีโดยไม่มีเวลาหน่วง หากจำเป็นสำหรับ Use Case ของตน
การออกแบบ API	ความกังวลว่าการลดข้อมูลในรายงาน Conversion และการเพิ่มสัญญาณรบกวนอาจส่งผลต่อระบบนิเวศมากกว่า Google	Google มุ่งมั่นที่จะออกแบบและใช้งานข้อเสนอ Privacy Sandbox ในลักษณะที่ไม่บิดเบือนการแข่งขันด้วยการให้สิทธิประโยชน์แก่ธุรกิจของ Google เอง และพิจารณาผลกระทบต่อการแข่งขันในการโฆษณาดิจิทัล รวมถึงผู้เผยแพร่โฆษณาและผู้ลงโฆษณาทุกขนาด
การแก้ไขการระบุแหล่งที่มา	ARA ไม่อนุญาตให้ผู้ให้บริการเทคโนโลยีควบคุมและยืนยันการระบุแหล่งที่มาที่ถูกต้อง	มีโซลูชันมากมายใน ARA ที่ให้การยืนยัน 1. ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาสามารถตรวจสอบได้ว่าลักษณะการทํางานของ ARA ตรงกับที่คาดไว้หรือไม่ – โค้ดฝั่งไคลเอ็นต์ของ ARA เป็นโอเพนซอร์ส – โค้ดฝั่งเซิร์ฟเวอร์ของ ARA ก็เป็นโอเพนซอร์สเช่นกัน และผู้ประสานงานจะตรวจสอบว่ามีเพียงบริการรวบรวมข้อมูลเวอร์ชันที่อนุญาตเท่านั้นที่สามารถถอดรหัสและประมวลผลรายงานที่รวบรวมได้ 2. Chrome มีไลบรารีการจําลองสําหรับเทคโนโลยีโฆษณาเพื่อยืนยันลักษณะการระบุแหล่งที่มา ซึ่งเทคโนโลยีโฆษณาสามารถทดสอบวิธีที่ ARA ระบุแหล่งที่มาในสภาพแวดล้อมจำลอง 3. ARA รองรับสัญญาณการแก้ไขข้อบกพร่องหลายรายการที่จะช่วยยืนยันว่าการประมวลผลที่คาดไว้อาจไม่เกิดขึ้นหรือไม่ และสาเหตุใด
(รายงานในไตรมาสก่อนหน้าด้วย) เสียงรบกวน	ความคิดเห็นว่าระดับของสัญญาณรบกวนสูงเกินไปและส่งผลต่อประโยชน์ของการรายงาน	เราได้พูดคุยกับผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาเกี่ยวกับความคิดเห็นนี้และสามารถระบุวิธีปรับแต่ง ARA ให้เหมาะกับกรณีการใช้งานได้ดียิ่งขึ้น แม้จะมีสัญญาณรบกวนก็ตาม เรามีเอกสารประกอบสําหรับนักพัฒนาซอฟต์แวร์ที่มีการตัดสินใจด้านการออกแบบและการปรับเปลี่ยนส่วนใหญ่ที่เราได้พูดคุยกับผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณา ARA ได้รับการออกแบบมาเพื่อให้ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาปรับแต่งการกําหนดค่า ARA ของตนเองเพื่อให้ครอบคลุมสถานการณ์การระบุแหล่งที่มาที่หลากหลาย แต่ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาจะต้องพิจารณาถึงข้อดีข้อเสียระหว่างมิติข้อมูลที่มีความสําคัญมากที่สุดในการวัดผลและผลกระทบของสัญญาณรบกวนต่อข้อมูล เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับผลกระทบของสัญญาณรบกวนจากระบบนิเวศ และสามารถให้คําแนะนําเพิ่มเติมเกี่ยวกับเครื่องมือ ARA ที่ใช้เพื่อเปลี่ยนผลกระทบของสัญญาณรบกวน
การระบุแหล่งที่มาข้ามโดเมน	วิธีติดตามการระบุแหล่งที่มาแบบข้ามโดเมน	เทคโนโลยีโฆษณาสามารถเปลี่ยนเส้นทางไปยัง URL การรายงานอื่นเพื่อแก้ปัญหา Use Case นี้ได้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศในด้านการออกแบบของ ARA
การปรับปรุง API	เปลี่ยนปัจจัยการขยายที่ใช้ในการบันทึกการระบุแหล่งที่มาสําหรับรายงานสรุป ARA เป็นประจํา	จากการสนทนาใน GitHub ดูเหมือนว่าการจัดการปัจจัยการปรับขนาดหลายรายการในบริการการรวมข้อมูลมีแนวโน้มที่จะเพิ่มระดับสัญญาณรบกวนลงในรายงานสรุปมากกว่าฟังก์ชันการทำงานปัจจุบัน เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับความจำเป็นในการใช้ปัจจัยการปรับขนาดเป็นส่วนหนึ่งของรายงานที่รวบรวมได้ แต่ต้องการชี้ให้เห็นถึงข้อเสียที่อาจเกิดขึ้นจากสัญญาณรบกวนเพิ่มขึ้น นอกจากนี้ เรายังประเมินด้วยว่าฟีเจอร์ ARA อื่นๆ ในอนาคตอาจช่วยแก้ปัญหา Use Case นี้ได้หรือไม่
การใช้ API	โอกาสในการรวมวิธีแชร์เหตุการณ์การระบุแหล่งที่มากับผู้เข้าร่วมทั้งหมด ซึ่งจะเป็นประโยชน์ต่อ SSP, DSP และอื่นๆ	เราวางแผนที่จะซิงค์กับเทคโนโลยีโฆษณาเพื่อทำความเข้าใจความคิดเห็นและข้อจำกัดที่พบได้ดียิ่งขึ้น
ปริมาณการเข้าชมทดสอบ	การเข้าชมทดสอบสําหรับโหมด B สําหรับ Chrome ทุกเวอร์ชันมีความเสถียรไหม	การรวมอยู่ในกลุ่มทดสอบจะไม่ได้รับผลกระทบจาก (ไม่ขึ้นอยู่กับ) การตั้งค่า Chrome
เอกสารประกอบ	รองรับ ARA สำหรับ Pixel	เราได้เผยแพร่ข้อมูลเกี่ยวกับวิธีรองรับกรณีการใช้งานนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การใช้ API	ARA อาจไม่ได้มาจากแหล่งที่มาที่ถูกต้องสำหรับผู้ขายบุคคลที่สามในแพลตฟอร์มอีคอมเมิร์ซ หาก Conversion ไม่ได้เกิดจากทัชพอยต์สุดท้าย	บริษัทสามารถใช้ตัวกรองเพื่อป้องกันไม่ให้มีการระบุแหล่งที่มาที่ไม่ถูกต้อง (เนื่องจากระบบจะไม่สร้างรายงาน Conversion) นอกจากนี้ เรายังกําลังพัฒนาข้อเสนอสําหรับการกรองก่อนการระบุแหล่งที่มาเพื่อช่วยใน Use Case นี้
การรองรับเบราว์เซอร์	เบราว์เซอร์อื่นจะรองรับ ARA ไหม	เรายินดีให้เบราว์เซอร์อื่นๆ นำ Privacy Sandbox API ไปใช้และยังคงหาเวลาพูดคุยเกี่ยวกับแนวทางของเราอย่างเปิดเผยใน W3C เราได้ระบุไว้อย่างชัดเจนว่าความสามารถในการทำงานร่วมกันเป็นเป้าหมายในการเปิดตัว ARA และการออกแบบ ARA ไม่ได้มีไว้สำหรับเบราว์เซอร์ใดเบราว์เซอร์หนึ่งโดยเฉพาะ โดยมีค่าที่ระบุโดยผู้ให้บริการที่ยืดหยุ่นสำหรับผู้ให้บริการที่มีจุดยืนด้านความเป็นส่วนตัวแตกต่างกัน เบราว์เซอร์อื่นๆ เลือกเองว่าจะจัดหาทางเลือกที่ใช้งานได้จริงสำหรับตัวระบุข้ามเว็บไซต์ที่รองรับระบบนิเวศดิจิทัลของเนื้อหาและบริการหรือไม่ เรายินดีที่ Microsoft Edge ระบุว่าจะรองรับ ARA
การใช้ API	ประเภทแหล่งที่มาที่คาดไว้สำหรับการลงทะเบียนแหล่งที่มา ARA สําหรับ registerAdBeacon/reportEvent (และบีคอนอัตโนมัติ navigation_start/commit) คืออะไร	ทั้งนี้ขึ้นอยู่กับว่าบีคอนเหล่านี้เป็นแบบอัตโนมัติหรือแบบกำหนดเอง - สงวนไว้* เหตุการณ์ (เช่น อัตโนมัติ) ต้องเป็นประเภทแหล่งที่มาของการนําทาง - เหตุการณ์ที่ทริกเกอร์ด้วยตนเองต้องเป็นประเภทแหล่งที่มาของเหตุการณ์
การใช้ API	ขีดจํากัดสูงสุด 20 รายงานที่รวบรวมได้ต่อแหล่งที่มาหมายถึงเหตุการณ์แหล่งที่มาแต่ละรายการใช่ไหม ขีดจํากัดเป็นแบบทั่วโลกหรือรายวัน มีแผนที่จะเพิ่มขีดจำกัดไหม	ขีดจํากัด 20 รายงานที่รวบรวมได้ต่อแหล่งข้อมูลคือขีดจํากัดทั่วโลกที่สามารถสร้างรายงานที่รวบรวมได้ 20 ฉบับสําหรับแต่ละแหล่ง ขีดจํากัดนี้กําหนดโดยเบราว์เซอร์และไม่สามารถกําหนดค่าได้ วัตถุประสงค์ของขีดจํากัดนี้คือเพื่อหลีกเลี่ยงการละเมิดการปกป้องรายงานการระบุแหล่งที่มาจริงด้วยรายงาน Null เราได้พูดคุยเรื่องนี้เพิ่มเติมที่นี่
การใช้ API	การสนับสนุนสําหรับการทำการตลาดทางอีเมลโดยใช้ ARA	ขณะนี้ยังไม่มีการสนับสนุนโดยตรงสำหรับกรณีการใช้งานนี้ภายใน ARA (หากคุณไม่ได้ควบคุมเว็บไซต์โฮสติ้งอีเมล) เรากำลังพูดคุยเรื่องนี้อยู่ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
Epsilon	ระบบจะกําหนดค่า epsilon สําหรับ Aggregate API เมื่อใด	เทคโนโลยีโฆษณาสามารถกําหนดค่า epsilon ปัจจุบันได้สูงสุดตามเกณฑ์ที่กำหนดไว้ล่วงหน้าโดย Privacy Sandbox (ปัจจุบันคือ 64) เราขอแนะนําให้ทดสอบค่า epsilon ต่างๆ และระบุจุดเปลี่ยนแปลงสําหรับกรณีการใช้งานของคุณเอง รวมถึงแสดงความคิดเห็น เราจะแจ้งให้นักเทคโนโลยีโฆษณาทราบล่วงหน้าก่อนที่จะมีการเปลี่ยนแปลงช่วงของค่า epsilon
การปรับปรุง API	รองรับกรณีการใช้งานที่ผู้ลงโฆษณาสามารถแทรกตัวระบุลงในฟิลด์ trigger_data เพื่อจับคู่กับข้อมูล CRM ภายนอกเพื่อให้ผู้ลงโฆษณายืนยันคุณภาพของ Conversion ได้	เรากำลังหารือเกี่ยวกับคำขอและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การใช้ API	วิธีจัดการ URL เปลี่ยนเส้นทางเป็น URL ปลายทาง	ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาจะทำอย่างใดอย่างหนึ่งต่อไปนี้ได้ 1. ใส่ URL ปลายทางสุดท้ายในช่องปลายทาง 2. ช่องปลายทางรองรับ URL ได้สูงสุด 3 รายการ ซึ่งช่วยให้คุณใส่ URL หลายรายการลงในช่องได้ ทั้ง 2 ตัวเลือกจะต้องทราบ URL ปลายทางสุดท้าย เราได้พูดคุยเรื่องนี้เพิ่มเติมที่นี่

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
กลไกการค้นพบคีย์	คำขอกลไกการค้นพบคีย์	เรามี ข้อเสนอสำหรับการค้นพบคีย์และยินดีรับ ความคิดเห็นจากระบบนิเวศเกี่ยวกับข้อเสนอนี้
การใช้ API	แผนงานสําหรับการสังเกตการณ์ในบริการรวมข้อมูล	เรากำลังตรวจสอบตัวเลือกต่างๆ เพื่อรองรับการสังเกตการณ์มากขึ้นและยินดีรับฟังความคิดเห็นจากระบบนิเวศที่นี่
การปรับปรุง API	ขอสิทธิ์ในการค้นหารายงานอีกครั้ง	บริการรวบรวมข้อมูลกําลังดําเนินการตามคําขอเสนอใหม่ ซึ่งเทคโนโลยีโฆษณาสามารถแยก epsilon ของแต่ละรายงานได้ วิธีนี้อาจทำให้เกิดสัญญาณรบกวนมากขึ้นต่อการค้นหาแต่ละครั้ง แต่จะช่วยให้เทคโนโลยีโฆษณาสามารถค้นหาอีกครั้งและรักษาความเป็นส่วนตัวได้
การปรับปรุง API	ต้องการเชื่อมโยงต้นทางหลายรายการกับรหัส AWS เดียวกัน	ตอนนี้บริการรวบรวมข้อมูลจะอนุญาตให้เริ่มต้นใช้งานเว็บไซต์หลายแห่งในบัญชีระบบคลาวด์เดียวกัน (Google Cloud หรือ AWS) ซึ่งจะช่วยให้นักเทคโนโลยีโฆษณาใช้ Enclave บริการรวบรวมข้อมูลเดียวกันในการประมวลผลรายงานจากหลายเว็บไซต์และหลายแหล่งที่มาจากเว็บไซต์เดียวกันได้
การใช้ API	เมื่อการรวมกลุ่มกลุ่มที่รวบรวมได้ไม่สําเร็จ ผู้ใช้ไม่แน่ใจว่างบประมาณถูกใช้ไปหรือไม่ และสามารถประมวลผลกลุ่มอีกครั้งได้หรือไม่ เมื่อบริการรวบรวมข้อมูลพบข้อผิดพลาดเกี่ยวกับงบประมาณสำหรับรายงานที่ซ้ำกัน รายงานที่เหลือจะหายไป วิธีลดการสูญเสียนี้	ในกรณีทั่วไป หากงานทั้งงานดำเนินการไม่สำเร็จ ระบบจะไม่ใช้งบประมาณ ในกรณีที่เกิดความล้มเหลวซึ่งเกิดขึ้นไม่บ่อยนักและมีการใช้งบประมาณ เทคโนโลยีโฆษณาจะขอการคืนเงินงบประมาณได้ หากเทคโนโลยีโฆษณาพบความล้มเหลวของงานบ่อยครั้งพร้อมกับข้อผิดพลาดว่างบประมาณหมดแล้ว ก็ควรตรวจสอบกลยุทธ์การแบ่งกลุ่ม ดูวิธีการจัดกลุ่มอย่างถูกต้องและหลีกเลี่ยงรายงานที่ซ้ำกัน รวมถึงข้อผิดพลาดได้ที่นี่ เรายินดีรับฟังความคิดเห็นเกี่ยวกับการกู้คืนงบประมาณที่นี่
การใช้ API	การใช้ Private Aggregation API กับทริกเกอร์ที่อธิบายไว้ที่นี่จะสร้างรายงานที่รวบรวมได้สําหรับการประมูลทุกรายการ บริการรวบรวมข้อมูลมีความสามารถในการปรับขนาดอย่างไร	บริการรวบรวมข้อมูลเองไม่ได้จำกัดจำนวนคีย์หรือรายงานสูงสุดในชุด แต่ปัจจุบันระบบยังไม่รองรับรายงาน 10^14 รายการและคีย์ 10^12 รายการเนื่องจากต้องใช้หน่วยความจำ คําแนะนําในการปรับขนาดจะระบุช่วงที่เราได้ทดสอบและแนะนําเพื่อให้ได้ประสิทธิภาพที่ดีที่สุดตามภาระงานที่คาดไว้และประเภทอินสแตนซ์ VM ของคลาวด์ที่รองรับ
การประมวลผลข้อมูล	หากข้อมูลที่เข้ารหัสมีข้อมูลส่วนบุคคล การจัดเตรียมทางกฎหมายในการให้ข้อมูลที่เข้ารหัสแก่บริการรวบรวมข้อมูลเป็นอย่างไร โปรดแจ้งว่าผู้ประสานงานจะเข้าถึงข้อมูลที่เข้ารหัสไม่ได้หรือไม่	บริการรวบรวมข้อมูลจะไม่แชร์ข้อมูลผู้ใช้ / ข้อมูลที่เข้ารหัสกับผู้ประสานงาน บริการรวมข้อมูลใช้ผู้ประสานงานสำหรับการจัดการคีย์และการบัญชี ดูรายละเอียดบางส่วนเกี่ยวกับผู้ประสานงานได้ที่นี่ สําหรับการบัญชี บริการรวบรวมข้อมูลจะแชร์เฉพาะรหัสที่แชร์และต้นทางการรายงานกับ PBS เพื่อใช้งบประมาณ เมื่อเปิดตัวเว็บไซต์หลายแห่ง เราจะแทนที่ต้นทางด้วยเว็บไซต์ โปรดทราบว่าบริการรวบรวมข้อมูลทํางานใน TEE ซึ่งเป็นที่เดียวที่จะสามารถถอดรหัสรายงานจากไคลเอ็นต์ได้ โค้ดที่ทำงานใน TEE เป็นโอเพนซอร์สและได้รับการตรวจสอบโดยบุคคลภายนอกตามที่ระบุไว้ที่นี่

Private Aggregation API

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
การใช้ API	ความสามารถของผู้ขายคอมโพเนนต์ในการส่งรายงานไปยังเซิร์ฟเวอร์การรวมข้อมูลหลายเซิร์ฟเวอร์ภายใน TEE	สถานะปัจจุบันของ Private Aggregation API ไม่รองรับฟีเจอร์นี้ เราได้พูดคุยเกี่ยวกับปัญหานี้เพิ่มเติมที่นี่
เอกสารประกอบ	ค่า epsilon ที่ใช้ในการทดลองของ Google คืออะไร	สําหรับ Private Aggregation API ค่า ε ที่ระบุในการค้นหาบริการรวบรวมข้อมูลจะสอดคล้องกับงบประมาณการมีส่วนร่วม L1 ของ 2^16 ซึ่งบังคับใช้ทุก 10 นาที นอกจากนี้ยังมีงบประมาณการมีส่วนร่วม L1 "สำรอง" เท่ากับ 2^20 ซึ่งบังคับใช้แบบต่อเนื่องตลอด 24 ชั่วโมง ดังนั้นพารามิเตอร์ความเป็นส่วนตัวจึงเท่ากับ ε ในช่วง 10 นาที และ 16ε ในช่วง 24 ชั่วโมง (แทนที่จะเป็น 144ε) ปัจจุบันบริการการรวมข้อมูลรองรับช่วง ε สำหรับการทดสอบ (สูงสุด 64) เพื่อให้ทดลองใช้กลยุทธ์การรวมข้อมูลที่แตกต่างกันและแสดงความคิดเห็นเกี่ยวกับประโยชน์ของระบบด้วยพารามิเตอร์ความเป็นส่วนตัวที่แตกต่างกันสําหรับการรวมข้อมูลส่วนตัวและ API อื่นๆ เราวางแผนที่จะกลับมาดูค่า epsilon สูงสุดที่อนุญาตเมื่อเวลาผ่านไปเมื่อได้รับความคิดเห็นจากผู้ทดสอบและเพิ่มฟีเจอร์ที่ช่วยให้การใช้งบประมาณด้านความเป็นส่วนตัวมีประสิทธิภาพมากขึ้น

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

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

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

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
รหัสการแก้ปัญหา	Privacy Sandbox ต้องสื่อสารกับสื่อมากขึ้นว่ารหัสการแก้ปัญหาซึ่งมักสร้างขึ้นจาก IP นั้นไม่ยั่งยืนสำหรับผู้ลงโฆษณา	Privacy Sandbox ชี้แจงอย่างชัดเจนว่าเรามุ่งลดการติดตามข้ามเว็บไซต์ โครงการริเริ่มสาธารณะของเราซึ่งครอบคลุมมากกว่าคุกกี้จะเผยแพร่ทั้งบน privacysandbox.com และ GitHub เรามุ่งมั่นที่จะลดการติดตามข้ามเว็บไซต์ ซึ่งรวมถึงการติดตามที่อิงตามที่อยู่ IP อย่างไรก็ตาม ท้ายที่สุดแล้ว เว็บไซต์แต่ละแห่งจะเป็นผู้ตัดสินใจว่าจะเปิดใช้การติดตามข้ามเว็บไซต์ในเชิงรุกหรือไม่ ในยุคที่การตรวจสอบการปฏิบัติตามข้อกำหนดมีมากขึ้น แต่ละบริษัทควรทำความเข้าใจแนวทางปฏิบัติของผู้ให้บริการ
Chromecast	การป้องกัน IP จะส่งผลต่อ Chromecast หรืออุปกรณ์ Chrome เครื่องอื่นๆ ไหม	ปัจจุบันยังไม่มีแผนที่จะใช้การคุ้มครองทรัพย์สินทางปัญญากับอุปกรณ์ Chromecast
รายการการปกป้อง IP	เราจะเผยแพร่รายชื่อบุคคลที่สามที่ระบุว่าอาจใช้ที่อยู่ IP สำหรับการติดตามข้ามเว็บไซต์ทั่วทั้งเว็บไหม	เราจะเผยแพร่รายการเมื่อสรุปแล้ว ตามที่ได้แจ้งไว้ที่นี่

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
ข้อยกเว้นการลงชื่อเพียงครั้งเดียว (SSO)	การลดการติดตามการตีกลับ (BTM) จะยืนยัน Use Case ของ SSO เพื่อรับการยกเว้นได้อย่างไร	วิธีการเดาทางของ Chrome จะปิดใช้ BTM โปรดดูรายละเอียดในคำอธิบาย
ช่วงทดลองใช้ฟีเจอร์ที่เลิกใช้งาน	มีการเปิดใช้ BTM สําหรับเว็บไซต์ในการทดลองการเลิกใช้งาน 3PC หรือไม่	ไม่ BTM จะยึดตามข้อยกเว้นคุกกี้ที่สร้างขึ้นจากการทดลองเลิกใช้งานตามที่ได้อธิบายไว้ที่นี่

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

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

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

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

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
คำขอฟีเจอร์	ระบบจะอนุญาตให้เข้าถึง CHIP และ / หรือการแบ่งพาร์ติชันพื้นที่เก็บข้อมูลใน RWS โดยอัตโนมัติโดยไม่ต้องใช้ Storage Access API หรือมีการโต้ตอบกับผู้ใช้	เรากำลังพิจารณาประโยชน์และความเป็นไปได้ของฟีเจอร์ที่อาจทํางานนี้ ข้อควรพิจารณาอย่างหนึ่งคือช่องโหว่ที่อาจเกิดขึ้นในความสามารถในการทำงานร่วมกันข้ามเบราว์เซอร์ ซึ่ง RWS จัดการโดย ใช้ประโยชน์จาก Storage Access API ปัจจุบันยังไม่มีฟังก์ชันการทำงานที่เทียบเท่าซึ่งรองรับในเบราว์เซอร์อื่นๆ เราขอแนะนำให้นักพัฒนาแอปส่งกรณีการใช้งานเกี่ยวกับปัญหานี้เพื่ออำนวยความสะดวกในการพูดคุยที่นี่
การนำชุดที่ไม่เป็นไปตามข้อกำหนดออก	กระบวนการนำชุดที่ไม่เป็นไปตามข้อกำหนดออกจากที่เก็บข้อมูลเป็นอย่างไร	เรากําลังกําหนดกระบวนการสําหรับการดำเนินการนี้ และจะแชร์ข้อมูลอัปเดตทันทีที่มี
กระบวนการบังคับใช้	บทบาทของ Google ในกระบวนการบังคับใช้ RWS นั้นไม่ชัดเจน	เนื่องจาก RWS เป็นโปรเจ็กต์ต่อเนื่องและเรายังได้รับข้อมูลใหม่อย่างต่อเนื่อง เราจึงยังคงพัฒนาแง่มุมต่างๆ ของกระบวนการและเกณฑ์ของเรา เราเห็นด้วยว่าหลักเกณฑ์การส่งข้อมูลควรระบุข้อกำหนดในการส่งข้อมูลอย่างครบถ้วน และเราจะเพิ่มรายละเอียดลงในหลักเกณฑ์การส่งข้อมูลในอนาคตเพื่อหลีกเลี่ยงความคลุมเครือและความสับสนเพิ่มเติม เราตั้งใจให้กระบวนการส่งข้อมูลเป็นกระบวนการทางเทคนิคมากที่สุดเท่าที่จะเป็นไปได้ เพื่อที่เราจะได้ลดการมีส่วนร่วมของเจ้าหน้าที่และอาศัยการตรวจสอบอัตโนมัติโดยสมบูรณ์ PR เช่นนี้จำเป็นต้องมีการจัดการโดยเจ้าหน้าที่มากขึ้นเนื่องจากมีพฤติกรรมที่เราคาดไม่ถึง แต่จะช่วยให้เราระบุขอบเขตเพิ่มเติมสำหรับการทํางานอัตโนมัติและวิธีแก้ไขหลักเกณฑ์เพื่อหลีกเลี่ยงปัญหาเหล่านี้ในอนาคตได้
การแชร์ข้อมูล	คำขอฟีเจอร์ที่อนุญาตให้เจ้าของโดเมนระบุได้ว่าต้องการให้บุคคลที่สามแชร์ข้อมูล RWS ด้วย โดยได้รับความยินยอมจากผู้ใช้	ฟังก์ชันการทำงานที่ขอมีให้บริการผ่าน API เช่น FedCM และ Storage Access API ที่เปิดใช้การเข้าถึงข้อมูลประจำตัวที่ตรวจสอบสิทธิ์แล้วหลังจากที่ผู้ใช้ยอมรับข้อความแจ้งสิทธิ์ เรายินดีรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับกรณีการใช้งานที่เฉพาะเจาะจงซึ่งผู้ใช้เชื่อว่าเป็นไปไม่ได้
วิธีการจัดเก็บข้อมูลอื่นๆ	ระบบจะตีความข้อมูลที่บันทึกไว้ในพื้นที่เก็บข้อมูลในเครื่องหรือพื้นที่เก็บข้อมูลเซสชันเป็น 3PC ด้วยไหม	พื้นที่เก็บข้อมูลในเครื่อง พื้นที่เก็บข้อมูลเซสชัน และพื้นที่เก็บข้อมูลรูปแบบอื่นๆ ที่ไม่ใช่คุกกี้เมื่อใช้ในบริบทของบุคคลที่สามได้รับการแบ่งพาร์ติชันใน Chrome ตั้งแต่เวอร์ชัน 115 ดูรายละเอียดเพิ่มเติมได้ในบล็อกโพสต์นี้
ขีดจํากัดชุดที่เชื่อมโยง	จะเกิดอะไรขึ้นกับองค์กรที่ส่งโดเมนมากกว่า 5 รายการ แม้ว่าจะมี "เว็บไซต์ที่เชื่อมโยงได้สูงสุด 5 รายการ"	ระบบจะยอมรับชุดเหล่านี้ผ่านกระบวนการของ GitHub แต่เบราว์เซอร์ (Chrome) จะใช้กฎการให้สิทธิ์ Storage Access API โดยอัตโนมัติกับโดเมน 5 โดเมนแรกเท่านั้น และจะละเว้นโดเมนที่เหลือ ตามที่อธิบายไว้ที่นี่
find_robots_txt	การตรวจสอบ find_robots_txt ไม่ทำงานกับการเปลี่ยนเส้นทาง	เราได้ส่งการแก้ไขเพื่อแก้ปัญหานี้ที่นี่
ท่าทางสัมผัสของผู้ใช้	นำข้อกำหนดเกี่ยวกับท่าทางสัมผัสของผู้ใช้สำหรับ accessStorage() ออก	ข้อกําหนดนี้จัดทำขึ้นตามการออกแบบที่คล้ายกันซึ่งมีอยู่ในเบราว์เซอร์หลักทั้งหมดสําหรับ requestStorageAccess API เรายินดีรับฟังความคิดเห็นและกรณีการใช้งานเพิ่มเติมในปัญหา GitHub นี้เพื่อช่วยเราจัดลําดับความสําคัญของคําขอนี้ และเปิดใช้การสนทนาข้ามเบราว์เซอร์
ท่าทางสัมผัสของผู้ใช้	ผู้ใช้ต้องทำการจับคู่ข้อมูลเพื่อมอบสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลของบุคคลที่สามหลังจาก Chrome หรือระบบปฏิบัติการรีสตาร์ทหรือไม่	ใช่ แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศเกี่ยวกับการเปลี่ยนแปลงลักษณะการทำงานนี้หรือไม่ที่นี่

Fenced Frames API

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
adComponent	ไม่มีเอกสารประกอบและความยืดหยุ่นในการใช้ AdComponents กับเฟรมที่มีการกำหนดขอบเขต	เราต้องการแชร์เอกสารประกอบเพิ่มเติมเกี่ยวกับกรณีการใช้งานนี้ นอกจากนี้ ระบบยังรองรับคอมโพเนนต์โฆษณาในเฟรมที่มีการกำหนดเขตโดยใช้ getNestedConfigs() ซึ่งมีอยู่ในข้อกําหนดที่นี่
(รายงานในไตรมาสก่อนหน้าด้วย) แสดงผล adComponent	ขอตัวอย่างโค้ดเกี่ยวกับวิธีแสดงผล adComponents ในเฟรมที่มีรั้วล้อม	เรากำลังเตรียมแชร์โค้ดตัวอย่างที่นี่
การยืนยันโฆษณาของบุคคลที่สาม	บทบาทของการยืนยันโฆษณาของบุคคลที่สามในบริบทของเฟรมที่มีรั้วล้อมต้องมีรายละเอียดเพิ่มเติม โดยเฉพาะเกี่ยวกับความปลอดภัยตามบริบท/ความปลอดภัยของแบรนด์	ปัจจุบันการรายงานโฆษณาเฟรมที่มีการกำหนดขอบเขตอนุญาตให้ DSP ส่งข้อมูลระดับเหตุการณ์การแสดงผลและราคาเสนอไปยังผู้ตรวจสอบโฆษณาบุคคลที่สามสําหรับการตรวจสอบความปลอดภัยของแบรนด์และการเรียกเก็บเงินหลังการแสดงผล
โฆษณาที่ขยายได้	คำขอรองรับโฆษณาที่ขยายได้	หากโฆษณาต้องสลับระหว่าง 2 ขนาดที่มีสัดส่วนการแสดงผลเดียวกัน และไม่มีความแตกต่างด้านฟังก์ชันการทำงานระหว่าง 2 ขนาด (มีแค่ขนาดเท่านั้น) ผู้ฝังโฆษณาสามารถปรับขนาดเฟรมที่มีรั้วล้อมด้วยขนาดโฆษณาที่ 2 และเบราว์เซอร์จะปรับขนาดองค์ประกอบเฟรมที่มีรั้วล้อมตามความเหมาะสม
(รายงานไว้แล้วในไตรมาสก่อนหน้า) การรองรับพื้นที่โฆษณาวิดีโอและเนทีฟ	เฟรมที่มีขอบเขตรองรับพื้นที่โฆษณาวิดีโอและเนทีฟไหม	คำตอบของเราคล้ายกับในไตรมาสก่อนหน้า นั่นคือ PA API รองรับการแสดงผลวิดีโอโดยใช้กลไกที่อาศัย iframe อย่างไรก็ตาม เรายังไม่ได้ออกแบบโซลูชันสำหรับการแสดงผลวิดีโอและโฆษณาเนทีฟที่เข้ากันได้กับเฟรมที่มีรั้ว ซึ่งเป็นหนึ่งในเหตุผลที่เราตัดสินใจเลื่อนการบังคับใช้เฟรมที่มีรั้วออกไปเป็นปี 2026 ซึ่งหมายความว่าหากพาร์ทเนอร์ตัดสินใจบังคับใช้เฟรมที่มีการกำหนดขอบเขตในตอนนี้ พาร์ทเนอร์รายดังกล่าวจะไม่สามารถรองรับวิดีโอและเนทีฟ
คณะกรรมการที่ปรึกษา	ขอให้สร้างคณะกรรมการที่ปรึกษาของผู้ให้บริการโฆษณาเนทีฟเพื่อให้แน่ใจว่าการใช้งานเฟรมที่มีรั้วรอบขอบชิดเป็นไปตามมาตรฐานอุตสาหกรรม	คุณไม่จำเป็นต้องใช้เฟรมที่มีการกำหนดขอบเขตใน PA API ก่อนปี 2026 ระยะเวลาที่เพิ่มขึ้นนี้จะช่วยให้เราทำงานร่วมกับอุตสาหกรรมต่อไปเพื่อออกแบบและติดตั้งใช้งานการรองรับกรณีการใช้งานที่สำคัญที่หลากหลายมากขึ้น เราได้แจ้งไว้ก่อนหน้านี้ว่าเราจะพัฒนาเฟรมที่มีการกำหนดขอบเขตก่อนถึงกำหนดเวลา เพื่อรักษาการรองรับวิดีโอและโฆษณาเนทีฟด้วย PA API ตามความมุ่งมั่นของเรา เราจะมีส่วนร่วมและแจ้ง CMA เกี่ยวกับการเปลี่ยนแปลงดังกล่าว และจะมีส่วนร่วมกับความคิดเห็นจากระบบนิเวศต่อไปก่อนที่จะกำหนดให้ใช้เฟรมที่มีการกำหนดเขต รูปแบบการมีส่วนร่วมในระบบนิเวศของเราที่ W3C และองค์กรมาตรฐานโฆษณาอย่าง IAB Tech Lab ช่วยให้ผู้เชี่ยวชาญในอุตสาหกรรมทุกประเภทสามารถให้คำแนะนำเกี่ยวกับการออกแบบได้ก่อนที่จะมีการใช้งาน
(รายงานในไตรมาสก่อนหน้าด้วย) ความแตกต่างของขนาดในแพลตฟอร์มต่างๆ	รายงานว่าขนาดของเนื้อหาที่แสดงในเฟรมที่มีการกำหนดขอบเขตนั้นแตกต่างกันระหว่างเดสก์ท็อปกับสมาร์ทโฟน	นี่เป็นปัญหา Chromium ที่ทราบอยู่แล้วและเรากำลังตรวจสอบอยู่ เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การปรับปรุง API	ข้อกําหนดของเฟรมที่มีรั้วถูกเลื่อนออกไปเป็นปี 2025 เพื่อให้รองรับโฆษณาเนทีฟใน Privacy Sandbox ใช่ไหม	ตามที่ได้แจ้งไว้ในประกาศสาธารณะเกี่ยวกับการบังคับใช้เฟรมที่มีการกำหนดขอบเขตภายในปี 2026 เราได้ทราบถึง "ความพยายามอย่างมากในการรองรับ" เฟรมที่มีการกำหนดขอบเขตในวงกว้าง แน่นอนว่าหนึ่งในนั้นคือโฆษณาเนทีฟ แต่ไม่ใช่ปัจจัยเดียว โดยมีจุดประสงค์เพื่อให้เวลาเพิ่มเติมเพื่อให้ระบบนิเวศพร้อมรองรับ Use Case หลักๆ ซึ่งรวมถึงแต่ไม่จํากัดเพียงโฆษณาเนทีฟ

Shared Storage API

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
ประสิทธิภาพ	เวลาที่ระบบจะแสดงผลพื้นที่เก็บข้อมูลที่แชร์นอก Worklet ดูเหมือนว่าจะขึ้นอยู่กับกิจกรรมใน Worklet	เรากำลังพูดคุยเกี่ยวกับผลการทดสอบนี้ที่นี่
การนําไปใช้ในวงกว้าง	พื้นที่เก็บข้อมูลที่ใช้ร่วมกันควรเป็นมาตรฐานทั่วทั้งอุตสาหกรรมที่ใช้ได้กับเบราว์เซอร์ต่างๆ	เรายินดีรับฟังและรับทราบความคิดเห็นนี้ Chrome จะยังคงมีส่วนร่วมในฟอรัม W3C รวมถึง WICG เพื่อสนับสนุนข้อเสนอนี้ต่อไป รวบรวมความคิดเห็น และกระตุ้นให้เกิดการนำไปใช้งาน
Worklet การเสนอราคา	เป็นไปได้ไหมที่จะอ่านจากพื้นที่เก็บข้อมูลที่ใช้ร่วมกันภายใน generateBid (ซึ่งทํางานอยู่ในเวิร์กเลตอยู่แล้ว) เพื่อใช้ตรรกะการตัดสินโฆษณา / ธุรกิจ (เช่น การจำกัดความถี่) โดยอิงตามข้อมูลข้ามเว็บไซต์และเลือกโฆษณาชุดย่อย	ไม่ได้ ไม่สามารถอ่านจากพื้นที่เก็บข้อมูลที่แชร์ภายในชิ้นงานการเสนอราคา

CHIPS

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
ความจุของพาร์ติชัน	ชี้แจงลักษณะการทำงานเมื่อใช้พื้นที่เก็บข้อมูลของพาร์ติชันเกินขีดจำกัด	เมื่อถึงขีดจํากัด ระบบจะนําคุกกี้ที่เก่าที่สุดออกจากคุกกี้ที่เข้าถึงล่าสุดเพื่อเพิ่มพื้นที่ว่างในหน่วยความจําจนกว่าจะไม่เกินขีดจํากัด นักพัฒนาแอปจะเห็นส่วนหัวคุกกี้ที่อัปเดตแล้วในคำขอที่ตามมา
สิทธิ์เข้าถึง iFrame ของบุคคลที่สาม	เนื้อหา iFrame ของบุคคลที่สามที่ฝังไว้ซึ่งเปิดแท็บ/หน้าต่างใหม่ไปยังเว็บไซต์ของบุคคลที่สามเดียวกันควรมีสิทธิ์เข้าถึงคุกกี้ที่มีการแบ่งพาร์ติชันเดียวกันกับที่เปิด	เรากำลังหารือเกี่ยวกับกรณีการใช้งานนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศที่นี่
คุกกี้ที่ซ้ำกัน	หากมีคุกกี้ที่มีการแบ่งพาร์ติชันและคุกกี้ที่ไม่ได้แบ่งพาร์ติชันซึ่งมีชื่อเดียวกัน เบราว์เซอร์จะเลือกส่งค่าคีย์ใด	เมื่อมีคุกกี้ 2 รายการที่ใช้ชื่อเดียวกัน (1 รายการมีการแบ่งพาร์ติชันและอีกรายการไม่มี) คุณจะได้รับคุกกี้ทั้ง 2 รายการ แต่ไม่สามารถแยกแยะได้ว่าคุกกี้ใดเป็นคุกกี้ใด คุณสามารถดูข้อกำหนด RFC เกี่ยวกับเรื่องนี้ได้ที่นี่ ซึ่งอธิบายว่าไม่ควรใช้ลําดับการส่งคุกกี้
คำขอฟีเจอร์	เลือกใช้คุกกี้ที่แบ่งพาร์ติชันตามต้นทาง	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศที่นี่

FedCM

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

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

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

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