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