ข้อมูลอัปเดตเกี่ยวกับข้อเสนอการรายงานการระบุแหล่งที่มาในเดือนมกราคม 2022

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

การลงทะเบียนแหล่งที่มาทำงานอย่างไร

1. สำหรับโฆษณาหนึ่งๆ ตอนนี้ AdTech จะต้องกำหนดแอตทริบิวต์ฝั่งไคลเอ็นต์ที่เฉพาะเจาะจง attributionsrc ค่าของแอตทริบิวต์นี้คือ URL ที่เบราว์เซอร์จะส่ง คำขอ; คำขอนี้จะมีส่วนหัว HTTP ใหม่ Attribution-Reporting-Source-Info ซึ่งมี navigationหรือevent,จะระบุว่าแหล่งที่มาเป็นการคลิกหรือการดูตามลำดับ
2. เมื่อได้รับคำขอนี้ เซิร์ฟเวอร์การติดตามการคลิก/การดูควรตอบกลับด้วย HTTP ส่วนหัว Attribution-Reporting-Register-Source ที่มีการระบุแหล่งที่มาที่ต้องการ พารามิเตอร์

3. ตอนนี้ต้นทางที่แสดงผลส่วนหัวนี้อยู่คือต้นทางการรายงาน (เดิมเรียกว่า attributionreportto)

   ส่วนหัวการตอบกลับ HTTP Attribution-Reporting-Register-Source:

   {
     "source_event_id": "267630968326743374",
     "destination": "https://toasters.example",
     "expiry": "604800000"
   }
   

ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค

การลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา

เข้าร่วมการสนทนาสาธารณะ

ปัญหา #261

ทริกเกอร์การระบุแหล่งที่มาที่อิงตามส่วนหัว (รายงานระดับเหตุการณ์)

มีอะไรเปลี่ยนแปลงบ้างและเพราะเหตุใด

เช่นเดียวกับการคลิกหรือดูการลงทะเบียน ข้อเสนอใหม่จะเปลี่ยนทริกเกอร์การระบุแหล่งที่มา เมื่อ 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 และบุคคลที่สามมีพิกเซลในหน้าเว็บ

ดูรายละเอียดเพิ่มเติมในการรายงานของบุคคลที่สาม

ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค

การระบุแหล่งที่มาที่ทริกเกอร์

เข้าร่วมการสนทนาสาธารณะ

ฉบับที่ 91

ไม่มี Worklet (รายงานที่รวบรวมได้)

มีอะไรเปลี่ยนแปลงบ้างและเพราะเหตุใด

ในข้อเสนอก่อนหน้านี้สำหรับรายงานที่รวบรวมได้ จำเป็นต้องมีการเข้าถึง JavaScript เพื่อเรียก Worklet ซึ่งเป็นกลไกที่ใช้ JavaScript ที่จะสร้างรายงานเหล่านี้

ไม่จำเป็นต้องมี Worklet ในข้อเสนอใหม่ แต่ AdTech จะกำหนดค่าอย่างประกาศผ่าน HTTP Header ซึ่งเป็นกฎที่เบราว์เซอร์ควรใช้ในการสร้างรายงานที่รวบรวมได้

ข้อเสนอใหม่มีข้อดีหลายประการดังนี้

• การใช้เบราว์เซอร์: การออกแบบใหม่ซึ่งแตกต่างจากการออกแบบของ Worklet ง่ายกว่า เนื่องจากไม่จำเป็นต้องใช้สภาพแวดล้อมการดำเนินการใหม่ในเบราว์เซอร์
• ประสบการณ์ของนักพัฒนาซอฟต์แวร์: การออกแบบใหม่จะใช้ส่วนหัว ซึ่งใช้กันโดยทั่วไปและ ซึ่งนักพัฒนาซอฟต์แวร์เป็นที่รู้จักอย่างกว้างขวาง ซึ่งต่างจากเวิร์กเล็ต และยังมีความใกล้เคียงกับแพลตฟอร์ม API สำหรับ การลงทะเบียนแหล่งที่มา ซึ่งทำให้การเรียนรู้และใช้ API ง่ายขึ้น
• การนำไปใช้: การออกแบบใหม่ช่วยให้ระบบการวัดที่มีอยู่จำนวนมากขึ้นใช้การผสมผสานได้ รายงาน โซลูชันการวัดผลจำนวนมากเป็นแบบ HTTP เท่านั้น ซึ่งอาศัยคำขอรูปภาพ ซึ่งก็คือพิกเซล ที่ไม่ต้องใช้การเข้าถึง JavaScript แต่เนื่องจากแนวทางการทำงานแบบ Worklet จำเป็นต้องใช้ การเข้าถึง JavaScript ซึ่งอาจทำให้ย้ายข้อมูลจากระบบการวัดที่มีอยู่บางระบบได้ยาก
• ประสิทธิภาพการทำงาน: การออกแบบใหม่ช่วยลดการสูญหายของข้อมูลเนื่องจากผสานรวมได้ง่ายขึ้น ที่ใช้ความหมาย keepalive เช่น หากมีการบันทึกการคลิกหรือการดูเมื่อผู้ใช้ออก หน้าเว็บ

กลไกการทำงานแบบไร้เวิร์กเล็ตทำงานอย่างไร

กลไกการประกาศนี้จะอิงตามส่วนหัว HTTP เช่นเดียวกับการลงทะเบียนแหล่งที่มาระดับเหตุการณ์ และส่วนหัวของทริกเกอร์การระบุแหล่งที่มา ดูรายละเอียดเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในส่วนถัดไป

เข้าร่วมการสนทนาสาธารณะ

ฉบับที่ 194

การลงทะเบียนแหล่งที่มาตามส่วนหัว (รายงานที่รวบรวมได้)

มีการเสนอกลไกใหม่ให้ลงทะเบียนแหล่งที่มาสำหรับรายงานที่รวบรวมได้ กลไกนี้คือ เช่นเดียวกับการลงทะเบียนแหล่งที่มาระดับเหตุการณ์

มีเพียงชื่อส่วนหัวเท่านั้นที่แตกต่างกัน: Attribution-Reporting-Register-Aggregatable-Source

ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค

การลงทะเบียนแหล่งที่มาของการระบุแหล่งที่มา

ทริกเกอร์การระบุแหล่งที่มาที่อิงตามส่วนหัว (รายงานที่รวบรวมได้)

มีการเสนอกลไกใหม่ให้ลงทะเบียนแหล่งที่มาสำหรับรายงานที่รวบรวมได้ กลไกนี้คือ เหมือนกับทริกเกอร์การระบุแหล่งที่มาระดับเหตุการณ์

มีเพียงชื่อส่วนหัวเท่านั้นที่แตกต่างกัน: Attribution-Reporting-Register-Aggregatable-Trigger-Data

ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค

การลงทะเบียนทริกเกอร์การระบุแหล่งที่มา

ฟีเจอร์ใหม่

การรายงานของบุคคลที่สาม (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)

มีอะไรเปลี่ยนแปลงบ้างและเพราะเหตุใด

ข้อเสนอใหม่ 2 ด้านจะช่วยสนับสนุนกรณีการใช้งานการรายงานของบุคคลที่สามได้ดีขึ้น ดังนี้

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

การรายงานของบุคคลที่สามทำงานอย่างไร

ในข้อเสนอใหม่ การลงทะเบียนและทริกเกอร์แหล่งที่มาตามการตอบกลับจะอาศัย ส่วนหัว HTTP AdTech ใช้การเปลี่ยนเส้นทาง HTTP สำหรับคำขอเหล่านี้ได้

หากคำขอคลิก/การดู บนไซต์ของผู้เผยแพร่โฆษณา (การลงทะเบียนแหล่งที่มา) ถูกเปลี่ยนเส้นทางไปยัง หลายฝ่าย แต่ละฝ่ายสามารถลงทะเบียนมุมมองนี้หรือคลิก (เหตุการณ์แหล่งที่มา)
ในทำนองเดียวกัน AdTech ก็สามารถเปลี่ยนเส้นทางคําขอการระบุแหล่งที่มาหนึ่งๆ ที่มาจากเว็บไซต์ผู้ลงโฆษณาได้ ซึ่งทำให้บุคคลอื่นหลายรายลงทะเบียน Conversion (ทริกเกอร์การระบุแหล่งที่มา) ได้

แต่ละฝ่ายจะเข้าถึงรายงานของตนเองและเพื่อกำหนดค่าข้อมูลแยกกันได้

ลงทะเบียนทริกเกอร์หลายรายการโดยไม่มีการเปลี่ยนเส้นทาง

นอกจากนี้คุณยังลงทะเบียนทริกเกอร์การระบุแหล่งที่มาได้หลายรายการโดยไม่ต้องใช้การเปลี่ยนเส้นทาง โดยการเพิ่มองค์ประกอบพิกเซลหลายรายการในด้าน Conversion (1 รายการต่อทริกเกอร์)

เข้าร่วมการสนทนาสาธารณะ

ฉบับที่ 91 ฉบับที่ 261

การวัดการดูผ่าน (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)

มีอะไรเปลี่ยนแปลงบ้างและเพราะเหตุใด

ในข้อเสนอใหม่ การวัดการดูผ่านและการวัดการคลิกผ่านจะทำงานแบบรวมเป็นหนึ่งเดียว ดังนี้

• registerattributionsrc ซึ่งเป็นแอตทริบิวต์เฉพาะมุมมองที่สั่งให้เบราว์เซอร์ นับยอดดูเทียบกับการคลิกแล้วจะไม่ได้เป็นส่วนหนึ่งของข้อเสนออีกต่อไป
• ตอนนี้กลไกด้านความเป็นส่วนตัวได้ผสานรวมกันทั้งในการคลิกและการดูแล้ว ในตัวเลือกนี้ ให้ดูรายละเอียดใน Noise และความโปร่งใส

โดยมีการเสนอการเปลี่ยนแปลงนี้เพื่อให้สอดคล้องกับกลไกการลงทะเบียนตามส่วนหัวใหม่ ทั้งยังทำให้นักพัฒนาแอปใช้งานได้ง่ายขึ้นด้วยเมื่อต้องการรองรับทั้งการคลิกผ่านและการดูผ่าน การวัดผล

การวัดการดูผ่านทำงานอย่างไร

ทั้งการวัดการดูผ่านและการวัดการคลิกผ่านต้องใช้การลงทะเบียนตามส่วนหัว

ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค

รายงานระดับเหตุการณ์ (สำหรับทั้งการคลิกและการดู)

เข้าร่วมการสนทนาสาธารณะ

ปัญหา #261

การวิเคราะห์การแก้ไขข้อบกพร่อง / ประสิทธิภาพ (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)

มีอะไรเปลี่ยนแปลงบ้างและเพราะเหตุใด

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

การแก้ไขข้อบกพร่องทำงานอย่างไร

การลงทะเบียนทั้งแหล่งที่มาและทริกเกอร์จะยอมรับพารามิเตอร์ใหม่ debug_key ซึ่งเป็นพารามิเตอร์ 64 บิตที่ไม่มีการรับรอง จำนวนเต็ม (หมายถึงจำนวนมาก)

กรณีที่รายงานสร้างขึ้นโดยมีแหล่งที่มาและทริกเกอร์คีย์การแก้ไขข้อบกพร่อง และหากมีคุกกี้ Samesite=None ar_debug=1 อยู่ในขวดคุกกี้ของต้นทางการรายงานที่ต้นทางและทริกเกอร์เวลาลงทะเบียน ซึ่งเป็นการแก้ไขข้อบกพร่อง ระบบจะส่งรายงาน (JSON) ไปยังปลายทาง .well-known/attribution-reporting/debug:

{
  "source_debug_key": 1234567890987,
  "trigger_debug_key": 4567654345028
}

รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้จะมีพารามิเตอร์ใหม่ทั้ง 2 รายการนี้รวมอยู่ด้วย เพื่อให้ ที่เชื่อมโยงกับรายงานการแก้ปัญหาที่ถูกต้อง

ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค

ไม่บังคับ: รายงานการแก้ไขข้อบกพร่องเพิ่มเติม

เข้าร่วมการสนทนาสาธารณะ

ฉบับที่ 174

ความสามารถในการกรอง (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)

มีอะไรเปลี่ยนแปลงบ้างและเพราะเหตุใด

หลายกรณีการใช้งานเนื่องจากรองรับ 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 ทริกเกอร์จะเป็น
จะไม่มีผลใดๆ หากสี่แยกว่างเปล่า

ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค

ตัวกรองการระบุแหล่งที่มาที่ไม่บังคับ

เข้าร่วมการสนทนาสาธารณะ

ฉบับที่ 194
ฉบับที่ 201

การเปลี่ยนแปลงการคุ้มครองความเป็นส่วนตัว

เสียงรบกวนและความโปร่งใส (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)

มีอะไรเปลี่ยนแปลงบ้างและเพราะเหตุใด

ในข้อเสนอใหม่นี้ หนึ่งในกลไกความเป็นส่วนตัวของรายงานได้รับการปรับปรุงให้ดีขึ้น ซึ่งก็คือการรายงาน ขึ้นอยู่กับคำตอบแบบสุ่ม
ซึ่งหมายความว่า Conversion จริงบางรายการจะได้รับการรายงานอย่างถูกต้อง และเปอร์เซ็นต์ที่แน่นอนของ ในเวลา Conversion จริงบางส่วนจะถูกระงับ หรือมีการเพิ่ม Conversion ปลอมบางรายการ

เทคนิคใหม่นี้มีประโยชน์ดังนี้

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

กลไกใหม่นี้จะแทนที่กลไกเดิมซึ่ง 5% ของเวลาทั้งหมดเรียกใช้ข้อมูล (ข้อมูล Conversion) ถูกแทนที่ด้วยค่าแบบสุ่ม

นอกจากนี้ยังมีการเพิ่มค่าความน่าจะเป็นของคำตอบแบบสุ่มในส่วนเนื้อหาของรายงาน (ช่อง randomized_trigger_rate) ฟิลด์นี้ระบุความน่าจะเป็น (0 ถึง 1) ที่แหล่งข้อมูล อาจได้คำตอบแบบสุ่ม

ซึ่งมีข้อดีหลัก 2 ประการดังนี้

• ซึ่งจะทำให้ลักษณะการทำงานของเบราว์เซอร์ที่เกี่ยวข้องมีความโปร่งใสต่อฝ่ายที่จะได้รับรายงาน (โดยทั่วไปเรียกว่า AdTech)
• ซึ่งจะเป็นประโยชน์สำหรับอนาคตที่จะมีการรองรับ API ใน เบราว์เซอร์ต่างๆ: เบราว์เซอร์ต่างๆ อาจเลือกใช้ระดับสัญญาณรบกวนที่แตกต่างกัน ทั้งนี้ขึ้นอยู่กับ และฝ่ายต่างๆ ที่จะจัดการรายงานจะต้องเห็นเรื่องนี้

เสียงรบกวนทำงานอย่างไร

ในข้อเสนอใหม่ เมื่อมีการลงทะเบียนแหล่งที่มา (นั่นคือ มีการบันทึกการคลิกหรือการดูโฆษณา) เบราว์เซอร์จะสุ่มตัดสินใจว่าจะระบุแหล่งที่มาของ Conversion และส่งรายงานสำหรับ การคลิก/การดูโฆษณา หรือการพิจารณาว่าจะสร้างเอาต์พุตปลอมแทนหรือไม่

โดยผลลัพธ์ปลอมอาจมีลักษณะดังนี้

• ไม่มีรายงานเลย ไม่ว่าผู้ใช้จะทำ Conversion หรือไม่ก็ตาม
• รายงานปลอมอย่างน้อย 1 ฉบับ ไม่ว่าผู้ใช้จะทำ Conversion หรือไม่ก็ตาม

ในรายงานปลอม ข้อมูลทริกเกอร์ (ข้อมูล Conversion) เป็นการสุ่ม ค่า 3 บิตแบบสุ่มสำหรับการคลิก ( ตัวเลขระหว่าง 0 ถึง 7) และค่า 1 บิตแบบสุ่มสำหรับการดู (0 หรือ 1)

เช่นเดียวกับรายงานจริง ระบบจะไม่ส่งรายงานปลอมในทันทีหลังจากที่ผู้ใช้ทำ Conversion ไปส่งที่ ส่วนท้ายของหน้าต่างการรายงานแบบสุ่ม

กรอบเวลาการรายงานสําหรับการคลิกมี 3 หน้าต่าง (2 วัน, 7 วัน หรือ 30 วันหลังการคลิก) ข้อมูลปลอมแต่ละรายการ จะได้รับการสุ่มกำหนดให้กับหนึ่งในหน้าต่างการรายงาน

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

ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค

ตัวอย่าง Conversion ปลอมที่มีเสียงดัง

เข้าร่วมการสนทนาสาธารณะ

ฉบับที่ 84
ฉบับที่ 273

ข้อจำกัดการรายงาน (รายงานระดับเหตุการณ์และรายงานที่รวบรวมได้)

ขีดจํากัดต้นทางการรายงาน

มีอะไรเปลี่ยนแปลงบ้างและเพราะเหตุใด

ข้อเสนอใหม่จำกัดจำนวนผู้ที่วัดเหตุการณ์ระหว่าง 2 เว็บไซต์อย่างชัดแจ้ง

• จํานวนสูงสุดของต้นทางการรายงานที่ไม่ซ้ำกัน (โดยทั่วไปคือ AdTech) ที่ลงทะเบียนได้ มีการเสนอให้แหล่งที่มาต่อ {publisher, advertiser} ไม่เกิน 100 ครั้งต่อ 30 วัน ช่วงเวลานี้ ระบบจะเพิ่มตัวนับเมื่อมีการคลิกหรือการดูโฆษณา (เหตุการณ์แหล่งที่มา) แต่ละครั้ง แม้แต่เหตุการณ์ที่ไม่ได้มาจาก ระบุแหล่งที่มา
• จํานวนสูงสุดของต้นทางการรายงานที่ไม่ซ้ำกัน (โดยทั่วไปคือ AdTech) ที่ส่งรายงานได้ต่อ มีการเสนอให้ {publisher, advertiser} จำกัดอยู่ที่ 10 ครั้งต่อ 30 วัน ตัวนับนี้จะ เพิ่มขึ้นตาม Conversion ที่มีการระบุแหล่งที่มาทุกรายการ

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

ขีดจำกัดระยะเวลาพัก / อัตราการรายงาน

มีอะไรเปลี่ยนแปลงบ้างและเพราะเหตุใด

ระยะเวลาพักการรายงานเป็นกลไกด้านความเป็นส่วนตัวที่ควบคุมปริมาณข้อมูลทั้งหมดที่ส่ง ผ่าน API นี้ภายในระยะเวลาที่กำหนด

ในข้อเสนอใหม่ มีรายงาน 100 ฉบับต่อ {source site,destination, reporting source} (โดยทั่วไปคือ {publisher, advertiser, adtech}) สามารถตั้งเวลาได้นานกว่า 30 วัน

เมื่อเกินขีดจำกัดนี้ เบราว์เซอร์จะหยุดตั้งเวลารายงานที่ตรงกับ {source site, ปลายทาง, ต้นทางการรายงาน} (โดยทั่วไปคือ {publisher, advertiser, adtech}) จนถึงช่วง 30 วันต่อเนื่อง จำนวนรายงานต่ำกว่า 100 สำหรับ {source site, destination, reportingorigin}

ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค

ขีดจำกัดระยะเวลาพัก / อัตราการรายงาน

การกำหนดความถี่สูงสุด (รายงานระดับเหตุการณ์เท่านั้น)

มีอะไรเปลี่ยนแปลงบ้างและเพราะเหตุใด

ระบบแก้ไขการกำหนดความถี่สูงสุดปลายทางให้รวมต้นทางการรายงาน (โดยทั่วไปคือ AdTech) ในขอบเขตดังนี้ 100 ที่ไม่ซ้ำกัน ปลายทางที่รอดำเนินการ (โดยทั่วไปคือ เว็บไซต์ของผู้ลงโฆษณา หรือเว็บไซต์ที่มี Conversion เกิดขึ้น Place) ได้ต่อ {publisher, adtech}

นี่คือการคุ้มครองความเป็นส่วนตัวเพื่อจำกัดการสร้างประวัติการท่องเว็บอีกครั้ง

ดูข้อมูลเพิ่มเติมในคำอธิบายทางเทคนิค

การจำกัดจำนวนปลายทางที่ไม่ซ้ำกันซึ่งแหล่งที่มาที่รอดำเนินการครอบคลุม

ทรัพยากรทั้งหมด

• ดูการรายงานการระบุแหล่งที่มา
• โปรดอ่านสิ่งที่คุณควรรู้เกี่ยวกับ API

รูปภาพส่วนหัวมาจาก Diana Polekhina ใน Unsplash