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

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

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

อภิธานศัพท์

  • ต้นทางการรายงานคือต้นทาง ที่ตั้งค่าส่วนหัวแหล่งที่มาและทริกเกอร์ของ Attribution Reporting ระบบจะส่งรายงานทั้งหมดที่สร้างโดยเบราว์เซอร์ไปยังต้นทางนี้ ในคำแนะนำนี้ เราใช้ https://adtech.example เป็นตัวอย่างที่มาของการรายงาน
  • รายงานการระบุแหล่งที่มา (รายงานสั้นๆ) คือรายงานสุดท้าย (ระดับเหตุการณ์หรือที่รวบรวมไว้) ที่มีข้อมูลการวัดที่คุณขอไว้
  • รายงานการแก้ไขข้อบกพร่องมีข้อมูลเพิ่มเติมเกี่ยวกับรายงานการระบุแหล่งที่มา หรือเกี่ยวกับเหตุการณ์แหล่งที่มาหรือทริกเกอร์ การได้รับรายงานการแก้ไขข้อบกพร่องไม่ได้หมายความว่ามีบางอย่างทำงานผิดปกติเสมอไป รายงานการแก้ไขข้อบกพร่องมี 2 ประเภท
  • รายงานการแก้ไขข้อบกพร่องแบบเปลี่ยนผ่านคือรายงานการแก้ไขข้อบกพร่องที่จำเป็นต้องตั้งค่าคุกกี้เพื่อสร้างและส่ง รายงานแก้ไขข้อบกพร่องในช่วงเปลี่ยนผ่านจะใช้งานไม่ได้หากไม่มีการตั้งค่าคุกกี้และเมื่อเลิกใช้งานคุกกี้ของบุคคลที่สามแล้ว รายงานแก้ไขข้อบกพร่องทั้งหมดที่อธิบายไว้ในคู่มือนี้เป็นรายงานแก้ไขข้อบกพร่องในช่วงเปลี่ยนผ่าน
  • รายงานการแก้ไขข้อบกพร่องสําเร็จจะติดตามการสร้างรายงานการระบุแหล่งที่มาที่สําเร็จ ซึ่งเกี่ยวข้องโดยตรงกับรายงานการระบุแหล่งที่มา รายงานแก้ไขข้อบกพร่องสำเร็จพร้อมให้ใช้งานแล้วตั้งแต่ Chrome 101 (เมษายน 2022)
  • รายงานการแก้ไขข้อบกพร่องอย่างละเอียดจะติดตามรายงานที่หายไปและช่วยคุณหาสาเหตุที่รายงานหายไปได้ โดยจะระบุกรณีที่เบราว์เซอร์ไม่ได้บันทึกเหตุการณ์แหล่งที่มาหรือทริกเกอร์ (ซึ่งหมายความว่าจะไม่สร้างรายงานการระบุแหล่งที่มา) และกรณีที่สร้างหรือส่งรายงานการระบุแหล่งที่มาไม่ได้ด้วยเหตุผลบางอย่าง รายงานการแก้ไขข้อบกพร่องแบบละเอียดมีช่อง type ที่อธิบายเหตุผลที่ไม่มีการสร้างเหตุการณ์แหล่งที่มา เหตุการณ์ทริกเกอร์ หรือรายงานการระบุแหล่งที่มา รายงานการแก้ปัญหาแบบละเอียดจะพร้อมให้บริการใน Chrome 109 เป็นต้นไป (เสถียรในเดือนมกราคม 2023)
  • คีย์การแก้ไขข้อบกพร่องคือตัวระบุที่ไม่ซ้ำกันซึ่งตั้งค่าได้ทั้งในด้านแหล่งที่มาและฝั่งทริกเกอร์ คีย์การแก้ไขข้อบกพร่องช่วยให้คุณแมป Conversion ที่อิงตามคุกกี้และ Conversion ที่อิงตามการระบุแหล่งที่มาได้ เมื่อตั้งค่าระบบให้สร้างรายงานการแก้ไขข้อบกพร่องและตั้งค่าคีย์การแก้ไขข้อบกพร่องแล้ว เบราว์เซอร์จะรวมคีย์การแก้ไขข้อบกพร่องเหล่านี้ไว้ในรายงานการระบุแหล่งที่มาและรายงานการแก้ไขข้อบกพร่องทั้งหมด

โปรดอ่านอภิธานศัพท์ของ Privacy Sandbox เพื่อดูแนวคิดและคําสําคัญอื่นๆ ที่ใช้ในเอกสารประกอบของเรา

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

  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 อาจเป็นสัญญาณของข้อบกพร่องในเบราว์เซอร์หรือข้อผิดพลาดเกี่ยวกับเครือข่าย หากพบปัญหานี้ซ้ำๆ โปรดแจ้งข้อบกพร่องแก่นักพัฒนาเบราว์เซอร์