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

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

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

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

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

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

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

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

อาร์เอ

Attribution Reporting API

CHIPS

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

DSP

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

FedCM

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

FPS

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

IAB

Interactive Advertising Bureau

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

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

IETF

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

อินนิ่ง

ที่อยู่ Internet Protocol

openRTB

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

OT

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

API ของ PAT

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

PatCG

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

RP

ฝ่ายอ้างอิง

RWS

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

SSP

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

TEE

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

UA

สตริง User Agent

UA-CH

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

W3C

World Wide Web Consortium

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

การตาบอด IP โดยเจตนา

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

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
การกำกับดูแล	ความสนใจในช่วงแสดงความคิดเห็นสาธารณะเกี่ยวกับการปรับปรุงการกำกับดูแล Privacy Sandbox	เรายินดีรับฟังความคิดเห็นของผู้มีส่วนเกี่ยวข้องที่สมเหตุสมผลเกี่ยวกับการพัฒนาที่สำคัญเกี่ยวกับ Privacy Sandbox รวมถึงการกำกับดูแล Privacy Sandbox ในอนาคต
การทดสอบ	ช่วงการทดสอบเพิ่มเติมสำหรับ 3PCD นอกเหนือจากการทดสอบที่อำนวยความสะดวกโดย Chrome 1% ในปัจจุบัน	เราไม่ตั้งใจที่จะเสนอการทดสอบที่อำนวยความสะดวกโดย Chrome นอกเหนือจากการเข้าชม Chrome 1% ในปัจจุบันที่เปิดใช้มาตั้งแต่ต้นเดือนมกราคม
เว็บไปยังแอป	3PCD ในอุปกรณ์เคลื่อนที่ไม่ควรเกิดขึ้นก่อนที่จะบรรลุการทำงานร่วมกันอย่างเต็มรูปแบบระหว่างเว็บและแอป	เราเข้าใจดีว่าการสนับสนุนความสามารถในการทำงานร่วมกันของแอปและเว็บเป็นเรื่องน่ายินดี และได้เปิดตัวการวัดการระบุแหล่งที่มาข้ามแอปและเว็บแล้ว และกําลังพิจารณาโซลูชันการกำหนดเป้าหมายจากเว็บไปยังแอป อย่างไรก็ตาม เราไม่มีแผนที่จะเลื่อนเวลา 3PCD ในเว็บบนอุปกรณ์เคลื่อนที่ เราไม่มีเป้าหมายครอบคลุม 100% เมื่อ 3PCD สิ้นสุดลง อย่างไรก็ตาม เราคาดหวังว่าใน Android สำหรับการวัดผลแบบข้ามแอปและเว็บจะมีความเข้ากันได้สูงพอสมควรเมื่อใช้ 3PCD และจะเพิ่มขึ้นเมื่อเวลาผ่านไปเมื่อผู้ใช้อัปเดตโทรศัพท์
บทบาทของเบราว์เซอร์	ดูเหมือนว่า Chrome จะสวมบทบาทเซิร์ฟเวอร์โฆษณาหรือ SSP	Chrome ไม่ได้สวมบทบาทเซิร์ฟเวอร์โฆษณาหรือ SSP PA API ทำให้ Chrome ให้บริการคอนเทนเนอร์สำหรับเซิร์ฟเวอร์โฆษณา, SSP, DSP และเทคโนโลยีโฆษณาอื่นๆ เพื่อนำตรรกะการเสนอราคาและการให้คะแนนมาใช้เอง
คำแนะนำสำหรับกรณีการใช้งาน	คำแนะนำที่ชัดเจนขึ้นเกี่ยวกับกรณีการใช้งานที่ Privacy Sandbox API จะรองรับ	ในช่วงต้นของโปรเจ็กต์ Privacy Sandbox เอกสารสำหรับนักพัฒนาซอฟต์แวร์มุ่งเน้นที่การนำนักพัฒนาซอฟต์แวร์เข้าสู่การอภิปรายและขั้นตอนการแสดงความคิดเห็นสำหรับข้อเสนอทั้งหมดเป็นหลัก ซึ่งหมายความว่าโดยทั่วไปแล้วเนื้อหาจะมีโครงสร้างที่เกี่ยวข้องกับการทำความเข้าใจแรงจูงใจและแนวคิดเบื้องหลังโปรเจ็กต์ ตามด้วยรายละเอียดการพัฒนาและการทดสอบในช่วงแรกสำหรับข้อเสนอแต่ละรายการ วิธีนี้มีประสิทธิภาพในการสร้างการทำงานร่วมกันในระบบนิเวศจริงในการพัฒนาข้อเสนอ แต่เมื่อ API ต่างๆ พัฒนาไปสู่เวอร์ชันสำหรับผู้ใช้ทั่วไปแล้ว ก็มีกลุ่มเป้าหมายใหม่ๆ ที่ตั้งใจจะสร้าง API ขึ้นมาแทนที่จะนำไปพัฒนาในส่วนสำคัญของการพัฒนาพื้นฐาน เมื่อเร็วๆ นี้เราได้อัปเดตการไปยังส่วนต่างๆ ของ Taskoration Sandbox เกี่ยวกับความเป็นส่วนตัวของ IAB.com เมื่อเร็วๆ นี้ และได้อัปเดตการไปยังส่วนต่างๆ ของ Taskor.google.com สำหรับ Taskor.com ด้วย เราจะยังเดินหน้านำเสนอแนวทางปฏิบัติแบบอิงตามกรณีการใช้งานเพื่อจัดทำเอกสารต่อไป
สภาพแวดล้อมการพัฒนาในท้องถิ่น	เราจะพัฒนาและทดสอบฟรอนท์เอนด์ภายใน 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 ง่ายขึ้น ตัวอย่างเช่น การอัปเดตการแทนที่มาโคร (กล่าวถึง ที่นี่) ซึ่งเราวางแผนไว้ว่าจะแก้ไขตามความคิดเห็นเกี่ยวกับกรณีการใช้งานด้านความปลอดภัยของแบรนด์ของเครื่องมือตรวจสอบโฆษณาของบุคคลที่สาม ก็จะช่วยแก้ไขปัญหาในกรณีการใช้งานวิดีโอ ซึ่งผู้ซื้อกำลังมองหามาโครผู้ขายที่จะใช้ในการแสดงผล การพูดคุยส่วนใหญ่จนถึงปัจจุบันมุ่งเน้นที่การแสดงโฆษณาวิดีโอ 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 ก่อนเวลาสิ้นสุดของ Standstill
กรณีการใช้งานที่ไม่รองรับ	ปัจจุบันไม่ได้พิจารณา Use Case ของ DSP แบบบริการตนเอง	มี DSP แบบบริการตนเองหลายแห่งที่แสดงความคิดเห็นแบบสาธารณะเกี่ยวกับ API เป็นประจำ DSP เหล่านี้หลายแห่งซึ่งให้ความคิดเห็นต่อสาธารณะเป็นประจำได้แสดงตัวว่าเป็นผู้ทดสอบด้วย นอกจากนี้ Chrome ยังมีส่วนร่วมในหัวข้อ DSP แบบบริการตนเองทั่วไป เช่น เซิร์ฟเวอร์โฆษณาวิดีโอและของบุคคลที่สาม การเรียก API ของ PA รายสัปดาห์ล่าสุดได้ครอบคลุมหัวข้อต่อไปนี้แล้ว
ช่วงทดลองใช้จากต้นทาง	คำขอ OT สำหรับเว็บไซต์ที่ต้องการเพิ่มจำนวนขึ้นและทดสอบการครอบคลุมของ 3PCD	Chrome กำลังพัฒนา OT ของบุคคลที่หนึ่ง ซึ่งจะอนุญาตให้ต้นทางเลือกใช้ลักษณะการยกเลิกการใช้งาน 3PC ได้ ต้นทางระดับบนสุดที่ลงทะเบียนสำหรับช่วงทดลองใช้นี้และโทเค็นการทำให้ใช้งานได้จะถูกบล็อก 3PC ราวกับว่าอุปกรณ์ของผู้ใช้เปิดใช้การป้องกันการติดตาม OT นี้จะมอบโอกาสอันดีให้เว็บไซต์ต่างๆ ดำเนินการทดสอบทางเลือกในระยะยาวสำหรับ 3PC ในวงกว้างขึ้น ก่อนช่วงการยกเลิกการใช้งาน 3PC ที่จะเกิดขึ้นในท้ายที่สุดหลังการปรึกษากับ CMA เรากำลังดำเนินการกำหนดระยะเวลาสิ้นสุดสำหรับการเปิดตัว OT
รายงาน IAB Tech Lab	ความคิดเห็นเกี่ยวกับ Privacy Sandbox ที่ได้รับจากรายงาน IAB Tech Lab	เราได้ตอบกลับรายงานของ IAB Tech Lab โดยละเอียดที่นี่ นอกจากนี้ เรารับทราบด้วยว่า "รายงานนี้ทำให้เกิดคำถามเกี่ยวกับเอกสารประกอบที่กระจัดกระจาย ข้อกำหนดเชิงพาณิชย์ การตรวจสอบของบุคคลที่สาม การรับรองอุตสาหกรรม ความสามารถในการปรับขนาด ความโปร่งใส และการกำกับดูแลในอนาคต ซึ่งเราจะมีส่วนร่วมกับระบบนิเวศและอัปเดตคำถามที่พบบ่อยสาธารณะตามนั้น" เราจัดการเอกสารที่แยกเป็นส่วนๆ ก่อนหน้านี้ เราปฏิบัติตามข้อกำหนดเชิงพาณิชย์ภายใต้ "การรับประกันข้อมูล" ที่นี่ และในผลิตภัณฑ์โฆษณาบางอย่างของ Google ได้แชร์แนวทางการดำเนินงานของตนไปแล้ว เราดำเนินการตรวจสอบของบุคคลที่สามภายใต้ "การรับประกันความสมบูรณ์ของอัลกอริทึม" ที่นี่ ในเรื่องการรับรอง เราคาดหวังว่าหน่วยงานเหล่านั้นจะให้การรับรองผลิตภัณฑ์ต่อไป ซึ่งรวมถึงการใช้เทคโนโลยี แทนที่จะเป็นเทคโนโลยีด้วยตนเอง ในส่วนของความสามารถในการปรับขนาด เรายังคงเปิดรับข้อมูลจากนักพัฒนาแอปที่แสดงให้เห็นถึงปัญหา เกี่ยวกับความโปร่งใสและการกำกับดูแล เรายังคงพัฒนาอย่างต่อเนื่องใน GitHub และในฟอรัมต่างๆ เช่น W3C ในขณะที่มีส่วนร่วมกับ CMA ภายใต้สัญญาผูกมัด
Google Sign-In	การลงชื่อเข้าใช้ Google จะทําให้ Google ใช้ข้อมูลการเข้าสู่ระบบจากการระบุตัวตนแบบข้ามได้ซึ่งขัดแย้งกับสัญญาผูกมัด	Google Sign-In ไม่อนุญาตให้ Google ใช้ข้อมูลที่ขัดแย้งกับสัญญาผูกมัด
ความเข้ากันได้	แผนการรองรับ Privacy Sandbox API และความเข้ากันได้ในอนาคต / ย้อนหลังคืออะไร	เมื่อ Chrome เปิดตัวฟีเจอร์เป็นเวอร์ชันสำหรับผู้ใช้ทั่วไปแล้ว เราตั้งใจที่จะรองรับฟีเจอร์ดังกล่าวต่อไป แน่นอนว่าการคงความเข้ากันได้แบบย้อนหลังนั้นทำไม่ได้เสมอไป และในกรณีดังกล่าว เรามีกระบวนการที่ชัดเจนในการเลิกใช้งานและนำฟีเจอร์ที่มีอยู่ออก ดังที่อธิบายไว้ที่นี่ เราคาดว่าจะเพิ่มฟีเจอร์ไปยัง Privacy Sandbox API อื่นๆ ต่อไปเรื่อยๆ เพื่อตอบสนองต่อความคิดเห็นของระบบนิเวศเกี่ยวกับกรณีการใช้งานที่จะได้รับประโยชน์จากการสนับสนุนที่ปรับปรุงให้ดีขึ้น ในกรณีดังกล่าว เรามักจะรวมเทคนิคการตรวจจับฟีเจอร์ไว้ด้วย เพื่อให้เทคโนโลยีโฆษณาที่สนใจทดลองใช้ฟีเจอร์ใหม่สามารถถามเบราว์เซอร์ได้โดยตรงว่ารองรับฟีเจอร์นี้หรือไม่ วิธีนี้ดีกว่าขอให้นักพัฒนาซอฟต์แวร์ตรวจสอบหมายเลขเวอร์ชันของ Chrome ที่แน่นอน เนื่องจากฟีเจอร์บางอย่างอาจเปิดตัวแก่ผู้ใช้ Chrome เพียงบางรายพร้อมกัน เช่น ดูการทำงานของการตรวจหาฟีเจอร์สำหรับ PA API ได้ที่นี่
การใช้งานเซิร์ฟเวอร์	แทนที่จะนำไปรวมกับการติดตั้งใช้งานของตัวเอง Chrome ควรระบุลักษณะการทำงานที่การใช้งานเซิร์ฟเวอร์สัญญาณที่เชื่อถือได้ เซิร์ฟเวอร์การรวม และคอมโพเนนต์ที่จำเป็นอื่นๆ ที่ไม่ใช่เบราว์เซอร์จะต้องเป็นไปตามที่น่าพึงพอใจ ซึ่งจะทำให้มีนวัตกรรมภายในขอบเขตความเป็นส่วนตัวที่ยอมรับได้	เรายินดีและยินดีอย่างยิ่งที่บุคคลภายนอกที่องค์กรปรารถนาให้เกิดนวัตกรรม สำหรับ API และบริการทั้งหมด เรามุ่งหวังที่จะให้ความยืดหยุ่นของเทคโนโลยีโฆษณาในการใช้ฟังก์ชันการทำงาน เช่น เราอนุญาตให้เทคโนโลยีโฆษณาใช้ข้อมูลทางธุรกิจที่เป็นความลับในการออกแบบตรรกะการเสนอราคาสำหรับการประมูล นอกจากนี้ เรายังมีส่วนร่วมกับความคิดเห็นจากเทคโนโลยีโฆษณาและนำไปใช้ในการออกแบบของเราอย่างต่อเนื่อง Privacy Sandbox จะต้องตรวจสอบโค้ด (และการเปลี่ยนแปลงทั้งหมด) เพื่อยืนยันว่าเป็นไปตามการรับประกันความเป็นส่วนตัวเพื่ออนุญาตให้ผู้อื่นเรียกใช้โค้ดของตนเองในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ ทีม Privacy Sandbox จะต้องใช้ความพยายามอย่างมาก ด้วยเหตุนี้ เราจึงอยากทราบว่าผู้มีส่วนเกี่ยวข้องมุ่งหวังที่จะได้รับประโยชน์อะไร ซึ่งเรายังไม่พบในปัจจุบัน
ระบบศึกษาตัวเลือก	แผนระยะยาวสำหรับวิทยาการศึกษาสำนึกคืออะไร	เพื่อให้สอดคล้องกับเบราว์เซอร์อื่นๆ ที่ระบุไว้ เราตั้งใจที่จะเลิกใช้วิธีการเรียนรู้เหล่านี้เพราะเป็นโซลูชันทางเลือกที่มีการใช้กันอย่างแพร่หลาย โดยขึ้นอยู่กับการวิเคราะห์ความเป็นไปได้เพิ่มเติม เราได้แชร์ไว้ที่นี่
ปริมาณการทดสอบ	ปริมาณการเข้าชมแตกต่างกันเมื่อเปรียบเทียบมิติข้อมูลที่แตกต่างกัน	การทดสอบ 1% มีเกณฑ์การยกเว้นที่ทำให้เกิดความแตกต่างในการมีสิทธิ์เข้าร่วมการทดสอบระหว่างประชากรต่างๆ ของลูกค้า Chrome ตัวอย่างเช่น การทดสอบไม่รวมผู้ใช้ Chrome Enterprise จึงคาดว่าจะมีสัดส่วนของการเข้าชมที่มีป้ายกำกับการทดสอบสูงกว่าในช่วงสุดสัปดาห์ การเห็นเปอร์เซ็นต์การเข้าชมที่แตกต่างกันในส่วนต่างๆ ของข้อมูล (เช่น ภูมิศาสตร์ วันที่ และแพลตฟอร์ม) นั้นเป็นเรื่องปกติ ซึ่งสอดคล้องกับสิ่งที่เราเห็นในข้อมูล Chrome
เปิดใช้ 3PC อีกครั้งด้วยตนเอง	เว็บไซต์จะสามารถทราบจำนวนผู้ใช้ (%) ที่เปิดใช้งานคุกกี้ด้วยตนเองอีกครั้งหลังจากบังคับใช้ 3PCD หรือไม่	ผู้ใช้สามารถเปิดใช้การเข้าถึง 3PC อีกครั้งที่ระดับเว็บไซต์ผ่านการข้ามผู้ใช้หากพบข้อบกพร่อง 3PC อาจยังได้รับการเปิดใช้อีกครั้งโดยมาตรการอื่นๆ เช่น Storage Access API เรามีมาตรการทางเทคนิค เช่น hasStorageAccess() ที่ช่วยให้เว็บไซต์สามารถตรวจหาว่า 3PC เปิดหรือปิดใช้งาน อย่างไรก็ตาม Chrome จะไม่ช่วยให้เว็บไซต์ทราบถึงเหตุผลในการเปิดใช้อีกครั้ง
การป้องกันการติดตาม	ฟีเจอร์ UI การปกป้องการติดตามของ Chrome จะเปิดให้ใช้งานได้นานเท่าใด	เราคาดว่า UI การป้องกันการติดตามในแถบที่อยู่จะยังคงอยู่หลังจากการเลิกใช้งาน 3PC แล้ว
(รายงานในไตรมาสก่อนหน้าด้วย) การสนับสนุนในเบราว์เซอร์ต่างๆ	ผู้ให้บริการเบราว์เซอร์รายอื่นๆ ที่ใช้ Privacy Sandbox API	ผู้ให้บริการเบราว์เซอร์อื่นๆ เช่น Apple, Mozilla และ Microsoft มีส่วนร่วมอย่างแข็งขันในฟอรัมสาธารณะซึ่งมีการกล่าวถึงหลักการด้านความเป็นส่วนตัวและการทำงานบนเบราว์เซอร์ เราได้รับการกระตุ้นจากการร่วมหารือกันในฟอรัมต่างๆ เช่น การประชุม TPAC ประจำปีของ W3C เมื่อเร็วๆ นี้และฟอรัม W3C PATCG ที่ดำเนินอยู่ ซึ่งเราพบสัญญาณของการรวมตัว ตัวอย่างเช่น เมื่อเร็วๆ นี้ Microsoft Edge ได้ประกาศแผนที่จะ "มุ่งเน้นความเข้ากันได้ทางไวยากรณ์ให้ได้มากที่สุด" กับ PA API และ ARA และในขณะเดียวกันก็นำเสนอฟีเจอร์เพิ่มเติมให้กับนักพัฒนาซอฟต์แวร์ด้วย
ตัวเลือกสำรองสำหรับการฝังที่ใช้ร่วมกันไม่ได้หลังโพสต์ 3PCD	ระบุฮุกของ API เพื่อตรวจหาว่า iframe / การฝังของบุคคลที่สามสอดคล้องกับ 3PCD หรือไม่	เราอยากพูดคุยเกี่ยวกับคำขอดังกล่าวที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การทดสอบ	ขอแฟล็กเพิ่มเติมในอินสแตนซ์ของ Chrome ที่มีการจัดการ ซึ่งปิดการทำงานที่กำหนดเองไว้ชั่วคราว	เรากำลังพิจารณาคำขอนี้สำหรับอินสแตนซ์ของ Chrome ที่มีการจัดการ และยินดีรับฟังข้อมูลเพิ่มเติมจากระบบนิเวศ หากการแจ้งดังกล่าวจะเป็นประโยชน์

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

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

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

หัวข้อ

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
(รายงานในไตรมาสก่อนหน้าด้วย) ไทม์ไลน์และเอกสารประกอบของตัวแยกประเภท	ควรมีกลไกบางรูปแบบสำหรับการตรวจสอบการจัดประเภท หรืออย่างน้อยก็ต้องมีความโปร่งใสเพิ่มเติมเกี่ยวกับวิธีกำหนดหมวดหมู่ของโหมดการแยกประเภท	ผลตอบรับของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่แล้ว: "การจัดประเภทเว็บไซต์ที่ไม่ถูกต้องอาจทําให้สัญญาณ Topics มีประโยชน์น้อยลงเล็กน้อยในการเป็นสัญญาณโดยรวม แต่เว็บไซต์ที่เจาะจงซึ่งจัดประเภทไม่ถูกต้องนั้นไม่ได้รับความเสียหายจากข้อผิดพลาดนี้มากกว่าเว็บไซต์อื่นๆ เนื่องจากข้อมูลตามบริบทของเว็บไซต์จะพร้อมให้ประมูลเสมอในเว็บไซต์ของตน ซึ่งจะให้ข้อมูลที่เปรียบเทียบกับหัวข้อที่ถูกต้องได้ แม้ในกรณีที่จัดประเภทไม่ถูกต้องก็ตาม เรายินดีรับฟังความคิดเห็นในเรื่องนี้ที่นี่"
Google Ad Manager	Google Ad Manager ฝังอยู่ในเว็บไซต์ส่วนใหญ่แล้ว และจะมีข้อมูลเกี่ยวกับหัวข้อของผู้ใช้ที่กว้างกว่ามาก เมื่อเทียบกับคู่แข่งที่อยู่ในเว็บไซต์น้อยกว่า	ข้อกำหนดการสังเกตการณ์มีไว้เพื่อให้มั่นใจว่า Topics API จะไม่ส่งผลให้มีการแชร์ข้อมูลผู้ใช้กับเอนทิตีมากกว่าเทคโนโลยีที่ API จะมาแทนที่ (รวมถึง 3PC) โซลูชันอื่นๆ ในอุตสาหกรรม เช่น Prebid สามารถทำงานร่วมกับเว็บไซต์กว่า 10,000 แห่ง และช่วยให้ผู้เข้าร่วมตลาดเรียกใช้ Topics API ผ่านเทคโนโลยีของตนได้ นอกจากนี้ โปรดทราบว่าขีดจำกัดหัวข้อยอดนิยมสูงสุด 5 หัวข้อต่อสัปดาห์อาจส่งผลอย่างเท่าเทียมกัน เนื่องจากผู้เข้าร่วมตลาดในเว็บไซต์หลายแห่งอาจเรียนรู้หัวข้อที่เทียบเท่ากันมากกว่า 5 รายการโดยใช้ 3PC จะจำกัดอยู่ที่ 5 รายการ
(รายงานในไตรมาสก่อนหน้าด้วย) ความมีประโยชน์สําหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ	ความกังวลเกี่ยวกับคุณค่าที่สร้างขึ้นและการกระจายค่าดังกล่าวสำหรับเว็บไซต์โดยขึ้นอยู่กับระดับการเข้าชมหรือความเฉพาะเจาะจงของเนื้อหาในเว็บไซต์	เราทราบดีว่าเว็บไซต์เฉพาะทางมีแนวโน้มที่จะร่วมแสดงหัวข้อที่ละเอียดยิ่งขึ้นมากกว่าโดเมนความสนใจทั่วไป อย่างไรก็ตาม เว็บไซต์เฉพาะทางบางเว็บก็ไม่ได้นำเสนอหัวข้อที่มีคุณค่าในเชิงพาณิชย์ นอกจากนี้ การเปลี่ยนแปลงนี้ยังสะท้อนถึงสถานภาพปัจจุบันและเป็นอิสระจากการสิ้นสุดการสนับสนุน 3PC ใน Chrome นอกจากนี้ ในสภาพแวดล้อมปัจจุบัน เว็บไซต์บางแห่งให้คุณค่ามากกว่าเว็บไซต์อื่นๆ ในระบบความเกี่ยวข้องของโฆษณา 3PC นอกจากนี้ หัวข้อระหว่างเว็บไซต์เฉพาะทางอาจเป็นประโยชน์ต่อกันและกัน เนื่องจากผู้ลงโฆษณาที่หลากหลายใช้งานแคมเปญในชุดหัวข้อที่หลากหลายได้ และตรรกะการเสนอราคาสามารถสังเกตมูลค่าของหัวข้อที่หลากหลายได้
ชื่อโฮสต์และ URL ที่สมบูรณ์	การจำแนกประเภทตามชื่อโฮสต์ของเว็บไซต์มีประสิทธิภาพเพียงพอหรือไม่ และสิ่งนี้จะช่วยลดความเสี่ยงด้านความเป็นส่วนตัวเมื่อเทียบกับ URL ที่สมบูรณ์หรือไม่	เราพิจารณาการใช้ URL หรือชื่อหน้าเว็บของข้อมูลเพิ่มเติมจากชื่อโฮสต์ และได้พิจารณาว่าประโยชน์ที่เป็นไปได้นั้นไม่เหนือกว่าความเสี่ยงต่อความเป็นส่วนตัวและความปลอดภัยของผู้ใช้ ตัวอย่างความเสี่ยงด้านความเป็นส่วนตัวของผู้ใช้ ได้แก่ การจัดประเภทข้อมูลที่ละเอียดอ่อนที่อยู่ใน URL หรือชื่อหน้าเว็บเป็นหัวข้อของผู้ใช้
การใช้หัวข้อเป็นสัญญาณ	ขอคำแนะนำเกี่ยวกับวิธีรวม Topics กับสัญญาณอื่นๆ และสัญญาณอื่นๆ ที่อาจมีประโยชน์	โซลูชันเทคโนโลยีโฆษณาจะมอบผลลัพธ์ที่ดีที่สุดโดยการรวมเครื่องมือทั้งหมดที่มีอยู่ เช่น แมชชีนเลิร์นนิงและสัญญาณที่ไม่ละเมิดความเป็นส่วนตัวจาก 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
การจำกัดต้นทางเดียวกันในเจ้าของ IG และ URL ตรรกะการเสนอราคา	เมื่อใช้ข้อกำหนดต้นทางเดียวกัน ระบบจะบังคับให้ปลายทางของเจ้าของ IG ผ่านตัวจัดสรรภาระงานเดียวกัน ซึ่งอาจทำให้การเปลี่ยนเส้นทางถูกปฏิเสธ	ข้อกำหนดต้นทางเดียวกันสำหรับการโหลดสคริปต์คือการรักษาความปลอดภัยที่สำคัญ เราขออธิบายรายละเอียดเกี่ยวกับโซลูชันที่นำเสนอในที่นี้ ซึ่งจะสร้างความสมดุลระหว่างความคิดเห็นเกี่ยวกับระบบนิเวศและข้อควรพิจารณาอื่นๆ ได้ที่นี่
การประมูลส่วนตัวแบบหลายช่อง	การอนุญาตให้การประมูลส่วนตัวแบบช่องหลายช่องอยู่ภายในขอบเขตความเป็นส่วนตัวด้วยการใช้สัญญาณรบกวนและการผสานรวมกับแนวทางปัจจุบันของโฆษณาที่ให้ผลลัพธ์มากขึ้น	เรากำลังพิจารณาความคิดเห็นนี้และประเมินคำขอสำหรับการประมูลหลายแท็กต่อความซับซ้อนและความเสี่ยงด้านความเป็นส่วนตัวที่เพิ่มขึ้นที่เกี่ยวข้องกับฟีเจอร์นี้ เราได้พูดคุยถึงปัญหานี้เพิ่มเติมในระหว่างการโทรติดต่อ PA API Web Incubator Community Group (WICG) ที่นี่
ผู้ขายระดับสูง	โครงสร้างปัจจุบันของ PA API ทำให้ผู้ขายระดับบนสุดได้รับข้อมูลและความเข้าใจเกี่ยวกับมูลค่าการแสดงผลที่เกี่ยวข้องมากกว่าทั้งผู้เผยแพร่โฆษณาหรือผู้ขายคอมโพเนนต์	ผู้ขายแต่ละรายจะเสนอราคาที่ดีที่สุดในการประมูลที่มีผู้ขายหลายราย นอกจากนี้ เรายังได้เรียนรู้จากระบบนิเวศที่ผู้เผยแพร่โฆษณาอาจต้องการพิจารณาความต้องการแบบขายตรงถัดจากราคาเสนอที่ดีที่สุดของผู้ขายแต่ละรายที่พวกเขาร่วมงานด้วย การตรวจสอบโอกาสในการสร้างรายได้เหล่านี้ทั้งหมดเป็นสิ่งจำเป็นในการระบุโฆษณาที่จะแสดง สถานการณ์นี้ การกระทำดังกล่าวจึงเกิดขึ้นก่อน PA API ซึ่งนักแสดงบางคนต้องเห็นตัวเลือกทั้งชุดเพื่อเลือกโฆษณาที่จะแสดง PA API พยายามสนับสนุนการประมูลของผู้ขายหลายรายและความต้องการของผู้เผยแพร่โฆษณาที่จะพิจารณาราคาเสนอที่ดีที่สุดของผู้ขายแต่ละรายถัดจากแคมเปญโฆษณาแบบขายตรง ซึ่งอาจต้องใช้หลัง นั่นหมายความว่าจำเป็นต้องมีกลไกในการเลือกจากโอกาสในการสร้างรายได้ดังเช่นที่มีในปัจจุบัน เราไม่คิดว่าเบราว์เซอร์นี้ควรมีบทบาทอย่างไรในการเลือกโฆษณาที่จะแสดง ดังนั้น แนวคิดของผู้ขายระดับบนสุดจึงจำเป็นต่อการเลือกโฆษณาที่ชนะจากความเป็นไปได้ต่างๆ ตรรกะของผู้ขายระดับสูงนั้นต้องสามารถพิจารณาราคาเสนอที่ดีที่สุดจากผู้ขายแต่ละรายที่ผู้เผยแพร่โฆษณาเลือกที่จะร่วมงานด้วย และตรรกะของผู้ขายนั้นอาจเลือกที่จะให้ข้อมูลเกี่ยวกับแคมเปญแบบขายตรงของผู้เผยแพร่โฆษณาที่มีข้อมูลดังกล่าว ข้อมูลทั้งหมดนี้สามารถนำมาพิจารณาในตรรกะการเลือกโฆษณาระดับบนสุด ซึ่งหมายความว่าตรรกะระดับบนสุดจะพิจารณาราคาเสนอที่ดีที่สุดจากการประมูลของ PA API และตัวเลือกโฆษณาแบบขายตรงจากผู้เผยแพร่โฆษณา (หากมี) เพื่อกำหนดผู้ชนะ Google Ad Manager แสดงรายละเอียดการใช้งาน PA API ในฐานะผู้ขายระดับบนสุดในรายงานนี้ภายใต้ธีม "การเข้าถึงข้อมูล"
การแยกโฆษณาของคู่แข่ง	ส่งคำขอแยกโฆษณาของคู่แข่ง เช่น ป้องกันไม่ให้โฆษณาจากแบรนด์คู่แข่งแสดงข้างกัน	เราไม่ทราบถึงวิธีที่จะช่วยแยกแยะความแตกต่างทางการแข่งขันในระบบนิเวศการโฆษณาดิจิทัลของผู้ขายหลายรายที่มีการเสนอราคาและแบบเป็นโปรแกรมในปัจจุบัน อย่างไรก็ตาม PA API ช่วยให้ผู้ขายสามารถดึงข้อมูลสัญญาณแบบเรียลไทม์เพิ่มเติม โดยอิงตามการผสานรวม URL และชื่อโฮสต์ (แทนโดเมนของผู้เผยแพร่โฆษณา) ที่จะใช้ระหว่าง scoreAd() เมื่อให้คะแนนครีเอทีฟโฆษณา ผู้ขายอาจใช้วิธีนี้เพื่อป้องกันไม่ให้โฆษณาจากแบรนด์คู่แข่งแสดงข้างๆ กัน โดยสมมติว่าผู้เผยแพร่โฆษณาต้องการบังคับใช้กฎนี้
ข้อมูลที่จำกัด	PA API จะลดข้อมูลที่ผู้เผยแพร่โฆษณาเข้าถึงได้ เช่น มูลค่าโฆษณา, ชื่อผู้ซื้อคอมโพเนนต์, ชื่อผู้ลงโฆษณา, URL ของหน้า Landing Page, ขนาดครีเอทีฟโฆษณา, เวลาในการตอบสนอง และอัตราราคาเสนอ รวมถึงการสูญเสียราคาเสนอ	เราได้เสนอโซลูชันที่เป็นไปได้บางส่วนที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การรายงานระดับเหตุการณ์	ผู้เผยแพร่โฆษณาไม่ได้รับข้อมูลเกี่ยวกับโฆษณาที่แสดงอย่างเพียงพอหลังจากเลิกใช้งาน API ของ PA การรายงานระดับเหตุการณ์	เราทราบถึงกรณีการใช้งานการรายงานต่างๆ ที่เราจะต้องให้การสนับสนุนต่อไปเมื่อมีการเลิกใช้การรายงานระดับเหตุการณ์ ด้วยเหตุนี้ เราจึงกำหนดเป้าหมายวันที่ที่จะเลิกใช้การรายงานระดับเหตุการณ์เป็นวันที่หลังปี 2026 ในช่วงเวลาระหว่างนี้เป็นต้นไป เราขอเชิญชวนให้คุณมีส่วนร่วมอย่างเต็มที่ขณะมีส่วนร่วมกับระบบนิเวศบนเส้นทางอันยั่งยืน ซึ่งอาจรวมถึงแนวคิดใหม่ๆ สำหรับการรับข้อมูลในลักษณะที่รักษาความเป็นส่วนตัว
SSP หลายรายการ	มูลค่าที่เพิ่มขึ้นจากการมี SSP หลายรายการจะต่ำเกินไปสําหรับผู้เผยแพร่โฆษณา	เราไม่เชื่อว่าการดำเนินการนี้ถูกต้อง และยินดีรับความคิดเห็นเพิ่มเติมจากระบบนิเวศเพื่อทําความเข้าใจเหตุผลในการยืนยันนี้
กิจกรรมการดูแลจัดการ	กิจกรรมการดูแลจัดการจะทำกับ PA API ไม่ได้	เราได้รับความคิดเห็นเกี่ยวกับความสามารถสำหรับผู้ขายในการใช้ PA API เพื่อแสดงข้อมูลผู้ชมแก่ผู้ซื้อทั่วเว็บ (หรือที่เรียกว่าส่วนขยายกลุ่มเป้าหมาย) เราเชื่อว่าทุกอย่างเป็นไปได้ในปัจจุบัน ด้วยการใช้ฟังก์ชันการมอบสิทธิ์ของ PA ควบคู่กับข้อตกลงทางธุรกิจ ในขณะเดียวกัน เรากำลังพิจารณาอย่างเต็มที่ว่าจะรองรับ Use Case ประเภทนี้หรือไม่และอย่างไร
ผู้ซื้อเลือกไม่รับ	การเลือกไม่ใช้โดยค่าเริ่มต้นของผู้ซื้อมีแนวโน้มที่จะทำให้เกิดผลลัพธ์ที่ต่ำกว่าสำหรับการประมูลส่วนประกอบ	ไม่ว่าจะเป็นการกำหนดการประมูล PA สำหรับผู้ขายรายเดียวหรือผู้ขายหลายราย ผู้ขายต้องระบุรายชื่อผู้ซื้อไว้อย่างชัดเจนในช่อง interestGroupBuyers ของผ่านauctionConfig ความคิดเห็นนี้ขึ้นอยู่กับความคิดเห็นของระบบนิเวศว่าผู้ขายมีข้อตกลงแบบสัญญากับผู้ซื้อบางราย ไม่ใช่ผู้ซื้อรายอื่น ดังนั้นคุณจะต้องควบคุมอย่างชัดแจ้งว่าจะรวมผู้ซื้อรายใดเข้าร่วมการประมูล เรายินดีพูดคุยเพิ่มเติมบน GitHub
ขนาดโฆษณา	ไม่สามารถกรองล่วงหน้าตามขนาด adSlotSize และ adSlotSize	เรากำลังดำเนินการเพิ่มความสามารถนี้อยู่และดูรายละเอียดเพิ่มเติมได้ที่นี่
การรองรับการกำหนดเป้าหมาย IG เชิงลบ	API เพื่อรองรับการกำหนดเป้าหมาย IG เชิงลบ: แสดงโฆษณาเมื่อผู้ใช้ไม่ได้อยู่ใน IG เท่านั้น	ปัญหาเกี่ยวกับ GitHub นี้ เสนออีกวิธีหนึ่งในการใช้การกำหนดเป้าหมายเชิงลบ ซึ่งเบราว์เซอร์จะบอกเซิร์ฟเวอร์โฆษณาโดยตรงว่ากฎการกำหนดเป้าหมายเชิงลบใดควรมีผลกับคำขอโฆษณาบางรายการ แม้ว่าวิธีนี้ดูเหมือนจะเป็นวิธีการที่น่าดึงดูด แต่แนวคิดนี้ทุกเวอร์ชันที่เราได้ตรวจสอบพบว่าช่วยให้เซิร์ฟเวอร์สามารถระบุผู้ใช้ได้อย่างแน่ชัด
กฎหมายบริการดิจิทัล	ผู้เผยแพร่เนื้อหาจะใช้ Fenced Frames และป้องกันไม่ให้แสดงคำตอบที่มีข้อมูลซึ่งอยู่ภายใต้กฎหมายบริการดิจิทัลได้อย่างไร	เช่นเดียวกับเทคโนโลยีใหม่อื่นๆ แต่ละบริษัทมีหน้าที่ตรวจสอบว่าการใช้ Privacy Sandbox เป็นไปตามกฎหมาย Google ไม่สามารถให้คำแนะนำด้านกฎหมายแก่ผู้อื่นได้ สำหรับ API แต่ละรายการ เราได้เผยแพร่เอกสารทางเทคนิคมากมาย ซึ่งควรเป็นพื้นฐานสำหรับการประเมินทางกฎหมายที่จำเป็น การใช้ Fenced Frame ไม่จำเป็นต้องใช้ใน PA API ก่อนปี 2026 ซึ่งช่วยให้ผู้มีส่วนเกี่ยวข้องมีเวลามากขึ้นในการตรวจสอบว่าการใช้เทคโนโลยีนี้เป็นไปตามนิติบัญญัติที่เกี่ยวข้องทั้งหมด
เอกสารประกอบ	UpdateAdInterestGroups() เป็นแบบชั่วคราวหรือไม่	เรายังไม่ได้ประกาศแผนในการเลิกใช้งานupdateAdInterestGroup ในอนาคต เราอาจใช้การคุ้มครองความเป็นส่วนตัวที่คล้ายกันกับที่เราได้พูดถึงแบบสาธารณะสำหรับกลไกการอัปเดตอื่นๆ ของ IG เช่น การใช้ที่อยู่ IP ยังพร็อกซีและเพิ่มความล่าช้าก่อนที่จะทำการอัปเดต
การสนับสนุนข้อมูลเมตาฝั่งซื้อและการเป็นเจ้าของตรรกะสำหรับผู้ที่ไม่ใช่ DSP	ขอวิธีทำหน้าที่เป็นพร็อกซีสำหรับ DSP	เราได้รับความคิดเห็นนี้จากกลุ่มที่ไม่ใช่ DSP และกำลังพิจารณาคำขอนี้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การรายงาน	คำขอเพิ่มฟีเจอร์ตัวแฮนเดิลที่กำหนดเองสำหรับที่เก็บข้อมูล / ค่าสัญญาณในการรายงานการรวมส่วนตัว	เราทราบแล้ว และขณะนี้คำขอฟีเจอร์นี้อยู่ในคิวรอการค้นพบเพิ่มเติมแล้ว เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศที่นี่
เอกสารประกอบ	มีลิงก์สําหรับดูส่วนหัวการตอบกลับทั้งหมดที่ผู้ลงโฆษณาและโดเมนเจ้าของ (ที่ได้รับมอบอำนาจ) ต้องตั้งค่าหรือไม่	เรากำลังวางแผนปรับปรุงเอกสารประกอบเพื่อชี้แจงเรื่องนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การเสนอราคาสำหรับหอคอยหลายอาคาร	ขอคำอธิบายเกี่ยวกับเวิร์กโฟลว์ (การฝึกและการอนุมาน) ผ่านแผนภาพสถาปัตยกรรม / บล็อกเกี่ยวกับมุมมองของแนวทางแบบ Multi-Tower ในบริบทของ PA API	ขอบคุณสำหรับความคิดเห็น เรามีงานนำเสนอบางส่วนเกี่ยวกับเรื่องนี้ ซึ่งเราคาดว่าจะสร้างเอกสารเพิ่มเติม
การกำหนดเป้าหมายเชิงลบ	ความสามารถของ Privacy Sandbox ในการปกป้องกลุ่มเป้าหมายที่มีความละเอียดอ่อนและผู้เยาว์จากโฆษณาที่ไม่เหมาะสม เช่น การพนัน	PA API จะไม่พิจารณาเนื้อหาของโฆษณาที่แสดง ส่วนนี้จะควบคุมนักพัฒนาเทคโนโลยีโฆษณาที่ใช้ PA โดยทั่วไป ผู้เผยแพร่โฆษณาและผู้ให้บริการเทคโนโลยีโฆษณาของตนจะบล็อกโฆษณาภายในการประมูล Protected Audience ได้โดยใช้ข้อมูลบริบทจากหน้าเว็บและชุดกฎของผู้เผยแพร่โฆษณา สิ่งนี้สะท้อนให้เห็นถึงความเข้าใจของเราเกี่ยวกับแนวทางของระบบนิเวศที่มีต่อความท้าทายเหล่านี้ในปัจจุบัน สำหรับผู้ซื้อ ฟังก์ชันการกำหนดเป้าหมาย IG เชิงลบอาจเป็นประโยชน์สำหรับกรณีการใช้งานด้านการปฏิบัติตามข้อกำหนดบางกรณีด้วย
การออกแบบ API	Google กำลังปฏิเสธและต้องการให้เทคโนโลยีโฆษณาใช้ฟังก์ชันการเสนอราคาสากล ซึ่งจะช่วยเพิ่มเวลาในการตอบสนอง แทนที่จะใช้ BiddingLogicURL ที่ต่างกันใน IG ที่ต่างกันซึ่งได้รับอนุญาต	ระหว่างการหารือเรื่องเวลาในการตอบสนองในการประมูล เราได้ไฮไลต์ว่าการใช้สคริปต์เดียวกันซ้ำใน IG ทั้งหมดของผู้ซื้อจะทำให้การเสนอราคาของผู้ซื้อรายนั้นทำงานเร็วขึ้น โปรดดูรายละเอียดเพิ่มเติมที่นี่ พร้อมคําแนะนําอื่นๆ สำหรับการปรับปรุงเวลาในการตอบสนองของการประมูล PA API
การตลาดตามบัญชี	PA API ไม่ใช่ API ที่ชัดเจนสำหรับกรณีการใช้งานทางการตลาดที่อิงตามบัญชี	เรายินดีรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับ Use Case ที่เฉพาะเจาะจงซึ่งเชื่อว่าเป็นไปไม่ได้ และขอแนะนำให้ผู้เข้าร่วมในระบบนิเวศพูดคุยเรื่องนี้ต่อไปผ่านที่เก็บ GitHub สาธารณะหรือทางโทรศัพท์รายสัปดาห์
การทดสอบ A/B	เมื่อมีการกำหนดค่า PA API ใน GAM สำหรับผู้เผยแพร่โฆษณา ปัจจุบันจะต้องมีการเปิดใช้ 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 นี้ ระบบก็จะรวมการกำหนดค่าดังกล่าวไว้ในรายการการประมูลคอมโพเนนต์สำหรับโอกาสในการโฆษณาดังกล่าว 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 และ Fenced Frame	เมื่อเดือนมกราคม เราได้เผยแพร่การสาธิตวิธีการทำงานของวิดีโอในสตรีมในการประมูลของ PA พร้อมด้วยรายละเอียดเพิ่มเติมเกี่ยวกับแนวทางอื่นๆ นอกจากนี้ เรายังเห็นผู้เล่นในระบบนิเวศเริ่มเสนอวิธีการทำงานของการแสดงภาพวิดีโอให้แก่พาร์ทเนอร์ที่ผสานรวมกับพาร์ทเนอร์ เช่น ข้อเสนอของ GAM เกี่ยวกับการสร้าง DisplayURL ที่เข้ากันได้กับวิดีโอหรือกระบวนการ E2E เต็มรูปแบบ นอกจากนี้ เรากำลังรับฟังความคิดเห็นเกี่ยวกับระบบนิเวศเกี่ยวกับการเปลี่ยนแปลงที่เราสามารถทำได้เพื่อเพิ่มการใช้งาน และรายละเอียดการเปลี่ยนแปลงดังกล่าว 1 อย่างใน GitHub เราจะยังคงมีส่วนร่วมกับระบบนิเวศอย่างแข็งขันเพื่อระบุอุปสรรคอื่นๆ ในการปรับใช้และรับมือกับอุปสรรคต่างๆ บน YouTube ในเวลาที่เหมาะสม
(รายงานในไตรมาสก่อนหน้าด้วย) นโยบายการจัดการข้อมูล	นโยบายการจัดการข้อมูลสำหรับ IG / PA API คืออะไร	ในการออกแบบ PA API ข้อมูลทั้งหมดที่จัดเก็บไว้ใน IG หรือเกี่ยวกับสิ่งที่ผู้คนอยู่ใน IG จะ (1) ยังคงอยู่ในอุปกรณ์ หรือ (2) ได้รับการประมวลผลในบริการการเสนอราคาและการประมูล (B&A) ที่ทำงานภายใน Trusted Execution Environment (TEE) ในทั้ง 2 กรณี ผู้อื่นจะไม่สามารถอ่านข้อมูล หรือใช้ข้อมูลในลักษณะอื่นใดนอกเหนือจากราคาเสนอในการประมูล การเพิ่มประสิทธิภาพด้านความเป็นส่วนตัวบางอย่างที่ Chrome กำลังศึกษาเกี่ยวข้องกับการโต้ตอบกับเซิร์ฟเวอร์ K-anonymity ที่ Google เป็นผู้ดูแลจัดการ การโต้ตอบดังกล่าวได้รับการออกแบบมาอย่างรอบคอบเพื่อหลีกเลี่ยงการแชร์ข้อมูลเกี่ยวกับผู้ใช้ และใน TEE เพื่อให้แน่ใจว่าข้อมูลในระบบนิเวศของโฆษณามีความเท่าเทียม Google ให้คำมั่นสัญญากับ CMA ในการออกแบบและนำข้อเสนอ Privacy Sandbox ไปใช้ในลักษณะที่ไม่บิดเบือนการแข่งขัน โดยอ้างอิงธุรกิจของ Google เอง รวมถึงคำนึงถึงผลกระทบต่อการแข่งขันด้านโฆษณาดิจิทัล ตลอดจนผู้เผยแพร่โฆษณาและผู้ลงโฆษณาด้วย เราจะทำงานอย่างใกล้ชิดกับ CMA ต่อไปเพื่อให้แน่ใจว่างานของเราจะสอดคล้องกับภาระหน้าที่เหล่านี้
(รายงานในไตรมาสก่อนหน้าด้วย) อายุการใช้งานของ IG	คำขอยืดอายุการใช้งานของ IG จาก 30 เป็น 90 วัน	การเปลี่ยนแปลงดังกล่าวต้องมีการประเมินอย่างรอบคอบ โดยต้องชั่งน้ำหนักระหว่างประโยชน์ที่มีต่ออุตสาหกรรมกับผลกระทบต่อผู้ใช้ Chrome และผู้มีส่วนเกี่ยวข้องคนอื่นๆ เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
(รายงานในไตรมาสก่อนหน้าด้วย) การประมาณสัญญาณ	ขอฟิลด์ใหม่นอกเหนือจากการสร้างแบบจำลองสัญญาณที่สามารถเข้ารหัสได้เฉพาะข้อมูลการแสดงผลและการคลิกเท่านั้น	เราได้ตอบกลับความคิดเห็นนี้พร้อมยื่นข้อเสนอโต้แย้งที่นี่ เรามีส่วนร่วมกับอุตสาหกรรมอย่างแข็งขันเพื่อทำความเข้าใจมุมมองของอุตสาหกรรมที่มีต่อข้อเสนอของเรา และขณะนี้กำลังชั่งน้ำหนักผลประโยชน์ที่อุตสาหกรรมนี้มีต่อผู้ใช้ Chrome และผู้มีส่วนเกี่ยวข้องคนอื่นๆ
บิตเพิ่มเติมใน reportWin()	ระบุบิตเพิ่มเติมใน reportWin() จากขีดจํากัดปัจจุบันที่ 12 ก่อนหน้า 3PCD	เรากําลังสํารวจแนวทางที่จะสนับสนุนกรณีการใช้งานนี้ เรายังต้องใช้เวลาอีกสักพักเพื่อมองหาแนวทางที่ช่วยให้มั่นใจได้ว่าเรามีแผนด้านความเป็นส่วนตัวในระยะยาว
การออกแบบการประมูล	คำขอสำหรับการประมูลครั้งเดียวที่แสดงผล URL ที่มีคะแนนที่เกี่ยวข้อง	เราพิจารณาการแสดงผล URL เดียวกันหลายรายการและคะแนนของแต่ละรายการจากการประมูล PA ครั้งเดียว แต่ไม่ได้ใช้เนื่องจากข้อกังวลด้านความเป็นส่วนตัว เราเข้าใจดีถึงความต้องการที่จะหลีกเลี่ยงการแสดงโฆษณาเดิมซ้ำหลายครั้งต่อผู้ใช้ในหน้าเดียว และยินดีรับฟังความคิดเห็นเพิ่มเติมทาง GitHub
reportWin	บันทึกช่องที่กำหนดเองในฟังก์ชัน reportWin()	ซึ่งจะเกิดขึ้นอยู่แล้วในวันนี้ตลอดระยะเวลาการทดสอบ เมื่อ Chrome ยุติการสนับสนุน 3PC แล้ว ระบบจะย้ายข้อมูล API เวอร์ชัน forDebuggingOnly เพื่อเปิดใช้การแก้ไขข้อบกพร่องแบบลดการสุ่มตัวอย่าง ซึ่งระบุไว้ที่นี่
ผู้ขายส่วนประกอบ	มีกลไกอิสระในการนับการแสดงผลและเหตุการณ์อื่นๆ ของตัวเอง และไม่จำเป็นต้องพึ่งพารายงานของเทคโนโลยีโฆษณาเพียงอย่างเดียว	คำขอฟีเจอร์นี้อยู่ในคิวรอการค้นพบเพิ่มเติม เราไม่คาดว่าจะแก้ไขปัญหานี้ได้ในช่วงระยะเวลาการทดสอบที่อำนวยความสะดวกโดย Chrome
การเรียกเก็บเงินแบบต้นทุนต่อคลิก	ใช้การเรียกเก็บเงินแบบต้นทุนต่อคลิกใน PA API	เรากำลังพิจารณาคำขอนี้ที่นี่ และปัจจุบันเราเห็นว่าคำขอนี้เป็นคำขอคำแนะนำเกี่ยวกับวิธีใช้แพลตฟอร์ม API ปัจจุบัน
browserSignals	เพิ่มอีเมลขาเข้าBidInSellerCurrency ลงในข้อกำหนดของ browserSignals สำหรับการรายงานสำหรับผู้ขาย	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การสนับสนุนข้อมูลเมตาฝั่งซื้อและการเป็นเจ้าของตรรกะสำหรับผู้ที่ไม่ใช่ DSP	การออกแบบ API ในปัจจุบันอาจทำให้เกิดการเปลี่ยนแปลงอย่างมากในแคมเปญการกำหนดเป้าหมายใหม่ในระดับผลิตภัณฑ์ ซึ่งแคมเปญอาจต้องย้ายข้อมูลไปยังแพลตฟอร์มที่เป็นทั้ง DSP และผู้ให้บริการ DCO	เรามีการพูดคุยเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การสนับสนุนข้อมูลเมตาฝั่งซื้อและการเป็นเจ้าของตรรกะสำหรับผู้ที่ไม่ใช่ DSP	แชร์ตัวอย่างที่ DSP ไม่ได้เป็นเจ้าของ IG	เราเข้าใจดีว่าผู้ที่ไม่ใช่ผู้เสนอราคาต้องการใช้ฟังก์ชันบางอย่างของ IG แต่ไม่ต้องการใช้ฟังก์ชันอื่น เรากำลังประเมินตัวเลือกในการจัดการกับกรณีการใช้งานเหล่านี้อย่างต่อเนื่อง และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การควบคุมระยะหมดเวลา	ผู้เผยแพร่โฆษณาควรกำหนดจำนวน IG ที่สามารถเข้าร่วมได้ และระยะหมดเวลาระดับบนสุด / ระยะหมดเวลาส่วนกลาง	เราเข้าใจดีว่า เราต้องการให้การควบคุมระยะหมดเวลาและระดับการเข้าถึงที่ดีขึ้นระหว่างผู้ขายระดับบนสุดและผู้ขายคอมโพเนนต์ ซึ่งเรากำลังพิจารณาคำขอนี้
โฆษณาหลายขนาด	การรองรับ PA API สำหรับกรณีการใช้งานของโฆษณาหลายขนาด	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
เอกสารประกอบ	มีรายการแอตทริบิวต์ IG ที่อยู่ภายใต้ k-anon ไหม	เราได้ตอบคำถามนี้ที่นี่
การแก้ไขข้อบกพร่อง	ปรับปรุงความสามารถในการแก้ไขข้อบกพร่องสำหรับ PA API	เราตระหนักถึงความสำคัญของเครื่องมือแก้ไขข้อบกพร่องที่มีประสิทธิภาพสำหรับนักพัฒนาแอปที่ทำงานกับ PA API เรามุ่งมั่นในการปรับปรุงประสบการณ์การใช้งานให้นักพัฒนาแอปด้วยการสำรวจวิธีผสานรวมการดึงข้อมูลไฟล์ .well-known เข้ากับเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ให้ดียิ่งขึ้น เป้าหมายของเราคือการเพิ่มระดับการเข้าถึงและความสามารถในการแก้ปัญหาภายในสภาพแวดล้อมการพัฒนาซอฟต์แวร์ เรามีการพูดคุยเกี่ยวกับปัญหานี้เพิ่มเติมที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
ป้ายกำกับ	ผู้ใช้ทั้งหมดในป้ายกํากับกลุ่มทดสอบโหมด B ได้เปิดใช้ Privacy Sandbox API แล้วใช่ไหม	การกำหนดกลุ่มทดสอบของ Chrome จะได้รับการสุ่มเลือกและไม่ขึ้นอยู่กับการตั้งค่า Chrome ที่ผู้ใช้กำหนดค่าไว้ แม้ว่า API เหล่านี้อาจพร้อมให้บริการแก่ผู้ใช้ภายในกลุ่มทดสอบเฉพาะ (เช่นtreatment_1.*) แต่คุณแก้ไขหรือปิดใช้ API เหล่านี้ได้ผ่านการตั้งค่า Chrome กลุ่มโหมด B control_2: การรวมในกลุ่มนี้จะปิดความเกี่ยวข้องและ API การวัดผลของ Privacy Sandbox และผู้ใช้ไม่สามารถลบล้างการตั้งค่านี้ได้ในการตั้งค่า Chrome
การใช้ API	การเรียก reportWin() และการแสดงโฆษณาจะเกิดขึ้นพร้อมกันหรือหลังจากมีการเรียกอย่างใดอย่างหนึ่ง	reportWin() จะถูกเรียกโดยตรงหลังจากที่ runAdAuction() เสร็จสิ้น ในขณะเดียวกัน กระบวนการแสดงโฆษณาอาจเริ่มต้นเมื่อผลลัพธ์การประมูลนั้นอยู่ใน iframe หรือ Fenced Frame หลังจาก reportWin() ดำเนินการเสร็จสิ้นและโฆษณาเริ่มแสดงผลแล้ว ระบบจะดึงข้อมูล URL ที่ระบุให้กับ sendReportTo()
(รายงานในไตรมาสก่อนหน้าด้วย) การสนับสนุนการทดสอบ A/B	ขอรับการสนับสนุนสําหรับการทดสอบ A/B ของ PA API	เราพูดคุยเกี่ยวกับคำขอนี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การกำหนดรูปแบบการเข้าชม	ข้อเสนอจาก Google เพื่อจัดการการตัดสินใจที่จำเป็นผ่านเซิร์ฟเวอร์ KV จะไม่มีประโยชน์ เนื่องจากผู้ขายไม่สามารถโต้ตอบกับแบ็กเอนด์ ซึ่งทำให้การกำหนดรูปแบบการเข้าชมทำได้ยาก	ตามที่ได้กล่าวไว้ในปัญหาเกี่ยวกับ GitHub การเปิดเผยว่า DSP แต่ละรายการมี IG หรือไม่อาจกังวลเรื่องฟิงเกอร์ปรินต์ของผู้ใช้ เราได้แนะนำทางเลือกอื่นๆ ในปัญหานี้และพร้อมที่จะให้คำแนะนำเพิ่มเติม
การกำหนดรูปแบบการเข้าชม	กลไกการแคชจะเพิ่มความซับซ้อนลงไปอีกชั้นหนึ่งและทำให้ DSP ไม่ทราบรูปแบบที่แท้จริงของการเข้าชมที่จะเสนอราคา	มีการเสนอกลไกการแคชเพื่อเป็นคำแนะนำเท่านั้น AdTech เลือกใช้คำแนะนำที่ตรงกับกรณีการใช้งานได้ และเรายินดีพูดคุยเพิ่มเติมที่นี่
ป้ายกำกับ	Chrome ควรแชร์ป้ายกำกับเป็นพารามิเตอร์ในคำขอที่ส่งถึงผู้ซื้อและผู้ขายที่เชื่อถือได้	ดูเหมือนว่าเป็นคําขอที่สมเหตุสมผลเนื่องจากดูเหมือนว่าจะสอดคล้องกับเป้าหมายการใช้ข้อมูล IG อย่างมีความรับผิดชอบ อย่างไรก็ตาม เรากำลังพิจารณาคำขอดังกล่าวเพื่อทำการตรวจสอบภายใน และจะแจ้งข้อมูลอัปเดตสาธารณะเกี่ยวกับเรื่องนี้ขณะที่การสนทนาดำเนินอยู่
การใช้ API	ชี้แจงคำนิยามที่ชัดเจนของกลุ่ม "control_1" ในเอกสาร "คำแนะนำเพิ่มเติมเกี่ยวกับ CMA แก่บุคคลที่สามเกี่ยวกับการทดสอบ" โดยเฉพาะอย่างยิ่ง มีข้อกังวลว่าการเปลี่ยนแปลงการใช้คำอาจถูกตีความผิดเนื่องจากทำให้ต้องยกเว้น Privacy Sandbox API ทั้งหมดจาก control_1	เราได้แสดงมุมมองเกี่ยวกับเรื่องนี้ไว้ใน ชุดข้อความของ GitHub อย่างไรก็ตาม เราไม่อยู่ในฐานะที่จะพูดคุยกับ CMA จึงขอแนะนำให้แจ้งปัญหาเกี่ยวกับการตีความ คำแนะนำในการทดสอบกับ CMA โดยตรง
การใช้ API	Chrome จะอนุญาตให้เรียก addAdInterestGroup() ในหน้าว่างขณะเปลี่ยนเส้นทางไปยังทรัพยากรอื่นหรือไม่	หากผู้ใช้กำลังเข้าชมเว็บไซต์บางแห่ง เจ้าของเว็บไซต์จะมอบสิทธิ์ในการเรียกใช้ JoinAdInterestGroup ไปยังบุคคลที่สามได้ การมอบสิทธิ์นี้ช่วยให้บุคคลที่สามสร้าง IG ได้โดยไม่ต้องเพิ่มการเปลี่ยนเส้นทางใดๆ ผ่านหน้าว่าง เรายินดีรับฟังความคิดเห็นเกี่ยวกับเหตุผลที่เจาะจงในการสร้าง IG ในระหว่างการเปลี่ยนเส้นทางแทนการใช้กลไกการมอบสิทธิ์ที่ต้องการ
การใช้ API	Exchange ควรเขียน IG ลงบนหน้าเว็บของผู้เผยแพร่โฆษณาที่ผู้เผยแพร่โฆษณาร่วมงานด้วยเป็นเจ้าของ และพวกเขาสามารถมอบสิทธิ์ในการเสนอราคาบน IG ดังกล่าวให้กับผู้ซื้อหรือ DSP ที่ต้องการได้	เราได้รับฟีดแบ็กและกำลังประเมินว่าคำขอดังกล่าวอาจได้รับการสนับสนุนหรือไม่ เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การใช้ API	ไม่มีการแจ้งเตือนการสูญเสียการแก้ไขข้อบกพร่องหากไม่มีใครชนะการประมูล PA API	ฟังก์ชัน reportWin และ report Results ของ Chrome ออกแบบมาสำหรับการรายงานที่ชนะในระดับเหตุการณ์ภายในระบบการประมูลความเป็นส่วนตัว (PA) ในกรณีที่การเสนอราคาทั้งหมดถูกปฏิเสธระหว่างการประมูล PA จะไม่มีการเรียกใช้ฟังก์ชันเหล่านี้เนื่องจากไม่มีการกำหนดผู้ชนะ การอัปเดต Chrome ครั้งล่าสุดอาจอธิบายความคลาดเคลื่อนของตำแหน่งที่ URL ที่ส่งไปยัง forDebuggingOnly.reportAdAuctionLoss() จะไม่ปรากฏในแผงเครือข่าย DevTools เราขอแนะนำให้ยืนยันฟังก์ชันนี้โดยใช้เวอร์ชัน Canary หรือเวอร์ชันที่กำลังพัฒนาของ Chrome
การใช้ API	adCost ที่ส่งคืนจาก generateBid จะเป็นค่าลบได้ไหม (มีการปัดเศษแบบโครงสร้างเป็น 2 ไบต์แล้ว)	AdCost คือการคลิกหรือต้นทุน Conversion ของผู้ลงโฆษณาที่ส่งผ่านจาก generateBid() ไปยัง reportWin() ค่านี้อาจเป็น Null หรือ 2 เท่า ระบบจะไม่สนใจค่าเชิงลบและไม่ส่งผ่าน ค่าจะถูกปัดเศษแบบสโตสโตรกเมื่อส่งผ่าน
การปรับปรุง API	สามารถใช้เซิร์ฟเวอร์การดำเนินการที่เชื่อถือได้และเข้ารหัสเพื่อจัดการการกำหนดเป้าหมาย / กลุ่มประชากรตามรุ่น / การระบุแหล่งที่มา และการประมูลแทนเบราว์เซอร์ Chrome ได้ไหม	เราขอแนะนำให้สำรวจคอมโพเนนต์และตัวเลือกที่ใช้ TEE ใน PA API (เช่น เซิร์ฟเวอร์ KV และบริการ B&A) รวมถึงองค์ประกอบที่ใช้ TEE ของ Attribution Reporting และการรวมแบบส่วนตัว (เช่น Aggregation Service) ซึ่งตอบคำถามนี้
การปรับปรุง API	การตอบกลับการประมูล Privacy Sandbox สามารถเป็นการเสนอราคาตอบ (เช่น การเสนอราคาส่วนหัว) แทนการตอบกลับโฆษณา (เช่น แท็กโฆษณา) ได้ไหม	โดยพื้นฐานแล้ว การเปลี่ยนแปลงประเภทนี้จะเปลี่ยนแปลงคุณสมบัติด้านความเป็นส่วนตัวของ PA API จึงไม่สามารถเปลี่ยนแปลงได้
การควบคุมผู้เผยแพร่โฆษณา	ผู้เผยแพร่โฆษณาจะบล็อกครีเอทีฟโฆษณา PA API ในหน้าเว็บของตนได้ไหม	Chrome มีข้อเสนอสำหรับการสแกนครีเอทีฟโฆษณาแบบเรียลไทม์ซึ่งยังไม่พร้อมสำหรับการทดสอบ แม้ฟีเจอร์นี้จะยังไม่พร้อมใช้งาน แต่เราพบว่า SSP ส่วนใหญ่ได้สร้างโซลูชันเพื่อรองรับการใช้งานนี้
การใช้ API	perBuyerSignals จำกัดขนาดเท่าใด	ในรูปแบบคลาสสิก PerBuyerSignals ไม่มีข้อจำกัดด้านขนาดตามปกติใน Chrome ข้อจำกัดหลักคือข้อมูลยังคงเป็นอนุกรม JSON และไม่ทำให้เกิดการใช้หน่วยความจำมากเกินไป อย่างไรก็ตาม โปรดทราบว่า PerBuyerSignals ที่มีขนาดใหญ่และซับซ้อนอาจส่งผลเสียต่อประสิทธิภาพ มีอีกวิธีในการส่งผ่าน PerBuyerSignals ผ่านdirectFromSellerSignalsHeaderAdSlot วิธีการนี้จะส่ง PerBuyerSignals ภายในส่วนหัว โดยมีขีดจำกัดขนาดสูงสุด 10 KB สำหรับการตอบสนองของส่วนหัวทั้งหมด นอกจากนี้ เซิร์ฟเวอร์แต่ละรายการอาจกำหนดข้อจำกัดของตัวเองเกี่ยวกับขนาดส่วนหัวสูงสุด
เอกสารประกอบ	ต้องเปลี่ยนแปลงเอกสารประกอบเกี่ยวกับ {1}callAdBeacon จากภายใน generateBid	เราอัปเดตเอกสารประกอบ นี้เมื่อวันที่ 17 กุมภาพันธ์
การใช้ API	reportEvent เลือก URL บีคอนที่ถูกต้องจากตัวเลือกที่บันทึกไว้หลายรายการได้อย่างไร	การประมูลแต่ละครั้งจะส่งผลให้เกิดการกําหนดค่าแยกกัน ซึ่งส่งผลให้แผนที่การรายงานแยกกัน การประมูลแต่ละครั้ง (และเฟรมที่เป็นผลลัพธ์) จะแยกออกจากกันอย่างสิ้นเชิงและไม่แชร์ข้อมูล คำอธิบาย "การรายงานโฆษณาเฟรมที่มีการปิดกั้น" จะให้รายละเอียดเพิ่มเติมเกี่ยวกับหัวข้อนี้
UI ของ Chrome	เพิ่มตัวกรองใน "แอปพลิเคชัน -> แท็บ "กลุ่มความสนใจ" ใน Chrome DevTools เพื่อให้กรองตามเจ้าของ IG ได้ (หรืออาจกรองตามชื่อ IG ก็ได้)	เรากำลังประเมินคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
Chrome แบบ Headless	การรองรับ PA API ใน Chrome แบบ Headless	มีคอมโพเนนต์บางอย่างของ PA API ที่ผูกกับ Chrome เช่น การเรียกใช้ K-anon ไปยังเซิร์ฟเวอร์ของ Google ซึ่งอาจใช้งานไม่ได้ใน Chrome แบบ Headless "แบบเก่า" เราเชื่อว่าปัญหานี้อาจเกิดจาก Chrome เวอร์ชัน "ใหม่" ที่เปิดตัวใน Chrome 112
การใช้ API	ในกรณีของการรายงานการสูญหายด้วย reportAdAuctionLoss เราเห็น "topLevelWinningBid=0" ในหลายกรณี การตีความของสิ่งนี้คืออะไร	ค่า topLevelWiningBid จะมาจากฟังก์ชัน 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-anonymity เราเข้าใจความกังวลที่หยิบยกขึ้นมาเกี่ยวกับผลกระทบด้านความเป็นส่วนตัวที่อาจเกิดขึ้นจากตัวระบุดังกล่าว แม้ว่าการใช้งานในช่วงแรกของเราจะใช้ตัวระบุเอนโทรปีต่ำเป็นกลไกป้องกันการละเมิด แต่เรากำลังสำรวจเทคนิคทางเลือกอื่นๆ เช่น โทเค็นการนับที่ไม่ระบุชื่อ ซึ่งให้ความสำคัญกับความเป็นส่วนตัวของผู้ใช้ในขณะที่ยังคงความสมบูรณ์ของระบบ เรามุ่งมั่นที่จะหาโซลูชันที่สร้างสมดุลระหว่างการใช้ข้อมูลอย่างมีความรับผิดชอบกับการคุ้มครองความเป็นส่วนตัวที่มีประสิทธิภาพ และเรายินดีพูดคุยกับชุมชนการวิจัยอย่างต่อเนื่อง เราพูดคุยกันเรื่องนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	AMP (Accelerated Mobile Pages) รองรับ PA API หรือไม่	ปัจจุบัน AMP ยังไม่รองรับ PA API ตั้งแต่แรก เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศหากการสนับสนุนโดย AMP มีความสำคัญมาก
การปรับปรุง API	ลองนําประเภทออกจากการตรวจสอบ k-anonymity	เรากําลังพิจารณาความคิดเห็นเกี่ยวกับการเพิ่มประสิทธิภาพโครงสร้างคําขอ k-anonymity ที่อาจเกิดขึ้น เราเข้าใจคำแนะนำในการรวมพารามิเตอร์ และอาจรวมประเภทต่างๆ เข้าด้วยกันเพื่อให้กระบวนการมีประสิทธิภาพมากขึ้น เป้าหมายของเราคือการมั่นใจถึงประสิทธิภาพและการบำรุงรักษา และเรากำลังประเมินตัวเลือกทั้งหมดในขณะที่พัฒนาโซลูชันด้านความเป็นส่วนตัวของเราต่อไป เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
UI ของ Chrome	ขอกลไกให้ผู้ใช้ที่ไม่เชี่ยวชาญด้านเทคนิคดูและจัดการ IG ที่ตนอยู่ได้อย่างง่ายดาย รวมถึงการควบคุมระดับเว็บไซต์ที่เป็นไปได้สำหรับการเลือกไม่ใช้	เราตระหนักถึงความสำคัญของการให้บริการเครื่องมือที่ใช้ง่ายเพื่อทำความเข้าใจและจัดการ IG เราได้พิจารณาวิธีการต่างๆ อย่างรอบคอบแล้ว และพบว่าการระบุ IG ตามเว็บไซต์ที่เข้าร่วมนั้นให้สมดุลระหว่างความชัดเจนกับการคุ้มครองความเป็นส่วนตัวที่ดีที่สุด ปัจจุบันการจัดการส่วนกลางของ IG จะอยู่ในการตั้งค่าของ Chrome เรากำลังสำรวจวิธีการปรับปรุงประสบการณ์ของผู้ใช้ในด้านนี้อย่างต่อเนื่อง เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
ความปลอดภัยของ API	PA API มีความเสี่ยงที่จะรั่วไหลเรื่องความเป็นส่วนตัวผ่านการโต้ตอบกับโฆษณาครีเอทีฟโฆษณา แม้จะอยู่ในบริบทของ Fenced Frames หรือไม่	เรารับทราบถึงโอกาสที่จะเกิดการรั่วไหลของข้อมูลผ่านการโต้ตอบกับโฆษณาที่ซับซ้อน เรากำลังตรวจสอบความสัมพันธ์ระหว่าง Fenced Frame, PA API และเวกเตอร์การโจมตีที่อาจเกิดขึ้นอย่างต่อเนื่อง การลดความเสี่ยงด้านความเป็นส่วนตัวมีความสำคัญสูงสุด และเรามุ่งมั่นที่จะพัฒนาโซลูชันที่มีประสิทธิภาพที่ช่วยรักษาสมดุลระหว่างนวัตกรรมกับการปกป้องผู้ใช้ เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
เวลาในการตอบสนอง	ค่าเริ่มต้นการหมดเวลา 50 มิลลิวินาทีสำหรับตรรกะการเสนอราคาของผู้ซื้อเป็นค่าจริงหรือไม่	เรารับทราบข้อกังวลเกี่ยวกับความไม่สอดคล้องที่อาจเกิดขึ้นระหว่างข้อกำหนดกับระยะเวลาของคำขอเครือข่ายสำหรับตรรกะการเสนอราคา เรากําลังตรวจสอบข้อกําหนดต่างๆ อย่างต่อเนื่องเพื่อความแม่นยําและตรวจสอบการตั้งค่าระยะหมดเวลาเริ่มต้นที่เหมาะสมที่สุด เพื่อสร้างความสมดุลระหว่างประสิทธิภาพและความเป็นไปได้ เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
เอกสารประกอบ	ช่วงเวลาที่อาจรั่วไหลในข้อกำหนดที่เว็บไซต์สามารถอนุมานได้ว่าโฆษณาไม่ผ่านเกณฑ์ k-anonymity หรือไม่ และผลกระทบที่อาจเกิดขึ้นสำหรับการติดตามข้ามเว็บไซต์	เราทราบถึงปัญหานี้เกี่ยวกับความล่าช้าของเวลาที่อาจเกิดขึ้น เราได้ยืนยันความคลาดเคลื่อนในข้อกำหนดแล้ว และกำลังดำเนินการเพื่อให้มั่นใจว่าสถานะ k-anonymity ของโฆษณาจะได้รับการกำหนดก่อนการประมูลเพื่อป้องกันการรั่วไหลดังกล่าว เราให้ความสําคัญกับข้อกังวลเหล่านี้และจะอัปเดตข้อกําหนดเพื่อให้สอดคล้องกับการเปลี่ยนแปลงเหล่านี้ เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	วิธีใช้รายการที่บล็อก SSP ภายใน PA API	เราตระหนักถึงความจำเป็นของกลไกในการจัดการข้อจำกัดด้านโฆษณาโดย SSP เราขอแนะนําให้สํารวจโซลูชันที่ให้ความสำคัญกับการประเมินในอุปกรณ์และใช้ประโยชน์จากข้อมูลเมตาของโฆษณาที่มีอยู่เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้ ในขณะเดียวกันก็มีความยืดหยุ่น เรามุ่งมั่นที่จะทำงานร่วมกับนักพัฒนาแอปเพื่อค้นหาแนวทางที่มีประสิทธิภาพภายใน PA API เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	คนอื่นสามารถบอกเบราว์เซอร์ให้แสร้งทำเป็นทำ PA API ในลักษณะที่เว็บไซต์ตรวจไม่พบได้หรือไม่	เรารับทราบว่าในรูปแบบปัจจุบันของกระบวนการเลือกไม่ใช้ PA API อาจตรวจพบได้โดยเว็บไซต์ เรากําลังทํางานอย่างต่อเนื่องในฟีเจอร์ต่างๆ เช่น ราคาเสนอเพิ่มเติมและการกำหนดเป้าหมายเชิงลบ รวมถึงการแสดงผลเฟรมที่มีการปิดกั้น เพื่อเพิ่มความเป็นส่วนตัวและพยายามมอบตัวเลือกในการเลือกไม่ใช้ที่ตรวจจับไม่ได้ เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การทดสอบ A/B ในโหมด	การรับส่งข้อมูลของศูนย์ข้อมูลที่อ้างว่าเป็นการปฏิบัติ 1.1	ทีม Chrome ได้ยืนยันกับทีม GAM ว่าการเข้าชมนี้ได้รับการกรองออกจากการทดสอบแล้ว เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	ประสิทธิภาพและความยุติธรรมของการติดตั้งใช้งานInterestGroupBuyers ใน PA API	เราได้รับการพูดคุยกันอย่างต่อเนื่องเกี่ยวกับประสิทธิภาพและความเป็นธรรมของฟิลด์ "interestGroupBuyers" ในการประมูล PA API เรารับทราบถึงข้อดีข้อเสียระหว่างประสิทธิภาพ ความเป็นส่วนตัว และความยุติธรรมในตลาด แม้ว่าผู้ขายจำเป็นต้องจัดการความสัมพันธ์ทางธุรกิจกับผู้ซื้อ เรากำลังสำรวจวิธีเพิ่มประสิทธิภาพกระบวนการจับคู่ ซึ่งอาจรวมถึงการปรับแบบไดนามิกตามข้อมูลแบบเรียลไทม์และโมเดลแบบผสม เรายังคงมุ่งมั่นที่จะหาโซลูชันที่ให้ความสำคัญกับความเป็นส่วนตัวของผู้ใช้และสนับสนุนระบบนิเวศการโฆษณาที่มีความสามารถในการแข่งขัน เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
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 ของคำแนะนำไคลเอ็นต์	เรากำลังติดตามคำขอฟีเจอร์นี้ที่นี่
การใช้ API	ไฟล์การมอบสิทธิ์ควรกำหนดให้ส่วนหัว "Access-Control-Allow-Origin" ต้องโหลดหรือไม่ ทั้งนี้เพื่อกำหนดลักษณะการเป็นสมาชิก IG สำหรับเบราว์เซอร์	เรามุ่งมั่นที่จะปฏิบัติตามแนวทางปฏิบัติแนะนำด้านความปลอดภัยบนเว็บ การกำหนดส่วนหัว "Access-Control-Allow-Origin" สำหรับไฟล์การมอบสิทธิ์จะช่วยให้มั่นใจว่าสอดคล้องกับหลักการ CORS และป้องกันการเปิดเผยข้อมูลที่ละเอียดอ่อนโดยไม่ได้ตั้งใจ เรากำลังสำรวจวิธีเพิ่มประสิทธิภาพกระบวนการนี้ไปพร้อมกับรักษาระดับการรักษาความปลอดภัยที่เข้มงวด เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	เปิดใช้เซิร์ฟเวอร์โฆษณาเพื่อปรับเปลี่ยนครีเอทีฟโฆษณาในแบบของคุณภายในเฟรมเวิร์ก PA API	เราตระหนักดีว่าเซิร์ฟเวอร์โฆษณามีบทบาทอย่างไรในการปรับโฆษณาตามโปรไฟล์ของผู้ใช้ เรากําลังสํารวจโซลูชันต่างๆ ที่จะเพิ่มประสิทธิภาพให้เซิร์ฟเวอร์โฆษณาภายใน PA API เช่น รูปแบบ "joint IG" ที่สามารถรวมตรรกะการเสนอราคาและการเลือกครีเอทีฟโฆษณาเข้าด้วยกัน เป้าหมายของเราคือการสร้างความสมดุลระหว่างการใช้ประโยชน์จากความสามารถด้านครีเอทีฟโฆษณาที่มีประสิทธิภาพและการปกป้องความเป็นส่วนตัวของผู้ใช้ เรายินดีรับฟังและเสนอความคิดเห็นเพิ่มเติมเกี่ยวกับการพัฒนา API ให้ตอบโจทย์ความต้องการของผู้มีส่วนเกี่ยวข้องทุกฝ่ายที่นี่
ข้อกังวลเกี่ยวกับข้อมูลส่วนบุคคล	ความพร้อมใช้งานของตัวระบุอื่นๆ (เช่น RampID, ID5) ในคําขอราคาเสนอตามบริบทอาจส่งผลเสียต่อเป้าหมายด้านความเป็นส่วนตัวของ PA API ด้วยการอำนวยความสะดวกในการเก็บรวบรวมข้อมูลข้ามเว็บไซต์	เราทราบถึงความตึงเครียดที่อาจเกิดขึ้นระหว่างตัวระบุข้ามเว็บไซต์และวัตถุประสงค์ด้านความเป็นส่วนตัวของ PA API แม้ว่าผู้เผยแพร่โฆษณาเลือกที่จะแชร์ตัวระบุดังกล่าวได้ แต่โดยพื้นฐานแล้ว การออกแบบของ PA API ก็มุ่งเน้นที่การแยกการเลือกโฆษณาจากความจำเป็นในการติดตามข้ามเว็บไซต์ เรามุ่งมั่นที่จะส่งเสริมระบบนิเวศการโฆษณาที่มุ่งเน้นความเป็นส่วนตัวและส่งเสริมให้นักพัฒนาแอปให้ความสำคัญกับแนวทางของ PA API เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การแคช	มีวิธีป้องกันไม่ให้มีการใช้สคริปต์การเสนอราคาซ้ำในการประมูลหลายครั้งหรือไม่	เรารับทราบลักษณะการแคชสคริปต์การเสนอราคาที่พบภายในเฟรมเวิร์กของ PA API แม้ว่าจะรองรับกลไกการแคช HTTP แบบมาตรฐาน แต่ก็มีโอกาสที่จะนำสคริปต์มาใช้ซ้ำในการประมูลตามลักษณะการทำงานของการระงับอุปกรณ์และการออกแบบของผู้ดำเนินการเสนอราคา ทีมงานกำลังตรวจสอบโซลูชันที่จะช่วยให้ผู้ซื้อควบคุมการแคชสคริปต์ได้มากขึ้นเพื่อจัดการกลยุทธ์การเสนอราคาอย่างมีประสิทธิภาพ เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	รวมการรายงานกิจกรรมการเสนอราคาใน IG ทั้งหมดไว้ในที่เดียวสำหรับ DSP โดยที่ยังเคารพความเป็นส่วนตัวของผู้ใช้	เราให้ความสำคัญกับความเป็นส่วนตัวของผู้ใช้เมื่อออกแบบ PA API แม้ว่าการรายงานโดยตรงของเหตุการณ์การเสนอราคาแต่ละรายการจะไม่สามารถทำได้เนื่องจากมีความเสี่ยงในการติดตามข้ามเว็บไซต์ แต่เรามีกลไก เช่น พื้นที่เก็บข้อมูลที่ใช้ร่วมกันและการรวมส่วนตัว สิ่งเหล่านี้ช่วยให้ DSP สามารถทราบข้อมูลเชิงลึกที่รวบรวมไว้เกี่ยวกับกิจกรรมการเสนอราคาในลักษณะที่สนับสนุนความเป็นส่วนตัวของผู้ใช้
การใช้ API	การดึงข้อมูลจาก sendReportTo() ใน report Results() จะเกิดขึ้นเพียง 94% จากจำนวนครั้งทั้งหมดที่เกี่ยวข้องกับการดึงข้อมูลที่ลงทะเบียนกับ forDebuggingOnly.reportAdAuctionWin()	แม้ว่าอาจมีช่วงเวลาไม่เท่ากัน แต่ระบบก็ดึงข้อมูลของ URL ทั้ง 2 รายการพร้อมกันได้ ในบางกรณี เวิร์กเล็ตของผู้ขายคอมโพเนนต์ได้ถูกกำจัดไปแล้วและต้องโหลดซ้ำเพื่อเรียกใช้ฟังก์ชัน report Results() อย่างไรก็ตาม ทั้งเวลาที่ใช้ในการดึงข้อมูลตรรกะการให้คะแนนและเวลาที่เวิร์กเล็ตจะโหลดใหม่จะไม่มีผลกับการหมดเวลา 50 มิลลิวินาทีสำหรับ report Results() โปรดทราบว่า Chrome จะใช้ส่วนหัวการแคชเพื่อกำหนดลักษณะการดึงข้อมูล ในกรณีที่จำเป็นต้องโหลดเวิร์กเลตใหม่ คุณสามารถดูข้อมูลเพิ่มเติมเกี่ยวกับขั้นตอนต่างๆ ของการประมูล PA ได้ที่นี่
K-anonymity	คําขอยืนยันว่าชื่อของInterestGroup ไม่มีผลกับ k-anonymity ของการแสดงโฆษณา	ครีเอทีฟโฆษณาจะถือว่าไม่ระบุชื่อ k-ไม่ระบุชื่อ แถบเครื่องมือของ URL ของเจ้าของ IG, URL สคริปต์การเสนอราคา, URL ครีเอทีฟโฆษณา และขนาดโฆษณาต้องตรงตามเกณฑ์ที่ระบุ (k) ในช่วงเวลาที่ผ่านมา (w) สถานะ k-anonymity จะอัปเดตเป็นระยะๆ (p)
UI ของ Chrome	ข้อเสนอที่จะระบุประเภท "ระดับการเข้าถึงภายใน" ที่เฟรมเวิร์ก MVC, ORM ฯลฯ มีให้ เช่น เริ่มด้วยการบันทึกเหตุการณ์ภายในที่เลือกอย่างง่ายๆ ไปยังแผงใหม่ในเครื่องมือสำหรับนักพัฒนาเว็บ --> แอปพลิเคชัน --> ส่วนแอปพลิเคชัน	เราพูดคุยเกี่ยวกับข้อเสนอที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
UI ของ Chrome	การเข้าร่วม IG เครื่องมือสำหรับนักพัฒนาเว็บไม่แสดงองค์ประกอบที่เกี่ยวข้องกับลำดับความสำคัญ	เราได้แก้ไขปัญหานี้แล้วที่นี่
การปรับปรุง API	จะเป็นการดีหากอนุญาตให้เซิร์ฟเวอร์โฆษณาครีเอทีฟโฆษณาติดตามเหตุการณ์ของตนเอง ฉันสามารถกำหนดค่ารายการโดเมนการติดตามที่อนุญาตได้ไหม	เราได้แชร์ข้อเสนอไว้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
คำขอฟีเจอร์ API	PA API สามารถขยายการรองรับธุรกรรมสื่อที่ไม่ใช่ RTB และคง Use Case ที่สำคัญ เช่น การแสดงโฆษณาและ DCO ได้ไหม	เราพูดคุยเกี่ยวกับปัญหาที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
หมดเวลาประมูลของผู้เผยแพร่โฆษณา	ผู้เผยแพร่โฆษณาต้องการควบคุมระยะเวลาการประมูลเพื่อป้องกันไม่ให้สูญเสียการแสดงผล โดยเฉพาะในการตั้งค่าการเสนอราคาส่วนหัวซึ่งมีการเลือกโฆษณาตามลำดับ	เราตระหนักถึงความสำคัญของการให้ผู้เผยแพร่โฆษณาควบคุมระยะหมดเวลาในการประมูลเพื่อแสดงโฆษณาได้อย่างละเอียด เรากําลังสํารวจหาวิธีติดตั้งใช้งานกลไกการหมดเวลาประมูลทั่วโลก ซึ่งอาจอยู่ในออบเจ็กต์ "auctionConfig" พร้อมกับพิจารณากรณีที่เป็นปัญหาที่สุดอย่างรอบคอบ ฟีเจอร์นี้มีเป้าหมายเพื่อเพิ่มประสิทธิภาพอัตราการส่งโฆษณาสำหรับผู้เผยแพร่โฆษณา และเราจะทำงานร่วมกับชุมชนต่อไปเพื่อค้นหาโซลูชันที่ดีที่สุด เราพูดคุยเกี่ยวกับปัญหาที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การปรับปรุง API	การออกแบบ IG ในปัจจุบันใน PA API จะทำให้มีข้อมูลเมตาขนาดใหญ่เนื่องจากแย้ง URL ที่ยาวเกินไป ผู้ทดสอบต้องการวิธีบีบอัด URL เหล่านี้ให้มีประสิทธิภาพมากขึ้น	เราตระหนักถึงความสำคัญของการเพิ่มประสิทธิภาพของขนาดข้อมูลเมตาของ IG โดยเฉพาะสำหรับการประมูลเพื่อแสดงโฆษณาที่ละเอียดอ่อนอย่างมีประสิทธิภาพ เราคิดว่าโซลูชันที่ใช้เทมเพลตสำหรับการบีบอัดRenderURL จะสร้างศักยภาพที่มีศักยภาพสูง เราจะประเมินการออกแบบเทมเพลตที่เสนออย่างรอบคอบ และตรวจสอบว่าโซลูชันที่นำมาใช้มีกลไกป้องกันการละเมิดที่มีประสิทธิภาพเพื่อรักษาความเสถียรของเบราว์เซอร์ การทำงานร่วมกับชุมชนมาตรฐานเว็บเพื่อพัฒนาแนวทางที่ดีที่สุดโดยคำนึงถึงข้อควรพิจารณาเหล่านี้ยังคงเป็นสิ่งสำคัญ เราพูดคุยเกี่ยวกับปัญหาที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	ผู้ทดสอบที่จัดการรูปแบบโฆษณาเนทีฟต้องการเพิ่มประสิทธิภาพให้กระบวนการประมูลของ Privacy Sandbox โดยการเรียกผลลัพธ์โฆษณาหลายรายการในการเรียกครั้งเดียวเพื่อลดการโหลดของเครือข่ายและเพิ่มความเร็วในการแสดงโฆษณา	เราทราบถึงความกังวลเกี่ยวกับประสิทธิภาพที่เกิดขึ้นสำหรับการแสดงผลโฆษณาเนทีฟใน Privacy Sandbox เรามุ่งมั่นที่จะหาสมดุลระหว่างประสิทธิภาพกับการคุ้มครองความเป็นส่วนตัวของผู้ใช้ที่แข็งแกร่ง แม้ว่าการแสดงโฆษณาหลายรายการที่มีคะแนนเต็มจะส่งผลต่อความเป็นส่วนตัว แต่เราก็ยังพยายามหาวิธีเพิ่มประสิทธิภาพให้กับกระบวนการประมูลอยู่อย่างเต็มที่ เรามุ่งมั่นยกระดับการรองรับ PA API สำหรับรูปแบบโฆษณาเนทีฟ พร้อมทั้งศึกษากลไกอื่นๆ ที่จะปรับปรุงประสิทธิภาพภายใต้ข้อจำกัดด้านความเป็นส่วนตัวที่เข้มงวดของ Privacy Sandbox เราพูดคุยเกี่ยวกับปัญหาที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
การใช้ API	ความยืดหยุ่นในการให้คะแนนและจัดเรียงราคาเสนอโฆษณาภายใน Privacy Sandbox โดยเฉพาะเพื่อแสดงระดับความสำคัญหรือกฎตลาดกลางส่วนตัว	เราเข้าใจถึงความจำเป็นในการควบคุมการให้คะแนนและการจัดเรียงโฆษณาอย่างละเอียดภายใน Privacy Sandbox โดยเฉพาะอย่างยิ่งในสถานการณ์การเสนอราคาที่ซับซ้อน เรารับทราบถึงโซลูชันที่เสนอโดยใช้ฟังก์ชัน Tuples และฟังก์ชันทางคณิตศาสตร์เพื่อให้ได้การให้คะแนนแบบหลายมิติโดยไม่ส่งผลกระทบต่อความเป็นส่วนตัวของผู้ใช้ แม้ว่าแนวทางเหล่านี้อาจเพิ่มความซับซ้อนให้นักพัฒนาแอป แต่ก็ช่วยมอบการแสดงออกที่จำเป็นได้ เรามุ่งมั่นสำรวจวิธีต่างๆ ที่จะปรับปรุงกระบวนการเหล่านี้ ซึ่งอาจผ่านฟังก์ชันหรือหลักเกณฑ์ตัวช่วย เพื่อให้แน่ใจว่าจะมีการใช้ฟีเจอร์ Privacy Sandbox ที่ดีที่สุดสำหรับตรรกะการประมูลขั้นสูง เรามีการพูดคุยเกี่ยวกับปัญหานี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
reportEvent()	เพิ่มเหตุการณ์ใหม่ที่จองไว้ (อาจจะเป็นบีคอนอัตโนมัติ) ที่เบราว์เซอร์เริ่มทำงานเมื่อเฟรมที่มีครีเอทีฟโฆษณาเริ่มต้นทำงานแล้ว	เราพูดคุยเกี่ยวกับคำขอนี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
adCost	การอนุญาตรายละเอียดค่าใช้จ่ายโฆษณา	ค่าต้นทุนแต่ละค่าคือโอกาสในการส่งข้อมูลในจำนวนที่จำกัดออกจากการประมูล การอนุญาตรายการค่าใช้จ่ายทั้งหมด N รายการเหล่านั้นก็เพียงพอที่จะส่งตัวระบุผู้ใช้ทั้งรายการได้ ซึ่งจะเป็นการเปิดใช้การติดตามข้ามเว็บไซต์ เราพูดคุยกันเรื่องนี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
resolveToConfig	ควรรับการแก้ไขToConfig มาจากระดับบนสุดและแสดงใน browserSignals ไหม	เราพูดคุยเกี่ยวกับคำขอนี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม
เครื่องมือที่ดีกว่า	มีอะไรที่คล้ายกับ chrome://topics-internals แต่สำหรับ PA API หรือไม่	ไม่มีอะไรเหมือนกันทุกประการ อย่างไรก็ตาม มีเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ที่หลากหลายสำหรับ PA API
ป้ายกำกับ	Chrome สามารถใช้ป้ายกำกับเพื่อระบุประชากร K-Anon 20% ได้ไหม	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
เอกสารประกอบ	Worklet การประมูล Privacy Sandbox จะกลายเป็นประเภท Worklet มาตรฐานไหม	เนื่องจากข้อกำหนดด้านความเป็นส่วนตัวและความปลอดภัยที่ไม่ซ้ำกัน Worklet เหล่านี้แตกต่างจากประเภท Worklet เบราว์เซอร์มาตรฐานอย่างมาก เราจึงไม่คิดว่าเวิร์กเล็ตเหล่านั้นจะกลายมาเป็นประเภท Worklet มาตรฐานภายในข้อกำหนด HTML ในเร็วๆ นี้ เรามุ่งมั่นปรับปรุงทรัพยากรสำหรับนักพัฒนาซอฟต์แวร์โดยมีคำอธิบายที่ชัดเจนเกี่ยวกับการใช้งานและสภาพแวดล้อมการดำเนินการของ Worklet การประมูล เพื่อให้ผู้เข้าร่วม Privacy Sandbox สามารถเข้าถึงข้อมูลนี้ได้มากขึ้น เราได้พูดคุยเรื่องนี้เพิ่มเติมที่นี่
เซิร์ฟเวอร์คีย์-ค่า (KV) สำหรับ Bring-Your-Own Server (BYOS)	คู่สัญญาอาจเรียนรู้ IG หลายรายการ (จากเจ้าของคนเดียวกัน) ที่มีการเข้าร่วมโดยผู้ใช้ผ่านการค้นหาบริการ KV ในการตั้งค่าบริการ BYOS KV	การดำเนินการนี้จะไม่สามารถทำได้อีกต่อไปเมื่อเซิร์ฟเวอร์ 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 และ GCP ได้ออกแบบและใช้การลดความเสี่ยงในการเข้าถึงทางกายภาพ รวมถึงจากพนักงานด้วย โปรดดูรายละเอียดเพิ่มเติมเกี่ยวกับการสนับสนุนภายในองค์กรด้านล่าง เทคโนโลยีโฆษณาบอกเราว่าการใช้งานบริการระบบคลาวด์มีราคาแพงกว่าศูนย์ข้อมูลเทคโนโลยีโฆษณาภายในองค์กร แม้เราจะไม่อยู่ในฐานะที่จะประเมินใบแจ้งยอดเหล่านั้น แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับค่าใช้จ่ายและประเมินทางเลือกต่างๆ ในการขยายการรองรับ TEE ต่อไป
เสื้อยืด	การสนับสนุนสำหรับ TEE ในสภาพแวดล้อมระบบคลาวด์ที่ไม่ใช่สาธารณะ	การตอบสนองของเราคล้ายกับไตรมาสก่อนๆ: แม้ว่าเราจะเดินหน้าค้นหาการสนับสนุนสำหรับตัวเลือกที่นอกเหนือจากโซลูชันระบบคลาวด์สาธารณะ แต่เรายังไม่มีแผนที่จะรองรับ TEE ภายในองค์กรในขณะนี้ ในขั้นนี้ เมื่อพิจารณาจากข้อกำหนดด้านความปลอดภัยของ Privacy Sandbox และความท้าทายที่สำคัญจากการติดตั้งใช้งานภายในองค์กร เราเชื่อว่าการขยายและปรับปรุงการติดตั้งใช้งานในระบบคลาวด์ (เช่น การรองรับ Google Cloud และ AWS) จะเป็นประโยชน์ต่อระบบนิเวศมากที่สุด อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับสาเหตุที่ข้อกำหนดดังกล่าวจำเป็นและเป็นไปได้เนื่องจากมีข้อจำกัดด้านความเป็นส่วนตัวและความปลอดภัย
ผู้ให้บริการคลาวด์รายอื่น	การสนับสนุนสำหรับผู้ให้บริการคลาวด์รายอื่น	เราเปิดรับคำแนะนำจากผู้ให้บริการคลาวด์รายอื่นอยู่เสมอ แต่ในตอนนี้เรามีแผนที่จะรองรับ GCP และ AWS เป็นอย่างน้อยเมื่อบังคับใช้ 3PCD ดูข้อมูลเพิ่มเติมได้ในคำอธิบายนี้
API บริการ B&A	Google มีทิศทางอย่างไรในการใช้ B&A Services API ระบบจะจัดลำดับความสำคัญให้สูงกว่าหรือต่ำกว่ากลุ่มเป้าหมายที่มีการป้องกันของเบราว์เซอร์ Chrome ในการประมูลอุปกรณ์หรือไม่	การตอบสนองของเราคล้ายกับไตรมาสก่อนๆ ดังนี้ เรายังคงยึดมั่นในการออกแบบการเสนอราคาในอุปกรณ์สำหรับ Protected Audience ในปัจจุบัน มีการเสนอบริการ B&A เพื่อสำรวจโซลูชันที่เป็นไปได้เพื่อสนับสนุนกรณีการใช้งานบางส่วนที่อุปกรณ์อาจจำกัดกำลังในการประมวลผลหรือความเร็วของเครือข่าย
การกำหนดมาตรฐาน	บริการ B&A ยังไม่ได้ผ่านกระบวนการกำหนดมาตรฐาน	ข้อเสนอบริการ B&A อยู่ในระยะกลางของกระบวนการกำหนดมาตรฐาน และเรายินดีรับการมีส่วนร่วมเพิ่มเติมเพื่อสนับสนุนเป้าหมายดังกล่าว โดยเริ่มต้นจากข้อเสนอ (จากข้อเสนอก่อนหน้า) ซึ่งจะได้รับการบ่มเพาะต่อสาธารณะผ่านการพูดคุยแบบเปิดที่ W3C และนักพัฒนาแอปที่สนใจสามารถเริ่มทดลองใช้ข้อเสนอและแสดงความคิดเห็นได้ นี่คือรูปแบบปกติของการพัฒนาฟีเจอร์บนเว็บ ตามที่อธิบายไว้ในบล็อกโพสต์ของเราที่นี่
เซิร์ฟเวอร์ KV	แสดง URL แบบเต็มไปยังเซิร์ฟเวอร์ KV ของผู้ซื้อสำหรับการกำหนดเป้าหมายเนื้อหา / บริบท / ไซต์	เราพูดคุยเกี่ยวกับคำขอนี้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
เอกสารประกอบ	เอกสารประกอบเกี่ยวกับ "คอมโพเนนต์ที่เชื่อถือได้/บังคับใช้กับทางเลือก" ใน GitHub ก่อให้เกิดความสับสนกับเทคโนโลยีโฆษณาบางรายที่มีชุดอิมเมจการทำให้ใช้งานได้และโครงสร้างพื้นฐานของตนเอง	เรากำลังหาวิธีปรับปรุงเอกสารประกอบเกี่ยวกับ "องค์ประกอบที่เชื่อถือได้/การบังคับใช้เทียบกับองค์ประกอบที่ไม่บังคับ" และสนใจที่จะรับฟังข้อมูลจากระบบนิเวศหากงานดังกล่าวจำเป็นต้องมีลำดับความสำคัญ
การปรับปรุง API	รหัสสถานะ HTTP ของการเรียกใช้เซิร์ฟเวอร์ KV ควรพร้อมใช้งานสำหรับฟังก์ชัน scoreAd() ในรูปของพารามิเตอร์	เรากำลังประเมินคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
เอกสารประกอบ	ให้ข้อมูลเพิ่มเติมเกี่ยวกับวิธีจัดการภาระงาน JS และ WASM อย่างชัดเจนด้วยการดำเนินการ UDF	เรากำลังตรวจสอบข้อมูลนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
เอกสารประกอบ	คำขออัปเดตชื่อที่เก็บ	เราได้เปลี่ยนชื่อที่เก็บเป็น "Protected-auction-key-value-service" ซึ่งสอดคล้องกับคำที่ใช้เรียกคอลเล็กชันของบริการซึ่งมีที่เก็บอื่นๆ ด้วย เช่น การสนทนาเกี่ยวกับ Protected Audience Services และเอกสารประกอบของบริการการประมูลที่มีการป้องกัน
เอกสารประกอบ	นำการอ้างอิงไปยัง API โปรแกรมแก้ไขข้อบกพร่องบนคลาวด์ออกใน bidding_auction_services_gcp_guide.md	เราได้อัปเดตเอกสารประกอบและนำข้อมูลอ้างอิงออกแล้ว
การใช้ API	เวลาในการตอบสนองที่เกิดจากการค้นหา KV จะใช้เวลานานกว่า 50 มิลลิวินาที ใช้เวลาเกือบ 100 มิลลิวินาที คุณมีคำแนะนำว่าสิ่งใดทำงานได้ดีสำหรับผู้ขายรายอื่นๆ ไหม คุณมีคำแนะนำเกี่ยวกับวิธีการวัดการหมดเวลาและเวลาหรือไม่	การเรียกเซิร์ฟเวอร์ KV จะเกิดขึ้นภายในบริบทของตัวเรียกใช้สคริปต์ กล่าวคือ เป็นสภาพแวดล้อมพิเศษที่มีการป้องกันภายในเบราว์เซอร์ Chrome และมีไว้เพื่อป้องกันข้อมูลในตัวเรียกใช้สคริปต์เหล่านี้เพื่อป้องกันการเข้าถึงที่ไม่ใช่ API เราได้ระบุคำอธิบายโดยละเอียดไว้ที่นี่
การใช้ API	เซิร์ฟเวอร์ KV จะตอบสนองในเวลาที่กำหนดหรือไม่	ผู้ขายสามารถระบุช่อง "perBuyerCumulativeTimeouts" ในการกำหนดค่าการประมูล ระยะหมดเวลานี้รวมถึงเวลาที่ต้องใช้ในการดึงสัญญาณการเสนอราคาที่เชื่อถือได้
เวลาในการตอบสนอง	ทีม Privacy Sandbox ทำงานกันอย่างไรเพื่อจัดการเวลาในการตอบสนอง	สำหรับกลยุทธ์ที่เรากำลังพัฒนาเพื่อให้เวลาในการตอบสนองอยู่ในขีดจำกัดที่ยอมรับได้ โปรดดูที่นี่

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

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

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

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

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

Private Aggregation API

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

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

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

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

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

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

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

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

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

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

เสริมสร้างขอบเขตความเป็นส่วนตัวข้ามเว็บไซต์

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

ธีมความคิดเห็น	สรุป	การตอบกลับจาก Chrome
คำขอฟีเจอร์	ระบบอนุญาตให้เข้าถึง CHIP และ / หรือการแบ่งพาร์ติชันพื้นที่เก็บข้อมูลโดยอัตโนมัติใน RWS โดยไม่ต้องมี Storage Access API หรือการโต้ตอบของผู้ใช้	เรากำลังพิจารณาถึงประโยชน์และความเป็นไปได้ของฟีเจอร์ที่อาจทำงานนี้ได้ ข้อควรพิจารณาหนึ่งคือช่องว่างที่อาจเกิดขึ้นในความสามารถในการทำงานร่วมกันข้ามเบราว์เซอร์ ซึ่ง RWS แก้ไขได้ด้วย การใช้ประโยชน์จาก Storage Access API ขณะนี้ยังไม่มีฟังก์ชันการทํางานที่ขอนี้ซึ่งรองรับในเบราว์เซอร์อื่นๆ เราขอแนะนำให้นักพัฒนาแอปส่ง Use Case เกี่ยวกับปัญหานี้มาหารือกันที่นี่
การนำชุดที่ไม่เป็นไปตามนโยบายออก	กระบวนการนำชุดที่ไม่เป็นไปตามนโยบายออกจากที่เก็บคืออะไร	เรากําลังหาขั้นตอนสําหรับกระบวนการนี้ และจะแจ้งให้ทราบทันทีที่มีการอัปเดต
กระบวนการบังคับใช้	กระบวนการบังคับใช้ RWS ขาดความชัดเจนเกี่ยวกับบทบาทที่เป็นความคิดเห็นส่วนตัวของ Google	เนื่องจาก RWS เป็นโครงการที่ดำเนินไปอย่างต่อเนื่องและเรากำลังได้รับการส่งใหม่ๆ อย่างต่อเนื่อง ดังนั้นกระบวนการและเกณฑ์ของเราในด้านต่างๆ ก็ยังคงเข้มแข็ง เรายอมรับว่าหลักเกณฑ์การส่งของเราควรระบุข้อกำหนดในการส่งข้อมูลอย่างสมบูรณ์ และเราจะเพิ่มรายละเอียดลงในหลักเกณฑ์การส่งในอนาคตเพื่อหลีกเลี่ยงความสับสนและความสับสนที่อาจเกิดขึ้น เราตั้งใจให้ขั้นตอนการส่งข้อมูลทางเทคนิคที่สุดเท่าที่ทำได้ เพื่อที่เราจะสามารถกรองการมีส่วนร่วมของมนุษย์ออกและอาศัยการตรวจสอบอัตโนมัติทั้งหมด การประชาสัมพันธ์เช่นนี้ทำให้ต้องมีการโต้ตอบกับมนุษย์มากขึ้นเนื่องจากมีพฤติกรรมที่เราไม่ได้คาดการณ์ไว้ แต่ก็ช่วยให้เราระบุขอบเขตการทํางานอัตโนมัติได้มากขึ้นและวิธีที่เราจะแก้ไขหลักเกณฑ์เพื่อหลีกเลี่ยงปัญหาเหล่านี้ในอนาคตได้
การแชร์ข้อมูล	ขอฟีเจอร์ที่ช่วยให้เจ้าของโดเมนระบุได้ว่าต้องการให้บุคคลที่สามแชร์ข้อมูล 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 หรือ OS ไหม	ได้ แต่เราก็ยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศว่าจะเปลี่ยนแปลงลักษณะการทำงานนี้หรือไม่ที่นี่

Fenced Frames API

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

Shared Storage API

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

CHIPS

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

FedCM

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

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

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

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