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

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

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

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

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

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

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

CHIPS
คุกกี้ที่มีสถานะการแบ่งพาร์ติชันอิสระ
DSP
แพลตฟอร์มฝั่งดีมานด์
FedCM
การจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์
FPS
ชุดโดเมนของบุคคลที่หนึ่ง
IAB
Interactive Advertising Bureau
IDP
ผู้ให้บริการข้อมูลประจำตัว
IETF
คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต
IP
ที่อยู่ Internet Protocol
openRTB
การเสนอราคาแบบเรียลไทม์
OT
ช่วงทดลองใช้จากต้นทาง
PatCG
กลุ่มชุมชนเทคโนโลยีโฆษณาส่วนตัว
RP
ผู้เชื่อถือ
SSP
แพลตฟอร์มฝั่งขาย
TEE
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้
UA
สตริง User Agent
UA-CH
คำแนะนำสำหรับไคลเอ็นต์ User Agent
W3C
World Wide Web Consortium
WIPB
การจงใจปิดบัง IP

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การกํากับดูแลข้อมูลและการปฏิบัติตามข้อกําหนด คำแนะนำสำหรับระบบนิเวศเกี่ยวกับการใช้ Privacy Sandbox เพื่อให้เป็นไปตามข้อกำหนดด้านกฎระเบียบ เช่นเดียวกับเทคโนโลยีใหม่อื่นๆ บริษัทแต่ละแห่งมีหน้าที่ตรวจสอบว่าการใช้ Privacy Sandbox เป็นไปตามกฎหมาย Google ไม่สามารถให้คําแนะนําทางกฎหมายแก่ผู้อื่น อย่างไรก็ตาม เราทราบดีว่านี่เป็นหนึ่งในหัวข้อที่น่าสนใจสำหรับระบบนิเวศ เราได้เผยแพร่เอกสารทางเทคนิคที่ครอบคลุมสำหรับ API แต่ละรายการ ซึ่งควรเป็นพื้นฐานในการประเมินทางกฎหมายที่จำเป็น และเรากำลังดำเนินการจัดทำเอกสารเพิ่มเติมเพื่อสนับสนุนความพยายามของบริษัทในการปฏิบัติตามข้อกำหนดด้านกฎระเบียบ
CMA Quantitative Testing proposal ข้อมูลเพิ่มเติมเกี่ยวกับข้อเสนอการทดสอบเชิงปริมาณของ CMA เรากำลังทำงานร่วมกับ CMA เพื่อออกแบบการทดสอบที่จะแสดงให้เห็นภาพรวมของผลกระทบจากการเลิกใช้งานคุกกี้ของบุคคลที่สามและการนำข้อเสนอ Privacy Sandbox มาใช้ในระบบนิเวศ ในเดือนเมษายน CMA ได้เผยแพร่คำแนะนำระดับสูงเกี่ยวกับสิ่งที่จะเกิดขึ้นในช่วงการทดสอบและช่วงทดลองใช้ ตามด้วยคำแนะนำโดยละเอียดในเดือนมิถุนายน เราขอแนะนำให้แชร์คำถามหรือความคิดเห็นเกี่ยวกับข้อเสนอการทดสอบเชิงปริมาณของ CMA กับ CMA โดยตรง
โหมดการทดสอบที่อำนวยความสะดวกโดย Chrome ข้อมูลเพิ่มเติมและการชี้แจงเกี่ยวกับกำหนดการทดสอบ เราได้เผยแพร่บล็อกโพสต์เมื่อวันที่ 18 พฤษภาคมเพื่อแชร์ข้อมูลเพิ่มเติมเกี่ยวกับโหมดการทดสอบที่ Chrome ช่วยอำนวยความสะดวก 2 โหมด รายละเอียดเหล่านี้ไม่ใช่รายละเอียดขั้นสุดท้าย และเราจะเผยแพร่คำแนะนำการใช้งานเพิ่มเติมเมื่อดำเนินการในไตรมาสที่ 3 ปี 2023
พื้นที่เก็บข้อมูลที่แบ่งพาร์ติชัน ระบบจะใช้พื้นที่เก็บข้อมูลที่แบ่งพาร์ติชันระหว่างการทดสอบที่อำนวยความสะดวกโดย Chrome ไหม การแบ่งพาร์ติชันพื้นที่เก็บข้อมูลจะพร้อมให้บริการแก่ผู้ใช้ทุกคนก่อนการทดสอบการเลิกใช้งานคุกกี้ของบุคคลที่สาม ดังนั้น ระบบจะเปิดใช้รูปแบบการทดสอบนี้สําหรับกลุ่มทดสอบทั้งหมด เว็บไซต์จะมีตัวเลือกในการเปิดใช้ช่วงทดลองการเลิกใช้งานเพื่อรับพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชันคืนในช่วงเวลานี้
การสนับสนุนด้านการผลิต Chrome มีกระบวนการใดบ้างในการสนับสนุนปัญหาทางเทคนิคของ Privacy Sandbox และการส่งต่อปัญหาที่ส่งผลกระทบต่อระบบนิเวศ Google มีช่องทางที่หลากหลายเพื่อให้ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณารายงานปัญหาและส่งต่อปัญหาที่จำเป็น
โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับฟอรัมสาธารณะและฟอรัมส่วนตัวสำหรับความคิดเห็นและการส่งต่อที่ภาพรวมความคิดเห็น
ไทม์ไลน์การลงทะเบียน กรอบเวลาปัจจุบันสำหรับการลงทะเบียนสั้นเกินไป เรายังคงประเมินกำหนดเวลาบังคับใช้อยู่และต้องการฟังความคิดเห็นจากระบบนิเวศว่าควรกำหนดเวลาอย่างไรให้เหมาะสมยิ่งขึ้น
หมายเลข D-U-N-S ข้อมูลเพิ่มเติมเกี่ยวกับข้อกำหนดหมายเลข D-U-N-S สำหรับการลงทะเบียนและการรับรอง ผู้เข้าร่วมดูข้อกำหนดในการขอรับหมายเลข D-U-N-S ได้ในเว็บไซต์ Dun and Bradstreet ข้อกำหนดจะแตกต่างกันไปตามตลาด ดังนั้นผู้เข้าร่วมควรตรวจสอบเว็บไซต์ของตลาดที่ตนสนใจ อย่างไรก็ตาม โดยทั่วไปผู้เข้าร่วมจะต้องให้ข้อมูลพื้นฐานเกี่ยวกับธุรกิจ เช่น ชื่อธุรกิจ ที่อยู่ และข้อมูลติดต่อของเจ้าของหรือผู้จัดการธุรกิจ นอกจากนี้ เราอาจขอให้ผู้เข้าร่วมระบุข้อมูลทางการเงิน เช่น รายได้ประจำปีของธุรกิจ เมื่อกรอกใบสมัครเสร็จแล้ว D&B จะตรวจสอบใบสมัครและออกหมายเลข D-U-N-S หากใบสมัครได้รับอนุมัติ
การเปลี่ยนจากช่วงทดลองใช้จากต้นทางเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไป การเปลี่ยนจากช่วงทดลองใช้จากต้นทางเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไปจะส่งผลต่อผู้ทดสอบช่วงทดลองใช้จากต้นทางในปัจจุบันหรือไม่ ตั้งแต่เดือนกรกฎาคมเป็นต้นไป ผู้ทดสอบจะเข้าถึง API ที่เกี่ยวข้องและการวัดผลได้แบบพร้อมให้บริการแก่ผู้ใช้ทั่วไป ซึ่งจะทำให้ช่วงทดลองใช้ของต้นทางซ้อนทับกับช่วงให้บริการทั่วไป
การศึกษาของ AdExchanger ข้อมูลเพิ่มเติมเกี่ยวกับระเบียบวิธีสํารวจ แบบสํารวจขอให้ผู้ตอบประมาณอัตราการซิงค์และรายได้ของธุรกิจ ผู้ตอบใช้วิธีการใดก็ได้ในการตอบคำถามแต่ละข้อ
ค่าพารามิเตอร์ ระบบกำหนดค่าพารามิเตอร์ เช่น ระดับสัญญาณรบกวน เกณฑ์การลบข้อมูลระบุตัวตน และงบประมาณความเป็นส่วนตัวอย่างไร คำอธิบายใน GitHub นี้ระบุหลักการทั่วไปเพิ่มเติมที่อยู่เบื้องหลัง Privacy Sandbox API เรายังคงกําลังกําหนดค่าหลายรายการให้เสร็จสมบูรณ์และยินดีรับฟังความคิดเห็นเกี่ยวกับเรื่องนี้

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

หัวข้อ

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การรักษาความเป็นส่วนตัว การวิจัยที่ประเมิน Topics API เกี่ยวกับการรักษาความเป็นส่วนตัว เรามีส่วนร่วมกับชุมชนการวิจัยอย่างสม่ำเสมอ โดยนำเสนองานวิจัยเกี่ยวกับพร็อพเพอร์ตี้ความเป็นส่วนตัวของ Topics API ในเอกสาร รายงาน และงานนำเสนอเวิร์กช็อป เรายินดีที่ได้เห็นสมาชิกภายนอกของชุมชนการวิจัยมีส่วนร่วมกับพื้นที่นี้มากขึ้น

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

เราขอแนะนำให้ระบบนิเวศตรวจสอบการจัดหมวดหมู่ล่าสุดและแสดงความคิดเห็นเกี่ยวกับการเปลี่ยนแปลง
กระบวนการอัปเดตการจัดหมวดหมู่และตัวจัดประเภท ข้อมูลเพิ่มเติมเกี่ยวกับการจัดหมวดหมู่ Topics และลําดับการเผยแพร่ตัวจัดประเภท รวมถึงวิธีที่บริษัทต่างๆ สามารถเตรียมพร้อมสําหรับการอัปเดตดังกล่าว ตามที่ได้แชร์ไว้ในบล็อกโพสต์ล่าสุด เราคาดว่าการจัดหมวดหมู่จะพัฒนาไปเรื่อยๆ และในที่สุดการกํากับดูแลการจัดหมวดหมู่จะเปลี่ยนไปเป็นของบุคคลภายนอกที่เป็นตัวแทนผู้มีส่วนเกี่ยวข้องจากทั่วทั้งอุตสาหกรรม นอกจากนี้ เรายังได้แชร์แผนการเพิ่มจำนวนผู้เข้าร่วมในกลุ่ม topics-announce ด้วย
ผลกระทบต่อสัญญาณของบุคคลที่หนึ่ง การเพิ่มจํานวนหัวข้อในการอัปเดตการจัดหมวดหมู่ครั้งล่าสุดอาจมีคุณค่าสูงมาก และส่งผลให้สัญญาณอื่นๆ ที่อิงตามความสนใจของบุคคลที่หนึ่งมีคุณค่าน้อยลง ในรายงานไตรมาสที่ 1 ปี 2023 CMA ให้ความเห็นว่า "เราเข้าใจว่า Google ได้พูดคุยเกี่ยวกับการจัดหมวดหมู่ใหม่ตามที่เสนอกับผู้เข้าร่วมในตลาดหลายรายในซัพพลายเชนเทคโนโลยีโฆษณา แม้ว่าผู้เผยแพร่โฆษณารายใหญ่บางรายจะกล่าวว่าประโยชน์ที่มากขึ้นของหัวข้อจะเพิ่มแรงกดดันด้านการแข่งขันในโซลูชันที่อิงตามข้อมูลจากบุคคลที่หนึ่ง แต่มุมมองเบื้องต้นของเราคือประโยชน์ที่มากขึ้นนั้นดีกว่าสำหรับการแข่งขันโดยรวม โดยเฉพาะความสามารถของผู้เผยแพร่โฆษณารายเล็กในการสร้างรายได้จากพื้นที่โฆษณาต่อไปหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม" มุมมองของเราสอดคล้องกับความคิดเห็นนี้ของ CMA
ประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ เทคโนโลยีโฆษณาที่ทําหน้าที่เป็น SSP และ DSP อาจมีข้อได้เปรียบอย่างมากเมื่อเทียบกับผู้เล่นรายอื่นๆ ในระบบนิเวศ การตอบกลับของเราไม่มีการเปลี่ยนแปลงจากไตรมาสก่อนหน้า

"Google มุ่งมั่นที่จะออกแบบและใช้งานข้อเสนอเกี่ยวกับ Privacy Sandbox ในลักษณะที่ไม่บิดเบือนการแข่งขันด้วยการให้สิทธิประโยชน์แก่ธุรกิจของ Google เอง และพิจารณาผลกระทบต่อการแข่งขันในการโฆษณาดิจิทัล รวมถึงผู้เผยแพร่โฆษณาและผู้ลงโฆษณา ไม่ว่าขนาดของธุรกิจจะเล็กหรือใหญ่ก็ตาม เรายังคงทำงานร่วมกับ CMA อย่างใกล้ชิดเพื่อให้มั่นใจว่าการดำเนินการของเราเป็นไปตามความมุ่งมั่นเหล่านี้ ในระหว่างการทดสอบ Privacy Sandbox คำถามสำคัญอย่างหนึ่งที่เราประเมินคือประสิทธิภาพของเทคโนโลยีใหม่สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ ความคิดเห็นของคุณมีความสำคัญอย่างยิ่งในเรื่องนี้ โดยเฉพาะความคิดเห็นที่เฉพาะเจาะจงและนำไปใช้ได้จริง ซึ่งจะช่วยให้เราปรับปรุงการออกแบบทางเทคนิคให้ดียิ่งขึ้นได้ เราได้ทํางานร่วมกับ CMA เพื่อพัฒนาแนวทางการทดสอบเชิงปริมาณ และสนับสนุน CMA ในการเผยแพร่หมายเหตุเกี่ยวกับการออกแบบการทดสอบเพื่อให้ข้อมูลเพิ่มเติมแก่ผู้เข้าร่วมในตลาดและโอกาสในการแสดงความคิดเห็นเกี่ยวกับแนวทางที่เสนอ"
หัวข้อที่สืบทอด เมื่อเกณฑ์การเลือกหัวข้อคือความถี่ในการเข้าชมเบราว์เซอร์ การที่กลุ่มเป้าหมายแตกแยกจะทำให้หัวข้อที่สืบทอดมาไม่มีโอกาสขึ้นสู่อันดับสูงสุดหรือไม่ ปัจจุบัน Chrome กำลังประเมินวิธีการจัดอันดับอื่นๆ และสำรวจสัญญาณอื่นๆ ที่อาจช่วยปรับปรุงการจัดอันดับ เราจะแจ้งแผนการที่แก้ไขแล้วให้ระบบนิเวศทราบในโอกาสต่อไป
ความไว เป้าหมายของ Topics API ควรเป็นการทำให้ข้อมูลผู้ใช้ที่ได้รับหรือมาจาก Topics API มีความละเอียดอ่อนน้อยกว่าข้อมูลที่อาจได้โดยใช้วิธีการติดตามในปัจจุบัน เราเชื่อว่า Topics API มีความเป็นส่วนตัวมากกว่าเทคโนโลยีปัจจุบันอย่างมาก จำกัดการระบุตัวตนผู้ใช้ซ้ำอย่างมีนัยสำคัญ และออกแบบมาเพื่อยกเว้นหัวข้อที่มีความละเอียดอ่อน เราทราบดีว่า Topics สามารถเชื่อมโยงหรือรวมกับข้อมูลจากบุคคลที่หนึ่งเพื่อสร้างหมวดหมู่ที่มีความละเอียดอ่อนได้ แต่เราเชื่อว่า Topics API เป็นก้าวสำคัญในการพัฒนาความเป็นส่วนตัวของผู้ใช้ และเรามุ่งมั่นที่จะปรับปรุง API นี้ต่อไป
โครงสร้างการจัดหมวดหมู่ เพิ่มรหัส การกำหนดเวอร์ชัน และโครงสร้างข้อมูลเมตาอื่นๆ ลงในการจัดหมวดหมู่ Topics ปัจจุบันเราใส่รหัสการจัดหมวดหมู่ในการตอบกลับของ API เมื่อเรากําลังเดินหน้าสู่การจัดการในระยะยาว เราจึงควรตรวจสอบออบเจ็กต์ Topics และใส่ข้อมูลเมตาเพิ่มเติมเกี่ยวกับเวอร์ชันหากจําเป็น
การควบคุมของผู้เผยแพร่โฆษณา ผู้เผยแพร่โฆษณาควรมีสิทธิ์เลือกหัวข้อที่เว็บไซต์ของตนควรจัดประเภท การจัดประเภทเว็บไซต์ที่ไม่ถูกต้องอาจทําให้สัญญาณ Topics มีประโยชน์น้อยลงเล็กน้อยโดยรวม แต่เว็บไซต์ที่การจัดประเภทไม่ถูกต้องจะไม่ได้รับผลกระทบมากหรือน้อยไปกว่าเว็บไซต์อื่นๆ เนื่องจากข้อมูลตามบริบทของเว็บไซต์จะพร้อมใช้งานสำหรับการประมูลในเว็บไซต์เสมอ ซึ่งจะให้ข้อมูลที่เปรียบเทียบได้กับหัวข้อที่ถูกต้อง แม้ว่าจะมีการจัดประเภทไม่ถูกต้องก็ตาม เรายินดีรับความคิดเห็นเกี่ยวกับเรื่องนี้ที่นี่

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

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การกำหนดรูปแบบการเข้าชม ผลกระทบด้านประสิทธิภาพของตัวกรองที่ขับเคลื่อนโดย SSP เพื่อเพิ่มประสิทธิภาพการโหลดคำค้นหาต่อวินาที (QPS) เราได้ใช้เวลาพิจารณาการปรับปริมาณการจราจรอย่างละเอียดแล้ว และขอแนะนําให้ SSP ใช้ประโยชน์จากการแคช
กำลังทดสอบระดับเสียง การทดสอบ Protected Audience เป็นเรื่องยากเนื่องจาก SSP และ DSP ประสบปัญหาในการรับปริมาณการเข้าชมจำนวนมาก เราดึงดูดพาร์ทเนอร์ SSP และ DSP ให้ใช้และทดสอบกลุ่มเป้าหมายที่ได้รับการคุ้มครองอย่างต่อเนื่อง เราเริ่มให้บริการแก่ผู้ใช้ทั่วไปแล้ว และมั่นใจว่าเปอร์เซ็นต์การเข้าชมที่เปิดใช้ PA จะช่วยให้พาร์ทเนอร์ทดสอบได้ง่ายขึ้น
ความซับซ้อน การใช้โซลูชันกลุ่มเป้าหมายที่ได้รับการคุ้มครองต้องใช้ความพยายามและค่าใช้จ่ายอย่างมาก เราตระหนักดีว่าการนำเทคโนโลยีใหม่ๆ มาใช้นั้นเป็นเรื่องยาก ซึ่งรวมถึง Privacy Sandbox ทีม Privacy Sandbox ทำงานร่วมกับผู้มีส่วนเกี่ยวข้องหลากหลายกลุ่มอย่างใกล้ชิดเพื่อแจ้งข้อมูลและสนับสนุนความพยายามของผู้มีส่วนเกี่ยวข้องเหล่านั้น และประเมินปัจจัยเร่งอื่นๆ อย่างต่อเนื่องเพื่อรองรับการใช้งานในระบบนิเวศ
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ การรองรับสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) ในสภาพแวดล้อมระบบคลาวด์แบบไม่สาธารณะ แม้ว่าเราจะกำลังสำรวจตัวเลือกที่อาจรองรับนอกเหนือจากโซลูชันที่ทำงานบนระบบคลาวด์ แต่ปัจจุบันเรายังไม่สามารถรองรับ TEE ในเครื่องได้เนื่องจากข้อจำกัดด้านความปลอดภัยในเครื่องซึ่งจะต้องใช้เวลาในการประเมินสำหรับ Privacy Sandbox เมื่อพิจารณาถึงข้อกําหนดด้านความปลอดภัยของ Privacy Sandbox และปัญหาสำคัญที่เกิดขึ้นจากการใช้งานในสถานที่ เราเชื่อว่าการขยายและปรับปรุงการใช้งานบนระบบคลาวด์อย่างต่อเนื่อง (เช่น การรองรับ GCP นอกเหนือจาก AWS) จะเป็นประโยชน์ต่อระบบนิเวศมากที่สุด อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ต้องมีข้อกำหนดดังกล่าว
โครงสร้างค่าใช้จ่าย ข้อเสนอบริการการเสนอราคาและการประมูลจะเพิ่มค่าใช้จ่ายและความซับซ้อนสําหรับเทคโนโลยีโฆษณาเมื่อเทียบกับรูปแบบฝั่งไคลเอ็นต์ ขณะนี้เรากําลังพัฒนาคําแนะนําสําหรับการประมาณค่าใช้จ่ายในการสนับสนุนเวิร์กโฟลว์การเสนอราคาและการประมูลในเซิร์ฟเวอร์การเสนอราคาและการประมูล ซึ่งจะเชื่อมโยงกับการใช้เทคโนโลยีโฆษณาเพื่อบรรลุเป้าหมายการออกแบบข้อใดข้อหนึ่งของเรา
ไทม์ไลน์ K-Anon ระบบจะบังคับใช้ข้อจำกัด k-anonymity ที่วางแผนไว้กับ `renderUrl` เมื่อใด เรากำลังจัดทำคำอธิบายลำดับเวลาการบังคับใช้ซึ่งจะเผยแพร่ในเร็วๆ นี้
ข้อจํากัดของ runAdAuction Chrome จำกัด runAdAuction ให้เรียกใช้ได้จากหน้าบนสุดเท่านั้นได้ไหม แม้ว่าการออกแบบของเรารองรับrunAdAuctionให้เรียกใช้ได้จากหน้าบนสุดอย่างเต็มรูปแบบ แต่เราเชื่อว่าการจํากัดให้เรียกใช้ได้จากโดเมนบนสุดเท่านั้นจะทําให้ผู้เผยแพร่โฆษณาได้รับอันตรายมากกว่า

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

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

เราได้เผยแพร่คําแนะนําเกี่ยวกับวิธีทํางานของ API ในที่เก็บ GitHub ของเรา และพร้อมที่จะสำรวจโซลูชันร่วมกับอุตสาหกรรม

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

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

เราได้พูดคุยเกี่ยวกับสถานการณ์ต่างๆ ที่เกี่ยวข้องกับปัญหานี้ในการประชุมเกี่ยวกับกลุ่มเป้าหมายที่ได้รับการคุ้มครองของ WICG ในเดือนพฤษภาคม และยินดีรับความคิดเห็นและการพูดคุยเพิ่มเติมเกี่ยวกับปัญหานี้
กลุ่มเป้าหมายที่กำหนดเอง Protected Audience API จะรองรับ Use Case ของ SSP ที่เกี่ยวข้องกับการสร้างกลุ่มเป้าหมายที่กำหนดเองไหม Protected Audience API ช่วยให้ SSP และผู้ให้บริการด้านเทคโนโลยีโฆษณารายอื่นๆ เป็นเจ้าของและจัดการกลุ่มเป้าหมายที่กำหนดเองได้ เรากําลังพัฒนาคําแนะนําเพิ่มเติมเกี่ยวกับวิธีที่ SSP สามารถผสานรวมกับ PA API และจะเผยแพร่คําแนะนําดังกล่าวแก่ SSP และผู้ให้บริการด้านเทคโนโลยีโฆษณารายอื่นๆ เพื่อสนับสนุนการผสานรวม
รูปแบบ Protected Audience API รองรับวิดีโอไหม โฆษณาวิดีโอจะแสดงด้วยวิธีใดวิธีหนึ่งต่อไปนี้ VAST XML หรือ HTML (โฆษณานอกสตรีมที่ท้ายที่สุดอาจโหลด VAST XML ลงในโปรแกรมเล่นวิดีโอด้วย) ผู้ซื้อสามารถแสดงผลรูปแบบใดก็ได้ผ่าน renderURL ข้อกําหนด VAST ได้รับการอัปเดตเมื่อเร็วๆ นี้เพื่อรองรับ Attribution Reporting API เว็บไซต์ที่แสดงโฆษณาวิดีโอจะต้องเตรียมพร้อมสําหรับวิธีแสดงโฆษณาผ่าน Protected Audience API ซึ่งหมายความว่าต้องตรวจสอบว่าแท็กตําแหน่งสามารถส่ง URL จาก iframe ของ Protected Audience ไปยังโปรแกรมเล่นวิดีโอได้ สำหรับเฟรมที่มีการกำหนดขอบเขต เราจะพยายามตอบสนองความต้องการด้านวิดีโอก่อนถึงกำหนดการใช้เฟรมที่มีการกำหนดขอบเขตซึ่งจะเริ่มต้นไม่เร็วกว่าปี 2026
การกำหนดอัตราการแสดงโฆษณา Use Case อัตราการแสดงโฆษณาทำงานร่วมกับ Protected Audience API อย่างไร ขอขอบคุณสำหรับความคิดเห็น เราสนใจที่จะดูคำขอนี้มากขึ้นพร้อมรายละเอียดเพิ่มเติมจากพาร์ทเนอร์ SSP จำนวนมากขึ้น เนื่องจากปัญหานี้ส่วนใหญ่เป็นข้อกังวลของ DSP จนถึงปัจจุบัน
ความถี่ในการอัปเดต ความถี่ในการเรียกใช้ dailyUpdate (สูงสุด 1 ครั้งต่อกลุ่มความสนใจต่อวัน) อาจไม่เพียงพอสำหรับบางกรณีการใช้งาน เช่น การอัปเดตข้อมูลผลิตภัณฑ์ ขอขอบคุณสำหรับความคิดเห็น มีโซลูชันอื่นๆ ที่อนุญาตให้เทคโนโลยีโฆษณาใช้สัญญาณที่รีเฟรชในจังหวะที่แตกต่างกัน เช่น การค้นหา K/V
การควบคุมคุณภาพโฆษณา ผู้เผยแพร่โฆษณาใช้การควบคุมคุณภาพโฆษณาอย่างไร ปัจจุบัน Protected Audience API มีฟังก์ชันการทำงานให้ผู้เผยแพร่โฆษณาแจ้ง SSP เกี่ยวกับการควบคุมบางอย่างที่สามารถสร้างได้เป็นส่วนหนึ่งของการกําหนดค่าการประมูลและการเสนอราคาล่วงหน้า (เช่น รายการที่ปฏิเสธตามป้ายกำกับที่เชื่อมโยงกับโฆษณา) เรายินดีรับฟังความคิดเห็นเกี่ยวกับฟังก์ชันการทำงานเพิ่มเติมที่ระบบนิเวศอาจต้องการ
การแก้ไขข้อบกพร่อง ระบบจะนำฟังก์ชันการทำงาน forDebuggingOnly ออกเมื่อใด เราวางแผนที่จะเลิกใช้งาน forDebuggingOnly สําหรับเหตุการณ์การสูญเสียเนื่องจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม เราวางแผนที่จะเลิกใช้งาน forDebuggingOnly สำหรับเหตุการณ์ "ชนะ" ในปี 2026 เป็นอย่างช้าที่สุด
กลุ่มความสนใจข้ามอุปกรณ์ ข้อเสนอเพื่อเปิดใช้กลุ่มความสนใจข้ามอุปกรณ์สําหรับ User Agent ที่ตรวจสอบสิทธิ์แล้ว เรากำลังประเมินข้อเสนอนี้ แต่การกำหนดเป้าหมายข้ามอุปกรณ์ที่เฉพาะเจาะจงสูงทำให้เกิดข้อกังวลด้านความเป็นส่วนตัวที่สำคัญดังที่กล่าวไว้ในปัญหานี้ใน GitHub
(รายงานในไตรมาสที่ 1 ด้วย) รีมาร์เก็ตติ้งแบบไดนามิก รีมาร์เก็ตติ้งแบบไดนามิกจะยังทํางานได้ไหมเมื่อใช้ Protected Audience API หลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม เราเชื่อว่า Use Case นี้เป็นไปได้โดยใช้ Protected Audience ตามที่อธิบายไว้ที่นี่
คลิกข้อมูลที่เกี่ยวข้อง เพิ่มข้อมูลที่เกี่ยวข้องกับการคลิกลงใน browserSignals. ขณะนี้เรากำลังขอคำชี้แจงเกี่ยวกับเวลาที่เกิดการคลิกเพื่อให้ตำแหน่งเบื้องต้น
(รายงานในไตรมาสที่ 4 ปี 2022 ด้วย) ฟังก์ชันที่ผู้ใช้กําหนดในกลุ่มเป้าหมายที่ได้รับการคุ้มครอง Protected Audience API จะรองรับฟังก์ชันที่ผู้ใช้กําหนด (UDF) อย่างไร ฟังก์ชันเหล่านี้เป็นฟังก์ชันที่ผู้ใช้ปลายทางสามารถเขียนโปรแกรมเพื่อขยายฟังก์ชันการทำงานของ API ได้ ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาที่แจ้งปัญหานี้ยังแจ้งอีกว่ายังประเมินสิ่งที่ทำได้ด้วย UDF อยู่ จึงยังไม่มีความคิดเห็นที่นําไปใช้ได้จริงในตอนนี้ อย่างน้อยก็จนกว่าจะมีการเปิดตัวแบบทั่วไป
สกุลเงิน ไม่ควรแสดงจำนวนเงินในสกุลเงินโดยใช้ทศนิยม เราได้แก้ไขปัญหานี้โดยละเอียดที่นี่
ความสามารถในการเลือกโฆษณาที่ไม่ใช่ DSP เซิร์ฟเวอร์โฆษณามีบทบาทอย่างไรในการประมูล Protected Audience API เราทราบดีถึงคําขอให้เซิร์ฟเวอร์โฆษณาให้บริการเลือกโฆษณาหลังการเสนอราคา / บริการเพิ่มประสิทธิภาพครีเอทีฟโฆษณาแบบไดนามิกต่อไป ขณะนี้เรากําลังประเมินการวิเคราะห์ช่องว่างโดยละเอียดระหว่าง Protected Audience API ปัจจุบันกับคําขอเหล่านี้
GenerateBid รองรับข้อเสนอของ Google Ads ในการแสดงโฆษณาที่มีโอกาสแสดงมากกว่า 1 รายการต่อกลุ่มความสนใจของโฆษณาจาก generateBid และคะแนนโฆษณาที่มีโอกาสแสดงเหล่านั้นใน `scoreAd` ขณะนี้เรากำลังประเมินเรื่องนี้ เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่
คำสั่งซื้อการประมูล การประมูล Protected Audience API ต้องทํางานเป็นรายการสุดท้ายเพื่อให้รับข้อมูลจากผลลัพธ์ของการประมูลอื่นๆ ทั้งหมดได้ไหม ไม่มีข้อกําหนดทางเทคนิคที่ Protected Audience API ต้องทํางานเป็นอันดับสุดท้าย
การนำทางที่ไม่ได้เริ่มต้นโดยผู้ใช้ แสดงการนําทางที่ผู้ใช้ไม่ได้เป็นผู้เริ่ม เรากำลังตรวจสอบคำขอนี้และพูดคุยกันที่นี่ รวมถึงยินดีรับฟังความคิดเห็นเพิ่มเติม
การแคช SSP ไม่ควรสร้าง perBuyerSignals ของ DSP หนึ่งๆ จากแคชหากสถานะผู้ใช้มีการเปลี่ยนแปลง เราเข้าใจว่าการแคชใช้ไม่ได้กับ Use Case ทั้งหมดสำหรับสัญญาณ perBuyer และกำลังประเมินตัวเลือกเพิ่มเติม เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศว่าแคชจะเหมาะกับกรณีการใช้งานหรือไม่
การรายงานการระบุแหล่งที่มาและ Protected Audience Attribution Reporting API และ Protected Audience API ทํางานร่วมกันได้อย่างไร ปัจจุบันการผสานรวมพร้อมใช้งานสําหรับ Protected Audience API สําหรับทั้ง 2 โหมดของ Attribution Reporting API (รายงานระดับเหตุการณ์และรายงานสรุป) เราได้แชร์ข้อมูลเพิ่มเติมเกี่ยวกับการผสานรวม Protected Audience API และการรายงานการระบุแหล่งที่มาที่ปรับปรุงแล้วเมื่อวันที่ 1 มิถุนายน คุณสามารถอ่านข้อมูลเกี่ยวกับแอปเหล่านี้ได้ที่นี่
ปลายทางเซิร์ฟเวอร์ ปลายทางเซิร์ฟเวอร์จะเป็นเซิร์ฟเวอร์การรวมข้อมูลที่เชื่อถือได้ในการออกแบบขั้นสุดท้ายไหม ปลายทางเซิร์ฟเวอร์คือปลายทางที่ดูแลรักษาโดยเทคโนโลยีโฆษณาซึ่งไม่เกี่ยวข้องกับเซิร์ฟเวอร์การรวมข้อมูลที่เชื่อถือได้ที่ใช้ประมวลผลรายงานที่รวบรวมและเปลี่ยนรูปแบบ ขณะนี้เราไม่มีแผนที่จะเปลี่ยนแปลงปลายทางการรายงาน การออกแบบปัจจุบันมีจุดมุ่งหมายเพื่อให้มั่นใจว่ารายงานที่รวบรวมได้ (ซึ่งมีเพย์โหลดที่เข้ารหัส) จะไม่รั่วไหลข้อมูลข้ามเว็บไซต์ ดังนั้นจึงไม่จำเป็นต้องมีปลายทางที่เชื่อถือได้ ความซับซ้อนอีกอย่างหนึ่งคือเทคโนโลยีโฆษณาแต่ละประเภทมีแนวโน้มที่จะใช้กลยุทธ์การแบ่งกลุ่มที่ต้องการแตกต่างกัน เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่
WebIDL ข้อมูลจำเพาะของ Protected Audience API ปัจจุบันใช้ร่วมกับข้อมูลจำเพาะ WebIDL ไม่ได้ เรากำลังประเมินความคิดเห็นนี้และพูดคุยเกี่ยวกับปัญหาที่นี่
การจัดการความยินยอม Protected Audience API จะจัดการการส่งสัญญาณความยินยอมอย่างไร ข้อมูลตามบริบทไม่อยู่ในขอบเขตของ Protected Audience API เรากำลังหารือเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติม
การตลาดตามบัญชี กรณีการใช้งานการตลาดตามบัญชีเป็นไปได้ไหม Protected Audience API รองรับกรณีการใช้งานทางการตลาดที่อิงตามกลุ่มเป้าหมายที่หลากหลาย เรากําลังพยายามทําความเข้าใจว่า Protected Audience API จะรองรับ Use Case นี้ได้อย่างไรให้ดีที่สุด และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้จากระบบนิเวศ
การประมูลคอมโพเนนต์ ผู้เข้าร่วมการประมูลองค์ประกอบจะได้รับคะแนนอย่างไร การประมูลคอมโพเนนต์ไม่ได้ให้คะแนนกลุ่มความสนใจโดยตรง แต่ให้คะแนนโฆษณาและการเสนอราคาที่ DSP ส่งจากฟังก์ชัน generateBid ฟังก์ชัน generateBid() จะทํางานตามกลุ่มความสนใจ และ DSP จะแสดงผลลัพธ์ต่อไปนี้เมื่อเรียกใช้ generateBid: 

return {
  'ad': adObject,
  'adCost': optionalAdCost,
  'bid': bidValue,
  'render': renderUrl,
  'adComponents':
    [adComponent1, adComponent2, ...],
  'allowComponentAuction': false,
  'modelingSignals': 123};
}

เนื้อหาที่มาจากภายนอก คำขอรองรับการมีส่วนร่วมจากภายนอกในฐานโค้ด GitHub ของเซิร์ฟเวอร์คีย์/ค่า เรากำลังอัปเดตกระบวนการที่เกี่ยวข้องเพื่อรองรับการมีส่วนร่วมจากภายนอกในโค้ด GitHub
ขนาดกลุ่มความสนใจ IG รองรับคีย์ได้สูงสุดกี่รายการ ปัจจุบันขนาดสูงสุดของ IG 1 รายการคือ 50 KB และระบบจะนับคีย์รวมอยู่ในขนาดดังกล่าว เรายินดีรับฟังการพูดคุยเกี่ยวกับขีดจำกัดขนาดเพิ่มเติม
การแบ่งกลุ่ม วิธีลดจํานวนการเรียกเซิร์ฟเวอร์ K/V คุณสามารถใช้ส่วนหัว HTTP Cache-Control เพื่อลดจํานวนการเรียกใช้ K/V เช่น อาจมีการจัดเก็บแคชไว้ในการประมูลคอมโพเนนต์ต่างๆ และช่องโฆษณาในหน้าเว็บเดียว
การควบคุมเวอร์ชัน รองรับโค้ดเทคโนโลยีโฆษณาหลายเวอร์ชัน บริการเสนอราคาและประมูลจะรองรับโค้ดเทคโนโลยีโฆษณาหลายเวอร์ชัน ใน Bidding and Auction API คําขอ SelectAd สามารถระบุเวอร์ชันของโค้ดที่ใช้สําหรับคําขอการประมูล (สําหรับการเสนอราคา / การประมูล และการรายงาน)
พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน รองรับการเขียนลงในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันในบริการเสนอราคาและประมูล ปัจจุบันบริการการเสนอราคาและการประมูลยังไม่รองรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่กรณีการใช้งานดังกล่าวสำคัญต่อระบบนิเวศ
เว็บไปแอป รองรับการแชร์กลุ่มความสนใจจากเว็บไปยังแอป ปัจจุบัน Web-to-app ไม่ได้อยู่ในขอบเขตของการติดตั้งใช้งาน Protected Audience API ใน Chrome และ Android แต่เราอยากทราบความคิดเห็นจากระบบนิเวศเกี่ยวกับความสำคัญของ Use Case นี้
K-Anonymity วิธีจัดการเส้นทางที่แสดงสำรองสำหรับ K-Anonymity เรากำลังหารือเกี่ยวกับปัญหาและยินดีรับฟังความคิดเห็นเพิ่มเติม

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

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การกำหนดค่ารายงานระดับเหตุการณ์ VTC ทางเลือก ความคิดเห็นเกี่ยวกับการกําหนดค่ารายงานระดับเหตุการณ์ VTC ทางเลือก เราได้รับความคิดเห็นบางส่วนว่าการกำหนดค่าระดับเหตุการณ์ในปัจจุบันไม่เหมาะสม และเราต้องการความคิดเห็นเกี่ยวกับการกําหนดค่าระดับที่เหมาะกับการใช้งานมากที่สุด เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเรื่องนี้และคิดว่าคำอธิบายระดับเหตุการณ์ที่ยืดหยุ่นจะช่วยแก้ปัญหานี้ได้เช่นกัน
การกําหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น ฟีเจอร์การกําหนดค่าระดับเหตุการณ์แบบยืดหยุ่นมีสถานะเป็นอย่างไร เราได้แชร์เอกสารประกอบเกี่ยวกับการกําหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น ฟีเจอร์นี้ยังอยู่ในระยะการเสนอและเราต้องการความคิดเห็นเพิ่มเติมว่าฟีเจอร์นี้จะมีประโยชน์ต่อระบบนิเวศหรือไม่
การกําหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น รายงานที่ขัดแย้งกันจากฝ่ายต่างๆ จะปรับยอดได้อย่างไร สถานการณ์การรายงานส่วนใหญ่ได้รับการแก้ไขผ่านการใช้รายงานแบบรวม ส่วนข้อเสนอการกําหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นมีไว้เพื่อเพิ่มความยืดหยุ่นให้กับรายงานระดับเหตุการณ์โดยเฉพาะ ซึ่งมักใช้กับ Use Case การเพิ่มประสิทธิภาพ เรายินดีรับความคิดเห็น/ความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศสำหรับสถานการณ์นี้
การจดทะเบียนแหล่งที่มา จะเกิดอะไรขึ้นหากการจดทะเบียนแหล่งที่มาเกิดขึ้นหลังจากการจดทะเบียนทริกเกอร์ ปัจจุบัน หากการบันทึกแหล่งที่มาเกิดขึ้นหลังจากการบันทึกทริกเกอร์ แหล่งที่มาและทริกเกอร์จะไม่สามารถระบุแหล่งที่มาของกันและกันได้ ดูเหมือนว่าจะเป็นกรณีที่สุ่มเสี่ยงจะละเมิดนโยบาย เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้ และจะพยายามแก้ไขปัญหานี้หากเป็นสถานการณ์ที่นักเทคโนโลยีโฆษณาจำนวนมากต้องเผชิญ
การทำงานร่วมกับเอเจนซีโฆษณาหลายแห่ง DSP จะใช้ Attribution Reporting API ได้อย่างไรเมื่อผู้ลงโฆษณาทํางานร่วมกับเอเจนซีโฆษณาหลายราย API รองรับการเปลี่ยนเส้นทาง จึงสามารถใช้ได้แม้ว่าผู้ลงโฆษณาจะทํางานร่วมกับเอเจนซีโฆษณาหลายราย นอกจากนี้ ยังมีข้อจํากัดบางอย่างเกี่ยวกับการเปลี่ยนเส้นทางเพื่อให้มั่นใจว่า API จะช่วยปรับปรุงความเป็นส่วนตัว นอกจากนี้ เรายังพบวิธีแก้ปัญหาที่เป็นไปได้โดยใช้ Shared Storage API สําหรับสถานการณ์ที่เฉพาะเจาะจงซึ่งเทคโนโลยีโฆษณาได้แจ้งมา เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับสถานการณ์นี้ และจะปรับปรุงต่อไปตามความคิดเห็นที่ได้รับ
ขีดจํากัดปลายทาง กรณีการใช้งานโฆษณาที่รีเฟรชอัตโนมัติอาจได้รับผลกระทบจากการมีขีดจํากัดปลายทาง เราได้พูดคุยเกี่ยวกับปัญหานี้ในการประชุม WICG วันที่ 1 พฤษภาคม และกำลังมองหาความคิดเห็นเกี่ยวกับขีดจำกัดที่เหมาะสม เราได้เพิ่มข้อมูลลงในการรายงานการระบุแหล่งที่มาพร้อมคําอธิบายรายงานระดับเหตุการณ์ที่ระบุว่าเบราว์เซอร์สามารถจํากัดจํานวน eTLD+1 "ปลายทาง" ที่แสดงโดยเว็บไซต์ต้นทาง (ดูคำขอดึง)
การรายงานการระบุแหล่งที่มาและ Protected Audience Attribution Reporting API และ Protected Audience API ทํางานร่วมกันได้อย่างไร ปัจจุบันการผสานรวมพร้อมใช้งานสําหรับ Protected Audience API สําหรับทั้ง 2 โหมดของ Attribution Reporting API (รายงานระดับเหตุการณ์และรายงานสรุป) เราได้แชร์ข้อมูลเพิ่มเติมเกี่ยวกับการผสานรวม Protected Audience API และการรายงานการระบุแหล่งที่มาที่ปรับปรุงแล้วเมื่อวันที่ 1 มิถุนายน คุณสามารถอ่านข้อมูลเกี่ยวกับแอปเหล่านี้ได้ที่นี่
การกําหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น แชร์แนวทางปฏิบัติแนะนำสำหรับการจําลองเสียงรบกวนเมื่อสามารถกําหนดค่าพารามิเตอร์ได้แล้ว เรามีโค้ดที่แชร์ใน GitHub ซึ่งทุกคนสามารถใช้เพื่อประเมินการได้ข้อมูลและผลกระทบจากสัญญาณรบกวนสำหรับการกำหนดค่าระดับเหตุการณ์แบบยืดหยุ่นที่ต้องการทดสอบ เรายินดีรับฟังความคิดเห็นจากทุกคนที่เลือกทดสอบด้วยรหัสนี้
การวัดการระบุแหล่งที่มาแบบข้ามแอปและเว็บ การวัดการระบุแหล่งที่มาข้ามแอปและเว็บจะพร้อมใช้งานเมื่อใด เมื่อวันที่ 9 พฤษภาคม เราได้ประกาศการทดสอบการวัดการระบุแหล่งที่มาแบบข้ามแอปและเว็บผ่าน Attribution Reporting API แม้ว่าจะมีการวางแผนให้ API ที่เกี่ยวข้องและการวัดผลพร้อมใช้งานใน Chrome 115 แต่ปัจจุบันยังไม่มีแผนที่จะทําให้การวัดการระบุแหล่งที่มาแบบข้ามแอปและเว็บพร้อมใช้งานใน Chrome 115
กรองข้อมูล Conversion ที่ซ้ำกันออก โซลูชันการวัดผลอิสระจะปรับยอดกับ ARA ได้อย่างไร เช่นเดียวกับแนวทางปฏิบัติมาตรฐานในปัจจุบัน ผู้ลงโฆษณาจะทํางานร่วมกับผู้ให้บริการการวัดผลอิสระบุคคลที่สามเพื่อกรองการรายงาน Conversion ที่ซ้ำกันออก เรามีแหล่งข้อมูลเกี่ยวกับวิธีกรอง Conversion ที่ซ้ำกันออกสําหรับการรายงานระดับเหตุการณ์
การสูญเสียข้อมูลระหว่างการอัปเดตฐานข้อมูลการรายงานการระบุแหล่งที่มา ข้อมูลจะสูญหายไหมเมื่อ Chrome อัปเดตฐานข้อมูลการรายงานการระบุแหล่งที่มาตามที่ได้ประกาศไว้ ตั้งแต่ Chrome เวอร์ชันเสถียร 115 เป็นต้นไป เราจะเริ่มเปิดใช้ Relevance และ Measurement API สำหรับผู้ใช้ Chrome บางรายโดยค่าเริ่มต้น เราจะทยอยเปิดตัวฟีเจอร์นี้ให้ผู้ใช้ทั่วไปใช้งานมากขึ้นเมื่อเราตรวจสอบปัญหาที่อาจเกิดขึ้น เป้าหมายคือทำให้ความพร้อมให้บริการ 100% ในช่วงหลายสัปดาห์ภายในไตรมาสที่ 3 ปี 2023 ซึ่งจะตรงกับช่วงสิ้นสุดการทดลองใช้แหล่งที่มาของความเกี่ยวข้องและการวัด ตั้งแต่เดือนกรกฎาคมเป็นต้นไป ผู้ทดสอบจะลงทะเบียนเพื่อเข้าถึง API เหล่านี้ได้เมื่อพร้อมให้บริการแก่ผู้ใช้ทั่วไป ซึ่งจะทำให้ช่วงทดลองใช้เวอร์ชันต้นฉบับและช่วงให้บริการทั่วไปทับซ้อนกันผ่านการลงทะเบียน โทเค็นช่วงทดลองใช้ต้นทางของคุณจะใช้งานได้จนถึงวันที่ 19 กันยายน แต่เราขอแนะนำให้คุณลงทะเบียนใช้ API ก่อนหมดอายุเพื่อเปลี่ยนจากช่วงทดลองใช้ต้นทางได้อย่างราบรื่นโดยไม่รบกวนการทดสอบที่ดำเนินอยู่

ตามที่ได้แจ้งไว้ในประกาศนี้ ระบบจะไม่ย้ายข้อมูลที่มีการลงทะเบียนจากเวอร์ชันเก่า (M113 และเวอร์ชันก่อนหน้า) หลังจากการอัปเดต ดังนั้นข้อมูลจึงอาจสูญหาย การสูญเสียข้อมูลนี้จะไม่แสดงในการรายงานการแก้ไขข้อบกพร่อง และเราจะพยายามหลีกเลี่ยงการสูญเสียข้อมูลจาก 114 เป็น 115
การเรียกเก็บเงิน การใช้การรายงานการระบุแหล่งที่มาสำหรับการเรียกเก็บเงินต้นทุนต่อ Conversion ตามที่ระบุไว้ในบทความนี้ Attribution Reporting API อาจไม่เหมาะกับความต้องการในการเรียกเก็บเงินแบบต้นทุนต่อ Conversion เนื่องจากมีข้อมูลรบกวนเพิ่มเข้ามาในรายงานระดับเหตุการณ์และรายงานสรุป เราขอแนะนําให้ผู้ใช้ในระบบนิเวศแชร์ความคิดเห็นเกี่ยวกับผลกระทบต่อรูปแบบการเรียกเก็บเงินต่างๆ ของ Attribution Reporting API ใน GitHub

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การเปลี่ยนแปลงระยะเวลาก่อนที่จะเกิด Conversion ของรายงานที่รวบรวมได้ ความคิดเห็นเชิงบวกต่อข้อเสนอในการเปลี่ยนความล่าช้าของรายงานแบบรวมจาก [10-60 นาที] เป็น [0-10 นาที] ตามความคิดเห็นจากระบบนิเวศ เรายินดีที่ได้เห็นการตอบรับเชิงบวกต่อการเปลี่ยนแปลงที่เสนอ และขอเชิญชวนให้ระบบนิเวศแสดงความคิดเห็นเกี่ยวกับข้อเสนอของเราต่อไป
โซลูชันในองค์กร บริการรวบรวมข้อมูลติดตั้งใช้งานในศูนย์ข้อมูลภายในองค์กรได้ไหม แม้ว่าเราจะกำลังสำรวจตัวเลือกที่อาจรองรับนอกเหนือจากโซลูชันที่ทำงานบนระบบคลาวด์ แต่ปัจจุบันเรายังไม่สามารถรองรับ TEE ในเครื่องได้เนื่องจากข้อจำกัดด้านความปลอดภัยในเครื่องซึ่งจะต้องใช้เวลาในการประเมินสำหรับ Privacy Sandbox เมื่อพิจารณาถึงข้อกําหนดด้านความปลอดภัยของ Privacy Sandbox และปัญหาสำคัญที่เกิดขึ้นจากการใช้งานในสถานที่ เราเชื่อว่าการขยายและปรับปรุงการใช้งานบนระบบคลาวด์อย่างต่อเนื่อง (เช่น การรองรับ GCP นอกเหนือจาก AWS) จะเป็นประโยชน์ต่อระบบนิเวศมากที่สุด อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ต้องมีข้อกำหนดดังกล่าว
ประมวลผลรายงานอีกครั้งสําหรับระยะเวลาต่างๆ ความสามารถในการประมวลผลรายงานอีกครั้งสำหรับระยะเวลาต่างๆ เราได้รับคำขอที่คล้ายกันให้แยกกลุ่มสำหรับช่วงวันที่ที่แตกต่างกัน ข้อเสนออย่างหนึ่งคือการอนุญาตให้ขยายรหัสที่แชร์ด้วยป้ายกํากับที่ระบุโดยเทคโนโลยีโฆษณาเพื่อให้รายงานแบ่งออกเป็นกลุ่มต่างๆ ได้ เรากําลังอยู่ในขั้นตอนเริ่มต้นของการประเมินกระบวนการนี้ และจะอัปเดตระบบนิเวศอย่างต่อเนื่องเมื่อข้อเสนอนี้พัฒนาขึ้น
ผลกระทบด้านความเป็นส่วนตัวของสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ ความรู้สึกเชิงบวกต่อผลกระทบด้านความเป็นส่วนตัวของสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ เรายินดีที่ได้ทราบว่าระบบนิเวศมีปฏิกิริยาเชิงบวกเกี่ยวกับข้อเสนอของเรา และยินดีรับฟังความคิดเห็นเพิ่มเติมในขณะที่เราปรับปรุงและพัฒนาต่อไป
ข้อกำหนดในการให้บริการ กำหนดเวลาในการยอมรับข้อกำหนดในการให้บริการของบริการรวบรวมข้อมูลคือวันไหน แม้ว่าเราจะยังไม่ได้ระบุกำหนดเวลาในการยอมรับข้อกำหนดและเงื่อนไข แต่เราขอแนะนำให้บริษัทในระบบนิเวศยอมรับข้อกำหนดและเงื่อนไขโดยเร็วที่สุดเพื่อป้องกันความล่าช้าในการลงทะเบียน เราขอแนะนำให้บริษัทติดต่อเราหากมีคำถาม
การค้นพบคีย์ ฟีเจอร์การค้นพบคีย์ช่วยให้ผู้ทดสอบสามารถค้นหารายงานรวมได้โดยไม่ต้องมีรายการชุดค่าผสมของคีย์ที่เป็นไปได้อย่างชัดเจนเพื่อประมวลผลรายงานสรุปสำหรับการระบุแหล่งที่มาข้ามเครือข่ายเพื่อประสิทธิภาพและความแม่นยำที่ดียิ่งขึ้น ขณะนี้เรากำลังหาวิธีแก้ปัญหาและวิธีแก้ปัญหาชั่วคราวที่เป็นไปได้ และยินดีรับความคิดเห็นเพิ่มเติมจากระบบนิเวศ

Private Aggregation API

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
ที่มาของการรายงาน มีการกําหนดแหล่งที่มาของการรายงานอย่างไร ต้นทางการรายงานคือต้นทางสคริปต์ของผู้เรียกใช้การรวมข้อมูลส่วนตัวเสมอ
พื้นที่คีย์ 128 บิต ความชัดเจนเกี่ยวกับข้อจํากัดของพื้นที่คีย์ 128 บิต เราจะทําให้ข้อจํากัดของคีย์สเปซนี้ชัดเจนขึ้นและแก้ไขความไม่สอดคล้องกันระหว่างหน้าต่างๆ เราขอแนะนำให้ใช้กลยุทธ์การแฮชเพื่ออยู่ในคีย์สเปซนี้
ข้อมูลสนับสนุนสูงสุดต่อรายงาน ขีดจํากัดปัจจุบันของการมีส่วนร่วม 20 รายการต่อรายงานนั้นต่ำเกินไป เราเปิดกว้างที่จะพิจารณาแยกรายงานแทนการตัดข้อมูลให้สั้นลงตามขีดจํากัดแทนที่จะเพิ่มจํานวนการมีส่วนร่วมสูงสุด เราจะมีส่วนร่วมกับระบบนิเวศเมื่อข้อเสนอนี้พัฒนาขึ้น
การรายงานการเข้าถึง คำขอการรายงานการเข้าถึงแบบข้ามแพลตฟอร์ม/ข้ามอุปกรณ์ การเข้าถึงคือเมตริกพื้นฐานของการโฆษณาแบรนด์ ผู้ลงโฆษณาใช้การประมาณแบบข้ามแพลตฟอร์ม/ข้ามอุปกรณ์ในการรายงานการเข้าถึงและความถี่เพื่อวิเคราะห์แคมเปญและจัดสรรการใช้จ่าย โมเดลการเข้าถึงใช้คุกกี้ของบุคคลที่สามเป็นสัญญาณสําหรับการวัดโฆษณาที่แสดงในสภาพแวดล้อมของบุคคลที่สาม เทคโนโลยีโฆษณาจึงขอโซลูชันอื่นเมื่อเลิกใช้งานคุกกี้ของบุคคลที่สาม
 ทีม Privacy Sandbox กําลังสํารวจฟีเจอร์เพื่อรองรับวิธีการเข้าถึงแบบข้ามโดเมนหลังจากเลิกใช้งานคุกกี้ของบุคคลที่สาม
เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ

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

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
(รายงานในไตรมาสที่ 1 ปี 2023 ด้วย) คำแนะนำสำหรับรูปแบบของอุปกรณ์เพิ่มเติม คำขอสำหรับ User Agent Client Hints (UA-CH) เพื่อระบุรูปแบบอุปกรณ์เพิ่มเติม เช่น ทีวี, VR เรายังคงพิจารณาการตัดสินใจด้านการออกแบบที่สำคัญบางอย่าง (ว่าจะระบุค่าเดียว เช่น "ทีวี" หรือรายการความสามารถของรูปแบบ) แต่ยังคงสนใจที่จะสร้างต้นแบบของแนวคิดนี้
งบประมาณด้านความเป็นส่วนตัว ข้อจํากัดของงบประมาณความเป็นส่วนตัวอาจทําให้คําขอ UA-CH เป็นแบบไม่แน่นอนเมื่อส่งคําขอมากเกินไป ขณะนี้เรายังไม่มีข้อมูลอัปเดตใหม่เกี่ยวกับข้อเสนองบประมาณความเป็นส่วนตัว แต่เรามุ่งมั่นที่จะไม่จํากัดคําขอคำแนะนำไคลเอ็นต์ UA ก่อนที่เราจะเลิกใช้งานคุกกี้ของบุคคลที่สาม
ความเข้ากันได้ของเว็บไซต์ เว็บไซต์ใช้แบรนด์ UA-CH เพื่อจํากัดไม่ให้บางเบราว์เซอร์เข้าถึงเว็บไซต์ การมีรายการแบรนด์มีกรณีการใช้งานที่ถูกต้อง และหนึ่งในนั้นคือความเข้ากันได้ UA มีสิทธิ์ใช้แบรนด์หลายแบรนด์เพื่อแก้ปัญหาเหล่านี้

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

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

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
หลักเกณฑ์การทดสอบ ข้อมูลเกี่ยวกับวิธีทดสอบการลดการติดตามการเข้าออก เราได้เผยแพร่ บล็อกโพสต์ในเดือนพฤษภาคมพร้อมข้อมูลเพิ่มเติมเกี่ยวกับวิธีทดสอบการลดการติดตามการตีกลับ
เอกสารประกอบ ความชัดเจนในข้อเสนอการติดตามการตีกลับ ข้อเสนอปัจจุบันยังอยู่ระหว่างการพัฒนา และ Chrome จะอัปเดตข้อเสนออย่างต่อเนื่องเพื่อให้ข้อมูลและเพิ่มความชัดเจนให้กับระบบนิเวศ เรากำลังดำเนินการเพื่อแจ้งรายละเอียดเพิ่มเติมและยินดีรับฟังความคิดเห็นเพิ่มเติม
การลบคุกกี้ การลดการติดตามการตีกลับจะลบคุกกี้ทั้งหมดในโดเมนไหม การลดการติดตามการตีกลับ (BTM) จะล้างพื้นที่เก็บข้อมูลและแคชทั้งหมด ตามที่อธิบายไว้ที่นี่
การหลีกเลี่ยงการลดการติดตามการเข้าชม การแยกประเภทเครื่องมือติดตามการตีกลับอาจถูกข้ามด้วยการเปลี่ยนเส้นทางด้วยป๊อปอัปหรือแท็บใหม่ ข้อกําหนดเฉพาะของการลดการติดตามการเข้าออกยังอยู่ระหว่างการพัฒนา ที่ผ่านมาเรามุ่งเน้นที่การเปลี่ยนเส้นทางในแท็บเดียวกันเป็นหลัก แต่เราวางแผนที่จะพัฒนาขั้นตอนการเปิดป๊อปอัปในอนาคต เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การกำหนดเป้าหมายที่ใกล้เคียง งบประมาณด้านความเป็นส่วนตัวอาจส่งผลต่อกรณีการใช้งานการกําหนดเป้าหมายตามสถานที่ตั้ง เราได้รับความคิดเห็นเกี่ยวกับปัญหานี้และอยากทราบข้อมูลเพิ่มเติมเกี่ยวกับผลกระทบที่อาจเกิดขึ้นจากระบบนิเวศ

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

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
(รายงานในไตรมาสก่อนหน้าด้วย) ขีดจํากัดของโดเมน คำขอเพิ่มจำนวนโดเมนที่เชื่อมโยง Chrome กำลังประเมินขีดจำกัดตัวเลขที่เหมาะสมสำหรับชุดย่อยที่เกี่ยวข้องซึ่งจะรักษาสมดุลระหว่างความเป็นส่วนตัวและประโยชน์สำหรับกรณีการใช้งานที่ระบุไว้ ตั้งแต่เริ่มต้น Chrome ได้แชร์ว่าจำนวนที่แน่นอนของชุดย่อยที่เกี่ยวข้องยังไม่ได้รับการสรุป
กรณีการใช้งานที่ฝัง การรองรับกรณีการใช้งานแบบฝังที่ต้องใช้ชุดโดเมนของบุคคลที่หนึ่ง, CHIP และพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน Chrome ได้รับความคิดเห็นเกี่ยวกับกรณีการใช้งานนี้แล้ว ทีมกำลังตรวจสอบและยินดีรับความคิดเห็นเพิ่มเติม
การจัดการที่เก็บ ข้อมูลเกี่ยวกับนโยบายในการนําชุดโดเมนของบุคคลที่หนึ่งออกจากที่เก็บ GitHub หากมีความคลาดเคลื่อนหรือการละเลย Chrome ได้รับความคิดเห็นเกี่ยวกับกรณีการใช้งานนี้แล้ว ทีมกำลังตรวจสอบและยินดีรับความคิดเห็นเพิ่มเติม
การให้ความรู้ผู้ใช้ Chrome ควรเพิ่มความตระหนักรู้และทำความเข้าใจของผู้ใช้เกี่ยวกับชุดข้อมูลจากบุคคลที่หนึ่งเพื่อกระตุ้นการใช้งาน Chrome มุ่งมั่นที่จะให้ความรู้แก่ผู้ใช้เกี่ยวกับชุดของบุคคลที่หนึ่ง และเผยแพร่ บทความในศูนย์ช่วยเหลือ (ลิงก์จาก UI ของ Chrome) เกี่ยวกับเรื่องนี้ นอกจากนี้ Chrome ยังลงทุนในการศึกษาวิธีให้ความรู้แก่ผู้ใช้ในบริบทที่เหมาะสมให้ดีที่สุดอย่างต่อเนื่อง
โพสต์ 3PCD คุกกี้ของบุคคลที่สามจะยังคงอยู่ในชุดของบุคคลที่หนึ่งหลังจากเลิกใช้งานคุกกี้ของบุคคลที่สาม แม้ว่า requestStorageAccess และ requestStorageAccessFor จะทำให้คุกกี้ของบุคคลที่สามพร้อมใช้งานอีกครั้งสำหรับ Use Case ที่เฉพาะเจาะจงซึ่งระบุไว้อย่างชัดเจน แต่ตอนนี้เว็บไซต์จะต้องเรียกใช้คุกกี้เหล่านี้แทนที่จะพร้อมใช้งานโดยค่าเริ่มต้น เช่นเดียวกับสถานะปัจจุบันของคุกกี้ของบุคคลที่สาม (ใน Chrome)

แม้ว่าการเรียกใช้ภายในชุดเดียวนี้จะไม่จําเป็นต้องได้รับการอนุมัติจากผู้ใช้ แต่ผู้ใช้สามารถป้องกันการดำเนินการนี้ได้โดยการเลือกไม่ใช้ลักษณะการทำงานนี้ในการตั้งค่า

ผู้ใช้สามารถดูข้อมูลเพิ่มเติมได้ในบทความในศูนย์ช่วยเหลือ (ลิงก์จาก UI ของ Chrome) เราวางแผนที่จะขยายคู่มือนักพัฒนาซอฟต์แวร์ที่มีอยู่เมื่อ FPS เพิ่มขึ้นเป็น 100%
การส่งชุดบุคคลที่หนึ่ง เปลี่ยนชื่อ .well-known/first-party-set ที่จำเป็นให้มีนามสกุล .json เราทำการเปลี่ยนแปลงนี้เพื่อรองรับแพ็กเกจเว็บโฮสติ้งบางรายการ
การจดทะเบียน IANA first_party_sets.JSON ควรจดทะเบียนกับ IANA เรากำลังพิจารณาข้อเสนอและยินดีรับความคิดเห็นเพิ่มเติมที่นี่

Fenced Frames API

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การบล็อกโฆษณา เฟรมที่มีขอบเขตอาจทําให้ตัวบล็อกโฆษณาบล็อกโฆษณาได้ง่ายขึ้น ส่วนขยายสามารถโต้ตอบกับเฟรมที่มีการกำหนดขอบเขตได้คล้ายกับที่โต้ตอบกับ iframe ส่วนขยายจะมองเห็น URL จริงที่กำลังจะไปยังเฟรมที่มีการป้องกันด้วย จึงใช้กฎการจับคู่ URL ใดก็ได้เพื่อบล็อกได้เช่นเดียวกับใน iframe การบล็อกเฟรมที่มีรั้วทั้งหมดโดยไม่มีเงื่อนไขอาจทำให้กรณีการใช้งานที่ไม่ใช่โฆษณาของเฟรมที่มีรั้วใช้งานไม่ได้

Shared Storage API

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การนําไปใช้ในวงกว้าง พื้นที่เก็บข้อมูลที่ใช้ร่วมกันควรเป็นมาตรฐานทั่วทั้งอุตสาหกรรมที่ใช้ได้กับเบราว์เซอร์ต่างๆ เรายินดีรับฟังและรับทราบความคิดเห็นนี้ Chrome จะยังคงมีส่วนร่วมในฟอรัม W3C เพื่อสนับสนุนข้อเสนอนี้ต่อไป รวบรวมความคิดเห็น และกระตุ้นให้เกิดการนำไปใช้งาน
เกตเอาต์พุต เกตเอาต์พุตของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันถูกจํากัดมากเกินไป เรากำลังพิจารณาความคิดเห็นนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศว่าเหตุใดเกตเอาต์พุตจึงจํากัดเกินไป
การปฏิบัติตามกฎระเบียบ พื้นที่เก็บข้อมูลที่ใช้ร่วมกันจะจัดการการปฏิบัติตามข้อกำหนด เช่น นโยบายการเก็บรักษาข้อมูล อย่างไร พื้นที่เก็บข้อมูลที่ใช้ร่วมกันมีความยืดหยุ่นในการใช้งานและปรับแต่งตรรกะเพื่อควบคุมอายุการใช้งานและการหมดอายุของข้อมูลที่จัดเก็บไว้ เทคโนโลยีโฆษณาสามารถอัปเดตหรือล้างข้อมูลพื้นที่เก็บข้อมูลที่ใช้ร่วมกันตามการประทับเวลาการเขียน
การทดสอบ A/B วิธีการทดสอบ A/B สําหรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกันและ Protected Audience API เรากำลังดำเนินการเผยแพร่คำแนะนำเพิ่มเติมเกี่ยวกับเรื่องนี้และหวังว่าจะได้แชร์รายละเอียดเพิ่มเติมในอนาคต
ขีดจํากัดพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน จะเกิดอะไรขึ้นเมื่อใช้พื้นที่เก็บข้อมูลร่วมกันเกินขีดจำกัด หากถึงขีดจํากัด ระบบจะไม่จัดเก็บอินพุตเพิ่มเติม
การเข้าถึงหลายครั้งในการโหลดหน้าเว็บเดียวกัน จะเกิดอะไรขึ้นเมื่อมีการเข้าถึงพื้นที่เก็บข้อมูลที่ใช้ร่วมกันหลายครั้งในการโหลดหน้าเว็บเดียวกัน วิธีที่ดีที่สุดในการจัดการกับปัญหานี้คือการใช้ฟังก์ชัน window.sharedStorage.append(key, value) แทนที่จะอัปเดตค่าสําหรับโฆษณาแต่ละรายการ ซึ่งอาจทําให้เกิดความทับซ้อนกันหากมีโฆษณาหลายรายการ ฟังก์ชันต่อท้ายจะเพิ่มค่าใหม่ต่อท้ายค่าที่มีอยู่
ฟังก์ชันของ iframe พื้นที่เก็บข้อมูลที่ใช้ร่วมกันจะรองรับฟังก์ชันการทำงานของ iframe บางรายการไหมเมื่อ iframe ไม่ทำงานอีกต่อไปหลังจากมีการเลิกใช้งานคุกกี้ของบุคคลที่สาม หลังจากเลิกใช้งานคุกกี้ของบุคคลที่สามแล้ว พื้นที่เก็บข้อมูลในเครื่องของ iframe จะแบ่งพาร์ติชันโดยเว็บไซต์ระดับบนสุด แต่ระบบจะไม่บล็อก iframe เอง ระบบไม่สามารถทำซ้ำข้อมูลในพื้นที่เก็บข้อมูลในระบบของ iframe ในเว็บไซต์ระดับบนสุดหลายแห่งได้ แต่ยังคงใช้พื้นที่เก็บข้อมูลในระบบภายใน iframe ได้

CHIPs

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
ขีดจํากัดพาร์ติชัน 10 KiB ต่อเว็บไซต์ที่มีการแบ่งพาร์ติชันยังคงมีขนาดใหญ่มากและเราต้องการลดขนาดลง Firefox ได้ระบุ ตำแหน่งเชิงบวกใน CHIPS แล้ว สำหรับการสนับสนุน Webkit เราขอแนะนำให้นักพัฒนาแอปแสดงความคิดเห็นต่อ Apple โดยตรงเกี่ยวกับ ปัญหานี้ใน GitHub เกี่ยวกับ Use Case ที่ควรใช้คุกกี้ที่มีการแบ่งพาร์ติชันมากกว่าพื้นที่เก็บข้อมูลที่แบ่งพาร์ติชัน
การฝังที่ได้รับการตรวจสอบสิทธิ์ CHIP อาจส่งผลต่อขั้นตอนการลงชื่อเข้าใช้ SSO ปัจจุบันเนื่องจากการแบ่งพาร์ติชันที่แตกต่างกันซึ่งส่งผลต่อการฝังที่ตรวจสอบสิทธิ์แล้ว เราตั้งใจที่จะใช้ประโยชน์จาก Storage Access API (พร้อมข้อความแจ้งผู้ใช้) เพื่อรองรับ Use Case ของเนื้อหาที่ฝังซึ่งมีการรับรอง และเพิ่งส่ง ความตั้งใจที่จะสร้างต้นแบบ
นโยบายตลอดอายุการใช้งาน นโยบายอายุการใช้งานที่อาจเกิดขึ้นจะมีผลกับคุกกี้ของบุคคลที่หนึ่งหรือไม่ ขณะนี้เราไม่มีแผนที่จะใช้ขีดจํากัดตลอดอายุการใช้งานกับคุกกี้ของบุคคลที่หนึ่ง

FedCM

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การรองรับการให้สิทธิ์ OAuth ปรับให้สอดคล้องกันเกี่ยวกับการให้สิทธิ์ขอบเขต OAuth ที่ไม่ใช่โปรไฟล์ เรากําลังมองหาข้อมูลจากชุมชน Web Identity ผ่าน W3C FedID CG เพื่อหาวิธีที่ดีที่สุดในการสนับสนุนการให้สิทธิ์นอกเหนือจากการตรวจสอบสิทธิ์พื้นฐานหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม
การสนับสนุน SAML ปรับให้สอดคล้องกับข้อกำหนดสำหรับการสนับสนุน SAML ทีมกำลังมองหาข้อมูลจากชุมชนการวิจัยและการศึกษาเกี่ยวกับความต้องการการสนับสนุน SAML (นอกเหนือจากการสนับสนุน OpenID Connect) หลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม

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

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การสํารวจสัญญาณใหม่ พาร์ทเนอร์หลายรายแสดงความคิดเห็นเชิงบวกเกี่ยวกับการสำรวจสัญญาณความสมบูรณ์ของอุปกรณ์หรือความไว้วางใจของผู้ใช้ที่ได้จากเบราว์เซอร์ โดยทั่วไปแล้ว ทีมยังระมัดระวังเกี่ยวกับสัญญาณใหม่ที่สร้างขึ้นเพื่อวัตถุประสงค์เฉพาะว่าจะเพียงพอที่จะรักษาระดับการตรวจจับการประพฤติมิชอบในปัจจุบันไว้ได้หรือไม่ เรายินดีที่จะสำรวจข้อเสนอใหม่ๆ ร่วมกันภายในชุมชนป้องกันการประพฤติมิชอบและความปลอดภัยบนเว็บ รวมถึงรับทราบและแชร์ข้อกังวลต่างๆ ของชุมชน ด้วยเหตุนี้ "การต่อสู้กับสแปมและกลโกง" จึงถือเป็นเวิร์กสตรีมหลักของ Privacy Sandbox และเราจึงให้ความสําคัญกับการลงทุนในการรักษาความปลอดภัยบนเว็บอย่างต่อเนื่องขณะที่ปรับปรุงความเป็นส่วนตัวของผู้ใช้
ความคิดเห็นเชิงบวกเกี่ยวกับ PST พาร์ทเนอร์หลายรายแสดงความสนใจในการทดสอบหรือใช้ PST สำหรับกรณีการใช้งานต่างๆ ในการป้องกันการประพฤติมิชอบหรือความปลอดภัยบนเว็บ เรายินดีที่ได้ทราบว่าคุณให้การสนับสนุนและสนใจที่จะสำรวจโซลูชันใหม่ๆ เพิ่มเติมซึ่งใช้ PST เรามีแหล่งข้อมูลและโค้ดตัวอย่างให้ใช้งานผ่านเว็บไซต์สำหรับนักพัฒนาซอฟต์แวร์ Chrome และยินดีรับฟังความคิดเห็นเพิ่มเติม
การประพฤติมิชอบและการละเมิด คำแนะนำสำหรับการป้องกันการประพฤติมิชอบในโฆษณา / การตรวจจับในการวัดผลหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามเมื่อไม่มีตัวระบุอีกต่อไป เราได้เปิดตัวเครื่องมือต่างๆ เช่น โทเค็นสถานะส่วนตัว ซึ่งช่วยกู้คืนสัญญาณบางส่วนที่คุกกี้ของบุคคลที่สามสูญหายเพื่อวัตถุประสงค์ในการป้องกันการประพฤติมิชอบ แต่มีการควบคุมความเป็นส่วนตัวใหม่ เรากําลังลงทุนอย่างจริงจังในข้อเสนอใหม่เพื่อต่อต้านการประพฤติมิชอบและการละเมิด เพื่อรักษาความสามารถไว้กับการเปลี่ยนแปลงอื่นๆ ของ Privacy Sandbox
อัตราข้อมูลผู้ออกบัตรถึงต้นทาง อัตราข้อมูลของผู้ออกบัตรไปยังต้นทางสูงพอที่จะระบุผู้ใช้ที่ไม่ซ้ำ เราได้อัปเดตข้อกำหนดเฉพาะให้ชัดเจนยิ่งขึ้นเกี่ยวกับข้อมูลผู้ใช้ที่ส่งได้โดยใช้โทเค็นสถานะส่วนตัว โดยการออกแบบ คุณจะใช้ได้ครั้งละ 6 คีย์สาธารณะ ซึ่งอาจแสดงถึง "สถานะ" ของผู้ใช้รายหนึ่งๆ ชุดคีย์เหล่านี้จะอัปเดตได้ทุก 60 วันเท่านั้น (ยกเว้นในกรณีที่จำเป็นต้องเปลี่ยนคีย์ฉุกเฉิน ซึ่งเกิดขึ้นไม่บ่อยนัก) ซึ่งจะทำให้มีโอกาสเข้าร่วมข้อมูลผู้ใช้เพิ่มเติมได้ช้าลงเมื่อเวลาผ่านไป เว็บ API ใหม่ใดๆ ก็ตามต้องมีความสมดุลระหว่างยูทิลิตีที่ให้บริการและข้อมูลผู้ใช้ใหม่สุทธิที่ให้บริการ เราประเมินว่า PST ช่วยให้เกิดความสมดุลที่เหมาะสมในการปกป้องความเป็นส่วนตัวของผู้ใช้ ขณะเดียวกันก็เปิดใช้ Use Case หลักๆ ในการป้องกันการประพฤติมิชอบที่ได้รับผลกระทบจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม
การผสานรวมการดึงข้อมูล การผสานรวม fetch มีความซับซ้อนและไม่จำเป็น การใช้ fetch มีทั้งข้อดีและข้อเสีย และเราต้องการทำให้มาตรฐานนี้มีความครอบคลุมมากขึ้นในระบบนิเวศของเว็บ แต่เราคิดว่ายังเร็วเกินไปที่จะทำการเปลี่ยนแปลงนี้จนกว่าเราจะทราบภาพรวมที่ชัดเจนขึ้นเกี่ยวกับมาตรฐานดังกล่าว หากมีมาตรฐานเกิดขึ้น เรามุ่งมั่นที่จะเปลี่ยนนักพัฒนาเว็บไปใช้มาตรฐานดังกล่าวอย่างมีความรับผิดชอบ
ตำแหน่งพื้นที่เก็บข้อมูล การกำหนดค่าคีย์โทเค็นสถานะส่วนตัวควรจัดเก็บไว้ในตำแหน่งเดียวกับโปรโตคอล PrivacyPass ในระหว่างการทดสอบในช่วงทดลองใช้ Origin นักพัฒนาแอประบุว่าต้องการความยืดหยุ่นในการเก็บคีย์ไว้ใน URL ทั่วไปแทนที่จะเป็นไดเรกทอรี .well-known รูปแบบความมุ่งมั่นของคีย์ใน PrivacyPass นั้นไม่เหมาะกับเวอร์ชันที่ชุดคีย์มีไว้เพื่ออนุญาตให้ใช้ค่า "ข้อมูลเมตาสาธารณะ" โดยนัย หากรูปแบบของ PrivacyPass ได้รับการกำหนดมาตรฐานด้วยข้อมูลเมตาสาธารณะ (ไม่ว่าจะเป็น POPRF, การปิดบัง RSA บางส่วน หรือชุดคีย์) เราอาจเปลี่ยนไปใช้ PST เวอร์ชันในอนาคตเพื่อรองรับรูปแบบดังกล่าว
การใช้ส่วนหัวของ API คำถามเกี่ยวกับการติดตั้งใช้งานส่วนหัวของ API เมื่อ API ได้รับการมาตรฐานและการใช้งานระบบนิเวศของ API นี้มีความซับซ้อนมากขึ้น เราหวังว่าจะรองรับทั้ง API เวอร์ชันมาตรฐานที่ไม่มีส่วนหัวและอาจเลิกใช้งานเวอร์ชันที่มีส่วนหัวในท้ายที่สุดหากมีการใช้งานน้อยมากหรือมีเครื่องมือ/การสนับสนุนนักพัฒนาแอปเพียงพอสำหรับวิธีมาตรฐานในการเชื่อมโยงคำขอออก/แลกสิทธิ์กับข้อมูลอื่นๆ เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่
การลงทะเบียน การทำให้ผู้ออกบัตรต้องลงทะเบียนกับผู้ให้บริการเบราว์เซอร์มีความเป็นไปได้จริงหรือไม่ เราได้อัปเดตข้อกำหนดเพื่ออธิบายกระบวนการจดทะเบียนผู้ออกโทเค็นสถานะส่วนตัว แม้ว่าจะมีกระบวนการเป็นของตัวเอง แต่แผนนี้คล้ายกับแผนการลงทะเบียนสําหรับส่วนที่เหลือของ Privacy Sandbox ซึ่งเราขอให้ผู้ออกใบอนุญาตประกาศต่อสาธารณะเกี่ยวกับความตั้งใจในการใช้ PST และรับทราบข้อจํากัดทางเทคนิคที่ปกป้องความเป็นส่วนตัวของผู้ใช้