ข้อเสนอ Attribution Reporting มีการเปลี่ยนแปลงหลายอย่างเพื่อตอบสนองความคิดเห็นของชุมชน ตั้งแต่การเปลี่ยนแปลงกลไก API ไปจนถึงฟังก์ชันการทำงานใหม่
บันทึกการเปลี่ยนแปลง
- 7 กุมภาพันธ์ 2022: เพิ่มส่วนการเปลี่ยนเส้นทางส่วนหัว
- 27 มกราคม 2022: เผยแพร่บทความเป็นครั้งแรก
โพสต์นี้มีไว้สำหรับใคร
โพสต์นี้มีไว้สำหรับคุณ
- หากคุณเข้าใจ API ดีแล้ว เช่น คุณได้สังเกตหรือเข้าร่วมการอภิปรายเกี่ยวกับที่เก็บ WICG และต้องการทำความเข้าใจการเปลี่ยนแปลงที่เกิดขึ้นกับข้อเสนอในเดือนมกราคม 2022
- หากคุณใช้ Attribution Reporting API ในเดโมหรือในการทดสอบเวอร์ชันที่ใช้งานจริง
หากคุณเพิ่งเริ่มใช้ API นี้และ/หรือยังไม่ได้ทดลองใช้ โปรดไปที่ข้อมูลเบื้องต้นเกี่ยวกับ API โดยตรงแทน
การย้ายข้อมูลข้างหน้า
เมื่อมีการนำการเปลี่ยนแปลงเหล่านี้ไปใช้ใน Chrome หากใช้รายงานระดับเหตุการณ์จาก Attribution Reporting API ในเดโมหรือในการทดสอบในเวอร์ชันที่ใช้งานจริง (ช่วงทดลองใช้จากต้นทาง) คุณจะต้องแก้ไขโค้ดเพื่อให้ API ทำงานต่อไปได้ และอาจพิจารณาใช้ฟีเจอร์ใหม่เหล่านี้ด้วย
บทความนี้จะแสดงการเปลี่ยนแปลงสำหรับรายงานที่รวบรวมได้ อย่างไรก็ตาม หากนำการเปลี่ยนแปลงเหล่านี้ไปใช้ ก็ไม่จำเป็นต้องดำเนินการใดๆ หรือย้ายข้อมูล เนื่องจากยังไม่มีการใช้งานเบราว์เซอร์สำหรับรายงานที่รวบรวมได้ในขณะที่เขียนบทความนี้
การเปลี่ยนชื่อ
รายงานสรุปและรายงานที่รวบรวมได้
สิ่งที่คุณเคยได้ยินในฐานะรายงานสรุปจะเรียกว่ารายงานสรุป
รายงานสรุปคือผลลัพธ์สุดท้ายจากการรวมรายงานที่รวบรวมได้หลายรายการ ซึ่งก่อนหน้านี้เรียกว่าการมีส่วนร่วมหรือการมีส่วนร่วมในฮิสโตแกรม
การเปลี่ยนแปลงกลไก API
การลงทะเบียนแหล่งที่มาที่อิงตามส่วนหัว (รายงานระดับเหตุการณ์)
สิ่งที่เปลี่ยนแปลงและสาเหตุ
เมื่อผู้ใช้ดูหรือคลิกโฆษณา เบราว์เซอร์จะบันทึกเหตุการณ์นี้ในเครื่องของผู้ใช้พร้อมกับพารามิเตอร์ที่ใช้กับการรายงานการระบุแหล่งที่มาโดยเฉพาะ (เช่น attributionsourceeventid, attributiondestination, attributionexpiry และพารามิเตอร์อื่นๆ) AdTech เป็นผู้กำหนดค่าของพารามิเตอร์เหล่านี้
วิธีการตั้งค่าพารามิเตอร์เหล่านี้กำลังมีการเปลี่ยนแปลง
ในข้อเสนอก่อนหน้า จะต้องรวมพารามิเตอร์ไว้ฝั่งไคลเอ็นต์ ไม่ว่าจะในแท็ก Anchor เป็นแอตทริบิวต์ HTML หรือเป็นอาร์กิวเมนต์ของการเรียกใช้แบบ JS ต้องทราบพารามิเตอร์เมื่อคลิกหรือเวลาในการดู
ในข้อเสนอใหม่ ระบบจะกำหนดค่าของพารามิเตอร์เหล่านี้ไว้ในเซิร์ฟเวอร์ AdTech แทน
การทำงานในลักษณะนี้มีข้อดีข้อเสียหลายอย่าง โดยเฉพาะในเรื่องความปลอดภัย นั่นก็คือกลไกของส่วนหัวให้ที่มาของการรายงาน ซึ่งโดยปกติแล้วจะเป็น AdTech ควบคุมโดยตรงว่าแหล่งที่มาของการระบุแหล่งที่มาจะได้รับการลงทะเบียนในขอบเขตของตนหรือไม่ วิธีนี้ช่วยลดข้อกังวลเกี่ยวกับการทุจริตได้บางส่วน เนื่องจากการเปลี่ยนแปลงนี้ เบราว์เซอร์จริงจะไม่ลงทะเบียนแหล่งที่มาหากไม่ได้เลือกใช้แหล่งที่มาของการรายงาน
การลงทะเบียนแหล่งที่มาทำงานอย่างไร
- สำหรับโฆษณาหนึ่งๆ ทาง AdTech จะต้องกำหนดแอตทริบิวต์ฝั่งไคลเอ็นต์ที่เฉพาะเจาะจง
attributionsrcค่าของแอตทริบิวต์นี้คือ URL ที่เบราว์เซอร์จะส่งคำขอ โดยคำขอนี้จะมีส่วนหัว HTTP ใหม่Attribution-Reporting-Source-Infoที่มีค่าnavigationหรือevent,ระบุว่าแหล่งที่มาเป็นการคลิกหรือข้อมูลพร็อพเพอร์ตี้ตามลำดับ - เมื่อได้รับคำขอนี้ เซิร์ฟเวอร์การติดตามการคลิก/การดูควรตอบกลับด้วยส่วนหัว HTTP
Attribution-Reporting-Register-Sourceซึ่งมีพารามิเตอร์การระบุแหล่งที่มาที่ต้องการ ต้นทางที่แสดงผลส่วนหัวนี้จะกลายเป็นต้นทางการรายงาน (เดิมกำหนดเป็น
attributionreportto)ส่วนหัวการตอบกลับ HTTP
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค
การลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา
เข้าร่วมการสนทนาสาธารณะ
ทริกเกอร์การระบุแหล่งที่มาที่อิงตามส่วนหัว (รายงานระดับเหตุการณ์)
สิ่งที่เปลี่ยนแปลงและสาเหตุ
ข้อเสนอใหม่จะเปลี่ยนทริกเกอร์การระบุแหล่งที่มา (เมื่อ AdTech สั่งให้เบราว์เซอร์บันทึก Conversion) เป็นวิธีที่อิงตามส่วนหัว เช่นเดียวกับการลงทะเบียนการคลิกหรือการดู
กลไกนี้สอดคล้องกับการลงทะเบียนแหล่งที่มาที่อิงตามส่วนหัวและเป็นแบบปกติมากกว่ากลไกการเปลี่ยนเส้นทางที่ใช้ก่อนหน้านี้
นอกจากนี้ ในข้อเสนอใหม่ยังจำเป็นต้องมีแอตทริบิวต์ attributionsrc ในหน้า Conversion ด้วย
เหตุผลคือเรื่องของสิทธิ์ ในข้อเสนอก่อนหน้า เว็บไซต์ฝั่งทริกเกอร์ (โดยทั่วไปคือเว็บไซต์ของผู้ลงโฆษณา) สามารถควบคุมฟีเจอร์นี้ผ่านส่วนหัว Permissions-Policy ได้ แต่ไม่ได้ควบคุมแบบละเอียดในระดับองค์ประกอบว่าองค์ประกอบจะส่งคำขอไปยังฝ่ายใดฝ่ายหนึ่งที่จะทริกเกอร์การระบุแหล่งที่มาในท้ายที่สุดได้หรือไม่ attributionsrc จะเปลี่ยนแปลงสิ่งนี้: เครื่องหมายที่จำเป็นนี้ช่วยให้ผู้ลงโฆษณาตรวจสอบและควบคุมองค์ประกอบที่จะทำให้เกิดการระบุแหล่งที่มาได้
โปรดทราบว่าในด้านแหล่งที่มา (โดยทั่วไปจะเป็นเว็บไซต์ของผู้เผยแพร่โฆษณา) จะมีตัวควบคุมแบบทั้งหน้าผ่าน Permissions-Policy และตัวควบคุมแบบทั้งองค์ประกอบผ่าน attributionsrc แสดงอยู่
ทริกเกอร์การระบุแหล่งที่มาทำงานอย่างไร
เมื่อได้รับคำขอพิกเซลและตัดสินใจว่าควรจัดหมวดหมู่คำขอเป็น Conversion แล้ว AdTech ควรตอบกลับด้วยส่วนหัว HTTP
ใหม่ Attribution-Reporting-Register-Event-Trigger
ค่าของส่วนหัวนี้ระบุวิธีจัดการกับเหตุการณ์ทริกเกอร์ในฐานะออบเจ็กต์ JSON นี่เป็นข้อมูลเดียวกับที่กำหนดไว้เป็นพารามิเตอร์การค้นหาในข้อเสนอก่อนหน้า
ส่วนหัวการตอบกลับ HTTP Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
การเปลี่ยนเส้นทาง (ไม่บังคับ)
(ไม่บังคับ) เซิร์ฟเวอร์ adtech จะกำหนดให้การตอบกลับที่มี Attribution-Reporting-Register-Event-Trigger เป็นการตอบกลับการเปลี่ยนเส้นทางได้
วิธีนี้ช่วยให้บุคคลที่สามสังเกตเหตุการณ์ Conversion ได้และสั่งให้เบราว์เซอร์ระบุแหล่งที่มาของเหตุการณ์ดังกล่าวได้
คุณจะเปลี่ยนเส้นทางหรือไม่ก็ได้ แต่ไม่จำเป็นต้องมีเมื่อทั้ง AdTech และบุคคลที่สามมีพิกเซลในหน้า
ดูรายละเอียดเพิ่มเติมในการรายงานบุคคลที่สาม
ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค
เข้าร่วมการสนทนาสาธารณะ
ไม่มี Worklet (รายงานที่รวบรวมได้)
สิ่งที่เปลี่ยนแปลงและสาเหตุ
ในข้อเสนอก่อนหน้าเกี่ยวกับรายงานที่รวบรวมได้ จะต้องมีการเข้าถึง JavaScript เพื่อเรียกใช้เวิร์กเล็ต ซึ่งเป็นกลไกที่ใช้ JavaScript ในการสร้างรายงานเหล่านี้
ในข้อเสนอใหม่ ไม่จำเป็นต้องใช้ Worklet แต่ AdTech จะกำหนดกฎแบบประกาศผ่านส่วนหัว HTTP แทน ซึ่งเป็นกฎที่เบราว์เซอร์ควรใช้เพื่อสร้างรายงานที่รวบรวมได้
ข้อเสนอใหม่มีประโยชน์หลายประการดังนี้
- การใช้งานเบราว์เซอร์: การออกแบบใหม่จะต่างจากการออกแบบ Worklet นั้นง่ายขึ้นมากเนื่องจากไม่ต้องใช้สภาพแวดล้อมการดำเนินการใหม่ในเบราว์เซอร์
- ประสบการณ์ของนักพัฒนาซอฟต์แวร์: การออกแบบใหม่อาศัยส่วนหัวที่นักพัฒนาแอปใช้กันโดยทั่วไปและรู้จักกันอย่างกว้างขวาง ไม่เหมือนเวิร์กเล็ต และยังสอดคล้องกับแพลตฟอร์ม API สำหรับการลงทะเบียนแหล่งที่มาอย่างใกล้ชิด ทำให้เรียนรู้และใช้งาน API ได้ง่ายขึ้น
- การนำไปใช้: การออกแบบใหม่ช่วยให้ระบบการวัดที่มีอยู่ใช้รายงานที่รวบรวมได้ โซลูชันการวัดผลจำนวนมากเป็นแบบ HTTP เท่านั้น โดยต้องใช้คำขอรูปภาพหรือคำขอพิกเซลที่ไม่จำเป็นต้องเข้าถึง JavaScript แต่เนื่องจากวิธี Worklet จำเป็นต้องใช้การเข้าถึง JavaScript การย้ายข้อมูลจากระบบการวัดที่มีอยู่บางระบบจึงอาจเป็นเรื่องยาก
- ประสิทธิภาพ: การออกแบบใหม่ช่วยลดการสูญหายของข้อมูลเนื่องจากผสานรวมกับความหมายของ
keepaliveได้ง่ายขึ้น เช่น เมื่อมีการบันทึกการคลิกหรือการดูเมื่อผู้ใช้ออกจากหน้าเว็บ
กลไกการทำงานที่ปราศจาก Worklet ทำงานอย่างไร
กลไกการประกาศนี้ใช้ส่วนหัว HTTP เช่นเดียวกับการลงทะเบียนแหล่งที่มาระดับเหตุการณ์และส่วนหัวทริกเกอร์การระบุแหล่งที่มา ดูรายละเอียดเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในส่วนถัดไป
เข้าร่วมการสนทนาสาธารณะ
การลงทะเบียนแหล่งที่มาที่อิงตามส่วนหัว (รายงานแบบรวมได้)
มีการเสนอให้กลไกใหม่ลงทะเบียนแหล่งที่มาสำหรับรายงานที่รวบรวมได้ ซึ่งกลไกนี้เหมือนกับการลงทะเบียนแหล่งที่มาระดับเหตุการณ์
เฉพาะชื่อส่วนหัวเท่านั้นที่ต่างกัน: Attribution-Reporting-Register-Aggregatable-Source
ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค
การลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา
ทริกเกอร์การระบุแหล่งที่มาที่อิงตามส่วนหัว (รายงานรวมได้)
มีการเสนอให้กลไกใหม่ลงทะเบียนแหล่งที่มาสำหรับรายงานที่รวบรวมได้ โดยกลไกนี้เหมือนกับทริกเกอร์การระบุแหล่งที่มาระดับเหตุการณ์
เฉพาะชื่อส่วนหัวเท่านั้นที่ต่างกัน: Attribution-Reporting-Register-Aggregatable-Trigger-Data
ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค
การลงทะเบียนทริกเกอร์การระบุแหล่งที่มา
ฟีเจอร์ใหม่
การรายงานของบุคคลที่สาม (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)
สิ่งที่เปลี่ยนแปลงและสาเหตุ
ข้อเสนอใหม่มี 2 ส่วนที่จะช่วยส่งเสริมกรณีการใช้งานการรายงานของบุคคลที่สามได้ดียิ่งขึ้น ได้แก่
- adtechs สามารถเปลี่ยนเส้นทางคำขอเครือข่ายไปยังเซิร์ฟเวอร์ adtechs อื่นได้ ซึ่งช่วยให้ adtechs อื่นๆ เหล่านั้นดำเนินการแหล่งที่มาของตัวเองและเรียกการลงทะเบียนได้ นี่เป็นวิธีทั่วไปของบุคคลที่สาม ในการกำหนดค่า วิธีนี้จะช่วยให้นำ API ไปใช้ได้ง่ายขึ้น รวมถึงข้อมูลอื่นๆ ในระบบการรายงานของบุคคลที่สามที่มีอยู่
- ที่มาของการรายงาน หรือปกติแล้วคือ AdTechs จะไม่แชร์ขีดจำกัดความเป็นส่วนตัวส่วนใหญ่อีกต่อไป ซึ่งรองรับกรณีการใช้งานที่ AdTech หลายรายการทำงานร่วมกับผู้เผยแพร่โฆษณาหรือผู้ลงโฆษณารายเดียวกัน
การรายงานของบุคคลที่สามทำงานอย่างไร
ในข้อเสนอใหม่ การลงทะเบียนแหล่งที่มาตามการตอบกลับและทริกเกอร์จะอาศัยส่วนหัว HTTP AdTech ใช้ประโยชน์จากการเปลี่ยนเส้นทาง HTTP สำหรับคำขอเหล่านี้ได้
หากคำขอคลิก/ดูบนเว็บไซต์ของผู้เผยแพร่โฆษณา (การลงทะเบียนแหล่งที่มา) มีการเปลี่ยนเส้นทางไปยังหลายฝ่ายในภายหลัง แต่ละฝ่ายในกลุ่มเหล่านี้จะลงทะเบียนการดูหรือคลิก (เหตุการณ์แหล่งที่มา) นี้ได้
ในทำนองเดียวกัน AdTech อาจเปลี่ยนเส้นทางคำขอการระบุแหล่งที่มาที่เจาะจงซึ่งมาจากเว็บไซต์ Adivertiser เพื่อช่วยให้บุคคลอื่นหลายฝ่ายลงทะเบียน Conversion (ทริกเกอร์การระบุแหล่งที่มา) ได้
แต่ละฝ่ายเข้าถึงรายงานแยกกันได้และกําหนดค่าให้ด้วยข้อมูลแยกกัน
ลงทะเบียนทริกเกอร์หลายรายการโดยไม่ต้องเปลี่ยนเส้นทาง
นอกจากนี้คุณยังลงทะเบียนทริกเกอร์การระบุแหล่งที่มาหลายรายการได้โดยไม่ต้องใช้การเปลี่ยนเส้นทาง โดยเพิ่มองค์ประกอบพิกเซลหลายรายการในฝั่ง Conversion (1 รายการต่อทริกเกอร์)
เข้าร่วมการสนทนาสาธารณะ
การวัดการดูผ่าน (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)
สิ่งที่เปลี่ยนแปลงและสาเหตุ
ในข้อเสนอใหม่ การวัดการดูผ่านและการวัดการคลิกผ่านทำงานในลักษณะเดียว
registerattributionsrcซึ่งเป็นแอตทริบิวต์เฉพาะการดูที่สั่งให้เบราว์เซอร์บันทึกการดูพร้อมกับการคลิกนั้นไม่เป็นส่วนหนึ่งของข้อเสนอแล้ว- ตอนนี้กลไกด้านความเป็นส่วนตัวได้รวมเป็นหนึ่งเดียวกับทั้งการคลิกและการดูแล้ว ในส่วนนี้ โปรดดูรายละเอียดในเสียงรบกวนและความโปร่งใส
มีการเสนอการเปลี่ยนแปลงนี้ให้สอดคล้องกับกลไกการลงทะเบียนที่อิงตามส่วนหัวใหม่ นอกจากนี้ ยังช่วยให้นักพัฒนาแอปได้รับประสบการณ์ได้ง่ายขึ้นเมื่อต้องการรองรับการวัดทั้งการคลิกและการดูผ่าน
การวัดการดูผ่านทำงานอย่างไร
ทั้งการวัดการดูผ่านและการวัดการคลิกผ่านใช้การลงทะเบียนตามส่วนหัว
ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค
รายงานระดับเหตุการณ์ (สำหรับทั้งการคลิกและข้อมูลพร็อพเพอร์ตี้)
เข้าร่วมการสนทนาสาธารณะ
การแก้ไขข้อบกพร่อง / การวิเคราะห์ประสิทธิภาพ (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)
สิ่งที่เปลี่ยนแปลงและสาเหตุ
มีการเพิ่มกลไกการแก้ไขข้อบกพร่องในข้อเสนอเพื่อช่วยนักพัฒนาแอปตรวจหาข้อบกพร่อง และเปรียบเทียบประสิทธิภาพของ Attribution Reporting กับโซลูชันการวัดผลที่ใช้คุกกี้ที่มีอยู่
การแก้ไขข้อบกพร่องทำงานอย่างไร
การลงทะเบียนแหล่งที่มาและทริกเกอร์จะยอมรับพารามิเตอร์ debug_key ใหม่ ซึ่งเป็นจำนวนเต็มที่ไม่มีเครื่องหมาย 64 บิต (ซึ่งเป็นตัวเลขที่มาก)
หากสร้างรายงานโดยมีคีย์การแก้ไขข้อบกพร่องและแหล่งที่มา รวมถึงหากมีคุกกี้ Samesite=None ar_debug=1 อยู่ในโหลคุกกี้ของต้นทางการรายงาน ณ เวลาลงทะเบียนของทริกเกอร์และแหล่งที่มา ระบบจะส่งรายงานการแก้ไขข้อบกพร่อง (JSON) ไปยังปลายทาง .well-known/attribution-reporting/debug ดังนี้
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้จะมีพารามิเตอร์ใหม่ 2 รายการนี้รวมอยู่ด้วย เพื่อให้เชื่อมโยงกับรายงานการแก้ไขข้อบกพร่องที่ถูกต้องได้
ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค
ไม่บังคับ: รายงานการแก้ไขข้อบกพร่องเพิ่มเติม
เข้าร่วมการสนทนาสาธารณะ
ความสามารถในการกรอง (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)
สิ่งที่เปลี่ยนแปลงและสาเหตุ
เนื่องจากรองรับ Use Case ที่สำคัญในระบบนิเวศการโฆษณาปัจจุบัน ตอนนี้ระบบจึงรองรับ Use Case จำนวนหนึ่งทั้งในรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้
- การกรอง Conversion: กรอง Conversion ตามข้อมูลฝั่งแหล่งที่มา ตัวอย่างเช่น เลือกข้อมูลทริกเกอร์ (ข้อมูล Conversion) ที่แตกต่างกันสำหรับการคลิกและดูโฆษณา
- การระบุแหล่งที่มาไม่ตรงกัน: กรอง Conversion ที่มีการระบุแหล่งที่มาไม่ถูกต้อง ซึ่งเป็นการกรอง Conversion ประเภทที่เจาะจง ตัวอย่างเช่น กรอง Conversion ที่ตรงกับการคลิก/การดูโฆษณาที่ไม่ถูกต้องออกเนื่องจากขอบเขตปลายทาง etld + 1 ใน API
ความสามารถในการกรองทำงานอย่างไร (สำหรับรายงานระดับเหตุการณ์)
ช่อง source_data (ไม่บังคับ) ในออบเจ็กต์ JSON ฝั่งแหล่งที่มาจะกำหนดรายการที่เบราว์เซอร์จะใช้ในภายหลังได้ ณ เวลาที่เกิด Conversion เพื่อนำตรรกะการกรองไปใช้
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
ตอนนี้การลงทะเบียนทริกเกอร์จะยอมรับส่วนหัวที่ไม่บังคับ Attribution-Reporting-Filters
ส่วนหัวการตอบกลับ HTTP Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
อีกทางเลือกหนึ่งคือ คุณสามารถขยายส่วนหัว Attribution-Reporting-Register-Event-Trigger ด้วยช่อง filters เพื่อทำการกรองเฉพาะส่วนเพื่อตั้งค่า trigger_data ตาม source_data
หากคีย์ในตัวกรอง JSON จับคู่คีย์ใน source_data ระบบจะ
ละเว้นทริกเกอร์โดยสิ้นเชิงหากทางแยกว่างเปล่า
ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค
ตัวกรองการระบุแหล่งที่มาที่ไม่บังคับ
เข้าร่วมการสนทนาสาธารณะ
การเปลี่ยนแปลงการคุ้มครองความเป็นส่วนตัว
ข้อผิดพลาดและความโปร่งใส (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)
สิ่งที่เปลี่ยนแปลงและสาเหตุ
ในข้อเสนอใหม่นี้ หนึ่งในกลไกด้านความเป็นส่วนตัวสำหรับรายงานได้รับการปรับปรุง นั่นคือรายงานจะต้องมีคำตอบแบบสุ่ม
ซึ่งหมายความว่าจะมีการรายงาน Conversion จริงบางรายการอย่างถูกต้อง และระบบจะระงับ Conversion จริงบางรายการหรือเพิ่ม Conversion ปลอมบางรายการ
เทคนิคใหม่นี้มีประโยชน์บางประการ ดังนี้
- โดยจะรวมกลไกด้านความเป็นส่วนตัวสำหรับการคลิกและการดู
- และให้เหตุผลง่ายกว่ามากกว่ากลไกที่จะแยกข้อมูลทริกเกอร์ (ข้อมูล Conversion) และสัญญาณรบกวนลิงก์แหล่งที่มาของทริกเกอร์
- โดยจะสร้างเฟรมเวิร์กความเป็นส่วนตัว ซึ่งใช้การตั้งค่าเสียงรบกวนที่เหมาะสมได้ เพื่อให้มั่นใจได้ว่าไม่มีฝ่ายใดอาศัย API นี้เพื่อให้ทราบได้อย่างมั่นใจว่าผู้ใช้แต่ละคนได้ทำ Conversion (หรือไม่ทำ) สำหรับโฆษณาหนึ่งๆ
กลไกใหม่นี้มาแทนที่กลไกก่อนหน้านี้ซึ่งแทนที่ 5% ของข้อมูลทริกเกอร์ (ข้อมูล Conversion) ด้วยค่าแบบสุ่ม
นอกจากนี้ยังมีการเพิ่มค่าความน่าจะเป็นของการตอบกลับแบบสุ่มลงในเนื้อหารายงาน (ช่อง randomized_trigger_rate) ช่องนี้ระบุความน่าจะเป็น (0 ถึง 1) ที่แหล่งที่มาจะได้รับคำตอบแบบสุ่ม
ซึ่งมีข้อดีหลักๆ 2 ประการดังนี้
- ทําให้ลักษณะการทำงานพื้นฐานของเบราว์เซอร์transparentต่อฝ่ายที่จะได้รับรายงาน (โดยทั่วไปคือ adtechs)
- สิ่งที่จะเป็นประโยชน์ในอนาคตที่ API จะได้รับการรองรับในเบราว์เซอร์ต่างๆ กล่าวคือ เบราว์เซอร์ที่แตกต่างกันอาจเลือกที่จะใช้ระดับสัญญาณรบกวนที่แตกต่างกันขึ้นอยู่กับเป้าหมายด้านความเป็นส่วนตัวของตน และฝ่ายที่จะจัดการรายงานจะต้องมีสิทธิ์เข้าถึงข้อมูลนี้
เสียงรบกวนทำงานอย่างไร
ในข้อเสนอใหม่ เมื่อมีการบันทึกแหล่งที่มา (เช่น มีการบันทึกการคลิกหรือการดูโฆษณา) เบราว์เซอร์จะสุ่มตัดสินว่าจะระบุแหล่งที่มาของ Conversion และส่งรายงานสำหรับการคลิก/การดูโฆษณานี้ตามความเป็นจริง หรือจะสร้างเอาต์พุตปลอมแทน
เอาต์พุตปลอมอาจมีลักษณะดังนี้
- ไม่มีรายงานเลย ไม่ว่าผู้ใช้จะทํา Conversion หรือไม่ก็ตาม
- รายงานปลอมอย่างน้อย 1 รายการ ไม่ว่าผู้ใช้จะทำ Conversion หรือไม่ก็ตาม
ในรายงานปลอม ข้อมูลทริกเกอร์ (ข้อมูล Conversion) จะเป็นแบบสุ่ม กล่าวคือ ค่า 3 บิตแบบสุ่มสำหรับการคลิก (ตัวเลขใดก็ได้ระหว่าง 0 ถึง 7) และค่า 1 บิตแบบสุ่มสําหรับการดู (0 หรือ 1)
เช่นเดียวกับรายงานจริง จะไม่มีการส่งรายงานปลอมในทันทีหลังจากที่ผู้ใช้ทำ Conversion โดยจะได้รับการสุ่มเมื่อสิ้นสุดกรอบเวลาการรายงานแบบสุ่ม
มีกรอบเวลาการรายงาน 3 ช่วงสำหรับการคลิก (2 วัน, 7 วัน หรือ 30 วันหลังจากการคลิก) รายงานปลอมแต่ละฉบับจะได้รับการสุ่มกำหนดให้กับหน้าต่างการรายงานใดหน้าต่างหนึ่ง
การจัดลำดับรายงานภายในกรอบเวลาจะเป็นแบบสุ่มแยกต่างหาก ดังที่ข้อเสนอก่อนหน้าได้ระบุไว้แล้ว
ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค
ตัวอย่าง Conversion ปลอมที่ส่งเสียงดัง
เข้าร่วมการสนทนาสาธารณะ
ข้อจำกัดการรายงาน (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)
สิ่งที่เปลี่ยนแปลงและสาเหตุ
ข้อเสนอใหม่นี้จํากัดจํานวนฝ่ายที่วัดเหตุการณ์ระหว่าง 2 เว็บไซต์อย่างชัดแจ้ง
- จำนวนสูงสุดของต้นทางการรายงานที่ไม่ซ้ำกัน (โดยทั่วไปคือ Adtechs) ที่ลงทะเบียนแหล่งที่มาได้ต่อ {publisher, advertiser} โดยเสนอให้จำกัดอยู่ที่ 100 ครั้งต่อ 30 วัน ระบบจะนับตัวนับนี้เพิ่มขึ้นสำหรับการคลิกโฆษณาหรือการดูแต่ละครั้ง (เหตุการณ์แหล่งที่มา) แม้ว่าจะไม่มีการระบุแหล่งที่มาก็ตาม
- จำนวนสูงสุดของต้นทางการรายงานที่ไม่ซ้ำกัน (โดยทั่วไปคือ adtechs) ที่สามารถส่งรายงานต่อ {publisher, advertiser} ได้ โดยเสนอให้จำกัดอยู่ที่ 10 ครั้งต่อ 30 วัน ระบบจะเพิ่มตัวนับนี้ สำหรับ Conversion ที่มีการระบุแหล่งที่มาทุกรายการ
ขีดจำกัดเหล่านี้ตั้งใจให้สูงพอที่จะไม่เป็นการจำกัดความสามารถของผู้ดำเนินการในการวัด Conversion แต่ให้ต่ำพอที่จะช่วยลดการละเมิด API บางรูปแบบได้
ระยะเวลาพัก / อัตราสูงสุดของการรายงาน
สิ่งที่เปลี่ยนแปลงและสาเหตุ
ระยะเวลาพักการรายงานเป็นกลไกด้านความเป็นส่วนตัวที่ควบคุมปริมาณข้อมูลทั้งหมดที่ส่งผ่าน API นี้ในระยะเวลาที่กำหนดสำหรับผู้ใช้
ในข้อเสนอใหม่ คุณจะกำหนดให้รายงานได้ 100 ครั้งต่อ {source site, destination, reporting origin} (โดยทั่วไปคือ {publisher, advertiser, adtech}) ในระยะเวลา 30 วัน
หากเกินขีดจำกัดนี้ เบราว์เซอร์จะหยุดตั้งเวลารายงานที่ตรงกับ {source site, destination, reporting origin} ที่ระบุนี้ (โดยทั่วไปคือ {publisher, advertiser, adtech}) จนกว่าจำนวนรายงานต่อเนื่อง 30 วันจะลดลงต่ำกว่า 100 สำหรับ {source site, destination, reporting origin} ดังกล่าว
ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค
ระยะเวลาพัก / อัตราสูงสุดของการรายงาน
การกำหนดความถี่สูงสุด (รายงานระดับเหตุการณ์เท่านั้น)
สิ่งที่เปลี่ยนแปลงและสาเหตุ
การกำหนดความถี่สูงสุดได้รับการแก้ไขให้รวมต้นทางการรายงาน (โดยทั่วไปคือ AdTech) ไว้ในขอบเขตดังนี้ 100 ปลายทางที่ไม่ซ้ำกันที่รอดำเนินการ (โดยปกติจะเป็นเว็บไซต์ของผู้ลงโฆษณาหรือเว็บไซต์ที่คาดว่าจะมี Conversion เกิดขึ้น) ต่อ {publisher, adtech}
นี่คือการคุ้มครองความเป็นส่วนตัวเพื่อจำกัดการสร้างประวัติการท่องเว็บใหม่
ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค
การจำกัดจำนวนปลายทางที่ไม่ซ้ำกันซึ่งครอบคลุมโดยแหล่งที่มาที่รอดำเนินการ
ทรัพยากรทั้งหมด
รูปภาพส่วนหัวมาจาก Diana Polekhina ใน Unsplash