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

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

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

อภิธานศัพท์

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.

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

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

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

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

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

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

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

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

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

ตรวจสอบส่วนหัวการรายงานการระบุแหล่งที่มา

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

หากต้องการเลือกรับรายงานการแก้ไขข้อบกพร่อง ให้ตอบกลับด้วย report-header-errors ในส่วนส่วนหัวการตอบกลับ Attribution-Reporting-Info

Attribution-Reporting-Info: report-header-errors

โปรดทราบว่า Attribution-Reporting-Info คือส่วนหัว Structured Data ของพจนานุกรมAttribution-Reporting-Info ดังนั้นการให้คีย์บูลีน report-header-errors จะถือว่ามีค่าเป็นจริง

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

https://<reporting origin>/.well-known/attribution-reporting/debug/verbose

ข้อมูลรายงานจะรวมอยู่ในเนื้อหาคำขอเป็นรายการ JSON ของออบเจ็กต์ที่มีแบบฟอร์มนี้

[{
  "type": "header-parsing-error",
  "body": {
    "context_site": "https://source.example",
    "header": "Attribution-Reporting-Register-Source",
    "value": "!!!", // header value received in the response
    "error": "invalid JSON" // optional error details that may vary across browsers or different versions of the same browser
  }
}]

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

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

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

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

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

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

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

คีย์การแก้ไขข้อบกพร่องแต่ละรายการต้องเป็นจำนวนเต็ม 64 บิตที่ไม่มีเครื่องหมายซึ่งอยู่ในรูปแบบสตริง base-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 ในเบราว์เซอร์
ตรวจสอบว่าได้เลือกช่องทําเครื่องหมายแสดงรายงานการแก้ไขข้อบกพร่องทั้งในแท็บรายงานระดับเหตุการณ์และแท็บรายงานที่รวบรวมได้
เปิดเว็บไซต์ที่คุณใช้การรายงานการระบุแหล่งที่มา ทำตามขั้นตอนที่คุณใช้ในการสร้างรายงานการระบุแหล่งที่มาให้เสร็จสมบูรณ์ ขั้นตอนเดียวกันนี้จะสร้างรายงานแก้ไขข้อบกพร่องสำเร็จ
ใน 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
}

โค้ดสาธิต: source header

โค้ดสาธิต: ส่วนหัว ทริกเกอร์

ขั้นตอนที่ 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 เหมาะที่จะใช้เป็นค่านี้เนื่องจากคุณสร้างค่านี้ได้โดยการเปลี่ยน รายงานแบบละเอียดที่เกี่ยวข้องกับเหตุการณ์ทริกเกอร์มักจะเป็นตัวเลือกที่ดีกว่า ส่วนรายงานแบบละเอียดที่เกี่ยวข้องกับเหตุการณ์แหล่งที่มานั้นสร้างได้ยากกว่า

เปิด chrome://attribution-internals ในเบราว์เซอร์
เรียกให้แสดงการระบุแหล่งที่มา (แปลง) ในเว็บไซต์ที่ตั้งค่าด้วยการรายงานการระบุแหล่งที่มา เนื่องจากไม่มีการมีส่วนร่วมกับโฆษณา (การแสดงผลหรือการคลิก) ก่อน 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 ฉบับต่อความล้มเหลวและต่อประเภทรายงาน (ระดับเหตุการณ์หรือที่รวบรวมได้)
รายงานแบบละเอียด 2 ฉบับหากความล้มเหลวส่งผลต่อทั้งรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ โดยมีข้อยกเว้นคือ หากเหตุผลของความล้มเหลวเหมือนกันสำหรับรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ ระบบจะสร้างรายงานแบบละเอียดเพียง 1 รายการ (เช่น trigger-no-matching-source)

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