รายงานรายไตรมาสสำหรับไตรมาสที่ 2 ปี 2025 ซึ่งสรุปความคิดเห็นจากระบบนิเวศที่ได้รับเกี่ยวกับ ข้อเสนอ Privacy Sandbox และการตอบสนองของ Chrome
Google ได้จัดทำรายงานรายไตรมาสนี้เป็นส่วนหนึ่งของความมุ่งมั่นต่อ Competition and Markets Authority ("CMA") ภายใต้วรรคที่ 12, 17(ค)(2) และ 32(ก) รายงานนี้ครอบคลุมความคืบหน้าของ Google เกี่ยวกับข้อเสนอ Privacy Sandbox, การปรับปรุงการคาดการณ์เวลา, คำอธิบายที่สำคัญเกี่ยวกับวิธีที่ Google พิจารณาข้อสังเกตของบุคคลที่สาม และสรุปการโต้ตอบระหว่าง Google กับ CMA ซึ่งรวมถึงความคิดเห็นจาก CMA และแนวทางของ Google ในการจัดการกับความคิดเห็น
Google ได้แจ้งให้ CMA ทราบถึงความคืบหน้าเกี่ยวกับข้อเสนอ Privacy Sandbox ในการประชุมเพื่ออัปเดตสถานะเป็นประจำตามที่กำหนดไว้ในย่อหน้าที่ 17(b) ของข้อตกลง นอกจากนี้ ทีมยังดูแลเอกสารประกอบสําหรับนักพัฒนาซอฟต์แวร์ ซึ่งมีภาพรวมของฟีเจอร์หลักของการโฆษณาส่วนตัวและการเปลี่ยนแปลงคุกกี้ รวมถึงการติดตั้งใช้งาน API และข้อมูลสถานะ เราจะแชร์ข้อมูลอัปเดตที่สำคัญในบล็อกของนักพัฒนาแอป พร้อมกับการอัปเดตที่เจาะจงซึ่งแชร์ไปยังรายชื่ออีเมลของนักพัฒนาแอปแต่ละราย
พิจารณาตามข้อสังเกตของบุคคลที่สาม
อภิธานศัพท์ของตัวย่อ
- ARA
- Attribution Reporting API
- CHIPS
- Cookies Having Independent Partitioned State
- DSP
- แพลตฟอร์มฝั่งดีมานด์
- FedCM
- Federated Credential Management
- IAB
- Interactive Advertising Bureau
- IDP
- ผู้ให้บริการข้อมูลประจำตัว
- IETF
- คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต
- IP
- ที่อยู่ Internet Protocol
- openRTB
- การเสนอราคาแบบเรียลไทม์
- OT
- ช่วงทดลองใช้จากต้นทาง
- PA API
- Protected Audience API (เดิมคือ FLEDGE)
- PatCG
- กลุ่มชุมชนเทคโนโลยีโฆษณาส่วนตัว
- RP
- บุคคลที่สาม
- RWS
- ชุดเว็บไซต์ที่เกี่ยวข้อง (เดิมคือชุดโดเมนของบุคคลที่หนึ่ง)
- SSP
- แพลตฟอร์มฝั่งขาย
- UA
- สตริง User Agent
- UA-CH
- คำแนะนำสำหรับไคลเอ็นต์ User Agent
- W3C
- World Wide Web Consortium
- WIPB
- การจงใจไม่รับรู้เรื่อง IP
ความคิดเห็นทั่วไป ไม่ได้เจาะจง API/เทคโนโลยี
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| อนาคตของ Privacy Sandbox | เนื่องจากการประกาศว่าจะไม่ดำเนินการต่อในการเปิดตัว กลไกทางเลือกของผู้ใช้สำหรับคุกกี้ของบุคคลที่สาม API บางรายการจึงมีประโยชน์มากกว่า รายการอื่นๆ เมื่อมีคุกกี้ของบุคคลที่สาม และ API บางรายการจะต้องได้รับการพัฒนาเพื่อให้มีประโยชน์ นอกจาก Privacy Sandbox API แล้ว Chrome ยังมีส่วนอื่นๆ ที่อาจต้องลงทุนเพิ่มเติมด้วย | เราขอขอบคุณสำหรับความคิดเห็นและจะยังคงทำงานร่วมกับ ผู้มีส่วนเกี่ยวข้องเพื่อประเมินบทบาทของ Privacy Sandbox API ในอนาคต รวมถึงสำรวจพื้นที่ใหม่ๆ สำหรับการลงทุนในอนาคต ตามประกาศของ Google ในเดือนเมษายน 2025 ว่าเราจะยังคงใช้วิธีการปัจจุบันในการให้ผู้ใช้เลือก 3PC ใน Chrome ต่อไป |
| Privacy Sandbox | ผู้เข้าร่วมระบบนิเวศบางรายรู้สึกผิดหวังกับการประกาศที่จะ ไม่ดำเนินการต่อในการเปิดตัวกลไกทางเลือกของผู้ใช้สำหรับ 3PC แต่ก็ภูมิใจกับผลงานที่ทำได้ ชื่นชม ความท้าทายทางเทคนิคภายใน Privacy Sandbox และได้เน้นย้ำถึง คุณค่าของความสัมพันธ์ในการทำงานร่วมกันกับ Chrome และ ประโยชน์ของเงินช่วยเหลือสำหรับการทดสอบตลาด | เราขอขอบคุณสำหรับความคิดเห็นและเห็นด้วยว่า Chrome สามารถและควร ทำงานร่วมกับนักพัฒนาแอปเพื่อสร้างเทคโนโลยีที่ช่วยปรับปรุง ความเป็นส่วนตัวทางออนไลน์ในขณะที่ยังคงรักษาอินเทอร์เน็ตที่มีโฆษณาสนับสนุนเอาไว้ |
| การแชร์ข้อมูลเบราว์เซอร์ | การแชร์ข้อมูลผ่านเบราว์เซอร์เป็นเทคโนโลยีที่น่าสนใจซึ่งมี ศักยภาพในการแก้ปัญหาความไม่มีประสิทธิภาพของตลาดและปัญหาความน่าเชื่อถือ เบราว์เซอร์มีค่าเป็นบริบทการดำเนินการของบุคคลที่สามสำหรับการ ทำงานร่วมกัน | เราขอขอบคุณสำหรับความคิดเห็นและเห็นด้วยว่า Chrome สามารถและควรมีบทบาทในการช่วยนักพัฒนาซอฟต์แวร์สร้างเทคโนโลยีที่ช่วยเพิ่มความน่าเชื่อถือระหว่างนักพัฒนาซอฟต์แวร์ที่ทำงานร่วมกันและผู้ใช้ |
| การเข้าชมจาก Chrome | สัดส่วนของการเข้าชมแบบไม่มีคุกกี้ใน Chrome และสัดส่วนของการเข้าชมสำหรับโหมดไม่ระบุตัวตนคือเท่าใด | ตามที่ CMA ระบุไว้ใน "ประกาศ
ความตั้งใจที่จะเผยแพร่ข้อผูกมัด" โหมดไม่ระบุตัวตนจะส่งผลต่อ
กิจกรรมการท่องเว็บเพียงเล็กน้อยเท่านั้น ในสหราชอาณาจักรและ
EEA โหมดไม่ระบุตัวตนของ Chrome แสดงถึงการนำทางน้อยกว่า 10% ในอุปกรณ์ที่ใช้ระบบปฏิบัติการ Android และการนำทางน้อยกว่า 10%
ในอุปกรณ์ที่ใช้ระบบปฏิบัติการ Windows
เมตริกเหล่านี้หมายถึงการไปยังส่วนต่างๆ ใน Chrome ที่ใช้ Chromium ในสหราชอาณาจักรและ EEA เท่านั้น
เราจะไม่แชร์ข้อมูลเกี่ยวกับเบราว์เซอร์ที่บล็อก 3PC นักพัฒนาแอปสามารถกำหนดเวลาที่จะแบ่งพาร์ติชันคุกกี้ได้โดยใช้ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูล และใช้การบรรเทาที่มีอยู่ตามความเหมาะสม |
| ป้ายกำกับการทดสอบ Chrome | แผนของ Chrome สำหรับการเข้าชมแบบไม่ใช้คุกกี้ 1% ที่เปิดใช้ เพื่อการทดสอบในปี 2024 คืออะไร | ขณะนี้เรายังไม่มีแผนที่จะแชร์ แต่เราตั้งใจที่จะแชร์ ต่อสาธารณะทันทีที่พร้อม |
| การทดสอบ Chrome | การตั้งค่าป้ายกำกับการทดสอบปัจจุบันมีการทดสอบสำหรับสถานการณ์ที่ทั้งคุกกี้ของบุคคลที่สามและ Privacy Sandbox API พร้อมใช้งานและเปิดใช้หรือไม่ | การตั้งค่าป้ายกำกับการทดสอบปัจจุบันรวมถึงการทดสอบทั้งสำหรับคุกกี้ของบุคคลที่สามและ Privacy Sandbox API ในรูปแบบของโหมด A |
| Privacy Sandbox | ผู้ลงโฆษณาบางรายเห็นว่า Privacy Sandbox API มีความซับซ้อนและ รู้สึกไม่แยแสเนื่องจากการเตรียมความพร้อมก่อนหน้านี้ โดยตั้งคำถาม ว่าจะวัดผลประโยชน์ของผู้ที่นำมาใช้ก่อนได้อย่างไร และกำลังมองหา การให้ความรู้เกี่ยวกับผลลัพธ์ของการรีทาร์เก็ตติ้ง การค้นหาลูกค้าใหม่ และ การวัดผล | ขอขอบคุณสำหรับความคิดเห็นและเราเข้าใจถึงความรู้สึกเกี่ยวกับ
ความซับซ้อนทางเทคโนโลยีและการฝึกความพร้อม ในส่วนของการทำความเข้าใจประสิทธิภาพของเทคโนโลยี Privacy Sandbox ปัจจุบัน ผลการทดสอบของเราชี้ให้เห็นว่าการเข้าร่วมในระบบนิเวศ เป็นปัจจัยสำคัญในการทำความเข้าใจประสิทธิภาพ ของโซลูชัน Privacy Sandbox การทดสอบในปริมาณน้อยไม่สามารถ จำลองพลวัตของตลาดกลางและสิ่งจูงใจในการใช้ เทคโนโลยีในวงกว้างได้ |
การลงทะเบียนและการรับรอง
ไม่ได้รับความคิดเห็นในไตรมาสนี้
แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง
หัวข้อ
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ความสนใจด้านประสิทธิภาพและยูทิลิตีใน Topics API พร้อมการปรับปรุง | ความคิดเห็นจากผู้มีส่วนได้ส่วนเสียฝั่งซื้อระบุว่า Topics API เป็น สัญญาณที่มีคุณค่าและส่งผลให้ข้อมูลต้นทุนต่อการแสดงผล (CPM) ที่ แข่งขันได้กับข้อมูลสำหรับกลุ่มเป้าหมาย 3PC สำหรับแคมเปญของผู้ลงโฆษณา ผู้เผยแพร่โฆษณาบางรายมองว่าสัญญาณของ Topics API มีคุณภาพสูงกว่าสัญญาณเว็บแบบเปิดมาตรฐาน จากความคิดเห็นเกี่ยวกับประโยชน์ของ Topics API ผู้มีส่วนเกี่ยวข้องจึงขอให้มีการปรับปรุง เช่น การปรับปรุงความถูกต้อง ความสอดคล้องของอนุกรมวิธาน และการขยายการควบคุมของผู้เผยแพร่โฆษณาเพื่อกระตุ้นให้มีการนำไปใช้ในวงกว้าง | เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| ประโยชน์สำหรับ ผู้มีส่วนเกี่ยวข้อง ประเภทต่างๆ |
เนื่องจากปัจจุบันเครื่องมือจัดประเภทของ Topics ใช้เฉพาะชื่อโฮสต์ของหน้าเว็บ เพื่อกำหนดหัวข้อที่เกี่ยวข้อง เว็บไซต์ขนาดใหญ่ที่มีเนื้อหาหลากหลาย จึงมีส่วนร่วมในหัวข้อทั่วไป ขณะที่เว็บไซต์ขนาดเล็กมีส่วนร่วมใน หัวข้อเฉพาะที่มีมูลค่าการโฆษณาสูงกว่า | การตอบสนองของเราคล้ายกับไตรมาสก่อนๆ ดังนี้ เช่นเดียวกับคุกกี้ของบุคคลที่สาม มูลค่าของข้อมูล ที่เว็บไซต์ต่างๆ มีส่วนร่วมนั้นแตกต่างกัน เว็บไซต์ที่เจาะจงความสนใจเฉพาะกลุ่มมีมูลค่าไม่สอดคล้องกัน เนื่องจากเว็บไซต์ที่เจาะจงความสนใจเฉพาะกลุ่มบางเว็บไซต์ไม่มี เนื้อหาที่มีมูลค่าเชิงพาณิชย์ จึงมีมูลค่าน้อยกว่า เว็บไซต์เหล่านี้จะได้รับประโยชน์จาก Topics API เราได้พิจารณาความเป็นไปได้ในการจัดประเภทระดับหน้าเว็บแทนระดับเว็บไซต์แล้ว แต่การจัดประเภทดังกล่าวมีข้อกังวลด้านความเป็นส่วนตัวและความปลอดภัยที่สำคัญหลายประการ |
| การจัดหมวดหมู่ Topics ไม่ละเอียดพอ | Topics API ไม่มีความละเอียดเพียงพอสำหรับผู้เผยแพร่ข่าวที่มีส่วนเนื้อหาหลากหลายภายในโดเมนเดียว ซึ่งอาจจำกัดประโยชน์ของ API ในการกำหนดเป้าหมายโฆษณา | เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| การปรับปรุงตัวแยกประเภท | อนุญาตให้ผู้เผยแพร่โฆษณามอบสิทธิ์ให้ Chrome จัดหมวดหมู่หัวข้อตาม เนื้อหาในหน้าเว็บ (เช่น ส่วนหัว เนื้อหา) | เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่ |
| นโยบาย | ขอคำชี้แจงเกี่ยวกับหลักเกณฑ์เกี่ยวกับการใช้ Topics API ร่วมกับข้อมูล 3PC | การใช้ทั้ง Topics API และคุกกี้ของบุคคลที่สามนั้นไม่มีปัญหาใดๆ เนื่องจาก Topics API มีฟังก์ชันการทำงานบางส่วนของคุกกี้ของบุคคลที่สาม |
| ส่วนหัว Observe-Browse-Topics | ขอคำชี้แจงเกี่ยวกับการติดตั้งใช้งานส่วนหัว Observe-Browse-Topics โดยเฉพาะอย่างยิ่งการส่งส่วนหัวอย่างต่อเนื่องจะทำให้เกิดปัญหาหรือไม่ | การส่งคืนส่วนหัว Observe-Browse-Topics: ?1
อย่างต่อเนื่องจะไม่ทำให้เกิดปัญหาทางเทคนิคเบราว์เซอร์จะจัดการสัญญาณนี้อย่างมีประสิทธิภาพ โดยเพียงแค่บันทึกว่า การเข้าชมหน้าเว็บมีสิทธิ์ในการคำนวณหัวข้อโดยไม่ทำให้เกิด การทำซ้ำหรือข้อผิดพลาด แม้จะไม่จำเป็นต้องใส่ในทุกหน้า แต่การส่งเป็นส่วนหัวมาตรฐานในเอกสารระดับบนสุดทั้งหมดก็เป็นกลยุทธ์ที่ถูกต้องและเรียบง่าย |
| หมวดหมู่การจัดหมวดหมู่ | ขออัปเดตการจัดหมวดหมู่ Topics ล่าสุดด้วยหัวข้อใหม่ | เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจาก ระบบนิเวศที่นี่ |
| ค่า Null | ขอคำแนะนำในการปรับปรุงประสิทธิภาพของ Topics API และ ทำความเข้าใจสาเหตุของการตอบกลับเป็น Null เช่น การกรองหรือความละเอียดอ่อน | เพื่อความชัดเจน การตอบกลับที่nullหรือว่างเปล่าจาก Topics API
เป็นฟีเจอร์ด้านความเป็นส่วนตัวที่คาดไว้ ไม่ใช่ข้อผิดพลาดnullการตอบกลับอาจเกิดจากสาเหตุต่อไปนี้• กฎความเป็นส่วนตัว: โอกาสแบบสุ่ม 5% null
หรือเนื่องจากสคริปต์ของคุณไม่ได้ "สังเกต" ผู้ใช้ในเว็บไซต์
ที่เกี่ยวข้องกับหัวข้อนั้น• สถานะผู้ใช้: ประวัติการท่องเว็บไม่เพียงพอ การใช้โหมดไม่ระบุตัวตน หรือผู้ใช้เลือกไม่ใช้ในการตั้งค่าความเป็นส่วนตัวของโฆษณาใน Chrome • ข้อผิดพลาดทางเทคนิค: เว็บไซต์ของผู้เผยแพร่โฆษณาต้องส่งส่วนหัว Observe-Browse-Topics: ?1 และ iframe ที่เรียกใช้ทั้งหมดต้องมีสิทธิ์ allow="Browse-topics"
หากต้องการตรวจสอบ ให้ใช้หน้า chrome://topics-internalsการแก้ไขข้อบกพร่อง
เพื่อดูว่าเบราว์เซอร์คำนวณหัวข้อใดและเพราะเหตุใดแม้ว่าฟีเจอร์ด้านความเป็นส่วนตัวจะป้องกันไม่ให้มีอัตราการแสดงโฆษณา 100% แต่คุณก็ปรับปรุง ประสิทธิภาพได้โดยทำดังนี้ • ทำงานร่วมกับผู้เผยแพร่โฆษณา: ตรวจสอบว่าพาร์ทเนอร์ส่งส่วนหัว Observe-Browse-Topics: ?1 ในเว็บไซต์ของตนอย่างถูกต้อง
• การยืนยันโค้ด: หากใช้ iframe ให้ยืนยันว่ามี allow="Browse-topics"นโยบาย
|
Protected Audience API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ค่าใช้จ่ายและความซับซ้อนเป็นอุปสรรคต่อการนำ PA API มาใช้ | ผู้ใช้กำลังลดความสำคัญหรือยกเลิกการผสานรวม Protected Audience API
(PA API) โดยอ้างถึงต้นทุนการดำเนินงาน ความต้องการของผู้ลงโฆษณา
ที่ต่ำ และปริมาณพื้นที่โฆษณาจาก Exchange ที่ต่ำ ความคิดเห็นบางส่วนรวมถึงประโยชน์ของศักยภาพของ PA API เช่น ความสามารถในการเข้าถึงกลุ่มเป้าหมายที่ยั่งยืนและการเข้าถึงที่เหนือกว่าเนื่องจากมี อัตราการจับคู่สูง |
เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| ฟังก์ชันการทำงานข้ามแพลตฟอร์ม | ควรสนับสนุนฟังก์ชันการทำงานข้ามแพลตฟอร์มโดยใช้ PA API ในแพลตฟอร์มต่างๆ เพื่อปลดล็อกความสามารถในการรีทาร์เก็ตติ้งและการกำหนดกลุ่มเป้าหมายที่ดียิ่งขึ้น Google ควรเปิดใช้กลุ่มความสนใจ (IG) ที่ลงทะเบียน ใน Chrome เพื่อให้เข้าถึงได้เมื่อแสดงโฆษณาในสภาพแวดล้อมเนทีฟหรือ ภายใน WebView และกลุ่มความสนใจที่ลงทะเบียนใน Android ควร พร้อมใช้งานในการประมูลของ Chrome | เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| directFromSellerSignals | การจำกัดปริมาณข้อมูลที่มีในการประมูลตามบริบทจะทำให้ระบบกำหนดเส้นทางผู้เข้าร่วมการประมูลผ่านเซิร์ฟเวอร์โฆษณาของ Google เสมอ ผู้เผยแพร่โฆษณาต้องเรียกพาร์ทเนอร์ Exchange ทั้งหมดก่อน
จากนั้นจึงเรียก Google Ad Manager (GAM) เป็นอันดับที่ 2 เพื่อเรียกใช้การประมูลตามบริบท และ
สุดท้ายคืออนุญาตให้ GAM เรียกใช้การประมูล IG หากไม่ทราบผลลัพธ์ของการประมูลตามบริบทแบบเรียลไทม์ ก็ไม่มีคู่แข่งรายใดสามารถ
ประสานการตัดสินใจระดับบนสุดได้อย่างเป็นธรรม ฟีเจอร์ directFromSellerSignals ภายใน PA API อาจขาดความโปร่งใสเกี่ยวกับข้อมูลการประมูล ซึ่งอาจขัดขวางความสามารถในการเข้าถึงข้อมูลที่จำเป็น Google ควรนำ directFromSellerSignals ออกหรืออัปเดตเพื่อไม่ให้ใช้ซ่อน ราคาเคลียร์การประมูลของเซิร์ฟเวอร์โฆษณาได้ ตัวอย่างเช่น Chrome สามารถส่งต่อราคาตามบริบท ผ่านฟิลด์ที่ลงชื่อแล้วแบบโปร่งใสและเปลี่ยนแปลงไม่ได้ ซึ่งผู้เข้าร่วมการประมูลทั้งหมด (และผู้เผยแพร่โฆษณา) สามารถเข้าถึง และยืนยันได้ |
คำตอบของเรายังคงเหมือนเดิมจากไตรมาสก่อนๆ คำตอบของ Chrome: เราไม่ทราบว่าข้อมูลที่ส่งไปยัง runAdAuction() มาจากผู้ขาย เว้นแต่ผู้ขายจะเรียกใช้ runAdAuction() จาก iframe ของตนเอง ในการประมูลผู้ขายหลายราย ผู้ขายทั้งหมดไม่สามารถสร้างเฟรมที่เรียกใช้ runAdAuction() ได้ directFromSellerSignals แก้ไขปัญหานี้ด้วยการโหลดเนื้อหาจากชุดทรัพยากรย่อย ที่โหลดจากต้นทางของผู้ขาย วิธีนี้ช่วยให้มั่นใจได้ว่าจะไม่มีการดัดแปลงความถูกต้องและความสมบูรณ์ของข้อมูลที่ส่งไปยังการประมูลจากการกำหนดค่าการประมูลของผู้ขาย หากผู้เผยแพร่โฆษณา ต้องการใช้ PA API เพื่อทำความเข้าใจข้อมูลใดๆ ที่ผู้ให้บริการด้านเทคโนโลยี ส่งไปยังการประมูล PA ผู้เผยแพร่โฆษณาสามารถขอฟังก์ชันนี้จากผู้ให้บริการด้านเทคโนโลยี เหล่านั้นได้ คำตอบจาก Google Ad Manager: เราให้ความสำคัญกับความเป็นธรรมในการประมูลมาหลายปี รวมถึงสัญญาของเราที่ว่าเราจะไม่แชร์ราคาจากแหล่งโฆษณาที่ไม่รับประกันการแสดงผลของผู้เผยแพร่โฆษณารายใดก็ตาม รวมถึงราคาของรายการโฆษณาที่ไม่รับประกันการแสดงผล กับผู้ซื้อรายอื่นก่อนที่ผู้ซื้อรายนั้นจะเสนอราคาในการประมูล ซึ่งเราได้ยืนยันอีกครั้งในความมุ่งมั่น ต่อหน่วยงานกำกับดูแลด้านการแข่งขันของฝรั่งเศส สำหรับการประมูลที่ใช้ Protected Audience API เราตั้งใจที่จะรักษาสัญญาโดย ใช้ประโยชน์จาก directFromSellerSignals และจะไม่แชร์ราคาเสนอของผู้เข้าร่วม การประมูลรายใดกับผู้เข้าร่วมการประมูลรายอื่นๆ ก่อน สิ้นสุดการประมูลในการประมูลที่มีผู้ขายหลายราย เราจะไม่แชร์ราคาของการประมูลตามบริบทกับการประมูลคอมโพเนนต์ของเราเองตามที่อธิบายไว้ในการอัปเดตนี้ |
| การรายงาน | ขอเพิ่มเอนทิตีการวิเคราะห์/การรายงานเพื่อเปิดใช้การรายงานแบบรวมศูนย์ | เรากำลังพูดคุยเกี่ยวกับคำขอนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| K-Anonymity ใน buyerReportingId | ความสามารถในการทิ้งราคาเสนอตามการไม่ระบุตัวตนแบบ k ของ "buyerReportingId" เพื่ออำนวยความสะดวกในการดูแลจัดการกลุ่มเป้าหมายและภาระหน้าที่ในการรายงานกับผู้ให้บริการข้อมูลจากบุคคลที่สาม | เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| การแก้ไขข้อบกพร่องที่ปรับปรุงแล้วในสคริปต์ generateBid | ขอให้มีกลไกในการระบุขั้นตอนหรือ "เบรกพอยต์" ที่เฉพาะเจาะจงภายในสคริปต์ generateBid ที่กระบวนการล้มเหลวอย่างรวดเร็ว | เราทราบถึงการใช้งานที่ต้องการของการวัดแบบเรียลไทม์ในฐานะกลไกการตั้งค่าเบรกพอยต์สำหรับการประมูลในอุปกรณ์ เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| Event Listeners สำหรับการตรวจสอบสถานะ runAdAuction | ข้อเสนอในการเพิ่มการรองรับ Listener เหตุการณ์ลงในฟังก์ชัน navigator.runAdAuction ของ PA API เพื่อปรับปรุงการตรวจสอบวงจรการประมูลโฆษณา | เรากำลังประเมินคำขอนี้และยินดีรับความคิดเห็นเพิ่มเติมจาก ระบบนิเวศที่นี่ |
| การใช้ API | ขอคำชี้แจงเกี่ยวกับวิธีที่ PA API และ Attribution Reporting API (ARA) สามารถ รองรับกรณีการใช้งานการโฆษณาบนเว็บในกรณีที่ไม่มีคุกกี้ของบุคคลที่สาม โดยเฉพาะอย่างยิ่งสำหรับผู้ใช้ที่เลือกไม่ใช้คุกกี้ของบุคคลที่สามแต่ไม่ได้เลือกไม่ใช้ Privacy Sandbox API และในสถานการณ์ที่เกี่ยวข้องกับการซิงค์คุกกี้ที่ไม่สำเร็จ และ WebView | เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| เวลาในการตอบสนอง | เวลาในการตอบสนองที่เชื่อมโยงกับ PA API อาจขัดขวางการนำไปใช้ เนื่องจากผู้เผยแพร่โฆษณา อาจเลือกปิดใช้ PA API หากเวลาในการตอบสนองสูงเกินไป | ในช่วง 2-3 ไตรมาสที่ผ่านมา เราได้ปรับปรุงเวลาในการตอบสนองในอุปกรณ์หลายจุด การสร้างและขยายบริการเสนอราคาและการประมูล (B&A) จะดำเนินต่อไปตามความจำเป็น เราได้อัปเดตคำแนะนำเกี่ยวกับแนวทางปฏิบัติแนะนำ เรื่องเวลาในการตอบสนองเพื่อให้มีข้อมูลเพิ่มเติมเกี่ยวกับ วิธีใช้ประโยชน์จากฟีเจอร์เหล่านี้ นอกจากนี้ เรายังกำลังสำรวจ การพัฒนาการปรับปรุงเวลาในการตอบสนองใหม่ๆ ซึ่งคุณสามารถดูข้อมูลบางส่วนได้ที่นี่ |
| การบันทึกพฤติกรรมใน B&A (การทดสอบเทียบกับการใช้งานจริง) | การชี้แจงเกี่ยวกับความแตกต่างในลักษณะการทำงานของการบันทึกระหว่างโหมดทดสอบและโหมดที่ใช้งานจริงสำหรับบริการ B&A โดยเฉพาะอย่างยิ่ง ความพร้อมใช้งานของบันทึกในระบบคลาวด์และผลกระทบของโหมดการใช้งานต่อการบันทึก | ก่อนอื่น คุณต้องแยกความแตกต่างระหว่างบิลด์ prod กับ
non_prod และพารามิเตอร์ TEST_MODE แยกต่างหาก ซึ่ง
เพียงแค่เปิดใช้คีย์การเข้ารหัสทดสอบที่ฮาร์ดโค้ด คำอธิบายด้านล่าง
มุ่งเน้นที่ประเภทบิลด์ ในบิลด์ที่ไม่ใช่โปรดักชัน เซิร์ฟเวอร์ B&A มี ระดับความละเอียดที่กำหนดค่าได้สำหรับการบันทึก ระบบจะเขียนบันทึกโดยละเอียดเหล่านี้ ลงในสตรีม stdout/stderr มาตรฐาน ใน Google Cloud คุณจะเข้าถึงได้ผ่านอินเทอร์เฟซการบันทึกแบบเนทีฟ และใน Amazon Web Services คุณจะดูได้ในบันทึกของคอนโซลที่แนบมา สำหรับบิลด์โปรดักชัน ลักษณะการทำงานของการบันทึกจะถูกจำกัดมากขึ้น ระดับความละเอียดจะคงที่และเปลี่ยนแปลงไม่ได้ แม้ว่าระบบจะยังคงพิมพ์บันทึกบางรายการที่ไม่เกี่ยวข้องกับความเป็นส่วนตัว เช่น ข้อความเริ่มต้นของเซิร์ฟเวอร์และข้อผิดพลาดส่วนใหญ่ที่เกิดจากข้อขัดข้อง ไปยัง stdout/stderr แต่จะไม่มีบันทึกที่เฉพาะเจาะจงสำหรับคำขอผ่านช่องทางนี้ บันทึกต่อคำขอจากบิลด์ที่ใช้งานจริงมีไว้สำหรับคำขอที่มีโทเค็นการแก้ไขข้อบกพร่องที่ได้รับความยินยอมเท่านั้น และจะส่งออกผ่าน OpenTelemetry เท่านั้น การใช้การแก้ไขข้อบกพร่องที่ได้รับความยินยอมเท่าที่จำเป็นเป็นสิ่งสำคัญ เนื่องจากการเข้าชมจำนวนมากอาจทำให้ประสิทธิภาพของเซิร์ฟเวอร์ลดลงและทำให้ การตรวจสอบสถานะล้มเหลว ในส่วนของเมตริก ระบบจะส่งออกทั้งหมดผ่าน OpenTelemetry ระบบจะส่งออกเมตริกที่ไม่มีความละเอียดอ่อนด้านความเป็นส่วนตัวตามเดิมเสมอโดยไม่มีการ "เพิ่มสัญญาณรบกวน" ในทางกลับกัน เมตริกที่ละเอียดอ่อนด้านความเป็นส่วนตัว จะ "มีสัญญาณรบกวน" เสมอเมื่อส่งออกจากเซิร์ฟเวอร์ที่ทํางานในโหมดการผลิต การกำหนดค่าการวัดและส่งข้อมูลที่เฉพาะเจาะจงจะกำหนดว่าควรส่งออกเมตริกที่ละเอียดอ่อนด้านความเป็นส่วนตัวเหล่านี้เป็นแบบมีสัญญาณรบกวน ไม่มีสัญญาณรบกวน หรือทั้ง 2 แบบ |
| รวมเส้นทางแบบเต็มของหน้าเว็บในสัญญาณการเสนอราคาที่เชื่อถือได้เพื่อความปลอดภัยของแบรนด์ | ขอให้อัปเดต PA API เพื่อรวมเส้นทาง URL แบบเต็มของ
หน้าเว็บระดับบนสุด นอกเหนือจากชื่อโฮสต์ ในคำขอเรียกข้อมูลสำหรับ
trustedBiddingSignals กรณีการใช้งานหลักคือการเปิดใช้การควบคุมความปลอดภัยของแบรนด์ที่ละเอียดยิ่งขึ้น ผู้ลงโฆษณามักต้องการบล็อกไม่ให้โฆษณาปรากฏใน ส่วนที่เฉพาะเจาะจงของโดเมน (เช่น news-site.com/politics) ขณะที่ ยอมรับโดเมนโดยทั่วไป เนื่องจากรายการที่ถูกบล็อกเหล่านี้อาจมีความยาวหลายล้านรายการ จึงต้องประเมินที่ฝั่งเซิร์ฟเวอร์ ข้อกำหนดปัจจุบันซึ่งส่งเฉพาะชื่อโฮสต์ทำให้เซิร์ฟเวอร์ TrustedBiddingSignals ไม่สามารถ ทำการประเมินระดับเส้นทางที่จำเป็นนี้ได้ ซึ่งจำกัดความสามารถด้านความปลอดภัยของแบรนด์ |
ขณะนี้เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่
หลังจากที่ได้พูดคุยกันอย่างกว้างขวางก่อนหน้านี้ ซึ่งคุณสามารถดูได้ที่นี่
และเรายินดีรับฟังความคิดเห็นเพิ่มเติม อย่างไรก็ตาม เราขอชี้แจงว่าเราจะพิจารณาเพิ่มข้อมูลนี้ ก็ต่อเมื่อการดึงข้อมูล TrustedBiddingSignals ไปยังเซิร์ฟเวอร์ ที่ทำงานภายในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) |
การประมูลที่ได้รับการปกป้อง (บริการ B&A)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การทดสอบความพร้อม | ข้อมูลเกี่ยวกับความพร้อมใช้งานของ Key/Value (KV) v2 สำหรับ การทดสอบทั้งในสภาพแวดล้อม Chrome และ B&A | KV v2 พร้อมใช้งานทั้งใน B&A และ Chrome ดูคำแนะนำเพิ่มเติมได้ที่นี่ |
| การติดตั้งใช้งานเซิร์ฟเวอร์ KV | ขอคำชี้แจงเกี่ยวกับการใช้เซิร์ฟเวอร์ KV โดยเฉพาะ เกี่ยวกับการแมป URL การแสดงผลครีเอทีฟโฆษณากับข้อมูลคำขอ ความจำเป็นในการประสานงานระหว่าง SSP และ DSP เพื่อกำหนด พารามิเตอร์ใน URL การแสดงผล และความพร้อมใช้งานของเอกสาร ที่ระบุการประสานงานและการจัดเก็บข้อมูลที่จำเป็นในโหมด KV | บริการ KV ใช้ renderURL เป็นคีย์ หากเป็น URL ใหม่ ระบบจะ
จัดเก็บไว้ หากมีอยู่ ระบบจะแสดงค่าเพื่อใช้ใน scoreAd
รูปแบบการแสดงผลจะขึ้นอยู่กับการตั้งค่า: "นำเซิร์ฟเวอร์ของคุณเองมา" (BYOS)
อนุญาตให้ใช้ค่าใดก็ได้ ในขณะที่บริการ KV ที่เชื่อถือได้ต้องใช้
ฟังก์ชันที่ผู้ใช้กำหนด แม้ว่าจะไม่จำเป็นเสมอไป แต่การประสานงานกับ DSP ก็เป็นสิ่งสำคัญสำหรับ ฟีเจอร์ต่างๆ เช่น การแทนที่มาโคร (เช่น ${AD_WIDTH}) ใน renderURL ซึ่งช่วยให้ปรับแต่งและยืนยันโฆษณาแบบไดนามิกได้ เราขอแนะนำให้เริ่มด้วยการทดสอบง่ายๆ กับ DSP รายเดียวเพื่อพิจารณา ระดับการประสานงานที่จำเป็น นอกจากนี้ เรายังอยู่ระหว่าง อัปเดตเอกสารประกอบเกี่ยวกับ KV และจะแชร์ต่อสาธารณะเมื่อ พร้อมใช้งาน |
| BYOS สำหรับ B&A | เหตุใด B&A จึงไม่มีโหมด BYOS ที่คล้ายกับโหมด BYOS ของ KV | B&A ต้องใช้ TEE ซึ่งป้องกันรูปแบบ BYOS เนื่องจากจัดการ
ชุดข้อมูลที่มีความละเอียดอ่อนสูงซึ่งต้องมีการบังคับใช้
กลไกความเป็นส่วนตัวตามที่อธิบายไว้ด้านล่าง สำหรับ DSP: B&A ประมวลผลบริบทของผู้เผยแพร่โฆษณา (อาจเป็น URL แบบเต็มหาก ผู้ขายส่งอย่างชัดเจนผ่าน auctionSignals / perBuyerSignals) รวมกับข้อมูล IG ของผู้ใช้แบบละเอียด TEE มีความสำคัญอย่างยิ่งต่อการประมวลผลการผสมผสานนี้อย่างปลอดภัย และเพื่อป้องกันการระบุตัวตนของผู้ใช้ซ้ำที่อาจเกิดขึ้น ใน KV BYOS จะส่ง URL แบบเต็มไม่ได้ สำหรับ SSP: เพียงแค่ทราบชุดค่าผสมของ IG ที่เข้าร่วม (และเจ้าของ DSP ของ IG เหล่านั้น) ในการประมูลก็สามารถสร้างลายเซ็นที่ระบุตัวตนได้ ซึ่งเป็นจุดที่โซลูชันการรบกวน เข้ามามีบทบาท ซึ่งต้องใช้ TEE ดังนั้น การประมวลผลสัญญาณที่ละเอียดอ่อนที่รวมกันเหล่านี้อย่างปลอดภัย และการบังคับใช้กลไกความเป็นส่วนตัวจึงกำหนดให้ต้องมีสภาพแวดล้อมที่ควบคุมและรับรองของ TEE |
การวัดโฆษณาดิจิทัล
การรายงานการระบุแหล่งที่มา (และ API อื่นๆ)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| นโยบายเกี่ยวกับเสียง | การใช้ ARA มีประโยชน์สําหรับผู้เข้าร่วมตลาดบางราย และ Google ควรยังคงรักษาการรายงานระดับเหตุการณ์ต่อไป Google ควรพิจารณาผ่อนปรนนโยบายเสียงรบกวนใน สถานการณ์ที่มีทั้ง ARA และ 3PC ผู้ลงโฆษณาที่วัดประสิทธิภาพใช้ฟิลด์ "มูลค่า" ปัจจุบันมากขึ้น การติดตั้งใช้งานเหตุการณ์แบบยืดหยุ่นของ ARA และนโยบายเกี่ยวกับสัญญาณรบกวนที่เข้มงวดน้อยลง จะช่วยลดความล่าช้าและการรายงานที่ไม่ถูกต้อง | กลไกนี้เป็นส่วนพื้นฐานของการออกแบบ ARA ซึ่งมีจุดประสงค์เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้โดยการป้องกันการติดตามผู้ใช้แต่ละราย เรา กำลังพิจารณาความคิดเห็นเกี่ยวกับความท้าทายในการรายงาน ที่เกิดจากสัญญาณรบกวน ขณะที่เรายังคงประเมินบทบาทที่ Privacy Sandbox API จะมีต่อไป รวมถึงการปรับปรุงในอนาคตที่อาจเกิดขึ้น ตามประกาศของ Google ในเดือนเมษายน 2025 ว่าแนวทางปัจจุบันในการเสนอตัวเลือกคุกกี้ของบุคคลที่สามให้แก่ผู้ใช้ใน Chrome จะยังคงมีอยู่ |
| แผนกลยุทธ์และการสนับสนุนระยะยาว | ขอแผนงานผลิตภัณฑ์สำหรับ ARA รวมถึงการยืนยัน การลงทุนและการสนับสนุนระยะยาวเมื่อพิจารณาถึงประกาศที่จะไม่ ดำเนินการต่อในการเปิดตัวกลไกทางเลือกของผู้ใช้สำหรับ 3PC | ทีม Privacy Sandbox กำลังทำงานร่วมกับระบบนิเวศเพื่อทำความเข้าใจ บทบาทของ Privacy Sandbox API ในอนาคตและเพื่อ ประเมินการลงทุนในอนาคต |
| การวัดผลข้ามสภาพแวดล้อม (แอปไปยังเว็บ) | ขอโซลูชันที่เกี่ยวข้องกับการใช้ ARA เพื่ออำนวยความสะดวกในการวัดผล ข้ามสภาพแวดล้อม ซึ่งจะช่วยให้มีโฟลว์ข้อมูลที่สะอาดและเชื่อถือได้มากขึ้น และเพิ่มความสามารถในการเชื่อมต่อการโต้ตอบของผู้ใช้ใน แพลตฟอร์มต่างๆ | ARA รองรับการเปลี่ยนจากแอปไปยังเว็บในอุปกรณ์เดียวกันอยู่แล้ว ดูรายละเอียดเพิ่มเติมเกี่ยวกับโซลูชันการวัดผลข้ามแอปและเว็บได้ที่นี่ และที่นี่ |
| การระบุแหล่งที่มาข้ามเบราว์เซอร์ | แนวทาง ARA แบบรวมที่ใช้ได้กับทุกเบราว์เซอร์จะช่วยปรับปรุงความสามารถในการวัด ROI บนเว็บแบบเปิดได้อย่างมาก และเป็นทางเลือกที่เสถียรเมื่อมีการเปลี่ยนแปลงด้านกฎระเบียบที่อาจเกิดขึ้น Chrome ควร ทำงานร่วมกับทีม Safari เพื่อหาทางแก้ไขปัญหาในลักษณะนี้ | เรากำลังสำรวจ API ที่ทำงานร่วมกันได้กับผู้ให้บริการเบราว์เซอร์รายอื่นๆ ในกลุ่ม PATCG และ PATWG ภายใน W3C อยู่แล้ว โปรดทราบว่างานนี้เป็นเพียงขั้นต้น ผู้มีส่วนเกี่ยวข้องสามารถดูความคืบหน้าที่นี่ |
| การวัดผลข้ามอุปกรณ์/ออฟไลน์ | การไม่รองรับการวัด Conversion จากหลายอุปกรณ์ภายใน ARA ถือเป็นข้อจำกัดที่สำคัญ การวัด Conversion จากออนไลน์สู่ออฟไลน์ ก็มีความสําคัญอย่างยิ่งเช่นกัน และเบราว์เซอร์อาจมีบทบาทในการ ทํางานร่วมกับผู้ให้บริการวัดผล | เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| การระบุแหล่งที่มาแบบมัลติทัช | ขออนุญาตให้ผู้ลงโฆษณาใช้ข้อมูล Privacy Sandbox เป็น "ความจริงพื้นฐาน" ที่เป็นกลางเพื่อตรวจสอบและปรับเทียบรูปแบบการระบุแหล่งที่มาที่มีอยู่ ซึ่งทำได้โดยใช้ข้อมูลที่เบราว์เซอร์ของ ARA ให้ไว้เป็นสัญญาณการปรับเทียบที่เชื่อถือได้ เพื่อสร้าง พื้นฐานของความจริง | เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| การวัดการเข้าชมที่ไม่ได้ให้ความยินยอม/เลือกไม่ใช้ | โซลูชันการรักษาความเป็นส่วนตัว เช่น การระบุแหล่งที่มาแบบส่วนตัวที่ทำงานร่วมกันได้ จะช่วยให้วัดผลสําหรับการเข้าชมที่ไม่ได้รับความยินยอมได้ ซึ่งจะช่วยให้เข้าใจประสิทธิภาพของแคมเปญได้ครอบคลุมมากขึ้นโดยรวมข้อมูลจากผู้ใช้ที่เลือกไม่ใช้การติดตาม ซึ่งจะช่วยเติมเต็มช่องว่างที่สำคัญในการวัดผลที่เกิดจากข้อกำหนดด้านความยินยอม | เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| การระบุแหล่งที่มาแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ | ขออนุญาตให้เทคโนโลยีโฆษณาที่มีโครงสร้างพื้นฐานฝั่งเซิร์ฟเวอร์ที่ซับซ้อนผสานรวมกับ ARA ได้อย่างยืดหยุ่นมากขึ้น รองรับกรณีการใช้งานที่จัดการได้ยากในฝั่งไคลเอ็นต์เพียงอย่างเดียว ขณะเดียวกันก็ยังคงรักษาความเป็นส่วนตัวของผู้ใช้ | เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
| การลงทะเบียนหลายโดเมน | ขอคำชี้แจงเกี่ยวกับข้อจำกัดและข้อควรระวังเมื่อลงทะเบียนโดเมนหลายโดเมนกับ ARA โดยเฉพาะอย่างยิ่งเกี่ยวกับบริการรวบรวมข้อมูลและแอตทริบิวต์แบบข้ามต้นทาง | ข้อจำกัดที่สำคัญเมื่อใช้ ARA กับหลายโดเมนมีดังนี้
• การระบุแหล่งที่มาจะกำหนดขอบเขตไว้ที่ต้นทางเดียว คุณ จับคู่การคลิกจากโดเมนหนึ่งกับ Conversion ใน อีกโดเมนหนึ่งไม่ได้ การระบุแหล่งที่มาจะอยู่ในแซนด์บ็อกซ์ของต้นทางเดียวกันทั้งสำหรับ แหล่งที่มาและทริกเกอร์ • บริการรวมข้อมูลไม่รองรับการจัดกลุ่มหลายต้นทาง รายงานจากแหล่งที่มาต่างๆ ต้องได้รับการจัดกลุ่มและ ประมวลผลแยกกัน เรากำลังหาวิธีที่จะรองรับการใช้งานนี้ในอนาคต กล่าวโดยย่อคือ แม้ว่าจะลงทะเบียนหลายโดเมนภายใต้นิติบุคคลเดียวได้ แต่ปัจจุบันฟังก์ชัน ARA ทั้งหมด เช่น การระบุแหล่งที่มาและการรวบรวม จะต้อง จัดการตามต้นทาง |
บริการรวมข้อมูล
ไม่ได้รับความคิดเห็นในไตรมาสนี้
Private Aggregation API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ขีดจำกัดและระดับเสียงรบกวน | ข้อกังวลเกี่ยวกับข้อจำกัดของขนาดคีย์การรวบรวมและ ค่าการรวบรวมภายใน Private Aggregation API | ระบบเลือกขนาดคีย์และค่าการรวมเพื่อให้มีความละเอียดสูง
พร้อมทั้งจำกัดค่าใช้จ่ายด้านเครือข่ายและพื้นที่เก็บข้อมูล นอกจากนี้ เราขอแนะนำให้ใช้การแฮช
เมื่อกำหนดคีย์เพื่อเพิ่มความยืดหยุ่นสูงสุด แม้จะมีปัจจัยอื่นๆ ที่ปกป้องข้อมูลผู้ใช้ แต่การเพิ่มสัญญาณรบกวนก็เป็น ส่วนสำคัญของการคุ้มครองความเป็นส่วนตัวของ Private Aggregation API เราจะนำความคิดเห็นมาพิจารณาและจะประเมินตัวเลือกพารามิเตอร์ที่เหมาะสมต่อไป ควบคู่ไปกับการพิจารณาบทบาทที่ Privacy Sandbox API จะมีในอนาคต ตามประกาศของ Google ในเดือนเมษายน 2025 ว่าเราจะยังคงใช้วิธีการปัจจุบันในการให้ตัวเลือกแก่ผู้ใช้ เกี่ยวกับคุกกี้ของบุคคลที่สามใน Chrome ต่อไป |
| ความเป็นส่วนตัวเทียบกับประโยชน์ใช้สอย | แนวทางของ Privacy Sandbox อาจให้ความสำคัญกับความเป็นส่วนตัวมากกว่ายูทิลิตี ซึ่งอาจขัดขวางการนำไปใช้ คำแนะนำในการอนุญาตการแชร์ข้อมูลแบบละเอียดยิ่งขึ้น โดยได้รับความยินยอมจากผู้ใช้เพื่อปรับปรุงการวัดผลและการ ปรับโฆษณาตามโปรไฟล์ของผู้ใช้ | ระบบเลือกขนาดคีย์และค่าการรวมเพื่อให้มีความละเอียดสูง
พร้อมทั้งจำกัดค่าใช้จ่ายด้านเครือข่ายและพื้นที่เก็บข้อมูล นอกจากนี้ เราขอแนะนำให้ใช้การแฮช
เมื่อกำหนดคีย์เพื่อเพิ่มความยืดหยุ่นสูงสุด เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมิน บทบาทของ Privacy Sandbox API ในอนาคต โดยพิจารณาจาก ประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ให้แก่ผู้ใช้ใน Chrome จะยังคงมีอยู่ |
จำกัดการติดตามแอบแฝง
การลด User Agent/คำแนะนำสำหรับไคลเอ็นต์ User Agent
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การตรวจจับสแปม | หากคำขอแรกจากเว็บไซต์ที่ใช้ระบบตรวจจับสแปมอาศัยคำแนะนำไคลเอ็นต์ ระบบติดตามหรือตรวจจับอาจระบุหรือจัดหมวดหมู่คำขออย่างถูกต้องไม่ได้ | Use Case ที่ต้องอาศัยการเข้าถึงคำแนะนำสำหรับไคลเอ็นต์ของ User Agent (UA-CH) ในคำขอแรกควรใช้คำแนะนำสำหรับไคลเอ็นต์ที่สำคัญ |
| ความคิดเห็นเกี่ยวกับ API | โปรดพิจารณาเลิกใช้งาน Sec-CH-USA-Wow64 เนื่องจากไม่เกี่ยวข้องกับ เว็บสมัยใหม่อีกต่อไป | เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่ นอกจากนี้ เรายังได้รับ ความคิดเห็นว่าการขยาย wow64 ให้ครอบคลุมระบบปฏิบัติการอื่นนอกเหนือจาก Windows จะเป็นประโยชน์ |
การปกป้อง IP (เดิมชื่อ Gnatcatcher)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การควบคุม | ขอเปิด/ปิดการป้องกัน IP สำหรับเว็บไซต์เพื่อใช้แบบเลือกนอกโหมดไม่ระบุตัวตน | ขอขอบคุณสำหรับความคิดเห็น และเรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้ที่นี่ |
| การประพฤติมิชอบ | โทเค็นการเปิดเผยเชิงสถิติ (PRT) ที่ส่งผลให้มีค่าเป็น NULL จะป้องกันการระบุตัวผู้กระทำผิดเมื่อตำรวจขอเปิดเผยที่อยู่ IP สำหรับการประพฤติมิชอบบนแพลตฟอร์มได้หรือไม่ | หากใช้โดเมนเพื่อการตรวจหาการฉ้อโกงและการละเมิดโดยเฉพาะ โดเมนนั้นอาจไม่ได้รวมอยู่ในรายการโดเมนที่มาสก์ (MDL) และจึงไม่ได้รับผลกระทบจากการปกป้อง IP ดังนั้นจึงไม่จำเป็นต้องใช้ PRT สำหรับโดเมนเหล่านั้น
หากมีโดเมนรวมอยู่ใน MDL ปัจจุบัน PRT เป็นวิธีเดียว ในการทราบที่อยู่ IP เดิมสำหรับคำขอที่ผ่านพร็อกซี เนื่องจาก PRT ออกแบบมาเพื่อรองรับการวิเคราะห์แบบรวมโดยเฉพาะ ไม่ใช่การระบุตัวบุคคล แต่ละราย จึงเป็นความจริงที่ PRT จะไม่มีที่อยู่ IP ในกรณีส่วนใหญ่ เราคาดว่าการเปลี่ยนแปลงนี้จะมีผลกระทบจำกัดในสถานการณ์ที่อธิบายไว้ เนื่องจากความคุ้มครอง IP จะมีผลเฉพาะในบริบทของบุคคลที่สาม ซึ่งหมายความว่าผู้เผยแพร่โฆษณาจะยังคงได้รับที่อยู่ IP ที่ไม่ได้ผ่านพร็อกซีสำหรับการโต้ตอบของบุคคลที่หนึ่ง เช่น ผู้ใช้เข้าชมเว็บไซต์ของแพลตฟอร์มออนไลน์ |
| ป้องกันการฉ้อโกง | มาตรการป้องกันการประพฤติมิชอบของ Google สำหรับการป้องกัน IP มีรายละเอียดอะไรบ้าง รวมถึงรายละเอียดเกี่ยวกับการจำกัดอัตราการเข้าถึงพร็อกซีและการออกโทเค็นการตรวจสอบสิทธิ์ และกรณีการใช้งานเฉพาะสำหรับ PRT คืออะไร | เรายืนยันว่าโทเค็นการจำกัดอัตราและการตรวจสอบสิทธิ์ใน IP Protection ออกแบบมาเพื่อป้องกันไม่ให้บ็อตทำการฉ้อโกงโฆษณาโดย การเข้าถึงพร็อกซีมากเกินไป ตามที่ระบุไว้ในกลยุทธ์การป้องกันการฉ้อโกงและการป้องกันสแปม กรณีการใช้งานอื่นๆ ของ PRT มีระบุไว้ในเอกสารประกอบคำอธิบาย PRT ที่นี่ |
| โหมดไม่ระบุตัวตน | ยังคงมีแผนที่จะเปิดตัวการปกป้อง IP ในโหมดไม่ระบุตัวตนในไตรมาสที่ 3 ไหม | ปัจจุบันยังไม่มีการเปลี่ยนแปลงไทม์ไลน์ในไตรมาสที่ 3 สำหรับการเปิดตัวการปกป้อง IP ในโหมดไม่ระบุตัวตน |
การลดการติดตามการเข้าออก
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ความคิดเห็นเกี่ยวกับ API | Chrome ควรบล็อกการเข้าถึงคุกกี้/พื้นที่เก็บข้อมูลแทนการแบ่งพาร์ติชันเมื่อใช้การลดการติดตามการตีกลับ (BTM) โดยอ้างถึงลักษณะการทำงานที่ไม่คาดคิดและความสับสนจากวิธีการ "การแบ่งพาร์ติชัน" ของ Safari | เรายินดีรับฟังคำแนะนำนี้ ปัจจุบัน BTM ไม่เกี่ยวข้องกับการแบ่งพาร์ติชันคุกกี้/พื้นที่เก็บข้อมูล แต่จะลบออกหลังจากระยะเวลาผ่อนผันแทน หากมีการออกแบบ BTM ในภายหลังที่เกี่ยวข้องกับการดำเนินการกับคุกกี้ในทันที เราตั้งใจที่จะเลือกบล็อกคุกกี้มากกว่าการแบ่งพาร์ติชัน |
เพิ่มความเข้มงวดให้ขอบเขตความเป็นส่วนตัวข้ามเว็บไซต์
ชุดเว็บไซต์ที่เกี่ยวข้อง (เดิมคือชุดโดเมนของบุคคลที่หนึ่ง)
ไม่ได้รับความคิดเห็นในไตรมาสนี้
Fenced Frames API
ไม่ได้รับความคิดเห็นในไตรมาสนี้
Shared Storage API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| คำขอฟีเจอร์ API | คำขอต่อท้ายการดูและการคลิกโฆษณาในพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน | เราจะนำความคิดเห็นนี้มาพิจารณาขณะประเมินบทบาทของ Privacy Sandbox API ในอนาคต โดยคำนึงถึงประกาศของ Google ในเดือนเมษายน 2025 ที่ระบุว่าแนวทางปัจจุบันในการเสนอทางเลือกเกี่ยวกับ 3PC ใน Chrome ให้แก่ผู้ใช้จะยังคงมีอยู่ต่อไป |
CHIPS
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| คำถามเกี่ยวกับ API | ขอคำชี้แจงเกี่ยวกับวิธีที่ตัวควบคุม 3PC ของ Chrome ทำงานร่วมกับ CHIPS โดยเฉพาะอย่างยิ่งว่าระบบจะแปลงคุกกี้ที่ไม่ได้แบ่งพาร์ติชันเป็นคุกกี้ที่แบ่งพาร์ติชัน เมื่อปิดใช้ 3PC หรือไม่ และคุกกี้ที่แบ่งพาร์ติชันจะยังคง ใช้งานได้หรือไม่ | ระบบจะไม่จัดเก็บ เรียก หรือส่งคุกกี้ที่ไม่ได้พาร์ทิชันในบริบทของบุคคลที่สามเมื่อปิดใช้ 3PC อย่างไรก็ตาม ระบบจะจัดเก็บ เรียกข้อมูล และส่งคุกกี้ที่แบ่งพาร์ติชันต่อไปในบริบทของบุคคลที่สาม เนื่องจากฟังก์ชันการทำงานของคุกกี้ดังกล่าวไม่ได้รับผลกระทบจากการตั้งค่าเบราว์เซอร์ที่ปิดใช้ 3PC |
| ข้อกังวลเรื่องความเป็นส่วนตัว | กังวลว่าบุคคลที่สามที่ฝังตัวซึ่งมีตัวระบุแบบถาวร เช่น สำหรับการลงชื่อเพียงครั้งเดียว อาจยังคงอนุญาตให้ทั้งฝ่ายที่ฝังและฝ่ายที่ถูกฝัง ได้รับตัวระบุแบบดิจิทัลส่วนกลาง แม้จะมีคุกกี้ที่แบ่งพาร์ติชันแล้วก็ตาม | แม้ว่าบุคคลที่สามที่ฝังอาจมีตัวระบุแบบถาวร แต่ตัวระบุดังกล่าวจะเข้าถึงได้เฉพาะในเว็บไซต์ที่ฝังตั้งค่าคุกกี้ไว้เท่านั้นเมื่อจัดเก็บไว้ในคุกกี้ที่แบ่งพาร์ติชัน การรวมตัวระบุนี้ข้ามเว็บไซต์ จะต้องมีการดำเนินการเข้าสู่ระบบ ซึ่งอนุญาตให้ แลกเปลี่ยนตัวระบุในรูปแบบของโทเค็นการตรวจสอบสิทธิ์ ได้อยู่แล้ว แม้ว่าจะไม่ได้ใช้คุกกี้ที่แบ่งพาร์ติชันก็ตาม |
FedCM
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การใช้ API | สื่อกลางแบบเงียบไม่ทำงานสำหรับผู้ใช้ที่มีหลายบัญชีโดยไม่มีข้อผิดพลาดที่เฉพาะเจาะจง | ลักษณะการทำงานของการไกล่เกลี่ยแบบเงียบเป็นฟีเจอร์ที่ออกแบบมาโดยเฉพาะ เนื่องจากมีไว้สำหรับกรณีที่เฉพาะเจาะจงมากซึ่งมีบัญชีที่พร้อมใช้งานเพียงบัญชีเดียว เราขอแนะนำให้ใช้สื่อกลาง "ไม่บังคับ" แทน ซึ่ง FedCM จะกลับไปแสดงตัวเลือกบัญชีแก่ผู้ใช้หากใช้สื่อกลางแบบเงียบไม่ได้ |
| การใช้ API | navigator.credentials.get จะแสดงข้อผิดพลาดทั่วไป
ซึ่งป้องกันการบันทึกเหตุผลที่เฉพาะเจาะจงในการปฏิเสธ เช่น การปฏิเสธผู้ใช้
หรือระยะเวลาคูลดาวน์ |
การที่นักพัฒนาซอฟต์แวร์ไม่สามารถแยกแยะระหว่างผู้ใช้ ปิดกล่องโต้ตอบ FedCM กับข้อผิดพลาดเกี่ยวกับเครือข่าย กับการที่ FedCM อยู่ใน "ระยะเวลาคูลดาวน์" เนื่องจากผู้ใช้เคยปิดกล่องโต้ตอบ ก่อนหน้านี้ก็เป็นฟีเจอร์ที่ออกแบบมาเพื่อรักษาความเป็นส่วนตัวของผู้ใช้ ข้อกังวลคือความสามารถดังกล่าวจะทำให้เว็บไซต์ อนุมานสถานะการเข้าสู่ระบบของผู้ใช้ในผู้ให้บริการข้อมูลประจำตัว (IdP) ต่างๆ ได้ |
| ลงชื่อเข้าใช้ | พบว่าการเลือกบัญชีที่ลงชื่อเข้าใช้หลายบัญชีมีลักษณะการทำงานที่ไม่สอดคล้องกัน | เราไม่แน่ใจว่าการเลือกบัญชีที่เฉพาะเจาะจงไม่ได้เป็นระยะๆ ในสถานการณ์ที่มีการลงชื่อเข้าใช้หลายบัญชีเป็นข้อบกพร่องที่เกิดขึ้นเป็นระยะๆ ใน FedCM หรือเป็นปัญหาบางอย่างที่เกี่ยวข้องกับระบบการทดสอบ เรากำลัง ทำงานร่วมกับผู้รายงานเพื่อแก้ไขปัญหานี้ และได้ขอ รายละเอียดเพิ่มเติมเพื่อทำความเข้าใจปัญหาได้ดียิ่งขึ้น |
| การใช้ API | หากผู้ใช้ปิดกล่องโต้ตอบขณะให้สิทธิ์ด้วย FedCM ระบบจะไม่รายงานว่าผู้ใช้อยู่ในสถานะช่วงพักผ่านข้อผิดพลาดที่จับได้ | ใช่ กรณีนี้จะเกิดขึ้นและจะทำให้เกิดรหัสข้อผิดพลาดทั่วไป เพื่อรักษาความเป็นส่วนตัวของผู้ใช้ |
| การใช้ API | เหตุใด FedCM จึงเข้าสู่ช่วงหยุดทำงาน 10 นาทีหลังจาก "การตรวจสอบสิทธิ์อีกครั้งโดยอัตโนมัติ" สำเร็จ | เนื่องจากการตรวจสอบสิทธิ์อีกครั้งโดยอัตโนมัติเกิดขึ้นโดยที่ผู้ใช้ไม่ได้เป็นผู้เริ่มดำเนินการ หากผู้ใช้ต้องการกลับไปที่เว็บไซต์แต่ลงชื่อเข้าใช้ด้วยบัญชีอื่น ผู้ใช้จะต้องรอระยะเวลาหนึ่งที่ FedCM ไม่ได้ตรวจสอบสิทธิ์อีกครั้งโดยอัตโนมัติ "ระยะเวลาที่ไม่มีการแจ้งเตือน" จะเป็น โอกาสให้ผู้ใช้ลงชื่อเข้าใช้ด้วยตนเองโดยใช้บัญชีอื่น บล็อกโพสต์นี้มีรายละเอียดเพิ่มเติมเกี่ยวกับ "ช่วงเวลาที่เงียบ" นี้ |
| FedCM แบบเบา | กังวลว่าข้อเสนอ FedCM แบบ Lightweight จะเพิ่มความซับซ้อนให้กับ IdP เนื่องจากต้องรองรับการใช้งาน 2 แบบที่เข้ากันไม่ได้ (FedCM กับ FedCM แบบ Lightweight) | FedCM แบบเบาเข้ากันได้กับ FedCM แบบเดิม IdP สามารถ
เลือกวิธีการติดตั้งใช้งานที่จะใช้ และไม่จำเป็นต้อง
รองรับทั้ง 2 วิธี FedCM แบบเบาเป็นกลไกการพุชสำหรับ FedCM หาก IdP เลือกใช้ฟีเจอร์นี้ IdP จะส่งข้อมูลบัญชีไปยังเบราว์เซอร์ได้เมื่อผู้ใช้เข้าสู่ระบบ เพื่อให้เมื่อฝ่ายที่ต้องอาศัยข้อมูล (RP) เรียกใช้ FedCM ระบบจะดึงข้อมูลบัญชีจากเบราว์เซอร์แทนที่จะดึงจากปลายทางบัญชีของ IdP |
| FedCM แบบเบา | ข้อกังวลเกี่ยวกับการเปิดเผยข้อมูลส่วนตัวของผู้ใช้ เช่น ชื่อ อีเมล และรูปโปรไฟล์ ให้กับ RP ในข้อเสนอ Lightweight FedCM | เราได้อัปเดตข้อเสนอ สำหรับ FedCM แบบเบาตั้งแต่ได้รับความคิดเห็นนี้ เพื่อนำชื่อ อีเมล และรูปโปรไฟล์ออกจาก การตอบกลับของเมธอด |
| FedCM แบบเบา | การจัดการบัญชีที่ลงชื่อเข้าใช้หลายบัญชีดูเหมือนจะเข้มงวดเกินไปใน ข้อเสนอ FedCM แบบเบา ขณะนี้ข้อเสนอไม่รองรับ อายุเซสชันแต่ละรายการหรือสถานะการเข้าสู่ระบบที่ซับซ้อนต่อบัญชี | ปัจจุบันการหมดอายุจะเชื่อมโยงกับ IdP ภายในออบเจ็กต์ข้อมูลเข้าสู่ระบบ เราได้บันทึกการหมดอายุต่อบัญชีเป็นคำถามที่ยังไม่ได้รับคำตอบ และจะนำความคิดเห็นนี้ไปพิจารณาในการพัฒนาในอนาคต |
| FedCM แบบเบา | ความแตกต่างระหว่าง "ลงชื่อเข้าใช้" กับ "พร้อมให้เลือก" ไม่ได้กำหนดไว้อย่างชัดเจน ซึ่งอาจส่งผลต่อประสบการณ์ของผู้ใช้สำหรับข้อเสนอ FedCM แบบ Lightweight | ปัจจุบันเราไม่รองรับความสามารถในการแยกแยะว่าบัญชี
เข้าสู่ระบบหรือออกจากระบบในอินเทอร์เฟซผู้ใช้ (UI) ของ FedCM ไม่ควรแสดงบัญชีที่ออกจากระบบแล้ว หากระบบออกจากบัญชีและแสดงบัญชีนั้นไว้ และผู้ใช้เลือกบัญชีที่ไม่ได้เข้าสู่ระบบ อย่างต่อเนื่อง คุณจะใช้ Continuation API เพื่อให้ผู้ใช้เข้าสู่ระบบอีกครั้งได้ |
| การใช้ API | ความไม่สอดคล้องกันระหว่างฟิลด์ given_name ใน
getUserInfo กับการใช้งานใน UI ของ FedCM |
เราได้พูดคุยเรื่องนี้กับ Mozilla เพิ่มเติมที่นี่ เพื่อให้ทราบวิธีจัดการกับ given_name ใน getUserInfo |
| การใช้ API | ฟิลด์บางรายการที่ใช้ใน UI จาก
IdentityProviderAccount ไม่ได้ระบุไว้ใน
getUserInfo โดยเฉพาะ tel และ
username ซึ่งแสดงให้เห็นว่าจำเป็นต้องมีการซิงค์ |
การพูดคุย
กับ Mozilla และสมาชิกคนอื่นๆ ใน FedID Community Group กำลังคืบหน้า
ในประเด็นการประมวลผลฟิลด์จาก
IdentityProviderAccount ที่ส่งไปยัง
getUserInfo. |
| FedCM สำหรับองค์กร | ขอรับการสนับสนุน FedCM สำหรับ Use Case ของ IdP สำหรับองค์กร | ประเด็นสำคัญคือความจำเป็นในการมีกลไกที่เชื่อถือได้สำหรับ IdP เพื่อส่งสัญญาณไปยังเบราว์เซอร์ว่าผู้ดูแลระบบได้ให้ความยินยอมล่วงหน้าในการอนุญาต ให้ผู้ใช้เข้าถึง RP ที่เฉพาะเจาะจงซึ่งเครื่องมือติดตามเว็บไม่สามารถเลียนแบบและ/หรือละเมิดได้ เรื่องนี้มีการพูดคุยในการประชุม FedID CG เมื่อวันที่ 22 เมษายน (โปรดดูหมายเหตุ ของการประชุมที่นี่) และมีการเสนอส่วนขยายเบราว์เซอร์และนโยบายขององค์กร (สำหรับอุปกรณ์ที่มีการจัดการ) เป็นโซลูชันที่เป็นไปได้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้ที่นี่ |
ต่อสู้กับสแปมและการประพฤติมิชอบ
Private State Token API (และ API อื่นๆ)
ไม่ได้รับความคิดเห็นในไตรมาสนี้