หน้านี้ได้รับการแปลโดย Cloud Translation API

ตั้งค่ารายงานการแก้ไขข้อบกพร่องสำหรับ Attribution Reporting

ส่วนที่ 2 จาก 3 เกี่ยวกับการแก้ไขข้อบกพร่อง Attribution Reporting ตั้งค่ารายงานการแก้ไขข้อบกพร่อง

อภิธานศัพท์

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

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

มีคำถามเกี่ยวกับการใช้งานใช่ไหม

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

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

ก่อนตั้งค่ารายงานการแก้ไขข้อบกพร่อง ให้ทำตามขั้นตอนต่อไปนี้

ตรวจสอบว่าคุณใช้แนวทางปฏิบัติแนะนำสำหรับการผสานรวม API แล้ว

ตรวจสอบว่าโค้ดอยู่หลังการตรวจจับฟีเจอร์ เรียกใช้โค้ดต่อไปนี้เพื่อให้แน่ใจว่า API ไม่ได้ถูกบล็อกโดย Permissions-Policy
```
if (document.featurePolicy.allowsFeature('attribution-reporting')) {
// the Attribution Reporting API is enabled
}
```
หากการตรวจสอบการตรวจหาฟีเจอร์นี้ส่งคืนค่า "จริง" ระบบจะอนุญาต API ในบริบท (หน้า) ที่ดำเนินการตรวจสอบ
(ไม่จำเป็นในช่วงทดสอบ: ตรวจสอบว่าคุณได้ตั้งค่านโยบายสิทธิ์แล้ว)

แก้ไขปัญหาการผสานรวมพื้นฐาน

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

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

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

ตั้งค่าคุกกี้ต่อไปนี้ในต้นทางการรายงาน

Set-Cookie: ar_debug=1; SameSite=None; Secure; Path=/; HttpOnly

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

โค้ดสาธิต: คุกกี้การแก้ไขข้อบกพร่อง

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

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

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

แมปคีย์การแก้ไขข้อบกพร่องฝั่งเซิร์ฟเวอร์กับข้อมูลเกี่ยวกับเวลาแหล่งที่มาเพิ่มเติมที่คุณคิดว่าเกี่ยวข้องกับการแก้ไขข้อบกพร่อง
แมปคีย์การแก้ไขข้อบกพร่องฝั่งทริกเกอร์กับข้อมูลเวลาทริกเกอร์เพิ่มเติมที่คุณคิดว่าเกี่ยวข้องกับการแก้ไขข้อบกพร่อง

เช่น คุณอาจตั้งค่าคีย์การแก้ไขข้อบกพร่องดังต่อไปนี้

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

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

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

Attribution-Reporting-Register-Source:
{
// … Usual fields for Attribution-Reporting-Register-Source
"debug_key":"647775351539539"
}

Attribution-Reporting-Register-Trigger:
{
// … Usual fields for Attribution-Reporting-Register-Trigger
"debug_key":"938321351539743"
}

รหัสสาธิต: คีย์การแก้ไขข้อบกพร่องต้นทาง โค้ดสาธิต: ทริกเกอร์คีย์การแก้ไขข้อบกพร่อง

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

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

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

ขั้นตอนที่ 3: ตั้งค่าปลายทางเพื่อรวบรวมรายงานการแก้ไขข้อบกพร่องที่ทำสำเร็จ

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

ปลายทางสำหรับรายงานการแก้ไขข้อบกพร่องที่สำเร็จระดับเหตุการณ์ https://adtech.example/.well-known/attribution-reporting/debug/report-event-attribution
- ปลายทางสำหรับรายงานแก้ไขข้อบกพร่องแบบรวบรวมข้อมูลได้ ได้แก่ https://adtech.example/.well-known/attribution-reporting/debug/report-aggregate-attribution

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

// Handle incoming event-Level Success Debug reports
adtech.post(
  '/.well-known/attribution-reporting/debug/report-event-attribution',
  async (req, res) => {
    // Debug report is in req.body
    res.sendStatus(200);
  }
);

// Handle incoming aggregatable Success Debug reports
adtech.post(
  '/.well-known/attribution-reporting/debug/report-aggregate-attribution',
  async (req, res) => {
    // Debug report is in req.body
    res.sendStatus(200);
  }
);

โค้ดสาธิต: ปลายทางรายงานการแก้ไขข้อบกพร่องระดับเหตุการณ์

โค้ดสาธิต: ปลายทางรายงานการแก้ไขข้อบกพร่องที่รวบรวมได้

ขั้นตอนที่ 4: ยืนยันว่าการตั้งค่าจะสร้างรายงานการแก้ไขข้อบกพร่องสําเร็จ

เปิด chrome://attribution-internals ในเบราว์เซอร์
ตรวจสอบให้แน่ใจว่าได้เลือกช่องทำเครื่องหมายแสดงรายงานการแก้ไขข้อบกพร่องทั้งในแท็บรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้
เปิดเว็บไซต์ที่คุณใช้ Attribution Reporting ทําตามขั้นตอนที่คุณใช้เพื่อสร้างรายงานการระบุแหล่งที่มา ขั้นตอนเดียวกันเหล่านี้จะสร้างรายงานการแก้ไขข้อบกพร่องสําเร็จ
ใน chrome://attribution-internals:
- ตรวจสอบว่ารายงานการระบุแหล่งที่มาสร้างขึ้นอย่างถูกต้อง
- ในแท็บรายงานระดับเหตุการณ์และแท็บรายงานที่รวบรวมได้ ให้ตรวจสอบว่ามีการสร้างรายงานการแก้ไขข้อบกพร่องสำเร็จด้วยเช่นกัน จดจำพวกเขาในรายการด้วยเส้นทาง debug สีน้ำเงิน

ภาพหน้าจอ: ข้อมูลภายในของการระบุแหล่งที่มา

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

ภาพหน้าจอ: บันทึกของเซิร์ฟเวอร์ต้นทางการรายงาน

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

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

{
  "attribution_destination": "https://advertiser.example",
  "randomized_trigger_rate": 0.0000025,
  "report_id": "7d76ef29-d59e-4954-9fff-d97a743b4715",
  "source_debug_key": "647775351539539",
  "source_event_id": "760938763735530",
  "source_type": "event",
  "trigger_data": "0",
  "trigger_debug_key": "156477391437535"
}

{
  "aggregation_service_payloads": [
    {
      "debug_cleartext_payload": "omRkYXRhgqJldmFsdWVEAACAAGZidWNrZXRQPPhnkD+7c+wm1RjAlowp3KJldmFsdWVEAAARMGZidWNrZXRQJFJl9DLxbnMm1RjAlowp3GlvcGVyYXRpb25paGlzdG9ncmFt",
      "key_id": "d5f32b96-abd5-4ee5-ae23-26490d834012",
      "payload": "0s9mYVIuznK4WRV/t7uHKquHPYCpAN9mZHsUGNiYd2G/9cg87Y0IjlmZkEtiJghMT7rmg3GtWVPWTJU5MvtScK3HK3qR2W8CVDmKRAhqqlz1kPZfdGUB4NsXGyVCy2UWapklE/r7pmRDDP48b4sQTyDMFExQGUTE56M/8WFVQ0qkc7UMoLI/uwh2KeIweQCEKTzw"
    }
  ],
  "shared_info": "{\"api\":\"attribution-reporting\",\"attribution_destination\":\"https://advertiser.example\",\"debug_mode\":\"enabled\",\"report_id\":\"4a04f0ff-91e7-4ef6-9fcc-07d000c20495\",\"reporting_origin\":\"https://adtech.example\",\"scheduled_report_time\":\"1669888617\",\"source_registration_time\":\"1669852800\",\"version\":\"0.1\"}",
  "source_debug_key": "647775351539539",
  "trigger_debug_key": "156477391437535"
}

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

ขั้นตอนที่ 3: เลือกใช้การแก้ไขข้อบกพร่องแบบละเอียดในส่วนหัวต้นทางและทริกเกอร์

ตั้งค่า debug_reporting เป็น true ทั้งใน Attribution-Reporting-Register-Source และ Attribution-Reporting-Register-Trigger

Attribution-Reporting-Register-Source:
{
// … Usual fields for Attribution-Reporting-Register-Source
"debug_key":"938321351539743",
"debug_reporting": true // defaults to false if not present
}

Attribution-Reporting-Register-Trigger:
{
// … Usual fields for Attribution-Reporting-Register-Trigger
"debug_key":"938321351539743",
"debug_reporting": true // defaults to false if not present
}

รหัสสาธิต: ส่วนหัว แหล่งที่มา

รหัสสาธิต: ส่วนหัวของทริกเกอร์

ขั้นตอนที่ 4: ตั้งค่าปลายทางเพื่อรวบรวมรายงานการแก้ไขข้อบกพร่องแบบละเอียด

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

https://adtech.example/.well-known/attribution-reporting/debug/verbose

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

// Handle incoming verbose debug reports
adtech.post(
  '/.well-known/attribution-reporting/debug/verbose',
  async (req, res) => {
    // List of verbose debug reports is in req.body
    res.sendStatus(200);
  }
);

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

รหัสสาธิต: ปลายทางรายงานการแก้ไขข้อบกพร่องแบบละเอียด

ขั้นตอนที่ 5: ยืนยันว่าการตั้งค่าจะสร้างรายงานการแก้ไขข้อบกพร่องแบบละเอียด

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

ประเด็นสำคัญ: เลือกรายงานการแก้ไขข้อบกพร่องแบบละเอียดที่ทำการทดสอบได้ง่าย trigger-no-matching-source เป็นตัวเลือกที่ดี เพราะคุณสามารถสร้างได้โดย Conversion รายงานแบบละเอียดที่เกี่ยวกับการทริกเกอร์เหตุการณ์มักจะเป็นตัวเลือกที่ดีกว่า ประเภทรายงานแบบละเอียดที่สัมพันธ์กับเหตุการณ์แหล่งที่มาจะน่าเบื่อมากกว่าเมื่อตั้งใจสร้าง

เปิด chrome://attribution-internals ในเบราว์เซอร์
เรียกให้แสดงการระบุแหล่งที่มา (Conversion) ในเว็บไซต์ที่ตั้งค่าการรายงานการระบุแหล่งที่มา และเนื่องจากไม่มีการมีส่วนร่วมกับโฆษณา (การแสดงผลหรือการคลิก) ก่อนเกิด Conversion นี้ ระบบจึงจะสร้างรายงานการแก้ไขข้อบกพร่องแบบละเอียดของประเภท trigger-no-matching-source
ใน chrome://attribution-internals ให้เปิดแท็บรายงานการแก้ไขข้อบกพร่องแบบละเอียด และตรวจสอบว่ามีการสร้างรายงานการแก้ไขข้อบกพร่องแบบละเอียดของประเภท trigger-no-matching-source แล้ว
ในเซิร์ฟเวอร์ ให้ตรวจสอบว่าปลายทางของคุณได้รับรายงานการแก้ไขข้อบกพร่องแบบละเอียดนี้ทันที

ขั้นตอนที่ 6: สังเกตรายงานการแก้ไขข้อบกพร่องแบบละเอียด

รายงานการแก้ไขข้อบกพร่องแบบละเอียดที่สร้างขึ้นในเวลาทริกเกอร์จะรวมทั้งคีย์การแก้ไขข้อบกพร่องฝั่งทริกเกอร์ (หากมีแหล่งที่มาที่ตรงกันสําหรับทริกเกอร์) รายงานการแก้ไขข้อบกพร่องแบบละเอียดที่สร้างขึ้นในเวลาต้นทางจะรวมคีย์การแก้ไขข้อบกพร่องฝั่งต้นทางด้วย

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

[
  {
    "body": {
      "attribution_destination": "http://arapi-advertiser.localhost",
      "randomized_trigger_rate": 0.0000025,
      "report_id": "92b7f4fd-b157-4925-999e-aad6361de759",
      "source_debug_key": "282273499788483",
      "source_event_id": "480041649210491",
      "source_type": "event",
      "trigger_data": "1",
      "trigger_debug_key": "282273499788483"
    },
    "type": "trigger-event-low-priority"
  },
  {
    "body": {
      "attribution_destination": "http://arapi-advertiser.localhost",
      "limit": "65536",
      "source_debug_key": "282273499788483",
      "source_event_id": "480041649210491",
      "source_site": "http://arapi-publisher.localhost",
      "trigger_debug_key": "282273499788483"
    },
    "type": "trigger-aggregate-insufficient-budget"
  }
]

รายงานแบบละเอียดแต่ละรายการจะมีช่องต่อไปนี้

Type: สาเหตุที่ทำให้ระบบสร้างรายงาน หากต้องการดูข้อมูลเกี่ยวกับประเภทรายงานแบบละเอียดทั้งหมดและการดำเนินการที่ต้องทำโดยขึ้นอยู่กับรายงานแต่ละประเภท ให้ดูข้อมูลอ้างอิงของรายงานแบบละเอียดในส่วนที่ 3: ตำราอาหารในการแก้ไขข้อบกพร่อง
Body: เนื้อหาของรายงาน แล้วแต่ประเภท ตรวจสอบข้อมูลอ้างอิงรายงานแบบละเอียดในส่วนที่ 3: ตำราอาหารในการแก้ไขข้อบกพร่อง

เนื้อหาของคำขอจะมีรายงานแบบละเอียดอย่างน้อย 1 ฉบับ และไม่เกิน 2 รายงาน ดังนี้

รายงานแบบละเอียด 1 รายการ หากความล้มเหลวส่งผลต่อรายงานระดับเหตุการณ์เท่านั้น (หรือส่งผลต่อรายงานที่รวบรวมได้เท่านั้น) ความล้มเหลวในการลงทะเบียนแหล่งที่มาหรือทริกเกอร์มีเพียงเหตุผลเดียว ดังนั้นระบบจึงสร้างรายงานแบบละเอียดได้ 1 ฉบับต่อความล้มเหลว 1 ครั้งต่อรายงานแต่ละประเภท (ระดับเหตุการณ์หรือรวบรวมข้อมูลได้)
รายงานแบบละเอียด 2 ฉบับหากความล้มเหลวส่งผลต่อทั้งรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ โดยมีข้อยกเว้นคือ หากสาเหตุของความล้มเหลวเหมือนกันสำหรับรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ จะมีการสร้างรายงานแบบละเอียดเพียง 1 รายการ (เช่น trigger-no-matching-source)

รายการถัดไป

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