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

bookmark_border จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

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

บันทึกการเปลี่ยนแปลง

• 7 กุมภาพันธ์ 2022: เพิ่มส่วนการเปลี่ยนเส้นทางทริกเกอร์ส่วนหัว
• 27 มกราคม 2022: เผยแพร่บทความเป็นครั้งแรก

โพสต์นี้มีไว้สำหรับใคร

โพสต์นี้มีไว้สำหรับคุณ

• หากคุณเข้าใจ API อยู่แล้ว เช่น หากคุณสังเกตการณ์หรือเข้าร่วมการสนทนาในที่เก็บข้อมูล WICG และต้องการทำความเข้าใจชุดการเปลี่ยนแปลงที่ทํากับข้อเสนอในเดือนมกราคม 2022
• หากคุณใช้ Attribution Reporting API ในเวอร์ชันเดโมหรือเวอร์ชันทดลองในเวอร์ชันที่ใช้งานจริง

หากคุณเพิ่งเริ่มใช้ API นี้และ/หรือยังไม่ได้ทดลองใช้ ให้ไปที่ข้อมูลเบื้องต้นเกี่ยวกับ API โดยตรงแทน

การย้ายข้อมูลที่กำลังจะเกิดขึ้น

เมื่อใช้การเปลี่ยนแปลงเหล่านี้ใน Chrome หากคุณใช้รายงานระดับเหตุการณ์จาก Attribution Reporting API ในเวอร์ชันเดโมหรือเวอร์ชันทดลองในเวอร์ชันที่ใช้งานจริง (ช่วงทดลองใช้จากต้นทาง) คุณจะต้องแก้ไขโค้ดเพื่อให้ API ทํางานต่อไปได้ คุณอาจพิจารณาใช้ฟีเจอร์ใหม่ด้วย

บทความนี้ยังแสดงการเปลี่ยนแปลงของรายงานที่รวบรวมได้อีกด้วย อย่างไรก็ตาม หากมีการใช้การเปลี่ยนแปลงเหล่านี้ คุณไม่จําเป็นต้องดําเนินการหรือย้ายข้อมูลใดๆ เนื่องจากยังไม่มีการใช้เบราว์เซอร์สําหรับรายงานที่รวบรวมข้อมูลได้ ณ เวลาที่เขียนบทความนี้

การเปลี่ยนชื่อ

รายงานสรุปและรายงานที่รวบรวมได้

สิ่งที่คุณอาจเห็นอธิบายว่าเป็นรายงานรวมจะเปลี่ยนเป็นรายงานสรุป

รายงานสรุปคือเอาต์พุตสุดท้ายของการรวมรายงานที่รวบรวมได้หลายรายการ ซึ่งก่อนหน้านี้เรียกว่าการมีส่วนร่วมหรือการมีส่วนร่วมของฮิสโตแกรม

การเปลี่ยนแปลงกลไกของ API

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

สิ่งที่เปลี่ยนแปลงและเหตุผล

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

วิธีการตั้งค่าพารามิเตอร์เหล่านี้กําลังมีการเปลี่ยนแปลง

ในข้อเสนอก่อนหน้านี้ พารามิเตอร์ต้องรวมอยู่ในฝั่งไคลเอ็นต์ ไม่ว่าจะเป็นในแท็ก Anchor ในฐานะแอตทริบิวต์ HTML หรือเป็นอาร์กิวเมนต์ของการเรียกใช้ JS พารามิเตอร์ต้องทราบ ณ เวลาที่มีการคลิกหรือดู

ในข้อเสนอใหม่ ค่าของพารามิเตอร์เหล่านี้จะกำหนดไว้ในเซิร์ฟเวอร์ AdTech แทน

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

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

1. ตอนนี้เทคโนโลยีโฆษณาจะต้องกำหนดแอตทริบิวต์ฝั่งไคลเอ็นต์ที่เฉพาะเจาะจงสำหรับโฆษณาหนึ่งๆ 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

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

สิ่งที่เปลี่ยนแปลงและเหตุผล

เช่นเดียวกับการบันทึกการคลิกหรือการดู ข้อเสนอใหม่นี้จะเปลี่ยนทริกเกอร์การระบุแหล่งที่มา (เมื่อเทคโนโลยีโฆษณาสั่งให้เบราว์เซอร์บันทึก 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)
    }]

การเปลี่ยนเส้นทาง (ไม่บังคับ)

เซิร์ฟเวอร์เทคโนโลยีโฆษณาอาจสร้างการตอบกลับที่มี Attribution-Reporting-Register-Event-Trigger การตอบกลับการเปลี่ยนเส้นทาง (ไม่บังคับ) ซึ่งจะช่วยให้บุคคลที่สามสังเกตเหตุการณ์ Conversion และสั่งให้เบราว์เซอร์ระบุแหล่งที่มาของเหตุการณ์ได้

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

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

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

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

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

ฉบับที่ 91

ไม่มีเวิร์กเลต (รายงานที่รวบรวมได้)

สิ่งที่เปลี่ยนแปลงและเหตุผล

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

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

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

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

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

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

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

ปัญหา #194

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

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

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

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

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

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

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

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

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

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

ฟีเจอร์ใหม่

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

สิ่งที่เปลี่ยนแปลงและเหตุผล

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

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

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

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

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

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

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

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

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

ปัญหา #91 ปัญหา #261

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

สิ่งที่เปลี่ยนแปลงและเหตุผล

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

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

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

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

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

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

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

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

ฉบับที่ 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 ที่สําคัญในระบบนิเวศการโฆษณาในปัจจุบัน ระบบจึงรองรับ Use Case จํานวนหนึ่งทั้งในรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ ดังนี้

• การกรอง Conversion: กรอง Conversion ตามข้อมูลฝั่งแหล่งที่มา เช่น เลือกข้อมูลทริกเกอร์ (ข้อมูล Conversion) ที่แตกต่างกันสําหรับการคลิกและยอดดูโฆษณา
• การระบุแหล่งที่มาไม่ตรงกัน: ตัวกรอง Conversion ที่มีการระบุแหล่งที่มาไม่ถูกต้อง ซึ่งเป็นการกรอง Conversion ประเภทหนึ่ง เช่น กรอง Conversion ที่ตรงกับการคลิก/การดูโฆษณาที่ไม่ถูกต้องเนื่องจากขอบเขตปลายทาง etld+1 ใน API

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

ช่อง source_data (ไม่บังคับ) ในแออบเจ็กต์ JSON ฝั่งแหล่งที่มาสามารถกําหนดรายการที่เบราว์เซอร์จะใช้ในภายหลัง ณ เวลาแปลงเพื่อใช้ตรรกะการกรอง

  {
    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 ข้อหลัก ดังนี้

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

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

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

เอาต์พุตปลอมอาจเป็นสิ่งต่อไปนี้

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

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

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

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

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

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

ตัวอย่าง Conversion ปลอมที่มีสัญญาณรบกวน

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

ปัญหา #84
ปัญหา #273

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

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

สิ่งที่เปลี่ยนแปลงและเหตุผล

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

• เราขอแนะนำให้จำกัดจำนวนแหล่งที่มาของการรายงานที่ไม่ซ้ำกัน (โดยทั่วไปคือเทคโนโลยีโฆษณา) สูงสุดที่ลงทะเบียนได้ไว้ที่100 แหล่งต่อ 30 วัน ตัวนับนี้จะเพิ่มขึ้นสําหรับการคลิกหรือยอดดูโฆษณาแต่ละครั้ง (เหตุการณ์แหล่งที่มา) แม้แต่การคลิกหรือยอดดูที่ไม่ได้ระบุแหล่งที่มา
• เราขอแนะนำให้จำกัดจำนวนแหล่งที่มาของการรายงานที่ไม่ซ้ำกัน (โดยทั่วไปคือ AdTech) สูงสุดที่ส่งรายงานได้ต่อ {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}

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

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

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

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

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

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