ข้อมูลเบื้องต้นเกี่ยวกับรายงานการแก้ไขข้อบกพร่องของ Attribution Reporting

ส่วนที่ 1 จาก 3 เกี่ยวกับการแก้ไขข้อบกพร่องของรายงานการระบุแหล่งที่มา ดูสาเหตุที่การแก้ไขข้อบกพร่องมีความสำคัญและกรณีที่ควรใช้รายงานการแก้ไขข้อบกพร่องในการทดสอบ

เหตุใดคุณจึงต้องมีรายงานการแก้ไขข้อบกพร่อง

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

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

อภิธานศัพท์

ลักษณะสำคัญของรายงานการแก้ไขข้อบกพร่อง

รายงานการแก้ไขข้อบกพร่อง 2 ประเภท

โดยมีรายงานการแก้ไขข้อบกพร่อง 2 ประเภทด้วยกัน ใช้ทั้ง 2 แบบ เนื่องจากกรณีการใช้งานที่ต่างกัน

รายงานการแก้ไขข้อบกพร่องสำเร็จ

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

รายงานแก้ไขข้อบกพร่องสำเร็จพร้อมให้ใช้งานแล้วตั้งแต่ Chrome 101 (เมษายน 2022)

รายงานการแก้ไขข้อบกพร่องแบบละเอียด

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

  • กรณีที่เบราว์เซอร์ลงทะเบียนแหล่งที่มาสำเร็จ
  • กรณีที่เบราว์เซอร์ไม่ลงทะเบียนเหตุการณ์แหล่งที่มาหรือทริกเกอร์เหตุการณ์สําเร็จ ซึ่งหมายความว่าเบราว์เซอร์จะไม่สร้างรายงานการระบุแหล่งที่มา
  • กรณีที่ระบบสร้างหรือส่งรายงานการระบุแหล่งที่มาไม่ได้ด้วยเหตุผลบางอย่าง

รายงานการแก้ไขข้อบกพร่องแบบละเอียดจะมีช่อง type ที่อธิบายการลงทะเบียนแหล่งที่มาที่สำเร็จ หรือเหตุผลที่ระบบไม่สร้างรายงานแหล่งที่มา ทริกเกอร์ หรือระบุแหล่งที่มา

รายงานการแก้ไขข้อบกพร่องแบบละเอียดมีให้บริการตั้งแต่ Chrome 109 (มกราคม 2023) แล้ว ยกเว้นรายงานการแก้ไขข้อบกพร่องแบบละเอียดสำหรับการลงทะเบียนต้นทางที่เพิ่มเข้ามาภายหลังใน Chrome 112

ดูตัวอย่างรายงานในส่วนที่ 2: ตั้งค่ารายงานการแก้ไขข้อบกพร่อง

หากต้องการใช้รายงานการแก้ไขข้อบกพร่อง ต้นทางการรายงานจะต้องตั้งค่าคุกกี้

หากต้นทางที่กำหนดค่าเพื่อรับรายงานเป็นบุคคลที่สาม คุกกี้นี้จะเป็นบุคคลที่สาม คุกกี้ ซึ่งมีนัยสำคัญบางประการดังนี้

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

ระบบจะส่งรายงานการแก้ไขข้อบกพร่องทันที

เบราว์เซอร์จะส่งรายงานการแก้ไขข้อบกพร่องไปยังต้นทางการรายงานทันที ช่วงเวลานี้ นั้นต่างจากรายงานการระบุแหล่งที่มาซึ่งส่งด้วย ล่าช้า

ระบบจะสร้างและส่งรายงานการแก้ไขข้อบกพร่องสำเร็จทันทีที่ ระบบจะสร้างรายงานการระบุแหล่งที่มาที่เกี่ยวข้อง นั่นคือเมื่อมีการทริกเกอร์ การลงทะเบียน

ระบบจะส่งรายงานการแก้ไขข้อบกพร่องแบบละเอียดทันทีเมื่อมีแหล่งที่มาหรือทริกเกอร์ การลงทะเบียน

รายงานแก้ไขข้อบกพร่องมีเส้นทางปลายทางต่างกัน

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

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

ดูข้อมูลเพิ่มเติมในส่วนที่ 2: ตั้งค่ารายงานการแก้ไขข้อบกพร่อง

กรณีการใช้งาน

การตรวจสอบการผสานรวมแบบเรียลไทม์พื้นฐาน

ระบบจะส่งรายงานการแก้ไขข้อบกพร่องไปยังปลายทางทันที ซึ่งจะแตกต่างจากรายงานการระบุแหล่งที่มา ซึ่งจะล่าช้าเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้ ใช้รายงานการแก้ไขข้อบกพร่องเป็นสัญญาณแบบเรียลไทม์ว่าการผสานรวมกับ Attribution Reporting API กําลังทํางาน

เรียนรู้วิธีการในส่วนที่ 3: การแก้ไขข้อบกพร่องในตำราอาหาร

การวิเคราะห์การสูญเสีย

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

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

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

ดูวิธีเรียกใช้การวิเคราะห์การสูญหายในส่วนที่ 3: การแก้ไขข้อบกพร่องของตำราอาหาร

การแก้ปัญหา

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

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

การตรวจสอบการกำหนดค่าขั้นสูง

ฟีเจอร์บางอย่างของ Attribution Reporting API จะให้คุณปรับแต่ง API พฤติกรรมของคุณ ตัวอย่างของกฎการกรอง กฎการกรองข้อมูลที่ซ้ำกันออก และกฎลำดับความสำคัญ

เมื่อใช้ฟีเจอร์เหล่านี้ ให้ใช้รายงานการแก้ไขข้อบกพร่องเพื่อตรวจสอบว่าตรรกะของคุณนำไปสู่ลักษณะการทำงานที่ต้องการใน เวอร์ชันที่ใช้งานจริง โดยไม่ต้องรอรายงานการระบุแหล่งที่มา เรียนรู้วิธีการในส่วนที่ 3: การแก้ไขข้อบกพร่องในตำราอาหาร

การทดสอบในเครื่องกับรายงานที่รวบรวมได้

รายงานแก้ไขข้อบกพร่องที่รวบรวมได้ต่างจากรายงานการระบุแหล่งที่มาที่รวบรวมได้ซึ่งเข้ารหัส รวมถึงเพย์โหลดที่ไม่เข้ารหัส

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

การประมวลผลรายงานบริการรวมข้อมูลอีกครั้ง

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

  • กำลังแก้ไขข้อบกพร่องของ Aggregation Service
  • ด้วยกลยุทธ์การทำงานแบบกลุ่ม ที่แตกต่างกัน
  • ด้วยค่า epsilon ที่แตกต่างกัน

การกู้ข้อมูล

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

ถัดไป

ส่วนที่ 2: ตั้งค่ารายงานการแก้ไขข้อบกพร่อง