ตำราการแก้ไขข้อบกพร่องในการรายงานการระบุแหล่งที่มา

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

ในสูตรนี้ คุณจะเห็นวิธีการใช้รายงานข้อบกพร่องสำหรับ Use Case ต่างๆ ที่ระบุไว้ในส่วนที่ 1: ข้อมูลเบื้องต้นเกี่ยวกับรายงานข้อบกพร่อง

อภิธานศัพท์

  • The reporting origin is the origin that sets the Attribution Reporting source and trigger headers. All reports generated by the browser are sent to this origin. In this guidance, we use https://adtech.example as the example reporting origin.
  • An attribution report (report for short) is the final report (event-level or aggregatable) that contains the measurement data you've requested.
  • A debug report contains additional data about an attribution report, or about a source or trigger event. Receiving a debug report does not necessarily mean that something is working incorrectly! There are two types of debug reports
  • A transitional debug report is a debug report that requires a cookie to be set in order to be generated and sent. Transitional debug reports will be unavailable if a cookie is not set, and once third-party cookies are deprecated. All debug reports described in this guide are transitional debug reports.
  • Success debug reports track successful generation of an attribution report. They relate directly to an attribution report. Success debug reports have been available since Chrome 101 (April 2022).
  • Verbose debug reports can track missing reports and help you determine why they're missing. They indicate cases where the browser did not record a source or trigger event, (which means it will not generate an attribution report), and cases where an attribution report can't be generated or sent for some reason. Verbose debug reports include a type field that describes the reason why a source event, trigger event or attribution report was not generated. Verbose debug reports are available starting in Chrome 109 (Stable in January 2023).
  • Debug keys are unique identifiers you can set on both the source side and the trigger side. Debug keys enable you to map cookie-based conversions and attribution-based conversions. When you've set up your system to generate debug reports and set debug keys, the browser will include these debug keys in all attribution reports and debug reports.

For more concepts and key terms used throughout our documentation, refer to the Privacy Sandbox glossary.

วิธี: ตรวจสอบการผสานรวมแบบเรียลไทม์

  1. ตั้งค่าระบบเพื่อสร้างรายงานการแก้ไขข้อบกพร่องที่สําเร็จ ดูวิธีในส่วนที่ 2: ตั้งค่ารายงานข้อบกพร่อง
  2. ทุกครั้งที่ติดตั้งใช้งานโค้ดการรายงานผลการระบุแหล่งที่มา ให้ตรวจสอบแบบเรียลไทม์ว่าคุณได้รับรายงานการแก้ไขข้อบกพร่องที่สําเร็จบางรายการในปลายทางหรือไม่ หากเป็นเช่นนั้น แสดงว่าการตั้งค่าการรายงานผลการระบุแหล่งที่มาใช้งานได้
  3. ระบบจะส่งรายงานการแก้ไขข้อบกพร่องที่สำเร็จเมื่อเกิด Conversion เท่านั้น แต่คุณอาจต้องตรวจสอบว่าได้ตั้งค่าการผสานรวมอย่างถูกต้องแล้วโดยไม่คำนึงถึง Conversion นั่นคือคุณต้องการตรวจสอบว่าได้ลงทะเบียนแหล่งที่มาเรียบร้อยแล้ว คุณสามารถใช้ความสําเร็จในการลงทะเบียนแหล่งที่มาและรายงานการแก้ไขข้อบกพร่องแบบละเอียดเพื่อให้บรรลุเป้าหมายนี้ ดูวิธีตั้งค่าได้ในส่วนที่ 2: ตั้งค่ารายงานข้อบกพร่อง

วิธีการ: วิเคราะห์การสูญเสียและแก้ปัญหาการผสานรวม

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

ภาพรวม

ขั้นตอนการวิเคราะห์การสูญเสีย
ขั้นตอนการวิเคราะห์การสูญเสีย

ใช้คีย์การแก้ไขข้อบกพร่อง (<source_debug_key, trigger_debug_key> คู่) เพื่อแมป Conversion ของคุกกี้กับรายงานการแก้ไขข้อบกพร่องที่สําเร็จ สําหรับ Conversion ที่เกิดจากคุกกี้แต่ละรายการ คุณได้รับรายงานการแก้ไขข้อบกพร่องที่สําเร็จที่เกี่ยวข้องในเวลาที่เกิด Conversion หรือไม่

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

หากไม่: แสดงว่า Conversion ไม่ได้ลงทะเบียนด้วย Attribution Reporting ใช้<source_debug_key, trigger_debug_key>คู่ (หรือคีย์แก้ไขข้อบกพร่องของแหล่งที่มาหากไม่มีคีย์แก้ไขข้อบกพร่องของทริกเกอร์) เพื่อแมป Conversion ของคุกกี้กับรายงานการแก้ไขข้อบกพร่องแบบละเอียด สำหรับ Conversion แต่ละรายการเหล่านี้ คุณได้รับรายงานการแก้ไขข้อบกพร่องแบบละเอียดที่เกี่ยวข้อง ณ จุดใดจุดหนึ่ง (แหล่งที่มาหรือเวลาที่ทริกเกอร์) หรือไม่

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

  • หากได้รับรายงานการแก้ไขข้อบกพร่องแบบละเอียด ให้ดูฟิลด์ type

    • หาก type เป็น source-success แสดงว่าลงทะเบียนแหล่งที่มาเรียบร้อยแล้ว แต่ทริกเกอร์ยังไม่สำเร็จ หากต้องการจำกัดสาเหตุที่ไม่มีรายงานการแก้ไขข้อบกพร่องที่สําเร็จ ให้มองหารายงานการแก้ไขข้อบกพร่องแบบละเอียดที่เกี่ยวข้องของประเภทอื่นๆ รายงานนั้นจะระบุปัญหาในฝั่งทริกเกอร์

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

สถานการณ์ที่เป็นไปได้

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

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

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

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

รายงานการแก้ไขข้อบกพร่องแบบละเอียดของประเภท source-success

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

แต่มีข้อควรระวังอยู่ 1 ข้อ ดังนี้

รายงานการแก้ไขข้อบกพร่องแบบละเอียดของประเภทอื่นๆ

หากได้รับรายงานการแก้ไขข้อบกพร่องแบบละเอียดของ Conversion คุกกี้ประเภทอื่น คุณจะไม่ได้รับรายงานการแก้ไขข้อบกพร่องที่สําเร็จ และจะไม่ได้รับรายงานการระบุแหล่งที่มาในภายหลังด้วย เนื่องจากรายงานแบบละเอียดหมายความว่าเกิดข้อผิดพลาดที่รายงานได้ มีบางอย่างขัดขวางการลงทะเบียนแหล่งที่มา การลงทะเบียนทริกเกอร์ การสร้างรายงาน หรือการส่งรายงาน สาเหตุที่เป็นไปได้:

  • ขีดจำกัดด้านความเป็นส่วนตัว
  • จำนวนสูงสุดในการเก็บข้อมูล
  • กฎที่กำหนดเอง
  • ปัญหาการใช้งานในโค้ด
  • ข้อบกพร่องของเบราว์เซอร์

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

ไม่มีรายงานการแก้ไขข้อบกพร่อง

หากได้รับเฉพาะรายงานการระบุแหล่งที่มา (ไม่มีรายงานการแก้ไขข้อบกพร่องที่สำเร็จและรายงานการแก้ไขข้อบกพร่องแบบละเอียด) สำหรับ Conversion คุกกี้หนึ่งๆ แสดงว่ามีบางอย่างที่ทำให้ระบบสร้างรายงานการแก้ไขข้อบกพร่องไม่ได้ สาเหตุที่เป็นไปได้:

  • ค่ากำหนดของผู้ใช้ (ผู้ใช้ปิดคุกกี้ของบุคคลที่สาม)
  • ไม่มีคุกกี้หรือคีย์การแก้ไขข้อบกพร่อง (ล้างคีย์การแก้ไขข้อบกพร่องเนื่องจากไม่มีคุกกี้) ใน chrome://attribution-internals ให้เปิดแท็บบันทึก แล้วดูว่ามีปัญหาใดปรากฏขึ้นหรือไม่
  • ปัญหาเกี่ยวกับเครือข่ายที่เกิดขึ้นในเวลาแหล่งที่มาหรือเวลาทริกเกอร์ แต่ไม่ได้เกิดขึ้นเมื่อส่งรายงานการระบุแหล่งที่มา

คุณได้รับรายงานการระบุแหล่งที่มาหรือไม่

นี่คือกรณีที่ไม่ได้รายงานการแก้ไขข้อบกพร่อง: หาก Conversion คุกกี้ที่ระบุ คุณไม่ได้รับรายงานใดๆ (ไม่มีรายงานการแก้ไขข้อบกพร่องใดๆ ไม่มีรายงานการระบุแหล่งที่มา) แสดงว่าเกิดข้อผิดพลาดที่รายงานไม่ได้ สาเหตุที่เป็นไปได้:

  • ปัญหาการผสานรวมขั้นพื้นฐาน ดูวิธีแก้ปัญหาเหล่านี้ได้ในแก้ไขปัญหาการผสานรวมพื้นฐาน
  • ปัญหาเกี่ยวกับเครือข่ายที่อาจเกิดขึ้น
  • ค่ากำหนดของผู้ใช้ในการตั้งค่าเบราว์เซอร์ เช่น ปิด Privacy Sandbox

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

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

ลงทะเบียนแหล่งข้อมูลสำเร็จ

ลงทะเบียนแหล่งที่มาเรียบร้อยแล้ว

source-success
รายละเอียดและเนื้อหารายงาน

รายงานข้อจำกัดด้านความเป็นส่วนตัว

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

source-destination-limit
รายละเอียดและเนื้อหาของรายงาน
source-noised
รายละเอียดและเนื้อหาของรายงาน
trigger-attributions-per-source-destination-limit
รายละเอียดและเนื้อหาของรายงาน
trigger-reporting-origin-limit
รายละเอียดและเนื้อหาของรายงาน
trigger-event-noise
รายละเอียดและเนื้อหาของรายงาน
trigger-event-excessive-reports
ระบบจะสร้างรายงานนี้หากจำนวนรายงานเกินขีดจำกัด โดยคุณจะลงทะเบียน Conversion สำหรับการดูได้สูงสุด 1 รายการ และสำหรับการคลิกได้สูงสุด 3 รายการ โปรดทราบว่าคุณกำหนดค่ารายงานที่จะรับได้โดยการตั้งค่าลำดับความสำคัญ รายละเอียดและเนื้อหาของรายงาน

รายงานข้อจำกัดของพื้นที่เก็บข้อมูล

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

source-storage-limit
รายละเอียดและเนื้อหาของรายงาน
trigger-event-storage-limit
รายละเอียดและเนื้อหาของรายงาน
trigger-aggregate-storage-limit
รายละเอียดและเนื้อหาของรายงาน

รายงานกฎที่กำหนดเอง

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

trigger-no-matching-filter-data
รายละเอียดและเนื้อหาของรายงาน
trigger-event-no-matching-configuration
รายละเอียดและเนื้อหาของรายงาน
trigger-event-deduplicated
รายละเอียดและเนื้อหาของรายงาน
trigger-aggregate-deduplicated
รายละเอียดและเนื้อหาของรายงาน
trigger-event-low-priority
รายละเอียดและเนื้อหาของรายงาน
trigger-event-report-window-passed
รายละเอียดและเนื้อหาของรายงาน
trigger-aggregate-report-window-passed
รายละเอียดและเนื้อหาของรายงาน

รายงานแบบละเอียดอื่นๆ

รายงานเหล่านี้อาจบ่งบอกถึงปัญหาในการติดตั้งใช้งานที่อาจเกิดขึ้นในโค้ด

trigger-no-matching-source
ปัญหานี้อาจเกิดจากการติดตั้งใช้งาน ตรวจสอบว่าการตั้งค่า <reporting origin, destination> ไม่มีการกำหนดค่าที่ไม่ถูกต้อง ซึ่งอาจเป็นลักษณะการทำงานของ API ที่คาดไว้ด้วย เช่น ผู้ใช้ล้างข้อมูล ณ จุดใดจุดหนึ่งหลังจากมีส่วนร่วมกับโฆษณาและก่อนทำ Conversion หรือผู้ใช้ทำ Conversion โดยไม่เคยเห็นโฆษณาที่เกี่ยวข้อง รายละเอียดและเนื้อหาของรายงาน
trigger-aggregate-no-contributions
ลักษณะการทำงานนี้อาจไม่ใช่สิ่งที่คุณต้องการให้โค้ดเป็น แก้ปัญหาโค้ดการลงทะเบียนทริกเกอร์ และตรวจสอบว่าการกำหนดค่าการมีส่วนร่วมถูกต้อง รายละเอียดและเนื้อหาของรายงาน
trigger-aggregate-insufficient-budget
ลักษณะการทำงานนี้อาจไม่ใช่สิ่งที่คุณต้องการให้โค้ดเป็น ตรวจสอบรหัสการลงทะเบียนทริกเกอร์อีกครั้งเพื่อให้แน่ใจว่าผลรวมของการมีส่วนร่วมทั้งหมดไม่เกินงบประมาณการมีส่วนร่วม รายละเอียดและเนื้อหาของรายงาน

ข้อผิดพลาดที่ไม่คาดคิด (ข้อบกพร่องที่อาจเกิดขึ้นในเบราว์เซอร์)

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

source-unknown-error
รายละเอียดและเนื้อหาของรายงาน
trigger-unknown-error
รายละเอียดและเนื้อหาของรายงาน

ตัวอย่างการวิเคราะห์การสูญเสีย

ขั้นตอนที่ 1: ตั้งค่าและแมปด้วยคุกกี้

ทำตามวิธีการในส่วนที่ 2: ตั้งค่ารายงานการแก้ไขข้อบกพร่องเพื่อตั้งค่าระบบให้สร้างรายงานการแก้ไขข้อบกพร่องที่สำเร็จและรายงานการแก้ไขข้อบกพร่องแบบละเอียด

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

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

ในตัวอย่างนี้ สมมติว่าคุณติดตาม Conversion 100 รายการด้วยระบบที่ใช้คุกกี้

ทุกครั้งที่บันทึก Conversion ที่อิงตามคุกกี้ ให้มองหารายงานการแก้ไขข้อบกพร่องที่สําเร็จ (ส่งทันที) ซึ่งมีคู่ <source_debug_key, trigger_debug_key> เดียวกันกับ Conversion ที่อิงตามคุกกี้นี้

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

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

ขั้นตอนที่ 3: การประเมินการสูญเสียโดยย่อ

100-70 = 30 รายงานการแก้ไขข้อบกพร่องที่สำเร็จหายไป ซึ่งหมายความว่าระบบไม่ได้บันทึก Conversion ทั้ง 30 รายการนี้ (ที่ติดตามในการติดตั้งใช้งานที่อิงตามคุกกี้) ด้วยการรายงานการระบุแหล่งที่มา คุณจะไม่ได้รับรายงานการระบุแหล่งที่มาสำหรับแคมเปญเหล่านี้

เนื่องจากคุณมี Conversion ที่อิงตามคุกกี้ 100 รายการ และ Conversion ที่อิงตามการระบุแหล่งที่มาเพียง 70 รายการ การสูญเสียจึงอยู่ที่ 30% ตอนนี้คุณมีการประเมินการสูญเสียโดยย่อแล้ว

ขั้นตอนที่ 4: วิเคราะห์สาเหตุ

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

  • สมมติว่ามีคีย์ 10 รายการที่ไม่มีรายงานการแก้ไขข้อบกพร่องแบบละเอียด ตรวจสอบว่ามีปัญหาเกี่ยวกับการผสานรวมหรือไม่ หากไม่เป็นเช่นนั้น อาจเป็นเพราะพฤติกรรมของผู้ใช้
  • คุณมีรายงานการแก้ไขข้อบกพร่องแบบละเอียด 20 รายการ ตอนนี้คุณปรับแต่งการวิเคราะห์การสูญเสียได้แล้ว วิเคราะห์typeของรายงานแบบละเอียดแต่ละรายการ ตัวอย่างเช่น คุณอาจพบว่า
    • รายงาน 10 ฉบับ (= 10% ในตัวอย่างของเรา) ไม่มีเนื่องจาก pending destination limit
    • รายงาน 5 ฉบับ (= 5%) หายไปเนื่องจาก trigger-aggregate-no-contributions
    • รายงาน 5 ฉบับ (= 5%) หายไปเนื่องจาก unknown-error

ขั้นตอนที่ 5: ดำเนินการและแก้ปัญหา

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

การดำเนินการที่ต้องทำจะขึ้นอยู่กับtypeของรายงานแบบละเอียดแต่ละรายการ ดูรายละเอียดได้ที่การอ้างอิงรายงานแบบละเอียด เช่น

  • pending-destination-limit คือการคุ้มครองความเป็นส่วนตัว คุณไม่จำเป็นต้องดำเนินการใดๆ ใช้ตัวเลขนี้เป็นจุดข้อมูลเพื่อการมองเห็นและการตรวจสอบของคุณเอง
  • trigger-aggregate-no-contributions อาจเป็นสัญญาณของปัญหาการติดตั้งใช้งานทางฝั่งคุณ วิเคราะห์เรื่องนี้เพิ่มเติม ใช้รายละเอียดในเนื้อหาของรายงานแบบละเอียดเพื่อแก้ปัญหาและแก้ไขหากจำเป็น
  • unknown-error อาจเป็นสัญญาณของข้อบกพร่องในเบราว์เซอร์หรือข้อผิดพลาดเกี่ยวกับเครือข่าย หากพบปัญหานี้ซ้ำๆ โปรดแจ้งข้อบกพร่องแก่นักพัฒนาเบราว์เซอร์